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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:07    [W:0.025 / U:108.356 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site