bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netfs part of a console server with server-client model


From: Marcus Brinkmann
Subject: Re: netfs part of a console server with server-client model
Date: Sun, 2 Jun 2002 23:22:58 +0200
User-agent: Mutt/1.3.28i

On Sun, Jun 02, 2002 at 11:09:30PM +0200, Niels Möller wrote:
> So if you have N virtual terminals, then you also have N instances of
> "display" and N instances of the "input". That makes it clearer.

Yes.
 
> But what about the actual multiplexing of N virtual terminals onto 1
> screen and keyboard? I thought that was also part of the console
> server, but now it seems that has to be a separate program. Which
> makes some sense, I just don't remember that being mentioned before.

Well, I don't know if this was explicitely mentioned, but it is certainly a
logical consequence of the separation, and this was discussed (first
mentioned by Roland, then followed up by me).

The consoles are created on the fly, but "ls root_node/" works, and lists
all virtual consoles available.  A display client can get this list, attach
itself to all nodes and provide console switching based on that.  It can
also possibly request dir_change notifications that make it possible to
notice it when new consoles are created or old ones are destroyed.

> > I am not sure what you have in mind.  Maybe it is useful to provide raw
> > write access to the text matrix in the console server.
> 
> That's a nice-to-have thing. Consider an alternative curses backend
> that doesn' use the old fashined escape sequences. There may be other
> interesting uses (like, display hacks), but I guess it's not terribly
> important.

Yeah, sure.  It makes sense to separate the display and input port for that.

> > 1/console -> for term
> > 1/display -> r(w) to screen content
> > 1/input   -> w(r) to input queue
> 
> The only point of having display and input be children to the console
> node is that if I'm given only a port to the console (say, it's my
> process' stdin), I can easily get to the raw display with a single
> dir_lookup on that port. But one could of course use some other rpc
> for that, if needed.

Mmmh.  Interesting thought.  I will ponder it, but the usefulness is not
very high, considering that there is usually term between you and the
console anyway.  Or term would have to support it to.  One way to get that
info is to look up your ttyname node and look at the translator settings.
 
Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]