Greg Thanks for your reply. I'll reply to your comments in reverse order.
Greg Kroah-Hartman wrote:
And how does this have anything to do with /sys? I can't see any sysfs interaction in the code, or am I missing it?
Yes, you are right. I'll change the subject and brief descriptions to something like: "Proxy, a simple bidirectional character device that almost transparently proxies opens, reads, writes, and closes from one side of the device to the other side." I'll take "/sys" from all descriptions of the device, but I might leave it in the Documentation/proxy.txt file since a major use case of proxy is to give user space drivers and daemons the same kind of interface the kernel enjoys with /sys and /proc. The similarity is very deliberate on my part for commands like echo 1 > /proc/sys/net/ipv4/ip_forward # procfs echo 75 > /dev/motors/left/speed # proxy dev Greg Kroah-Hartman wrote: > Why not just use the cuse interface instead? How does this differ from > that /dev node interaction? I am a big fan of FUSE and CUSE but they do not support what I need. CUSE is OK if _ALL_ interaction is through its interface. What is lacking is an ability to open, say, a USB serial port and add its file descriptor to CUSE's FD_SET. This is a pretty deep problem since a CUSE takes away main() from the application developer. A CUSE application looks kind of like this: main(argc, argv) { (check and process command line) cuse_lowlevel_main(argc, argv, ...) } Another difference is that no language bindings are needed. There is no equivalent of libfuse.so. Since proxy is just a character device and there are no language bindings, someone could, in the unlikely case it ever made sense, write a user space device driver in node.js. 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/