Hi Michal,
On 01/29/2015 11:13 PM, Michal Koutný wrote:
> 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.)
The kernel framebuffer and keyboard is just a debugging feature that can
be omitted during configuration. The PIC is kind of necessary (and also
duplicated to some extent in uspace) right now, but we have been long
planning on moving it to uspace completely too.
> 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?
It's not an analogy to POSIX signals, because tasks cannot send each
other events directly. It is always the kernel who initiates the "event"
as a response to some real event in the system. Our kernel events have
undergone some development. Initially they were only for singleton,
system-wide events, but later their possibilities increased.
> 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.
I will try to have a look tomorrow.
Jakub
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
