On Sunday 11 August 2013, Bob Smith wrote:
> Arnd Bergmann wrote:
> >> GOAL
> >> The goal of this patch was to make it possible to configure
> >> daemons using simple file IO. The litmus test for this is
> >> that commands like these should be possible
> >> cat < /var/daemons/wpa_supplica
Arnd Bergmann wrote:
GOAL
The goal of this patch was to make it possible to configure
daemons using simple file IO. The litmus test for this is
that commands like these should be possible
cat < /var/daemons/wpa_supplicant/use_channel
echo 5 >/var/daemons/wpa_supplicant/use_chan
On Saturday 10 August 2013, Bob Smith wrote:
> GOAL
> The goal of this patch was to make it possible to configure
> daemons using simple file IO. The litmus test for this is
> that commands like these should be possible
> cat < /var/daemons/wpa_supplicant/use_channel
> echo 5 >/var
richard -rw- weinberger wrote:
GOAL
The goal of this patch was to make it possible to configure
daemons using simple file IO. The litmus test for this is
that commands like these should be possible
cat < /var/daemons/wpa_supplicant/use_channel
echo 5 >/var/daemons/wpa_supplican
On Sat, Aug 10, 2013 at 10:08 PM, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
>>
>> Otherwise, to accept this code, I need to see a way that normal users
>> can use it (i.e. no root or mknod), and that it can handle namespaces
>> and the security interface that the kernel has to support. To do s
Greg Kroah-Hartman wrote:
Otherwise, to accept this code, I need to see a way that normal users
can use it (i.e. no root or mknod), and that it can handle namespaces
and the security interface that the kernel has to support. To do so
otherwise would be unfair to users who expect such a thing.
On Fri, Aug 09, 2013 at 04:35:16PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >Good protocols exist, look at protobufs from Google if you want to
> >define your own. Never create your own protocol these days, it doesn't
> >make sense, be it a text one or something else.
>
> OK. I was
Greg Kroah-Hartman wrote:
Good protocols exist, look at protobufs from Google if you want to
define your own. Never create your own protocol these days, it doesn't
make sense, be it a text one or something else.
OK. I was using the term in the broader sense in which _meaning_ is
assigned to t
On Fri, Aug 09, 2013 at 03:51:39PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >On Wed, Aug 07, 2013 at 02:53:50PM -0700, Bob Smith wrote:
> >>Agreed. But you need root permissions to install an application
> >>and part of that installation can be setting up systemd files
> >>that alloca
On Fri, Aug 09, 2013 at 03:14:10PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> (snip)
> > You are mixing protocols and bindings and system calls up it seems.> They
> > are not the same at all.
>
> Yes, I may be using the term binding wrong. As I understand it
> - We should use a _sysc
Greg Kroah-Hartman wrote:
On Wed, Aug 07, 2013 at 02:53:50PM -0700, Bob Smith wrote:
Agreed. But you need root permissions to install an application
and part of that installation can be setting up systemd files
that allocate resources at boot.
Do you have examples of those systemd files? Las
Greg Kroah-Hartman wrote:
On Thu, Aug 08, 2013 at 02:23:06PM -0700, Bob Smith wrote:
Greg
I'll reply again to this message but for now let me try
another explanation that does not mention sysfs, procfs, or
device drivers. This is probably how I should have started.
I fail to understand
Greg Kroah-Hartman wrote:
(snip)
> You are mixing protocols and bindings and system calls up it seems.> They are
not the same at all.
Yes, I may be using the term binding wrong. As I understand it
- We should use a _syscall_ to open a unix socket on the daemon, then
- define a _protocol_ to de
On Wed, Aug 07, 2013 at 02:53:50PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >>The proxy device nodes are application specific and need to be
> >>created as needed by applications.
> >
> >But applications do not have the permissions in a system to create
> >device nodes. Nor should the
On Thu, Aug 08, 2013 at 02:23:06PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:>
> > You are mixing protocols and bindings and system calls up it seems.
> > They are not the same at all.
>
> > How can you control a robot with this code?
> > What do you want to do in order to control your ro
Greg Kroah-Hartman wrote:>
> You are mixing protocols and bindings and system calls up it seems.
> They are not the same at all.
> How can you control a robot with this code?
> What do you want to do in order to control your robot? What are your
> needs in accessing the hardware? What hardware
Greg Kroah-Hartman wrote:
The proxy device nodes are application specific and need to be
created as needed by applications.
But applications do not have the permissions in a system to create
device nodes. Nor should they need that permission.
Agreed. But you need root permissions to install
On Wed, Aug 07, 2013 at 02:28:49PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> > You ignored my mknod comment.
> Yes, proxy is a type of IPC. It's closest counterpart in the
> kernel now is a named pipe. The kernel does not try to create
> named pipes automatically. Named pipes are cr
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
On Wed, Aug 07, 2013 at 02:04:52PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >>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 w
Greg Kroah-Hartman wrote:
> You ignored my mknod comment.
Yes, proxy is a type of IPC. It's closest counterpart in the
kernel now is a named pipe. The kernel does not try to create
named pipes automatically. Named pipes are created deliberately
by users with the mkfifo command or system call.
Greg Kroah-Hartman wrote:
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,
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
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.
You ignored my mknod comment.
Also, no, setting the permissions like this is not ok for a real
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
On Wed, Aug 07, 2013 at 12:02:03PM -0700, Bob Smith wrote:
> Greg
>This sample program shows what I'm trying to accomplish.
>
> I still owe you a reply for your previous posting
>
> thanks
> Bob Smith
>
>
> /*
> * pxtest.c : This program demonstrates the use of a proxy device.
> *
> * Th
Greg
This sample program shows what I'm trying to accomplish.
I still owe you a reply for your previous posting
thanks
Bob Smith
/*
* pxtest.c : This program demonstrates the use of a proxy device.
*
* The program generates some data once a second and tries to send
* it to /dev/proxyout
On Mon, Aug 05, 2013 at 04:46:32PM -0700, Bob Smith wrote:
> Greg
> Thanks for discussing the module with me. I think I'm now
> closer to distilling it down to its essence.
>
>
> GOAL:
> The goal of this module is to give user space programs an
> interface similar to that enjoyed by the kernel u
Greg
Thanks for discussing the module with me. I think I'm now
closer to distilling it down to its essence.
GOAL:
The goal of this module is to give user space programs an
interface similar to that enjoyed by the kernel using procfs
and sysfs. All of the following should be possible
ec
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
Greg
I've added some white space and snipped some text to make
the questions more visible.
Greg Kroah-Hartman wrote:
No signed-off-by:, or body of text here that explains what this is and
why it should be accepted.
D'oh! I'll fix this and add Joe's changes before resubmitting
the patch.
B
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 7ee4391af95b8281
Greg
Thanks for your reply. I'll reply to your comments in reverse order.
Greg Kroah-Hartman wrote:
And how does this have anything to do with /sys? I can't see any sysfs
interaction in the code, or am I missing it?
Yes, you are right. I'll change the subject and brief descriptions to
s
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.
Why not just use the cuse interface instead? How does th
On Fri, 2013-08-02 at 18:19 -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.
Trivial notes:
> diff --git a/drivers/char/proxy.c b/drivers/ch
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.
thanks
Bob Smith
From 7ee4391af95b828179cf5627f8b431c3301c5057 Mon Sep 17 00:00:00 2001
From: Bob Smith
Date: Fri, 2
36 matches
Mail list logo
