Re: placing console clients and library

[Marcus Brinkmann]

On Wed, Jun 26, 2002 at 12:01:18AM -0400, Roland McGrath wrote:
> That all sounds good, except perhaps some of the names. 

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

> Most of the input
> stuff, and some of the output stuff like fonts, is not really specific to
> PCs or VGA.

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.

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

So the only pressing question is what we call the directory which contains the
initial PC client, which might (and should) evolve into a generic client.  As
"console" is already taken, maybe it should be "console-client".  Or
what is now in console/console.c and console/display.c should be in
"console-server/" ("consolefs" is just too silly) and the client
stay in "console/".  Note that there are currently more files for
the client in "console/" than there are for the server, because I
kept the server tightly into a few files only until the naming
issue is resolved.  So this makes even sense economically. ;)

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

> So if PC keyboards and VGA is what you mean by the "PC
> client", then some pieces belong in a more general library of stuff for
> (some) console clients.  
> 
> If what you mean is a client for display hardware and keyboard/mouse input
> hardware, then the parts specific to PC keyboards or to VGA should be in
> device-specific (which is not to say CPU-specific) file structure.

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.
Maybe even something with dynamically loadable modules, so you can hot
plug the hardware.  And "hardware" here can mean virtual hardware, too,
of course, like VNC.  But I am not having concrete ideas or plans about that
stage of development, as I am still focused on libcons version 1 and the
client which will initially only support PC hardware to some limited
extent.  Keeping the names generic sounds like a good idea to me.


Thanks,
Marcus