On Mon, Nov 30, 2009 at 7:57 AM, Andy Walls <awalls@xxxxxxxxx> wrote: > I suppose my best answer to that is question back to you: Why does udev > run in userspace versus a kernel thread? Because udev is a scripting system. I've always said that the scripting piece of IR belongs in user space. IR scripting should be optional, none of the systems I work on need it. This is the event flow being built... device timing data -- send timing data to user space -- do protocol decode (40K code) -- send decoded data back to kernel other devices that decode in HW add events here -- send decoded data to user space -- map to keys (30K code) -- send keys back to kernel apps listen for keys -- send keys back to user space -- user space apps act on key (possibly run scripts) I'd like to see... device timing data -- user space can inject timing data from user space drivers do protocol decode (40K code) other devices that decode in HW add events here -- user space can inject decoded data from user space drivers map to keys (30K code) apps listen for keys -- send keys back to user space -- user space apps act on key (possibly run scripts) > > 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 > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
