From owner-freebsd-hackers  Thu Jan  2 12:09:05 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id MAA27689
          for hackers-outgoing; Thu, 2 Jan 1997 12:09:05 -0800 (PST)
Received: from profane.iq.org (profane.iq.org [203.4.184.217])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA27661
          for <hackers@freebsd.org>; Thu, 2 Jan 1997 12:08:39 -0800 (PST)
Received: (from proff@localhost)
          by profane.iq.org (8.8.4/8.8.2) id HAA12208;
          Fri, 3 Jan 1997 07:07:31 +1100 (EST)
From: Julian Assange <proff@iq.org>
Message-Id: <199701022007.HAA12208@profane.iq.org>
Subject: Re: divert code not thread/smp compatible
In-Reply-To: <199701021936.LAA26380@bubba.whistle.com> from Archie Cobbs at "Jan 2, 97 11:36:06 am"
To: archie@whistle.com (Archie Cobbs)
Date: Fri, 3 Jan 1997 07:07:31 +1100 (EST)
Cc: hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > Is this an acceptable trick in the FreeBSD kernel, passing parameters
> > > with global variables?
> > > 
> > > -Julian <proff@iq.org>
> 
> My only excuse is that at the time I started writing the divert code,
> it wasn't planned on being checked in to the main branch, but instead
> was going to be a patch to be applied locally... so I tried to keep
> the patch as small as possible... and as a result committed some
> non-esthetically pleasing programming in the process... :-)
> 
> Any suggestions on the best way to properly threadify this?
> 
> Thanks,
> -Archie

Well, I looked at threading/locking issues in netinet/* generally and
have come to view the chances of seeing more than one thread in anything
close to the bsd44 inet code is zero. The whole thing is locked by
a few fat, totally non-granular splnet()s.

While we are on the subjects of locking, I notice a distinct lack
of atomic test-and-set or test-and-inc instructions for struct
usage counts (which are instead relying on non-atomic C). Is there
such an existing kernel macro that does:

int
tas(slock_t *m)
{
    slock_t res;
    __asm__("xchgb %0,%1":"=q" (res),"=m" (*m):"0" (0x1));
    return(res);
}

-Julian <proff@iq.org>