From owner-freebsd-arch@FreeBSD.ORG Sat Apr 8 04:18:26 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5EA416A404 for ; Sat, 8 Apr 2006 04:18:26 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 730F543D53 for ; Sat, 8 Apr 2006 04:18:26 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.4) with ESMTP id k384Hg9a088694; Fri, 7 Apr 2006 21:17:42 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.4) with ESMTP id k384HgFv023980; Fri, 7 Apr 2006 21:17:42 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id k384HfIQ023979; Fri, 7 Apr 2006 21:17:41 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Sam Leffler In-Reply-To: <44370CD6.9090006@errno.com> References: <44370CD6.9090006@errno.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Fri, 07 Apr 2006 21:17:41 -0700 Message-Id: <1144469861.21943.13.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.88/1382/Fri Apr 7 13:51:23 2006 on tinker.exit.com X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: ifnet cloning changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 04:18:26 -0000 On Fri, 2006-04-07 at 18:07 -0700, Sam Leffler wrote: > modifies the SIOCIFCREATE api in the kernel so that an opaque parameter > block can be passed down to ifnet cloning routines (actually the user > address is passed down and the caller must do the copyin since it alone > knows the size of the parameter block). Isn't that a recipe for potential breakage? Why not make the api receive a vector, i.e. buffer/length? The "caller" will know the actual layout of the parameter block but other kernel routines will at least be able to deal with it, since they'll know the size. As an aside, I just recently got this reference regarding "self-describing" data: http://www.multicians.org/thvv/marking.html Interesting. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/