l4vfs and stdin/stdout handles

Martin Pohlack mp26 at os.inf.tu-dresden.de
Sun Jun 20 14:19:29 CEST 2010


Hi Valery,

huh, many questions :-).

On 20.06.2010 12:08, Valery V. Sedletski wrote:
> I am trying to make a test using l4vfs libc backends so the three predefined file descriptors 0, 1, 2 work for 
> stdin, stdout and stderr correspondingly. It appears that these file descriptors are already predefined for some 
> purpose:

Depending on the IO backend used the 3 standard file descriptors are
already opened for you.

> when I am trying to open files like this:
> 
>   // open initial file descriptors
>   // stdin
>   fd = open("/vc/vc0", O_RDONLY);
>   LOG("stdin: fd=%d, errno=%d", fd, errno);
>   // strout
>   fd = open("/vc/vc0", O_WRONLY);
>   LOG("stdout: fd=%d, errno=%d", fd, errno);
>   // stderr
>   fd = open("/vc/vc0", O_WRONLY);
>   LOG("stderr: fd=%d, errno=%d", fd, errno);
> 
> -- like in term_con_test example for term_con server, the 3, 4, 5 descriptors are returned from open().

This is what you expect in an posix environment, where your shell passes
these on to you on fork.

As there is no real fork support in l4vfs, I implemented special
parameters which are evaluated and eaten before main() is executed in
pkg/l4vfs/lib/libc_backends/io/operations.c:init_io().  These parameters
trigger the open to the VCs for you (--stdin, --stdout, --stderr).

> If I not use term_con at all, and not open vc0 three times as above, read(0, ....); and write(1,....); works but 
> strangely. For example, read() returns immediately with no error and returns a single symbol (EOF, I think). But 
> as I tested in Linux and OS/2 operating systems, when stdin is a console, read(0,...); must block until '\n' is 
> returned (user pressed an Enter key).

Not sure what happens here, IIRC, dietlibc behaved a bit strange when
printf etc. was used on invalid FDs.  These days you will probably be
using uclibc, right?  Maybe you are using the minimal_io backend, this
may just ignore reads.

> So, it seems that the file descriptors 0, 1, 2 are reserved, but they are not working as expected. Maybe, my 
> setup is incorrect or something is not yet implemented?

It is quite likely that something is not implemented here.  For example,
if you use the minimal_io backend, only write to 1 and 2 is implemented.
 There is some documentation, for example, in
pkg/dietlibc/lib/backends/README.

I haven't touched the source in the last two years, maybe others have a
more current view on things?

HTH,
Martin




More information about the l4-hackers mailing list