Date: Thu, 28 Nov 1996 09:49:44 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, phk@critter.tfs.com Subject: Re: users of "ft" tapes, please test! Message-ID: <199611272249.JAA32491@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611272249.JAA32491>