#9903 NORM 1.5-fir: Mfg test logging

[Zarro Boogs per Child]

#9903: Mfg test logging
-------------------------------------------+--------------------------------
           Reporter:  wmb at firmworks.com    |       Owner:  wmb at firmworks.com
               Type:  defect               |      Status:  assigned         
           Priority:  normal               |   Milestone:  1.5-firmware     
          Component:  ofw - open firmware  |     Version:  not specified    
         Resolution:                       |    Keywords:                   
        Next_action:  design               |    Verified:  0                
Deployment_affected:                       |   Blockedby:                   
           Blocking:                       |  
-------------------------------------------+--------------------------------
Changes (by wmb at firmworks.com):

  * status:  new => assigned


Comment:

 Replying to [comment:1 pgf]:
 >
 > perhaps stating the obvious, but if possible this should be a generic
 mechanism, and not just tailored to "test results".  (i've wanted this in
 the past, as well, for saving an arbitrary span of i/o from OFW.  kind of
 like "script" for unix.)

 Do you know about the "to-file <filename> <rest of command line>"
 facility?  It temporarily redirects console output to <filename> for the
 rest of the command line, like ">" in Unix.

 But since you said "arbitrary span" and cited "script" instead of ">",
 perhaps you already know about to-file and are looking from something more
 capable.

 The good news is that, since the console output device (and input device
 too) is now a generic multiplexor, it should be easy enough to
 attach/detach a logger device to the mux at any time, thus avoiding some
 of the complexities associated with device switching.  (The particular
 challenge of device switching is dealing with error conditions that might
 leave the output invisible and thus leave the machine inaccessible.)

 The real challenge here is not the underlying mechanism but rather the
 possible interactions with other aspects of the user interface.  What if
 the operator has giant garden shears instead of hands and wants to log the
 output to an iPod after having inserted a toothpick in the microphone
 jack?  (That's of course a silly example, but the past three weeks of
 dealing with mfg test flow vagaries have left me in a silly state.)

 I think the solution in the mfg flow case - and perhaps in general - may
 be to log all console output to memory and provide a mechanism for dumping
 the log to a device.

 Ideally, it might also be nice to provide console scrollback, but that
 starts to get interesting because it requires as more complex mechanism
 that knows not to log output that is actually display of existing
 scrollback - and it also suffers from the well known bad interactions
 between scroller and screen-oriented use of the display.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9903#comment:2>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system