[openbeosstorage] Re: session module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 15:32:45 +0100 CET
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> 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.
I do that too, if it helps ;-)
[C++ only API]
> I don't have a problem with that either. On the other hand (or in
> conjunction), if the disk=5Fscanner 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=3F 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 would be fine with a C++ only API. And no, there is no resource
tracking of modules, so you can safely allocate memory within those,
unload them, and the buffer is still valid - no bets accepted anymore,
now :-))
> > 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.
Oh yeah, I like that, too! :-)
Perhaps we can even have registrar (=3F) add-ons that take over the job
of cddblinkd :-)
But of course, we could just let it run as a separate server as well
(now without polling, since the new API allows for notifications :-)
We could even integrate cddafs and cddblinkd databases, so that the
audio CD doesn't even have to be mounted to get recognized and its
names updated :-)
We could ask Marco if he would release the source to his cdda-fs.
> 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.
That sounds very reasonable! Then it's a matter of priorities which
partition module gets there, first.
Although in the case of iso9660 vs. HFS, normally HFS should be
preferred, because it allows for more information to be stored (like
file types, long file names etc.).
Adios...
Axel.
Other related posts:
