Messages in this thread | | | From | Dmitry Torokhov <> | Subject | Re: [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach | Date | Fri, 5 Nov 2004 00:02:57 -0500 |
| |
On Thursday 04 November 2004 12:53 pm, Greg KH wrote: > On Thu, Nov 04, 2004 at 04:43:30PM +0900, Tejun Heo wrote: > > Hello, again. :-) > > > > These are the manual device attach patches I was talking about in the > > previous posting. These patches need devparam patches to be applied > > first. It's composed of two parts. > > > > 1. sysctl node dev.autoattach > > > > dev.autoattach is read/write integer sysctl node which controls > > driver-model's behavior regarding device - driver association. > > Ick, no new sysctls please. Make this a per-bus attribute that gets > written to in sysfs. Much nicer and much finer control then. >
I think that my bind)mode patches which allow to control binding through sysfs on pre-device and per-driver base should suffice here. I really doubt that anybody would want to keep autoattach disabled and do all matching manually ;). Besides having per-driver attribute allows drivers authors control binding.
> > 0: autoattach disabled. devices are not associated with drivers > > automatically. i.e. insmod'ing e100.ko won't cause it to attach to the > > actual e100 devices. > > 1: autoattach enabled. The default value. This is the same as the > > current driver model behavior. Driver model automatically associates > > devices to drivers. > > 2: rescan command. If this value is written, bus_rescan_devices() is > > invoked for all the registered bus types; thus attaching all > > devices to available drivers. After rescan is complete, the > > autoattach value is set to 1. > > Make this a different sysfs file. "rescan" would be good. > > Look at how pci can handle adding new devices to their drivers from > sysfs. If we can move that kind of functionality to the driver core, so > that all busses get it (it will require a new per-bus callback though, > se the other patches recently posted to lkml for an example of this), > that would be what I would like to see happen. > > > 2. per-device attach and detach sysfs node. > > > > Two files named attach and detach are created under each device's > > sysfs directory. Reading attach node shows the name of applicable > > drivers. >
Do we really need 2 or even 3 files ("attach", "detach" and "rescan")? Given that you really can't (at least not yet) do all there operations for all buses from the core that woudl require 3 per-bus callbacks. I think reserving special values such as "none" or "detach" and "rescan" shoudl work just fine and also willallow extending supported operations on per-bus basis. For example serio bus supports "reconnect" option which tries to re-initialize device if something happened to it. It does not want to do rescan as that would generate new input devices while it is much more convenient to re-use old ones.
> How does a device know what drivers could be bound to it? It's the > other way around, drivers know what kind of devices they can bind to.
But when 2+ drivers can be bound to a device then particular _device_ gets to decide which driver is best suited for it, like in cases of e100/eepro100 or psmouse/serio_raw.
> Let's add the ability to add more devices to a driver through sysfs, > again, like PCI does. >
Well, PCI does add a new ID to a driver allowing it to bind to a whole new set of devices. I agree that this is a "driver" operation.
> > Writing a driver name attaches the device to the driver. > > No, do it the other way, attach a driver to a device. >
I disagree. Here you working with particular device. You are not saying "from now on I want e100 to bind all my 5 new network cards that happen to have id XXXX:YYYY". Instead you are saying "I want to bind e100 driver to this card residing at /sys/bus/pci/0000.....". In other word it is operation on particular device and should be done by manipulating device attribute.
-- Dmitry - 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/
| |