From owner-freebsd-hackers  Tue Jun  6 01:22:50 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id BAA08324
          for hackers-outgoing; Tue, 6 Jun 1995 01:22:50 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA08316
          for <hackers@freebsd.org>; Tue, 6 Jun 1995 01:22:45 -0700
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id BAA01430; Tue, 6 Jun 1995 01:26:05 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id BAA00244; Tue, 6 Jun 1995 01:22:57 -0700
Message-Id: <199506060822.BAA00244@corbin.Root.COM>
To: Eric Hoffman <hoffman@ipsilon.com>
cc: hackers@freebsd.org
Subject: Re: external storage for mbufs 
In-reply-to: Your message of "Mon, 05 Jun 95 19:38:30 PDT."
             <199506060238.TAA06992@servo.ipsilon.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 06 Jun 1995 01:22:56 -0700
Sender: hackers-owner@freebsd.org
Precedence: bulk

>
>  #ifdef notyet
>  #define       MFREE(m, n) \
>  ....general purpose deallocator which uses ext_free function pointer..
>  #else /* notyet */
>  #define       MFREE(m, nn) \
>  ....deallocator which assumes M_EXT is always part of the cluster system...
>  #endif
>
>could someone lend some context to why the following code from
>mbuf.h is conditionalized the way it is?
>
>an idle recompile with the new code caused damage...what other
>conditions in the system exist that make it not yet ready?

   It's not too difficult to get it to work, but the main problem is that
reference count tracking must be disabled when there is an "external" free
routine. This is because the reference counts are all in an array that is
indexed by the address of the data (divided by the appropriate constant).
If there is an external free routine, then the memory won't be the 'managed'
memory that is in the special address region...thus leading to an array index
that is out of bounds...causing a panic.
   I had this working in 1.1.5 and was using it to speed up NFS. I chose not
to bring that change forward (it was too much of a hack).

-DG