|Sam Lawrance||Mar 25, 2004 3:26 pm|
|Bernd Walter||Mar 25, 2004 11:49 pm|
|M. Warner Losh||Mar 27, 2004 3:56 pm|
|Bernd Walter||Mar 27, 2004 4:25 pm|
|M. Warner Losh||Mar 28, 2004 12:30 am|
|Bernd Walter||Mar 28, 2004 2:49 am|
|Sam Lawrance||Mar 29, 2004 6:33 pm|
|M. Warner Losh||Mar 29, 2004 6:44 pm|
|Bernd Walter||Mar 30, 2004 12:41 am|
|M. Warner Losh||Mar 30, 2004 12:46 am|
|Bernd Walter||Mar 30, 2004 1:13 am|
|Sam Lawrance||Mar 31, 2004 4:55 am|
|M. Warner Losh||Mar 31, 2004 9:11 am|
|Bernd Walter||Mar 31, 2004 10:16 am|
|Subject:||usbd config file parse behaviour|
|From:||Bernd Walter (tic...@cicely12.cicely.de)|
|Date:||Mar 28, 2004 2:49:57 am|
On Sun, Mar 28, 2004 at 01:31:03AM -0700, M. Warner Losh wrote:
In message: <2004...@cicely12.cicely.de> Bernd Walter <tic...@cicely12.cicely.de> writes: : On Sat, Mar 27, 2004 at 04:55:56PM -0700, M. Warner Losh wrote: : > In message: <2004...@cicely12.cicely.de> : > Bernd Walter <tic...@cicely12.cicely.de> writes: : > : I'm working on getting devd(8) usable for usb devices. : > : > The part I'm not sure about is where you add the pnpinfo to the : > devaddq stuff. All that stuff should generally be in devaddq. Why : > did you did it the way you did and what were you able to gain by it? : : Fact is that we need more information then available for attach/detach : statements right now to replace usbd - especially the serial number of : a device was the part that I'm interested in.
OK. That makes sense.
: What still puzzles me is why pnpinfo is currently only part in case of : unassigned new devices - it looks intentionaly to be left out for other : cases - therefor the current patch just adds it in the most simple way : to test the other part and was never intended as a commit candidate. : Do you think there could be problems with pnpinfo for other type of : devices (cardbus, pcmcia, acpi, ...)?
No problems. I didn't add it because I originally thought that devd could look up the device and tease it out. However, it would be convenient to have this information at hand, and it does eliminate a potential race condition to provide it all at once. The only thing I worry about it exceeding some static limit in devd/devctl. And if we do, we can increase it because we malloc things in the kernel and having a bigger userland buffer isn't going to hurt.
I'll look into these issues and see how hard this will be.
Btw, any interest in making it possible to kldload a usb module and having device attach to it? Right now the usb code assumes that you can unplug the device and replug it back in. I have at least two devices on my laptop that can't be removed (bluetooth and memory stick reader), so I can't dynamically load drivers for them...
I'll think about it. Reprobing is not so much an issue as selecting an interface for it.