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/
