[Cryptech Core] proposed core reorganization

[Paul Selkirk]

On 03/10/2015 09:37 AM, Peter Stuge wrote:
> Rob Austein wrote:
>> Not just creating new ones.  Intent is to rename the ones we're
>> keeping and delete the ones that we think are completely useless.
> 
> Yes, I think renames too are fine, but deleting non-empty ones
> without having that history somewhere else?

The repo currently named core/novena_eim has the history of our
thrashing around with Bunnie's EIM code, before Pavel completely rewrote
it. It might be of mild interest to someone, but it never produced a
usable result. Even today, it doesn't work - the working code is in
test/novena_base and user/paul/core. The whole point of the reorg
exercise is to be able to promote the working EIM code to core, in a way
that's hopefully a little easier to navigate. So core/novena_eim can go
away.

core/novena is really the top-level for Novena with I2C, and will
effectively be moved to platform/novena/i2c, or whatever else we want to
call it.

core/novena_i2c_simple was something I cons'd up as a more efficient,
but also more application-specific, I2C interface to the hash cores.
Joachim is right that it never should have been in core/ in the first
place, so it can be moved to test/.

core/coretest_hashes is two things: a top-level module for the Terasic
platform, and a project-specific mux for the particular combination of
uart + sha cores. The mux part has been obsoleted by core_selector, and
the top-level is part of platform/terasic.

core/coretest_test_core is a dummy project, which is intimately bound to
core/test_core, and is a prime example of how the current ad-hoc
arrangement of cores is getting us into trouble.

I suppose I don't object in principle to archiving the current state of
the core/ tree (in say archive/ or historical/), but it will need a
user's guide.

>> whereas with the ten zillion separate repositories there's no
>> history mechanism for rearrangements of the repository tree itself.
> 
> Sure there is, a single top level repo has each of the zillion repos
> as submodule. History of that repo tracks rearrangements, even though
> history of the zillion repos is not atomic.

It may be a religious question, but what is the advantage of having a
super-repo with a bunch of repos as submodules, versus having one
honking big repo? I could understand it if the repos are hosted on
different servers, but all of the cryptech repos are hosted on the
cryptech server, and they are furthermore somewhat inter-dependent.

				paul