[Nut-upsdev] RFC: allow HID subdriver's to register ups.conf

[Peter Selinger]

Hi Jo,

this might work, but perhaps it is too complicated for what you want
to achieve. I would be reluctant to make major changes to main.c, as
this affects all drivers, entails a lot of testing, etc. Think e.g. of
the help messages that --help would have to generate for drivers with
subdriver specific switches. 

I think the straightforward, and much more conservative solution is to
simply add the -x wait options to newhidups, and document in the help
string and man page that these have an effect for Belkin devices
only. (You could even produce an error message if these options are
used on another device). This solution is less general, but the
problem at hand does not seem to require a very general solution, so I
would go with the conservative one. 

-- Peter

j T wrote:
> 
> Hi Peter
> 
> Don't ya just love insomnia? ;-) While I wasn't managing to get any sleep 
> last night, my head was running over the whole driver/subdriver command 
> line/ups.conf options thing and I *think* I have a way to make it work.
> 
> I've just found out that I'm not working today or tomorrow, so I'm going to 
> have a bit of an explore of my idea to find out how well it works.
> 
> Basically the idea is to split things up for drivers that support 
> subdrivers.
> 
> In order to avoid break exisiing drivers, I'm planning to add a 
> driver_has_subdrivers variable at the top of main.c, initialised to 0, which 
> can then be overridden by newhidups (and any other driver that has 
> subdrivers with command-line options (not that any exist at this time so far 
> as I know...)) as driver_has_subdrivers=1 . Selection of the operation with 
> respect to command-line handling then gets controlled by "if 
> (driver_has_subdrivers)".
> 
> This should mean that essentially, nothing has changed for the other 
> drivers, and they should compile and run as before. There will be a few 
> extra comparison operations performed when the driver is run, but on a 
> modern machine, the few extra processing cycles used shouldn't make any 
> noticeable difference to the execiution speed of the driver.
> 
> Now for the guts of the changes....
> 
> I'm planning to modfy the handling of -x options so that options that are 
> not handled by the driver in the current processing switch get collected 
> into a new variable, rather than simply failing.
> 
> main() then runs initups(). For subdriver-drivers, once the subdriver has 
> been selected, initups() will call extendvatable()/init(), as previously 
> discussed.
> 
> After initups() returns, a second switch in main() will process the 
> outstanding -x options and the failure for "bad" options will occur at 
> *that* point instead.
> 
> I *think* that this should all work, but I need to actually *try* it to be 
> sure... it sounds and looks right to me, but I might have missed something 
> in the current code that will make it not work.
> 
> I'll probably post an update as to how this goes later today.
> 
> Jo Turner
>   -)O(-
> 
> --
> jT | mail to: hyvan_trant at hotmail.com
> ** | website: http://www.chiark.greenend.org.uk/~jsturner/
> 
>