From owner-freebsd-hackers Mon Oct 13 22:03:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA22213 for hackers-outgoing; Mon, 13 Oct 1997 22:03:26 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA22208 for ; Mon, 13 Oct 1997 22:03:22 -0700 (PDT) (envelope-from kpneal@pobox.com) Received: from bogus.mindspring.com (user-37kbo23.dialup.mindspring.com [207.69.224.67]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id BAA19291 for ; Tue, 14 Oct 1997 01:03:19 -0400 (EDT) Message-Id: <1.5.4.32.19971014050321.006e0640@mindspring.com> X-Sender: kpneal@mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Oct 1997 01:03:21 -0400 To: freebsd-hackers@freebsd.org From: "Kevin P. Neal" Subject: Re: Large scale code integrations (Was: Re: C2 Trusted FreeBSD?) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 11:06 PM 10/13/97 -0500, Chris Csanady wrote: > >>> code ought to be moved to a stacking layer, as well. Unfortunately, the >>> FS framework has problems right now, and it's not terribly clear if they >>> will ever be solved without someone on the core team doing the actual >>> work, since the changes required are so large that only a core team member >>> could do them in the face of the fear that much change generates. >> >>yes the changes would be large, and of course would require core team >>coordination. > >Terry has actually done much of the work to get our FS framework into shape, >it just has not been integrated because of its size and impact. I think Jordan >was going to try to help get things started on this a while ago, but I don't >remember exactly. I for one would really love to see a working stackable FS >framework. Also the locking changes for NFS, etc.. > >I don't know if this sort of thing is typical for large changes in general, but >it does worry me when contemplating them. There just seem to be things which >can not really be broken up, yet still need doing. :\ What is the proper way >to go about these, and still have something that can be integrated? A branch for the changes to go on, and move them over when they are fully baked? Oh joy, more branches. :/ -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!"