looking for simple module/driver programming examples in source tree

looking for simple module/driver programming examples in source tree

[Robert P. J. Day]

  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
========================================================================

looking for simple module/driver programming examples in source tree

[Greg KH]

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

looking for simple module/driver programming examples in source tree

[Robert P. J. Day]

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
========================================================================

looking for simple module/driver programming examples in source tree

[Greg KH]

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

looking for simple module/driver programming examples in source tree

[Robert P. J. Day]

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
========================================================================

looking for simple module/driver programming examples in source tree

[Mandeep Sandhu]

>> > ? 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

looking for simple module/driver programming examples in source tree

[Robert P. J. Day]

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
========================================================================

looking for simple module/driver programming examples in source tree

[Mandeep Sandhu]

> 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

looking for simple module/driver programming examples in source tree

[Greg KH]

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

looking for simple module/driver programming examples in source tree

[Javier Martinez Canillas]

>
>> ? 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

looking for simple module/driver programming examples in source tree

[anish singh]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110503/cbb2e213/attachment-0001.html