From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 4 21:01:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6087D106564A for ; Tue, 4 Aug 2009 21:01:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 20EC58FC08 for ; Tue, 4 Aug 2009 21:01:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C748646B0D; Tue, 4 Aug 2009 17:01:56 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0B8028A0A8; Tue, 4 Aug 2009 17:01:56 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 4 Aug 2009 08:08:04 -0400 User-Agent: KMail/1.9.7 References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> In-Reply-To: <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200908040808.05074.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 04 Aug 2009 17:01:56 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Maslan , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Subject: Re: sosend() and mbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 21:01:57 -0000 On Monday 03 August 2009 5:25:27 pm Maslan wrote: > No my code doesn't work, I thought it may be because that soaccept() > -which is not found in man 9- is non-blocking, so i've to put my code > in a thread. > Now i got another problem, when I open a text file from this thread, > the kernel crashes, I'm sure that its the thread. > > kthread_create((void *)thread_main, NULL, NULL, RFNOWAIT, 0, "thread"); > > void thread_main(){ > struct thread *td = curthread; > int ret; > int fd; > ret = f_open("/path/to/file.txt", &fd); > printf("%d\n", ret); > tsleep(td, PDROP, "test tsleep", 10*hz); > f_close(fd); > kthread_exit(0); > } > > int f_open(char *filename, int *fd){ > struct thread *td = curthread; > int ret = kern_open(td, filename, UIO_SYSSPACE, O_RDONLY, FREAD); > if(!ret){ > *fd = td->td_retval[0]; > return 1; > } > return 0; > } kthread's / kproc's do not have a valid file descriptor table. I think you are probably not going to be happy trying to stuff a full httpd in the kernel, btw. I think instead you should look at creative ways of exposing certain bits of what you need to userland instead where possible. Alternatively, you could use a caching accelerator of some sort that maps known URLs to specific vnodes so you can reply to those directly, but when you miss in your cache you wake up a userland process which processes the URL and opens a file and you can then save the vnode from that file handle in your cache. However, stuffing httpd into the kernel may not buy you an appreciable amount of gain relative to the expense of making it work. BTW, kern_open() "works" in your module handler because the module handler runs in the kernel half of the thread from the kldload command. And when you do "kern_open()" you are actually opening a new file descriptor in the kldload process. This is quite a bad, bad idea to be indiscriminately screwing with user process' file descriptors behind their back. A brief search in the archives should cover how to initalize the necessary vnode references for a kproc's file descriptor table so that namei() works (and then you can use vn_open(), but _not_ kern_open()). I answered that question just last week in another thread ("Driver development question" on drivers@). However, in general the kernel is not nearly as friendly an environment as userland, and it can be quite saner and easier to debug if you export certain bits of the kernel to userland to accelerate portions of your application than moving the application into the kernel in my experience. -- John Baldwin