[PATCH 1/2] dhcpcd: Add rtems_dhcpcd_start()
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu May 3 07:13:22 UTC 2018
On 03/05/18 03:03, Chris Johns wrote:
> 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.
The libbsd started as a USB stack. It evolved step by step.
>
> 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.
The rc.conf approach is very elegant and good.
>
> 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.
>
For applications which support the old and new network stack it is
easier to work with function calls. I encapsulated now the DHCP client
start code into one function which is used throughout libbsd.
https://lists.rtems.org/pipermail/devel/2018-May/021314.html
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list