Re: session module

> On 2003-02-18 at 11:59:55 [-0800], Ingo Weinhold wrote:
> > 
> > > "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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