From: Greg KH <gregkh@suse.de>
To: Alex Chiang <achiang@hp.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sysfs: sysfs_add_one tells you _where_ the duplicate file is
Date: Wed, 11 Feb 2009 19:02:27 -0800 [thread overview]
Message-ID: <20090212030227.GA4859@suse.de> (raw)
In-Reply-To: <20090212025655.GA6916@ldl.fc.hp.com>
On Wed, Feb 11, 2009 at 07:56:55PM -0700, Alex Chiang wrote:
> * Greg KH <gregkh@suse.de>:
> > On Wed, Feb 11, 2009 at 01:26:01PM -0700, Alex Chiang wrote:
> > > Give a better clue about where we might be creating duplicate
> > > files by displaying the parent's name as well.
> > >
> > > Signed-off-by: Alex Chiang <achiang@hp.com>
> > > ---
> > > It would be nice to get a full path, but simply printing out the
> > > parent is cheap and more useful than what we have now.
> >
> > What happens if you don't have a parent? will this oops if you are
> > creating a duplicate device in the root of the sysfs tree?
>
> We won't oops because if you attempt to create a device in the
> root of the sysfs tree with a NULL parent, then we say that your
> parent is sysfs_root:
>
> int sysfs_create_dir(struct kobject * kobj)
> {
> ...
> if (kobj->parent)
> parent_sd = kobj->parent->sd;
> else
> parent_sd = &sysfs_root;
> ...
>
> But I do notice that we're not giving sysfs_root a name, so if
> you do hit the WARN for a duplicate entry in sysfs_root, you get
> a blank string for the location of the duplicate.
>
> How about this instead?
>
> From: Alex Chiang <achiang@hp.com>
>
> sysfs: give sysfs_root a proper name; display parent in duplicate entry WARN
>
> Name sysfs_root "/".
>
> Make sysfs_add_one tell you _where_ you're attempting to create a
> duplicate file to help debug.
>
> Giving sysfs_root a proper name covers the case when trying to
> create multiple entries with the same name in the root of the
> sysfs tree.
>
> Signed-off-by: Alex Chiang <achiang@hp.com>
> ---
> Still would be nicer to get a full path.
It would, and you _almost_ might be able to get it, but it might take
some work. We do store the last sysfs file accessed, and can compute
the path of that as we have a struct file * to play with. You could
walk the tree of devices backwards to reconstruct the full path to
emulate this if you want to.
> I think that in the context of a sysfs WARN, claiming that you're
> trying to create a duplicate file in "/" really means "/sys" and
> shouldn't be confusing. Sample output:
While you and I mount sysfs at /sys/ and it is the "expected" place for
it to be, we shouldn't just assume that is where it is in the
filesystem, especially as I don't where the container people are placing
sysfs.
> sysfs: duplicate filename 'alex' can not be created in /
>
> This maybe wants to be 2 patches, and I can split it up that way
> if you prefer.
Sure, that would probably be best.
thanks,
greg k-h
next prev parent reply other threads:[~2009-02-12 3:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 20:26 [PATCH] sysfs: sysfs_add_one tells you _where_ the duplicate file is Alex Chiang
2009-02-11 22:39 ` Greg KH
2009-02-12 2:56 ` Alex Chiang
2009-02-12 3:02 ` Greg KH [this message]
2009-02-12 7:02 ` Alex Chiang
2009-02-12 9:05 ` Kay Sievers
2009-02-12 16:02 ` Greg KH
2009-02-12 17:38 ` Alex Chiang
2009-02-12 17:41 ` Greg KH
2009-02-12 17:56 ` Alex Chiang
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=20090212030227.GA4859@suse.de \
--to=gregkh@suse.de \
--cc=achiang@hp.com \
--cc=linux-kernel@vger.kernel.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