On Wed, 10 Nov 2004, David Brownell wrote:
> > > But as I said: that relies on type punning ("knowing"
> > > that pointer-to-A is also pointer-to-B), which is a
> > > practice best observed by avoiding it.
> >
> > I think it's not so bad, when done in controlled ways like here. You
> > might just as well complain about the types returned by kmalloc and
> > accepted by kfree. :-)
>
> That'd be beside the point ... those routines DO work with
> untyped blocks of memory, always have, always will. The
> type punning here involves two different data types, saying
> they must be embedded within each other in a particular way.
Not embedded within each other. (Not even one embedded within the other,
which must be what you really meant!) One is allocated immediately
following the end of the other. A minor difference, true.
Yes, there are two different data types, usb_hcd plus something else.
The difficulty is that the second type is variable and unknown to the core
routine that has to allocate the storage for it. Sometimes it will be a
uhci_hcd, other times it will be an ohci-hcd, etc. Since the actual type
isn't known until runtime, naturally the pointer has to be treated as
untyped.
Strictly speaking, the pattern here isn't type punning as you described
it. That is, it doesn't involve knowing that a pointer-to-A is also a
pointer-to-B. Rather, it involves knowing for example that a pointer to
just beyond the end of struct usb_hcd is also a pointer to struct
ohci_hcd. It's kind of like what to_usb_device() does; that involves
knowing that a pointer the right amount before the beginning of a struct
device is also a pointer to a struct usb_device. In both cases it's
possible to violate type safety: In the first case by calling
hcd_to_ohci() with an hcd that wasn't created by the OHCI driver, in the
second case by calling to_usb_device() with a struct device that isn't
part of a struct usb_device.
> I guess until there actually IS code that knows how to restart
> a generic dead HCD, those issues don't matter much. And maybe
> those recent patches to let drivers be bound/unbound through
> sysfs could help in this area too ... though I don't much like
> the notion of unbind/rebind instead of driver reset (it might
> not be able to reclaim all the resources again!), that should
> certainly work with any driver when resources arent' scarce.
I agree. I also worry that when driver->reset eventually gets invoked
while restarting an OHCI controller, the function call I added (performing
the private initializations currently found in ohci_alloc_hcd) will cause
trouble.
> > Shall I simply go ahead and submit my patches for Greg to review?
>
> I don't think I'd have too many worries about them going on
> top of those PM patches, except for the "type punning must
> work" issue. I'll send Dales' third OHCI patch soonish
> too, that'll have another HCD that'll need updates.
I'll redo them against your recent PM changes. Please don't change much
more until they've had a chance to get accepted!
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
