Hi Jonathan,

Well I waited a few days to see if anyone else would come in on this, but its
been pretty quiet, so it looks like few others considered it to be a worth
while discussion as well......;-)

 PK> How about the method used by unix? 

 JdBP> Given that UNIX doesn't *have* drive letters, I can 
 JdBP> see that this idea is going to be an interesting one. 
 JdBP>  (-:

Ok, maybe I should have made that "How about mounting other partitions off the 
Root (booted) file system (partition) similar to unix."

 PK> Then the "issue" over the visibility and ordering of
 PK> primary/logical partitions goes away completely...

 JdBP> Actually, no it doesn't go away.  It is just renamed in the hope that 
 JdBP> everyone will overlook it.

Not at all, it really does "go away" as far as the USER is concerned (and it
IS the USER we are doing this for isn't it?). Of course these issues are going 
to remain for the OS, regardless of it being a manual or automatic process. In 
my scenario, ALL "other" partitions are accessed under the Root by USER
defined controls. When the USER wants to assigned a drive letter (other than
C:), then HE has can make the necessary decisions. Alternatively he can set it 
up to automatically assign Drive letters much as it does now, however the OS
should work on the "single drive letter" principle. If the User wants, his OS
can boot and run fine using just the ONE drive letter, which will ALWAYS be
C:.

 JdBP> (Amazingly, this actually seems to happen.  (-:)  What on "PC 
 JdBP> style" operating systems is an issue of drive letter assignment 
 JdBP> order is, on PC unices, an issue of the assignment order of 
 JdBP> device numbers. 

HOWEVER, in my scenario that device "ordering" is NOT critical to the
operation of the OS other than for the initial install stage, and the
methodology of doing that is already worked out and handled by the install
routines anyway. To the User, nothing really changes in this area, other than
the identification label (IE the drive letter) that is attached to the device. 
In the User control scenario only ONE letter (C:) is assigned by the OS, ALL
others are assigned by the User. If the system is set up to automatically
assign Drive latters, then that is optional, but NOT required by the OS.

 JdBP> One still has to change things. 

Try as I might, I can't see your logic here. Whatever changes that affect the
boot up process will change for ALL OS's that need to find that same device
again, regardless of the storage mechanism or "labels" that are used to
address the device. Yes, this part will be the biggest change that a human
will have to work with, however the overall process is not far removed from
having to work with the current "dynamic" drive letter assignment anyway. 

Of course people can move from a Dos drive letter based environment to a unix
one, they have been doing it for quite a while now. Its like moving a person
from riding a 2 wheeled bike to a motorcar, the roadmap is the same, the road
itself is the same, and the passengers are the same, its just the skills
needed to navigate the vehicle are slightly different, but certainly not
unattainable.

 JdBP> One simply has to change *different* things.

Exactly, one still has partitions to work with, but the addressing of those
partitions changes from drive letters to paths under the Root. Instead of this 
process being a dynamic (arbitrary) assignment by the OS, the partition
"assignment" phase moves totally to USER control. Sure, you can have an
automatic assignment tool that builds the map for you, or it can suggest what
partitions are available and leave it up to the user to decide what they are
and where to place them. 

I think the main point I am trying to make here is that the ONLY OS decided
issues relate to the BOOT partition, everything else is under total USER
control (either automatic or manual).

 JdBP> Indeed, this is in fact made *more* complicated on unices than on "PC 
 JdBP> style" operating systems because one has to have 
 JdBP> *additional* mechanisms to enable the partition 
 JdBP> number for the root volume to be overridden in the 
 JdBP> case that the re-partitioning happens to have altered 
 JdBP> it.  This is because it is compiled into the kernel.  

I said SIMILAR to the unix style of partition assignment, however who says you 
have to follow the unix brain dead style of manually rebuilding the kernal for 
such changes! I actually find this methodology a bit backward in todays modern 
computing environment, however I suppose unix has been around a long time and
its hard to teach an old dog new tricks.......;-)

 JdBP> ( Actually, there's no reason that unix boot loaders 
 JdBP> cannot do the same as "PC style" operating systems do 
 JdBP> here and have the boot loader automatically work out 
 JdBP> the correct device number for the root volume and 
 JdBP> pass it to the kernel.  I suspect that the reason 
 JdBP> that they do not is a blind refusal on the part of 
 JdBP> unix devotees to take a good idea from "peecee 
 JdBP> operating systems" despite it being a good idea, more 
 JdBP> than anything else. )

Aha... we think alike in this area then.........;-)

Cheers............pk.


--- Maximus/2 3.01