Messages in this thread | | | Date | Wed, 07 Aug 2013 14:38:22 -0700 | From | Bob Smith <> | Subject | Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface |
| |
Greg Kroah-Hartman wrote: >> 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.
You are correct. But it's not _what_ is being done, it's _how_. Procfs clients have a really simple way of sending data to the kernel open(ip_forward) write("1\n") close I want the same thing for my user space daemon open(speed) write("75\n") close
> >> 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?
I could be wrong but to accomplish an open/write/close interface sort of like sysfs or procfs, I think we need an IPC that is - visible as a file name - bidirectional - both ends much be connected to communicate - a writer can effectively send EOF through the device
> > 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.
Hopefully the sample program I sent earlier makes sense. The source of data in the sample program was time of day but it could have as easily been date from a USB serial device or from a generic i2c device.
> >> 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?
Again, I hope the sample program makes this easier to see.
> >> USE CASE #2: End the madness of per-language bindings > 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.
Agreed. But isn't every IPC or other feature in the kernel there because someone in user space needed it? I hope so.
> > ASCII isn't all that its cracked up to be, you should know better than > that :) > And why ASCII? Why not XML? :)
You are entirely correct here.
thanks Bob Smith
| |