Changeset 9646d5be in rtems for make/compilers/gcc-portsw.cfg

Timestamp:
02/17/98 18:46:38 (26 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
ac61209b
Parents:
e81ef51
Message:

Patch from Eric Norum <eric@…>:

I've gone through and cleaned up the TFTP driver so that it fits
into the libio system. Here's the comment from the new driver:

/*

  • Usage: *
  • To open /bootfiles/image' on hostname' for reading:
  • fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY); *
  • The `hostname' can be a symbolic name or four
  • dot-separated decimal values. *
  • To open a file on the host which supplied the BOOTP
  • information just leave the `hostname' part empty:
  • fd = open ("/TFTPbootfiles/image", O_RDONLY); * */

You can `fopen' TFTP files the same way:

fp = fopen (fullname, "r");
nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp);

The diff's are included below. I've also modified the TFTP demo
program and the bootstrap PROM example. They should be on my ftp
site `soon'.

The one thing I don't like is the way I had to do an end-run on the
libio routines to get errno passed back from my driver to the
application (since there are some errno codes that don't map to RTEMS
status codes). My approach was to set errno in the driver and have
the driver routine return an RTEMS status code that I `know' isn't in
the errno_assoc[] in libio.c.

Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or
something similar) which driver routines could return to indicate
that the driver routine has set errno and that the libio routines
shouldn't attempt to map the returned status code to errno.

Actually, I think the entire I/O system needs looking at -- as
you've already mentioned. The hacks I've dropped in to syscalls.c to
make fstat work, for example, are *not* shining examples of good
code......

(No files)

Note: See TracChangeset for help on using the changeset viewer.