From owner-freebsd-current  Wed Nov 27 14:50:51 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA19190
          for current-outgoing; Wed, 27 Nov 1996 14:50:51 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA19182
          for <current@FreeBSD.ORG>; Wed, 27 Nov 1996 14:50:46 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id JAA32491; Thu, 28 Nov 1996 09:49:44 +1100
Date: Thu, 28 Nov 1996 09:49:44 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199611272249.JAA32491@godzilla.zeta.org.au>
To: current@FreeBSD.ORG, phk@critter.tfs.com
Subject: Re: users of "ft" tapes, please test!
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Unless somebody convinces me that this patch doesn't work, It will
>be committed.  It shaves about 5K of the size of the ft.o object
>file.

There are several other places with big static buffers, but I thought
that the savings for making them dynamic would be negative for kzipped
kernels.  How much is saved by this change?

>-  ft = &ft_data[ftu];
>+  ft = ft_data[ftu] = malloc(sizeof *ft, M_DEVBUF, M_NOWAIT);
>+  bzero(ft, sizeof *ft);

Why don't people check the the value returned by malloc()?  malloc()
is unlikely to fail at probe time (except on 4MB machines :-), and
the null pointer panic isn't much different from panic("malloc failed")
but it is harder to debug.  How about a new flag M_NOFAIL which causes
a panic if malloc() would fail.  M_WAITOK is rarely correct in probes
(hanging is worse than panicing) and M_NOWAIT is inconvenient if you
actually check for errors.

Bruce