Re: cdev documentation (was Drop second arg of unregister_chrdev())

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

On 8/18/06, Jonathan Corbet <corbet@lwn.net> wrote:
> Rolf Eike Beer <eike-kernel@sf-tec.de> wrote:
>
> > Nevertheless, I ported my driver to the new interface. I see it cdev_add()
> > succeeding, but the device never shows up in sysfs. Do I have to do any more
> > tricks with class devices and stuff?
>
> Yes, cdevs do not, themselves, show up in sysfs.  A simple class is what
> you want for that part of the job.
>
> > While I was sneaking around in the code I found this drivers/char/tty_io:3093
> >
> >         cdev_init(&driver->cdev, &tty_fops);
> >         driver->cdev.owner = driver->owner;
> >         error = cdev_add(&driver->cdev, dev, driver->num);
> >         if (error) {
> >                 cdev_del(&driver->cdev);
> >
> > Isn't the call to cdev_del() just wrong here?
>
> It is correct, in that it returns the reference you hold to the cdev's
> internal kobject.  If you got the cdev with cdev_alloc(), that's the
> only way it will get returned to the system.  For a cdev allocated
> elsewhere (as is the case here) it probably doesn't make any difference.

This is not a good practice though because it will attempt to unmap
device that is not mapped. Depeneding on changes in kmap code (for
example adding checks for regions being busy) blindly calling unmap
could unmap some other cdev. For dynamically allocated objects calling
kobject_put(&cdev->kobj) would be more correct but not very nice.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/