Clean up src/components/lib/

[gparmer]

This directory is a little schizophrenic. A look at the Makefile yields a large number of special cases. In fact, it is likely accurate to say that there is no design, and only special cases. This directory grew and accumulated functionality, and was never re-designed to accommodate it. This issue is meant to start a discussion, and I'll do the re-design as part of the booter stuff. The proposal (that is completely up for discussion...we just need a starting point for the discussion):

• The default behavior should be for the lib directory to include subdirectories, and to simply pass the build system on to them. Thus, they can define their own mechanisms for building rather than special-casing them in lib/Makefile. This means that libraries that are external (like musl) will have another layer in their directory hierarchy; lib/musl/Makefile with be Composite-specific and will appropriately use the build system in lib/musl/musl-1.1.11/.... Same with parsec and others.

• We need to support include files being in lib/x/include/ as that is the way it will be for musl, ps, etc... The question is, if we need to support this, then why do we also use include/? There is a single mandatory library, the Composite runtime (cosrt) that includes the entry addresses, stack management, thread allocation management (closure indirection), default client stubs, and component information structure (including e.g. the heap pointer). Other than that, each component's specified library dependencies will fill out both its -lxxxlib.a requirements, but also its -I header dependencies. There will need to be horrible and somewhat extreme build-foo to figure out where the proper -I include directory is for each library, but, so be it.

• Clean up the mandatory libraries. There is a ton of trash in them currently, some of which dates back to 2005. They need to be pared down solely for the reason that we want devs to have confidence that everything in them is necessary. This includes a large revisit of cos_types and consts.h which are shared between user and kernel.

• Instead of relying on 2^18 -l specifications for the scheduling library (sl), generate a .a library for each configuration. The main configuration parameters currently are 1. scheduling policy, and 2. memory management mechanism, 3. (add more here if I'm forgetting something @phanikishoreg ). Thus, we can name the different configurations using, for example, a two-tuple: sl_policy_alloc.a. For example: sl_fprr_static.a. My feeling is that this is worthwhile. Please let me know if you disagree.

These changes should clean up the directory, remove exceptions, and make the de-facto using external libraries. Paired with the proposed interface changes, in which many of the interface libraries will be moved into interface/*/, I believe this brings the consistency we need to this directory.

Comments?

@phanikishoreg @Others @ryuxin @WenyuanShao @hjaensch7

[phanikishoreg]

You're right and I think we have this problem with components\Makefile.comp also.

We need to make them or at least rip out case specifics to include rules in their own makefiles. Having to make changes to them both for including a new library in the system is not great. We should have components\lib\Makefile call into each subdirectory's Makefile and those makefiles should define standard make rules for all, clean, install, uninstall etc. Having them to copy headers to src/components/include// is probably better.
It might be useful to have a src/components/build directory and copy all headers from composite and external libraries copy to build/inc, and copy libs and objs in the same way.
Furthermore, I think we should also look into cleaning up the transfer directory and renaming it. :)
We should probably have a folder under it for runscripts seperate from how we have everything (every object) in that one directory.

For cleaning up cos_types and others, I agree with that too. We should also look into cleaning up cos_component.h or at least have cos_comp_defs.h or cos_comp_types.h for common types and definitions that are shared between components (like spdid, channelkey or something like that!). I feel like cos_component.h is kinda doing a lot.

I'm not very clear about what 2^18 is referring to. But I think we should talk about this more. The way it is right now, I agree it is confusing to know what to link to and what not to, what to include etc.

[gparmer]

@phanikishoreg Thanks for the input!

You're right and I think we have this problem with components\Makefile.comp also.

Agreed. I didn't say in the message above, but I think this proposal cleans this up.

It might be useful to have a src/components/build directory and copy all headers from composite and external libraries copy to build/inc, and copy libs and objs in the same way.

The problem with this is that there might be conflicts (same file name). I think that instead the build system just needs to know how to generate the -I lists for each component. This will likely mean dynamically generating each library's include paths from the ../lib/*/Makefile file that kicks off their own compilation.

Furthermore, I think we should also look into cleaning up the transfer directory and renaming it. :)
We should probably have a folder under it for runscripts separate from how we have everything (every object) in that one directory.

Yes. 👍 I think that runscripts will specify the components using <type>.<instance> syntax (e.g. sched.fprr), so the runscript should be able to get the binaries for each component solely from that specification. This means we don't need them all in a shared directory.

I don't know where to put the system specification files currently. Maybe src/sysspec/? Don't know.

For cleaning up cos_types and others, I agree with that too. We should also look into cleaning up cos_component.h or at least have cos_comp_defs.h or cos_comp_types.h for common types and definitions that are shared between components (like spdid, channelkey or something like that!). I feel like cos_component.h is kinda doing a lot.

Oh absolutely!!!! I haven't looked at it close enough to figure out how it should be broken up, but I completely agree it needs to be pared down, and separated.

2^18 was a bad joke ;-) Read "lots" of configurations.

@Others made the good point that the sl problem is likely better addressed by the interface revamp. Not the library revamp.

One other thing to think about: My proposal for lib looks very much like the extern/ proposal for cfe, rk, etc... I'm not that excited about adding redundant ideas.