Linux 用户空间 exe 的 IPC 传递
我们有一个程序，我们称之为 Y.exe。它运行在嵌入式系统上，并且运行时无需退出（即系统启动，加载Linux内核，所有内核模块，然后Y.exe，并且Y永远不会返回（用户空间））。
现在有时我们需要更改 Y.exe 的运行方式，即打开一些调试，使其采用某些其他代码路由进行测试等。
当前的方法是编译，然后重新编译 Y 来处理每次测试。这看起来很花时间，我们应该能够动态设置条件。
我很想使用内核中的 proc/debug 系统之类的东西，您可以简单地执行以下操作：
echo 1 > /proc/test_y
启用测试等。
看到 proc/debug 是内核级项目，它们不能用于用户空间可执行文件（？ ）。
除了通过消息Q或TCP实现完整的IPC之外，还有其他方法来实现类似的功能吗？
谢谢。
We have a programme, lets call it Y.exe. It runs on an embedded system and it runs without exiting (i.e. the system starts, loads the Linux kernel, all the kernel modules, then Y.exe, and Y never returns (user space)).
Now there comes a time when we are required to change how Y.exe is running i.e. turn on some debug, make it take certain other code routes for tests, etc.
The current way of doing this is to compile, and recompile Y to handle each test. This seems like a waist of time and we should be able to dynamically set the conditions.
I would love to use something like the proc/debug system from the kernel where you can simply do something like:
echo 1 > /proc/test_y
to enable tests, etc.
Seeing that the proc/debug are kernel level items, they cannot be used for user space executables(?).
Apart from implementing a full on IPC through message Q's or TCP, are there any other ways to implement similar functionality?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它是否在每次事件循环迭代中检查某处是否存在标志文件？
为
SIGUSR1设置信号处理程序？ SIGUSR2？发生任何这些情况时，在程序中设置一个标志值，该标志值将执行测试或输出调试信息，然后在收到另一个标志值后进行切换，或者标志文件消失等。
类似上面的东西应该实现与以下类似的功能你说的是。信号会更直接（而且可能更直接），但任何一种机制都应该足够了。
Have it check for the existence of a flag file somewhere through each event loop iteration?
Set a signal handler for
SIGUSR1?SIGUSR2?Upon any of these occurring, set a flag value in the program that will perform the tests or output the debugging information, and then is toggled after receiving another, or the flag file disappearing, etc.
Something like the above should achieve similar functionality to what you're talking about. The signals would be more immediate (and probably more straightforward), but either mechanism should be sufficient.