From owner-freebsd-fs Sat Sep 13 14:27:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA00721 for fs-outgoing; Sat, 13 Sep 1997 14:27:35 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA00712 for ; Sat, 13 Sep 1997 14:27:31 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id WAA05466 for ; Sat, 13 Sep 1997 22:47:01 +0200 (CEST) To: fs@freebsd.org Subject: getcwd() as syscall... From: Poul-Henning Kamp Date: Sat, 13 Sep 1997 22:47:00 +0200 Message-ID: <5464.874183620@critter.freebsd.dk> Sender: owner-freebsd-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Now that we have v_dd and v_ddid in the vnodes, and since the namecache is quite reluctant to throw out directories, it would be possible to make a "getcwdifyoucan()" syscall, which would run a lot faster than the getcwd() library routine. The "ifyoucan" bit reflects that it may actually not be able to if the required information isn't in the namecache, in which case I would prefer to have userland fall back to the usual method, rather than have to implement it in the kernel. I have no idea how much this would or wouldn't save in time. I know that during a "make world", 13 % of the name cache lookups are for "..", and quite a number of these probably come from getcwd(), so there is something to go aim for. Comments ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."