Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a/sys-like interface

From: Greg Kroah-Hartman
Date: Tue Aug 06 2013 - 05:44:51 EST

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.
> 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.)
> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at