lkml.org 
[lkml]   [2004]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.984 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site