Re: [PATCH] Newbus locking

2009/7/31 Hans Petter Selasky <hselasky_at_c2i.net>:
> On Friday 31 July 2009 18:34:26 Attilio Rao wrote:
>> 2009/7/31 Hans Petter Selasky <hselasky_at_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