On 14/02/2020 17:02, Joel Sherrill wrote:
Hi
I was porting some code from Linux to RTEMS. It doesn't use stdin/out,
error directly but does all debug IO to a configured file. Most of the
time
when running on Linux, the device is /dev/stderr. For the RTEMS port,
I added link(/dev/console, /dev/stderr) to the init task and that worked.
The locking is done at the FILE object level, if you use multiple FILE
objects with a single file descriptor you may get mixed output.
But the application uses fopen(name, "w") to open the logging file.
This works on Linux. On RTEMS, this failed because "w" implies
ftruncate() and that returned -1.
I got around this by changing the logging helper to use fopen(name, "a").
I haven't done a POSIX deep dive and consulted with my POSIX contacts
yet for a strict POSIX ruling but I think we probably want the "w" to work
on RTEMS if it works on Lnux.
I can put together a test case but I would like to settle on the accepted
behavior first.
This is probably because of our rtems_filesystem_default_ftruncate()
implementation:
int rtems_filesystem_default_ftruncate(
rtems_libio_t *iop,
off_t length
)
{
rtems_set_errno_and_return_minus_one( EINVAL );
}
Are there some rules for character devices? What happens on FreeBSD or
macOS?
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
