libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] problems with libcdio on openbsd (and probably netbs


From: Robert Kausch
Subject: Re: [Libcdio-devel] problems with libcdio on openbsd (and probably netbsd too)
Date: Sun, 27 May 2018 14:22:48 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0

Am 27.05.2018 um 11:38 schrieb Thomas Schmitt:
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:
Hi folks, I'm still reading the mailing list.

The device detection code was not in place when I worked on the NetBSD code. It was added in commit 56258f9838563fb9ef74bfb367cd96d8e6cfd366:

    Committer: R. Bernstein <address@hidden>
    Date: 2017-12-21 12:20:17 -0500

    Add NetBSD drive detection; correct drive detection in cd-info.c
    Patches from Onno van der Linden

The problem seems to be the syscall, as Edd already pointed out. You can count my vote on enumerating and trying to open possible device files instead.

Just one note regarding the final letter in device names like /dev/rcd0c:

The letter names the raw partition, the one to open for raw disc access. It's defined as RAW_PART in sys/disklabel.h and should be used like 'a' + RAW_PART to find the correct letter.

RAW_PART is always 2, thus 'c', in OpenBSD, but it's architecture dependent, 2 or 3, in NetBSD [1]. So it would be a good idea to use RAW_PART instead of a fixed 'c' or 'd' when looking for devices.

[1] https://github.com/IIJ-NetBSD/netbsd-src/search?q="%23define+raw_part";

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.
I agree that the errors should be changed to warnings to match the behavior of other drivers.

Cheers,
Robert

----
Robert Kausch
address@hidden




reply via email to

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