Hi Constantine, On Tue, Oct 02, 2012 at 01:01:51AM +0200, Constantine Shulyupin wrote: > You got the main idea. It is supposed to be best practices example. > I am not sure that it is need to be mainlined , because: > 1. Its is more difficult to maintain it in the mainline.
How so? From my experience maintaining a driver becomes easier once the driver is in the mainline code, since API changes are applied to all in-tree code, including your driver. Having an always current driver is another benefit from having your driver in the mainline kernel. This would allow you to do away with backwards compatibility cruft to support older kernel versions, and make it easier to extend the driver to demo newer subsystems/methods/APIs as they are integrated into the kernel. Each kernel includes a driver version that is optimized for the current kernel version. > 2. The driver works with demo application and test script, which can't > be efficiently mainlined. You can put the testing code under the tools/testing/selftests/ directory, which already contains userspace C and shell code for specific subsystems and features. > I haven’t tried to mainline it. > > I would expect more feedback from other developers to make it real > best practices example. You'll get high quality feedback from kernel developers responding to your patch. A proper patch is the only way to get the attention of kernel developers. I glanced over the driver and I have few quick comments: 1. Symbols that are for local use only should be declared static (e.g. fifo_lock, ldt_received, ldt_send, ldt_tasklet_func, ldt_tasklet). 2. Drives should be able to handle multiple devices of the same type. That's why most drivers define a local struct, and allocate one struct per device at probe time to keeps its state. I think that a template driver should reflect this common practice. 3. Maintaining private debugging wrappers (tracef, trlm, trv, etc.) is usually frowned upon in the mainline kernel. This also goes against the goal of being a demo driver. I think that a template driver in the mainline kernel would be a great contribution to the kernel. Good luck, baruch > On Tue, Oct 2, 2012 at 12:26 AM, Tim Bird <tim.b...@am.sony.com> wrote: > > On 10/1/2012 4:43 AM, Constantine Shulyupin wrote: > >> > >> Hi, > >> I develop LDT - Linux Driver Template. It can used as starting pint of > >> development custom device driver and for learning development of Linux > >> device drivers. > >> > >> Documentation: https://github.com/makelinux/ldt/blob/master/README.md > >> > >> The driver uses following Linux facilities: module, platform driver, > >> file operations (read/write, mmap, ioctl, blocking and nonblocking > >> mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, > >> timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, > >> ftracer. > >> > >> To test the driver just run > >> git clone git://github.com/makelinux/ldt.git&& cd ldt&& ./ldt-test > >> > >> > >> You feedback, suggestions, discussions, recommendations patched will > >> be greatly appreciated! > >> > > I don't write many drivers, but this seems like it's very useful > > as example code. I think there might even be value in mainlining > > it. In my opinion, a lot of copy-and-paste happens in kernel > > development, but it's hard to know if the code being copied > > really implements the "best practices" for using the different > > facilities and APIs in the kernel. (I was disappointed when > > I found out that the scull device driver sample from the > > Linux Device Drivers book wasn't mainlined.) > > > > Have you tried to mainline this? > > > > Whether it gets mainlined or not, it's probably worth referencing > > as example code. Maybe we should put up a wiki page directing > > people to it? > > -- Tim -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
