lkml.org 
[lkml]   [2009]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    From
    On Mon, Nov 30, 2009 at 7:57 AM, Andy Walls <awalls@radix.net> 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@vger.kernel.org
    > More majordomo info at  http://vger.kernel.org/majordomo-info.html
    >



    --
    Jon Smirl
    jonsmirl@gmail.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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