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]
Message-ID: <Pine.LNX.4.44L0.0904211026080.2981-100000@iolanthe.rowland.org>
Date:	Tue, 21 Apr 2009 10:36:28 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jamie Lokier <jamie@...reable.org>
cc:	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	David VomLehn <dvomlehn@...co.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Linux Embedded Mailing List <linux-embedded@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wait for console to become available, v3.2

On Tue, 21 Apr 2009, Jamie Lokier wrote:

> Ingo Molnar wrote:
> > * Arjan van de Ven <arjan@...radead.org> wrote:
> > > But more importantly... USB *CANNOT* do this fundamental 
> > > operation. USB does not have the capability to know when you have 
> > > seen all devices that are connected. Devices just show up a random 
> > > amount of time after you turn the power on for the bus.... there's 
> > > no "and now we've seen all" operation.
> > 
> > Yes - and this is fundamentally true of any hotplug bus design.
> 
> It's not fundamental, for devices you know are plugged in at boot.
> All it takes is for the bus to support a synchronous "enumerate all"
> procedure.  That _could_ involve a timeout, but there are better ways.
> But not for USB.

Is that last sentence necessarily true?  I suppose it is true that a
USB device isn't obligated to make its presence on the bus known
immediately, but nevertheless, most of them do.  In theory we could add
code to the USB subsystem to detect when the hub driver has become idle
and therefore all devices that were initially plugged in have been
probed.

That probably would work for solving the console problem.  Storage 
devices present additional problems, however:

When usb-storage discovers a device, it generally delays a while before 
scanning it.  (The default delay is 5 seconds, but it is adjustable by 
a module parameter.)  And then when the scanning function is called, 
the SCSI subsystem turns it into an asynchronous request -- that's why 
the kernel log usually says "usb-storage: device scan complete" before 
the scan has in fact begun.

So I don't know about determining when all USB mass-storage devices 
have been detected, but USB serial devices should be practical.

If somebody would like to suggest a programming interface (a waitqueue 
perhaps?) by which the USB hub driver could send a notification when it 
becomes idle, I could implement it.

Alan Stern

--
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