Comtrol eCos - Manual (Page 505)

Chapter 37. Support Features
TFTP
The TFTP client and server are described in tftp_support.h ; the client API is simple and can be easily under-
stood by reading tftp_client_test.c .
The server is more complex. It requires a filesystem implementation to be supplied by the user, and attached to the
tftp server by means of a vector of function pointers:
struct tftpd_fileops {
int ( ∗ open)(const char ∗ , int);
int ( ∗ close)(int);
int ( ∗ write)(int, const void ∗ , int);
int ( ∗ read)(int, void ∗ , int);
};
These functions have the obvious semantics. The structure describing the filesystem is an argument to the
tftpd_start(int, struct tftpd_fileops ∗ ); call. The first argument is the port to use for the server.
As discussed in the description of the tftp_server_test above, an example filesystem is provided in
net/common/VERSION /src/tftp_dummy_file.c for use by the tftp server test. The dummy filesystem is not a
supported part of the network stack, it exists purely for demonstration purposes.
DHCP
This API publishes a routine to maintain DHCP state, and a semaphore that is signalled when a lease requires
attention: this is your clue to call the aforementioned routine.
The intent with this API is that a simple DHCP client thread, which maintains the state of the interfaces, can go as
follows: (after
init_all_network_interfaces() is called from elsewhere)
while ( 1 ) {
while ( 1 ) {
cyg_semaphore_wait( &dhcp_needs_attention );
if ( ! dhcp_bind() ) // a lease expired
break; // If we need to re-bind
}
dhcp_halt(); // tear everything down
init_all_network_interfaces(); // re-initialize
}
and if the application does not want to suffer the overhead of a separate thread and its stack for this, this function-
ality can be placed in the app’s server loop in an obvious fashion. That is the goal of breaking out these internal
elements. For example, some server might be arranged to poll DHCP from time to time like this:
while ( 1 ) {
init_all_network_interfaces();
401