From owner-freebsd-hackers Thu Aug 24 19:08:09 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA16465 for hackers-outgoing; Thu, 24 Aug 1995 19:08:09 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id TAA16452 for ; Thu, 24 Aug 1995 19:08:07 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA09902; Thu, 24 Aug 95 20:09:44 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508250209.AA09902@cs.weber.edu> Subject: Re: sys/malloc.h To: davidg@Root.COM Date: Thu, 24 Aug 95 20:09:44 MDT Cc: hackers@freebsd.org In-Reply-To: <199508250111.SAA00647@corbin.Root.COM> from "David Greenman" at Aug 24, 95 06:11:13 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > >2) Has anyone else noticed the mixing of FREE/free on cn_pnbuf > > elements of nameidata structures? Doesn't this seem broken, > > considering the use of MALLOC in the non-'HASBUF' case for > > allocation in all cases in vfs_lookup.c? Won't this fail > > for the case of a kernel without either KMEMSTATS or > > DIAGNOSTIC defined? > > The KMEMSTATS #ifdefs are bogus and should be removed. I had removed them > once in my local sources but the changes got lost. We always gather malloc > stats in FreeBSD - the information is just too important to be without. In which case the MALLOC()/free() parings are incorrect, and should be using MALLOC()/FREE() instead, right? Or malloc()/free(). It doesn't seem legal to mix pairings. On the other hand, the spl() code still seems ...bizarre. The spl() is being set twice, once in the malloc()/free() and once on the macroized versions. Seems that maybe the stats gathering should be moved into malloc()/free() itself instead of being in malloc.h to save at least one spl/splx pair. We may even want to reconsider why spl/splx is needed to guard around the malloc()/free() anyway -- obviously to allow allocation/freeing in interrupt code. Perhaps we should adopt an architecture of prealloc and free later for interrupt level alloc/free? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.