[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150128222851.GA24074@kroah.com>
Date: Wed, 28 Jan 2015 14:28:51 -0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Add device_create_files() and device_remove_files()
helpers
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
--
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