proposal to delete the skeleton driver

proposal to delete the skeleton driver

[Oliver Neukum]

Hi,

it seems to me that the method of maintaining an example driver
does not work because it will inevitably be

* untested

* out of date

Thus our documentation would be improved by replacing its examples
with code from drivers for real hardware. Such code wouldn't be pretty
or written for text books, but it would be tested.
I could do it this week in a first proposal. But I don't want to start
if somebody feels that the skeleton driver absolutely has to stay.

    Regards

        Oliver

Re: proposal to delete the skeleton driver

[Greg KH]

On Tue, Dec 07, 2021 at 11:16:37AM +0100, Oliver Neukum wrote:
> Hi,
> 
> it seems to me that the method of maintaining an example driver
> does not work because it will inevitably be
> 
> * untested
> 
> * out of date
> 
> Thus our documentation would be improved by replacing its examples
> with code from drivers for real hardware. Such code wouldn't be pretty
> or written for text books, but it would be tested.
> I could do it this week in a first proposal. But I don't want to start
> if somebody feels that the skeleton driver absolutely has to stay.

As the author of the skeleton driver, I have no objections to removing
it as it is showing its age and all of the problems that you mention
here are real.

So sure, delete away!

thanks,

greg k-h

Re: proposal to delete the skeleton driver

[Theodore Y. Ts'o]

On Tue, Dec 07, 2021 at 11:16:37AM +0100, Oliver Neukum wrote:
> 
> Thus our documentation would be improved by replacing its examples
> with code from drivers for real hardware. Such code wouldn't be pretty
> or written for text books, but it would be tested.
> I could do it this week in a first proposal. But I don't want to start
> if somebody feels that the skeleton driver absolutely has to stay.

In addition to your idea, I wonder if we could point people at some
simple "real world" drivers that people could look at which are (a)
simple, and (b) relatively clean and free of anti-patterns that we
don't want driver authors to copy pasta into their drivers.

Sort of like how we have the "minix" and "ext2" file systems as
examples that we will sometimes point people to who want to understand
how to do their own new file systems.

       	  	    	     - Ted

Re: proposal to delete the skeleton driver

[Oliver Neukum]

On 07.12.21 23:43, Theodore Y. Ts'o wrote:
> In addition to your idea, I wonder if we could point people at some
> simple "real world" drivers that people could look at which are (a)
> simple, and (b) relatively clean and free of anti-patterns that we
> don't want driver authors to copy pasta into their drivers.
I will try to. It may come as a surprise but if we want to limit
ourselves to drivers implementing a classical character device,
the number of recent examples dwindles rapidly.

And I think we should stick to such devices to give examples
comprehensible and relevant to as many people as possible.

    Regards
        Oliver

Re: proposal to delete the skeleton driver

[Philipp Hortmann]

On 12/8/21 12:13 PM, Oliver Neukum wrote:
> 
> On 07.12.21 23:43, Theodore Y. Ts'o wrote:
>> In addition to your idea, I wonder if we could point people at some
>> simple "real world" drivers that people could look at which are (a)
>> simple, and (b) relatively clean and free of anti-patterns that we
>> don't want driver authors to copy pasta into their drivers.
> I will try to. It may come as a surprise but if we want to limit
> ourselves to drivers implementing a classical character device,
> the number of recent examples dwindles rapidly.
> 
> And I think we should stick to such devices to give examples
> comprehensible and relevant to as many people as possible.
> 
>      Regards
>          Oliver
> 
> 
I like drivers/usb/misc/usblcd.c as one simple example. An older version 
of usb-skeleton was the template. It is using urbs only for writing.

Since no driver seems to cover everything we may need two examples of 
maintained drivers as transfer performance and interrupt endpoints are 
not relevant for usblcd.

Regards
Philipp

Re: proposal to delete the skeleton driver

[Philipp Hortmann]

On 12/7/21 11:16 AM, Oliver Neukum wrote:
> Hi,
> 
> it seems to me that the method of maintaining an example driver
> does not work because it will inevitably be
> 
> * untested
> 
> * out of date
> 
> Thus our documentation would be improved by replacing its examples
> with code from drivers for real hardware. Such code wouldn't be pretty
> or written for text books, but it would be tested.
> I could do it this week in a first proposal. But I don't want to start
> if somebody feels that the skeleton driver absolutely has to stay.
> 
>      Regards
> 
>          Oliver
> 

My wish is that it is only deleted when you have something similar as 
proposed by Ted.

I have tested the driver during the last three month. I used different 
devices. The best one was a USB to serial adapter, as it has the by the 
driver expected bulk in and out endpoints. In the skel_open() I was 
putting in an initialization and was able to set RTS and other signals 
on the RS232 side. I was also able to test the usb_bulk_msg() receiving 
example for my patch…

I truly believe that it has issues. But it is usable.

I liked that it is a character device and that it is one file and not 
distributed among many files.

Regards
Philipp