From owner-cvs-all Wed Mar 13 5:58:24 2002 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0826637B405; Wed, 13 Mar 2002 05:58:16 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2DDwEi86413; Wed, 13 Mar 2002 08:58:14 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 13 Mar 2002 08:58:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient bootp_subr.c In-Reply-To: <20020313054705.B65383@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 13 Mar 2002, Luigi Rizzo wrote: > On Wed, Mar 13, 2002 at 08:05:59AM -0500, Robert Watson wrote: > ... > > Hmm. This is in the private number range, I assume? Hopefully the > > of course yes. > > > handling is sufficiently robust that whatever comes back, bad things won't > > happen (be it a binary blob with lots of nulls, *'s, shell > > meta-characters, etc, when handled in userland?). > > I am not going, in the kernel, to escape characters which have special > meaning for arbitrary userland programs -- that's their business. > > The kernel copies chars up to the first NUL and within the buffer size > allocated for the purpose, and bootpc_tag() makes sure that there is > actually a NUL in the source buffer when it returns. I was wondering if the better approach wouldn't be to export the data as SYSCTL_OPAQUE, since it really is just a binary blob. Otherwise it will pop out in sysctl -a (if represented as a string) and potential toast the terminal. I had no end of fun sending xterm resize and retitle escape codes during IETF a few years ago in Pittsburgh... Turns out everyone ran dsniff in an xterm without output filtering. For the general exporting case (see below), exporting is also more useful. > > It seems to me that a slightly more useful incantation would actually > > expose all of the bootp options to userland via a more dimmensional sysctl > > mib. This would allow userland to inspect any other options that turned > > Sure, i don't mind doing that using dynamic sysctls if people have no > objections. I can create kern.bootp.tX (where X is the tag number) > sysctl variables according to what came back from the server. Using > names instead of numeric values is not going to work I am afraid, as > half of the namespace is not standardized anyways. Sounds great. I was also interested in, for reference purposes, caching and exporting the interface name used to bootp (caching in case it's removed, since the ifnet will go away). What I have in mind is a userland utility to make use of the bootp options more generally following a diskless boot. I'm particularly interested in the bootp DNS-related fields, log server, and YP information fields. A lot of this would remove the local customization I have to do for rc.conf and /etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message