Date:	Sun, 4 Aug 2013 06:38:28 +0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Bob Smith <bsmith@...uxtoys.org>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a
 /sys-like interface

On Fri, Aug 02, 2013 at 06:19:19PM -0700, Bob Smith wrote:
> This character device can give daemons an interface similar to
> the kernel's /sys and /proc interfaces.   It is a nice way to
> give user space drivers real device nodes in /dev.

Other comments about this patch:

> From 7ee4391af95b828179cf5627f8b431c3301c5057 Mon Sep 17 00:00:00 2001
> From: Bob Smith <bsmith@...uxtoys.org>
> Date: Fri, 2 Aug 2013 16:44:48 -0700
> Subject: [PATCH] PROXY, a driver that gives daemons a /sys like interface
> 

No signed-off-by:, or body of text here that explains what this is and
why it should be accepted.

> ---
>  Documentation/proxy.txt |   36 ++++
>  drivers/char/Kconfig    |    8 +
>  drivers/char/Makefile   |    2 +-
>  drivers/char/proxy.c    |  539 +++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 584 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/proxy.txt
>  create mode 100644 drivers/char/proxy.c
> 
> diff --git a/Documentation/proxy.txt b/Documentation/proxy.txt
> new file mode 100644
> index 0000000..6b9206a
> --- /dev/null
> +++ b/Documentation/proxy.txt
> @@ -0,0 +1,36 @@
> +Proxy Character Devices
> +
> +
> +Proxy is a small character device that connects two user space
> +processes.  It is intended to give user space daemons a /sys like
> +interface for configuration and status.
> +
> +As an example consider a daemon that controls a stepper motor. The
> +daemon would create and open one proxy device to read and write
> +configuration (/dev/stepper/config) and another proxy device to
> +accept a motor step count (/dev/stepper/count).
> +Shell commands to illustrate this example:
> +	$ stepper_daemon	# start the stepper control daemon
> +	$ # Set config to full steps, clockwise and 400 step/sec
> +	$ echo "full, cw, 400" > /dev/stepper/config
> +	$ # Now tell the motor to step 4000 steps
> +	$ echo 4000 > /dev/stepper/count
> +	$ sleep 2
> +	$ # How many steps remain?
> +	$ cat /dev/stepper/count
> +
> +
> +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?

> +Proxy will succeed on a write of zero bytes.  A zero byte write
> +gives the client an EOF.  The daemon in the example above would
> +use a zero byte write in the last command after it had written the
> +number of steps remaining.  No other IPC mechanism can close one
> +side of a device and leave the other side open.

No "direct" IPC, but you can always emulate this just fine with existing
IPC mechanisms.

> +Proxy works well with select(), an important feature for daemons.
> +In contrast, the FUSE filesystem has some issues with select() on
> +the client side.

What are those issues?  Why not just fix them?

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?  Maybe a simple userspace library that wraps the
existing mechanisms would be better (no kernel changes needed, portable
to any kernel release, etc.)?

thanks,

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

Powered by blists - more mailing lists