On 14:36 Thu 04 Oct , Baruch Siach wrote: > Hi Peter, Ezequiel, Thomas, > > On Thu, Oct 04, 2012 at 08:38:32AM +0200, Peter Korsgaard wrote: > > >>>>> "Ezequiel" == Ezequiel Garcia <elezegar...@gmail.com> writes: > > > > Hi, > > > > >> Still it doesn't make this driver really useful as a template. The best > > >> templates are quite certainly the existing drivers in drivers/<foo>/, > > >> where <foo> in the subsystem you are writing a driver for. > > > > Ezequiel> To add some value to this argument, video4linux subsystem has > > Ezequiel> a couple of template drivers -fully maintained- called vivi > > Ezequiel> and mem2mem_testdev. > > > > Ezequiel> These are the starting point of any v4l developer. > > > > Ezequiel> Adding more drivers like these to other subsystems > > Ezequiel> -mainlined, of course- would be more worthy than maintaining > > Ezequiel> a general template of them off-tree. > > > > I agree. It needs to be focused on the specific subsystem and not > > something trying to do everything. > > The question remains whether there is a place for demo code of basic Linux > driver development mechanisms and concepts when treated by themselves, and > not > as part of a specific subsystem? Or is the existing body of code under > drivers/ enough? > > The problem I see with the subsystem only approach is that basic mechanisms > don't get the attention they need. Apart from the excellent (and increasingly > becoming outdated) book of Linux Device Drivers (which also includes the demo > scull driver that Tim has mentioned), I'm not aware of demo code we can point > kernel newbies at, that explains the basic ingredients of a kernel driver. > > Here is a list of the concepts that I'm thinking of (most of which are > covered > in Constantine's driver template): > > 1. interrupt handling > 2. tasklets > 3. work queues > 4. completion > 5. kfifo > 6. kthread > 7. timers > 8. locking primitives > 9. linked lists > 10. debugfs > 11. kernel module > 12. probe > 13. instance private state struct honestly just point at drivers already implenmenting it
they are maintained and wrote by maintainers with history so people can follow the evolution across version out of tree example is a non sense as the kernel evolve too nuch and such code are not review by people. And today the kernel evolve so much with the DT support that such effort (out of tree) is a waste of time. > > In my opinion, there is a place in the mainline kernel for a live, constantly > evolving, body of code serving as demo for the above listed and other > relevant > concepts. who is going to maintain it? if no one do so and we have to maintain it I'll drop it and concetrate on real drivers Best Regards, J. _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
