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 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' 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. 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. 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. 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! 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. thanks Bob Smith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/