mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Hans-Jürgen Koch" <hjk@linutronix.de>
To: "Jesper Juhl" <jesper.juhl@gmail.com>
Cc: "Greg Kroah-Hartman" <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] UIO: Documentation
Date: Thu, 9 Aug 2007 09:41:09 +0200	[thread overview]
Message-ID: <200708090941.09484.hjk@linutronix.de> (raw)
In-Reply-To: <9a8748490708081436g23c8f01cga585d6612b380f16@mail.gmail.com>

Am Mittwoch 08 August 2007 23:36 schrieb Jesper Juhl:
> On 19/07/2007, Greg Kroah-Hartman <gregkh@suse.de> wrote:
> > From: Hans J. Koch <hjk@linutronix.de>
> >
> > Documentation for the UIO interface
> >
> ...
> > +<para>If you use UIO for your card's driver, here's what you get:</para>
> > +
> ...
> > +<listitem>
> > +       <para>if you need to keep some parts of your driver closed source,
> > +       you can do so without violating the GPL license on the kernel.</para>
> > +</listitem>
> > +</itemizedlist>
> > +
> ...
> 
> Do we really want this?

Yes. Please remember that UIO is for industrial I/O cards, not mainstream
PC hardware. You'll never see an UIO driver for an USB Scanner or a TV card.
Just try to write one. You will see that an UIO kernel driver for a device 
that has to interact with lots of kernel subsystems will become almost as
big as a normal kernel driver. Not much left for user space.

Typical industrial IO cards are simple PCI cards with loads of 
functions that don't fit in any kernel subsystem. A pure kernel driver
is usually _big_ and ugly and introduces 50 new ioctls and will never
make it into mainline.

> 
> In my oppinion we run the risk here of encouraging behaviour akin to
> what NVidia is doing - release a small kernel "glue" module and then
> keep the driver proper in a binary blob (in userspace, but still a
> binary blob).

If a company wants to do that, they'll do it, with or without UIO.

> If the company goes out of business and take their driver source with
> them then users are left with a useless, un-debugable, un-maintainable
> binary blob.
> Don't we instead want to encourage/pressure people to release specs
> and/or source code for their hardware/drivers so open, modifiable
> drivers can be written?

No. Please note that there _are_ reasons to keep code closed. I agree
with you when it comes to mass market hardware like graphics cards.
But in embedded systems with custom hardware for military or other
critical applications, you can't force a manufacturer to show you
his concepts. Usually, he's not allowed to.

UIO offers a legal way for these people to implement their driver.
Without it, they'll violate the GPL or don't use Linux at all.

> 
> This opens the door for people to start writing closed drivers. 

No. UIO doesn't change anything. You were always free to choose
your license for userspace stuff.

What we want to achieve is that IO cards, for which you get a
driver with 5000 lines of unreadable code for 2.6.12 from the
manufacturer at the moment, can get a sensible driver with
mainline support. That's all. We will see if that encourages
manufacturers to make drivers closed source.

Thanks,
Hans

  parent reply	other threads:[~2007-08-09  7:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 23:23 [GIT PATCH] UIO patches for 2.6.22 Greg KH
2007-07-18 23:26 ` [PATCH 1/3] UIO: Add the User IO core code Greg Kroah-Hartman
2007-07-18 23:26   ` [PATCH 2/3] UIO: Documentation Greg Kroah-Hartman
2007-07-18 23:26     ` [PATCH 3/3] UIO: Hilscher CIF card driver Greg Kroah-Hartman
2007-07-19 16:33       ` Jan Engelhardt
2007-07-19 19:28         ` Hans-Jürgen Koch
2007-07-19 20:02           ` Jan Engelhardt
2007-07-19 20:24             ` Hans-Jürgen Koch
2007-08-08 21:36     ` [PATCH 2/3] UIO: Documentation Jesper Juhl
2007-08-08 22:12       ` Valdis.Kletnieks
2007-08-08 23:03         ` Jesper Juhl
2007-08-09  7:19           ` Greg KH
2007-08-09 16:50             ` Jesper Juhl
2007-08-08 23:40         ` Alan Cox
2007-08-09 12:29           ` Hans-Jürgen Koch
2007-08-09 14:09             ` Alan Cox
2007-08-09 13:02         ` Hans-Jürgen Koch
2007-08-09 14:12           ` Alan Cox
2007-08-09 15:23             ` Hans-Jürgen Koch
2007-08-09  7:41       ` Hans-Jürgen Koch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-05-08 14:04 [GIT PATCH] UIO patches for 2.6.21 Greg KH
2007-05-08 14:08 ` [PATCH 1/3] UIO: Add the User IO core code Greg Kroah-Hartman
2007-05-08 14:08   ` [PATCH 2/3] UIO: Documentation Greg Kroah-Hartman
2007-04-27 22:49 [GIT PATCH] UIO patches for 2.6.21 Greg KH
2007-04-27 22:50 ` [PATCH 1/3] UIO: Add the User IO core code Greg Kroah-Hartman
2007-04-27 22:50   ` [PATCH 2/3] UIO: Documentation Greg Kroah-Hartman
2007-05-01 23:42     ` Randy Dunlap
2007-05-02  8:41       ` Hans-Jürgen Koch
2007-05-02 20:52         ` Randy Dunlap
2007-05-02 22:00           ` Hans-Jürgen Koch
2007-05-02 23:37             ` Randy Dunlap
2007-05-03  5:37               ` Greg KH
2007-05-03  6:39                 ` Hans-Jürgen Koch
2007-05-04  9:37                   ` Hans-Jürgen Koch
2007-05-07 17:46                     ` Randy Dunlap
2007-05-07 20:01                       ` Hans-Jürgen Koch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200708090941.09484.hjk@linutronix.de \
    --to=hjk@linutronix.de \
    --cc=gregkh@suse.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome