From: Kay Sievers <kay.sievers@vrfy.org>
To: Peter Osterlund <petero2@telia.com>
Cc: Greg KH <greg@kroah.com>, Nix <nix@esperi.org.uk>,
linux-kernel@vger.kernel.org, a.zummo@towertech.it
Subject: Re: pktcdvd -> sysfs warning with 2.6.27
Date: Tue, 14 Oct 2008 11:20:41 +0200 [thread overview]
Message-ID: <1223976041.5394.6.camel@nga.site> (raw)
In-Reply-To: <ac3eb2510810140138u438b3935ia134fe8e5dbb795a@mail.gmail.com>
On Tue, 2008-10-14 at 10:38 +0200, Kay Sievers wrote:
> On Tue, Oct 14, 2008 at 7:27 AM, Peter Osterlund <petero2@telia.com> wrote:
> > Greg KH <greg@kroah.com> writes:
> >
> >> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
> >>> On 12 Oct 2008, Greg KH uttered the following:
> >>> > Perhaps some other kernel code is registering with that same major/minor
> >>> > number, making it already present in sysfs. Where does that sysfs file
> >>> > link to before you load your driver?
> >>>
> >>> Exactly so. This is probably *not* a regression after all: the only
> >>> change I made to my 2.6.27 config (weeks before actually rebooting, so I
> >>> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
> >>> make hrtimers work on this old hardware (I knew it was hopeless but
> >>> tried anyway). (Unsurprisingly it didn't work:
> >>> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
> >>> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
> >>> and several of my programs are happier!)
> >>>
> >>> And, looky here, a smoking gun:
> >>>
> >>> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
> >>> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
> >>> hades:~# ls -l
> >>> lrwxrwxrwx 1 root root 4 2008-10-13 21:57 /dev/rtc -> rtc0
> >>> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
> >>>
> >>> hades:~# pktsetup cdrw /dev/cdrw
> >>> hades:~# ls -l /dev/pktcdvd/
> >>> total 0
> >>> brw-r----- 1 root root 254, 0 2008-10-13 22:23 cdrw
> >>> crw-r--r-- 1 root root 10, 63 2008-10-13 21:57 control
> >>> brw-rw---- 1 root cdrom 254, 0 2008-10-13 22:23 pktcdvd0
> >>>
> >>> Am I right in assuming that this sort of isn't going to work? :)
> >>
> >> Yes, you are right :)
> >
> > I don't think so. One is a character device and the other is a block
> > device. Block devices didn't use to collide with character devices.
> > Has that changed recently?
>
> No, that's still true.
>
> >>> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
> >>> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
> >>> former in particular has been in the kernel for years.
> >>
> >> Both of those should get "real" majors assigned to them. It's not ok to
> >> randomly go grabbing major:minor numbers like this for code that is in
> >> mainline.
> >
> > It's not about random grabbing. It's about getting a dynamically
> > assigned number. The pktcdvd driver once had static numbers, but at
> > the time when the driver was merged into the mainline kernel, dynamic
> > numbers were considered better. Therefore I changed the driver to use
> > dynamic numbers.
>
> The pktcdvd driver allocates a dynamic block major, which is fine. But
> doesn't it use the same number, and now not allocated, for the char
> devices it uses? That looks like something that needs to fixed, right?
>
> static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
> {
> if (class_pktcdvd) {
> pd->dev = device_create_drvdata(class_pktcdvd, NULL,
> pd->pkt_dev, NULL,
> "%s", pd->name);
Something similar to this, with error checking, might be needed. It has
two independent majors now in block and char:
$ grep pkt /proc/devices
251 pktcdvd-char
252 pktcdvd
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 29b7a64..07dd157 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -86,6 +86,7 @@
static struct pktcdvd_device *pkt_devs[MAX_WRITERS];
static struct proc_dir_entry *pkt_proc;
static int pktdev_major;
+static int pktdev_char_major;
static int write_congestion_on = PKT_WRITE_CONGESTION_ON;
static int write_congestion_off = PKT_WRITE_CONGESTION_OFF;
static struct mutex ctl_mutex; /* Serialize open/close/setup/teardown */
@@ -301,9 +302,11 @@ static struct kobj_type kobj_pkt_type_wqueue = {
static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
{
+ dev_t devno = MKDEV(pktdev_char_major, MINOR(pd->pkt_dev));
+
if (class_pktcdvd) {
pd->dev = device_create_drvdata(class_pktcdvd, NULL,
- pd->pkt_dev, NULL,
+ devno, NULL,
"%s", pd->name);
if (IS_ERR(pd->dev))
pd->dev = NULL;
@@ -320,10 +323,12 @@ static void pkt_sysfs_dev_new(struct pktcdvd_device *pd)
static void pkt_sysfs_dev_remove(struct pktcdvd_device *pd)
{
+ dev_t devno = MKDEV(pktdev_char_major, MINOR(pd->pkt_dev));
+
pkt_kobj_remove(pd->kobj_stat);
pkt_kobj_remove(pd->kobj_wqueue);
if (class_pktcdvd)
- device_destroy(class_pktcdvd, pd->pkt_dev);
+ device_destroy(class_pktcdvd, devno);
}
@@ -3067,6 +3072,7 @@ static struct miscdevice pkt_misc = {
static int __init pkt_init(void)
{
int ret;
+ dev_t devno;
mutex_init(&ctl_mutex);
@@ -3083,6 +3089,9 @@ static int __init pkt_init(void)
if (!pktdev_major)
pktdev_major = ret;
+ alloc_chrdev_region(&devno, 0, 255, "pktcdvd-char");
+ pktdev_char_major = MAJOR(devno);
+
ret = pkt_sysfs_init();
if (ret)
goto out;
@@ -3117,6 +3126,8 @@ static void __exit pkt_exit(void)
pkt_debugfs_cleanup();
pkt_sysfs_cleanup();
+ unregister_chrdev_region(MKDEV(pktdev_char_major, 0), 255);
+
unregister_blkdev(pktdev_major, DRIVER_NAME);
mempool_destroy(psd_pool);
}
next prev parent reply other threads:[~2008-10-14 9:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 12:26 pktcdvd -> sysfs warning with 2.6.27 Nix
2008-10-12 18:17 ` Greg KH
2008-10-12 20:25 ` Nix
2008-10-12 22:18 ` Greg KH
2008-10-12 22:36 ` Nix
2008-10-13 10:27 ` Philip Martin
2008-10-13 21:28 ` Nix
2008-10-13 21:47 ` Greg KH
2008-10-13 22:01 ` Alessandro Zummo
2008-10-13 22:03 ` Nix
2008-10-14 5:27 ` Peter Osterlund
2008-10-14 8:38 ` Kay Sievers
2008-10-14 9:20 ` Kay Sievers [this message]
2008-10-14 19:53 ` Peter Osterlund
2008-10-14 22:32 ` Kay Sievers
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=1223976041.5394.6.camel@nga.site \
--to=kay.sievers@vrfy.org \
--cc=a.zummo@towertech.it \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nix@esperi.org.uk \
--cc=petero2@telia.com \
/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.