Date: Sun, 28 Mar 2004 12:47:35 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: usbd config file parse behaviour Message-ID: <20040328104734.GB15543@cicely12.cicely.de> In-Reply-To: <20040328.013103.00569637.imp@bsdimp.com> References: <20040326074634.GG94505@cicely12.cicely.de> <20040327.165556.34761174.imp@bsdimp.com> <20040328002334.GA15543@cicely12.cicely.de> <20040328.013103.00569637.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 28, 2004 at 01:31:03AM -0700, M. Warner Losh wrote: > 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. Thanks. > 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. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040328104734.GB15543>