Date: Thu, 28 Nov 1996 00:05:24 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.org Subject: Re: users of "ft" tapes, please test! Message-ID: <3252.849135924@critter.tfs.com> In-Reply-To: Your message of "Thu, 28 Nov 1996 09:49:44 %2B1100." <199611272249.JAA32491@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199611272249.JAA32491@godzilla.zeta.org.au>, Bruce Evans writes:
>>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?
4k in VM-space available for user-land. A seriously strained resource
if 4MB installs are to be possible.
>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.
Good idea. Maybe, M_PANICFAIL is more obvious.
--
Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox.
whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3252.849135924>