Duplicate getprotobynumber() in 4.5.0-beta3a was Re: Problem building gateway

[Chris Johns]

Joel Sherrill wrote:
> 
> This problem report is because there is a real and dummy version of
> getprotobynumber() and getprotobyname().  The real code works
> by parsing a real file and will work if a real file is instantiated.
> But the old code just looked things up in a structure.
> 
> If you disable lib/getprotoby.c, then you must setup the
> support files for the networking (like /etc/hosts, etc).
> 
> Aren't there other cases like this in the stack where if the file
> does not exist, it is created with default information or something
> is looked up in a structure. 

I am not sure if other cases exist. I could only see the one. A number
of files are required by the stack (grep /etc ...) :

  /etc/hosts.equiv
  /etc/hosts
  /etc/networks
  /etc/protocols
  /etc/services
  /etc/resolv.conf
  /etc/ethers
  /etc/host.conf
  /etc/publickey
  /etc/rpc
  /etc/netid

outside the stack :

  /etc/group
  /etc/passwd

The list does not include a number of files used by the ppp code.

> If so, then I can see modifying
> libc/getprotoent.c to default to the static table when the fopen()
> fails.  This would require renaming the routines in lib/getprotoby.c
> and invoking them when the fopen() fails.  Minor change.

This adds another change to the TCP/IP stack making an upgrade of the
stack harder.

Will you do the "minor change" for all cases listed above ?

> Comments?  I would like to resolve this before cutting a release.

I have added some of the files using the IMFS and found this easy and
clean to add. If you are using the full TCP/IP stack, the extra RAM used
for the files is small. With the bin commands ls, cat etc debugging
these files is simple. I also append entires to the files based on the
bootp response which would be harder with the table version.

I would prefer to see support for the files being added rather than
changes to the stack. The stack is currently documented in terms of the
files. Making changes like this will require extra documentation. Other
package moved to RTEMS could also use files. Having to provide an non
file approach could effect these. The ppp code is an example of this.


-- 
 Chris Johns, mailto:cjohns at cybertec.com.au mailto:ccj at acm.org