[PATCH 1/2] dhcpcd: Add rtems_dhcpcd_start()

Chris Johns chrisj at rtems.org
Thu May 3 01:03:23 UTC 2018


On 03/05/2018 10:30, Joel Sherrill wrote:
> On Wed, May 2, 2018, 4:35 AM Sebastian Huber <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>     On 02/05/18 11:01, Chris Johns wrote:
>     > This is duplicating this code:
>     >
>     >
>     https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-rc-conf-net.c#n632
>     >
>     > It is a documented way to run DHCP [1].
> 
>     The FreeBSD compatible initialization is nice, but not every application
>     should be forced to use the rc.conf based initialization approach.
> 
> I have to disagree. We don't need multiple ways of initializating something.
> 
> The value of following the FreeBSD model is high.

Yes, a key requirement we have for this project, which has been there from day
1, is a need for transparency and this means transparent source, drivers,
commands, documentation and initialisation.

This change hacks a small piece of FreeBSD to do something specific, what about
all the other parts of FreeBSD we want to support, vlan, wifi, etc? Note, vlan
is already supported per FreeBSD documentation with rc.conf.

As indicated there are other ways the initialisation, ie command, can be wrapped
by an RTEMS thread to detach the user's initialisation flow from the DHCP
server's worker thread.

>     >
>     > The change no documentation and seems rather custom. This approach was a flaw
>     > with the legacy stack and I would prefer we do not follow. It allows
>     > applications to be created that use it which means we need to maintain
>     this forever.
> 
>     It is a simple refactorization of the default-network-init.h code. For
>     some applications this is just the right thing to do.

I hope you are not serious? This file is under the testsuites tree and for good
reason, it is a local custom hack to get tests working. I do not think it is
installed. A patch to move away from this file to something rc.conf based for
the tests would be most welcome by me and so this file could radically change or
be removed.

Any user encouraged to use this file and this method for initialisation is being
mislead. We are free to make changes to these types of interfaces. We will
maintain rc.conf initialisation as documented by FreeBSD.

>     In terms of libbsd documentation, yes, this is an open issue in general.
>     Its likely more than one week of work which I don't have at the moment.
> 
> 
> That's just unfortunate and not a good reason to take shortcuts.

Agreed.

Chris


More information about the devel mailing list