Subject: Re: cd(4) and xmcd
To: Peter Seebach <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 02/15/2000 16:14:10
On Tue, 15 Feb 2000, Peter Seebach wrote:
# When a CD-ROM is changed in a drive controlled by the cd driver,
# then the act of changing the media will invalidate the disklabel
# and information held within the kernel. To stop corruption...
...excuse me. Hello? CD-ROM? ...ROM? as in READ-ONLY MEMORY?
# accesses to the device will be discarded until there are no more
# open file descriptors referencing the device.
This is broken. Why doesn't the access return EBADF instead of being
"discarded" (i.e. CLOSE the damn descriptors)? And if it's bound to the
device, why does it not just flush the data cache associated therewith, if
applicable (which I don't think it is, but hey...)?
# During this
# period, all new open attempts will be rejected. When no more
# open file descriptors reference the device, the first next open
# will load a new set of parameters (including disklabel) for the
# Does this explain why xmcd stays permanently convinced that there's no disk
# in my drive after a change, until I quit it and restart?
I believe it does. Mine does this too, at least for ATAPI under i386
(Haven't tried with -current/SPARC yet). I don't know if it does this
with SCSI drives as well or not -- anyone care to volunteer?
If this is the case, maybe we should work out a patch to force a reopen
of the fd when the ioctl/read returns EBADF (if it does)?
NetBSD: The power to Connect