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

[Greg Kroah-Hartman]

On Wed, Aug 07, 2013 at 12:39:48PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >>  *    sudo chmod 666 /dev/proxyout /dev/proxyctrl
> >That's mighty permissive :(
> For a demo it might be OK.
> 
> BUT: I think I should modify the module to forward a close request
> (write 0 bytes) only if the sender UID matched the proxy node's UID.
> This might not be strictly required but is a security nice to have.
> 
> 
> >>  *    gcc -o pxtest pxtest.c
> >>  *    ./pxtest &
> >>  *    cat /dev/proxyout    # view the output
> >>  *    (switch to another terminal window)
> >>  *    cat /dev/proxyctrl   # what is the offset?
> >>  *    echo 2 > /dev/proxyctrl  # set offset to 2
> >>  */
> >
> >I really don't understand this, you just have two programs talking to
> >each other, passing the data blindly through the kernel.  Again, we
> >already have over 10 different ways to do IPC these days, are you _sure_
> >that _none_ of them work for you like this?  You have gone and looked at
> >them all, right?
> 
> All along I've had a clear goal.  I want to configure a running program
> the same way I configure the kernel.  It is simple and I don't need any
> language bindings.
> 	cat /dev/proxyctrl   # what is the offset?
> 	echo 2 > /dev/proxyctrl  # set offset to 2

You have language bindings right there in bash for this api, what you
are saying is that you don't want to write new syscall bindings for new
languages, which is fine, don't do that, use the ones we already have
for the vast number of different IPC types.

> Yes, I am sure that nothing else will do.  A named pipe is the closest
> but it has a buffer and is not bidirectional.   I am also convinced that
> there is no way to do what I want with fewer lines of code.

What is your specific requirements, I see you couch them in terms of
what you have created, but none in terms of actual requirements with no
specific implementation.

And all of my other outstanding questions still remain, please address
those as well.

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/