[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hh9vaft0u.wl-tiwai@suse.de>
Date: Wed, 28 Jan 2015 23:18:57 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Add device_create_files() and device_remove_files() helpers
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.
What if having a link to the chained group for appending entries
dynamically? Just a wild idea, but it might make things easier.
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists