MIME-Version: 1.0
In-Reply-To: <87zk2hubh1.fsf@nemi.mork.no>
References: <1353007337-12791-1-git-send-email-const@MakeLinux.com>
	<20121115224030.GA16377@kroah.com>
	<87zk2hubh1.fsf@nemi.mork.no>
Date: Fri, 16 Nov 2012 12:27:33 +0200
Message-ID: <CAE7jHC817W77-Dgk7MJ2s7RVnxRGbO6oaSvqge75OCMo-8haFg@mail.gmail.com>
Subject: Re: [PATCH v2] LDT - Linux Driver Template
From: Constantine Shulyupin <const@makelinux.com>
To: =?ISO-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no>
Cc: linux-kernel@vger.kernel.org, celinux-dev@lists.celinuxforum.org,
        selimtemur@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2486
Lines: 52

On Fri, Nov 16, 2012 at 11:46 AM, Bj?rn Mork <bjorn@mork.no> wrote:
> Greg KH <gregkh@linuxfoundation.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)
Thanks. I seems you have missed.
The main advantage of LDT - is working driver with real HW and simple
test suite.
It implements trivial UART driver just to write to port, receive real
HW interrupt
and read data from port. (You can to suggest to use any another HW).
Without available UART, LDT emulates loopback in SW for testing.
Memory buffers are used for mmap and ioctl operations.
LDT test script ldt-test and test utility dio.c configures the driver
for loopback mode, passes data to the driver, receives back and
compares with input and gives result of comparison.
To perform validation tests, regression tests need simply to run test script.
Detailed kernel log and ftrace log during the test are saved for analysts.

> 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.
Thank you. Possible too. Can you or somebody else recommend such drivers?

>
> 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.
Thanks. I already research omap panda platform for improvement opportunities.

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