Re: API Extensions

On Wed, 8 Jan 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote:

> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > > > > Why not have both=3F If you're using the device API, getting
> > > > ...
> > > Well, I guess I'm thinking of Axel's version as more of a POSIX-ish
> > > type interface, and then your version as device API interface. If
> > > we
> > > had to go with one, I'd vote for the latter.
> > Fine, then I would say, I'll add it, and we can also add Axel's
> > version
> > to unistd.h as soon as our kernel is ready for it. Apropos, Axel,
>
> 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?

> Also, the file system's initialize() function will need to have this
> device name, so it probably makes more sense this way, anway.

That's a very good argument!

> > what's the current status of the kernel=3F I haven't missed, that it
> > can
> > now boot from HD now, have I=3F (I guess, that would have been worth a
> > news item. :-) BTW, I just come to think, that it doesn't make much
> > sense to build the disk=5Fscanner as R5KernelAddon, as we couldn't make
> > use of them in the R5 kernel anyway.
>
> 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.

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

> We could of course write a device driver which exports their
> functionality for R5, but since you already implemented the testing
> stuff, we won't need this at all.

Right.

> > > Maybe we should just make it a string then, and let the partition
> > > module convert the codes to appropriate string, if it can.
> > Actually that's already happing (cf. `partition=5Ftype'). My motivation
> > to add `partition=5Fcode' was, that, in a case where the partition
> > module
>
> 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.

> > doesn't know the code and sets the type to something like `unkown',
> > the
> > information is not lost. In fact the only application/add-on I can
> > imagine using the code field is the userland add-on for editing the
> > parameters for partitioning. But such an add-on would probably also
> > need other (partition system specific) information, that the
> > extended=5Fpartition=5Finfo doesn't provide. So maybe it's a better idea
> > to
> > get rid of `partition=5Fcode' and provide a mechanism for the userland
> > add-ons -- also the ones for the file systems -- to get information
> > from the respective module/FS add-on.
>
> Of course, this would also make sense. The user space add-on to setup a
> partition (visually) probably needs to know certain partition specific
> information.
> How about having a basic partition info structure which adds
> implementation specific fields at the end of it=3F
> I.e. something like:
> struct partition=5Finfo {
> 	off=5Ft offset;
> 	off=5Ft length;
> 	char *type=5Fstring;
> };
> struct intel=5Fpartition=5Finfo {
> 	struct partition=5Finfo info;
> 	uchar type;
> 	...
> };
>
> status=5Ft get=5Fpartition=5Finfo(..., partition=5Finfo *info, size=5Ft *
> sizeOfInfoStruct);

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.
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.
The third problem arises with unpartitioned disks: There are no partitions
you could get an info for.
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'.

CU, Ingo