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>