Hi, > Hi libcdio developers!
... and interested neighbors ... > I'm an OpenBSD developer That's a bit exotic. Did you already try to contact Robert Kausch by the mail address at his copyright notice in lib/driver/netbsd.c ? He seems to have been the last OpenBSD user who worked on libcdio: commit e8a00707109fd7e5bd4d2613a2fd5e2db6629f8f Author: R. Bernstein <[email protected]> Date: Wed Jun 4 14:14:33 2014 -0400 From Robert Kausch: configure recognizes OpenBSD (via the NetBSD driver) which Robert says he has tested > 1) The device detection logic is broken. > [...] I've patched it > locally with code which simply finds devices by opening /dev/rcd[0-9]c. > That would probably work on netbsd too. libburn's adapter sg-netbsd.c enumerates /dev/rcd%d%c with d={0 to 63}, c={'d', 'c'} It was tested with OpenBSD in 2016 by SASANO Takayoshi. See https://dev.lovelyhq.com/libburnia/libburn/raw/master/libburn/sg-netbsd.c (The NetBSD tests were made by Freddy Fisker in 2014.) > 2) Error and warning handling in netbsd.c seems wrong. [...] > When the empty /dev/rcd0c is queried, the ioctl returns an error, and > cdio_error() exits. Ouch. The use of cdio_error() in lib/driver/netbsd.c seems to be mislead. MSWindows is the only other libcdio system driver which uses it: ./lib/driver/MSWindows/aspi32.c: cdio_error( "out of memory" ); ./lib/driver/MSWindows/win32.c: cdio_error ("init called more than once"); The netbsd.c uses are cdio_error("unknown access type: %s ignored.", value); cdio_error("error in ioctl(CDIOREADTOCHEADER): %s\n", cdio_error("error in ioctl(CDROMREADTOCENTRIES): %s\n", cdio_error("ioctl(fd, CDIOCALLOW) failed: %s\n", cdio_error("ioctl(CDIOCEJECT) failed: %s\n", None of them look as fatal as the MSWindows error messages. > should all of the cdio_error()s be at least cdio_warn()s? lib/driver/gnu_linux.c does it that way. For example: read_toc_linux (void *p_user_data) ... if ( ioctl(p_env->gen.fd, CDROMREADTOCHDR, &p_env->tochdr) == -1 ) { cdio_warn("%s: %s\n", "error in ioctl CDROMREADTOCHDR", strerror(errno)); return false; } > The `return false` even suggests that the author > of this code was expecting cdio_error() to return. One reason more to downgrade the error severity. Of course it would be neat to provoke and test all five occasions whether the callers react properly. But maybe it suffices to check whether the respective functions in gnu_linux.c already show a behavior similar to the new behavior of netbsd.c. Have a nice day :) Thomas
