Re: What's with all the Cisco stuff?

[Stan Shebs <shebs@cygnus.com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 16 Aug 1999 13:23:56 -0700

   Stan> That was kicked around a bit in our internal (ahem :-) )
   Stan> discussion.  Basically you ask the RTOS "what kinda objects you
   Stan> got?", get back a list of types, then ask "how should type X be
   Stan> displayed?" and get back something like a printf format string
   Stan> or maybe even a bit of XML, then GDB follows instructions when
   Stan> getting the objects' data and displaying it.

   The "how should type X be displayed?" question IMO is inappropriate.
   The target knows the kernel objects and their types, but the user is
   in a better position to know how they are to be displayed (or other-
   wise manipulated).

Put the emphasis on *should*.  Of course the target should return back
exact data types, so as to distinguish between integer and string
types, but it ought to return "hints" also, for instance that a
numeric value should be displayed in hex, while another value should
be displayed in decimal.  The user can always override.

   I've thought about this a bit, and it seems the best model to use is
   something like SNMP.  But instead of a pre-defined MIB that is known
   by both the debug agent on the target and GDB, the MIB is downloaded
   from the target.  There should probably be traps so the debug agent
   can tell GDB that new MIBs are present or old ones have been removed
   if the kernel has loadable kernel modules or the like.

Going by your description, this seems very heavyweight, only really
appropriate for Unix-sized OSes.  But I'm not that familiar with SNMP;
what should I look at to educate myself?

   Stan> eCos and other folks observed that this was probably too
   Stan> heavyweight to impose on every RTOS, although it would make
   Stan> sense for the larger OSes.  

   Even though I walked through the above thought experiment, I'm still
   not convinced that direct access to kernel data structures with GDB
   scripts is not superior.

You're assuming that direct access is possible though.  While some,
like VxWorks, give you full access to things like task state, others,
like QNX, don't seem to keep kernel data in a place where you can
get to it.  It's also easy to imagine an RTOS that got stopped right
in the middle of updating a kernel object; wouldn't you rather have
the RTOS report "invalid, please step to <x>" instead of being misled
by pointers and references that don't connect right?

   In my opinion, KOD must be much more than a
   kernel object pretty-printer to justify its exisistance.  Individual
   objects must be able to be queried and their values must be usable in
   GDB expressions.

   This model requires quite a bit of hair to create an abstraction layer
   between kernel objects and GDB.  I'm not sure that that abstraction
   provides enough benefits to overcome the complexity in an OS of any
   size.

Yes, which is why a display-only ability is a good intermediate step.
GDB often doesn't make values out of the data it displays, for instance
the output of "x" is just output, you don't get an array of values.
But I think that everybody still finds "x" to be a useful command.

								Stan