[openbeosstorage] Re: API Extensions
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 06 Jan 2003 16:10:28 -0800
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.
> > > Perhaps it's also better to drop that `version' stuff. I thought,
> > > it
> > > could help to deal better with situations when different versions
> > > of a
> > > FS exist, but probably that's a bit too esoteric.
> >
> > Perhaps set things up so the latest version is used unless specified
> > (does C allow for default parameters? I can't remember...)?
>
> Sadly C doesn't know default parameters. And, if the versions really
> matter, one would simply set up two differently named modules/FS add-
> ons (cf. bfs vs. ofs) -- with priorities one can gracefully deal with
> such a situation. Therefore it is not really necessary to explicitly
> reflect versions stuff in the API.
Sounds reasonable to me. :)
> > > > OTOH we can use this information to display names for partitions
> > > > with
> > > > unknown or initialized file systems - so that Tracker displays
> > > > "Be
> > > > volume" or "QNX volume" if the recognizes a BFS/QNX partition
> > > > but
> > > > it
> > > > cannot read the file system for whatever reason.
> > >
> > > The extended_partition_info features both the type code
> > > (`partition_code') and a human readable interpretation
> > > (`partition_type'). partition_code is uint8 currently -- maybe it
> > > should be resized to uint32.
> >
> > Do you know offhand if anyone else has done this yet (and would the
> > intel partition specs allow the expansion to happen gracefully?).
> > IIRC,
> > there are very few type codes in the 8-bit range that haven't been
> > used, so it seems like something will have to be done one of these
> > days.
>
> 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.
> 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.
-Tyler
Other related posts:
