[openbeosstorage] Re: API Extensions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 14 Jan 2003 17:15:39 +0100 CET
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > I am not sure how useful this would be - I think a way to retrieve
> > the
> > final device name would be much nicer, and would have a greater
> > flexibility.
> ... to retrieve the final device name for what given data=3F
Well, to some degree, the partition modules set the file name - it's
currently {session}=5F{partition} in the same path as the examined raw
device.
That name or just the info should or must be in the B=5FSET=5FPARTITION
equivalent to devfs. That way it either knows the correct name or it
asks for it using the session and partition identifiers "against" the
raw device.
Have I understood you correctly=3F
> > No, you haven't missed it, it still can't do this :-)
> > Anyway, it will be able to mount HDs (probably some time) before it
> > will be able to boot from a hard disk.
> I don't have a floppy drive (that's not entirely true, but more or
> less),
> so I have to stick to Bochs, which is not really the ideal test
> environment.
Not ideal, that's right, but working well enough. Although VMware is
supposed to be much faster :-)
> > I think the boot process as it
> > is in BeOS will take some time until it is done (and it's not that
> > important while we are in development for R1).
> At the latest, when we start to port our libbe to our libroot, I
> would
> very much appreciate to be able to boot from HD. It will certainly be
> necessary anyway, as the system won't fit on a floppy disk. :-)
No, it won't be necessary then - I think we will first have a similar
boot strategy as R5, allowing to put all necessary files on a floppy
disk and boot from there. That info might also be written to a
dedicated hard disk partition, though.
In any case, this will happen before we will be able to boot directly
from a HD - but I can't tell you when that will be because booting is
not yet a priority (of course I mean booting from HD, not booting in
general ;-))
> > AFAIK Apple partitions use in fact strings to find out about the
> > partition type. I think having both fields as you planned it is the
> > best way to handle this.
> But isn't that even more a reason to drop the code field and let the
> intel partition add-on convert it to a string.
Yeah, might be right, but file systems could inspect the intel
partition code field for their own use (even if the partition add-on
couldn't find a nice string for it).
BTW the new partition format for the IA-64 platform does also support
names for partitions (not only the volume contained therein).
> One problem with this may be, that the data may not be of fixed size.
> Probably not for the Intel system, but imagine a system that allows
> for a
> partition to have an arbitrary number of sub-partitions.
That should have been a "per partition" entry, so from the system's
point of view, there aren't any sub partitions - extended partitions
would just be listed normally.
> The second problem is -- not a real problem, but at least not nice --
> that
> the GUI add-on had to query this information by itself.
Hm... do you have any idea how to change this=3F Probably we could add an
option to the Device API to get this information for the add-on.
> The third problem arises with unpartitioned disks: There are no
> partitions
> you could get an info for.
Yes, but that's not really a problem, is it=3F The Device API will just
ask for a particular partitioning scheme to be used, or not=3F
> And last but not least: There may be information for the partitioning
> system that is not bound to the partitions themselves. E.g. `use XYZ
> style partitions'.
What do you mean=3F
Anyway, I've just another thing to add:
For example Windows uses an additional proprietary partitioning system
- for example to be able to create volumes that span over several
partitions and drives. Or to have a specific RAID setup.
Although this makes sense, my plan to integrate such functionality is
as follows (put your favourite R2 disclaimer in here :-)):
When a disk is scanned, all directly mountable partitions are
published, the rest should be internally known somehow, or remembered
on request (but probably not visible from outside the kernel). That
way, we could have a special partition that saves information about
volumes that span several disks/partitions and whatever else, and could
also support 3rd party solutions via dedicated drivers or just cover
this information in a settings file (the latter is not perfect solution
because we don't want to have the RAID array depending on the boot
system if possible).
The volume manager can then collect all partitions needed for a volume
and publish a special device that let you access it. This device either
accesses the raw disk directly (and constraints itself to the correct
partition) or uses the devfs partitions to access the data and let the
file system believe there is a contiguous space it could work on
(mostly depends on wether those partitions should be visible or not
from userland, but there might be some issues which prevent the
latter).
Either way, the kernel could completely set up the volume structures
without intervention from a user, making it possible to access those
disks once the boot process has loaded all drivers (booting has
obviously to be done from standard partitions, though, or could you add
support for striped disks in the 1024 bytes of our boot loader=3F :-))).
Thoughts=3F
BTW NT has one fs recognizer to not have to load all file systems when
sniffing for the correct fs. I am not sure we should have something
like this, and if, then only as a fall back (actually meaning the
opposite :-).
Adios...
Axel.
Other related posts:
