[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150203133906.1a2c14f6@lxorguk.ukuu.org.uk>
Date: Tue, 3 Feb 2015 13:39:06 +0000
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Takashi Iwai <tiwai@...e.de>
Cc: Kay Sievers <kay@...y.org>, Jens Axboe <axboe@...nel.dk>,
Oliver Neukum <oneukum@...e.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: How to fix CDROM/DVD eject mess?
> > It is no workaround, it's the SCSI spec. You only see events if you
> > lock the door.
>
> Yeah, I do understand the reason behind it. But: why udev has to take
> care of SCSI implementation details at this place at all? Isn't the
> place for the generic cdrom device? If it's only for obtaining the
> eject events, you're essentially working around the problem. Instead,
> the kernel should have provided a saner way to enable the event
> generation, IMO.
You could take that to the SCSI and ATA committee's and then try and get
them to agree and every vendor on the planet to make every crapware USB
device implement it. Good luck.
The kernel can provide only the lowest common denominator of service if
it provides a single unified model. In CD space thats a *very low common
denominator*
> The worst point in the current udev rule implementation is that we
> lose the tray lock functionality effectively since the udev rule lock
> and unlock unconditionally.
So fix udev. The kernel can't invent features the hardware doesn't have
and it certainly can't keep polling a drive as that'll murder the battery.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists