| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
* machine/types.h, pppd/pppd.h, rtems/rtems_bsdnet_internal.h,
rtems_webserver/webmain.c: machine/types.h should not have
included rtems.h. It is now including precisely the
least amount of low level, yet portable .h files to get
the basic RTEMS types defined. This rippled into other
files since rtems_bsdnet_internal.h used machine/types.h to include
rtems.h.
|
|
|
|
|
|
|
| |
* kern/Makefile.am, lib/Makefile.am, libc/Makefile.am,
net/Makefile.am, netinet/Makefile.am, nfs/Makefile.am,
pppd/Makefile.am, rtems/Makefile.am, rtems_servers/Makefile.am,
rtems_webserver/Makefile.am, wrapup/Makefile.am: Include compile.am
|
|
|
|
|
|
| |
* rtems/rtems_syscall.c: Changed from O_NONBLOCK to internal
RTEMS_LIBIO_FLAGS_NO_DELAY to avoid O_NONBLOCK/O_NDELAY confusion
and to work with the converted flags.
|
|
|
|
|
| |
fast mutexes that bypass the API level to directly interface with the
SuperCore.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialization. This adds an interface which makes it easier to
control the BSD stack from user code. The BSD stack initialise uses
it. It is a sort of `function' interface for an ifconfig
command.
I also added support for attaching and removing interfaces. With hot
swap PCI comming online support for hot swap PCI will be an important
factor in "state of art" RTOS's. This is also part of a general move on
my part to allow RTEMS to be configured at runtime by calls rather than
table driven at initialisation.
|
| |
|
|
|
|
| |
adds .cvsignore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that contains the automake files for libnetworking plus a couple of
minor fixes. [Now only one unused/unsupported Makefile.in remains
(./c/src/lib/libbsp/hppa1.1/pxfl/Makefile.in).]
To apply:
patch -p1 < rtems-rc-20000118-7.diff
/bin/sh rtems-rc-20000118-7.rm
/bin/sh rtems-rc-20000118-7.add
./bootstrap
Notes:
* I have tested this one by building all BSPs for m68k, powerpc, sh and
unix with toolchains built since last weekend.
* I did not touch libnetworking's directory layout.
|
|
|
|
|
|
|
| |
Janovetz <janovetz@tempest.ece.uiuc.edu> to return a status from
network initialization rather than panic'ing. It changes a bunch
of rtems_panics to printfs and returns a status from
rtems_bsdnet_initialize_network().
|
| |
|
| |
|
|
|
|
|
| |
Patches against 1105 snapshot to add NTP server support to network
configuration/BOOTP.
|
|
|
|
|
|
|
|
| |
EPICS needs a synchronized time-of-day clock. This patch is the changes
needed to get NTP server information from a BOOTP server.
This patch also adds NTP server information to the network configuration
structure, too.
|
|
|
|
|
|
|
|
| |
now prototypes the malloc family in stdlib.h. This causes conflicts
with the way the network stack overrides the definitions of malloc.
As best I (being Joel) can tell, commenting stdlib.h out keeps the
files compiling and referencing the desired malloc/free but results
in more warnings.
|
|
|
|
|
|
| |
The old system would panic when the loopback interface was included as
part of the network initialation structures. With the printf you get an
message, but the interface is still properly initialized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The select function is not particularly efficient when dealing with a
large number of sockets. The application has to build a big set of
bits and pass it in. RTEMS has to look through all those bits and see
what is ready. Then the application has to look through all the bits
again.
On the other hand, when using RTEMS, the select function is needed
exactly when you have a large number of sockets, because that is when
it becomes prohibitive to use a separate thread for each socket.
I think it would make more sense for RTEMS to support callback
functions which could be invoked when there is data available to read
from a socket, or when there is space available to write to a socket.
Accordingly, I implemented them.
This patch adds two new SOL_SOCKET options to setsockopt and
getsockopt: SO_SNDWAKEUP and SO_RCVWAKEUP. They take arguments of
type struct sockwakeup:
struct sockwakeup {
void (*sw_pfn) __P((struct socket *, caddr_t));
caddr_t sw_arg;
};
They are used to add or remove a function which will be called when
something happens for the socket. Getting a callback doesn't imply
that a read or write will succeed, but it does imply that it is worth
trying.
This adds functionality to RTEMS which is somewhat like interrupt
driven socket I/O on Unix.
After the patch to RTEMS, I have appended a patch to
netdemos-19990407/select/test.c to test the new functionality and
demonstrate one way it might be used. To run the new test instead of
the select test, change doSocket to call echoServer2 instead of
echoServer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ian Lance Taylor <ian@airs.com>:
Ian Lance Taylor wrote:
>
> In rtems-19990528, sbwait sets SB_WAIT in sb_flags. sowakeup checks
> it. Why doesn't socket_select set it?
>
> I don't know that this is a bug--I haven't tried to create a test
> case. However, it certainly looks odd.
>
> Ian
Yes, there's a bug there. Sorry about that.
It was introduced when I did some cleanup on the sleep/wakeup handling
in rtems_glue.c.
|
|
|
|
| |
the stack will wait for mbufs.
|
| |
|
|
|
|
| |
network stack runs out of mbufs.
|
|
|
|
| |
that results in an error in parsing network unit names/numbers.
|
|
|
|
| |
porting of ACE to RTEMS.
|
|
|
|
|
| |
I added __INSIDE_RTEMS_BSD_TCPIP_STACK__ that trips all the needed
macro definitions for a network driver.
|
|
|
|
|
| |
the reset of the CPU specific implementations after comment from
Eric Norum.
|
|
|
|
| |
sequence.
|
| |
|
| |
|
|
|
|
| |
by Jiri Gaisler <jgais@ws.estec.esa.nl>.
|
|
|
|
|
| |
network interface names. This change does not introduce any
compatibility problems.
|
|
|
|
| |
fcntl support and an external fcntl handler for sockets.
|
|
|
|
|
| |
IO handlers scheme that was implemented originally just to support
sockets. The file system IO switch is more general and works fine.
|
| |
|
| |
|
|
|
|
| |
NULL pointer.
|
|
|
|
| |
so that the libc code did not have to know about (struct socket).
|
| |
|
|
|
|
| |
all conflicts.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Socket timeout field changed from `short' to `long'. This makes longer
timeouts possible. With a 1 kHz system clock the old system allowed
timeouts only up to a little over 30 seconds! This change is a
slightly cleaned-up version of the patch proposed by Ian Lance Taylor.
2) Major changes to BOOTP/DHCP reply handling. Now supports much of
RFC2132. These changes were done at the request of, and with the
assistance of, Erik Ivanenko.
If you're making changes, you might want to change the network
supplement Essentially just do a global search and replace of BOOTP
with BOOTP/DHCP.
|
|
|
|
| |
in include file order.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Here's a patch to make the rtems_showroute routine a little more
useful. For `host' route table entries the link-level address is now
displayed. This is equivalent to the old `show arp table'
information displayed by the KA9Q code.
|
|
|
|
| |
message after comments from Eric Valette <valette@crf.canon.fr>.
|
| |
|
|
|
|
|
| |
I have reworked the ethernet driver for the BSP pc386 and
here is the patch to apply.
|
| |
|
| |
|
| |
|
| |
|