the guy on github isn't familiar with github or something, and it's
   quite confusing.
   1429
   pretty hard to continue.  maybe with some time I can understand how to
   respond to the guy.
   i'll move forward and testing the stable code with the test app.  then
   i'll try adding my change.  if I ever finish, i'll plan to tell the
   guy, "hey what you said was kinda confusing to me, so I just did it".
   1430
   tmux reloading panes again
   1431
   1432
   gotta bring raid array up.  looks like my usb hub is unpowered.
   1434
   gotta reboot android
   1435
   k test time
   1436
   test passed.  which gives me working code and shows me how to rebuild
   this project at the same time.  i'll try removing the extra set option
   call, and look at appropriate control flow logic hopefully.
   okay.  I remember now.  wait.  no.  I don't.
   1438
   1439
   the first confusing thing is the check in libusb_init .  it passes the
   default options to the backend again only if no ctx pointer was
   bpassed, and there is no default ctx pointer.
   ok, so it only passes them, if it is making a new default ctx ptr.
   meanwhile, the old android flag had set a static flag and ignored the
   ctx pointer.
   my new code associates the flag with the ctx instead.  currently
   unstable.
   the current code still ignores the ctx pointer.
   1442
   so, the current tip code assumes that options are associated with
   ctxs.  if no ctx is passed, it stores them as defaults: but it only
   passes them on if creating a default ctx.
   so there's maybe a tiny leakish, for this use, in hjelmn's code where
   defaults set with no context, are unused if the user sets a context
   and something else with harbulot's code
   with the old android code, defaults were set for the context before it
   was created.
   this could mean passing them on, even if the context is not the
   default.
   alternatively, the intent of hjelmn's code could have been to set
   options on context storage before it is initialised.  I guess that
   seems a little unsafeish to me, unsure, nobody's mentioned trying it I
   guess.
   1445
   so what's the plan
   seems most direct to pass defaults in whether a new default context is
   made or not
   alternatively we could stay near the current code, and set defaults
   when the option is passed, and read straight from the defaults.
   I thought of two approaches to the option situation I might as well add
   as comments to a different issue
   - options could be passed on an uninitialised context
   - the backend could be refactored to initialise on use, so that early
   options can be passed after it is constructed
   regarding the first option, it seems that the user only has control of
   context pointer storage, so that's not too workable unless allocation
   is separated from initialisation
   k I submitted those ideas to their issue for such ideas
   1454
   ok um
   copypaste: seems most direct to pass defaults in whether a new default
   context is made or not
   alternatively we could stay near the current code, and set defaults
   when the option is passed, and read straight from the defaults.
   it seems more compatible a little to keep the approach I currently have
   of setting the defaults in the option handler, and reading from them to
   manage the options.
   this is similar to the solution bits made by the visiting contributer.
   1455
   current issues include:
   - deadlock, roughly resolved
   - segfault?  let's see what he addressed
   right.  my option handler checks wrt null.
   this issue should go away if duplicate passing goes away.
   but basically, it's ok to reset it if the value is unchanged ... I
   guess ... maybe ...?  i'll try looking at it!
   I think I might be able to complete this!
   1459