fopen() on /dev/console

[Joel Sherrill]

On Fri, Feb 14, 2020 at 10:11 AM Sebastian Huber <
sebastian.huber at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200214/21998fcb/attachment.html>