bug-hurd
[Top][All Lists]
Advanced

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

Re: console stuff (was: Re: argp limitation


From: Roland McGrath
Subject: Re: console stuff (was: Re: argp limitation
Date: Mon, 11 Mar 2002 21:31:51 -0500 (EST)

> Maybe I don't know enough about the xfs protocol.  

Me either.

> But it seems to me a very good thing if the console server can copletely
> configure itself from the passive translator setting, without requiring
> to run a loadfont program or anything.

I certainly agree with that.  And having translator command line arguments
that make it look at files or whatnot is certainly fine.  The only thing I
am concerned about is that the dynamic configuration interfaces a) don't
make the server less robust by wedging on random filesystems and whatnot,
and b) properly refer to the filesystem/network/whatever view of the user
doing the configuration rather than the server's.

That second condition really means not presuming that there is any common
filesystem at all between the user and the server, so the shared temporary
file concept does not fit.

I am also not entirely comfortable with the idea of the console server
itself talking to the network.  It just seems hard to keep that robust
(though just having an extra thread blocked on the network would not harm
the rest).  And even if you are careful with avoiding blocking, it could
just be darn annoying to have your console causing the /servers/socket
passive translators start up all the time while you are busy trying to fix
the network or something.  (On the other hand, I can imagine it would be
pretty cool if all your consoles came up in some default font (or a
configured secondary preference) when not connected, and then automagically
just flipped themselves to a new font downloaded via xfs after the net
comes up.)

I suppose as long as all of these things are just done at startup-time (and
after that it doesn't have any sockets open, etc) it would be ok.  I am
presuming that the startup-time option processing will do essentially the
same lookup/conversion things to get the data that the user-side
configuration program would do for dynamic changes.



reply via email to

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