[openbeosstorage] Re: API Extensions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 15 Feb 2003 19:08:26 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > ... to retrieve the final device name for what given data=3D3F
> > Well, to some degree, the partition modules set the file name -
> > it's
> > currently {session}=3D5F{partition} in the same path as the examined
> > raw
> > device.
** > Yes. **
> > That name or just the info should or must be in the B=3D5FSET=3D
> > 5FPARTITION
> > equivalent to devfs. That way it either knows the correct name or
> > it
> > asks for it using the session and partition identifiers "against"
> > the
> > raw device.
** > Yes. **
> > Have I understood you correctly=3D3F
> Er, probably not. :-)
Hehe :-)))
> 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 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).
And then, I don't remember what was the background for that thread
anyway ;-))
> > Not ideal, that's right, but working well enough. Although VMware
> > is
> > supposed to be much faster :-)
> Uh, speed. Won't OBOS be so fast, that one won't notice the
> difference
> between it running in Bochs and BeOS R5 running natively=3F ;-)
> If not, what are you kernel guys doing, eh=3F ;-)
Erm.... (looking at the floor, ashamed) ;-))
[...]
> > 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 ;-))
[...]
> > 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.
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.
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.
Adios...
Axel.
Other related posts:
