From owner-freebsd-hackers  Sat Oct 14 04:44:42 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id EAA05420
          for hackers-outgoing; Sat, 14 Oct 1995 04:44:42 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA05415
          ; Sat, 14 Oct 1995 04:44:39 -0700
Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id EAA05509; Sat, 14 Oct 1995 04:44:39 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id EAA00288; Sat, 14 Oct 1995 04:42:18 -0700
Message-Id: <199510141142.EAA00288@corbin.Root.COM>
To: Julian Elischer <julian@freefall.freebsd.org>
cc: hackers@freefall.freebsd.org
Subject: Re: suggested changes to mbuf routines 
In-reply-to: Your message of "Sat, 14 Oct 95 04:19:35 PDT."
             <199510141119.EAA05158@freefall.freebsd.org> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sat, 14 Oct 1995 04:42:18 -0700
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>the difference is to bring in the support for 3rd-party 'external objects'
>being linked to by an mbuf
>the code has been in the kernel for a while,
>and it's in 4.3, and OSF1
>in similar forms, but for some reason was commented out
>in FreeBSD..
>does anyone know why?

   Yes. There were some bugs in other parts of the system that cause this to
not work properly. I fixed it back in 1.x, but as far as I know, the fix
wasn't brought forward.

>I did notice that if I had just enabled it then there would ahve been the 
>potential for the duplication of an mbuf with an external
>reference to  do bad things it the external object was not a 
>mbuf cluster.

   Yes, that's one of the architectural problems with it (not what I'm
refering to above, however).

>for this reason I've implimented teh  ext_ref function call
>in teh ext struct which is a pointer to a function that 
>will increment the reference count of whatever object
>has been externally referenced.

   Hmmm, where do you track the references? The mbuf cluster stuff uses a
special reference array that is indexed by the offset of the cluster in the
map (mb_map) where it was allocated from and then scaled. I think this might
have been one of the bugs with enabling the non mbuf cluster external
storage - some things expected the external storage pointer to be an mbuf
cluster.

>Once again I discussed this with mike Karels about 3 years ago,
>and I'm surprised to see it still not implimented..
>he said back then that it was on his list..

   In 1.x, we used the mechanism for speeding up NFS. This particular use
didn't require tracking the references (there was only one reference to the
external storage).

>I desperatly need this  for TFS because we hang all sorts of external
>'things' off mbufs and tehy need to be freed when the mbuf is freed
>
>I just spent teh best part of a day trying to figure out why my objects were't
>getting freed, because I 'assumed' this was in the kernel, and was 
>very shocked to find it had been commented out..
>
>anyhow, ehough babble
>
>here are teh diffs

   Beware of the bugs/incomplete support for this elsewhere in the kernel. If
they still exist, they will eventually bite you.

-DG