looking for simple module/driver programming examples in source tree
as a followup to an earlier post, this is kind of a nebulous proposal but i want to start collecting examples out of the kernel source tree that demonstrate a lot of the basic or introductory kernel programming concepts. with some of the courseware i deal with, there's typically a perfectly reasonable explanation for numerous introductory concepts and topics, but none of that beats being accompanied by an actual example right out of the source. for example, i can explain in detail how to write a simple, read-only proc file, or i can just point at some terrific examples in the fs/proc directory, such as version.c: === snip header files === static int version_proc_show(struct seq_file *m, void *v) { seq_printf(m, linux_proc_banner, utsname()->sysname, utsname()->release, utsname()->version); return 0; } static int version_proc_open(struct inode *inode, struct file *file) { return single_open(file, version_proc_show, NULL); } static const struct file_operations version_proc_fops = { .open = version_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static int __init proc_version_init(void) { proc_create("version", 0, NULL, &version_proc_fops); return 0; } module_init(proc_version_init); === end version.c === once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file? as another example, we all know that if your module init() routine runs into an error, it has an obligation to carefully (and, typically, in reverse order) undo everything it's done up to that point. sometimes, that routine is loaded with "goto" stmts. other times, the module author might create a "cleanup" routine that is callable from both the init and exit routines. i'm currently perusing the source for nice, uncluttered examples of exactly that (where the explanation isn't buried under extraneous processing to the point where it's hard to see the relevant code). and the list goes on and on -- there are assuredly all sorts of source files for drivers that can be used as respectable examples of all sorts of *introductory* concepts. i'm also interesting in collecting examples of documentation for basic kernel programming concepts. sometimes, there are excellent examples in the source Documentation/ directory, sometimes not. or there might be high-quality tutorials at places like lwn.net, developerworks, and lots of other places. i'm interested in starting a list of tutorials like that that explain, ideally, a single topic really, really well for the sake of beginners. thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Tue, May 03, 2011 at 07:45:54AM -0400, Robert P. J. Day wrote:
once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file?
You need to know that if your module/driver ever creates a simple read-only proc file, they will be flamed to a crisp on lkml when they submit it :) Seriously, don't ever create a new proc file, it's not anything anyone should ever be doing anymore.
i'm also interesting in collecting examples of documentation for basic kernel programming concepts. sometimes, there are excellent examples in the source Documentation/ directory, sometimes not.
The kobject documentation should be good, and there are examples in the samples/ directory in the kernel that should be a great place to start. Also look at drivers/usb/usb-skeleton.c for an example usb driver. It is a bit complex, but then again, it's a real-world one so that's needed in places. hope this helps, greg k-h
On Tue, 3 May 2011, Greg KH wrote:
On Tue, May 03, 2011 at 07:45:54AM -0400, Robert P. J. Day wrote:
once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file?
You need to know that if your module/driver ever creates a simple read-only proc file, they will be flamed to a crisp on lkml when they submit it :)
Seriously, don't ever create a new proc file, it's not anything anyone should ever be doing anymore.
so have proc/seq file been massively deprecated in favour of sysfs attribute files, then? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Tue, May 03, 2011 at 08:38:48AM -0400, Robert P. J. Day wrote:
On Tue, 3 May 2011, Greg KH wrote:
On Tue, May 03, 2011 at 07:45:54AM -0400, Robert P. J. Day wrote:
once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file?
You need to know that if your module/driver ever creates a simple read-only proc file, they will be flamed to a crisp on lkml when they submit it :)
Seriously, don't ever create a new proc file, it's not anything anyone should ever be doing anymore.
so have proc/seq file been massively deprecated in favour of sysfs attribute files, then?
Yes, that happened about 8 years ago :) No driver should ever add a proc file, it's that simple. thanks, greg k-h
On Tue, 3 May 2011, Greg KH wrote:
On Tue, May 03, 2011 at 08:38:48AM -0400, Robert P. J. Day wrote:
On Tue, 3 May 2011, Greg KH wrote:
On Tue, May 03, 2011 at 07:45:54AM -0400, Robert P. J. Day wrote:
once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file?
You need to know that if your module/driver ever creates a simple read-only proc file, they will be flamed to a crisp on lkml when they submit it :)
Seriously, don't ever create a new proc file, it's not anything anyone should ever be doing anymore.
so have proc/seq file been massively deprecated in favour of sysfs attribute files, then?
Yes, that happened about 8 years ago :)
No driver should ever add a proc file, it's that simple.
oh, i was aware that the preference was for sysfs attr files. i just didn't realize it was that stringent. thanks. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
so have proc/seq file been massively deprecated in favour of sysfs attribute files, then?
Yes, that happened about 8 years ago :)
No driver should ever add a proc file, it's that simple.
oh, i was aware that the preference was for sysfs attr files. i just didn't realize it was that stringent. thanks.
I think the 'strictness' comes from the fact the /proc system was heavily abused for dumping just about any info into it (in the early days 2.4 kernel, I think). /proc was originally meant for putting 'process' specific info (thats why the name - proc) and not for device drivers. CMIIW. sysfs is a dedicated place for device drivers to export info to userland. HTH, -mandeep
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 3 May 2011, Mandeep Sandhu wrote:
so have proc/seq file been massively deprecated in favour of sysfs attribute files, then?
Yes, that happened about 8 years ago :)
No driver should ever add a proc file, it's that simple.
oh, i was aware that the preference was for sysfs attr files. i just didn't realize it was that stringent. thanks.
I think the 'strictness' comes from the fact the /proc system was heavily abused for dumping just about any info into it (in the early days 2.4 kernel, I think).
/proc was originally meant for putting 'process' specific info (thats why the name - proc) and not for device drivers. CMIIW.
sysfs is a dedicated place for device drivers to export info to userland.
and i can accept that. i'm still going to cover (briefly) how /proc files work simply because there's a lot of them and i don't see them going away any time soon, but i'll emphasize that they are a bad thing for new drivers. rday p.s. on that note, of course, i'm interested in really simple examples of drivers that create increasingly complex collections of sysfs attr files. i *really* like to explain stuff like this by being able to point at existing drivers in the tree. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
p.s. on that note, of course, i'm interested in really simple examples of drivers that create increasingly complex collections of sysfs attr files. i *really* like to explain stuff like this by being able to point at existing drivers in the tree.
Giving 'real' examples will surely help drive home a point! :) Good luck. I'll be looking fwd to your tutorials! :) Regards, -mandeep
On Tue, May 03, 2011 at 09:44:47AM -0400, Robert P. J. Day wrote:
p.s. on that note, of course, i'm interested in really simple examples of drivers that create increasingly complex collections of sysfs attr files. i *really* like to explain stuff like this by being able to point at existing drivers in the tree.
Any of the sensor drivers would be good examples of this, they create loads of sysfs files. Also please explain that _any_ new sysfs or file that is added, a corresponding Documentation/ABI/ file needs to be also added. thanks, greg k-h
i'm also interesting in collecting examples of documentation for basic kernel programming concepts. sometimes, there are excellent examples in the source Documentation/ directory, sometimes not.
I think a useful work would be to keep an up-to-date version for the example drivers found in Linux Device Drivers 3. Despite being a few years old, the book is a valuable source of information regarding kernel drivers development. There are lots of repositories with examples updated to many kernel versions. A few months ago I needed the examples updated to 2.6.32 and found repositories for older kernels. I sent a few patches to the author of the most up-to-date repository I found (I think It was 2.6.28) but didn't have any feedback so I (also) started my own git tree with examples to kernel versions 2.6.32, 2.6.35 and 2.6.38. Maybe instead having so many repositories all over the Internet trying to do the same. It will be good to have a kernelnewbies oficial repository for virtual device drivers. These drivers can be a good starting point for someone doing real driver development (something like the usb-skeleton.c for usb drivers). Also it could be a playground for people eager to learn and start contributing with more examples. -- Javier Martínez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Autònoma de Barcelona Barcelona, Spain
On Tue, May 3, 2011 at 7:50 PM, Javier Martinez Canillas < martinez.javier@gmail.com> wrote:
i'm also interesting in collecting examples of documentation for basic kernel programming concepts. sometimes, there are excellent examples in the source Documentation/ directory, sometimes not.
I think a useful work would be to keep an up-to-date version for the example drivers found in Linux Device Drivers 3. Despite being a few years old, the book is a valuable source of information regarding kernel drivers development.
There are lots of repositories with examples updated to many kernel versions. A few months ago I needed the examples updated to 2.6.32 and found repositories for older kernels. I sent a few patches to the author of the most up-to-date repository I found (I think It was 2.6.28) but didn't have any feedback so I (also) started my own git tree with examples to kernel versions 2.6.32, 2.6.35 and 2.6.38.
Yes https://github.com/martinezjavier/ldd3 is very helpful indeed,other day someone was asking(on kernelnewbies IRC) for some examples not compiling in latest kernel and i gave this link which helped.
Maybe instead having so many repositories all over the Internet trying to do the same. It will be good to have a kernelnewbies oficial repository for virtual device drivers. These drivers can be a good starting point for someone doing real driver development (something like the usb-skeleton.c for usb drivers). Also it could be a playground for people eager to learn and start contributing with more examples.
-- Javier Martínez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Autònoma de Barcelona Barcelona, Spain
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (5)
-
anish singh -
Greg KH -
Javier Martinez Canillas -
Mandeep Sandhu -
Robert P. J. Day