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




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