From owner-cvs-all Thu Jun 15 23:40: 1 2000 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0592E37BD00; Thu, 15 Jun 2000 23:39:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA56354; Thu, 15 Jun 2000 23:39:53 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jun 2000 23:39:53 -0700 (PDT) From: Matthew Dillon Message-Id: <200006160639.XAA56354@apollo.backplane.com> To: Alfred Perlstein Cc: Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/sys socket.h References: <200006151818.LAA31278@freefall.freebsd.org> <200006151845.MAA25472@nomad.yogotech.com> <20000615120807.M18462@fw.wintelcom.net> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In regards to the HTTP specific code in the kernel. I have to say that I do not like the idea of placing application specific code in the kernel, but I do like the more 'general' idea of having the kernel wait for data before returning. Why not use the KLD mechanism to implement a more general 'loadable' socket filter rather then hardwiring specific protocols into the kernel? Then write a module for HTTP and the final result is that you get the feature you want, and the kernel gets a very powerful KLD socket-data filter mechanism. -Matt. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message