From owner-freebsd-current Wed Apr 5 03:14:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA14352 for current-outgoing; Wed, 5 Apr 1995 03:14:43 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA14346 for ; Wed, 5 Apr 1995 03:14:36 -0700 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id GAA03887; Wed, 5 Apr 1995 06:14:11 -0400 From: Peter Dufault Message-Id: <199504051014.GAA03887@hda.com> Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 5 Apr 1995 06:14:11 -0400 (EDT) Cc: nate@trout.sri.MT.net, rkw@dataplex.net, current@FreeBSD.org In-Reply-To: <9504042045.AA18525@cs.weber.edu> from "Terry Lambert" at Apr 4, 95 02:45:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2588 Sender: current-owner@FreeBSD.org Precedence: bulk Terry Lambert writes: > > > *BLECH* BSD systems have *never* (and should *never*) require that you > > have the complete source tree installed just to build a kernel. Making > > them go through alot of trouble to build a kernel is a waste of their > > time. Many, many more people build kernels w/out src trees than people > > who build kernels w/src trees. We are trying to make the system > > *easier* to use for the avg. user w/out penalizing the developer. > > I'm glad you said this. > > When will the binary link kit be available? > > I've often thought that it should be possible to configure devices > in and out of the kernel without regenerating more than a single > object file containing the device switches. Wait a minute, who was that Terry Lambert giving me such grief about this last week? I thought we had to redesign the configuration, power management, and make the kernel multithreaded (no, that last one was a different issuse, never mind) at the same time. At the moment you can almost do this for isa drivers except for the assignment of interrupts in isa/isa.c. I just steal unused interrupts to get around the problem. > > The really nice thing about this, of course, is that multiport > board drivers and Adaptec drivers using Adaptec code, and (potentially) > the Intel supplied-for-MACH binary math coprocesser emulator could > all be supplied without sources in full conformance to the non > disclosure agreements required to obtain them. I agree with this completely. Fundamental changes to company policy on intellectual property are best left to the Linux camp. > > To make the nay-sayers happy, putting the source in escrow with the > condition that a non-disclosure be signed to obtain it should be > sufficient to not vest too much in a driver writer as a single point > of failure. I don't know about this. You'll have to be very careful about who these sources go to. One slip and FreeBSD has a black eye and a lawsuit. > That's just a legal niceity, however, and the main point, that it be > *possible*, is the important thing. > > Actually, sufficient reliance on a devfs, loadable modules, and > soft autoconfiguration with a "save" for "/kernel -c" boot should > make it totally unnecessary to have a link kit to get a new kernel > configuration anyway. Yes, this is a good design rule and with a little attention to detail it won't even be much work. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267