Re: [RFC] bind and unbind drivers from userspace through sysfs

[Dmitry Torokhov]

On 6/30/05, Greg KH <greg@xxxxxxxxx> wrote:
> On Thu, Jun 30, 2005 at 01:13:53AM -0500, Dmitry Torokhov wrote:
> > On Wednesday 29 June 2005 18:47, Greg KH wrote:
> > > On Fri, Jun 24, 2005 at 11:22:57PM -0500, Dmitry Torokhov wrote:
> > > > On Friday 24 June 2005 00:12, Greg KH wrote:
> > > > > Even so, with these two patches, people should be able to do things that
> > > > > they have been wanting to do for a while (like take over the what driver
> > > > > to what device logic in userspace, as I know some distro installers
> > > > > really want to do.)
> > > > >
> > > >
> > > > I think bind/unbind should be bus's methods and attributes should be
> > > > created only if bus supports such operations. Some buses either have
> > > > or may need additional locking considerations and will not particularly
> > > > like driver core getting in the middle of things.
> > >
> > > Examples of such?
> >
> > serio, gameport. Everything is protected by a semaphore, partly for
> > historical reasons, partly because when adding children devices parent
> > devices need to be locked too...
> 
> Why do parent devices need to be locked?  Reference counting in the
> driver core should take care of everything properly, right?  Also, these

Children devices access hardware thtough their parent, which has to be
functional at that time, otherwise if you initializing child device
while parent is half gone you'll get bunch of errors reported. And
again - historical reasons - when driver core did not allow adding
children from parents probe routines serio core had to work around it
and it required additional locking.

> are not hotpluggable devices, so it should be a lot easier :)

Some of them are and some are not. Hot-plugging an PS/2 mouse or
keyboard usually works, although there are exceptions.

> 
> > > Yes, a bus that isn't really expecting this to
> > > happen, as it has some odd locking logic in the
> > > registering/unregistering of a new driver for it, might have issues.
> > > But I'd say that this is the bus's fault, not the driver core's fault.
> > >
> >
> > I don't think so. Up to now all driver core iteractions were under
> > individual bus code control. Now out of sudden you allow disconnecting
> > device from its driver from outside of bus control and you are saying
> > that's all right. Driver core is a framework; buses use driver core to
> > simplify their tasks but driver core does not really control their
> > operations.
> 
> Well, yes and no.  I see the driver core driving a lot of interactions,
> due to the probing and matching and disconnecting all coming from the
> core, but I guess as they are usually initiated from the bus itself, I
> can see how you feel this way also.  So ok, yes, this is a change, I
> agree.  But it isn't one that should cause major issues.
> 

It is fixable and I meant to cange it, but not ATM and I hate leaving
the code with bad locking in kernel proper ;(

> > > > Btw, do we really need separate attributes for bind/unbind?
> > >
> > > Overloading a single file would be messier.  The overhead for an
> > > additional attribute per driver is quite small (I move the unbind
> > > attribute to the driver, as it makes more sense there as Pat mentioned.)
> > >
> >
> > Let me ask again - what if we need more operations similar to [un]bind,
> > such as rescan?
> 
> "rescan"?  Like reprobe the bus address space?  That sounds like a bus
> specific issue.  But if you like I could add a general bus callback for
> that and an attribute for it.  I know pci could use that for some odd
> cases (see the fakephp driver for an example of how to do rescan for pci
> devices from a driver itself.)
> 

No, it for entire bus space. Imagine you have a device that is marked
as "bind_mode=manual" because normally you don't want to have it
activated for some reason. Later you want to activate it. Right now in
serio you can do:

     echo -n "rescan" > /sys/bus/serio/devices/serioX/drvctl

and it will do the standard binding (match + probe) for that device
only. It is different from bus-wide rescan operation. Maybe rescan is
not the best name, but that what I have in serio for now.

Reconnect is indeed bus-specific issue but it is very close to rescan.
We already know the driver, we just want to reinitialize hardware, if
possible. Helps to keep input devices the same when mouse goes crazy
for some reason.

> > They do not use a specific driver but work for device.
> 
> Yes, and as such, rescan should be a bus attribute, not a driver or
> device one.
>

See above, I want a per-device operation here. Bus-wide one could be
also useful, but I was talking about per-device.
 
> > If you keep bind/unbind in driver and rescan/reconnect/etc in device
> > subdirectoty it will be rather messy. Please consider movin in the
> > opposite directtion - have bind and unbind attributes of device, not
> > driver.
> 
> No, I put bind/unbind in the driver directory.  There is no additions to
> the device directory.
> 

Could you give your rationale for putting it in driver?

> > Also, what about rolling bind_mode attribute into driver core as well?
> 
> Um, I don't recall what you are referring to here.  Have a
> pointer/patch?
> 

No patch at the moment, there were quite few changes since I sent it
to you last time. You could take a look in serio for the usage though.
Basically both drivers and devices get a new attribute "bind_mode"
(auto|manual). When bind mode is set to manual devices are bound to
driver only when user explicitely says so. This allows having 2+
drivers for the same hardware at the same time. The preferred one has
bind_mode=auto, secondary has bind_mode=manual. Take for example
serio_raw. We really want psmouse be loaded by default but if user
needs raw access to a specific serio port he can manually bind
serio_raw module to that port.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/