From owner-cvs-src@FreeBSD.ORG Thu Nov 10 13:57:12 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10D5D16A41F; Thu, 10 Nov 2005 13:57:12 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7548C43D48; Thu, 10 Nov 2005 13:57:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAADv5Pr031505; Thu, 10 Nov 2005 06:57:05 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <437351BB.6000103@samsco.org> Date: Thu, 10 Nov 2005 06:57:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White References: <1547.1131574569@critter.freebsd.dk> <20051109225823.Y62099@carver.gumbysoft.com> In-Reply-To: <20051109225823.Y62099@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Doug White , cvs-src@FreeBSD.org, Poul-Henning Kamp , src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/fs/devfs devfs_vnops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 13:57:12 -0000 Doug White wrote: > On Wed, 9 Nov 2005, Poul-Henning Kamp wrote: > > >>In message <200511092203.jA9M3omu013054@repoman.freebsd.org>, Doug White writes >>: >> >> >>> This is a workaround for a complicated issue involving VFS cookies and devfs. >>> The PR and patch have the details. The ultimate fix requires architectural >>> changes and clarifications to the VFS API, [...] >> >>The proper fix is to put the cookie in the dirent and abandon the >>microoptimization that UFS/FFS stores struct dirent directly on >>the disk. > > > It would be nice if you guys could sit down and figure out just which > "proper fix" you want implemented, since everyone seems to have their own > ideas. > Putting the cookie into the dirent means either changing the size of the dirent struct and breaking the userland ABI (almost as bad as changing the size of stat, but not quite), or making a 'kdirent' struct and then manually shifting and copying it to a dirent struct. Since the dirent struct is copied directly into the uio buffer by the filesystem code and not actually consumed by the caller of VOP_READDIR, it means that every filesystem would have to be messed with. Neither of these 'solutions' is very appealling, and I don't understand why the whole kernel and/or userland needs to pay a penalty because of devfs. Cookie handling is not a hard problem nor does it take a signficant amount of code. What I really think this is is a ploy by PHK to get someone motivated to fix it for him ;-) Scott