<?xml version="1.0"?>
<rss version="2.0.">
  <channel>
    <title>Advogato blog for jimb</title>
    <link>http://www.advogato.org/person/jimb/</link>
    <description>Advogato blog for jimb</description>
    <language>en-us</language>
    <generator>mod_virgule</generator>
    <pubDate>Fri, 25 Jul 2008 20:18:59 GMT</pubDate>
    <item>
      <pubDate>Tue, 31 Jan 2006 10:54:19 GMT</pubDate>
      <title>31 Jan 2006</title>
      <link>http://www.advogato.org/person/jimb/diary.html?start=2</link>
      <guid>http://www.advogato.org/person/jimb/diary.html?start=2</guid>
      <description>Yay, set up a &lt;a href="http://www.red-bean.com/trac/tracepoints" &gt;Trac instance&lt;/a&gt; for the Linux kernel tracepoint stuff.
</description>
    </item>
    <item>
      <pubDate>Thu, 26 Jan 2006 00:43:53 GMT</pubDate>
      <title>26 Jan 2006</title>
      <link>http://www.advogato.org/person/jimb/diary.html?start=1</link>
      <guid>http://www.advogato.org/person/jimb/diary.html?start=1</guid>
      <description>I'm working on adding support for &lt;a href="http://www.sourceware.org/gdb/talks/esc-west-1999" &gt;GDB tracepoints&lt;/a&gt; to &lt;a href="http://kgdb.linsyssoft.com/" &gt;KGDB&lt;/a&gt;, a GDB stub for the Linux kernel.  Essentially, a tracepoint is like a breakpoint except that, when you hit a tracepoint, the stub records some data that you specify (using arbitrary C expressions; you can deference pointers, index arrays, refer to structure members, etc.) in a log, and then immediately continues the program, without communicating with GDB.  Then you can examine log hits with GDB; GDB acts as if the selected hit's recorded data were "live".  If you log a hundred bytes or so off the top of the stack, you can even get backtraces.

&lt;p&gt; I'd like to get a &lt;a href="http://www.edgewall.com/trac/" &gt;Trac&lt;/a&gt; site set up for it, so people can see what I'm doing.

&lt;p&gt; I wonder --- would it be possible to provide Dwarf CFI data for the IRQ handlers, so you could unwind through IRQ's?</description>
    </item>
    <item>
      <pubDate>Wed, 15 Nov 2000 22:23:45 GMT</pubDate>
      <title>15 Nov 2000</title>
      <link>http://www.advogato.org/person/jimb/diary.html?start=0</link>
      <guid>http://www.advogato.org/person/jimb/diary.html?start=0</guid>
      <description>This week goes mostly to Red Hat --- I need to get a GDB
release together for a customer.

&lt;p&gt; However, I think I've figured out how to present a pretty
nice interface in the &lt;a
href="/proj/Subversion"&gt;Subversion&lt;/a&gt; filesystem library
for
building transactions.  A transaction will behave just like
a revision: it's a directory tree, which you can browse
using the normal filesystem API.  However, unlike a
revision's tree, which is permanent and unchanging, a
transaction's tree is mutable --- you can use additional
functions to create, delete and modify nodes as you please. 
When you've munged the tree to your satisfaction, you can
commit the transaction; if there are no conflicts, the
transaction's tree becomes a new revision of the filesystem.

&lt;p&gt; This will require some fancy logic, mostly to conceal the
sharing of nodes between a transaction and extant, committed
revisions, but it should make the interface consistent and
easy to learn.  And hopefully make it simpler to implement
WebDAV's `activities' on top of the Subversion filesystem.
</description>
    </item>
  </channel>
</rss>
