linux-kernel - Re: [PATCH v2] LDT - Linux Driver Template

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Nov 2012 10:46:18 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Constantine Shulyupin <const@...eLinux.com>,
	linux-kernel@...r.kernel.org, celinux-dev@...ts.celinuxforum.org,
	Ryan Mallon <rmallon@...il.com>,
	Tim Bird <tim.bird@...sony.com>,
	Baruch Siach <baruch@...s.co.il>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Peter Korsgaard <jacmet@...site.dk>,
	Ezequiel Garcia <elezegarcia@...il.com>,
	Selim TEMUR <selimtemur@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
Subject: Re: [PATCH v2] LDT - Linux Driver Template

Greg KH <gregkh@...uxfoundation.org> writes:

>  Normally you just start with a
> driver for a device like the one you need to write and modify it from
> there.

Yes.

Even if the template driver is fixed up to be the most beautiful driver
ever made, it will still always be made for non-existing hardware.  This
causes two major problems:
 - the driver will not be tested, so it will have bugs
 - the driver will not be used by anyone, so it will not be maintained
   (remember that it is initially perfect, so there is no reason to
   change it)

May I suggest another approach?  How about selecting a set of existing
drivers which are suitable as templates, and put all this effort into
making those drivers *the* perfect examples instead? Start submitting
cleanup patches for the selected drivers until everyone is satisfied and
then document them as starting points for anyone wanting to write a
similar driver.

I believe many subsystem maintainers already have such sample drivers
which they point new submitters to when asked.  That does not mean that
these drivers necessarily are perfect, so there is still work to do here
for anyone interested.  And collecting this information and documenting
it would be useful in itself.

It would also be nice if hardware availability was considered when
selecting the sample drivers.  Buying an already supported device to
experiment with its driver can be useful even if you have another device
you want to write a driver for.  Or just for the learning experience.

Just my € .02

Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/