Re: session module

On 2003-02-19 at 07:10:52 [-0800], Ingo Weinhold wrote:
> 
> > 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?

Understood. I think Axel's later suggestion made sense.

> 
> > > > 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.
> 

Well, I'd say that's another good reason to move things into the 
kernel, as it could greatly speed up CD recognition.

-Tyler