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

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

  • Next message: H. J. Lu: "i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)"
    To: Dominik Brodowski <linux@dominikbrodowski.net>
    Date:	Sun, 27 Mar 2005 17:18:10 -0500
    
    

    On Sun, 2005-03-27 at 23:43 +0200, Dominik Brodowski wrote:
    > On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
    > > > 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.
    >
    > To be honest, I don't consider this to be a pollution of the "bus"
    > namespace, but I fear that having two different places for somewhat similar,
    > or even equal, data adds unneeded complexity to the driver model. In what
    > specific instances has the current design limited or obstructed your
    > intentions?
    >

    Fair enough. I just wanted to float this possibility. I appreciate
    your comments. The original intention for this design was to begin
    working on a framework for driver layering. (ex. snd-intel8x0m -> ac97,
    or the pci express bus abstraction) I was considering the possibility
    of having driver devices with parent and child relationships that
    reflect the internal layering of Linux drivers. I haven't really had a
    chance to fully develop this idea, so at this point, driver layering and
    my original email are just abstract concepts.

    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: H. J. Lu: "i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)"

    Relevant Pages

    • Re: [RFC] Some thoughts on device drivers and sysfs
      ... I'm aware of these functions but they pollute the bus level ... namespace, but I fear that having two different places for somewhat similar, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] Driver States
      ... > discussion on how these might be defined at the bus, driver, and class ... > At the bus level, there are two state attributes, power and ... > be enabled during a non-off power state. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: My thoughts on the "new development model"
      ... |>>> 2.6 tree is great for gentoo users who like gcc consuming all CPU ... |>> that after a month or so of fixes etc it will be a very stable kernel ... driver for 2.6.7 for an ADSL card; a development driver for 2.6.5 for a ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: sata related hang with linux-2.6
      ... IMHO there's something not quite right with the Silicon Image libata ... Perhaps the driver is enabling the hardware to generate interrupts ... before setting up the interrupt routine for it? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: SL811 problem on mach-pxa
      ... It was tested with _both_ workarounds for IRQ issues; ... unlike the predecessors to this driver). ... I've had reports that one of the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)