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
