From: Greg KH <greg@kroah.com>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Updates to sysfs_create_subdir()
Date: Wed, 30 Nov 2005 14:11:53 -0800 [thread overview]
Message-ID: <20051130221153.GA16208@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.50.0511300759170.28582-100000@monsoon.he.net>
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
next prev parent reply other threads:[~2005-11-30 23:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-23 21:56 [RFC] Updates to sysfs_create_subdir() Patrick Mochel
2005-11-28 20:49 ` Greg KH
2005-11-29 1:10 ` Kyle Moffett
2005-11-29 5:44 ` Greg KH
2005-11-29 6:41 ` Kyle Moffett
2005-11-29 6:55 ` Greg KH
2005-11-30 17:05 ` Patrick Mochel
2005-11-30 22:11 ` Greg KH [this message]
2005-12-05 6:24 ` Maneesh Soni
2005-12-19 19:08 ` Patrick Mochel
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=20051130221153.GA16208@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.