Re: argp limitation

[Roland McGrath]

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 yours via the children pointers.  That latter style is what I would
have suggested to begin with, I think--it's simple and clean for a
parse_opt to just consume as many arguments as it wants to rather than
having argp somehow involved in the control flow of what is conceptually a
procedure call at that point in the argument parsing anyway.

libstore in fact has both ills.  Its lack of modularity is the --layer and
--interleave options, which are type-specific options for a couple of
particular types.

As to your particular option syntax plans for console, I can't even figure
out what most of that means exactly.  (I don't think something other than
options is better, presuming it would be either some stupid configuration
file or a hairy set of state-setting RPCs/ioctls, both of which are worse.
The options approach is easy for us to do deal with, and fits as well as
anything with whatever friendly front-end most people will actually want to
use to configure their system.)  You'll have to remind me how precisely
this is all structured and what all the options mean.  I think the idea of
presenting a virtual directory of nodes on which to fsysopts might be much
easier to operate than a real hairy nesting option syntax.  That definitely
makes it much easier to understand what is going on with an fsysopts query.
It's also about the only thing that makes sense for having separate logins
on separate vts with each one allowed to control only its own settings.

That would be a somewhat strange thing to implement for using fsysopts,
because given the fsys_set_options protocol each different node has to
technically be its own filesystem.  I'm not sure there's much extra work
there, it's just different from any program we have now.  It seems like it
ought to be fine if lookups still work as in any other filesystem rather
than doing an fsys_getroot dance with itself, and the nodes don't need to
report themselves as being translated or roots--just doing file_getcontrol
on each one will get you a different fsys port.

The other obvious thing to do is not use fsysopts at all (for the
fine-grained controls anyway), but instead create new RPC protocols
understood by the appropriate particular nodes in the virtual directory.
(They could be ioctls if there are any interfaces worth being compatible
with.)  Using fsysopts is not a proper way to do things like font loading
(or anything read from a file), anyway.  You really want the user making
the configuration call to supply the data directly; it might not even exist
in any filesystem the user and the console server have in common.  (For
such things you can either define new RPC protocols or do overloaded
virtual file things if those seem clean interfaces, such as a .../fontdata
file that you just io_write a whole font to might not be bad.)