[Top][All Lists]

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

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

From: Edd Barrett
Subject: Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD
Date: Sun, 16 Dec 2018 17:32:32 +0000
User-agent: Mutt/1.11.1 (2018-12-01)

On Sun, Dec 16, 2018 at 11:36:40AM +0100, Thomas Schmitt wrote:
> Hi,
> the commit history in libcdio/commits/openbsd_fixes_to_master_for_merge
> looks good to me, as far as i can judge without testing on OpenBSD and
> NetBSD.
> A last bug fix about CDIOREADMSADDR in get_last_session_netbsd() seems
> still necessary (i proposed to initialize "int addr" to 0).

Indeed this seems to help. Instead of the error message, we have:

Last CD Session LSN: 0

I tested on OpenBSD and NetBSD.

(The only outstanding quirk remaining is now a message we have
preivoulsy discussed: "SCIOCCOMMAND cmd 0xad sts 3" in cd-info on
OpenBSD only. I'd like to merge what we have before I look at this. It's
not fatal.)

WRT the review, is it possible you looked at the wrong branch? I linked
a new branch in my last email which squashes away some of the commits
that (as you pointed out) didn't make a great deal of sense any more.

This is the branch I think we can now merge:

I squashed your get_disc_last_lsn_netbsd() fix into:

NetBSD/OpenBSD: Merge in-tree driver with the local patch in OpenBSD ports.

And here's the github PR for paranoia:

Here's some responses to the comments that still apply:

> - 8207ace8914c418dea9d626d7839bec0f7202fab
>   "Make work on OpenBSD."
>   (OK)
>   On how many operating systems was this this tested ?
>   I ran it on Debian "oldstable" without noticing problems.

I only tested on OpenBSD and NetBSD. As far as I know, no other
operating system reads these environment variables aside from OpenBSD.

> - 0897e98ba338fa1223a4b7ff786bf517362ff34b
>   "Improve NetBSD device enumeration and make it work on OpenBSD."
>   (OK)
>   The new drive enumeration by /dev/rcd%d%c matches in principle the one
>   in libburn/sg-netbsd.c. libburn uses {'d', 'c'} for "%c" instead of
>   'a'+RAW_PART..
>   (Advise is welcome about how bad this hardcoding in libburn might be.)

Up to you, but I prefer to use the macro. In the unlikely event the raw
partition changes, no code changes would be required.


Best Regards
Edd Barrett

reply via email to

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