[openbeosstorage] Re: session module
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 18 Feb 2003 20:59:55 CET (+0100)
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> [...]
> > For the partition module there is a narrow line between being too
> > tolerant -- and mistakenly recognize a partition map -- and being
> > too
> > strict -- making the users life hard, when a partition descriptor
> > is
> > not valid. Originally the module was very lax. Then, after your
> > discovery, I made it fail whenever there was a problem in any of
> > the
> > partition table sectors. This was too strict, as it turned out. I
> > relaxed the rules a bit, but maybe that's not enough.
>
> It all depends on how important the invalid data is - if it's a
> missing
> active bit, or the wrong type, then everything should be mounted
> nevertheless, but when the partition size is zero or something like
> this, we probably shouldn't try to mount it :-))
That's for sure. :-)
Anyway, the actual problem occurs on a lower level. E.g. the R5 CD has
a correct partition table sector signature on one of the sessions, and
originally the intel partition module considered that a sufficient
hint, that it is responsible in this case. Therefore the disk_scanner
module had to assume, that the session was indeed partitioned according
to that scheme, although in fact the session directly contained a file
system.
Thus the question is, what the partition module shall check, before
agreeing that it is responsible. Currently there must be no error at
all in the primary partition table (the active flag isn't checked
though -- I wouldn't even know what to check); if an extended partition
table sector could be read successfully and has the correct signature,
it must not contain errors either; furthermore no partitions must
overlap and the partition table sectors must not lie within non-
extended partitions, and some other things. If any of that checks fails
the module rejects the session.
This is, as I said, relatively strict and could certainly be relaxed a
bit. But some of these checks ensure properties, that sessions not
having them would cause me some head ache how to deal with them (e.g.
overlapping partitions, or if an inner partition belongs to more than
one primary extended partition).
> Another thing: when you repartition a disk with Windows, the order of
> partition entries doesn't match the physical order - I guess we
> should
> always use the order of the partition entries, right=3F
Yes, I think so.
> (but of course,
> this could be inconvenient for the user as well)
Well, by allowing The Evil OS (tm) to infiltrate their hard disk the
user manoeuvered themselves into that inconvenience, I would say. ;-)
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?
> BTW Windows 2000 doesn't boot if it's partition entry is not the
> first,
> great, isn't it=3F
The empire strikes back. ;-)
BTW, I think Windows XP doesn't required that anymore.
[...]
> > 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=5Fscanner 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? I thought I just said, that this would be an argument *for*
moving everything into the kernel.
> 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=3F
Mmh, seems so. :-P
Maybe, my sentence about getting rid of the disk_scanner 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.
> [...]
> > The `Device format error' occurs when the disk=5Fscanner module
> > tries
> > to
> > load the first block of the audio session. To provide the
> > possibility
> > for a cdda file system, I would like to call the FS module hooks
> > nevertheless. Maybe with an optional flag. In case we'll get rid of
> > the
> > FS modules, the FS add-on hook must be able to deal with that.
>
> In any way, I think it should check for audio sessions, and just not
> read from those, i.e. don't return an error when there is none!
That's what I was trying to say. I wouldn't read from the session, but
I would nevertheless want to call the FS hooks, since otherwise a cdda
FS wouldn't get a chance to recognize it.
> > The offset of session 1 is obviously nonsense, but session 0 is
> > located
> > at the same offset as our session 1 (just in blocks), but it shows
> > an
> > Apple style partitioning, while we recognize an ISO9660 FS. I'm
> > sure
> > both is correct. I wonder, how to deal with such a case.
>
> 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=3F
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.
CU, Ingo
Other related posts:
