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.
The reentrant versions of the malloc functions in
c/src/lib/libc/malloc.c
do not match the definitions in newlib. These will be used if you use
newlib routines such as fdopen. I believe this patch to malloc.c is
needed to provide the correct versions.
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.
I fixed the problems noted by Victor Vengerov.
1) Fix typo in cfsetispeed().
2) In rtems_termios_open, ensure that args->iop->data1 is set before calling
device-specific open routine.
I think I figured out why rtems_panic was locking up instead of
shutting down the executive and returning to the code that called
boot_card().
Later on there is code to print some messages on the standard error
stream, a recursive call back to rtems_verror (through rtems_error)
and finally a call to _exit().
I think that the _Thread_Disable_dispatch() is preventing the final
context switch back to the boot_card() code. Does this sound right
to you?
"Thomas Doerfler" <td@imd.m.isar.de> wrote:
>
> While implementing/testing the console/termios support for
> PPC403 in RTEMS-4.0.0-beta3, I am stuck at a certain location in
> termios.c:
>
> During "rtems_termios_initialize", the main control data structure
> "*tty" is allocated using malloc(). (Note, that malloc does not
> clear the allocated memory and my BSP does not clear memory during
> startup). Furtheron, a lot of fields of that structure are
> initialized, but the field "rawOutBufState" is not, and therefore
> keeps an arbitrary contents.
>
> When "osend()" is called the first time(with the serial device
> driver working in interrupt mode), termios gets stuck and will not
> call the device drivers output function.
>
> My questions now are:
>
> - anybody already experienced this bug?
> - is it a bug at all or did I do anything fundamentally wrong?
> - is there already a common bugfix for that?
>
> I don't like poking around in other people code, as long as I am
> not absolutely sure, what I do...
Yes, there's a bug there.
I thought that Joel had patched this already, but here's a patch to
fix this. This patch also addresses a concern that many others have
raised regarding enabling and disabling of transmitter interrupts.
First, here's the example I've been using of a simple UART-style
interrupt-driven driver:
===============================================================
void
device_write_routine (int minor, char *buf, int count)
{
UART->control_register &= ~UART_TRANSMITTER_READY;
UART->output_register = *buf;
UART->control_register |= UART_TRANSMIT_INTERRUPT_ENABLE;
}
void
device_transmit_interrupt_routine (int vector)
{
UART->control_register &= ~UART_TRANSMIT_INTERRUPT_ENABLE;
rtems_termios_dequeue_characters (device_ttyp, 1);
}
==============================================================
Several people have expressed their concern about the disable/enable
of transmitter interrupts for every character. On some machines
this disable/enable is an expensive operation. With the attached
patch applied you can write the two routines as:
==============================================================
void
device_write_routine (int minor, char *buf, int count)
{
code_to_clear_transmitter_ready_status ();
if (device_ttyp->rawOutBufState == rob_idle)
code_to_enable_transmitter_interrupts ();
code_to_send_one_character_to_transmitter (*buf);
}
void
device_transmit_interrupt_routine (int vector)
{
rtems_termios_dequeue_characters (device_ttyp, 1);
if (device_ttyp->rawOutBufState == rob_idle)
code_to_disable_transmitter_interrupts ();
}
===============================================================
returned a buffer which was not zero-filled, the reference count
was not correct. When the application exitted, the "lastClose"
handler was not being called to flush the output. This problem
had manifested itself on a variety of platforms.
The function rtems_termios_dequeue_characters() incorrectly incremented
the buffer pointers when it was invoked and there were no characters
in the ring buffer. This problem had also manifested itself on a
variety of platforms. The symptom was a strange repeating of the
data in the transmitter buffer when the transmitter serial device
was supposed to go idle.
Haven't had a chance to do an extensive shake-out of 980710, but it
builds just fine on FreeBSD 2.2.5 (after termios is fixed using the
attached patch), and the tests run fine. FYI: FreeBSD doesn't support
System V IPC out of the box, but one only needs to add three options
to the kernel build configuration file, recompile the kernel, and
you're ready.
of seconds since 1988 from RTEMS and not adding in the 1970-1988 correction
factor. Plus removed checks for data/time set since POSIX does not permit
this call to fail. GNAT 3.12 depends on this.
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.
code in each BSP's bspstart.c. These changes were:
+ confdefs.h now knows libio's semaphore requirements
+ shared/main.c now copies Configuration to BSP_Configuration
+ shared/main.c fills in the Cpu_table with default values
This removed the need for rtems_libio_config() and the constant
BSP_LIBIO_MAX_FDS in every BSP. Plus now the maximum number of open
files can now be set on the gcc command line.
I've gone through and cleaned up the TFTP driver so that it fits
into the libio system. Here's the comment from the new driver:
/*
* Usage:
*
* To open `/bootfiles/image' on `hostname' for reading:
* fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY);
*
* The `hostname' can be a symbolic name or four
* dot-separated decimal values.
*
* To open a file on the host which supplied the BOOTP
* information just leave the `hostname' part empty:
* fd = open ("/TFTP//bootfiles/image", O_RDONLY);
*
*/
You can `fopen' TFTP files the same way:
fp = fopen (fullname, "r");
nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp);
The diff's are included below. I've also modified the TFTP demo
program and the bootstrap PROM example. They should be on my ftp
site `soon'.
The one thing I don't like is the way I had to do an end-run on the
libio routines to get errno passed back from my driver to the
application (since there are some errno codes that don't map to RTEMS
status codes). My approach was to set errno in the driver and have
the driver routine return an RTEMS status code that I `know' isn't in
the errno_assoc[] in libio.c.
Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or
something similar) which driver routines could return to indicate
that the driver routine has set errno and that the libio routines
shouldn't attempt to map the returned status code to errno.
Actually, I think the entire I/O system needs looking at -- as
you've already mentioned. The hacks I've dropped in to syscalls.c to
make fstat work, for example, are *not* shining examples of good
code......
