On Mon, Feb 8, 2010 at 12:11 AM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >>On Sun, Feb 7, 2010 at 2:09 PM, Theo de Raadt <dera...@cvs.openbsd.org> >>wrote: >>>> Why does cp need to be portable? B Who's porting OpenBSD cp to other >>systems? >>> >>> Will the same diff be added to every io generating program in /bin? >>> >>> They all generate io, of course. >> >>I was planning on something similar for tar. B But that's it really. >>They are the programs that read/write in a loop, where the >>reads/writes are blocked by writes/reads. B ls doesn't generate IO of >>the same magnitude as cp, the writes are very small in proportion to >>reads, and the writes don't go to disk either. B Very different. >> >>Programs like scp are also unaffected (unless you forget the colon), >>because one of the ends is network. B The source and sink aren't >>dependent. > > And in mv, for the cross-device case? B I see others that do fast > reads, like sum. B diff? B cmp? B grep? B How many others? B If cp(1) > is such a common operation (I bet it isn't), how soon before other > programs doing exactly the same thing want the same chunk of code? > > I think adding big chunks of sysctl code to such specific applications > is very un-unix.
Some of us consider sysctl itself extremely un-unix (same goes for ioctl). Sometimes one wonders why 'modern' so called 'unix' systems bother implementing open/read/write/close at all. > If choosing a buffer size is going to be a common operation, it should > be an API called to "ask what the buffer size should be". B If that is > the case, it will soon over-commit the resources of the machine. B So > then it starts being something you want a system call for. B The unix > practice is to undercommit, and punish userland because userland is > commonly unefficient, while the kernel is trying to be efficient (as > much as it can). B This scaling undoes that. B cp will have it's > priority increased since it is "efficient", and an un-modified one > using the standard buffer sizes will be demoted. > > So I guess it begs for an extension to the UNIX system calls. > > That is a road that requires long consideration, to avoid overcommit. > You would not want a bunch of applications asking "how much should I > use", and then doing the allocation later. > > That is why I don't like what you are doing in cp. B I think your > heuristic is hasty. > > For those of you who asked why cp needs to be portable, come on. > You've got it all wrong. B If cp isn't written in a portable fashion, > then what is the point of doing anything else in a portable fashion. I agree completely, OpenBSD is one of the few *nix variants that retains an userspace displaying a minimum respect for the unix traditions; this includes simple and not too ugly implementations that are mostly portable. It would be great if the OpenBSD user space was more easily available for other systems (ala Plan 9 from User Space), and it is good to at least keep that possibility open; some of us often take advantage of the the existing OpenBSD source when we need a simple, sane and portable implementation of a certain unix command (for example I have used in the past some OpenBSD commands to expand Plan 9's APE PoSix compatibility environment). uriel
