Date: Wed, 29 Dec 2004 16:51:35 -0800 From: Nate Lawson <nate@root.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys ktr.h Message-ID: <41D35117.4010505@root.org> In-Reply-To: <20041229193531.M60504@mail.chesapeake.net> References: <200412260013.iBQ0DcJ1074546@repoman.freebsd.org> <20041229020531.GA12575@dragon.nuxi.com> <41D26CE3.4070404@root.org> <20041229124826.Q60504@mail.chesapeake.net> <41D30245.8020600@root.org> <20041229151758.S60504@mail.chesapeake.net> <41D33C50.6090109@root.org> <20041229193531.M60504@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > On Wed, 29 Dec 2004, Nate Lawson wrote: >>>>Isn't there a way to dynamically allocate ids, like sysctl does for oid? >>> >>>They need to be static at compile time or they always produce massive >>>bloat in the kernel. >> >>Right, I thought we did something like that for other subsystems. I'm >>very fuzzy on the current best approach but in the past we used linker >>sets to gather a class of data at link time (including mod load). If >>the linker set was an id placeholder for a particular type of debug >>data, the kernel could overwrite this with the actual runtime id. > > > We already have a runtime mechanism for disabling a particular class that > could tolerate dynamic class ids. That's KTR_MASK. The issue I'm talking > about, is the ability to compile it out. Since gcc's dead code eliminator > doesn't run after link time, all ktrs would forever be compiled into the > kernel. Ok. It might be possible to mark such code with __init and KTR ids with __initdata. Then the linker can discard them if not using KTR. This is the approach Linux takes to reclaim memory from code/data that only needs to be accessed once, at boot. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41D35117.4010505>