Date: Sat, 13 Sep 1997 22:01:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@FreeBSD.ORG (Poul-Henning Kamp) Cc: fs@FreeBSD.ORG Subject: Re: getcwd() as syscall... Message-ID: <199709132201.PAA29443@usr03.primenet.com> In-Reply-To: <5464.874183620@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 13, 97 10:47:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 ?
I'd say try the cache first, and then do the work in the kernel to
make it work. The work is going to be done on the users dime (quantum)
anyway. Knowing the parent will save looking up "..". Otherwise, it
won't be used much because it won't work on anything but UFS.
There may be a problem with this, however, given that the parent
may not know about the child.
If the child has been deleted while it was someone's current
directory, then the parent value needs to be set to 0 (or whatever
other marker value) so that people with it open can distinguish
an orphaned open directory from an unorphaned one. You can't
use the link count because multiple people might have it open,
and you won't be able to distinguish that from "I have it open and
the other links are '.' and the one in the parent".
Note: you need different markers for "deleted" and "root of FS";
I think "root of FS" should have itself (2) as the parent.
Other than that, it's a *great* idea, and the purpose behind
the parent pointers in the first place. 8-) 8-).
Oh... is there an option to fsck to set these on a legacy FS?
And has newfs been fixed to fill the values in for the default
director{y/ies}? I know the code has a "create lost+found" option,
even if it is never exercised...
Finally, I'd be *real* tempted to make it an fcntl() instead of
a system call, and make "-1" mean "cwd", so it can be used on fd's
pointing to directories (saves on the system call name space, too).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709132201.PAA29443>