public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox