Date: Sun, 28 Mar 2004 01:31:03 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: usbd config file parse behaviour Message-ID: <20040328.013103.00569637.imp@bsdimp.com> In-Reply-To: <20040328002334.GA15543@cicely12.cicely.de> References: <20040326074634.GG94505@cicely12.cicely.de> <20040327.165556.34761174.imp@bsdimp.com> <20040328002334.GA15543@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040328002334.GA15543@cicely12.cicely.de>
Bernd Walter <ticso@cicely12.cicely.de> writes:
: On Sat, Mar 27, 2004 at 04:55:56PM -0700, M. Warner Losh wrote:
: > In message: <20040326074634.GG94505@cicely12.cicely.de>
: > Bernd Walter <ticso@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...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040328.013103.00569637.imp>