The emu.c stuff got written because there was no gdb kernel debugger
working for Linux at the time it was written. Having done it we find it
is easier to debug outside the kernel, even with a gdb kernel debugger,
due to reboot time. It is a user-daemon-kernel interaction, no return
to user space.
I guess the daemon makes it really not an exokernel. If it was really
an exokernel, it would be the user libraries that do everything, am I
right? In exo-kernels, why the user-kernel-user mode transition? I
thought the whole thing was that they wanted to avoid that? Is security
the reason? I don't think loic@ceic.com is worrying about security, he
doesn't need it for his web crawler. He does need to be able to batch a
lot of system calls together, and debugging that in user space may be
easier.
I have mixed feelings about it.
Hans
Theodore Y. Ts'o writes:
> From: Hans Reiser <reiser@ceic.com>
> Date: Thu, 24 Jun 1999 15:25:09 +0000 (/etc/localtime)
>
> Placing the filesystem into user libraries exo-kernel style is another
> orthogonal issue. I don't want to start an exo-kernel implementation
> right now, especially not without doing it completely and systematically
> for all of the filesystem.
>
> I'm not sure what you mean by "completely and systematically for all of
> the filesystem"; I think a user library approach has the advantage that
> it indeed works for all filesystems (not just one specialized filesystem
> like NTFS 5), and for all operating systems (not just Linux). This is a
> big win!
>
> I also take issue with your calling what I described in my straw-man
> proposal as an exo-kernel approach. There isn't the user->kernel->user
> mode transition which is typical of standard exo-kernel approaches (and
> which generally incur enough of a performance penalty to be
> problematic).
>
> What I was demonstrated was a pure user-mode-only approach, just to show
> it was possible. In fact, if people want to play with filters that show
> different views of the file, I would strongly encourage that it be first
> prototyped using a userspace library approach, for the following
> reasons:
>
> 1) Application writers will likely not use this thing unless there is a
> way to get the same functionality across a wide number of Unix
> platforms.
It's called porting the filesystem. It is as feasible as porting a
library when you have access to kernel source.
>
> 2) It is easier to test out approaches and semantics in user-mode than
> in kernel mode. Doing it in kernel mode first risks doing a lot of work
> which then either has to be thrown away, or which the kernel programmer
> ends up clinging to because it represents so much investment, in spite
> of the fact that application writers are telling him that this is not
> what they want. Let's get the semantics and the functionality and the
> interfaces right first, before we try thrusting it into the kernel.
Kernel programming isn't so hard....
>
> 3) The Unix way is to try doing things using a decomposed tool chain or
> user space first, and only then pushing functionality into an integrated
> program or into the kernel if absolutely necessary. If it turns out that
> performance and maintainibility and functionality is perfectly adequate
> using a pure user-mode approach, then perhaps, just maybe, it means it
> doesn't belong in the kernel.
We'll try to write modular code.... even to make it a kernel module...:-)
>
> - Ted
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/