From owner-freebsd-usb@FreeBSD.ORG Tue Aug 19 20:27:02 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752781065702; Tue, 19 Aug 2008 20:27:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 83EB38FC18; Tue, 19 Aug 2008 20:27:01 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=H3poPDSvFasA:10 a=fj6dw-CIB2gA:10 a=6MIg2jpqvhTpo/gR8GzG7Q==:17 a=3KYg0pR1Xb4fHWQ9kKcA:9 a=tj716jywtbLrFEIbY1QA:7 a=1YIwwewWvihx4zNiTmpyUEW7NckA:4 a=MxZ3bB5I4kYA:10 Received: from [62.113.133.243] (account mc467741@c2i.net [62.113.133.243] verified) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 302565072; Tue, 19 Aug 2008 22:26:59 +0200 From: Hans Petter Selasky To: Alfred Perlstein Date: Tue, 19 Aug 2008 22:28:36 +0200 User-Agent: KMail/1.9.7 References: <20080818205914.GJ16977@elvis.mu.org> <48AB233C.2010602@FreeBSD.org> <20080819200017.GC16977@elvis.mu.org> In-Reply-To: <20080819200017.GC16977@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808192228.39015.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb4bsd patch review [was Re: ...] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 20:27:02 -0000 > > > > What do the newbus guys say about this? Adding a workaround in > > underlying code for a problem caused by your own code is often a signal > > that you're not going about it the right way. At the very least the > > reason for the special case should be documented here. > > I need to think about this, Hans gave me a better argument on > AIM earlier for it, I need to reload this in my head. > > > >int > > >device_delete_all_children(device_t dev) > > >{ > > > device_t *devlist; > > > int devcount; > > > int error; > > > > > > error = device_get_children(dev, &devlist, &devcount); > > > if (error == 0) { > > > while (devcount-- > 0) { > > > error = device_delete_child(dev, > > > devlist[devcount]); > > > if (error) { > > > break; > > > } > > > } > > > free(devlist, M_TEMP); > > > } > > > return (error); > > >} > > > In the existing kernel code, "device_get_children()" is used many places without checking the error code. I have patches, but they are not part of the patch-set. Also freeing a pointer to zero bytes is not logical. I'm not sure if this is allowed in kernel space? ptr = malloc(0, ... ) free(0); The device_get_children() could have returned an error if there are no children, but again, the existing code does not check this return value. --HPS