* fhpd user interaction (and corefiles)
@ 2007-11-02 10:03 Phil Muldoon
2007-11-02 13:50 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Phil Muldoon @ 2007-11-02 10:03 UTC (permalink / raw)
To: Frysk Hackers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fhpd user interaction (and corefiles)
2007-11-02 10:03 fhpd user interaction (and corefiles) Phil Muldoon
@ 2007-11-02 13:50 ` Andrew Cagney
2007-11-05 9:52 ` Phil Muldoon
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2007-11-02 13:50 UTC (permalink / raw)
To: Phil Muldoon; +Cc: Frysk Hackers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fhpd user interaction (and corefiles)
2007-11-02 13:50 ` Andrew Cagney
@ 2007-11-05 9:52 ` Phil Muldoon
2007-11-08 11:25 ` Phil Muldoon
0 siblings, 1 reply; 4+ messages in thread
From: Phil Muldoon @ 2007-11-05 9:52 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Frysk Hackers
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fhpd user interaction (and corefiles)
2007-11-05 9:52 ` Phil Muldoon
@ 2007-11-08 11:25 ` Phil Muldoon
0 siblings, 0 replies; 4+ messages in thread
From: Phil Muldoon @ 2007-11-08 11:25 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Frysk Hackers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-11-08 11:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-02 10:03 fhpd user interaction (and corefiles) Phil Muldoon
2007-11-02 13:50 ` Andrew Cagney
2007-11-05 9:52 ` Phil Muldoon
2007-11-08 11:25 ` Phil Muldoon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).