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.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
