libbsd kernel namespace generation

[Chris Johns]

On 23/7/21 5:00 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 22/07/2021 10:44, Chris Johns wrote:
>> Hello,
>>
>> Libbsd uses the pre-processor to map all the kernel calls into a libbsd kernel
>> name space by prepending _bsd_ to each symbol. The script ...
>>
>> https://git.rtems.org/rtems-libbsd/tree/create-kernel-namespace.sh?h=6-freebsd-12
>>
>> ... generates the list and the result is pushed into the repo. The symbols need
>> to be regenerated when new sources are added into the `freebsd` tree.
>>
>> The script has a few issues:
>>
>> 1. Objdump does not work on FreeBSD for different archs.
>>
>> 2. Binutils is being removed from FreeBSD base.
> 
> what would be the alternative?

The ones we build. It is not a big change to the script but one that needs to be
amde. We cannot expect the host OS to provide a suitable objdump.

>> 3. A number of BSPs need to be built to cover all the possible symbols
>>
>> I would like to document the list of BSPs a generate needs to cover. I propose:
>>
>>   arm/xilinx_zynq_a9_qemu
>>   aarch64/xilinx_versal_lp64_qemu
>>   i386/pc686
>>   powerpc/mvme2307
>>   sparc/erc32
> 
> Basically if you import code you just have to build a BSP which covers the
> imported code. Then you use ...

There are other complexities that only a handful of people in the world would
know or understand. For example you build a zynq BSP or any 32bit BSP and import
code that conditionally defines 64bit functionality then you may miss some
symbols. We have cases of this, well I am seeing them adding VFS.

>> Also the documentation says to use `git add -p` to add the changes. How does an
>> interactive add help?
> 
> git add -p
> 
> to add only the changes relevant to the imported (or removed or changed) code.

OK and this is good advice so I will add something to the doco to state this is why.

A baseline list of BSPs is also needed to regenerate the file. We cannot add for
ever because some symbols disappear over time.

Chris