Andy Walls wrote: > On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote: >> Andy Walls wrote: >>> On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote: >>>> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote: >>>>> This has zero advantages besides good developer feeling that "My system >>>>> has one less daemon..." >>>> Surely it's clear that having an unnecessary daemon is introducing >>>> another point of failure? >>> A failure in a userspace IR daemon is worst case loss of IR >>> functionality. >>> >>> A failure in kernel space can oops or panic the machine. >> If IR is the only interface between the user and the system (like in a TV >> or a Set Top Box), both will give you the same practical result: the system >> will be broken, if you got a crash at the IR driver. > > Yes, true. I had forgotten about the embedded space. > > Nonetheless I'd still rather debug a problem with a dead process in > userspace than an oops or panic (not that an end user cares) and avoid > the risk of filesystem corruption. > >> Userspace is much more flexible. >> >> Why? The flexibility about the same on both kernelspace and userspace, >> except for the boot time. > > I suppose my best answer to that is question back to you: Why does udev > run in userspace versus a kernel thread? udev relies on a kernel implementation: sysfs. > My personal thoughts on why user space is more flexible: > > 1. You have all of *NIX available to you to use as tools to achieve your > requirements. > > 2. You are not constrained to use C. > > 3. You can link in libraries with functions that are not available in > the kernel. (udev has libudev IIRC to handle complexities) > > 4. Reading a configuration file or other file from the filesystem is > trivial - file access from usespace is easy. > > 5. You don't have to be concerned about the running context (am I > allowed to sleep here or not?). You can do all the above steps with the proper API, just like udev does with sysfs API. After the boot, a device can open the raw API, disabling any in-kernel decoding/handling and handle IR directly. Alternatively, an udev rule can load a different keymap based on some config written on a file. So, you won't loose anything by having an in-kernel driver or decoder. >> A kernelspace input device driver can start working since boot time. >> On the other hand, an userspace device driver will be available only >> after mounting the filesystems and starting the deamons >> (e. g. after running inittab). >> >> So, you cannot catch a key that would be affecting the boot >> (for example to ask the kernel to run a different runlevel or entering >> on some administrative mode). > > Right. That's another requirement that makes sense, if we're talking > about systems that don't have any other keyboard handy to the user. > > So are we optimizing for the embedded/STB and HTPC with no keyboard use > case, or the desktop or HTPC with a keyboard for maintencance? If we remove the in-kernel decoders/evdev handlers, you'l limit the usecase, where if you keep them in kernel, both ways can be used. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
