l4vfs and stdin/stdout handles

[Martin Pohlack]

Hi Valery,

sorry for the delay, I was a little busy in the last days.

On 22.06.2010 22:35, Valery V. Sedletski wrote:
> On Mon, 21 Jun 2010 17:29:00 +0200, Martin Pohlack wrote:
> 
>>>
>>> I checked init_io(), it seems to do the same as a fragment in term_con_test example -- it opens a terminal device
>>> and checks the file descriptors to be 0, 1, 2 (with unessential details). I forgot to mention that my program is an API
>>> server which implements an API and starts a client program using that API. I load the client program, all needed libraries
>>> for it. Then I start a function called trampoline() in a separate task, prepare an environment for the program in that 
>>> function (including file descriptors). Then I just setup registers, push params for C startup code on stack, and call an
>>> entry point in a client program.
>>
>> I think it is not so easy to transfer these FDs into another task, as
>> server state is associated with many FDs (depending on the server).
>>
> 
> Yes, transfer to another task is difficult but I meant to execute the same startup code as in init_io() but for client task, not a server.
> Now I specified '--stdin /dev/vc0 --stdout /dev/vc0 --stderr /dev/vc0' in server command line and mounted term_con at /dev. -- After that
> I got one l4con tab opened and all terminal i/o got in there. So, it works but the server owns the terminal. But it is desirable to do the same
> for client program. I start it using task server, so I cannot specify command line, so I must init terminal i/o other way.

I did a quick check how to specify command lines and didn't find a way.
 I have probably overlooked it.  Can others jump in here?

>>> I tried to add "--stdin /dev/vc0" to API server's command line. The init_io() function opens all file descriptors successfully. 
>>> Then these file descriptors seem to be inherited by a client program (if I try to open /dev/vc0 in trampoline(), it returns a fd equal 
>>> to 3, 4, 5, so 0, 1, 2 are already used). But when I try calling read(0, ...); (I call it in the API call from the client program, so the task 
>>> id at the moment is from the client program) it says that 
>>
> 
> I changed now the app behaviour, so all terminal reads and writes are performed in server stub but not in the context of a client. The server 
> owns a terminal and works with it. But it is not the intended way. Of course, I need each client program have its own std* file descriptors.
> 
>> I looked again in operations.c:init_io()
>>
>> If you do not provide "--stdin x" etc. argument, dummy FDs are put into
>> place in the local FD table, e.g., here:
>>
>>        ft_fill_entry(1, file_desc);      // fill in dummy entry
>>
>> I vaguely recall doing this to prevent accidents with printf() etc. in
>> dietlibc which had no error checking regarding invalid FDs.  I have not
>> revisited this code since we switched to uclibc years ago ...
>>
> 
> So, they're just dummy. I didn't know that ft_fill_entry() fills the local descriptor table. So, it is also needed besides just open()'ing it. But how can I
> get the file descriptor got from open() to be in a range of 0..2? It seems they are already predefined at the moment, though are dummy..

No, open uses ft_fill_entry().  But open will not reuse FDs marked as
in-use (as done by ft_fill_entry()).

* Have you tried closing them?
* Have you tried dup2()ing into them?
* You can always modify the library code to not reserve these special
  FDs if you want to.

I probably cannot give you any more detailed information regarding this
problem as I stopped developing l4vfs about 2 years ago.  Maybe a
current maintainer will jump into the discussion here ...

Alternatively, the Dresden L4 group released a new userland version
which may be supported more actively.  Maybe this is an alternative for you?

  http://os.inf.tu-dresden.de/L4Re/overview.html

HTH,
Martin