On Mon, May 13, 2002 at 12:26:55PM -0700, David Brownell wrote:
> > See my previous response to Johannes about
> > what Documentation/CodingStyle says.
>
> You quoted "if another thread can find your data structure,
> and you don't have a reference count on it you almost
> certainly have a bug". But see above -- the count does
> not need to be driver-visible.
But one of the threads that can touch that data structure, comes
directly from the device driver itself. We _need_ that protection!
> As always, usable style guidelines are not ironclad rules,
> since there's no way for them to capture every possible
> situation and still be usable by non-lawyers.
This is a pretty iron clad rule that we need to follow. It just makes
good sense, from a programming standpoint.
<offtopic>
As for the other rules in CodingStyle being iron-clad, I don't see
anything in there that isn't unreasonable, and should not be followed.
The only "specific" things that are stated there are:
- tabs are 8 spaces big.
- place braces in this format.
Everything else in there is a good guideline. Like "make useful
variable names", and "use good comments that show meaning not
implementation".
And yes, the usb code does violate some of these rules already, but
let's try to fix them, not allow them to linger around (usb-storage
formatting style anyone? :)
Then there's all of the "unwritten" kernel programming guidelines which
I've attempted to document in my paper/article/talk that I don't want to
go into here. If anyone's interested and is not able to make it to OLS,
I'd be glad to send out a copy.
</offtopic>
> > What I'm more worried about is, do you think these two patches contain
> > anything that would cause a bug?
>
> They absolutely do ... they allow the *hci_free_dev() calls to
> be made in_interrupt() contexts, which changes the API.
>
> Arguably, one problem is that this refcounting is being used in a
> way it shouldn't be. It's co-mingling memory management with
> device management.
>
> If I can restate Johannes' claims without needing to put on
> asbestos underwear, he wants hci_free_dev() to just be a
> memory management call ... when it's really a call for device
> management, and those calls aren't done in_interrupt().
>
> I don't actually buy that argument, because I can't see any
> situation where the device management and the memory
> management can justifiably be out of sync. Once the device
> is gone, it's gone.
True, but our reference to that device can linger around in the bowels
of some of the usb device drivers for longer than we would like them to.
Let's make their lives easier and allow themselves to avoid a lot of
grief and effort to get the model correct and handle it all for them.
thanks,
greg k-h
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
