Hi, 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. (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.) Have a nice day :) Thomas
