On Fri, Feb 14, 2020 at 10:11 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> 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. > There are multiple file descriptors. Each thread opens it independently. > > 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 ); > } > I debugged to that call and then realized if I used "a", it wouldn't call it. > > Are there some rules for character devices? What happens on FreeBSD or > macOS? > I haven't looked there. Hopefully someone can answer that. I'm not going to be able to produce an example before the close of business today though. I have reached out to a POSIX contact on what he thinks. But I'm also prone to do what makes us have the same behavior as the others. --joel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel