Re: First C Device API Draft

> > In the case of get_nth_partition_info() and get_partition_module() 
> > the
> > fields `index' (the documentation says the `session' field of the
> > partition_info is required, but I think that's a lie) and `flags' 
> > were
> > not needed. Currently it looks like one would request a 
> > session_info
> > before anyway, though. So I tend to agree with your suggestion. The
> > same holds for the partition module functions.
> 
> That's the main thing: it seems like you'll just have a session_info 
> lying around ready to be used anyway.

Done.

> > 2) Regarding the get_{partition,session}_module() functions of the
> > partscan module: I intended them as a way (for the kernel) to 
> > bypass
> > the other functions, which each time must iterate through the list 
> > of
> > session/partition modules to find the one responsible. Maybe it is
> > better to add remove the get_*_module() functions and add a 
> > parameter
> > to the other ones, used to return the module's name (first call) 
> > and
> > pass it to the function (subsequent calls).
> 
> Not decided yet... :)

I was almost starting to implement it, when I started wondering whether 
it would be better to return/pass a pointer to the module itself, not 
just the name. This would even save the overhead for loading/unloading 
the module each time. Then the caller would be responsible for calling 
put_module() (unless a NULL module_info** had been supplied or the 
returned pointer was NULL). How does that sound?

> > 3) Regarding the extended_partition_info structure: (the comments 
> > in
> > PartScanTest.cpp are swapped)
> > a) get_nth_partition_info() doesn't fill in the `device' field in 
> > the
> > partition_info structure. It could get it via the 
> > B_GET_PARTITION_INFO
> > ioctl(). Is it maybe better not to use partition_info, but rather 
> > to
> > include only the other of its fields? The caller passed a FD to the
> > device and certainly also has a path name. The field is shorter 
> > than 
> > it should be for a path name anyway.
> 
> Well, they had a path name at one time, but I could see that it might 
> be handy to be able to get that info back. Is it that costly to do 
> the 
> ioctl() that it would matter?

I'm not longer sure, whether it is possible at all. 
B_GET_PARTITION_INFO has to be called on the partition device, not on 
the raw device, and I wouldn't know how to get hold of it (it's in the 
same dir as the raw device, but that doesn't really help...).

> And separately, are we at liberty to muck 
> around with struct sizes here?

Not with partition_info, but with extended_partition_info.

> > b) get_nth_partition_info() doesn't fill in the `mounted_at' field 
> > in
> > the partition_info. Currently I don't even know how to get it. 
> > Maybe
> > omit it?
> 
> Couldn't we eventually get it rather easily once we have our own 
> kernel? Seems like another "could be handy" kind of field to me. I'd 
> rather leave it in.

OK. But then we should find a way to fill it in for the time being, 
since one would certainly like to use it in implementation of the C++ 
API.

CU, Ingo