From owner-cvs-all Sun Feb 21 8:39:24 1999 Delivered-To: cvs-all@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id B947F114B5 for ; Sun, 21 Feb 1999 08:39:21 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA14194; Sun, 21 Feb 1999 15:23:27 +0100 From: Luigi Rizzo Message-Id: <199902211423.PAA14194@labinfo.iet.unipi.it> Subject: Re: Current status of the olicom fracas. To: lile@stdio.com (Larry Lile) Date: Sun, 21 Feb 1999 15:23:27 +0100 (MET) Cc: phk@critter.freebsd.dk, julian@whistle.com, jkh@zippy.cdrom.com, cvs-all@FreeBSD.ORG In-Reply-To: from "Larry Lile" at Feb 21, 99 10:29:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 916 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > I personally advocate the position that any instruction executed > > on the CPU must be available in source form, and therefore this i second this position. The idea being that you might not trust a module and want to have a chance that it does not do bad things. ... > Now how do we save the oltr driver and token-ring support for FreeBSD? Perhaps this would be a good case for a "kernel patch" type of port, wouldn't it ? I know by experience that kernel patches are problematic because they are much harder to keep consistent with the system and/or other patches, but at least, by going this way, one really has to know what s/he does before using an external object module. The other possibility would be to modify the config structure so that obkect-only modules can be clearly identified and either config or a kernel build loudly remarks the use of such a module. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message