Date: Wed, 3 Dec 1997 00:14:52 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_aio.c Message-ID: <199712030014.RAA01867@usr06.primenet.com> In-Reply-To: <3180.881092488@critter.freebsd.dk> from "Poul-Henning Kamp" at Dec 2, 97 08:54:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On the subject of the change, the majority by number (and as far as I > have been able to measure: by usage) of our syscalls do not use the > retval for anything. Consequently it is a waste of time to move it > around on the stack like we did. I think that people are too hung up on "I must see this much win for a change to be considered good". I think the larger issues are being ignored: 1) What future work is enabled/disallowed by this change? This must be the primary consideration. If Poul needs the change for future work, it should go in, even if there is net zero win. 2) How does the change impact the need for machine specific code? If it decreases the need for machine specific code, then it makes porting to a new architecture easier. Porting to a new architecture is probably going to require a "generic" version of a lot of code that is currently in assembly, and that can be made into assembly code on the new platform after a minimally functional system exists (this is, at least how I've approached the problem). If there is a decrease in machine specificity, and thus enables future work, it should go in, even if there is a net zero win. 3) What are the ramifications for the proc structure? If this change doesn't push the proc structure over a power of two boundry, or it brings it under a power of two boundry, it's either a NOP or a win. Either way, the proc structure changes more frequently than a politicians stance on an issue, and if anything, it will be incentive to solve the use of kmem as an external interface, and it should go in, even if there is a net zero win. There is such a thing as "building a platform for future work"; squash that for the lack of a short term win, and you squash *good* research for the dubious benefit of maintaining the status quo. 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?199712030014.RAA01867>