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 <
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_supplicant/use_channel
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
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
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
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
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.
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 Sat, Aug 10, 2013 at 10:08 PM, Bob Smith bsm...@linuxtoys.org 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
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
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
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
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
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
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
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?
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
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
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
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 robot? What
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 they need that
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
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:
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?
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 _syscall_ to
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 allocate
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
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 using
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:
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 are
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
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
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.
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
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
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
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
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.
> *
> *
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
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
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.
*
* The program
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
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
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
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,
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.
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 want to write
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 created
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 are
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
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
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 using
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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 this
72 matches
Mail list logo
