search

nasa / osal

The Core Flight System (cFS) Operating System Abstraction Layer (OSAL)
Apache License 2.0
552 stars 215 forks source link

divide osconfig.h three ways #87

Open skliper opened 5 years ago

skliper commented 5 years ago

The current osconfig.h (present in BSP trees and, as a bonus, in the build/inc directory) contains configuration items that are OSAL generic, plus configuration items that are BSP specified, and probably items that are OS specified.

The content of this file needs to be divided.

Items that are generic OSAL configurations need to be in a header file located centrally.

Items that are specified by the OS should be kept in a header file within the appropriate /os/ tree; probably a good idea to have this file included by the generic configuration file, to provide "sane defaults" in the central file (where there can be sane "most OS" values), then have the OS-specific file override those as appropriate.

Ditto for the BSP.

skliper commented 5 years ago

Imported from trac issue 64. Created by glimes on 2015-06-30T15:05:34, last modified: 2019-08-14T14:11:46

skliper commented 5 years ago

Trac comment by jphickey on 2015-07-08 16:38:56:

First step here....

Pushed commit [changeset:efe5b97] that updates the {{{src/bsp/pc-linux/osconfig.h}}} file to be a correct/usable sample configuration for pc-linux and removes the version that was in {{{build/inc}}} to eliminate confusion here.

skliper commented 5 years ago

Trac comment by jphickey on 2015-07-08 16:40:50:

Proposing that the commit above becomes part of the next OSAL merge as the multiple copies of osconfig.h are causing some difficulties that this may help alleviate.

There is more to do under this ticket though, so not marking it as work_complete yet.

skliper commented 5 years ago

Trac comment by glimes on 2015-07-10 11:41:52:

Should we split this ticket, to track the "move stuff into the BSP header" separately from "architect a solution that recombines BSP-independent stuff in a non-BSP header"?

skliper commented 5 years ago

Trac comment by jphickey on 2015-07-10 12:43:06:

Maybe I shouldn't have hijacked this ticket for that ... but moving osconfig.h to the BSP was such a trivial thing I didn't want to open a new ticket just for that.

So my vote is no - I don't think we need a separate ticket...

skliper commented 5 years ago

Trac comment by acudmore on 2015-07-10 15:13:42:

I support the idea of breaking this apart, or at least partitioning the file to make it clear where the generic OS specific parameters are vs the BSP/target OS/architecture options are.

If we split this up and make a generic OS option file that is centrally located, will this apply to any OSAL application? Or are we just talking about the location in context of the standalone OSAL distribution?

I want to make sure we have the ability to tailor all of the parameters in the OSAL for different targets, even in the same build tree.

If this is the intention, then I recommend accept

skliper commented 5 years ago

Trac comment by glimes on 2015-07-13 13:31:45:

Recommend accept of [changeset:efe5b97] which updates the osconfig.h in pc-linux and deletes the one currently being tracked in build/inc.

I'll make a note to be sure to not sweep up this Trac ticket when this changeset gets committed to development.

skliper commented 5 years ago

Trac comment by glimes on 2015-07-16 10:30:17:

Initial change included in [changeset:ec67bd4 2015-07-14 development merge], now present on Babelfish and IPAS-LIB. Leaving this ticket open to track the reorganization issue.

skliper commented 5 years ago

Trac comment by glimes on 2015-07-16 10:43:11:

Side note: this broke the Classic build. See #97 for details.

There is an obvious short term fix, but the longer term fix is of course to include a Classic build in our Bamboo plan, which is being tracked by that ticket for the CFS-OSAL plan.