[openbeosstorage] Re: session module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 18 Feb 2003 17:58:54 +0100 CET
"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 :-))
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 (but of course,
this could be inconvenient for the user as well)
BTW Windows 2000 doesn't boot if it's partition entry is not the first,
great, isn't it=3F
> Since get=5Fnth=5Fpartition=5Finfo() only gets the session index, for each
> call the session has to be found first. If a session=5Finfo would be
> provided, the disk=5Fscanner could work with that, but I don't feel
> very
> comfortable with passing such an info to the kernel without checking
> it.
Indeed.
> 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. I would rather maintain a list of
sessions in the kernel as well, to reduce the amount of reloads. Or
haven't I understood you correctly=3F
[...]
> 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!
> 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
> Even more things to discover: Our implementation implicitly assumes,
> that the (logical) block size of the device is also that of the
> session
> and the partitions. Shall the session and the partition modules
> return
> their block size=3F I mean, there is a field in both of the structures,
> so that wouldn't be a problem.
>
> Shall the block size in the extended=5Fpartition=5Fmodule then be the one
> from the partition module or from the FS module=3F Or shall another
> field
> for the latter one be added=3F
Dunno...
Adios...
Axel.
Other related posts:
