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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
