From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 28 02:50:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 769B916A4CE for ; Sun, 28 Mar 2004 02:50:07 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE08043D2F for ; Sun, 28 Mar 2004 02:50:06 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i2SAmmUS078496 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 28 Mar 2004 12:48:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i2SAlahn016246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Mar 2004 12:47:37 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i2SAla4n019633; Sun, 28 Mar 2004 12:47:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i2SAlZWd019632; Sun, 28 Mar 2004 12:47:35 +0200 (CEST) (envelope-from ticso) Date: Sun, 28 Mar 2004 12:47:35 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20040328104734.GB15543@cicely12.cicely.de> References: <20040326074634.GG94505@cicely12.cicely.de> <20040327.165556.34761174.imp@bsdimp.com> <20040328002334.GA15543@cicely12.cicely.de> <20040328.013103.00569637.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040328.013103.00569637.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.cicely.de cc: ticso@cicely12.cicely.de cc: samuel.lawrance@studentmail.newcastle.edu.au cc: ticso@cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: usbd config file parse behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2004 10:50:07 -0000 On Sun, Mar 28, 2004 at 01:31:03AM -0700, M. Warner Losh wrote: > In message: <20040328002334.GA15543@cicely12.cicely.de> > Bernd Walter writes: > : On Sat, Mar 27, 2004 at 04:55:56PM -0700, M. Warner Losh wrote: > : > In message: <20040326074634.GG94505@cicely12.cicely.de> > : > Bernd Walter 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