[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: We are as good as our tools

On Thu, 7 Sep 2000, Horst von Brand wrote:

> Alexander Viro <> said:
> [...]
> > BTW, tools are really nice, but I wouldn't call conventional debuggers
> > a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it
> > feels like a switch from MCR to sh. Small core providing a language with
> > enough primitives to build the rest of debugger + library + ability to
> > write new functions. _That_ would be very useful thing to have - you are
> > not limited to stepping/poking anymore and can actually write functions
> > that check state consistency/get stats/whatever and use them. I would
> > really recommend everyone involved in that thread look through the
> > papers on this thing (USENIX '94; available online on the
> > and look at it in work. Something similar
> > could be really useful - unlike gbd it allows to look at the large picture
> > without wearing your fingers to bones. Essentially, Acid libraries can be
> > used as documentation on the state - very expressive beast.
> Is this animal available in source together with plan9? Could it be adapted
> for use on more conventional systems (licence and otehrwise)?

Yes (/sys/src/cmd/acid/*, /sys/src/libmach/*). As for porting... I suspect
that it's easier to write a native equivalent than to emulate their procfs
mechanisms and notes handling. Heck, core stuff (.../acid/*) is 90Kb of
sparse C; our ext2 implementation is several times larger. License is the
usual Plan 9 one, but it applies to source, not to ideas or language
itself... If the core is to be embedded into a kernel (*note*: these guys
didn't bother with that themselves) it certainly needs rewrite anyway.
Note on C style: they keep all library API in one include file, e.g.
libc.h, libmach.h, libregex.h, etc. u.h is the kernel API. libfoo.h
normally contains #pragma lib "libfoo.a", so they don't have to mention
libraries in mkfiles explicitly - derive that information from what is
included. mkfile is equivalent of Makefile - slightly different syntax,
but mostly isomorphic to GNU make. Directory hierarchy is different from
usual for recent Unices - their /usr is our /home and /sys - our /usr;
machine-dependent stuff lives in /{386,alpha,sparc,...}/{bin,lib,include}

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.152 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site