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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Linus,

On Monday 07 March 2011 17:39:43 Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@kroah.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).

I agree with you on the pain introduced by mixing drivers with userspace 
helpers. However, I'm still concerned about having a full JTAG stack in the 
kernel.

The Altera JTAG driver is basically a firmware loader. There's nothing wrong 
with firmare loaders in the kernel per-se, we have plenty of them and they 
usually request firmware data from userspace (hopefully specially crafted for 
the Linux driver, or pre-processed when the firmware is extracted from a 
Windows driver) and more of less dump it to the device.

Now, if a vendor provided a firmware in the form of a Java bytecode file, 
requiring the kernel driver to implement a JVM to load the firmware into the 
device, would you accept it ? JTAG is not Java, but it still requires several 
non-trivial layers, from controller drivers (we need to support multiple APIs 
there, as controllers can range from simple bit-banging adapters to more 
complex and faster devices with a higher level interface) to binary firmware 
interpreters (and I'm really talking about intepreters here, not just parsers 
- the Altera firmware file requires a VM) with of course incompatible vendor-
specific formats.

-- 
Regards,

Laurent Pinchart