Barcode driver to donate to Linux - Linux

This is a discussion on Barcode driver to donate to Linux - Linux ; Hi, I wrote a Linux driver for my barcode reader, since I couldn't find any appropriate on the Internet, so I wander what the procedure is for drivers to be included in future versions of Linux kernel. Generally, I don't ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Barcode driver to donate to Linux

  1. Barcode driver to donate to Linux

    Hi,

    I wrote a Linux driver for my barcode reader, since I couldn't find
    any appropriate on the Internet, so I wander what the procedure is for
    drivers to be included in future versions of Linux kernel. Generally,
    I don't know if Linux kernel developers are interested to include such
    specific drivers into the kernel, and second, if so, I am interested
    what requirements it has to fulfil to be included in it. By
    "requirements" I mean what form it has to be in, cause in this moment
    it works as following: when the USB driver is inserted, it is
    recognized as such and given to my driver which then allows making a /
    dev/ file to read from. Reading blocks until a barcode is available
    from the device. The /dev/ file major number is generated where
    available (0 in place of major in register_chrdev) and can be read
    from a /proc file which I automatically create.

    Cheers
    Darko

  2. Re: Barcode driver to donate to Linux

    Darko wrote:

    > Hi,
    >
    > I wrote a Linux driver for my barcode reader, since I couldn't
    > find any appropriate on the Internet, so I wander what the
    > procedure is for drivers to be included in future versions of
    > Linux kernel. Generally, I don't know if Linux kernel
    > developers are interested to include such specific drivers into
    > the kernel,


    Of course they are.

    > and second, if so, I am interested what
    > requirements it has to fulfil to be included in it.


    Your code must follow the kernel coding style, fit well into the
    already existing code, at best uses already existing code,
    instead of reinventing the wheel creating redundancies.

    Just post it to the Linux Kernel Mailing List. But be prepared
    for a lot of criticisim. They're not critising you (personally)
    but just try to give you hints to improve it.

    > By "requirements" I mean what form it has to be in, cause in
    > this moment it works as following: when the USB driver is
    > inserted, it is recognized as such and given to my driver which
    > then allows making a / dev/ file to read from. Reading blocks
    > until a barcode is available from the device. The /dev/ file
    > major number is generated where available (0 in place of major
    > in register_chrdev) and can be read from a /proc file which I
    > automatically create.


    You told this bardcode reader is a USB device. Could it be, that
    it is a USB-HID device? Then IMHO a good practise would be, to
    integrate it with the input subsystem, so that barcode input was
    accessible through evdev devices (/dev/input/event...). This
    would have the great advantage, that it was immediately
    avaliable to X11 as a InputDevice, either sending core events,
    or being accessible to applications through XDevice.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  3. Re: Barcode driver to donate to Linux

    Wolfgang Draxinger writes:
    > Darko wrote:
    >> I wrote a Linux driver for my barcode reader, since I couldn't
    >> find any appropriate on the Internet, so I wander what the
    >> procedure is for drivers to be included in future versions of
    >> Linux kernel. Generally, I don't know if Linux kernel
    >> developers are interested to include such specific drivers into
    >> the kernel,

    >
    > Of course they are.


    Of course, they are not. Otherwise, the driver would already have been
    written.

    >> and second, if so, I am interested what
    >> requirements it has to fulfil to be included in it.

    >
    > Your code must follow the kernel coding style,


    This doesn't help. At least Greg KH insists on 'unwritten coding style
    rules' (he has actually stated so publically at least a couple of
    times) ie on "do it the way I would have done it" [but I won't tell
    you how] (AFAIK, no while loops, no switches, no pointer arithmetic).

    The IMO best course of action would be to just publish the driver,
    dropping 'notes' to a couple of relevant places (eg lkml,
    freshmeat). If people consider it to be generally useful, they will
    start using it. Assuming enough people consider it to be useful and
    it is somewhat likely that the code will actually continue to be
    maintained for forseeable future, trying to get it into the
    stock-kernel could be sensible.

  4. Re: Barcode driver to donate to Linux

    Wolfgang Draxinger schrieb:

    > You told this bardcode reader is a USB device. Could it be, that
    > it is a USB-HID device? Then IMHO a good practise would be, to
    > integrate it with the input subsystem, so that barcode input was
    > accessible through evdev devices (/dev/input/event...). This
    > would have the great advantage, that it was immediately
    > avaliable to X11 as a InputDevice, either sending core events,
    > or being accessible to applications through XDevice.


    If it is no HID device, the kernel is the very wrong place for the
    driver anyways - Userspace/libusb is the proper place then.

    Regards,
    Johannes

    --
    "PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  5. Re: Barcode driver to donate to Linux

    Rainer Weikusat schrieb:

    >>> I wrote a Linux driver for my barcode reader, since I couldn't
    >>> find any appropriate on the Internet, so I wander what the
    >>> procedure is for drivers to be included in future versions of
    >>> Linux kernel. Generally, I don't know if Linux kernel
    >>> developers are interested to include such specific drivers into
    >>> the kernel,

    >> Of course they are.

    >
    > Of course, they are not. Otherwise, the driver would already have been
    > written.


    You're saying that all drivers which the kernel developers are
    interested in have already been written? What a ridiculous claim!

    Take a look at the write support for NTFS which has been wanted for a
    *long* time by many people. If somebody could supply that, LKML would
    surely be more than grateful to include it in mainline.

    And, no, I'm not talking about the current/broken support which only
    allows you to overwrite file content et cetera.

    Regards,
    Johannes

    --
    "PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  6. Re: Barcode driver to donate to Linux

    On Fri, 04 Apr 2008 19:53:44 +0200 Johannes Bauer wrote:
    | Rainer Weikusat schrieb:
    |
    |>>> I wrote a Linux driver for my barcode reader, since I couldn't
    |>>> find any appropriate on the Internet, so I wander what the
    |>>> procedure is for drivers to be included in future versions of
    |>>> Linux kernel. Generally, I don't know if Linux kernel
    |>>> developers are interested to include such specific drivers into
    |>>> the kernel,
    |>> Of course they are.
    |>
    |> Of course, they are not. Otherwise, the driver would already have been
    |> written.
    |
    | You're saying that all drivers which the kernel developers are
    | interested in have already been written? What a ridiculous claim!

    I have to agree. But maybe Rainer Weikusat didn't mean it exactly that
    way.

    Of course Linux developers are interested in adding drivers ... subject
    to certain criteria. Given a driver that meets the criteria and does
    gain interest by the developers, it is not necessarily the case that the
    developers would already have developed it. The biggest reason is most
    likely that the time is not available (e.g. driver developers work on
    other more important things, like drivers for other devices that have a
    higher level of popularity).

    The criteria needs to be considered. I don't even know what that is, but
    I would speculate that it not only requires the code to be of good quality
    (works, reasonably bug free, very secure, easy to read, etc), but also the
    device must have sufficient interest to the community to make it worth
    adding the driver to the source tree, even if it is never going to be
    enabled by default. The Linux kernel source tree cannot be a repository
    to deposit an infinite number of devices that maybe have only 2 or 3 users,
    even if the driver is of the highest quality. It must be justified to be
    added. It must be very well justified to make it be enabled by default
    (you'd know that by the time it gets there). For all others, drivers can
    be distributed in the form of kernel source tree patches and/or modules
    independently. Still, I am sure they are "interested" in having it made
    available for consideration.

    To the OP, subscribe to LKML (Google if you don't know what that means)
    and follow the conversations for a month or so. Clean up your code so
    it looks like it fits right in to other kernel code. Use the style of
    the existing kernel code as best you can. Make a patch file that updates
    the most recent kernel version, as well as the latest release candidate
    of the next version. Offer that patch to others who might be interested
    in that device and have them test that the process of patching the source,
    configuring it, building it, and trying it out, works OK. At that point
    someone can help you contact a sponsor who can help you get it submitted
    for consideration to include in the kernel.


    | Take a look at the write support for NTFS which has been wanted for a
    | *long* time by many people. If somebody could supply that, LKML would
    | surely be more than grateful to include it in mainline.

    It's not exactly a device driver, but it is a kernel component of value.
    This one may pose legal issues, so this is a special case. For example,
    a former Microsoft developer might be highly questionable if developing
    such code for Linux, because of the likelihood that it would not be
    "clean room" developed (e.g. Microsoft could assert that intellectual
    property of theirs is involved, and have more of a case for this than
    merely someone in the Linux community reverse engineering NTFS).

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-04-1532@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread