Date: Thu, 24 Aug 95 20:09:44 MDT From: terry@cs.weber.edu (Terry Lambert) To: davidg@Root.COM Cc: hackers@freebsd.org Subject: Re: sys/malloc.h Message-ID: <9508250209.AA09902@cs.weber.edu> In-Reply-To: <199508250111.SAA00647@corbin.Root.COM> from "David Greenman" at Aug 24, 95 06:11:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508250209.AA09902>