[openbeosstorage] Re: API Extensions

> On 2003-01-06 at 14:35:14 [-0800], openbeosstorage@xxxxxxxxxxxxx 
> wrote:
> > 
> > > > > > And the user functions:
> > > > > > status=5Ft partition=5Fsession(int deviceFD, int32
> > > > > > sessionIndex,
> > > > > > const
> > > > > > char
> > > > > > *identifier, uint32 version, void *parameters, size=5Ft
> > > > > > paramLen);
> > > > > > status=5Ft initialize=5Fpartition(int deviceFD, int32
> > > > > > sessionIndex,
> > > > > > int32
> > > > > > partitionIndex, const char *identifier, uint32 version, 
> > > > > > char *
> > > > > > volumeName, void *parameters, size=5Ft paramLen);
> > > > > 
> > > > > I would replace the second with:
> > > > > status=5Ft initialize=5Fvolume(const char *where, const char 
> > > > > *
> > > > > fileSystem,
> > > > > const char *volumeName, const char *parameters);
> > > > > 
> > > > > Or something similar, probably in unistd.h (accompanying
> > > > > mount()).
> > > > 
> > > > Mmh, I could live with that, though it doesn't fit with the 
> > > > rest 
> > > > of
> > > > the
> > > > functions.
> > > 
> > > Why not have both? If you're using the device API, getting
> > > session_info's and partition_info's and what not, you're going to 
> > > be
> > > really annoyed if you have to convert that info to a path name to
> > > initialize the partition; thus you want Ingo's version. But if 
> > > you
> > > just
> > > feel like initializing a volume for whatever reason, Axel's 
> > > version
> > > would be nicer (and would probably make sense living in 
> > > unistd.h).
> > 
> > That's fine as a compromise. Though, one might object, that it 
> > isn't a
> > good idea to have different APIs (at the same abstraction level) 
> > that
> > do the same thing.
> 
> 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, 
what's the current status of the kernel? I haven't missed, that it can 
now boot from HD now, have I? (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_scanner as R5KernelAddon, as we couldn't make 
use of them in the R5 kernel anyway.

> > I don't really get the point, I'm afraid. The Intel/DOS/IBM/
> > whatever
> > partition layout specs are what they are, i.e. simply non-existent. 
> > ;-)
> > But nevertheless one has no way to get around them. :-P So we can't
> > just modify them, without risking, that other tools and operating
> > systems will break.
> 
> I guess I was thinking in terms of whether or not someone might try 
> to 
> hack an extension into the specs (or lack thereof :) sometime, a la 
> FAT 
> -> FAT32.

Well, before this someone isn't also able to hack the BIOS, he won't 
have much fun with his new partition system. ;-)

> > The reason for proposing a uint32 was merely to be
> > prepared for other partitioning styles. 
> 
> Understood.
> 
> > I don't know about what it
> > looks like on PPC. In the worst case it is even a string. Anyway,
> > `partition_code' is merely a read-only field of informational
> > (entertainment? ;-) use. 
> 
> 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_type'). My motivation 
to add `partition_code' was, that, in a case where the partition module 
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_partition_info doesn't provide. So maybe it's a better idea to 
get rid of `partition_code' 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.

I think of something like:

status_t get_partitioning_parameters(int deviceFD, int32 sessionIndex, 
const char *pmIdentifier, char *buffer, size_t bufferSize, size_t *
actualSize);
status_t get_fs_initialization_parameters(int deviceFD, int32 
sessionIndex, int32 partitionIndex, const char *fsIdentifier, char *
buffer, size_t bufferSize, size_t *actualSize);

The functions would propagate the request to the partition kernel 
module/FS add-on, which in turn fills the buffer with the parameters 
currently active for the session/partition, or, if not recognized, with 
the default parameters.

Of course, the userland add-ons wouldn't need to retrieve these data, 
but they would simply be passed to the parameter editor on construction
/initialization.

CU, Ingo

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

Other related posts: