[openbeosstorage] Re: session module
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 16:10:52 CET (+0100)
> On 2003-02-18 at 11:59:55 [-0800], Ingo Weinhold wrote:
> >
> > > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > 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.
Sure, but a bad partition table may specify that too partitions span
overlapping areas. That's what I mean. The partition module rejecting
the session, as done now, is a very simple solution, but, if one
doesn't do that, one has to decide, what to present to the user. Both
partitions? One? None?
> > > 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 :-)
:-)
I think such a cookie would be fine in the kernel, but I would
definitely not pass it to the userland. If only the kernel caused
accesses to the disk_scanner modules, when updating its live list, then
that will work. In this case the userland would get a copy of the
kernel's list instead of causing module access itself.
[...]
> > 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.
Yes.
[...]
> > 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.
Yes, I think, that's how it works.
> 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.
Yep, perhaps we should leave it like that.
CU, Ingo
Other related posts:
