[openbeosstorage] Re: API Extensions

> 
> 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.

Yes.

> 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.

Yes.

> Have I understood you correctly=3F

Er, probably not. :-)
You wrote, that it would be nice to retrieve the final device name 
(representing the partition I suppose). And what I wanted to know is, 
what the input for that function should be. A FD for the partition 
device would be sufficient, as one can get a partition_info via 
B_GET_PARTITION_INFO and construct the path from the one for the `raw' 
device and the session+partition identifiers. A partition_info is 
obviously sufficient, too.
Or were you simply pointing out the fact, that it is inconvenient or 
simply a lack of abstraction provided by the system, that one has to 
construct the partition device path from the `raw' device name and the 
identifiers manually, and that there should be a function to do that?

> > > 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 :-)

Uh, speed. Won't OBOS be so fast, that one won't notice the difference 
between it running in Bochs and BeOS R5 running natively? ;-)
If not, what are you kernel guys doing, eh? ;-)

> > > 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 ;-))

I see.

> > > 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).

Why should a FS be interested in that field? As it doesn't even exist 
for other partitioning systems, a FS can't (must not) rely on this 
value.

> BTW the new partition format for the IA-64 platform does also support 
> names for partitions (not only the volume contained therein).

Nice. Fortunately the (current version of the) extended_partition_info 
structure supports that, too. :-)

> > 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.

Sure, from the system's point of view there is only a simple list of 
partitions, but that has not much to do with how the partitioning 
system organizes them. If it allows an arbitrary number of sub-
partitions, then the tree structure must be passed to the GUI add-on. 
If you want to pass a list of sub-partition pointers/adresses/... for 
each partition, then the size of the data structure is not fixed. 

Agreed, in that example you can as well supply a pointer to the parent 
partition for each partition to reconstruct the tree, but that shows 
only that my example is bad. What I was driving at, is that it may be, 
that the per partition data are not of fixed size, and that this 
wouldn't work very well with the interface you proposed, while it is no 
problem with mine.

> > 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.

Well, none of the issues occurs, when -- as I proposed in the first 
place -- the partition module can be asked to return the parameters for 
a given session to be partitioned. For the whole session, not for 
individual partitions. The returned data could be retrieved by the 
Device API implementation and passed to the add-on. (The data could 
have the same format as those passed to partition_session().)

In case the session is currently not partitioned with the same system 
it is going to be partitioned, the partition module would return 
default parameters.

> > 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

Mmh, that also means, that there can't be passed any information at all 
from the module to the GUI add-on. Maybe the partition module wants to 
examine whether the device has certain properties and give that 
information to the GUI add-on to make use of it, e.g. by simply 
displaying it, or maybe these information have effect on the possible 
partition layouts.

> > 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

I think of information that concern the partition system, but not 
individual partitions. E.g. if the partitioning system stores a header, 
that contains information like its version, flags and maybe a name for 
the session. These global data don't belong to any partition, but they 
should probably be transferred to the GUI add-on.

> 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

Sounds good so far. At least I can't see any general problems. Right 
now I can't even see points, where the userland API would need to be 
adjusted. The fact that in the end a volume -- whatever strange 
combination of RAID and distributed partitions it may be -- will always 
end up as a device to be addressed like any contiguous storage makes 
that concept integrate very well. There certainly needs to be a 
preferences application to set up those volumes, but it can either 
communicate with the kernel (volume manager) via an interface to be 
added, or via settings files or both.

> 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 :-).

Mmh, as I understand you, your concern is the perhaps long time it 
takes to load the file systems to check a partition. The kernel could 
of course load all file systems once and keep them loaded, while all 
partitions are checked. The other solution would be,... er,... to re-
introduce (or rather not drop) the FS disc_scanner modules. :-P They 
should load very quickly and it wouldn't even hurt memory-wise to keep 
them loaded all the time.

CU, Ingo

Other related posts: