From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Mon, 30 Nov 2009 09:01:31 -0500 Message-ID: <9e4733910911300601x513e8ac5n86b9b745536ca955@mail.gmail.com> References: <9e4733910911280937k37551b38g90f4a60b73665853@mail.gmail.com> <1259469121.3125.28.camel@palomino.walls.org> <20091129124011.4d8a6080@lxorguk.ukuu.org.uk> <1259515703.3284.11.camel@maxim-laptop> <2c0942db0911290949p89ae64bjc3c7501c2de6930c@mail.gmail.com> <1259537732.5231.11.camel@palomino.walls.org> <4B13B2FA.4050600@redhat.com> <1259585852.3093.31.camel@palomino.walls.org> <1259588608.13049.16.camel@maxim-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1259588608.13049.16.camel@maxim-laptop> Sender: linux-media-owner@vger.kernel.org To: Maxim Levitsky Cc: Andy Walls , Mauro Carvalho Chehab , Ray Lee , Alan Cox , Krzysztof Halasa , Christoph Bartelmus , dmitry.torokhov@gmail.com, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, stefanr@s5r6.in-berlin.de, superm1@ubuntu.com List-Id: linux-input@vger.kernel.org On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky 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 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 introduc= ing >> > >> 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: t= he system >> > will be broken, if you got a crash at the IR driver. >> >> Yes, true. =A0I 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 avo= id >> the risk of filesystem corruption. >> >> > Userspace is much more flexible. >> > >> > Why? The flexibility about the same on both kernelspace and usersp= ace, >> > except for the boot time. >> >> I suppose my best answer to that is question back to you: Why does u= dev >> 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 i= n >> the kernel. =A0(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 setu= ps. > Like you know that there are remotes that send whole packet of data t= hat > 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 thin= g > 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 a= n > sqllite database, and pulling them out when specific remote is detect= ed. Linux is not a microkernel it is a monolithic kernel. http://en.wikipedia.org/wiki/Microkernel If you want to push all of the device drivers to user space go run a microkernel. Even the X server has finally come around to getting rid of their cross platform OS in user space model and begun the switch to kernel drivers. That transition is going to take ten years to complete. 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. > > >> >> >> >> >> >> >> > A kernelspace input device driver can start working since boot tim= e. >> > On the other hand, an userspace device driver will be available on= ly >> > 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 ente= ring >> > on some administrative mode). >> >> Right. =A0That's another requirement that makes sense, if we're talk= ing >> 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-medi= a" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html > > > --=20 Jon Smirl jonsmirl@gmail.com