Date: Tue, 27 May 1997 18:16:31 -0400 (EDT) From: Ben Black <black@zen.cypher.net> To: Christopher Sedore <cmsedore@mailbox.syr.edu> Cc: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <Pine.LNX.3.91.970527180624.1463I-100000@zen.cypher.net> In-Reply-To: <Pine.SOL.3.95.970527165604.11761B-100000@rodan.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.91.970527180624.1463I-100000>