| Commit message (Collapse) | Author | Files | Lines |
|---|
|
There seems to be an ugly dependency between posix-headers and
libcsupport.
Configuring rtems with
../rtems-rc-19990324-0/configure \
--target=i386-rtems \
--prefix=<somewhere> \
--disable-posix
"make RTEMS_BSP=pc386" results into:
[...]
/opt/rtems/bin/i386-rtems-gcc --pipe
-B/users/rtems/src/multi/build/pc386/lib/ -specs bsp_specs -qrtems
-I/users/rtems/src/multi/build/pc386/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -c -o o-pc386/utime.o
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c
In file included from
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:16:
/opt/rtems/i386-rtems/include/utime.h:4: sys/utime.h: No such file or
directory
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
`struct utimbuf' declared inside parameter list
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
its scope is only this definition or declaration,
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
which is probably not what you want.
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c: In function
`utime':
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:34:
dereferencing pointer to incomplete type
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:34:
dereferencing pointer to incomplete type
make[4]: *** [o-pc386/utime.o] Error 1
make[3]: *** [all] Error 1
make[2]: *** [all] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/lfs/poseidon/users/rtems/src/multi/build/c'
make: *** [all] Error 1
Apparently sys/utime.h is one of the posix headers and therefore gets
not installed (I suppose this is correct).
IMO, this probably indicates that sys/utime.h has to be moved to another
include subdirectory and should not be part of the posix-package.
[AFAIK, sys/*.h are system dependent headers, so why should it be a
posix-header? - Hmm]
|
|
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.
|
|
|
|
|
|
would work. At the same time, the initial implementation of F_SETFL
was added. A support routine was added to convert internal libio
flags back to the POSIX style. Eventually the internal representation
should be eliminated in the interest of simplicity and code reduction.
This problem was reported by Jake Janovetz <janovetz@tempest.ece.uiuc.edu>.
|
|
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).
|
|
<ian@airs.com> to fix this problem:
There is a small bug in __rtems_close in c/src/lib/libc/libio.c. It
does not check whether the file descriptor it is passed is open. This
can cause it to make a null dereference if it is passed a file
descriptor which is in the valid range but which was not opened, or
which was already closed.
|
|
|
|
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.
|
|
and RPC support to RTEMS. Thanks. :) Email follows:
Hello,
For Xmas, here is the Remote Debugger on RTEMS !
Here are 2 patches for the Remote Debugger on RTEMS for pc386 from Linux
host :
- one for RTEMS it self,
- one for GDB-4.17.
1/ RTEMS patch
--------------
This patch adds 2 libraries :
- a simplified SUN RPC library
- the Remote Debugger library
The configuration command is the following :
../rtems4/configure --target=i386-rtemself --enable-rtemsbsp=pc386
--enable-rdbg
The SUN RPC library is built only if networking is set.
The RDBG library is built if networking and enable-rdbg are set.
The function used to initialize the debugger is :
rtems_rdbg_initialize ();
A special function has been created to force a task to be
in a "debug" state : enterRdbg().
The use of this function is not mandatory.
2/ GDB-4.17 patch
-----------------
This patch create a new RTEMS target for GDB-4.17.
The configuration command is the following :
./configure --enable-shared --target=i386RTEMS
To connect to a target, use :
target rtems [your_site_address]
Then, attach the target using : attach 1
And... Debug ;)
You can obtain the original GDB-4.17 on
ftp://ftp.debian.org/debian/dists/stable/main/source/devel/gdb_4.17.orig.tar.gz
This has been tested from a Debian 2.0.1 linux host.
|
|
|
|
overhaul of the RTEMS system call interface. This base file system is
the "In-Memory File System" aka IMFS.
The design and implementation was done by the following people:
+ Joel Sherrill (joel@OARcorp.com)
+ Jennifer Averett (jennifer@OARcorp.com)
+ Steve "Mr Mount" Salitasc (salitasc@OARcorp.com)
+ Kerwin Wade (wade@OARcorp.com)
PROBLEMS
========
+ It is VERY likely that merging this will break the UNIX port. This
can/will be fixed.
+ There is likely some reentrancy/mutual exclusion needed.
+ Eventually, there should be a "mini-IMFS" description table to
eliminate links, symlinks, etc to save memory. All you need to
have "classic RTEMS" functionality is technically directories
and device IO. All the rest could be left out to save memory.
|
|
with libchip.
|
|
1. Finally fixes raw interrupts for pc386
2. Makes some minor cleanup in console and startup
3. Makes rtems_termios_dequeue_characters() to return count of
outstanding chars - it allows to simplify console isrs a little
bit.
4. pc386 uart modified to be friendlier to termios parameter changes,
to have minor performance improvement and to take advantage of
of above termios modification.
|
|
|
|
|
|
|
|
|
|
|
|
Eric Norum per request from Geoffroy Montel:
> The rtems_termios_enqueue_raw_characters function type is void.
> The problem is that I can't return an error message if the input
> buffer is full.
> Could we add a return value?
Sure, but what would you do with the overflow indication? POSIX says,
``when the input limit is reached, the saved characters are thrown away
without notice''.
Anyhow, the change is so small I've done it and enclosed the patch.
|
|
|
|
|
|
support for device driver support on tcsetattr(), and hardware
flow control callbacks.
|
|
a result of enabling the newlib POSIX directory.
|
|
|
|
Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working
with different shells and relative/absolute paths.
What I did is relatively simple in principle:
Instead of setting RTEMS_ROOT in configure.in and then let configure
substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile
set RTEMS_ROOT from each Makefile's @top_srcdir@ value.
The difference is subtile, but with enormous side effects:
- If RTEMS_ROOT is set in configure, then the same single value will be
propagated to all Makefiles. This breaks using relative paths, as the
relative path to the root of the source tree is used inside of all
subdirectory Makefiles.
- Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is
computed individually by configure for each single Makefile.in, hereby
receiving the correct value, no matter if relative or absolute paths are
used.
To get this working, I needed to remove setting RTEMS_ROOT from
target.cfg.in, because this overrides the value of RTEMS_ROOT from each
individual Makefile.
Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all
"include $(RTEMS_CUSTOM)" directives with"include
$(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this,
but I think, to have one variable less is clearer and easier to
understand than having several variables refering to the next one.
I enclose a small patch to this mail, which
- fixes the config.h problem (to finally clearify misunderstands)
- removes assignment/subsitution of RTEMS_ROOT from configure.in
- contains a workaround for the application Makefile's RTEMS_ROOT
problem (reported by Eric)
- removes some unused lines from the toplevel Makefile.in
- removes assignment of RTEMS_ROOT from make/target.cfg.in
|
|
|
|
|
|
properly reflect the const on the buffer pointer being passed in.
|
|
any directory in the build tree. The only variable which must be set
before the command "gmake" is invoked is RTEMS_BSP (e.g. RTEMS_BSP=erc32).
|
|
|
|
|
|
|
|
|
|
Added new entry point to add in per physical port resource requirements.
|
|
|
|
|
|
to lib/include.
Went to using a PROJECT_INCLUDE variable.
|
|
|
|
|
|
|
|
|
|
|
|
(Sapporo, Japan) submitted the extended console driver for the
MVME162LX BSP and the POSIX tcsetattr() and tcgetattr() routines.
This device driver supports four serial ports, cooked IO, and
provides a portable base for Zilog 8530 based console drivers.
|
|
<cjohns@plessey.com.au>. This patch includes the ods68302 bsp,
the RTEMS++ class library, and the rtems++ test.
|
|
<cjohns@plessey.com.au>. This patch includes the ods68302 bsp,
the RTEMS++ class library, and the rtems++ test.
|
