From owner-cvs-all@FreeBSD.ORG Wed Oct 15 17:36:40 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D1716A4BF; Wed, 15 Oct 2003 17:36:40 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E577043F93; Wed, 15 Oct 2003 17:36:39 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9G0aZE7073549; Wed, 15 Oct 2003 18:36:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Oct 2003 18:33:29 -0600 (MDT) Message-Id: <20031015.183329.95757716.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <46551.1066250432@critter.freebsd.dk> References: <20031015133353.W35236@root.org> <46551.1066250432@critter.freebsd.dk> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: nate@root.org Subject: Re: cvs commit: src/sys/sys conf.h src/sys/fs/specfs spec_vnops.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2003 00:36:41 -0000 In message: <46551.1066250432@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20031015133353.W35236@root.org>, Nate Lawson writes: : : >I assume this is to avoid a trip through a vnode when doing IO to a : >device? Can you point me at the analysis of this approach? I've heard : >you talking about it before but don't have a reference. : : See the streams driver for an example why this can be considered : merely a cleanup. : : >> @@ -223,6 +224,7 @@ : >> u_int d_flags; : >> const char *d_name; : >> d_open_t *d_open; : >> + d_fdopen_t *d_fdopen; : >> d_close_t *d_close; : >> d_read_t *d_read; : >> d_write_t *d_write; : > : >Sure we have C99 now but for binary compatibility with third party : >drivers, shouldn't this be added at the end of the structure? Especially : >since this is an optional function. : : This was deliberately put in the logical place in order to encourage : 3rdparty drivers to use the correct C99 initialization for cdevsw. That doesn't do anything to make it binary compatible, which is nate's point. Warner