Date: Mon, 30 Oct 1995 11:52:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett A. Wollman) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Message-ID: <199510301852.LAA06119@phaeton.artisoft.com> In-Reply-To: <9510291813.AA26273@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 29, 95 01:13:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [CC list trimmed AGAIN. Can you please get this discussion OUT of > cvs-committers?] Hey, I just reply. If it's there in your to list, it's there in mine. 8-). > > I understand the rationale for considering the changes. I don't understand > > the rationale for making them. It seems the rationale is "to compete with > > NetBSD and Linux regarding speed". Is this correct? > > > I personally don't find that compelling (that's not to say that the > > majority doesn't outweigh me on this -- only that it does not convince > > me, personally). > > Every microsecond counts. I agree with this to a point: I am a computational nanosecond kind of guy. But the reason the Mac hasn't failed yet when by all rights it should have died a long time ago is that when a tradeoff between the user and the programmer needed to be made, the trade off was made in favor of the user. This issue is on an orthogonal axis of speed vs. portability, and while I'd never say make the trade for portability in all cases, neither would I advocate trading for speed in all cases. The Mac had the luxury of hanging out on the far end of one axis because everyone else was on the opposite side of center. BSD does not have that luxury. > I am presently having to design a disgusting hack in the kernel which > allows our traffic generator to run in the kernel because it is not > possible to fill an Ethernet with minimum-length UDP packets when > crossing the system call boundary. Isn't this really a synchronous interface turn around issue that could be resolved by causing O_NDELAY to cause the operation to return immediately at the syscall layer so that another operation could follow immediately on its heels? This seems to be an issue more closely related to kernel threads and/or an alternate async call gate than anything else. > As for the `off_t' question: you will never convince me that the > Berkeley people did not do the right thing. I still hold out hope > that it will be possible to create a proper ISO C environment for > FreeBSD in which CHAR_BIT*sizeof(long) == 64. Certainly, the on disk storage should be invariant (or variant only in byte/word order, not in storage size). But most likely, the quad vs. long[2] abstraction should have taken place by macroizing the element references to cause them to "turn into longs" for the same speed arguments that keeps us from having better than 2G file sizes in the VM system today. I also agree that CHAR_BIT*sizeof(long) == 64 would go a long way toward solving the issue. But it would (unless int == 32 at the same time) lose us either atomic 32 or atomic 16 bit object access, which is unacceptable. Probably we would trade quad for "short short == 16" to get at on disk sized structures, or some similar abomination (quad is itself, an abomination). I think we would be equally served by violating the standard int/long size relationship as we are by violating the off_t underlying type relationship. C really needs sized types. 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?199510301852.LAA06119>