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