[openbeosstorage] Re: session module
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 00:30:40 -0800
On 2003-02-18 at 11:59:55 [-0800], Ingo Weinhold wrote:
>
> > "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).
I don't think real sessions will ever actually overlap; I believe they
just refer to data outside their own session using absolute disc
addresses.
> > 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.
I don't have a problem with that either. On the other hand (or in
conjunction), if the disk_scanner session function could return a
cookie the first time it was called, the CD table of contents would
only need to be read once (though do the modules need to be guaranteed
to not be unloaded for that to work safely, if the module is allocating
the cookie's memory? I'm thinking it doesn't matter, but I'm not quite
confident enough in my guess to that I would bet large sums of money on
it :-)
>
> > [...]
> > > 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.
>
Yes! (I think I've mentioned I really like BeOS' cdda file system :-)
Incidentally, most of the work a cdda file system would need to do is
already handeled by the session module, I believe. When it comes time
to do a such a file system, the code of interest can be pulled out and
shared fairly easily if so desired.
> > > 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.
I haven't checked yet, but it's possible that the Mac partition
information is stored in the first 16 blocks of the ISO file system (as
you may recall from that lovely iso9660 standard, those blocks are
reserved for "system use", and are usually just zeros; plus the first
address listed for the Mac partition was block 1). In that case, the
Mac partition would be recognized first (given a proper Mac partition
module), and subsequently the HFS file system would get recognized
(wherever it's hidden). Otherwise the ISO file system just gets
recognized. That seems like a resonable expected behavior to me. I'm
not sure I like the idea of letting both partition modules and file
system modules have an equal go at the session data; letting the
partition modules have the first crack at it like we currently do seems
better.
-Tyler
Other related posts:
