Date: Sun, 15 Dec 2002 14:24:31 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Lawson <nate@root.org>, phk@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: setattr() syscall as proposed by phk Message-ID: <200212152224.gBFMOVAG098468@apollo.backplane.com> References: <Pine.BSF.4.21.0212151211031.44745-100000@root.org> <200212152111.gBFLB5WI093761@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
And, I will also add, in regards to using the stat structure for
setattr(), that it creates a serious portability problem as well as
a serious forward and reverse compatibility problem. Which fields
in the stat structure are going to be ignored by the syscall and
which are not? You don't know and there is no way to tell. What
happens when some of the modifying operations are allowed and some
aren't? There is no way to tell, there is no way to return an error
indicating where the problem is. How do you tell setattr() not
to modify certain fields? There is no way to do it other then to
store special values in the stat structure. What happens to forward
portability if the stat structure gets something you didn't know
existed and you don't want to change the new field? There is no way
to deal with it.
In short, using the stat structure for something like this is a bad
idea. The system call will wind up being one of those things that
we constantly break from release to release as new things come up.
If this is going to be done, it needs to be done properly, and
while the stat structure may give us instant gratification it will
only bite us in the ass down the line.
-Matt
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?200212152224.gBFMOVAG098468>