Remove cfe_es_devsrvr code

nasa / cFE

The Core Flight System (cFS) Core Flight Executive (cFE)

Apache License 2.0

408 stars 200 forks source link

Remove cfe_es_devsrvr code #47

Closed skliper closed 4 years ago

skliper commented 4 years ago

cfe_es_devsrvr.c and .h appear to be stale/obsolete and not being called or referenced by anything else in cFE.

Furthermore, it should be deprecated anyway since device-support code logically fits better within the PSP. At the cFE layer it should be all hardware-independent code.

If this is correct, these two files should be removed from the build.

skliper commented 4 years ago

Imported from trac issue 16. Created by jphickey on 2015-01-02T14:53:13, last modified: 2019-03-05T14:57:55

skliper commented 4 years ago

Trac comment by jphickey on 2015-01-26 14:56:09:

Branch "trac-16-remove_devsvr_code" pushed for this -- Commit [changeset:13569c321]

Removes unused API calls CFE_ES_RegisterDriver() and CFE_ES_UnloadDriver(). These only returned "CFE_ES_NOT_IMPLEMENTED".
Removed cfe_es_devsvr.c and cfe_es_devsvr.h. These two files were not even being built.

It does not make much sense to have device driver load/unload functions within the CFE. Device drivers fit more logically as component of the PSP.

See [https://babelfish.arc.nasa.gov/trac/cfs_psp/ticket/3] for a proposal on an easy way to do this as part of the PSP.

skliper commented 4 years ago

Trac comment by jphickey on 2015-04-06 11:37:49:

This is ready for review/merge

skliper commented 4 years ago

Trac comment by acudmore on 2015-04-07 08:58:32:

We were keeping this in the cFE source tree, hoping to finish it one day. We certainly have this code in CM and old release tar files if we ever want to get it back.

I agree that we should remove it until we decide what to do. It is worth taking a fresh look at the device model before trying to implement it. The PSP location is a good thought too.

Recommend accept.

skliper commented 4 years ago

Trac comment by jphickey on 2015-04-07 09:52:13:

I think a device model (in general) is a very necessary thing in order to keep device access consistent and sane particularly if we are looking at promoting app sharing/re-use.

FYI - CCSDS SOIS has a proposed reference architecture for dealing with devices. This architecture describes both an application level and a platform level abstraction. I think whatever we do in cFE should at least be compatible with what SOIS has defined. The PSP would serve as the platform level abstraction and I think the application level abstraction could be done as a separate CFS application.

skliper commented 4 years ago

Trac comment by glimes on 2015-04-07 12:53:34:

Tested changeset [changeset:13569c3] as part of the ic-2015-03-10 merge.

skliper commented 4 years ago

Trac comment by glimes on 2015-04-13 15:20:15:

Part of integration candidate 2015-03-10, committed to cFS CFE Development branch on 2015-04-10 as part of merge [changeset:7d6f6d0].

skliper commented 4 years ago

Trac comment by glimes on 2016-02-25 10:17:32:

these will be fixed in CFE 6.5

skliper commented 4 years ago

Trac comment by jhageman on 2019-03-05 14:57:55:

Milestone renamed