2015-01-09 11:42 GMT+01:00 Michal Koutný <[email protected]>:
> It seems that having root FS in /root (or similar) is a good starting
> point to verify some of my ideas. I will experiment a bit and let you
> know later.
Finally (few days prior FOSDEM :-), I managed to start HelenOS with
applications loaded from filesystem backed by an ATA drive. In fact, I
"only" reordered tasks from original init. Thus I generated some
questions.
i) Despite HelenOS microkernel design, I've found there are few kernel
drivers (e.g. framebuffer, PIC, keyboard). Just asking whether I got
it right, are they historical artifacts nowadays used for easier
debugging? (Sidenote -- I'd be lost without them.)
ii) I've discovered the events mechanism (alas it's not mentioned in
the wiki). Is it meant to be an analogy to POSIX signals or rather a
way kernel can propagate asynchronous information to tasks?
iii) Last one is the most insidious. In my version of init I ran into
a page fault error raised inside VFS related libc code (below
uspace/lib/c/generic/vfs/vfs.c:175). Somehow all but one ('fqsn')
arguments of the function 'mount' are zeroed after return from
'loc_service_get_id' (line 167). This fault is not present when I
increase time between devman start and considered 'mount' call
(uspace/app/einit/init.c:213). I think that call to
'loc_service_get_id' blocks in the former case and does not in the
latter. Is there something I should know about fibrils that could
cause such a behavior? I've put relevant branch to Launchpad [1], I
tried it on IA32 build with standard 'ew.py' start script.
Thank you,
Michal
[1] https://code.launchpad.net/~werkov/helenos/early-userspace-bug
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
