lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ