On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> can real DEC Alpha hardware end up with both instances of "r1"
> having the value 1?
I thought this question reminded me of something, so I found this:
> https://www.kernel.org/doc/Documentation/memory-barriers.txt
and I pasted in the content - David
On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> can real DEC Alpha hardware end up with both instances of "r1"
> having the value 1?
I thought this question reminded me of something, so I found this:
> https://www.kernel.org/doc/Documentation/memory-barriers.txt
and I pasted in the content - David
would
then always use the file_operations that you defined for your
chardev but use that with inode_operations similar to tmpfs.
THANKS! It would still be a kernel patch and still require
root to set up but so would FUSE and your approach might be
much lighter weight.
thanks
Bob
roceed from here then modifying the user space parts
of FUSE might be the best way to go.
Sorry that it took so long to get to the point that my goals
for the patch were clearly stated. As I say, I'm an EE who
probably need more adult supervision. :)
thanks
Bob Smith
--
To unsubscribe from thi
es a device
node.
CONCLUSION
Pseudo-ttys not withstanding, the kernel does not want
IPC mechanisms that require root privileges or mknod.
For this and other reasons this patch is rejected.
Greg, once again thanks for your patience in helping a
non-kernel guy through all of this. Thanks.
bye
Bob Smith
-
Pseudo-ttys not withstanding, the kernel does not want
IPC mechanisms that require root privileges or mknod.
For this and other reasons this patch is rejected.
Greg, once again thanks for your patience in helping a
non-kernel guy through all of this. Thanks.
bye
Bob Smith
--
To unsubscribe from
from here then modifying the user space parts
of FUSE might be the best way to go.
Sorry that it took so long to get to the point that my goals
for the patch were clearly stated. As I say, I'm an EE who
probably need more adult supervision. :)
thanks
Bob Smith
--
To unsubscribe from this list
then always use the file_operations that you defined for your
chardev but use that with inode_operations similar to tmpfs.
THANKS! It would still be a kernel patch and still require
root to set up but so would FUSE and your approach might be
much lighter weight.
thanks
Bob Smith
e 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.
OK, this makes sense.
thanks
Bob Smith
--
To unsubscribe from
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
today?
Because the kernel doesn't even see the hardware I'm controlling.
>
> greg k-h
Greg, sorry this message was so long, and thanks again for your patience.
Bob Smith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
was so long, and thanks again for your patience.
Bob Smith
--
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
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
), 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.
OK, this makes sense.
thanks
Bob Smith
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
inux since it can help remove
the burden of writing language specific bindings for the daemon.
thanks
Bob Smith
--
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.or
language specific bindings for the daemon.
thanks
Bob Smith
--
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/
y
>> nodes.
>
> Ok, but to do so, you have to have root permissions to start with, which
> is generally not going to happen on sane systems. Only allowing root
> access to this seems like a huge limitation.
As noted above, yes, root has to set it up and set the permi
sn't relevant at all.
Agreed. But isn't every IPC or other feature in the kernel
there because someone in user space needed it? I hope so.
>
> ASCII isn't all that its cracked up to be, you should know better than
> that :)
> And why ASCII? Why not XML? :)
You are entirely correct
system,
> what is going to be in charge of setting the permissions on these random
> device nodes?
Again, compare proxy to a named pipe. It is up the application
writer to decide who gets read and write access to its proxy
nodes.
thanks
Bob Smith
--
To unsubscribe from this list: s
And all of my other outstanding questions still remain, please address
those as well.
Yes, understood.
Greg, once again let me thank you for your patience while dealing
with an EE (who probably needs more adult supervision).
thanks
Bob Smith
--
To unsubscribe from this list: send the line "
se 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.
thanks
Bob Smith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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
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
. 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.
thanks
Bob Smith
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
still remain, please address
those as well.
Yes, understood.
Greg, once again let me thank you for your patience while dealing
with an EE (who probably needs more adult supervision).
thanks
Bob Smith
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
,
what is going to be in charge of setting the permissions on these random
device nodes?
Again, compare proxy to a named pipe. It is up the application
writer to decide who gets read and write access to its proxy
nodes.
thanks
Bob Smith
--
To unsubscribe from this list: send the line unsubscribe
that :)
And why ASCII? Why not XML? :)
You are entirely correct here.
thanks
Bob Smith
--
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
permissions to start with, which
is generally not going to happen on sane systems. Only allowing root
access to this seems like a huge limitation.
As noted above, yes, root has to set it up and set the permissions,
but this is hardly unusual, is it?
thanks
Bob Smith
--
To unsubscribe from
s with cat and
echo, it will _NEVER_ need dedicated per-language bindings.
thanks
Bob Smith
--
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-
, it will _NEVER_ need dedicated per-language bindings.
thanks
Bob Smith
--
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
expect to control an LED with a command like
this: echo 1 > /sys/class/gpio/gpio25
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
Again, I hope you don't mind the text snip and extra
with a command like
this: echo 1 /sys/class/gpio/gpio25
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
Again, I hope you don't mind the text snip and extra white space.
thanks
Bob Smith
--
To unsubscribe
eone could, in the unlikely case it ever made
sense, write a user space device driver in node.js.
thanks
Bob Smith
--
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.
made
sense, write a user space device driver in node.js.
thanks
Bob Smith
--
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
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 bsm
38 matches
Mail list logo
