Do not use the interface mutex in the receive loop. Avoid multiple
reads of DMA descriptor words. Use a compile-time constant for the
receive DMA descriptor count to simplify calculations.
Update #4652.
Use the transmit interface handler to avoid a transmit task/interrupt.
Use a compile-time constant for the transmit DMA descriptor count to
simplify calculations.
Update #4652.
How test media01 can be executed is described in section
*Qemu and Networking* of the README.md at the top of the
rtems-libbsd GIT repository.
When connected via `telnet` with the RTEMS shell of the
media01.exe test executed by QEMU, one can list the filesystems
available for mounting:
TLNT [/] # mount -L
File systems: / dosfs tftpfs
The list will contain `tftpfs`. The filesystem can be mounted
as in the following example:
TLNT [/] # mkdir /tftp
TLNT [/] # mount -t tftpfs -o verbose "" /tftp
A TFTP server is needed to use this filesystem. The simplest way
would be to run such a server on the host machine and open the
firewall for the TFTP protocol (port 69) on the TAP device used.
Files can then be downloaded using the usual shell commands
as in the following example:
TLNT [/] # cat /tftp/169.254.1.1:hello.txt
Uploading is also possible provided the TFTP server supports it,
for example:
TLNT [/] # cp /etc/dhcpcd.duid /tftp/169.254.1.1:myfile
By default, pfkey allocates a 2MB buffer that is used for SPD entries.
This size is a good choice for a server system where a lot of clients
should be handled. But on our embedded systems, an application with that
much clients is unlikely and 2MB is a lot of space. So reduce that to
the default value of 128kB which should be enough for a small number of
ipsec connections.
See https://bugzilla.redhat.com/show_bug.cgi?id=607361 for more details
why the upstream project originally increased the size.
If someone really needs a bigger size, there is a option in the
configuration file of pfkey called `pfkey_buffer` that can overwrite
this value.
Closes#4621
The pppstart expected that a driver write would somehow magically
process all data passed to the write function. Because ppp disables all
buffering that originally has been in termios, that assumption is not
true for all but polled drivers.
With this patch, the pppstart now gets and processes the feedback that
is returned from the driver via rtems_termios_dequeue_characters.
Update #4493
There was a typo in the patch that added the HAVE_<LIBRARY> definition
that prevented "./waf configure" from succeeding. This adds the missing
character.
Conditionally compiled tests (consisting only of debugger01) were not
compiling as expected when libdebugger was present. This appears to have
occurred during the transition from header detection or due to an
intervening change in the waf internal libraries. The result of
check_cc() is the only location this information is reported, so library
checks now set HAVE_<LIBRARY> as appropriate when the library is found
so existing code for header configuration correctly recognize that a
library is present.
Since the epoch call callbacks may lock/unlock a mutex the callbacks must be
called from within thread context with thread dispatching enabled. Use thread
pinning to ensure that the calling thread stays on the right processor. Use
the interrupt server to ensure the thread context for the epoch drain.
Changed nfs_utime() to nfs_utimens(), changed the arguments to use
a timespec array instead of individual variables for access and
modified time.
Updates #4400
setkey uses pfkey_open to open a socket. But setkey doesn't close the
socket.
The libipsec functions are used only by user space applications (setkey
and racoon). Adding the wrapper for socket makes sure that the opened
socket is registered and closes if the application exits.
Fixes#4405
Possible data sources for SD driver:
- mmc_sd_switch():
- length: 64 byte;
- buffer on stack
- mmc_test_bus_width():
- length: 4 or 8 byte
- buffer in program memory or on stack
- mmc_app_send_scr():
- length: 8 byte
- buffer from device ivar structure
- mmc_app_sd_status():
- length: 64 byte
- buffer from device ivar structure
- mmc_send_ext_csd():
- length: MMC_EXTCSD_SIZE = 512
- buffer from device ivar structure
- rtems_bsd_mmcsd_disk_read_write():
- length: depends on read
- buffer from rtems_blkdev buffer -> already aligned
- mmcsd_ioctl_cmd():
- length: depends on call
- buffer malloced, not aligned -> patched in RTEMS
So the problematic buffers are only the ones up to 512 bytes. Copy these data
into a buffer to avoid that problem.