This is the mail archive of the
mailing list for the Archer project.
Re: froggy plans
>>>>> "Chris" == Chris Moller <firstname.lastname@example.org> 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
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
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.