Date: 12 Dec 2000 17:33:01 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Matt Dillon <dillon@earth.backplane.com>, kris@citusc.usc.edu, arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel Message-ID: <xzpitop4n2a.fsf@flood.ping.uio.no> In-Reply-To: Julian Elischer's message of "Tue, 12 Dec 2000 04:50:22 -0800" References: <18190.976606205@critter> <3A361F0E.F015A262@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer <julian@elischer.org> writes:
> Poul-Henning Kamp wrote:
> > There are several places where this new API would make the code
> > simpler and less prone to overflowable errors. procfs and various
> > netgraph nodes spring to mind immediately.
> hmmm such as?
In procfs: portions of procfs_{map,rlimit,status,vnops}.c
In linprocfs: most of linprocfs_misc.c
Poul-Henning also mentioned the mn(4) and musycc(4) drivers.
Any part of the kernel that exports string sysctls will also benefit.
Most of the magic that's necessary for writeable string sysctls can be
eliminated by using sbufs in such a way that you'll be able to declare
string sysctls just as easily as integer sysctls (currently, each
writeable string sysctl requires ~20 lines of code).
Empirical tests show that the sbuf API adds less than 2 kB of code to
the kernel, and I believe (though I can't prove) that the amount of
duplicated code and static buffers that can be replaced with judicious
use of sbufs will more than outweigh that cost. In some cases (procfs
and linprocfs at least, but probably others too) using sbufs also
saves large amounts of syscall stack space.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpitop4n2a.fsf>