linux-kernel - Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Mar 2011 08:39:43 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
Cc:	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...ux.intel.com>,
	"Igor M. Liplianin" <liplianin@...by>,
	Ben Gamari <bgamari.foss@...il.com>
Subject: Re: Kernelspace firmware loaders (was: linux-next: manual merge of
 the staging tree with the v4l-dvb tree)

On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@...ah.com> wrote:
>
> If the code is just a "pass-through" to the hardware, I have no
> objection to the driver being in the kernel, if it needs to be in order
> to control the hardware properly.

.. or even if it doesn't "need to be", and you _could_ do it in user space.

We've had tons of problems with user space breakage and version skew
etc. It's often been a total pain to have user space-vs-kernel
components that support one version but not the other, making it hard
to upgrade the kernel independently of other things. The whole
experience with X-vs-drm has been very painful.

There are two cases where user-space drivers work fine:

 (a) if there is no kernel component to them at all. Think "this
driver would work on not just Linux, but on FreeBSD and UnixWare".
Examples of this would be the original X approach.

 (b) if there's a kernel driver which exports an interface that is
specified by the hardware (NOT specified by some "abstraction" layer),
and where the kernel just exports an interface and doesn't expect
anything back (ie the kernel is _strictly_ the lower-level driver,
there is no two-way "user space helps kernel" crap)

     A reasonable example of this would be the USB user space drivers:
the kernel interface is clearly _below_ (so the kernel does not depend
on user space), and the defined not by some crazy software interface,
but by the USB hardware standard.

But any other kind of mixing is just a big pain. Having a user-space
thing to set things up for a kernel driver is crazy crap. It
inevitably leads to "one or the other is broken, and people working on
one piece aren't the same people working on the other". Just don't do
it. Every time it's done, it leads to problems. You need special
programs to set things up etc. It's just f*cked up.

(An example of why it's crazy crap: it inevitably means that the
kernel can not "resume" a device. Because it now needs user space help
to get the device going again. Crazy. Don't do it. It's shit).

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