Re: [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach

From: Dmitry Torokhov (dtor_core_at_ameritech.net)
Date: 11/05/04

  • Next message: Anton Blanchard: "[PATCH] reset cache_hot_time" 
    To: linux-kernel@vger.kernel.org
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/
  • Next message: Anton Blanchard: "[PATCH] reset cache_hot_time"

    Relevant Pages

    • Re: MOUHID attaching problem
      ... driver passes AttachDevice function in CDevice.cpp. ... UHCD driver DLL attach ... InitializeUHCI ++ ... CHub(Root tier 0)::AllocateDeviceArray - attempting to allocate 1 devices ...
      (microsoft.public.windowsce.platbuilder)
    • [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach
      ... These are the manual device attach patches I was talking about in the ... dev.autoattach is read/write integer sysctl node which controls ... driver-model's behavior regarding device - driver association. ...
      (Linux-Kernel)
    • Problems installing X25 9.1 on Solaris 8
      ... Driver successfully added to system but failed to attach ... Warning: Driver successfully added to system but failed to attach ... Installation of was successful. ...
      (SunManagers)
    • HP-UX driver attach routine not called, ioscan does not help
      ... An HP-UX 11.0 DLKM PCI interface device driver I have written does not ... attach() is still not called. ... the loadand attachroutines that I am using to track down the ...
      (comp.sys.hp.hpux)
    • Re: MMC: Make the configuration memory resource optional
      ... I think everyone wants to use the clock API to control clocks. ... Talk to Dmitry about his clock API patches. ... Find out why they didnt go upstream. ... solved by a patch that removes power switching from the tmio driver. ...
      (Linux-Kernel)