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

_______________________________________________
Celinux-dev mailing list
Celinux-dev@lists.celinuxforum.org
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

Reply via email to