Messages in this thread |  | | Date | Thu, 7 Sep 2000 13:23:33 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: We are as good as our tools |
| |
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/
|  |