[PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

[Sebastian Huber]

On 06.02.23 05:16, Chris Johns wrote:
> On 3/2/2023 6:31 pm, Christian Mauderer wrote:
>> This patch tries to make the most important goals of LibBSD development
>> more clear based on the results of the discussion on the mailing list:
>>
>> https://lists.rtems.org/pipermail/devel/2023-January/074164.html
>> ---
>>   CONTRIBUTING.rst | 39 ++++++++++++++++++++++++++++++---------
>>   1 file changed, 30 insertions(+), 9 deletions(-)
>>
>> diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
>> index 0b6fc7a0..31561f6a 100644
>> --- a/CONTRIBUTING.rst
>> +++ b/CONTRIBUTING.rst
>> @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the
>>   FreeBSD source are permitted, and some other topics.  For building the library,
>>   see the `README <README.rst>`_.
>>   
>> -Goals of the LibBSD activity are
>> -
>> -* provide functionality from FreeBSD to RTEMS,
>> -* ease updating to future FreeBSD versions,
>> -* ease tracking changes in FreeBSD code,
>> -* minimize manual changes in FreeBSD code.
>> -
>> -We will work to push our changes upstream to the FreeBSD Project and minimize
>> -changes required at each update point.
>> +Every change to LibBSD has to consider the following points in groups of
>> +descending priority:
>> +
>> +#. Real-time Impacts + Maintainability Loss
>> +   * LibBSD itself doesn't make any real time claims because it is basically
>> +     FreeBSD and they don't make any real time claims either.  But all
>> +     development in LibBSD must make sure that the real time ability of the
>> +     RTEMS core system or the application is not affected.
>> +   * It's utterly important that LibBSD is simple to maintain.  One of the most
>> +     important points for that is that upgrades to newer FreeBSD versions have
>> +     to be easy.
> Correct and it is important we adopt and use what FreeBSD provides rather than
> adding extra complexity. I wrote about this in the FreeBSD journal years ago.

We already have a file descriptor to file object mapping in RTEMS so 
adding an additional file descriptor to file object mapping on top of it 
makes little sense. The libbsd should add complementary functionality 
otherwise you could just use FreeBSD directly.

By adding the FreeBSD file descriptors you added a lot of unnecessary 
complexity. The FreeBSD file descriptor handing has to meet a couple of 
requirements which are not present in the RTEMS context.


> The bespoke handing of fd and file objects is something I consider an unneeded
> complexity for specific system related reasons. We need NFSv4 and that uses VFS
> and that in turn uses the FreeBSD fd and file objects.

This conclusion is simply wrong. You don't need the FreeBSD file 
descriptors for the VFS support. See:

https://github.com/sebhub/rtems-libbsd/tree/filedesc

For VFS you need a proper struct file object associated with a file 
descriptor. For sockets, you don't need a struct file object.

What is your hard technical reason to keep the FreeBSD file descriptors?

> 
> Source transparency is what matters and as a test of what is acceptable it must
> be preferred between competing implementations.

Whatever source transparency is, it is just one aspect out of many.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/