Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD

[Greg Troxel]

(I'm a big paged out today and not really keeping up, but wanted to
comment quickly since I was asked.)

"Thomas Schmitt" <address@hidden> writes:

> Edd Barrett wrote:
>> Is it important, though, to offer up both addressing modes for consumers
>> of libcdio? Or is it not exposed that way?
>> Put differently, if the underlying OS supports both addressing modes,
>> should we implement both callbacks in the driver.
>
> The libcdio API has functions for LBA addressing and for MSF addressing.
>
> On operating system level, only one of both address modes would need to
> be supported, because the implementation of libcdio seems to expect
> this and uses the supported format with subsequent conversion to the
> desired format. See in track.c cdio_get_track_lba(), cdio_get_track_msf().
>   
> I.e in
>   static cdio_funcs_t _funcs
> at least one of
>   .get_track_lba
>   .get_track_msf
> must be non-NULL. Not much benefit seems gained if both are non-NULL.
>
> Important is that the functions of the netbsd.c driver know which format
> they get from their interface to the operating system, _cdio_read_toc(). 
> The netbsd.c driver assumes that MSF is delivered.
> But the OpenBSD driver from which you take code obviously assumes that
> LBA adresses are delivered.
>
> You need to unify this. My proposal is to let _cdio_read_toc() deliver MSF
> on both systems. If OpenBSD cannot deliver MSF to _cdio_read_toc(), then
> let it deliver LBA and convert the result to MSF. (See mail of yesterday.)
>
> If you decide to keep get_track_lba_netbsd(), then you need to adapt it
> to _cdio_read_toc() delivering MSF.

This all sounds sensible to me.  Definitely the code needs to keep track
of which is which especially with unions.

Going out on a limb maybe more than I should, it seems like the CD world
prefers MSF as the main thing, so trying to be in that format as much as
possible seems good.  If so having OpenBSD-specific code to use LBA if
that's needed and get back to MSF as fast as possible seems like it will
cause the least confusion long term.

> (I still doubt that OpenBSD cannot deliver MSF. In the end it is about
>  a field in SCSI command READ TOC/PMA/ATIP. But exploring this is a new
>  adventure which we can easily avoid by result conversion.)

Agreed on both counts, and I have zero  clue about the actual details.