TSEM code organization.

[Dr. Greg]

Good morning Paul, I hope your weekend is going well or your week is
starting well, whenever this e-mail finds you.

We've been waiting for the release of 6.8 for the V3 release of TSEM.
TSEM seems to be co-habitating with it reasonably well, modulo some
atomic structure magazine refill issues we are sorting out that appear
to be caused by workqueue scheduling latency differences between this
kernel and older kernels, so we are getting ready to push the V3
release.

Casey has previously raised an issue with the fact that we used a
single include file, tsem.h, for all of the entities that are global
to the various compilation units.  We placed that file first in the
patch series so that it could be referenced for review as the
individual compilation units were added.

Everything in that file has a 'tsem_' prefix on it, in one way or
another, so that anyone looking at the code knows that if that prefix
is seen the definition for whatever it is can be found in the global
include file.

Casey advocates that we break the global file into individual include
files that pair with the compilation units and we do appreciate the
concern behind that.  However, given that all of the compilation units
reference these global values in one way or another, we will then have
a model where we are introducing code that is using definitions of
things that are not yet available.

You are the final judge and jury on this so we would look to your
advice on how we should proceed.  We maintain TSEM across multiple LTS
branches so if we are going to go through the code churn this requires
we only want to do it once and get it over with.

We will look forward to your recommendations on this.

Have a good week/end.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project