removing unused third-party headers (objbsd)?

Joel Sherrill joel at rtems.org
Sat Jun 29 15:16:09 UTC 2024


On Fri, Jun 28, 2024 at 7:30 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Fri, Jun 28, 2024 at 10:41 AM Gedare Bloom <gedare at rtems.org> wrote:
> >
> > On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber
> > <sebastian.huber at embedded-brains.de> wrote:
> > >
> > > On 28.06.24 00:42, Gedare Bloom wrote:
> > > > I've been doing back through my third-party source code attribution.
> > > > I've found that there is a chunk of header files that are apparently
> > > > not included anywhere in rtems, and that are third-party headers. Is
> > > > there any reason we can't get rid of them?
> > >
> > > These files are included from Newlib header files and are used by the
> > > legacy network stack and libbsd.
> > >
> > Ok, thanks. The legacy network stack is maintenance-only. Any updates
> > to these files will result in divergence and breakage?
> >
> > I think we need to split these files out of rtems.git. Likely the
> > current versions need to be copied into legacy network stack, and the
> > libbsd should provide its own versions?
> >
> > -Gedare
>
> This got me to thinking there may be other header files that are
> potentially not used in rtems.git, and of questionable value to keep
> there:
>
> cpukit/include/rtems/vmeintr.h
> cpukit/include/rtems/spurious.h
> cpukit/include/rtems/score/smplockseq.h
> cpukit/include/rtems/score/smplockmcs.h
> cpukit/include/rtems/rtemsdialer.h
> cpukit/include/rtems/mptables.h
>
> Anyone have insight on whether these headers are unused, or are used
> in other dependent repos and should be considered for migration?
>

mptables. is mentioned in a comment in spsize. The file mptables.h has
been empty since 2003. As best I can recall, it contained the declaration
for the distributed multiprocessing configuration.

spsize may itself be hopelessly out of date. It prints the size of various
data structures allocated by RTEMS during initialization and shows the
formula for computing memory usage. I don't remember anyone touching
the math in ages. Probably a candidate for removal as well.

spurious.h isn't included but the method it prototypes is defined by
one BSP.

$ grep -r Spurious_Initialize

cpukit/include/rtems/spurious.h:  { Spurious_Initialize, NULL, NULL, NULL,
NULL, NULL }
cpukit/include/rtems/spurious.h:rtems_device_driver Spurious_Initialize(
bsps/m68k/mrm332/include/bsp.h:void Spurious_Initialize(void);
bsps/m68k/mrm332/start/bspstart.c:extern void Spurious_Initialize(void);
bsps/m68k/mrm332/start/bspstart.c:  Spurious_Initialize,
bsps/m68k/mrm332/start/spinit.c:void Spurious_Initialize(void)

Perhaps a rename in the BSP and remove the header file since bsp.h
prototypes it.

vmeintr.h is not included and uses the namespace VME_interrupt.
No implementation exists of anything in that namespace. Remove it.

That is three that can go. I think doing them one commit at a time
would be preferred to me at least.



> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240629/5cd62157/attachment.htm>


More information about the devel mailing list