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? 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?). > 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? Regards, Andy -- 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
