Re: [PATCH] Introduce {sysfs,device}_create_file_mode

[Daniel Mack]

On Wed, May 12, 2010 at 11:30:50PM +0400, Anton Vorontsov wrote:
> On Wed, May 12, 2010 at 09:12:46PM +0200, Kay Sievers wrote:
> > On Wed, May 12, 2010 at 21:08, Anton Vorontsov <cbouatmailru@xxxxxxxxx> wrote:
> > > On Wed, May 12, 2010 at 11:38:06AM -0700, Greg KH wrote:
> > >> On Wed, May 12, 2010 at 10:15:46PM +0400, Anton Vorontsov wrote:
> > >> > We need to create attributes with different modes across devices.
> > >> > We can do this by modifying attr.mode between device_create_file
> > >> > invocations, but that is racy in case of globally defined attrs.
> > >> >
> > >> > Luckily, there's sysfs_add_file_mode() function that seems to do
> > >> > exactly what we want, and if we use it, we don't need any locks
> > >> > to avoid races. Though, it isn't exposed via device-drivers core
> > >> > API.
> > >>
> > >> But you race the creation of the device notifying userspace, and then
> > >> the file being created, right?
> > >
> > > Yep, you've raised that question once, like 3 years ago. :-)
> > >
> > > http://lkml.org/lkml/2007/4/11/452
> > > http://lkml.org/lkml/2007/4/12/144
> > >
> > > In short: we can't use attr groups since the attributes creation
> > > is conditional. And we especially don't want to use the attr groups
> > > for attrs with different modes. But it's not a problem, because...
> > 
> > Groups have a filter callback for every member, to decide if the
> > attribute should be created or not.
> 
> Thanks Kay. It seems the callback was added just a few months
> after the discussion above. ;-)
> 
> And this commit looks especially cool:
> 
> commit 0f4238958d28044b335644b69df6071cdb04b5ce
> Author: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> Date:   Thu Mar 20 20:47:52 2008 -0500
> 
>     [SCSI] sysfs: make group is_valid return a mode_t
> 
> Daniel, I think that today we can just use the attribute group
> mechanism, it has all needed. Do you want me to prepare a patch
> to convert existing attributes, or do you to try it yourself?

Would be good if you did that, just to see how this is interface meant
to be used exactly. I'll adopt my patches accordingly then.

Thanks,
Daniel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/