All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <abelay-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
To: Dominik Brodowski
	<linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>
Cc: linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC] Some thoughts on device drivers and sysfs
Date: Sun, 27 Mar 2005 17:18:10 -0500	[thread overview]
Message-ID: <1111961891.3503.132.camel@localhost.localdomain> (raw)
In-Reply-To: <20050327214309.GA18745-JwFqNg2GrOVrgjWwlLH9qw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

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



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



WARNING: multiple messages have this Message-ID (diff)
From: Adam Belay <abelay@novell.com>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Greg KH <greg@kroah.com>,
	Patrick Mochel <mochel@digitalimplant.org>,
	linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org
Subject: Re: [RFC] Some thoughts on device drivers and sysfs
Date: Sun, 27 Mar 2005 17:18:10 -0500	[thread overview]
Message-ID: <1111961891.3503.132.camel@localhost.localdomain> (raw)
In-Reply-To: <20050327214309.GA18745@isilmar.linta.de>

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



  parent reply	other threads:[~2005-03-27 22:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-27 19:24 [RFC] Some thoughts on device drivers and sysfs Adam Belay
2005-03-27 19:24 ` Adam Belay
     [not found] ` <1111951499.3503.87.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2005-03-27 20:53   ` Arioch
2005-03-27 20:53     ` Arioch
2005-03-27 21:08   ` Dominik Brodowski
2005-03-27 21:08     ` Dominik Brodowski
     [not found]     ` <20050327210853.GA18358-JwFqNg2GrOVrgjWwlLH9qw@public.gmane.org>
2005-03-27 21:27       ` Adam Belay
2005-03-27 21:27         ` Adam Belay
     [not found]         ` <1111958844.3503.100.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2005-03-27 21:43           ` Dominik Brodowski
2005-03-27 21:43             ` Dominik Brodowski
     [not found]             ` <20050327214309.GA18745-JwFqNg2GrOVrgjWwlLH9qw@public.gmane.org>
2005-03-27 22:18               ` Adam Belay [this message]
2005-03-27 22:18                 ` Adam Belay
2005-03-27 21:25   ` Jon Smirl
2005-03-27 21:25     ` Jon Smirl
2005-03-29  5:03   ` Greg KH
2005-03-29  5:03     ` Greg KH
     [not found]     ` <20050329050345.GB7937-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2005-03-29  6:33       ` Dmitry Torokhov
2005-03-29  6:33         ` [linux-pm] " Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111961891.3503.132.camel@localhost.localdomain \
    --to=abelay-et1tbqhtxzrqt0dzr+alfa@public.gmane.org \
    --cc=linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.