Re: placing console clients and library

[Roland McGrath]

> Some people would go as far as saying that choosing the right names for
> variables etc is the most difficult problem in programming :)

It's certainly the one that people argue about most fervently.

> I agree.  However, what I want to avoid is to add lots of directories to
> the top level right now, for only a few files.  Eg, there could be a
> libbdf for bdf font support, or a libfont for generic font support of
> which bdf is just one module.  OTOH, currently it is just a bdf.c and
> bdf.h which is most conveniently compiled into the single program that
> uses it.

Agreed.  And at some point it will become painfully obvious how silly our
names are and that we need to prefix them all with something containing
"hurd" or else we must be insane, and noone wants to make that day come sooner.

> Maybe I am just mega-lazy, and confused by your Makefiles :), which sort
> of endorse a flat directory hiearchy.

Not as lazy as me, or I would have fixed the makefiles by now!
They ain't my makefiles, they're Thomas's.

> How does creating a new directory for the console server
> ("console-server"?) sound, and leaving the client in "console/"?

I don't have strong opinions, really.  But "console" seems fine enough for
the server, since it's called /hurd/console (right?), and from the
Unix/POSIX perspective the server is what's the "console".  I'd say here
"console" means the console device from the system's perspective, not a
physical console from the user's perspective.  The PC/VGA client might be
called "the console console client" (as distinct from "the curses console
client" or "the VNC server console client"), to use both meanings at once. :)
We should come up with a naming convention for the client programs,
foocons or foo-console or console-foo or consfoo or something or other.
Then your client will fit naturally into that as pccons or console-console
or whatever.

> I am not sure which of these two ways it will go, but I would think the
> latter makes more sense.  When I do everything right with the libcons
> library, the only thing left in the client will be the hardware specific
> stuff, but I still see room and merit for a framework which allows to
> plug in various different hardware support.

I tend to agree.  After all, on a single machine installation you could
have many different kinds of hardware that you want to support and maybe
hot swap.