From: Kay Sievers <kay.sievers@vrfy.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Greg KH <greg@kroah.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH mm] sysfs: add /sys/dev/usb to handle CONFIG_USB_DEVICE_CLASS=y
Date: Fri, 18 Apr 2008 09:54:51 +0200 [thread overview]
Message-ID: <1208505291.2514.9.camel@lov.site> (raw)
In-Reply-To: <e9c3a7c20804172159x16554078i6d5c9097eeadc91c@mail.gmail.com>
On Thu, 2008-04-17 at 21:59 -0700, Dan Williams wrote:
> On Thu, Apr 17, 2008 at 8:21 PM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Apr 17, 2008 at 07:11:03PM -0700, Dan Williams wrote:
> >
> > > The deprecated config option CONFIG_USB_DEVICE_CLASS causes class devices
> > > with duplicate major:minor numbers to be registered. In effect they
> > > represent a usb specific address space for major:minor numbers so add 'usb'
> > > as a directory along side 'block' and 'char'.
> >
> > Hm, no they do not, they are not a new address space, we are just
> > reusing them as the other user wasn't using them, and the code is
> > deprecated and will be removed eventually. Neither of these char
> > devices are really hooked up to anything within the kernel, so it
> > doesn't matter yet.
> >
> > I wonder how many other duplicates we have floating around...
> >
>
> Hm, so how about making this an opt-in capability of the class? At
> device_add() time the class is queried to see if a link should be
> created in /sys/dev/block or /sys/dev/char?
This could work, yes. We could just set a flag in the class, that
prevents the device entries in /sys/dev/.
> Although, this leads to
> inconsistent coverage. But maybe that does not matter as many of
> these character devices do not have interesting attributes to be
> accessed?
The usual case is that one of the duplicated /sys devices is deprecated,
so it should be fine, to always point to the new one.
> Sigh, I am beginning to wonder if the character device side
> of this capability is a solution looking for a problem...
We will find a solution. :)
The following should work for the common case.
Best,
Kay
From: Kay Sievers <kay.sievers@vrfy.org>
Subject: sysfs: fix duplicated device number registration in /sys/dev/
If the parent device has the same dev_t, we skip the registration
for the device number at /sys/dev.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
core.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index de925f8..afedadb 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -821,10 +821,13 @@ int device_add(struct device *dev)
if (error)
goto ueventattrError;
- format_dev_t(devt_str, dev->devt);
- error = sysfs_create_link(kobj, &dev->kobj, devt_str);
- if (error)
- goto devtattrError;
+ /* do not create /sys/dev/ entry if parent already did */
+ if (!(dev->parent && dev->parent->devt == dev->devt)) {
+ format_dev_t(devt_str, dev->devt);
+ error = sysfs_create_link(kobj, &dev->kobj, devt_str);
+ if (error)
+ goto devtattrError;
+ }
}
error = device_add_class_symlinks(dev);
@@ -950,8 +953,10 @@ void device_del(struct device *dev)
if (parent)
klist_del(&dev->knode_parent);
if (MAJOR(dev->devt)) {
- format_dev_t(devt_str, dev->devt);
- sysfs_remove_link(device_to_dev_kobj(dev), devt_str);
+ if (!(parent && parent->devt == dev->devt)) {
+ format_dev_t(devt_str, dev->devt);
+ sysfs_remove_link(device_to_dev_kobj(dev), devt_str);
+ }
device_remove_file(dev, &devt_attr);
}
if (dev->class) {
next prev parent reply other threads:[~2008-04-18 7:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 2:11 [PATCH mm] sysfs: add /sys/dev/usb to handle CONFIG_USB_DEVICE_CLASS=y Dan Williams
2008-04-18 3:00 ` Greg KH
2008-04-18 3:08 ` Andrew Morton
2008-04-18 3:44 ` Dan Williams
2008-04-18 3:21 ` Greg KH
2008-04-18 4:59 ` Dan Williams
2008-04-18 7:54 ` Kay Sievers [this message]
2008-04-18 16:37 ` Dan Williams
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=1208505291.2514.9.camel@lov.site \
--to=kay.sievers@vrfy.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@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 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.