From owner-freebsd-current Sat May 16 05:16:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07432 for freebsd-current-outgoing; Sat, 16 May 1998 05:16:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07420; Sat, 16 May 1998 05:16:08 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id WAA18632; Sat, 16 May 1998 22:12:55 +1000 Date: Sat, 16 May 1998 22:12:55 +1000 From: Bruce Evans Message-Id: <199805161212.WAA18632@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@netplex.com.au Subject: Re: libc corruption Cc: current@FreeBSD.ORG, dyson@FreeBSD.ORG, kkennawa@physics.adelaide.edu.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >To make it a little easier, perhaps have libc's syscall tables explicitly >> >generated from the kernel sources and committed. That should make it >> >a no-brainer to keep them in sync and yet will stop accidental leakage >> >from the kernel into libc. >> >> Better yet, generate the tables explicity and don't commit them anywhere. >> That should make it a no-brainer to keep them in sync and stop accidental >> blockage of the flow from the kernel into libc :-). > >This is the present situation and it's not working very well. It isn't the present situation. We commit the tables to src/sys and use some tables from , some from src/sys/sys, and even some from src/sys/kern (see src/usr.bin/kdump/kdump.c). We only generate the tables on the fly for truss (see src/usr.bin/truss/Makefile). >Generating vnode_if.[ch] is another annoyance that I'd like to see >eradicated. No, it actually works. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message