Hi all.
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: 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)…
[View More];
// 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().
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).
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?
I have a menu.lst entry like this:
title The "Hello, world!" program
kernel $(A)/bootstrap -serial
modaddr 0x02000000
module $(B)/fiasco $(FIASCOARGS)
module $(B)/sigma0
module $(B)/roottask \
task modname 'simple_file_server' attached 6 modules
module $(B)/log
module $(B)/names
module $(B)/dm_phys
module $(B)/l4io
module $(B)/rtc
module $(B)/l4con
module $(B)/simple_ts -t 300
module $(B)/name_server
module $(B)/term_con
module $(B)/simple_file_server -v 14
module $(B)/os2/config.sys
module $(B)/os2/mini33.exe
module $(B)/os2/minicmd.exe
module $(B)/os2/msg.dll
module $(B)/os2/doscalls.dll
module $(B)/os2/sub32.dll
module $(B)/fstab \
-c /file \
-c /file/system -v 14 -b / -m /file/system \
-c /vc -v 132 -b / -m /vc
module $(B)/os2/os2server -d c: -m /file/system
vbeset $(VBE_MODE)
I needed to relink a term_con server to an address 0x01450000 instead of the default one of 0x01400000
because the latter was the same as with simple_ts server (0x01400000 too). I was not able to use loader
server to load at other address because I needed to launch two l4vfs servers, term_con and
simple_file_server where simple_file_server serves all files through fprov_proxy file provider (I don't want to
use an extra bmodfs server to serve files for loader -- it would be an ugly decision, I think).
The 'os2server' server uses the files that were served by simple_file_server and it tries to use l4vfs servers for
reading from stdin.
My makefile looks like this:
PKGDIR ?= ../..
L4DIR ?= $(PKGDIR)/../..
TARGET = os2server
# the default relocation address. This may be superseded by a STATIC file.
DEFAULT_RELOC = 0x01800000
# list your .c files here
# os2server.c
SRC_C = main.c utility.c io.c MountReg.c globals.c native_dynlink.c l4_alloc_mem.c \
Shared/token.c \
Shared/modmgr.c \
Shared/ixfmgr.c \
Shared/ixfmgr_lx.c \
Shared/ixfmgr_lx_load.c \
Shared/ixfmgr_ne.c \
Shared/ixfmgr_lx_fixuplx.c \
Shared/ixfmgr_lx_loadobjlx.c \
Shared/ixfmgr_lx_modlx.c \
Shared/ixfmgr_lx_execlx.c \
Shared/ixfmgr_lx_debuglx.c \
Shared/memmgr.c \
Shared/api/apistub.c \
Shared/cfgparser.c \
Shared/processmgr.c
#Shared/ow_dlfcn.c \
# if your server implements the server side of an idl defined in an idl-file
# of your package, list the idl file name(s) here (no path needed)
SERVERIDL = os2server.idl
# list additional library paths and libraries here
LIBS = -los2server -lparsecmdline -lthread -lcon -lcontxt -lconstream-server
CFLAGS = -I$(PKGDIR)/include
MODE=l4env_base
include $(L4DIR)/mk/prog.mk
Maybe some libs are interfere with l4vfs ones or something like this? I suspect the l4con server libs interfere
with l4vfs libs. For example, l4con has its own getchar() implementation but in uCLibc this function is
implemented through l4vfs backends. When I am trying to use getchar() or scanf() functions, I see that read()
function is called behind the scenes, and it don't get blocked until Enter is pressed.
So, any help is appreciated.
WBR,
valery
[View Less]
