On Tue, Jan 11, 2022 at 09:09:31PM +0100, Philipp Hortmann wrote:
> On 1/11/22 9:51 AM, Greg KH wrote:
> > On Mon, Jan 10, 2022 at 10:31:28PM +0100, Philipp Hortmann wrote:
> > > Hi all,
> > >
> > > template usb-skeleton.c is working but outdated, documentation is helpful
> > > but years old and checkpatch.pl is giving hints to deprecated functions.
> > > This information is helpful but it does not show the way how to write a
> > > state of the art USB driver. Where to find this information? In the USB
> > > mailing list? By checking in git on which files most maintenance
> > > activities
> > > were done?
> >
> > First off, what do you mean by "state of the art"? USB drivers are
>
> Program code that is using the latest functions, macros and is up to date.
> Simply code that you like or consider best.
It all depends on the use-case for what is the "best". If you have a
slow device, and only need control/bulk USB transfers, that is one type
of design pattern of a USB driver, while higher throughput requirements
using streams is another, and data that can be lossy using isoc
endpoints is yet another.
So it will depend.
> > almost never just a USB driver. The USB portion of the driver is the
> > "simple" part. The "real" part of the driver is going to be doing
> > whatever functionality the device is (i.e. sound device, keyboard
> > device, video device, etc.)
> >
> > USB is just a dumb pipe. The USB portion of your driver just needs to
> > set up the pipes, and get the data flowing in them. How you deal with
> > that data is going to be the real work you have to do, and the majority
> > of the driver size. Otherwise you really do not even need a USB driver,
> > and you can just do everything from userspace and use libusb to
> > read/write to the USB device directly.
> >
> > If you have a new driver you need to write, look at the existing drivers
> > for guidance, and the documentation. Then submit it to the linux-usb
> > mailing list for review, the people there will help you out with any
> > portions that you have problems with.
>
> Intention of this email was to not bother the community to much as I am a
> newbie.
>
> >
> > So, what have you tried so far that is not working and what type of
> > device are you trying to control that needs a new USB driver for?
>
> No new driver and no new device. I want to do maintenance on old drivers.
Doing maintenance on old drivers that currently work well is hard
without having the hardware for them and finding a real problem with the
driver itself. So start with drivers for devices that you have today,
and look and see if you can find any throughput issues or anything else.
But again, that's going to be very device/type specific as to what needs
to happen there.
> I
> have not chosen one yet as I want to practice first to get more into
> details. I have adapted the usb-skeleton.c for a USB to serial adapter and
> for a USB LCD Display. When I am doing it right the usb-skeleton.c is
> working very well. The reason why I am asking is because very experienced
> kernel developers have said it is "out of date" and want to delete it
> because it is so bad and so wrong. I do not understand what is so bad and so
> wrong.
That driver tried to be an example for an unknown device, doing multiple
different things that no single driver/device would probably ever need.
Also it can almost always just be replaced with a simple userspace
program using libusb, as I bet your driver could be replaced with as
well, right?
When I wrote that original usb skeleton driver, there was still many
different types of USB devices out there that we did not support, and so
an example driver was one way to help others out. Given that Linux now
supports all USB devices and types, it's not so useful as if you need to
support a new one, it usually just requires you to modify an existing
driver. New USB device types are, thankfully, quite rare these days,
with most of the crazy new things being able to be controlled directly
from userspace.
thanks,
greg k-h
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
