Hi Ladislav, Steve, You are both correct but to me personally, such an effort feels misguided simply because it would further increase the complexity of libsigrok while cementing its role in the architecture.
>From my perspective, the only sane way to move forward is to push libsigrokflow. Having a block-based data flow provides the only truly manageable way to extend sigrok without creating dependencies and legacy crutches. Creating a new block that provides data to the sigrok pipeline would not only be completely decoupled from all other blocks, it would also not matter which language it's written in. That's where I'd like to go. Cheers, -Soeren On Wed, 2025-10-15 at 11:33 +0200, Ladislav Laska wrote: > That makes a complete sense and would allow to decouple the device > drivers. I've personally written some munin plugins and while the > complexity is nowhere near what sigrok needs, it would make sense. > > The API calls would have to be translated somehow. If anybody would want > to go through this effort, I'd like to see a TCP/IP support too (we > could then run the driver on some single board computer and connect > remotely). Or maybe I'm talking nonsense and there is a better way of > doing that. Just pushing my ideas out there :-) > > Cheest, > Ladislav > > > On Wed, Oct 15, 2025 at 10:50:06AM +0200, Steve Schnepp wrote: > > Actually, I specifically asked because I wanted to see if I could > > write a generic stdin/stdout driver that could simply move that > > heavy-lifting in "user space" as an external process written in > > whatever language. > > Much like what libfuse is to filesystems. > > > > Rationale : I'm coming from the munin monitoring system where every > > plugin is a full standalone executable that can be a shell script, > > python or C, depending on the need. > > > > Cheers, > > -- > > Steve Schnepp > _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
