From owner-freebsd-arch@FreeBSD.ORG Thu Jun 19 00:10:07 2003 Return-Path: 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 2C5B837B401 for ; Thu, 19 Jun 2003 00:10:07 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71B3843F93 for ; Thu, 19 Jun 2003 00:10:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk2f.dialup.mindspring.com ([165.247.208.79] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19StYP-0007Rg-00; Thu, 19 Jun 2003 00:09:53 -0700 Message-ID: <3EF1617F.C1EC5C12@mindspring.com> Date: Thu, 19 Jun 2003 00:08:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew D. Fuller" References: <20030618174733.GC10127@over-yonder.net> <20030618190032.GG10127@over-yonder.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b3d42763fbf89967bbac5bd940dc7857a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: Meta: explain what where when? (was Re: userland access todevicesis moving!) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 07:10:07 -0000 "Matthew D. Fuller" wrote: > Reading the discussion of this change, I'd say "This is a structural > cleanup that eliminates some complexity and makes it easier to understand > and add onto, with the 'cleanup' features related to the reduced > complexity. It may also yield a small real-world performance improvement > for things that do a lot of /dev/* fiddling." Just a thumbnail sketch of > whether this is moving us down the path, or hacking out thorns that are > keeping us from moving down the path, etc. That's more like a marketing blurb. It does not evenly present both the perceived benefits, and the potential negative consequences. I can see several. I think much of the claim to gain here can be won back by not gathering per-layer statistics at the GOEM level, and collapsing the GEOM layers to direct block references, when possible (for example). I also think it's sort of a half-approach to getting rid of struct fileops, which is the real source of the problem here, not the fact that the thing holding the struct fileops pointer happens to be a vnode. How's this going to effect diskless boots? What about the mmap() of /dev/zero for anonymous pages? What about doing descriptor passing it off to another program? What does the author honestly think it will break, such that it needs a "Heads Up!" warning? Does everyone value the things that will break as little as the author, or is it just something he doesn't use, so it's not important to him? I really hate when someone posts something that is effectively nothing more than propaganda in favor of something that they haven't documented in sufficient detail and/or provided their own list of the negative consequences, such that people can form an informed opinion on the merits of the idea, instead of deciding based on personalities, or how effective someone is at writing propaganda in favor of what they intend to do anyway. -- Terry