[TangerineSDR] Seeking your Review and Comment on Tangerine SBC Functional Specification

[Rob Wiesler]

On Thu, Sep 26, 2019 at 2:48 PM Engelke, Bill <bill.engelke at ua.edu> wrote:
> You may notice that there are a number of things we have dreamed about which are not included in the Functional Spec (but may be included in  the Future Concepts section). This spec is intended to capture Phase 1 (i.e., what we are going to do that is NSF-funded).  We plan to made the system modular so that if volunteer developers wish to contribute additional work outside the major scope, they can do that.

I notice that the 24-hour ring buffer is still specified for Phase 1.
I thought we had decided to remove that?  It should still be possible
to add back in the future.  (It doesn't bother me if it stays in - I'm
just trying to get my memory of the meeting at DCC in order.)

Since the Local Host (SBC) is physically connected to (or at least
co-located with) the DE, I'm not sure if there are any security
concerns there at all?  So long as unprivileged users can't reprogram
the DE, and reprogramming the DE is either atomic or restartable (i.e.
a partial update won't brick the DE), that should be fine.

As I mentioned at DCC, the Case PSWS has an additional "Guiding
Principle" not listed in the functional specification: the system
shall not enter a state during which a power cycle would break it in
ways not automatically rectified when power comes back on.  This means
that all updates will be atomic (which isn't really the case on Debian
systems by default, although it's been getting better over time).

I'm not sure I see any particular value to network discoverability
(3.5.6) beyond what a normal Debian system already does, at least as
far as Phase 1 is concerned.  If there's anything on the local network
that needs to talk to a TangerineSDR, that should probably be
configured explicitly.

In the caption for Figure 4 in section 3.6, I'm not sure what you mean
by waiting for files to close.  Closing a file in a modern operating
system is not an expensive operation, so long as you don't
subsequently block on syncing the file to disk (which we won't).  If
you mean that you want real-time processing of data by the Central
System, I don't really see an issue, as there's no reason why we
couldn't send data-to-be-uploaded through the network to the database
at the same time as we store it to disk (as you would in a typical
Store-Forward architecture).  (If this paragraph doesn't make sense to
you, that's because I'm having trouble understanding the comment at
the end of the caption.)

I know it was just mentioned as an example, but there's no reason to
add a dependency on mender.io .  That's just extra complexity we'll
have to manage, and quite possibly vaporware to boot.  I'd much rather
rely on a normal Debian system update, with our software packaged in a
side repo, backed by a simple system to make sure updates are atomic
(btrfs snapshots and an initramfs hook to roll back partial changes in
case of a powercycle, for example) and don't require user intervention
(just a matter of configuring dpkg correctly) by default.  In any
case, we need to make sure that operating system updates *and*
PSWS-specific updates are handled identically, and are both atomic and
non-interactive.

(I'm going to be experimenting with setting up such a system in the
near future.  I'll keep you all informed.)

ACK the rest of the changes.

(There's some indication that the list may not like .edu addresses.
Apologies if I have to resend this.)

--
73 DE AC8YV