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
--
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/
