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 Smith
ah, if I proceed 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 unsub
but requires 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
B
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.
OK, this makes sense.
thanks
Bob Smith
--
To unsubscrib
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 under
el apis we have 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
ervices to appear in Linux 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
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 permissions,
n call, or not, it's up to them. So this
> really isn'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
&
real 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 li
o try to provide these.
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 lis
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.
thanks
Bob Smith
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
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
;cat' above is kind
of a litmus test. If a daemon interface works 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.k
ed by a newline. My
Raspberry Pi customers 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
no language bindings, someone 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
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: F
19 matches
Mail list logo
