From owner-cvs-all@FreeBSD.ORG Wed Oct 15 13:49:35 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 A709D16A4C0 for ; Wed, 15 Oct 2003 13:49:35 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 2809143FBF for ; Wed, 15 Oct 2003 13:49:33 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 32780 invoked by uid 1002); 15 Oct 2003 20:49:30 -0000 Received: from unknown (HELO ?10.4.1.5?) (64.58.1.252) by smtp.mho.net with SMTP; 15 Oct 2003 20:49:30 -0000 Date: Wed, 15 Oct 2003 14:50:38 -0600 (MDT) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Poul-Henning Kamp In-Reply-To: <46551.1066250432@critter.freebsd.dk> Message-ID: <20031015144549.E9965@pooker.samsco.home> References: <46551.1066250432@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Nate Lawson 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: Wed, 15 Oct 2003 20:49:35 -0000 On Wed, 15 Oct 2003, Poul-Henning Kamp wrote: > 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. I think that Nate was concerned about binary compatibility, not source compatibility (which is why he mentioned C99). This change will of course affect things like nvidia.ko, so a small heads-up might be in order. Even though 5.x is not yet STABLE, we still need to practice good common courtesy with API and ABI changes. Scott