FreeLists / openbeosstorage / [openbeosstorage] Re: session module

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"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.