Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 30 Nov 2016 18:02:10 -0600

Hello Heinz,

On 11/30/2016 10:56 AM, Heinz Junkes wrote:
> Is there a guideline how to add a new OS_CLASS to epics-base ?

I'm not aware of anything written down. The Application Developers Guide
section on the Build system lists the classes known at the time the
document was written, but says nothing about adding new classes.

> My suggestion : In addition to RTEMS : RTEMS-4.12

The value of OS_CLASS is used in a couple of different ways, so we have
to be slightly careful about which characters to use. The main uses I
know of are:

 * Source directories (e.g. src/libCom/osi/os/*, include/os/*)
 * Makefile variables (e.g. PROD_*, LIB_SRCS_*, USR_CFLAGS_* etc.)

GNUMake's variable names are more flexible that you might expect and
both . and - are legal in variable names, although the results might
look slightly strange to some people.

Note that adding a second RTEMS OS_CLASS means any support applications
that currently have something like this in their Makefiles

  PROD_vxworks = Vxxx
  PROD_RTEMS = Rxxx
  PROD_default = xxx

will try to build the workstation product xxx for RTEMS-4.12 if Base is
configured to build one of the new RTEMS targets, which is probably the
wrong target. To change that the Makefile would need an additional line
such as

  PROD_RTEMS-4.12 = Rxxx

That variable name looks a little strange as I mentioned above, and it's
a pity to have to force support module authors to add an extra line like
this.

> The next could then be RTEMS-SMP ?

Do you think you would need yet /another/ OS_CLASS for the SMP version?
I would much prefer to have one class handle both unless you really
can't avoid it, and in fact considering my discussion above I'm
wondering if the idea of adding a second OS_CLASS for RTEMS is the right
thing to do after all.

It might be better to configure the libCom build to search different
source directories depending on the RTEMS version number, or on some
target-specific setting given in the CONFIG_SITE.Common.RTEMS-<arch>
file. I will help with doing this if you want to go that way.

You could also consider putting different implementations in different
source files under osi/os/RTEMS and have the main osd*.c files #include
one or other of the implementations, but this doesn't solve situations
where your new version wants to throw away the old implementation and
just use the copy in the osi/os/posix directory. I think my previous
idea could be made to work with that.

Discussion on this from anyone else?

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System