Re: [RFC] Some thoughts on device drivers and sysfs

From: Adam Belay (abelay_at_novell.com)
Date: 03/27/05

  • Next message: Dominik Brodowski: "Re: [RFC] Some thoughts on device drivers and sysfs" 
    To: Dominik Brodowski <linux@dominikbrodowski.net>
Date:	Sun, 27 Mar 2005 16:27:24 -0500

    On Sun, 2005-03-27 at 23:08 +0200, Dominik Brodowski wrote:
    > On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
    > > One of the original design goals of sysfs was to provide a standardized
    > > location to keep driver configuration attributes. Although sysfs
    > > handles this very well for bus devices and class devices, there isn't
    > > currently a method to export attributes for device drivers and their
    > > specific bound device instances to userspace.

    You're right, I should have worded this differently.

    >
    > Drivers can add (e.g. in ->probe) attributes for devices using
    > extern int device_create_file(struct device *device, struct device_attribute
    > * entry);
    > and delete them (e.g. in ->remove) using
    > extern void device_remove_file(struct device * dev, struct device_attribute
    > * attr);
    >
    > and there's also
    >
    > extern int driver_create_file(struct device_driver *, struct
    > driver_attribute *);
    > extern void driver_remove_file(struct device_driver *, struct
    > driver_attribute *);
    >
    >
    > Dominik

    Yes, I'm aware of these functions but they pollute the bus level
    namespace. I'm interested in reactions to this alternative approach. I
    wanted to explore the possibility of making a device driver instance a
    separate component with its own individual state and relationships.

    Adam

    -
    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: Dominik Brodowski: "Re: [RFC] Some thoughts on device drivers and sysfs"

    Relevant Pages

    • Re: [RFC] New Time of day proposal (updated 9/2/04)
      ... although I want to put the control into sysfs. ... > overhead. ... timesource management code needs to be split off into a timesource.c, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] scsi/sata write barrier support
      ... > the disc parameters and then trigger a device rescan via sysfs (I'll ... > then reading and setting it should be exported via sysfs. ... > sorts of trouble which is why we prefer asking the device what state ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
      ... > Mixing types, expressing multiple lines of data, and doing fancy ... There's precedent for binary data in sysfs -- pci config space is one. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] increse MAX_NR_MEMBLKS to same as MAX_NUMNODES on NUMA
      ... the low level arch specific discontig code, ... memblks in sysfs and elsewhere would have to take that into account... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: debugfs in the namespace
      ... >>fully achieve that goal in my lifetime is something that is left to be ... don't belong in there (like the /proc/drivers/ tree stuff) that should ... Slowly, over time, with creating good, standardised things like sysfs ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)