From owner-cvs-all Wed Mar 13 5:47:31 2002 Delivered-To: cvs-all@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 23ED737B41C; Wed, 13 Mar 2002 05:47:06 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2DDl5R65506; Wed, 13 Mar 2002 05:47:05 -0800 (PST) (envelope-from rizzo) Date: Wed, 13 Mar 2002 05:47:05 -0800 From: Luigi Rizzo To: Robert Watson Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient bootp_subr.c Message-ID: <20020313054705.B65383@iguana.icir.org> References: <200203130923.g2D9NBL68938@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i 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, 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. > > The intended use is to pass information to userland for run-time > > configuration of a diskless client without having to run a bootp/dhcp > > client for the third time (after the one in pxeboot/etherboot, and > > the one in the kernel bootp), also because these clients generally > > screwup the interface configuration, which is not exactly what you > > want when you have your disks nfs-mounted. > > 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. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message