lkml.org 
[lkml]   [2013]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
    On Mon, Aug 05, 2013 at 04:46:32PM -0700, Bob Smith wrote:
    > Greg
    > Thanks for discussing the module with me. I think I'm now
    > closer to distilling it down to its essence.
    >
    >
    > GOAL:
    > The goal of this module is to give user space programs an
    > interface similar to that enjoyed by the kernel using procfs
    > and sysfs. All of the following should be possible
    > echo 1 > /proc/sys/net/ipv4/ip_forward # procfs
    > echo 75 > /dev/motors/left/speed # proxy
    > echo 5 > /dev/wpa_supplicant/use_channel # proxy

    No it shouldn't, that is userspace talking to the kernel, you aren't
    doing that at all.

    > IPC:
    > To accomplish the above goal a new IPC is required. This
    > new IPC must have the following characteristics:
    > - bidirectional
    > - writer blocks until reader is present
    > - a writer can cause the reader to close
    > - works with 'echo' and 'cat'

    Who is saying "must" here? Why are those requirements at all?

    > No existing IPC in Linux has all of these characteristics
    > but proxy, the tiny self-contained module submitted, does.
    > (Greg, I'm kind of surprised that a shim of an IPC like this
    > wasn't added to Linux a long, long time ago.)
    >
    > USE CASES:
    > Proxy should be added to the kernel because it can greatly
    > improve Linux in two significant ways.
    >
    > USE CASE #1: User space device drivers
    > A viable approach to user space device drivers would make
    > life easier for both programmers and kernel maintainers.
    > The latter because now a maintainer can now reasonably say
    > "go use proxy and a user space driver". Some of the SPI
    > and I2C drivers might have been easier to do with proxy.

    Specifically how would someone would use this to write a userspace
    driver? I'm totally not seeing it at all, and possibly, that's why I am
    so confused.

    > Programmers doing device drivers might have an easier time
    > since it will be easier to prototype and debug a system in
    > user space. SPI and I2C driver writers in particular may
    > appreciate the ability to build a working system without
    > having to go through the sometimes tedious process of a
    > kernel submission.

    "tedious"? Those crummy kernel maintainers, always insisting on the
    highest quality of code, it's as if the product runs the world or
    something. Oh wait...

    > Finally, some device drivers that are not possible today
    > would become possible. In my case I have a USB-serial link
    > to a robot controller and so need a user space daemon to
    > terminate the serial line. It is only with proxy that I
    > can hide the details of this and give users a nice /dev
    > view of the robot.

    How specifically would you do this with such a usb-serial device?

    > USE CASE #2: End the madness of language bindings
    > Over 10 years ago kernel developers had the sense to escape
    > (some) ioctl language bindings with the introduction of
    > procfs. How is it that in all this time we haven't done
    > the same thing for all the daemons that populate Linux?
    > No, today daemon writers are still being forced to open a
    > socket, define and document a protocol over it, and then
    > write a library for that protocol for all the popular
    > languages. And we're not talking about just one or two
    > languages. No, now it more like C, Java, Python, PHP, and
    > soon node.js. Next week some new language will wander off
    > the street and need a yet another binding. Eeeech!

    The kernel doesn't deal with language bindings, it provides a syscall
    interface that any language can call, or not, it's up to them. So this
    really isn't relevant at all.

    > Let's let daemons use the same kind of interface that the
    > kernel has with /sys and /proc. With proxy, daemon coders
    > could define an ASCII interface in exactly the same way the
    > kernel has. The inclusion of 'echo' and 'cat' above is kind
    > of a litmus test. If a daemon interface works with cat and
    > echo, it will _NEVER_ need dedicated per-language bindings.

    ASCII isn't all that its cracked up to be, you should know better than
    that :)

    And why ASCII? Why not XML? :)

    specific examples please,

    greg k-h


    \
     
     \ /
      Last update: 2013-08-06 12:01    [W:3.400 / U:1.340 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site