Messages in this thread | | | Date | Thu, 24 Jun 1999 11:52:32 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: albods are not a clean set of orthogonal primitives (was Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!) |
| |
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.
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.
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.
- Ted
- 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/
| |