Re: froggy plans

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Chris" == Chris Moller <cmoller@redhat.com> writes:

Chris> I'm trying to avoid having froggy turn into a gdb-only thing.  Uses such
Chris> as a froggy-based strace can generate a /bunch/ of events--it was to
Chris> handle that exact case that I stuck the page-sized ring buffer in the
Chris> froggy kernel.

That makes sense to me.

But, I don't think this is really at odds with gdb integration.  In
order to be used in gdb, froggy will have to provide the features gdb
needs.

I think there have been a couple implementable plans suggested in
these two threads.  What I'm suggesting is pushing forward on one of
them far enough to get something working -- "run" an inferior or
something like that -- then incrementally add features to froggy while
making more and more of gdb work.  The gdb side of the integration is
not going to get any easier; might as well crack the nut now.

My concern is that working on froggy in isolation will mean that, at
integration time, we'll find we have to add a bunch more features to
froggy to make it work for gdb.  So, the above is a way to prevent
that, by making sure the features needed for gdb are finished first.
I don't think this has to necessarily warp froggy's overall design or
make it less useful to other clients; it is just picking one client to
start with.

For example, froggy can even remain multi-threaded and purely
callback-based; the queueing and other event management stuff can all
be done on the gdb side.

Tom