lkml.org 
[lkml]   [2009]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    From
    Date
    On Mon, 2009-11-30 at 09:01 -0500, Jon Smirl wrote: 
    > On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky <maximlevitsky@gmail.com> 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@gmail.com> 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@vger.kernel.org
    > >> More majordomo info at http://vger.kernel.org/majordomo-info.html
    > >
    > >
    > >
    >
    >
    >




    \
     
     \ /
      Last update: 2009-11-30 16:07    [W:3.339 / U:1.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site