From: Tom Tromey <tromey@redhat.com>
To: Frysk List <frysk@sourceware.org>
Subject: Changes
Date: Wed, 09 Jul 2008 22:19:00 -0000 [thread overview]
Message-ID: <m33ami66rk.fsf@fleche.redhat.com> (raw)
Here's the first message of the messages I promised during the
meeting.
Red Hat is revisiting its interest in Frysk. In particular, our goal
is now:
Build the best C++ debugger in the world.
This has a few sub-goals:
* Have a CLI
* Integrate with Eclipse
* Scale to very large programs (w/ lots of shared libraries)
* Scale to many threads
In particular I think Red Hat is not going to pursue Frysk's current
monitoring and tracing goals, or the existing GUI.
I'm sending everything in this message to this list. However, if the
consensus is that we need a new list, that would also be fine by me.
Meanwhile I'll carry on here.
Internally we've revisited a number of decisions made during the
course of Frysk's development. I'll summarize here our current
thinking about what we'd like to do. Comments, criticism, etc are
welcome.
Note that I'm using the Red Hat "we" in the below. I'm sure that
individuals disagree with various statements here. (Feel free to
speak up, etc.) I am responsible for anything you read here, and I
don't want to avoid that, but I did not want to take undue credit for
ideas, etc, which are not mine.
* Java. We've heard many times while discussing Frysk with other
parties that the choice of Java is an odd one.
In order to more fully align the interests of the developers of the
debugger with the interests of its users, we'd like to use C++ as
the implementation language. We picture refactoring the core of
Frysk into C++; not changing the design but simply the
implementation language.
* Scripting. One issue with gdb is its poor support for scripting.
We think scripting is needed for debugger programmability, and in
particular that it will be needed for C++ pretty-printing. So, our
thinking is that this debugger would have a Python binding to its
core.
In order to exercise this binding code, we picture rewriting the
existing CLI code in Python. The idea here is that part of the CLI
need a rewrite anyhow, and there is no particular reason that the
CLI needs to be written in C++.
* HPD. We discussed HPD a little. It seems ok, overall, though a bit
underpowered; in particular there are common debugging operations
that one can do in gdb which have no analog in HPD. So, we know we
must at least extend it.
Some people expressed concern that the HPD language differs
needlessly from gdb -- meaning that they need to re-learn things to
try a new debugger. I don't think we have a particular solution in
mind for this. We could move more toward a gdb-like CLI, or we
could supply a compatibility mode; dunno.
We think it makes sense to still have a CLI even though there is
also a scripting language under the hood. The reason for this is
simply that Python would make for a funny CLI -- you'd have to quote
arguments, etc.
* We would like to drop the existing GUI. It does not align with our
goals. However, as I said during the meeting, if someone wants to
maintain the GUI, that would be fine.
We may want a standalone debugger GUI. One idea is to see if we can
reuse the Eclipse work using RCP. Another idea is to go the gdb
route and hope some 3rd party either writes one, or ports and
existing one from gdb.
* Naming. There's some contention as to whether the result should
keep the name "Frysk". I will let proponents and opponents make
their arguments; I don't have an opinion on this.
* Process. We'd like to institute some form of patch review. Ideally
this would be low on bureaucracy; perhaps just an Apache-style "+1"
voting system. The intent here is to raise coding standards overall
-- make sure that features have more polish when they go in, and
that both internal and external documentation are included.
* Roadmap and milestones. We want to publish a general roadmap along
with milestones that will describe roughly what features will be
available when. I don't know whether this is interesting to non-Red
Hat folks; if not we can do this internally. Let us know.
The general milestone idea we've been discussing is "depth first" --
using user-visible features to drive the development process; but
probably the "releases" would be time-based as much as possible.
The roadmap will be where we figure out what "best C++ debugger"
means -- that is, what specific features this entails. We'll be
starting that process on this list (or elsewhere in public) soon.
* Licensing. We discussed this at the meeting. Eric is looking into
the ownership issue and the choice of license.
We've talked a bit about constraints on the license and owner:
* Who owns the current code; what do we need to drop or relicense if
we want to change the license
* Can we assign to the FSF or some other entity?
* What constraints does our Eclipse integration approach put on the
choice? Rick is looking into some details here.
* Can we reuse bits of gdb if we want? (There are a few things that
might be worth reusing.)
* GDB. A recurring question is: why not expend our efforts improving
gdb? There are no easy answers here; the tradeoffs are complicated.
This is probably more of a Red Hat internal decision (it is about
where we want to focus our efforts, not about the frysk project per
se) -- but it is an obvious and important question and deserves to
be brought up here.
We're open to arguments either way on this topic. Given our goals,
what would you choose to do?
That is pretty concise. I'm happy to try to expand on anything that
seems unclear -- goals, reasoning, etc.
I don't think I've forgotten anything here, but if I did, please bring
it up.
Since we want to build a healthy community around this project, your
opinion matters. Please share it. Aside from Red Hat's goals,
nothing here is truly decided; it is all open to debate.
thanks,
Tom
next reply other threads:[~2008-07-09 22:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 22:19 Tom Tromey [this message]
2008-07-10 0:06 ` Changes Sami Wagiaalla
2008-07-11 17:04 ` Changes Sami Wagiaalla
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
2008-07-10 13:14 ` Changes Rick Moseley
2008-07-10 13:26 ` Changes Phil Muldoon
2008-07-10 17:07 ` Changes Eric Bachalo
2008-07-10 19:43 ` Changes Dodji Seketeli
2008-07-11 16:55 ` Changes Tom Tromey
2008-07-10 8:24 ` Changes Phil Muldoon
2008-07-11 10:44 ` Changes Phil Muldoon
2008-07-17 7:51 ` Changes Jan Blunck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m33ami66rk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).