From owner-freebsd-chat Thu Jul 15 11:55:34 1999 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 89E7F155E6 for ; Thu, 15 Jul 1999 11:55:31 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 15 Jul 1999 11:54:35 -0700 From: "David Schwartz" To: "Terry Lambert" Cc: , , , Subject: RE: Known MMAP() race conditions ... ? Date: Thu, 15 Jul 1999 11:54:35 -0700 Message-ID: <001101becef3$7b5056b0$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <199907151842.LAA29095@usr07.primenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On FreeBSD, I'm basically screwed. I'd have to write me own resolver > > library to do the job. Licensing problems prevent me from using > pretty much > > every nice resolver library out there. > > The bind 8.x stuff doesn't have licensing issues; it allows multiple > concurrent operations. It is merely that the 4.x resolved is wedged > into libc that causes your problem. The bind license has 'forced speech' requirement. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. > > > Completion ports are no more, and no less, than VMS AST's. Just > > > like aio* in FreeBSD, and much of the POSIX crap that's passing > > > for standards these days. Completion ports are not about asynchronous I/O. They're not about having your I/O routines called automatically. They're about having the optimimum number of threads running. What completion ports do is allow a group of threads to be associated such that if one thread blocks, another one is automatically freed. This way, on an N processor machine, you can nearly always have N active threads. This is extremely difficult to do well on pretty much every UNIX. > > > They may make it easier to code, by calling your callbacks, but > > > the idea that network buffers should be in user space instead of > > > on the kernel side of the protection domain barrier is just > > > plain nuts. I'm not really sure why you feel that way. If there weren't performance issues, I don't see why you wouldn't want the whole network stack to be in user space. > > They're on both sides in every implementation. It's just a > matter of when > > the borders get crossed. > > I disagree. I can turn around reads and writes in the kernel without > taking the copy overhead. NFS does this, and a KLD that could do this > for SAMBA and AFS, while not trivial, given the state of the FreeBSD > VFS interface, the protocol stack incursions for routing of the > specific packets, and the mbuf reference to buffer cache objects that > would be required, is well within the realm of possibility. If > anything, the ability to use the GPL'ed SAMBA code in the Linux > kernel may well be the deciding factor for eventual FreeBSD vs. > Linux SMB performance, the same as it was for Linux vs. FreeBSD NFS > performance. That is true. But it's really not relevant to the current discussion. But I still think it's better to pull everything into user space to avoid copies rather than push everything into kernel space. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message