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!

Thanks
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

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

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.
2. The driver works with demo application and test script, which can't
be efficiently mainlined.

I haven’t tried to mainline it.

I would expect more feedback from other developers to make it real
best practices example.

Thanks

--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

Really nice work, thanks for myself.

I need writing drivers sometimes, but I am always googling for the facilities I need,
putting all in together is a good idea, nice start point for a complete driver.

Thank you very much!
Can you suggest something?

--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

I've created stub page http://elinux.org/Device_drivers

--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

On Tue, Oct 2, 2012 at 7:58 AM, Constantine Shulyupin
<const@...> wrote:

I've created stub page http://elinux.org/Device_drivers

Thanks, I've added the link to the mainpage.

On Tue, Oct 2, 2012 at 12:26 AM, Tim Bird <tim.bird@...> 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

--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

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.bird@...> 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------------{=
- baruch@... - tel: +972.2.679.5364, http://www.tkos.co.il -

On Wed, 3 Oct 2012 19:07:31 +0200, Baruch Siach wrote:

I think that a template driver in the mainline kernel would be a great
contribution to the kernel.

On my side, I am questioning whether this is a goal that can actually
be achieved.

In practice, Constantine driver will never be useful as a template for
any driver, for two main reasons:

* It is only showing how to write a raw character driver, while most
drivers in the kernel are integrated inside an existing subsystem,
that requires the implementation of subsystem-specific APIs (tty
subsystem, mtd subsystem, input subsystem, network subsystem, etc.).
Therefore, each of those subsystems would require a separate
template driver. And in fact some of them already have such a
template, see for example
http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c for
the framebuffer subsystem. Doing similar skeleton drivers for each
subsystem would most likely be a lot more useful.

* This driver only shows how to implement a platform driver, while
only some of the drivers are platform drivers. Many other are I2C
drivers, SPI drivers, USB drivers, PCI drivers, etc. and therefore
this template does not show any of this. Another example is that
this driver is a platform driver, but does not support the Device
Tree, which is needed on ARM, PowerPC, Microblaze and probably at
least another architecture.

Therefore the whole idea of writing a "generic template kernel driver"
is doomed to fail, as it is simply not possible.

Also, /proc entries are deprecated for drivers. No new driver should
create one. Use debugfs instead for debugging features, or possibly
sysfs if this is actually relevant.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Hi Thomas,

On Wed, Oct 03, 2012 at 08:25:16PM +0200, Thomas Petazzoni wrote:

On Wed, 3 Oct 2012 19:07:31 +0200, Baruch Siach wrote:

I think that a template driver in the mainline kernel would be a great
contribution to the kernel.

On my side, I am questioning whether this is a goal that can actually
be achieved.

In practice, Constantine driver will never be useful as a template for
any driver, for two main reasons:

* It is only showing how to write a raw character driver, while most
drivers in the kernel are integrated inside an existing subsystem,
that requires the implementation of subsystem-specific APIs (tty
subsystem, mtd subsystem, input subsystem, network subsystem, etc.).
Therefore, each of those subsystems would require a separate
template driver. And in fact some of them already have such a
template, see for example
http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c for
the framebuffer subsystem. Doing similar skeleton drivers for each
subsystem would most likely be a lot more useful.

* This driver only shows how to implement a platform driver, while
only some of the drivers are platform drivers. Many other are I2C
drivers, SPI drivers, USB drivers, PCI drivers, etc. and therefore
this template does not show any of this. Another example is that
this driver is a platform driver, but does not support the Device
Tree, which is needed on ARM, PowerPC, Microblaze and probably at
least another architecture.

Therefore the whole idea of writing a "generic template kernel driver"
is doomed to fail, as it is simply not possible.

To me the significance of this template driver is not as a demonstration of IO
operations that are, as you correctly point out, subsystem specific. This
driver uses the concepts of file operations and platform driver, I guess,
because they are easy to emulate. But these are only means to demonstrate
common driver programming patterns and mechanisms like interrupt handling,
tasklets, workqueues, completion, etc. Details like DT binding, deprecated
/proc use, as well as some other issues, are fixable in my opinion.

baruch

Also, /proc entries are deprecated for drivers. No new driver should
create one. Use debugfs instead for debugging features, or possibly
sysfs if this is actually relevant.

Best regards,

Thomas

--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@... - tel: +972.2.679.5364, http://www.tkos.co.il -

On Wed, 3 Oct 2012 22:18:43 +0200, Baruch Siach wrote:

Therefore the whole idea of writing a "generic template kernel driver"
is doomed to fail, as it is simply not possible.

To me the significance of this template driver is not as a demonstration of IO
operations that are, as you correctly point out, subsystem specific. This
driver uses the concepts of file operations and platform driver, I guess,
because they are easy to emulate. But these are only means to demonstrate
common driver programming patterns and mechanisms like interrupt handling,
tasklets, workqueues, completion, etc. Details like DT binding, deprecated
/proc use, as well as some other issues, are fixable in my opinion.

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.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On Wed, Oct 3, 2012 at 6:06 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

On Wed, 3 Oct 2012 22:18:43 +0200, Baruch Siach wrote:

Therefore the whole idea of writing a "generic template kernel driver"
is doomed to fail, as it is simply not possible.

To me the significance of this template driver is not as a demonstration of IO
operations that are, as you correctly point out, subsystem specific. This
driver uses the concepts of file operations and platform driver, I guess,
because they are easy to emulate. But these are only means to demonstrate
common driver programming patterns and mechanisms like interrupt handling,
tasklets, workqueues, completion, etc. Details like DT binding, deprecated
/proc use, as well as some other issues, are fixable in my opinion.

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.

To add some value to this argument, video4linux subsystem has
a couple of template drivers -fully maintained- called vivi and mem2mem_testdev.

These are the starting point of any v4l developer.

Adding more drivers like these to other subsystems -mainlined, of course-
would be more worthy than maintaining a general template of them off-tree.

Just my two cents,
Ezequiel.

"Ezequiel" == Ezequiel Garcia <elezegarcia@...> 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.

--
Bye, Peter Korsgaard

Hi Peter, Ezequiel, Thomas,

On Thu, Oct 04, 2012 at 08:38:32AM +0200, Peter Korsgaard wrote:

"Ezequiel" == Ezequiel Garcia <elezegarcia@...> 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

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.

baruch

--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@... - tel: +972.2.679.5364, http://www.tkos.co.il -

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 <elezegarcia@...> 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.