How does /sys/dev/char get populated in Linux?










1















I'm learning to write a simple kernel module that implements open, read, write, close, ioctl syscalls for reading/writing in kernel memory (something like a shared memory / IPC demo).



I used to call mknod for binding the major/minor number allocated by the driver with a character file. But I questioned myself about why we aren't always required to manually do so when we attach an USB pendrive to the system, and I discovered udev.



I know how to use kobject_init_and_add() and kobject_uevent() to create a node in sysfs tree and notify udev, but while exploring /sys folder I noticed the /sys/dev/char folder, that contains symlinks to devices, named like major:minor. I don't understand why I can't find here the major/minor couple of my driver... Am I supposed to manually do something else from inside the module?



How can I find a full-but-simple example on how to properly describe and handle my "virtual" device in the sysfs tree?










share|improve this question




























    1















    I'm learning to write a simple kernel module that implements open, read, write, close, ioctl syscalls for reading/writing in kernel memory (something like a shared memory / IPC demo).



    I used to call mknod for binding the major/minor number allocated by the driver with a character file. But I questioned myself about why we aren't always required to manually do so when we attach an USB pendrive to the system, and I discovered udev.



    I know how to use kobject_init_and_add() and kobject_uevent() to create a node in sysfs tree and notify udev, but while exploring /sys folder I noticed the /sys/dev/char folder, that contains symlinks to devices, named like major:minor. I don't understand why I can't find here the major/minor couple of my driver... Am I supposed to manually do something else from inside the module?



    How can I find a full-but-simple example on how to properly describe and handle my "virtual" device in the sysfs tree?










    share|improve this question


























      1












      1








      1








      I'm learning to write a simple kernel module that implements open, read, write, close, ioctl syscalls for reading/writing in kernel memory (something like a shared memory / IPC demo).



      I used to call mknod for binding the major/minor number allocated by the driver with a character file. But I questioned myself about why we aren't always required to manually do so when we attach an USB pendrive to the system, and I discovered udev.



      I know how to use kobject_init_and_add() and kobject_uevent() to create a node in sysfs tree and notify udev, but while exploring /sys folder I noticed the /sys/dev/char folder, that contains symlinks to devices, named like major:minor. I don't understand why I can't find here the major/minor couple of my driver... Am I supposed to manually do something else from inside the module?



      How can I find a full-but-simple example on how to properly describe and handle my "virtual" device in the sysfs tree?










      share|improve this question
















      I'm learning to write a simple kernel module that implements open, read, write, close, ioctl syscalls for reading/writing in kernel memory (something like a shared memory / IPC demo).



      I used to call mknod for binding the major/minor number allocated by the driver with a character file. But I questioned myself about why we aren't always required to manually do so when we attach an USB pendrive to the system, and I discovered udev.



      I know how to use kobject_init_and_add() and kobject_uevent() to create a node in sysfs tree and notify udev, but while exploring /sys folder I noticed the /sys/dev/char folder, that contains symlinks to devices, named like major:minor. I don't understand why I can't find here the major/minor couple of my driver... Am I supposed to manually do something else from inside the module?



      How can I find a full-but-simple example on how to properly describe and handle my "virtual" device in the sysfs tree?







      linux linux-kernel kernel driver kernel-module






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 15 '18 at 17:30







      Patrick Roncagliolo

















      asked Nov 14 '18 at 20:54









      Patrick RoncaglioloPatrick Roncagliolo

      133212




      133212






















          1 Answer
          1






          active

          oldest

          votes


















          2














          After reading Chapter 4 of "Linux device driver development" by John Madieu, I discovered that it was easier than what I thought:



          all you need in order to automatically instantiate the proper character device abstractions in /sys and /dev is to create a struct class with the help of class_create(...) function, and then use device_create(...).



          Effects:
          assuming you have a class called my_class and call the device my_device with major number xx and minor number yy,




          • /sys/class/my_class folder is created;


          • /sys/devices/virtual/my_class/my_device folder is created;


          • /sys/class/my_class/my_device symlink points to /sys/class/my_class/my_device;


          • /sys/dev/char/xx:yy symlink points to /sys/class/my_class/my_device;


          • /dev/my_device character device is created (so no more mknod calls);

          The /sys/class/my_class/my_device folder is quite interesting. It has:




          • dev file: it contains major:minor number;


          • uevent file: if you write add in it, the kernel will re-emit add uevents; uevents are used to signal a userspace daemon like udev about creation/modification/removal of a kernel object in the sysfs tree;


          • subsystem symlink: it points back to /sys/class/my_class;


          • power folder: probably some interfaces for stuff like this.

          Always remember to match every *_create call with a *destroy call in the exit function of the module.



          class_create, class_destroy, device_create, device_destroy are declared in include/linux/device.h and defined respectively in drivers/base/class.c and drivers/base/core.c (paths in kernel source tree). There's good documentation in those source files.






          share|improve this answer
























            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308573%2fhow-does-sys-dev-char-get-populated-in-linux%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            After reading Chapter 4 of "Linux device driver development" by John Madieu, I discovered that it was easier than what I thought:



            all you need in order to automatically instantiate the proper character device abstractions in /sys and /dev is to create a struct class with the help of class_create(...) function, and then use device_create(...).



            Effects:
            assuming you have a class called my_class and call the device my_device with major number xx and minor number yy,




            • /sys/class/my_class folder is created;


            • /sys/devices/virtual/my_class/my_device folder is created;


            • /sys/class/my_class/my_device symlink points to /sys/class/my_class/my_device;


            • /sys/dev/char/xx:yy symlink points to /sys/class/my_class/my_device;


            • /dev/my_device character device is created (so no more mknod calls);

            The /sys/class/my_class/my_device folder is quite interesting. It has:




            • dev file: it contains major:minor number;


            • uevent file: if you write add in it, the kernel will re-emit add uevents; uevents are used to signal a userspace daemon like udev about creation/modification/removal of a kernel object in the sysfs tree;


            • subsystem symlink: it points back to /sys/class/my_class;


            • power folder: probably some interfaces for stuff like this.

            Always remember to match every *_create call with a *destroy call in the exit function of the module.



            class_create, class_destroy, device_create, device_destroy are declared in include/linux/device.h and defined respectively in drivers/base/class.c and drivers/base/core.c (paths in kernel source tree). There's good documentation in those source files.






            share|improve this answer





























              2














              After reading Chapter 4 of "Linux device driver development" by John Madieu, I discovered that it was easier than what I thought:



              all you need in order to automatically instantiate the proper character device abstractions in /sys and /dev is to create a struct class with the help of class_create(...) function, and then use device_create(...).



              Effects:
              assuming you have a class called my_class and call the device my_device with major number xx and minor number yy,




              • /sys/class/my_class folder is created;


              • /sys/devices/virtual/my_class/my_device folder is created;


              • /sys/class/my_class/my_device symlink points to /sys/class/my_class/my_device;


              • /sys/dev/char/xx:yy symlink points to /sys/class/my_class/my_device;


              • /dev/my_device character device is created (so no more mknod calls);

              The /sys/class/my_class/my_device folder is quite interesting. It has:




              • dev file: it contains major:minor number;


              • uevent file: if you write add in it, the kernel will re-emit add uevents; uevents are used to signal a userspace daemon like udev about creation/modification/removal of a kernel object in the sysfs tree;


              • subsystem symlink: it points back to /sys/class/my_class;


              • power folder: probably some interfaces for stuff like this.

              Always remember to match every *_create call with a *destroy call in the exit function of the module.



              class_create, class_destroy, device_create, device_destroy are declared in include/linux/device.h and defined respectively in drivers/base/class.c and drivers/base/core.c (paths in kernel source tree). There's good documentation in those source files.






              share|improve this answer



























                2












                2








                2







                After reading Chapter 4 of "Linux device driver development" by John Madieu, I discovered that it was easier than what I thought:



                all you need in order to automatically instantiate the proper character device abstractions in /sys and /dev is to create a struct class with the help of class_create(...) function, and then use device_create(...).



                Effects:
                assuming you have a class called my_class and call the device my_device with major number xx and minor number yy,




                • /sys/class/my_class folder is created;


                • /sys/devices/virtual/my_class/my_device folder is created;


                • /sys/class/my_class/my_device symlink points to /sys/class/my_class/my_device;


                • /sys/dev/char/xx:yy symlink points to /sys/class/my_class/my_device;


                • /dev/my_device character device is created (so no more mknod calls);

                The /sys/class/my_class/my_device folder is quite interesting. It has:




                • dev file: it contains major:minor number;


                • uevent file: if you write add in it, the kernel will re-emit add uevents; uevents are used to signal a userspace daemon like udev about creation/modification/removal of a kernel object in the sysfs tree;


                • subsystem symlink: it points back to /sys/class/my_class;


                • power folder: probably some interfaces for stuff like this.

                Always remember to match every *_create call with a *destroy call in the exit function of the module.



                class_create, class_destroy, device_create, device_destroy are declared in include/linux/device.h and defined respectively in drivers/base/class.c and drivers/base/core.c (paths in kernel source tree). There's good documentation in those source files.






                share|improve this answer















                After reading Chapter 4 of "Linux device driver development" by John Madieu, I discovered that it was easier than what I thought:



                all you need in order to automatically instantiate the proper character device abstractions in /sys and /dev is to create a struct class with the help of class_create(...) function, and then use device_create(...).



                Effects:
                assuming you have a class called my_class and call the device my_device with major number xx and minor number yy,




                • /sys/class/my_class folder is created;


                • /sys/devices/virtual/my_class/my_device folder is created;


                • /sys/class/my_class/my_device symlink points to /sys/class/my_class/my_device;


                • /sys/dev/char/xx:yy symlink points to /sys/class/my_class/my_device;


                • /dev/my_device character device is created (so no more mknod calls);

                The /sys/class/my_class/my_device folder is quite interesting. It has:




                • dev file: it contains major:minor number;


                • uevent file: if you write add in it, the kernel will re-emit add uevents; uevents are used to signal a userspace daemon like udev about creation/modification/removal of a kernel object in the sysfs tree;


                • subsystem symlink: it points back to /sys/class/my_class;


                • power folder: probably some interfaces for stuff like this.

                Always remember to match every *_create call with a *destroy call in the exit function of the module.



                class_create, class_destroy, device_create, device_destroy are declared in include/linux/device.h and defined respectively in drivers/base/class.c and drivers/base/core.c (paths in kernel source tree). There's good documentation in those source files.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 15 '18 at 17:25

























                answered Nov 15 '18 at 16:25









                Patrick RoncaglioloPatrick Roncagliolo

                133212




                133212





























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308573%2fhow-does-sys-dev-char-get-populated-in-linux%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Darth Vader #20

                    How to how show current date and time by default on contact form 7 in WordPress without taking input from user in datetimepicker

                    Ondo