Date: Fri, 31 Jul 2009 20:15:40 +0200 From: Attilio Rao <attilio@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Peter Holm <pho@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [PATCH] Newbus locking Message-ID: <3bbf2fe10907311115m1fb0fcd9lf630c1224682472d@mail.gmail.com> In-Reply-To: <200907311919.26913.hselasky@c2i.net> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311818.08481.hselasky@c2i.net> <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com> <200907311919.26913.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/7/31 Hans Petter Selasky <hselasky@c2i.net>: > 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()! I already told you several time that USB is not my area of expertise and that: * if there is a real time loss * if the time loss is measurable * if the time loss is a real hurt * assuming we think 1 sec delay at boot is something to care about * assuming the drop/pickup for Giant does introduce race that this patch fixes I would have taken care of the problem None of this point is demostrated. I can't measure a time critical issue, neither other people alredy testing the patch could. Privately you said that my work is old/wrong because just of this thing. I can't accept your critics based on the fact you: * didn't look at the patch at all * didn't look at my locking requirements * didn't look at newbus races * didn't quantify the time loss (if any) Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10907311115m1fb0fcd9lf630c1224682472d>