On Mon, 2009-11-30 at 09:01 -0500, Jon Smirl wrote: > On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote: > > On Mon, 2009-11-30 at 07:57 -0500, 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? > >> > >> > >> 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?). > > > > > > 6. You can modify userspace driver easily to cope with all weird setups. > > Like you know that there are remotes that send whole packet of data that > > consist of many numbers that are also displayed on the LCD of the > > remote. > > Otherwise you will have to go through same fight for every minor thing > > you like to add to kernel... > > > > > > 7. You don't have an ABI constraints, your userspace program can read a > > configuration file in any format you wish. > > I for example was thinking about putting all lirc config files into an > > sqllite database, and pulling them out when specific remote is detected. > > Linux is not a microkernel it is a monolithic kernel. > http://en.wikipedia.org/wiki/Microkernel The above is trolling. Maybe it will come as a surprise to you, but I am quite big supporter of in-kernel code. For example I don't quite like that alsa doesn't do mixing and re-sampling in kernel. These days pulseaudio works quite well, but it still sucks in some sense sometimes. I know about dmix/dsnoop, etc, these are nice, but still I would be happy if kernel did that critical for both performance and latency thing in kernel. Some time ago an idea to move kernel VT support in userspace surfaced, and I was against it too. However, following established concept in philosophy, extremes are equally bad. Both pushing everything out of kernel, and shoving everything in is equally bad. So I am not blindly saying that, 'Everything belongs to kernel!' or 'Lets put everything out, its more stable that way!, Moore law will take care of performance...' Instead I consider the pros and cons of both solutions, picking the best one. In that particular case I was even happy to see your kernel patches at first glance, but then, after deep review I found that in-kernel approach will create only problems, won't eliminate userspace decoding, and solve only one problem, that is give good feeling about 'one less daemon in system'. > Once things get into the kernel they become far harder to change. > Stop for a minute and think about designing the best IR system for > Linux and forget about making a cross platform solution. IR is an > input device, it should be integrated into the Linux input subsystem. > You may not like the designs I have proposed, but running IR in user > space and injecting a keystroke at the end of the process is not > integrating it into the input subsystem. Yes it is, like it or not. Best regards, Maxim Levitsky > > > > > > > >> > >> > >> > >> > >> > >> > >> > 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-media" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > > -- 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
