* libc/ioman.c: Moved to libfs.
* libc/Makefile.am: Removed ioman.c as part of moving it to libfs.
* libc/base_fs.c: Removed include of imfs.h and reworded comment
to avoid being IMFS specific.
* libc/libio.h: Removed prototype of IMFS_ops since it should
not be in this file.
* libc/mount.c: Removed IMFS specific configuration information.
* libc/unmount.c: Removed include of imfs.h and reworded comment
to avoid being IMFS specific.
* libc/Makefile.am: Added mallocfreespace.c.
* libc/mallocfreespace.c: New file based on work by Nick Simon
<Nick.SIMON@syntegra.bt.co.uk> which he included in malloc.c.
* libc/libcsupport.h: Added prototype for malloc_free_space().
<charles.gauthier@iit.nrc.ca>, and Darlene A. Stewart
<Darlene.Stewart@nrc.ca> to add support for a number of very
significant things:
+ BSPs for many variations on the Motorola MBX8xx board series
+ Cache Manager including initial support for m68040
and PowerPC
+ Rework of mpc8xx libcpu code so all mpc8xx CPUs now use
same code base.
+ Rework of eth_comm BSP to utiltize above.
John reports this works on the 821 and 860
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]
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>.
<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.
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.
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.
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.
