[openbeosstorage] Re: session module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 20 Feb 2003 16:01:48 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[partition order]
> Anyway, at least under BeOS (and the OS that must not yet be named
> publicly) there shouldn't be any problem. Or do I overlook something=3F
Only that the device names will change due to such a change. So it
might be nice for users to be able to specify mount settings via volume
name as well, something like:
volume System /dev/disk/.../master/0=5F1 {
read=5Fonly true
}
And the system would only apply the settings when either both of the
constraints are true, or something like this=3F
> > BTW Windows 2000 doesn't boot if it's partition entry is not the
> > first,
> > great, isn't it=3D3F
> The empire strikes back. ;-)
> BTW, I think Windows XP doesn't required that anymore.
That's possible, they made the partition stuff a lot less transparent
in XP by adding yet another proprietary layer to it.
> > > BTW, this would be a reason to move the DiskDevice stuff from the
> > > registrar into the kernel. It could also keep a pointer the
> > > module,
> > > avoiding even the module loading/unloading completely. And we
> > > could
> > > completely get rid of the current (libroot) disk=3D5Fscanner API
> > > functions,
> > > which I don't find very nice anyway.
> > Well, that would defeat the original idea of moving that stuff *
> > into*
> > the kernel, making it independent from userland, and be able to
> > provide the partition entries on the fly.
> Does it=3F I thought I just said, that this would be an argument *for*
> moving everything into the kernel.
Er.... actually I misread you, sorry :-))
> > I would rather maintain a list of
> > sessions in the kernel as well, to reduce the amount of reloads.
>
> Yes, when moving what I added to the registrar into the kernel, then
> there would be the whole live device list with all sessions and
> partitions.
>
> > Or haven't I understood you correctly=3D3F
> Mmh, seems so. :-P
Indeed :)
> Maybe, my sentence about getting rid of the disk=5Fscanner functions in
> libroot (<kernel/diskscanner.h>) was a bit ambiguous. The DiskDevice
> API would, of course, still need some interface to get the data from
> the kernel, but I would rather like to provide private functions,
> that
> suit its needs better.
>
> That would disable C-only apps to access that functionality, but
> personally I wouldn't have a problem with that.
So do I.
> > Good questions, but I think this is the place where our module
> > priorities come into play again. Perhaps the apple style
> > partitioning
> > is only a virtual one which is there when there is a HFS disk=3D3F
>
> I'm afraid, I didn't get that. :-/
>
> The only way out I see for this situation, was to try to let the file
> system modules recognize the session (i.e. virtual partition), even,
> if
> a partition module identified it positively. The result would then
> be
> a session with some partitions the partition module found plus a
> virtual partition spanning the whole session. Don't know, if that is
> such a good idea.
No no, I think that's not a good idea, I was still on the wrong path
when writing the above paragraph :)
There should only be the real partitions and the raw device, no virtual
partitions spanning the whole session when there is none.
Adios...
Axel.
Other related posts:
