Date: Sun, 15 Dec 2002 13:11:05 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Lawson <nate@root.org> Cc: phk@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: setattr() syscall as proposed by phk Message-ID: <200212152111.gBFLB5WI093761@apollo.backplane.com> References: <Pine.BSF.4.21.0212151211031.44745-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
setattr() and friends do not exist anywhere outside of this proposal.
I don't particularly like the idea of replacing existing functionality
with a new non-standard system call. The speed issue alone is not enough
to justify the change, nor is Kirk's new creation time field (besides
I thought that field was not supposed to be changeable?).
--
In regards to the implementation itself, I really don't like the idea
of passing a stat structure as an argument. If we are going to have
a 'general' setattr() system call it should be extensible. That is,
something like this:
struct fsattr {
int token;
union {
char pad[32];
struct timeval tv;
time_t t;
etc....
} fsu;
}
struct fsattr attrs[] = { { SAT_MTIME, mtime}, { SAT_CTIME, ctime } };
setattr(path, attrs, nattrs);
But it should not take a stat structure. We have enough problems with
the stat structure changing as it is, IMHO. If we use an extensible
structure we won't ever have to change the system call.
This also brings up the possibility that we could integrate setattr-like
functions into the MAC layer, which is already extensible, yes?
-Matt
Matthew Dillon
<dillon@backplane.com>
:Heh, you took that too literally. I meant the IO is coming from a tape,
:disk, or other physical media device where latencies for a 32-64k xfer are
:usually on the order of 1-10 ms or more.
:
:> >So why is this faster? Something is likely slowing namei() down.
:>
:> Because 1 syscall and 2 namei calls are faster than 4 syscalls and
:> four namei calls.
:
:Which leaves us back at my previous point which is that something is wrong
:with caching if 4 namei calls (for the SAME name) are so much slower. A
:great task would be to examine/test namei(), identify why it's not cached
:correctly, and fix the underlying problem. The syscall boundary crossing
:is NOT significant here.
:
:-Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212152111.gBFLB5WI093761>