Re: API Extensions

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

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

> > > 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. The reason for proposing a uint32 was merely to be 
prepared for other partitioning styles. 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. For partitioning the parameters passed to the 
partition module would contain that kind of information.

CU, Ingo