FreeLists / openbeosstorage / [openbeosstorage] Re: API Extensions

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > You wrote, that it would be nice to retrieve the final device name 
> > (representing the partition I suppose). And what I wanted to know 
> > is, 
> > what the input for that function should be. A FD for the partition 
> > device would be sufficient, as one can get a partition=5Finfo via 
> > B=5FGET=5FPARTITION=5FINFO and construct the path from the one for 
> > the 
> > `raw' 
> > device and the session+partition identifiers. A partition=5Finfo is 
> > obviously sufficient, too.
> > Or were you simply pointing out the fact, that it is inconvenient 
> > or 
> > simply a lack of abstraction provided by the system, that one has 
> > to 
> > construct the partition device path from the `raw' device name and 
> > the 
> > identifiers manually, and that there should be a function to do 
> > that=3F
> 
> Good question, actually... I am not sure what to answer. I think it 
> would be nice to have a call to get the underlying device, without 
> having to construct it manually.

That way around it is possible. One can use B_GET_PARTITION_INFO to get 
the `raw' device for a partition device.

> That call could even fail if it is a volume that spans over several 
> real devices, and therefore can't provide the level deeper (of 
> course, 
> there is always one "raw" device, but that might be a combination of 
> other raw devices, too).

Mmh, `raw' device is `raw' device. If it is composed of several 
partitions/devices nobody knows but the driver providing that feature 
(or the devfs, if it is built in). I feel, one should be happy with 
being able to get the `raw' device for a partition. :-P

> And then, I don't remember what was the background for that thread 
> anyway ;-))

Er, me neither. I have to admit, I haven't known from the beginning. ;-
)

> [...]
> > > Yeah, might be right, but file systems could inspect the intel 
> > > partition code field for their own use (even if the partition add
> > > -
> > > on 
> > > couldn't find a nice string for it).
> > Why should a FS be interested in that field=3F As it doesn't even 
> > exist 
> > for other partitioning systems, a FS can't (must not) rely on this 
> > value.
> 
> Right, it could use it as a extra validity check in combination with 
> the partitioning type. Anyway, I don't remember right now if we 
> decided 
> to drop that field, I am fine with everything ;-))

I gave up. :-) It's still there but uint32 now.

> [...]
> > > BTW NT has one fs recognizer to not have to load all file systems 
> > > when 
> > > sniffing for the correct fs. I am not sure we should have 
> > > something 
> > > like this, and if, then only as a fall back (actually meaning the 
> > > opposite :-).
> > Mmh, as I understand you, your concern is the perhaps long time it 
> > takes to load the file systems to check a partition. The kernel 
> > could 
> > of course load all file systems once and keep them loaded, while 
> > all 
> > partitions are checked. The other solution would be,... er,... to 
> > re-
> > introduce (or rather not drop) the FS disc=5Fscanner modules. :-P 
> > They 
> > should load very quickly and it wouldn't even hurt memory-wise to 
> > keep 
> > them loaded all the time.
> 
> Since the kernel add-ons (and all other executables) are loaded using 
> memory mapped files, also file systems won't take much space in 
> memory; 
> only the parts needed are loaded, so it doesn't make a big 
> difference.

Cool. :-))

> The difference would be that there are many file systems, but only 
> some 
> of them are real ones (i.e. with a mass storage backing), we also 
> have 
> pipefs, networking fs, etc. - all those wouldn't have to be called at 
> all.
> But, of course, they don't have to implement the identify() hook, and 
> the kernel could remember the file systems that implement the hook, 
> and 
> keep only those loaded.

Yep.

> Of course, we could also just not drop the fs disk scanner add-ons, 
> but 
> for some file systems, there is much functionality needed to read out 
> the volume name - something which is very easy to do for the file 
> system itself, so we shouldn't drop the idea of adding an identify() 
> hook at all.

Yes, let's see how things work out in practice.

CU, Ingo