[TangerineSDR] List of Software Modules to be Designed

[Engelke, Bill]

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:
https://opensource.com/article/19/4/interprocess-communication-linux-networking

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…

IPC:
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.