libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD
Date: Tue, 30 Oct 2018 23:46:29 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]