From owner-freebsd-hackers Sun Dec 15 13:11: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE5E37B401; Sun, 15 Dec 2002 13:11:05 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84D0A43E4A; Sun, 15 Dec 2002 13:11:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gBFLB5OM093762; Sun, 15 Dec 2002 13:11:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gBFLB5WI093761; Sun, 15 Dec 2002 13:11:05 -0800 (PST) (envelope-from dillon) Date: Sun, 15 Dec 2002 13:11:05 -0800 (PST) From: Matthew Dillon Message-Id: <200212152111.gBFLB5WI093761@apollo.backplane.com> To: Nate Lawson Cc: phk@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: setattr() syscall as proposed by phk References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :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