summaryrefslogtreecommitdiffstats
path: root/c/src/lib/libnetworking/rtems/rtems_syscall.c (unfollow)
Commit message (Collapse)AuthorFilesLines
1999-10-04Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de> to make libnetworkingJoel Sherrill1-760/+0
a top level more independently configured package.
1999-03-31Patch from Eric Norum <eric@skatter.usask.ca> which changed the exitJoel Sherrill1-2/+1
sequence.
1999-03-30Patch to add shutdown() routine from Tony R. Ambardar <tonya@ece.ubc.ca>.Joel Sherrill1-0/+25
1999-03-19Patch from Eric Norum <eric@skatter.usask.ca> that adds externalJoel Sherrill1-4/+30
fcntl support and an external fcntl handler for sockets.
1999-03-01Patch from Eric Norum <eric@skatter.usask.ca> to eliminate externalJoel Sherrill1-13/+34
IO handlers scheme that was implemented originally just to support sockets. The file system IO switch is more general and works fine.
1999-01-28Patch from Eric Norum <eric@skatter.usask.ca> to avoid dereferencing aJoel Sherrill1-1/+4
NULL pointer.
1998-12-10Merged Eric Norum's select patch that was based on 4.0 and resolvedJoel Sherrill1-89/+14
all conflicts.
1998-12-07Patch from Ian Lance Taylor <ian@airs.com>:Joel Sherrill1-2/+2
RTEMS permits using the SO_SNDTIMEO and SO_RCVTIMEO socket options to set a timeout for most socket I/O operations. However, in RTEMS 4.0.0, those options do not affect connect or accept. I don't know of any way to put a timeout on those calls in RTEMS 4.0.0; can anybody point to one. Since it is frequently useful to have a timeout on accept, and sometimes useful to have a timeout on connect shorter than the BSD system default of 75 seconds, the following patch causes SO_RCVTIMEO to affect connect and accept.
1998-09-29Patch from Eric Norum <eric@skatter.usask.ca>:Joel Sherrill1-3/+2
Remember the test to see if a socket could be read and written at the same time by two different tasks? I discovered that if both tasks attempt to close the socket a panic can occur from inside the BSD code. Closing the same socket twice from two different threads is certainly an error, but a panic is not the greatest error reporting method :-) The following small change to the socket close routine should reduce the chances of the panic.
1998-08-20Patches from Eric NorumJoel Sherrill1-3/+17
1998-08-20Added CVS IdsJoel Sherrill1-0/+4
1998-08-20Fixed many warnings.Joel Sherrill1-0/+1
1998-08-19Base filesJoel Sherrill1-0/+743