Re: We are as good as our tools

From: Alexander Viro (viro@math.psu.edu)
Date: Thu Sep 07 2000 - 12:23:33 EST


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

> Alexander Viro <viro@math.psu.edu> 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
> > plan9.bell-labs.com/sys/doc/) 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST