Re: [RFC] Updates to sysfs_create_subdir()

From: Greg KH
Date: Wed Nov 30 2005 - 18:07:22 EST


On Wed, Nov 30, 2005 at 09:05:41AM -0800, Patrick Mochel wrote:
>
> On Mon, 28 Nov 2005, Greg KH wrote:
>
> > On Wed, Nov 23, 2005 at 01:56:29PM -0800, Patrick Mochel wrote:
> > >
> > > The patch below addresses this issue by parsing the subdirectory name and
> > > creating any parent directories delineated by a '/'.
> >
> > Generally I never liked parsing stuff like this in the kernel (proc and
> > devfs both do this). That being said, I do see the need to make subdirs
> > like this easier.
>
> Heh, just because proc and devfs did it doesn't mean it's inherently
> evil..

I did not mean to imply that, just that putting parsers like this spread
around the kernel in different places isn't the best thing to have.

> > But what about cleanups? If I create an attribute group "foo/baz/x/" and
> > then remove it, will the subdirectories get cleaned up too? What about
> > if I had created a group "foo/baz/y/" after the "x" one? Or just
> > "foo/baz"?
>
> The patch I sent previously did not include a way to cleanup the
> subdirectories, but it's pretty straightforward and covered by this patch.
> Basically, it adds a new refcount to struct sysfs_dirent (->s_refs) that
> is incremented when a subdirectory is created and decremented when the
> subdirectory is removed. When it reaches 0, that directory itself can be
> removed.
>
> Note that it's a bit hacky in sysfs_remove_group(), since we need the
> bottom-most dentry a priori. I'm not sure the best way to do this off the
> top of my head, and ideas?

Don't know, I'd ask Maneesh, as he knows this code quite well.

> If you're interested, I will break it up into 2-3 patches for application
> (I'd like to also move the sysfs_dirent declaration into fs/sysfs/sysfs.h,
> since they're really private and so that further modification of the
> declaration doesn't preclude a nearly-full recompile of the tree).

Thanks, breaking it up into logicial pieces is a good idea so we can see
what is happening easier.

greg k-h
-
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/