| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
warnings.
|
|
|
|
| |
<janovetz@tempest.ece.uiuc.edu>.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is an enhancement to acpolish.
It replaces some Makefile variables by others variable in Makefile.ins
(tries to use unique name for some variables). It therefore eases
parsing Makefile.ins for further automatic Makefile.in conversions in
future.
To apply:
cd <rtems-source-tree>
sh <path-to>/rtems-rc-19990407-8.sh
./autogen
|
|
|
|
| |
sin_port.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the most scary of all proposals I've been mailing to you
this week until now.
It consists of 3 parts:
1. a patch
2. a perl script (acpolish)
3. a shell script wrapper to invoke the perl-script.
The perl-script reads in each Makefile.in and modifies them
("polishes/beautifies" them :-).
These modifications are not easy to describe:
Basically, it hard-codes some automake Makefile-variables and rules into
RTEMS autoconf-Makefile.ins (Note: autoconf vs. automake!!) and converts
some settings/variables to configure scripts' requirements (Yes,
plural).
E.g. it adds the automake standard variables $top_builddir and $subdir,
adds dependency rules for automatic re-generation of Makefiles from
Makefile.in, adds support variables for relative paths to multiple
configure scripts etc.
The patch is a one-line patch to enable the support of the new features
added by acpolish.
The shell script is a wrapper which pokes around inside of the source
tree for Makefile.ins and invokes acpolish on all autoconf-Makefile.ins.
acpolish is designed to be able to run several times on the same
Makefile.in and may once become a more general tool to convert RTEMS
Makefile.in to automake. Therefore, I'd like to keep it inside of source
tree. (e.g. as contrib/acpolish or c/update-tools/acpolish). However, it
doesn't make sense to export it outside of RTEMS.
To apply this:
cd <source-tree>
patch -p1 -E < <path-to-patch>/rtems-rc-19990318-1.diff
tar xzvf <path-to>/rtems-rc-polish.tar.gz
./rtems-polish.sh
./autogen
Note: The path contrib/acpolish is hard-coded into rtems-polish.sh, if
you decide to put it in an alternative place, please modify
rtems-polish.sh to reflect this change.
Later:
cvs rm make/rtems.cfg (It isn't used anymore)
cvs add contrib
cvs add contrib/acpolish
cvs commit
I've tested this intensively, but naturally I can't exclude bugs.
Ralf.
PS.: Most probably, this is the last "Towards automake" patch. The next
one probably will be a real automake patch.
|
|
|
|
| |
fcntl support and an external fcntl handler for sockets.
|
|
|
|
| |
are build issues with it.
|
| |
|
| |
|
|
|
|
|
| |
IO handlers scheme that was implemented originally just to support
sockets. The file system IO switch is more general and works fine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
|
| |
|
|
|
|
| |
is very useful when debugging a device driver.
|
| |
|
|
|
|
|
|
| |
allows one to trace the enqueueing and dequeueing of messages. This
can be used to insure that packets are getting to the boundary between
the network stack and the device driver.
|
| |
|
|
|
|
| |
Added volatile to i386 assembly statements in header checksum code.
|
| |
|
|
|
|
| |
printing messages.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
NULL pointer.
|
|
|
|
| |
so that the libc code did not have to know about (struct socket).
|
| |
|
| |
|
| |
|
|
|
|
| |
prototype.
|
| |
|
|
|
|
| |
properly in conditionals
|
|
|
|
| |
all conflicts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Eric Norum <eric@skatter.usask.ca>
Date: Sat, 5 Dec 98 13:20:51 -0600
What do you think of this patch? It implements your `tap'
suggestion in a way that adds support for all ethernet devices with
no driver modifications. I also added a return value from the tap
function. If the return value is zero, the packet will be passed up
the chain as usual. If the return value is non-zero the mbuf holding
the packet will be freed and the packet will be dropped.
If you like it, please submit it to Joel.
I guess there needs to be an addition to the network documentation
describing the additional ioctl's -- and a big warning that the tap
function is called from a context that holds the network semaphore.
Here is Eric's patch. I've tested it a bit, and made a couple of
trivial changes. This is certainly better than mine: it should work
for all Ethernet drivers.
==================================================
The only concern I have about this patch is that the tap function may
want to fiddle with the mbuf, calling functions like m_pullup and the
like. If those force the networking code to rearrange the mbuf
structure, then the caller's call to m_freem may crash. I don't know
if this is a realistic concern--I don't know enough about the mbuf
layer.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
the inet checksum routine.
|
|
|
|
|
|
|
|
|
|
|
| |
I've fixed a few minor probs with the optimised version that Eric put
together for me the other day and sent the fixes back to him. Provided he
doesn't have a problem with it we've got a pretty solid in_cksum for the
ColdFire as well as straight m68k. I've enclosed my updated in_cksum_m68k.c
At the moment my own bottlenecks are elsewhere...as my driver is pulling
16bit data chunks through a libchip-esq access routine from the chip which
for a polled I/O device is never going to be quick.
|