Roland McGrath <[EMAIL PROTECTED]> writes:
> > It's a lot easier on everything, I think.
>
> I think you are wrong.
>
> > The client can just open the file, and then hand the handle over to
> > the server.
>
> Which means that if the client wants to supply data from someplace else, it
> has
On Mon, Mar 11, 2002 at 11:27:23PM -0800, Thomas Bushnell, BSG wrote:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > > An alternative strategy (for the dynamic case) is to have the client
> > > hand a port for the file to the console server, which can then read
> > > from it exactly as if it
> It's a lot easier on everything, I think.
I think you are wrong.
> The client can just open the file, and then hand the handle over to
> the server.
Which means that if the client wants to supply data from someplace else, it
has to become a filesystem.
> The server can just read it exactly
Roland McGrath <[EMAIL PROTECTED]> writes:
> > An alternative strategy (for the dynamic case) is to have the client
> > hand a port for the file to the console server, which can then read
> > from it exactly as if it were a file (which it normally will be).
>
> Yeah, maybe. But that is certainl
> An alternative strategy (for the dynamic case) is to have the client
> hand a port for the file to the console server, which can then read
> from it exactly as if it were a file (which it normally will be).
Yeah, maybe. But that is certainly more of a burden on the server to stay
robust that j
Roland McGrath <[EMAIL PROTECTED]> writes:
> > And then the way to change that dynamically is to, well, do a setopts
> > call.
> >
> > If there is some error and it can't read the file, then it returns an
> > error and leaves the previous keymap in place.
>
> That seem utterly unacceptable to m
> And then the way to change that dynamically is to, well, do a setopts
> call.
>
> If there is some error and it can't read the file, then it returns an
> error and leaves the previous keymap in place.
That seem utterly unacceptable to me based on the principles I described.
Since you haven't r
Roland McGrath <[EMAIL PROTECTED]> writes:
> 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.
It seems to me that the ideal thing would have the passive translator
h
> 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
On Mon, Mar 11, 2002 at 04:51:03AM -0500, Roland McGrath wrote:
> That is a wacky notion, but it might just make sense. Certainly using the
> xkb utilities from X directly is an attractive idea. Not only is the
> configuration based on a compatible format, it's actually the very same
> commands
How are you handling keyboard LEDs?
> Mmmh. You know, I considered supporting a subset of the X server protocol
> for that, so that you can use an X font server which supplies the fonts to
> the console server, and xkb to configure your keyboard map. That will
> definitely not be done in the
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> From a quick glance, argp seems to be reentrant, is this really
> true? Are there any (better) alternatives?
argp (at least the version in glibc-2.2.5, which is the latest glibc I
have around) uses getopt, which is inherently non-reentrant. There
se
On Sun, Mar 10, 2002 at 07:47:23PM -0500, Roland McGrath wrote:
> If you wanted to do that, you could call another argp's parse_opt function
> from yours via the children pointers.
Ok.
> As to your particular option syntax plans for console, I can't even figure
> out what most of that means exac
argp is generic libc code now, so the questions about how best to use it
really belong on bug-glibc. But anyway, I think your conclusions are
right. I don't think argp's are intended to be used so you shadow options.
If you wanted to do that, you could call another argp's parse_opt function
from
Hi,
I wanted to use a hierarchy of argp parsers in the console server, one in
each driver module, one for focus groups, one for consoles, and one for the
main program. However, argp parents and childs shade the options of other
childs, in the sense that argp calls only one parser for each recogn
15 matches
Mail list logo
