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

[Greg KH <greg@kroah.com>]

On Thu, Jun 30, 2005 at 03:20:10PM -0500, Dmitry Torokhov wrote:
> On 6/30/05, Greg KH <greg@kroah.com> 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.

Ok, that locking can now be removed :)

> > 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.

hot-plugging a ps/2 device is a short trip to a burnt out motherboard.
I've worked with the ps/2 specs long enough to know that :)

Anyway, you aren't discovering them on the fly, but I see how a rescan
would help you out here, right?

> > > > > 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.

I don't like "modes" like that.  Just have the driver have no built in
ids, then use the addition of a dynamic id from userspace do the bind,
like pci.

> 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.

Sure, for this I think it should be a bus specific thing.

> 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.

But rescan/reconnect is a bus thing.  The driver core never kicks this
off, nor should it.

> > > 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.

per-device scan doesn't make much sense for other busses, does it?

> > > 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?

The driver is the thing you want to have bound to a device.  Putting it
in every device directory would make the 20K scsi device people very
unhappy as I take up even more of their 31bit memory :)

> > > 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.

Ah, ok, now I remember.  I still think this is more complex than needed,
but don't have an alternative proposal right now :)

thanks,

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