Thread (75 messages) 75 messages, 14 authors, 2014-10-15

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2014-09-30 21:34:53
Also in: linux-scsi, lkml

On Tue, Sep 30, 2014 at 11:06:34PM +0200, Pavel Machek wrote:
On Mon 2014-09-22 13:23:54, Dmitry Torokhov wrote:
quoted
On Monday, September 22, 2014 09:49:06 PM Pavel Machek wrote:
quoted
On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
quoted
On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
quoted
quoted
quoted
quoted
Yes, but we mostly do this anyway.  SCSI for instance does asynchronous
scanning of attached devices (once the cards are probed)
What would it do it card was a bit slow to probe?
quoted
but has a sync
point for ordering.
Quite often we do not really care about ordering of devices. I mean,
does it matter if your mouse is discovered before your keyboard or
after?
Actually yes, I suspect it does.

I do evtest /dev/input/eventX by hand, occassionaly. It would be
annoying if they moved between reboots.
I am sorry but you will have to cope with such annoyances. It' snot like we 
fail to boot the box here.

The systems are now mostly hot-pluggable and userland is supposed to
handle it, and it does, at least for input devices. If you want stable naming
use udev facilities to rename devices as needed or add needed symlinks (by-id, 
etc.).
Well, it would be nice if udev was not mandatory. Do the sync points
for ordering actually cost us something?
Yes, boot time. We can save a second or two off the boot time if we probe
several devices/drivers simultaneously.

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help