speedtch usbatm.h,1.4,1.5 usbatm2.c,1.13,1.14
duncan.sands at math.u-psud.fr
Mon Feb 7 17:43:16 EST 2005
On Monday 07 February 2005 19:15, Roman Kagan wrote:
> Ups, didn't see your new message which answers my questions, sorry.
> I agree that my first two arguments are subjective, but...
> On Mon, Feb 07, 2005 at 06:52:28PM +0100, Duncan Sands wrote:
> > > 3) if we ever come to publish some info from the subdrivers in sysfs,
> > > the .cleanup will be a must (as the only way to handle the
> > > degenerate case of open files in sysfs while removing the device)
> > Well, we could (and probably should) just return an error when someone tries
> > to read info for a subdriver that has been disconnected.
> I was talking about something like
> (sleep 120; cat) < /sys/foo/bar &
> modprobe -r subdriver
> Due to this being possible any sysfs stuff is _required_ to provide an
> asynchronous cleanup function to the sysfs core.
there is no contradiction. I don't know anything about sysfs, but this kind of
thing always happens when a driver creates files. One way to do things is to hold
a reference to the struct usbatm_data instance as long as the files are around.
Access to minidriver data is protected by a lock that lives in this instance.
During disconnect, the lock is taken and the pointer to the minidriver data
is cleared. When reading from a file, the lock is taken before copying minidriver
data to the file. If the pointer is NULL, then the file operation is made to fail.
There is no need to take a reference to the _minidriver's_ data.
By the way, maybe I should explain my point of view: minidrivers register and
deregister themselves with usbatm core. [Right now, registration is done via
USB probing, and deregistration is implicitly done by device disconnect. That
is kind of twisted/muddled up, but nevermind :)] Anyway, the core can exploit
the minidriver's methods (and, implicitly, data) from the moment a minidriver
is registered, but not after a minidriver is deregistered. That's how a lot of
the kernel does things, and it is simple and clear. I would like things to be
that way for usbatm too. It also has the advantage that minidrivers can be unloaded
at any time: they just have to deregister themselves when unloaded.
In our case, since deregistration coincides with device disconnect, this means
that the usbatm core needs to arrange things so that it doesn't try to access
the minidriver in any way after the disconnect method returns. In particular,
the heavy_init kernel thread must not be running after disconnect. So the
disconnect method is obliged to wait for the thread to exit. There is no escape
if you want the above simple registration/deregistration model. Likewise for sysfs
attributes: if the minidriver has gone (deregistered), then you mustn't access its
data, and the file method must fail. There is no choice. Since I want that simple
registration/deregistration model (at least I think I do!), inevitably I want the
synchronous thread implementation, and also some way of handling sysfs attributes
without keeping a reference to the minidriver's data.
In short, if you want to argue against waiting for the kernel thread to exit (please
feel free to do so), or holding onto the minidriver's data, you need to argue against
More information about the Usbatm