[En-Nut-Discussion] Attempting to fix network config API.
Thiago A. Corrêa
thiago.correa at gmail.com
Wed Aug 20 16:23:20 CEST 2014
Even Nut/OS hacks are better quality than most of what I see
available in embedded :D
Anyway, the important thing is that we are fixing them now.
NutDhcpIfSetup works but we already have NutIfSetup for static
config, how does NutStaticIfSetup sound to you?
Thiago A. Correa
On Wed, Aug 20, 2014 at 5:50 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Hi Thiago,
> in general I share your opinion about the current network configuration.
> Nut/OS folklore:
> In early time we, egnite, had a US customer, who wanted to use Nut/OS.
> However, he insisted on DHCP, which wasn't available and had been
> "hacked in" somehow within a few days. Too me, it is a major example for
> how long such hacks survive. It had been discussed in this list many
> times and several cosmetic changes had been applied. But actually
> Nut/Net DHCP had been an inflexible piece of crap since it was
> introduced. Some Nut/OS examples using this API are even worse. If I
> remember correctly, running the FTP server example once may result in a
> hard-coded IP address stored in NVRAM. If Ethernuts in our network got
> duplicate IP addresses, I typically comment: "Oh, someone ran the FTP
> server example on these boards." -- EOF --
> On 20.08.2014 04:11, Thiago A. Corrêa wrote:
>> Any suggestion for names? I wouldn't like to append numbers to the
>> API names. It would be best if we could reuse the current names (break
>> current behavior). Just occurred to me to make it a configure option,
>> to select old/new behavior.
> There had been several incompatible changes during the last months. At
> least most, if not all of them had been unavoidable and can be disabled
> by configuration. We, including some of our customers, do have several
> applications, which run fine with all versions of Nut/OS 4. But moving
> them to version 5 is usually a pain. Due to the lack of a related
> document (how to migrate from version 4 to version 5), you need some
> knowledge about Nut/OS internals and some time to figure out, why your
> app stops working on the latest Nut/OS release.
> Adding new incompatibilities just to keep API names would worsen this
> situation without need. I also agree: Just adding numbers to existing
> API names like NutDhcpIfConfig_3_() is simply ugly.
> I'd recommend to create new names. For example, the prefixes
> [Nut]NetSetupXxx() seem to be unused. If this new implementation
> requires duplicate code, go ahead. Duplicate code is bad, but breaking
> existing code is always worse.
More information about the En-Nut-Discussion