[TangerineSDR] List of Software Modules to be Designed

Engelke, Bill bill.engelke at ua.edu
Thu Oct 24 22:24:00 EDT 2019

Hello Rob - I was not including SYSV as the IPC. 
I have seen articles discussing the POSIX approach using a backing file - see the shared memory discussion about halfway through this article: https://opensource.com/article/19/4/interprocess-communication-linux-storage

Is this the filesystem approach you mentioned? It appears to work with a sort of virtual file.

There is a follow on article by the same author which discusses using Unix sockets here:

Are there dramatic differences between these that would make a big difference in an application like we plan for the SBC?

Let's tackle the topics one at a time (we can work down thru your other thoughts next)...

-tnx fer the help es 73 - Bill

-----Original Message-----
From: Rob Wiesler <rpw10 at case.edu> 
Sent: Thursday, October 24, 2019 8:48 PM
To: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>
Cc: Engelke, Bill <bill.engelke at ua.edu>; Matthew McConnell <mjm28 at case.edu>
Subject: Re: [TangerineSDR] List of Software Modules to be Designed

On Wed, Oct 16, 2019 at 10:28 AM Engelke, Bill via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
> Here is a first pass (version 01) list of software modules needing to be designed/coded/tested/integrated for PSWS system. (The list is also attached as a file for posting).
> If you have any comments or additions, they are most welcome…

Please don't use shared memory for this.  SYSV IPC is basically dead in modern applications, and for lots of good reasons.  Instead, use a sane combination of Unix sockets, filesystem/inotify, and maybe dbus or MQTT if we have a matching use case (I don't think we do).

Local command processor:
I don't see what use this is.  That may be because the description is fairly vague.  What set of commands do you envision?  I think that comes first, before deciding that there should be a single software agent to handle them (usually it's much cleaner to talk to local software agents directly, without an intermediary).

Data upload/command dissemination:
Of course, I'm willing to help with this, but this is already the domain of others at CWRU (Matthew McConnell, in CC, who may or may not be subscribed to this list, plus a bunch of students), so ultimately none of this is my decision, even if I do the work.

Please add to the list of overall systemic components:
- Package build system
- Package repository
- Private development package repository(-ies)
- Physical test harness (for dev -> prod package migration acceptance testing (after unit testing))
  - This will be part of the CWRU PSWS infrastructure, as a last-gasp measure to make sure we don't push out anything fundamentally broken.

More information about the TangerineSDR mailing list