devfs
[Top] [All Lists]

Re: devfs/cdrom problem

To: Gary Shea <shea@xxxxxxxxxxxxx>
Subject: Re: devfs/cdrom problem
From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2001 16:59:19 -0700
Cc: devfs@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.40.0111291644390.2635-100000@ns.local.net>
References: <200111292232.fATMW0v02889@vindaloo.ras.ucalgary.ca> <Pine.LNX.4.40.0111291644390.2635-100000@ns.local.net>
Sender: owner-devfs@xxxxxxxxxxx
Gary Shea writes:
> Richard Gooch (rgooch@xxxxxxxxxxxxxxx) wrote:
> > Did you take out the "hdc=ide-scsi" boot line?
> 
> Yeah, removing it had no effect.  That was hours ago ;)
> 
> > Something (not devfs) is causing your ATAPI CD-ROM to be managed by
> > the ide-scsi driver, rather than the ide-cd driver.
> 
> Ok, this critter seems to be under control.  The trick that seems to
> have done it was deleting the cdrom link, cdroms directory, and
> other scsi paraphernalia from the /lib/dev-state directory.  I
> figured maybe devfs was dutifully recreating them just like the
> /dev/hdc I created with mknod.  When devfs recreated the cdrom*
> stuff, /dev/cdroms/cdrom0 was a link down into the /dev/ide
> directory, and the cdrom works again.

Ah. Perhaps your system boot scripts copy the state from
/lib/dev-state into /dev. That's actually unwise, since there is no
distinction between devfs/devfsd created inodes and normal process
created inodes. It would be interesting to know if this indiscriminate
copying is actually happening. It would be nice to know what the
problem was.

I'm currently finishing off the persistence management in devfsd,
which will do this stuff properly. It will require v1.2 of the devfs
core (already in kernel 2.4.17-pre1). Expect a new version of devfsd
soon.

                                Regards,

                                        Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current:   rgooch@xxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>