[openbeosstorage] Re: API Extensions
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 16 Feb 2003 01:33:34 CET (+0100)
> "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
Other related posts:
