[openbeosstorage] Re: session module

> On 2003-02-17 at 15:14:16 [-0800], Ingo Weinhold wrote:
[...]
> > BTW, this would be a reason to move the DiskDevice stuff from the
> > registrar into the kernel. It could also keep a pointer the module,
> > avoiding even the module loading/unloading completely. And we could
> > completely get rid of the current (libroot) disk_scanner API 
> > functions,
> > which I don't find very nice anyway.
> 
> I have to admit, I'm not sure I see much use in keeping it all in 
> userland. Basically no one but the registrar will use the libroot 
> functions otherwise, so why bother with the overhead imposed by 
> keeping 
> them out of the kernel?

That's more and more the feeling I have, too. The list of advantages 
for the kernel-only solution keeps growing, while on the registrar side 
only the argument for keeping things out of the kernel, that doesn't 
really need to be there, still stands.

[...]
> > BTW, I ran the test program with my precious Portishead `Roseland 
> > NYC
> > Live' CD, which contains among the great music also a data session.
[...]
> > The `Device format error' occurs when the disk_scanner 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.
> 
> Yes, I see no reason not to do otherwise (I do like BeOS' cdda 
> filesystem :-).
> 
> > Then it seems the flags for session 1 are not set correctly. They
> > should indicate a data session.
> 
> Oops, I'll fix that, thanks.

Already done. I had to, when fixing the error above. :-)

> > But there's more interesting to learn from that data, especially 
> > when
> > comparing it with the info the old Device API returns:
> > 
> > device: /dev/disk/ide/atapi/1/master/0/raw
> >   display name(0, 0): `IDE master bus:1'
> >   display name(0, 1): `IDE master bus:1'
> >   display name(1, 0): `IDE master bus:1'
> >   display name(1, 1): `IDE master bus:1'
> >   session 0 (apple)
> >     offset:  270257
> >     virtual: 0
> >     data:    1
> >     partition 0 (MRKS)
> >       offset:         1
> >       blocks:         2
> >       block size:     512
> >       hidden:         true
> >       partition code: 0x0
> >       partition name: `MRKS'
> >       partition type: `Apple_partition_map'
> >       FS short name:  `'
> >       FS long name:   `'
> >       volume name:    `'
> >       mounted at:     `'
> >     partition 1 (Toast 3.0.2 PPC HFS Optimizer)
> >       offset:         24961
> >       blocks:         190117
> >       block size:     512
> >       hidden:         false
> >       partition code: 0x0
> >       partition name: `Toast 3.0.2 PPC HFS Optimizer'
> >       partition type: `Apple_HFS'
> >       FS short name:  `hfs'
> >       FS long name:   `Mac HFS'
> >       volume name:    `PNYC (MAC)'
> >       mounted at:     `'
> >   session 1 (none)
> >     offset:  2147483647
> >     virtual: 1
> >     data:    1
> >     partition 0 ()
> >       offset:         0
> >       blocks:         271001
> >       block size:     2048
> >       hidden:         false
> >       partition code: 0xff
> >       partition name: `'
> >       partition type: `'
> >       FS short name:  `cdda'
> >       FS long name:   `Audio Filesystem'
> >       volume name:    `Audio CD'
> >       mounted at:     `'
> > 
> > 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.
> 
> See my next email for my take on the matter. :-)

Will do.

> > Even more things to discover: Our implementation implicitly 
> > assumes,
> > that the (logical) block size of the device is also that of the 
> > session
> > and the partitions. Shall the session and the partition modules 
> > return
> > their block size? I mean, there is a field in both of the 
> > structures,
> > so that wouldn't be a problem.
> 
> Hmmm, they could... Are they likely to ever differ, thoguh?

In the example above they do. Session 0 has a block size of 512, while 
1 has 2048.

> > Shall the block size in the extended_partition_module then be the 
> > one
> > from the partition module or from the FS module? Or shall another 
> > field
> > for the latter one be added?
> 
> I'd say fs.

That's what I tend to think too.

CU, Ingo

Other related posts: