linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Add device_create_files() and device_remove_files() helpers
Date: Wed, 28 Jan 2015 14:28:51 -0800	[thread overview]
Message-ID: <20150128222851.GA24074@kroah.com> (raw)
In-Reply-To: <s5hh9vaft0u.wl-tiwai@suse.de>

On Wed, Jan 28, 2015 at 11:18:57PM +0100, Takashi Iwai wrote:
> At Wed, 28 Jan 2015 13:34:21 -0800,
> Greg Kroah-Hartman wrote:
> > 
> > On Wed, Jan 28, 2015 at 10:26:28PM +0100, Takashi Iwai wrote:
> > > At Wed, 28 Jan 2015 13:05:47 -0800,
> > > Greg Kroah-Hartman wrote:
> > > > 
> > > > On Wed, Jan 28, 2015 at 09:46:12PM +0100, Takashi Iwai wrote:
> > > > > Hi,
> > > > > 
> > > > > this is a simple patch to add device_create_files() and
> > > > > device_remove_files() to replace multiple device_create_file() or
> > > > > _remove() calls with a single shot with the device_attr list.
> > > > > 
> > > > > It's basically just a clean up, but also helps to simplify the error
> > > > > handling a lot in many existing codes since the function itself does
> > > > > rollback at error.
> > > > > 
> > > > > The series contains a patch to apply these to drivers/base/node.c.
> > > > > I have lots of patches (up to 30) to use these in the whole tree, but
> > > > > maybe it'd be easier too apply once after this stuff is merged at
> > > > > first.  It's just a cleanup so no urgent task, after all.
> > > > 
> > > > I'd like to some day be able to drop device_create_file entirely, as it
> > > > is almost always used in a racy way (but not always, so we can't get rid
> > > > of it today.)
> > > > 
> > > > A driver should be using an attribute group and be created/registered
> > > > with it if they want any files associated with it, so giving people the
> > > > ability to add large numbers of files all at once seems like the wrong
> > > > thing to do :)
> > > 
> > > Well, through the glance over many codes using device_create_file(),
> > > I think the problem of the attribute group is that there is little
> > > help for generating the entries dynamically.  For example, if you have
> > > two groups you want to enable conditionally, what would be the best
> > > way to implement?
> > 
> > Use the is_visable() function callback, that's what it is there for.
> 
> But if the entries are determined dynamically?  Selecting the enabled
> elements from the static list is one way, it'd work in many cases, but
> it's not always the most straightforward way.  It often would be
> easier to build up the list dynamically.

Do you have an example of this?  Wouldn't it be the same thing to list
them all in an attribute group, but only say "this is valid" in the
is_visable() callback for those that would have been built up
dynamically?

> What if having a link to the chained group for appending entries
> dynamically?  Just a wild idea, but it might make things easier.

We have the ability to pass a group list pointer to device_create
already, and the attribute pointer is a list of groups as well, how can
we change this to be "easier"?

thanks,

greg k-h

  reply	other threads:[~2015-01-29  2:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 20:46 [PATCH 0/2] Add device_create_files() and device_remove_files() helpers Takashi Iwai
2015-01-28 20:46 ` [PATCH 1/2] driver core: " Takashi Iwai
2015-01-28 20:46 ` [PATCH 2/2] drivers/base/node: Use device_create_files() and device_remove_files() Takashi Iwai
2015-01-28 21:06   ` Greg Kroah-Hartman
2015-01-28 21:27     ` Takashi Iwai
2015-01-28 21:05 ` [PATCH 0/2] Add device_create_files() and device_remove_files() helpers Greg Kroah-Hartman
2015-01-28 21:26   ` Takashi Iwai
2015-01-28 21:34     ` Greg Kroah-Hartman
2015-01-28 22:18       ` Takashi Iwai
2015-01-28 22:28         ` Greg Kroah-Hartman [this message]
2015-01-28 23:11           ` Takashi Iwai
2015-01-30  4:26             ` Greg Kroah-Hartman
2015-01-30 16:31               ` Takashi Iwai
2015-02-07 10:10                 ` Greg Kroah-Hartman
2015-02-08  8:41                   ` Takashi Iwai

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=20150128222851.GA24074@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).