Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface

[Bob Smith <bsmith@linuxtoys.org>]

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