No. Somebody invented a new mechanism for something we already had, and I
still don't see the reason.
The thing we already had and that everybody is already using is called a
"tty".
> I like the EvStack concept of consoles consisting of a series of
> pluggable event handler/router modules. I like the idea of the kernel
> having a generic, flexible and fast way to pass abstract messages between
> itself and userspace. And I like the idea that any console IO device, no
> matter how wierd, can have all its capabilities encapsulated into a set of
> abstracted messages.
I'd prefer to see those "abstract messages" be abstract enough that you
can consider them to be just a character stream. That's the unix
philosophy. And, by the way, that's a tty (or a pipe or a socket - does
EvStack work naturally over the network?).
Which still means that I don't see the point for EvStack. As far as I'm
concerned, the output layer should do output (graphics or whatever), and
the input layer should do input, and the two really shouldn't ever meet.
The only current meeting point is the special case of "echo", and I'd be
more understanding if somebody told me that the current "echo" support is
limited. But on the other hand I don't really think the kernel should do
echoing at all due to the layering violation, so I'm happy with the
minimal echo support the kernel already has.
(A very rudimentary echo feature is required for a minimal console
implmentation: Linux-0.01 actually tried to avoid even that minimal echo,
and made "echo" part of the user-level reading routines, but that breaks
too many peoples expectations of what happens when the reader isn't always
active. But with a server-based approach like X11 or similar, the echo is
quite naturally done by the application like it should be).
In short, I do not buy into the argument that EvStack has anything to do
with multiple consoles or anything else.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu