[En-Nut-Discussion] RFC: Extending Network Configuration

[Thiago A. Corrêa]

Hi there,

  I'm glad I'm not the only one unhappy with the current config
interface :) I'm all for changing it ( Althought I'm a nobody here in
the comunity, we would need the blessing of those with cvs write
access ).

   Anyway, I just wanted to point out that there is DNS support in
ethernut already.... althought not being saved at all, which is sad.
So Applications which use DNS, like mine are all storing it in their
own data. Just wanted to point out ;)

Cheers.

On 10/31/06, Michael Jones <Michael.e.Jones at web.de> wrote:
> Hello!
>
> I'm currently working on adding a few things to Nut/OS. One being SNTP
> resolution via DHCP. In the course of this I have stumbled across a few
> details that require some changes.
>
> The first is that the NUTCONF structure will have to grow to add IP
> Addresses for DNS (two entries) and NTP. There is not much what we can do
> about NUTCONF growing - it was bound to happed one day - so anybody that has
> data stored in the EEPROM right behind NUTCONF will have to shift that data.
>
>
> The second set of changes is how NutNetIfConfig2(...) / NutNetIfSetup(...)
> works. Currently everything is passed as parameters so adding DNS and NTP
> and whatever will come next will make these functions very unhandy. I
> therefore am suggesting a set of functions to set and retrieve individual
> NutConfig options (see below).
>
> The final addition results from the current situation that different modules
> have to refer each other due to them having to exchange information. One
> example being that NutDnsConfig(...) is called by DHCP to activate any
> received DNS servers, thereby forcing the DNS to be linked whenever DHCP is
> used. And there are other examples that force similar dependencies. Using a
> common NutConfig interface will remove some of these dependencies as all
> modules would retrieve and store information independent of each other. But
> not all, as one problem still remains; in the above DHCP example the actual
> DNS addresses are delivered at a "random" time. The DNS would therefore have
> to be notified that something actually has changed. I therefore propose a
> global notification sub system which allows individual modules to subscribe
> to and broadcast notifications between each other (see below).
>
>
> Suggested functions for the NutConfig addition:
>
> void NutConfigSetMac(CONST char *adapter, u_byte *mac);
>  int NutConfigGetMac(CONST char *adapter, u_byte *mac);
>
> void NutConfigSetIpAddress(CONST char *adapter, u_long ip_addr);
>  int NutConfigGetIpAddress(CONST char *adapter, u_long *ip_addr);
>
> void NutConfigSetNetMask(CONST char *adapter, u_long ip_mask);
>  int NutConfigGetNetMask(CONST char *adapter, u_long *ip_mask);
>
> void NutConfigSetGateway(CONST char *adapter, u_long ip_gateway);
>  int NutConfigGetGateway(CONST char *adapter, u_long *ip_gateway);
>
> void NutConfigSetAssigedIpAddress(CONST char *adapter, u_long ip_assigned);
>  int NutConfigGetAssigedIpAddress(CONST char *adapter, u_long *ip_assigned);
>
> void NutConfigSetDns(CONST char *adapter, u_long ip_dns1, u_long ip_dns2);
>  int NutConfigGetDns(CONST char *adapter, u_long *ip_dns1, u_long *ip_dns2);
>
> void NutConfigSetNtp(CONST char *adapter, u_long ip_ntp);
>  int NutConfigGetNtp(CONST char *adapter, u_long *ip_ntp);
>
>
> Suggested functions for the notification interface:
>
> HANDLE NutNofifySubscribe(void *filter <currently unused>, void (*callback)
> (HANDLE, u_int identifier, void *arg1, void *arg2));
>
> void NutNofifyUnsubscribe(HANDLE handle);
>
> void NutNofifyBroadcast(u_int identifier, void *arg1, void *arg2);
>
> Calling NutNotifyBroadcast(...) will call all subscribed callback functions
> passing the given parameters to it. A callback function will be required to
> keep processing to a minimum and return as soon as possible. The filter
> parameter in NutNotifySubscribe(...) should be NULL if no filter is assigned
> (and until we actual have implemented it).
>
>
> So... that's it for now - looking forward to your comments!
>
> Cu,
> Michael
>
>
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>