From owner-freebsd-current@FreeBSD.ORG Thu Jul 10 19:37:29 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93138106568D for ; Thu, 10 Jul 2008 19:37:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2F38FC14 for ; Thu, 10 Jul 2008 19:37:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.40] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m6AJI2mZ057545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 12:18:04 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48766067.6090008@FreeBSD.org> Date: Thu, 10 Jul 2008 12:17:59 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Maksim Yevmenkin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: network protocol stacks in userspace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2008 19:37:29 -0000 Maksim Yevmenkin wrote: > somewhat generic implementation. each pru_xxx request loops back to > user space in a form of an event/message. such events could be > completely synchronous (blocking connect(), accept(), read() etc.) or > asynchronous (non-blocking connect(), etc.). each "loop" socket will > have either no or very little pcb associated with it - it will just > the socket's state. from user space each "loop" socket will be > accessible using its file descriptor and regular socket api and via > /dev/loopsock device node (or possibly create device node for each > "loop" socket). Not necessary the best way to do it in this case, but one approach would be to have some kind of "syscall diversion" layer, which would allow some/all syscalls issued by one process to be diverted for actual execution to another userland process. I am sure such layer could have other interesting applications. -Maxim