fhpd user interaction (and corefiles)

fhpd user interaction (and corefiles)

[Phil Muldoon]

In fhpd, there are several scenarios where guessing a user's intentions 
with the data available becomes difficult. Right now the core file code 
makes the decision for you. This is wrong and I would like to change 
that. Consider the scenarios below.

No executable specified:

- The user specifies a corefile, but no executable. The code finds a 
named executable as described in the corefile in 'pwd', does it use it? 
Yes in the current code.
- The user specifies a corefile, but no executable. The code does not 
find a named executable as described in the corefile in 'pwd', but does 
in /usr/bin or /bin, does it use it? Yes in the current code.
- The user specifies a corefile, but no executable. The code does not 
find a named executable in either of the top two scenarios, and just 
builds basic metadata. Yes in the current code.

Executable specified:

- The user specifies a corefile, and an executable, but the executable 
name does not match the name that the corefile has on record, does it 
use this executable, warn the user, or abort? No, it blindly uses the 
executable.
- The user specifies a corefile, and an executable. Both match and the 
corefile code builds rich metadata. Yes in the current code.
- The user specifies a corefile, and an executable. Both match, but 
there are permission issues. How should the core continue here? Right 
now it ignores the executable and builds basic metadata.

One of the sticking points is the dead/LinuxHost.java code does not let 
the hpd/CoreCommand.java know what it is doing. In fact, unless it 
throws an exception in building the corefile metadata ,it does not 
communicate anything at all.  It is even further compounded by fstack 
where beyond current initial bootstrapping there is no bandwidth to ask 
the user anything.

 The question here then: if the LinuxHost code has a question for the 
user, how does it ask that user the question via CoreCommand? As far as 
I can tell, none of the fhpd commands are interactive.

Possible solutions:

- Do exactly as the user instructs. Abandon all attempts at executable 
auto-location. If the user does not specify an executable, no executable 
is loaded or searched for. Only basic meta data is built.
- Allow the user to specify data to the corefile via another command 
later. Like a file command which specifies an executable and allows the 
corefile code to reboot and rebuild itself at a later time.
- Continue with existing plan above, but allows callbacks and active 
user interaction with the fhpd
- Something else?

Regards

Phil

Re: fhpd user interaction (and corefiles)

[Andrew Cagney]

Phil Muldoon wrote:
> The question here then: if the LinuxHost code has a question for the 
> user, how does it ask that user the question via CoreCommand? As far 
> as I can tell, none of the fhpd commands are interactive.
As you point out, the bottom line is fstack et.al., where no interaction 
is possible.  The create either succeeds or fails.  With that in mind 
can i suggest considering instead how you might interact with this from 
a UI.  For instance, would this work:
    ->File->Open
       use file browser to open a core file
    <<Core file assistant appears; perhaps pre-populated with info from 
raw core file>>
       - indicates what action is going to happen next, for instance 
indicates the executable it will attempt to open (or don't bother)
       - OK attempts to open the executable or fails leaving the user 
with the assistant
from a cli, a similar interaction might be:
   (fhpd) core foo
   Executable <exe> for <foo> not found.
   (fhpd) core foo exe                 --- the user is right
   OR
   (fhpd) core foo -noexe
another might be:
   (fhpd) core foo
   Corefile .... of arch ... no executable.      --- printed by fhpd 
using stuff from core
   (fhpd) exe ..the-exe...
   Corefile ... of arch ... executable ...      --- intercede the no-exe 
core
Each of these are built round the assumption that the code creating the 
core file is more predicatable (and more likely to throw an exception) 
for instance, interfaces with requirements such as:
   -- create core and must use implicit exe or fail
   -- create core and ignore exe
   -- create core and use explicit EXE

Andrew

Re: fhpd user interaction (and corefiles)

[Phil Muldoon]

Andrew Cagney wrote:
> Phil Muldoon wrote:
>> The question here then: if the LinuxHost code has a question for the 
>> user, how does it ask that user the question via CoreCommand? As far 
>> as I can tell, none of the fhpd commands are interactive.
> As you point out, the bottom line is fstack et.al., where no 
> interaction is possible.  The create either succeeds or fails.  With 
> that in mind can i suggest considering instead how you might interact 
> with this from a UI.  For instance, would this work:
>    ->File->Open
>       use file browser to open a core file
>    <<Core file assistant appears; perhaps pre-populated with info from 
> raw core file>>
>       - indicates what action is going to happen next, for instance 
> indicates the executable it will attempt to open (or don't bother)
>       - OK attempts to open the executable or fails leaving the user 
> with the assistant
> from a cli, a similar interaction might be:
>   (fhpd) core foo
>   Executable <exe> for <foo> not found.

Yeah, pretty much what I was thinking. I'm still undecided how 
LinuxHost.java should message back that the corefile executable has not 
been found. I could raise a (checked) exception, but that somewhat 
indicates an error condition when it is not. I could implement 
callbacks, but that would require a declared interface, which may muddle 
the very simple and clean interaction now.

Any ideas?

Regards

Phil
>  

Re: fhpd user interaction (and corefiles)

[Phil Muldoon]

Phil Muldoon wrote:
> Andrew Cagney wrote:
>> Phil Muldoon wrote:
>>> The question here then: if the LinuxHost code has a question for the 
>>> user, how does it ask that user the question via CoreCommand? As far 
>>> as I can tell, none of the fhpd commands are interactive.
Further on from yesterdays talks, this is the workflow:

(fhpd) core core.1234

Error: Could not find executable: 'a.out' specified for corefile. You 
can specify one with the core command. E.g: core core.file yourexefile. 
Alternatively you can tell fhpd to ignore the executable with -noexe. 
E.g core core.file -noexe. No corefile has been loaded at this time.


Then from that point:

core core.1234 -noexe
(basic metadata only)

or

core core.1234 /home/foo/a.out
(override exe option in the corefile)

There's an issue here. How do you lint that /home/foo/a.out really is 
the executable  that matches the corefiles? I could check the name in 
the corefile, but that sort of negates the point of having an overriding 
executable. If it is not the executable, the metadata builders gets very 
confused pretty fast as the PT_LOADS in the exe look nothing like they 
should.

This leads onto another question. If a set is "half built" as it were, 
how does one clear that set and start from fresh? Or just simply replace 
whatever is in that set, good or bad, with a new fresh set of processes 
and tasks?
Regards

Phil