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

[Greg Kroah-Hartman]

On Sun, Aug 04, 2013 at 02:54:46PM -0700, Bob Smith wrote:
> >>+Proxy has some unique features that make ideal for providing a
> >>+/sys like interface.  It has no internal buffering.  The means
> >>+the daemon can not write until a client program is listening.
> >>+Both named pipes and pseudo-ttys have internal buffers.
> >
> >So what is wrong with internal buffers?  Named pipes have been around
> >for a long time, they should be able to be used much like this, right?
> Buffers are great for streaming data but are unneeded for
> configuration and status information.  Neither sysfs or procfs
> have internal buffers because they are not needed.

That's because they have a "consumer" at all times already, the kernel
itself.  And there is a buffer used, but it's quickly cleaned up.

>   In a way the problem is not the buffer itself but that a write
> into a named pipe, for example, will succeed even if there is no
> one at the other end to receive the data.  I think you'd want an
> open and write on a device driver to fail if the driver is not
> there and ready for the request.

Yes, but you aren't a device driver, you are a IPC between userspace
processes.

> >Adding a new IPC function to the kernel should not be burried down in
> >drivers/char/.  We have 10+ different IPC mechanisms already, some
> >simple, some more complex.  Are you _sure_ none of the existing ones
> >will not work for you?
> I'm convinced this has the fewest lines of new code and the
> smallest impact on the rest of the system, but I could be wrong.
> The minimum feature set I want is to emulate for my user-space
> device driver what the kernel has for procfs and sysfs, That is,
> 	echo 1 > /proc/sys/net/ipv4/ip_forward  # procfs
> 	echo 75 > /dev/motors/left/speed        # proxy dev

As I mentioned above, the kernel does have buffers, and you are using
them to talk to the device / driver / hardware / kernel when accessing
proc and sysfs files.

> > Maybe a simple userspace library that wraps the
> >existing mechanisms would be better (no kernel changes needed, portable
> >to any kernel release, etc.)?
> Yes, this is the traditional model for approaching problems like
> the one I have.  It would involve opening a unix socket, defining
> a protocol for that socket, and then writing several bindings for
> that protocol for different languages.  Wow, that is a LOT of work.

Use protobufs, all of the bindings and protocol is already handled for
you.

>   Luckily for us the procfs and sysfs authors have given us a much
> better model to use: ASCII characters terminated by a newline.  My
> Raspberry Pi customers expect to control an LED with a command like
> this:	echo 1 > /sys/class/gpio/gpio25

That is because you are talking to a hardware device, so that makes
sense.

> So it is entirely reasonable on their part to want to control a
> stepper motor with a command like this:
> 	echo 300 > /dev/robot/stepper0/count

That would be good, if you were talking to hardware.  But you aren't,
you are talking to another userspace process "somewhere else".

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/