Sarah Sharp wrote:
> Yes, this is a slight race condition, and we should wait for the
> successful event. However, we have not seen any issues with this
> race condition.
I'm glad that you say that having the race is wrong ("we should") and
I guess that "we should wait" for the sake of correctness?
> > Which means that the controller is obeying the rules, and the
> > software is wrong.
>
> I think your mindset isn't helpful here.
I think his mindset is helpful for xHCI users in the future.
> Software will never be perfect.
I think software can be perfect. It just takes well-defined scope
and desire for perfection. But let's ignore perfect and stay at
correct, because it doesn't make sense for many businesses to
invest in perfection.
David mentioned that his company is investing in xHCI correctness,
and you seem to principally agree with correctness since you write
that we shouldn't settle for having a race.
<side_note>
> The questions to ask when discovering a bug are:
>
> 1. What is the impact of this bug? Is it user-visible?
> 2. How many customers are impacted by this bug?
> 3. What is the software complexity of fixing this bug?
> 4. What are the chances of the fix causing other issues?
2. sounds like you reduce humans to business entities "customers"
which I don't think is cool, but I do realize that most kernel work
is completely business-driven.
Users are other humans and when I work on software I want those
other humans to have the best possible software I can give them,
not just the best possible software I can give them without causing
(or exposing?) other issues. That seems like sweeping dust under the
carpet. :)
My fault in libusb is that I naïvely expected other open source
developers to share the desire for correctness, when in fact many
developers don't care about correctness at all, much less perfection.
> In this case, the bug has been worked around (not perfectly), but we've
> had no customer reports that this is an issue.
Maybe perfection could be expressed as pre-empting any and all issues.
Again - not economical. Much more about what we leave behind for those
who come after us, than about what we can profit from today.
</side_node>
> So fixing this race condition is a really low priority for me
If fixing the race requires larger architectural changes doesn't that
suggest that the software model for the hardware interface is still
(perhaps just a little) incorrect, and should be fixed?
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
