Date: Mon, 20 Nov 1995 16:19:49 -0800 From: David Greenman <davidg@Root.COM> To: Peter Wemm <peter@jhome.dialix.com> Cc: CVS-commiters@freefall.freebsd.org, cvs-usrsbin@freefall.freebsd.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c Message-ID: <199511210019.QAA00254@corbin.Root.COM> In-Reply-To: Your message of "Tue, 21 Nov 95 07:59:29 %2B0800." <Pine.BSF.3.91.951121074351.17368B-100000@jhome.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>> [Hummmm.. would /dev/kmem work???. I think not since the a.out header is >> missing :-(] > >How's this for a hack alternative.... >1: stop modifying kern.bootfile; and >2: hack nlist() so that if the nlist'ed pathname is the same as >kern.bootfile, then use the /var/db/kvm_kernel.db database; and >3: dump the 4.3-net2 symorder program, as now the kernel nlisting is done >via the efficient DB file. >We can then do anything to the /kernel* files and nothing will be >affected as all the run-time stuff will come from the kvm_mkdb database. > >The only problem is that I suspect this is going to make DavidG's >fingernails curl.. :-) We're quickly headed down the road that leads to the kernel symbols being loaded as part of the kernel all of the time. We're going to require this in the future if we plan to have dynamically loaded device drivers. We shouldn't touch nlist - it's used by things such as nm(1) and needs to read from whatever binary is specified. If we load the entire kernel image, one thing we could do is use kernfs to provide a kernel "image" that looks to programs like a binary. We couldn't allow non-root access to the .data portion (since it's modified after the kernel starts and may contain sensitive data), but we could allow anything to read the symbols. Perhaps kernfs isn't the way to do it. Perhaps instead to minimize kernel bloat we should create another /dev device - say /dev/kernel. Hmmm...I could probably hack that out in a few minutes... -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511210019.QAA00254>