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.) _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
