Date: Fri, 31 Jul 2009 19:19:25 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-current@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, Peter Holm <pho@freebsd.org> Subject: Re: [PATCH] Newbus locking Message-ID: <200907311919.26913.hselasky@c2i.net> In-Reply-To: <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311818.08481.hselasky@c2i.net> <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 31 July 2009 18:34:26 Attilio Rao wrote: > 2009/7/31 Hans Petter Selasky <hselasky@c2i.net>: > > Hi, > > > > Speaking about the USB subsystem and newbus: > > Hans, > I wanted to maintain this private to us but you clearly don't > understand what races live in newbus, what requirements in locking we > need to protect that and also how a sane locking scheme should be > built. > Please drop this conversation. Hi, I'm not saying that your approach will not work or that it is wrong. I'm saying that it is not fast enough. Your patch affects the boottime, in a negative way. Sure I can help you eliminate blocking the whole USB explore thread from newbus_lock(), but there are sometimes also synchronous delay inside device probe functions, and I think for those cases it would be better if we kept using Giant, because then all sleep calls have drop- and pickup- Giant code, but there is no automatic drop and pickup for the newbus_lock()! How can we multi-thread the boot-sequence given your newbus_lock() requirement ? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907311919.26913.hselasky>