From owner-freebsd-hackers Tue May 27 15:17:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07031 for hackers-outgoing; Tue, 27 May 1997 15:17:15 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA07023 for ; Tue, 27 May 1997 15:17:06 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id SAA06467; Tue, 27 May 1997 18:16:33 -0400 Date: Tue, 27 May 1997 18:16:31 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > how do you spell kludge? > > Why does this qualify as a kludge (and a better question might be "how do > you pronounce kludge?" :). > it is a kludge because it is in there for EXACTLY one purpose. you couldn't use the facilities for any but transferring a file from one host to another. it is only there to get around a general problem for a specific application. that's a kludge. > It seems to me that a good test set for what facilities should be in the > kernel might include: > > 1. can the kernel do it significantly more efficiently that the user? and if not, is that because the kernel needs to be reworked rather than hacked up to solve a single problem. > 2. can it be implemented in userland and if so, is it likely to be highly > duplicated code? and if it can be implemented well at user level and is duplicated code, why is that code in the kernel at all? > 3. what is the expense to the kernel of doing this? > > > The answer to #1 is yes, much more efficiently. because there is no *general* facility for doing high-speed, low-latency networking. this does not argue for the nastiness you describe in NT. > The answer to #2 is yes, it can, but it is very likely to be duplicated see above. > The answer to #3 is a maybe 1k of code (at most) and no mods to critical > performance sections in the kernel. > 1k of application specific code. sounds like a waste. > #2 is really a test question for a library rather than the kernel, but, > where applicable, it should also be applied to kernel calls. > > Maybe not, but I don't think I could even get my code to run under FBSD > without some non-trivial rearrangement because of facilities that don't > exist or are costly to use (I'm not happy about the idea of checking 800 > connections with an FD_ISSET() loop). > so use 800 threads with a single fd each. > > You can shrink the kernel continuously, down to something like: > > kernel: > jmp kernel > > and it will be very fast, but not terribly useful. :) This certainly > maximizes both your criteria for kernel characteristics (and it also would > probably meet very stringent reliability standards :). I happen to have > more criteria than small and fast. > > Functions that can be executed without penalty in userland should be, > those that are highly duplicated and pay an userland penalty deserve > consideration for kernel inclusion, IMHO. > and you have presented no evidence that it needs to be in the kernel. i have suggested fbufs and various eros techniques while you have just listed why *something* is needed. it *can* be done cleanly and quickly assuming proper kernel support. adding an application specific system call to the kernel is just a bad idea. b3n