[openbeosstorage] Re: API Extensions

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> 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.
Also, the file system's initialize() function will need to have this 
device name, so it probably makes more sense this way, anway.

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

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

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

> PS: After neglecting the OpenBeOS project a bit over the last weeks, 
> I 
> plan to get more involve again. Starting this this week (on the 
> weekend 
> at the latest). I will roll in the discussed changes and will have a 
> closer look on what is still missing for the implementation of the C+
> + 
> API. If you've ideas for larger changes, please don't hesitate to 
> utter 
> them. :-)

Nice, although it's not been such a long time to legitimate a "welcome 
back" :-)
Anyway, take your time, you've already done more than most others (even 
on this list ;-P).

Adios...
   Axel.

Other related posts: