Hi,

Thanks to Baruch Siach, Thomas Petazzoni, Jean-Christophe
PLAGNIOL-VILLARD, Peter Korsgaard, Ezequiel Garcia, Selim TEMUR and
Tim Bird who sent feedback on LDT announce!

With you help I've made following updates:
- created new page http://elinux.org/Device_drivers with list of all
mentioned and discovered driver samples and skeletons for video, usb,
network, including updated examples from book LDD3. You are welcome to
update the list.
- added multiple char devices with Device Model support, debugfs and
other small fixes to https://github.com/makelinux/ldt/

I absolutely agree that LDT can't be universal template. First of all
it is better to fork a new driver from similar existed driver or use
subsystem template. But sometimes it is easier to write driver from
scratch than rework existed. It this case LDT can be useful.

If you think that there is lack of subsystem driver template, please
write me. I have some free time to write it.

LDT is more just char UART device driver. UART is used only for sample
and can be replaced with another HW interface. Also LDT provides a lot
of most common device driver infrastructure: bottom halves, kthread,
synchronization, memory, mmap and ioctl interfaces.
Finally, only LDT can be executed and tested by running a single
script https://github.com/makelinux/ldt/blob/master/ldt-test, which
send data to driver and check driver's response.

Thank you very much!


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

On 00:45 Sun 07 Oct , Constantine Shulyupin wrote:

Hi,

Thanks to Baruch Siach, Thomas Petazzoni, Jean-Christophe
PLAGNIOL-VILLARD, Peter Korsgaard, Ezequiel Garcia, Selim TEMUR and
Tim Bird who sent feedback on LDT announce!

With you help I've made following updates:
- created new page http://elinux.org/Device_drivers with list of all
mentioned and discovered driver samples and skeletons for video, usb,
network, including updated examples from book LDD3. You are welcome to
update the list.
- added multiple char devices with Device Model support, debugfs and
other small fixes to https://github.com/makelinux/ldt/

don't take it bad but this kind of example will never make it mainline

it's wrote in the right way

I absolutely agree that LDT can't be universal template. First of all
it is better to fork a new driver from similar existed driver or use
subsystem template. But sometimes it is easier to write driver from
scratch than rework existed. It this case LDT can be useful.

no sorry you miss the point here it's better to based your work on a clean
driver so you can see how it's supposed to be written

If you think that there is lack of subsystem driver template, please
write me. I have some free time to write it.

LDT is more just char UART device driver. UART is used only for sample
and can be replaced with another HW interface. Also LDT provides a lot
of most common device driver infrastructure: bottom halves, kthread,
synchronization, memory, mmap and ioctl interfaces.
Finally, only LDT can be executed and tested by running a single
script https://github.com/makelinux/ldt/blob/master/ldt-test, which
send data to driver and check driver's response.

I'm sorry but you code can not be useed as a recommandation for people to
write new drivers. Read a mainline will be better and will show practice we
use right now such as we de not use ifdef is the as muchas possible we use
IS_ENABLED & co and for the UART Russel King the ARM Maintainer si currently
reworking the tty API and I can point others suach PM, DT etc...

Best Regards,
J.

On 12:34 Sun 07 Oct , Constantine Shulyupin wrote:

Thanks,

On Sun, Oct 7, 2012 at 12:24 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote:

I can point others suach PM, DT etc...

What to you mean?

I mean those example are way too much far from the mainline practice and any
real application

They are not a "good practice example" as you miis too many point about
drivers such as PM, Runtime-PM, Devicetree etc...

That's why I said and will maintain to said use mainline drivers as example
with real use case

And I speak as a Kernel Maintainer

Best Regards,
J.

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

On 10/07/2012 03:24 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

On 00:45 Sun 07 Oct , Constantine Shulyupin wrote:

LDT is more just char UART device driver. UART is used only for sample
and can be replaced with another HW interface. Also LDT provides a lot
of most common device driver infrastructure: bottom halves, kthread,
synchronization, memory, mmap and ioctl interfaces.
Finally, only LDT can be executed and tested by running a single
script https://github.com/makelinux/ldt/blob/master/ldt-test, which
send data to driver and check driver's response.

I'm sorry but you code can not be used as a recommandation for people to
write new drivers. Read a mainline will be better and will show practice we
use right now such as we de not use ifdef is the as much as possible we use
IS_ENABLED & co and for the UART Russel King the ARM Maintainer si currently
reworking the tty API and I can point others such PM, DT etc...

I understand the sentiment, but most of these are arguments
for mainlining the code, IMO. If the code practices in the template
are out-of-date, then they should, of course, be updated. But
rather than have a single developer constantly tracking the
state of different kernel APIs and practices, it would be
better for things to be caught by more eyeballs in the code.
Whether or not developers would bother to update this driver
example, if it were in mainline, would remain to be seen.

I agree that working from a working driver is going to give
someone a better chance of getting exposed to all the nitty-gritty
details that are required to make new real drivers. But I
also think there is some value to stripped-down examples that
show uncluttered code sequences for utilizing the variety of
in-kernel APIS that are available.

There is a reason that there are so many "hello world" examples
in the world. It's not that you use them as the starting
point for production software. It's that they have pedagogical
value for newcomers.

My biggest problem looking for samples to follow in the kernel
source tree is that you're never sure what constitutes good and
bad code. Those designated templates and skeletons
that are sprinkled about the kernel tree are really good for
that (or they should be if they don't bit-rot.)

Anyway, I think documenting all this on the elinux wiki
is very useful. By going to the page that Constantine
put together, I found out that someone is actually maintaining
the scull driver, which was one of my own wishes.
So I've already gotten something out of the thread. :-)

Thanks everyone for the good discussion.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================