From owner-freebsd-arch@FreeBSD.ORG Tue Jan 1 02:36:23 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59A3A16A417 for ; Tue, 1 Jan 2008 02:36:23 +0000 (UTC) (envelope-from BearPerson@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A60D113C447 for ; Tue, 1 Jan 2008 02:36:22 +0000 (UTC) (envelope-from BearPerson@gmx.net) Received: (qmail invoked by alias); 01 Jan 2008 02:36:21 -0000 Received: from port-83-236-56-222.dynamic.qsc.de (EHLO gmx.net) [83.236.56.222] by mail.gmx.net (mp042) with SMTP; 01 Jan 2008 03:36:21 +0100 X-Authenticated: #20254835 X-Provags-ID: V01U2FsdGVkX1/X33o1CIHXo+91lforUlsdVAYusvr6b3/azIyaLv yG01/ldY71BZBl Date: Tue, 1 Jan 2008 03:36:20 +0100 From: Karsten Behrmann To: freebsd-arch@freebsd.org Message-ID: <20080101033620.4050569c@Karsten.Behrmanns.Kasten> In-Reply-To: <4774DBB2.5060707@FreeBSD.org> References: <200712271704.44796.jhb@FreeBSD.org> <4774DBB2.5060707@FreeBSD.org> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.8.18; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: kernel features MIB X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 02:36:23 -0000 On Fri, 28 Dec 2007 12:19:14 +0100, Kris Kennaway wrote: > John Baldwin wrote: >> One of the things we have at work is a kern.features sysctl MIB that contains >> nodes to indicate if a named feature is present. For example, on i386 we >> have kern.features.pae and we auto enable -DPAE for kernel modules if the >> currently running kernel is using PAE using that sysctl. >>[...] >> Any objections to the idea? > > I have wanted something like this for a long time. In ports land they > often need to know this kind of thing, e.g. is compat4x support enabled > in the kernel, etc. Hmm. But will everyone be running a kernel and system that the stuff they build will later run on? (when upgrading, or when building kernel and tools to be installed via NFS and pals) Mind, it could be a good heuristic for the common cases, and directly useful for some libraries, but I'm thinking that we may need some easily- accessible override knobs. I could be wrong, though. Karsten -- Open source is not about suing someone who sells your software. It is about being able to walk behind him, grinning, and waving free CDs with the equivalent of what he is trying to sell. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 1 10:59:50 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E98416A418 for ; Tue, 1 Jan 2008 10:59:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A2AC113C447; Tue, 1 Jan 2008 10:59:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A1D16.2090605@FreeBSD.org> Date: Tue, 01 Jan 2008 11:59:34 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Karsten Behrmann References: <200712271704.44796.jhb@FreeBSD.org> <4774DBB2.5060707@FreeBSD.org> <20080101033620.4050569c@Karsten.Behrmanns.Kasten> In-Reply-To: <20080101033620.4050569c@Karsten.Behrmanns.Kasten> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: kernel features MIB X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 10:59:50 -0000 Karsten Behrmann wrote: > On Fri, 28 Dec 2007 12:19:14 +0100, Kris Kennaway wrote: >> John Baldwin wrote: >>> One of the things we have at work is a kern.features sysctl MIB that contains >>> nodes to indicate if a named feature is present. For example, on i386 we >>> have kern.features.pae and we auto enable -DPAE for kernel modules if the >>> currently running kernel is using PAE using that sysctl. >>> [...] >>> Any objections to the idea? >> I have wanted something like this for a long time. In ports land they >> often need to know this kind of thing, e.g. is compat4x support enabled >> in the kernel, etc. > > Hmm. But will everyone be running a kernel and system that the stuff they > build will later run on? (when upgrading, or when building > kernel and tools to be installed via NFS and pals) > > Mind, it could be a good heuristic for the common cases, and directly > useful for some libraries, but I'm thinking that we may need some easily- > accessible override knobs. I could be wrong, though. It would just be used to display informational messages about the need to recompile the kernel, etc. Kris From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 22:53:59 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E957C16A41A for ; Wed, 2 Jan 2008 22:53:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5407013C46A for ; Wed, 2 Jan 2008 22:53:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81381 invoked from network); 2 Jan 2008 22:19:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 22:19:15 -0000 Message-ID: <477C1604.2030905@freebsd.org> Date: Wed, 02 Jan 2008 23:53:56 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: John Baldwin References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> In-Reply-To: <200712271805.40972.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:54:00 -0000 John Baldwin wrote: > On Sunday 02 December 2007 07:53:18 am Andre Oppermann wrote: >> Poul-Henning Kamp wrote: >>> In message <4752998A.9030007@freebsd.org>, Andre Oppermann writes: >>>> o TCP puts the timer into an allocated structure and upon close of the >>>> session it has to be deallocated including stopping of all currently >>>> running timers. >>>> [...] >>>> -> The timer facility should provide an atomic stop/remove call >>>> that prevent any further callbacks upon return. It should not >>>> do a 'drain' where the callback may be run anyway. >>>> Note: We hold the lock the callback would have to obtain. >>> It is my intent, that the implementation behind the new API will >>> only ever grab the specified lock when it calls the timeout function. >> This is the same for the current one and pretty much a given. >> >>> When you do a timeout_disable() or timeout_cleanup() you will be >>> sleeping on a mutex internal to the implementation, if the timeout >>> is currently executing. >> This is the problematic part. We can't sleep in TCP when cleaning up >> the timer. We're not always called from userland but from interrupt >> context. And when calling the cleanup we currently hold the lock the >> callout wants to obtain. We can't drop it either as the race would >> be back again. What you describe here is the equivalent of callout_ >> drain(). This is unfortunately unworkable in TCP's context. The >> callout has to go away even if it is already pending and waiting on >> the lock. Maybe that can only be solved by a flag in the lock saying >> "give up and go away". > > The reason you need to do a drain is to allow for safe destroying of the lock. > Specifically, drivers tend to do this: > > FOO_LOCK(sc); > ... > callout_stop(...); > FOO_UNLOCK(sc); > ... > callout_drain(...); > ... > mtx_destroy(&sc->foo_mtx); > > If you don't have the drain and softclock is trying to acquire the backing > mutex while you have it held (before the callout_stop) then Bad Things can > happen if you don't do the drain. Having the lock just "give up" doesn't > work either because if the memory containing the lock is free'd and > reinitialized such that it looks enough like a valid lock then softclock (or > its equivalent) will still try to obtain it. Also, you need to do a drain so > it is safe to free the callout structure to prevent it from being recycled > and having weird races where it gets recycled and rescheduled but the timer > code thinks it has a pending stop for that pointer and so it aborts the wrong > instance of the timer, etc. This is all well known. ;) What isn't known is that this (the sleep part) is a major problem for TCP due to being run from interrupt context. Hence the request for some kind of busy-drain or other method prevent the sleep. A second less severe problem are races while the lock is dropped during the sleep. Here some other part of TCP may go into the tcpcb scheduled for destruction. -- Andre From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 22:56:21 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27A0916A41A; Wed, 2 Jan 2008 22:56:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D83E213C442; Wed, 2 Jan 2008 22:56:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B97DA486D8; Wed, 2 Jan 2008 17:56:19 -0500 (EST) Date: Wed, 2 Jan 2008 22:56:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <477C1604.2030905@freebsd.org> Message-ID: <20080102225534.U30578@fledge.watson.org> References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:56:21 -0000 On Wed, 2 Jan 2008, Andre Oppermann wrote: >> If you don't have the drain and softclock is trying to acquire the backing >> mutex while you have it held (before the callout_stop) then Bad Things can >> happen if you don't do the drain. Having the lock just "give up" doesn't >> work either because if the memory containing the lock is free'd and >> reinitialized such that it looks enough like a valid lock then softclock >> (or its equivalent) will still try to obtain it. Also, you need to do a >> drain so it is safe to free the callout structure to prevent it from being >> recycled and having weird races where it gets recycled and rescheduled but >> the timer code thinks it has a pending stop for that pointer and so it >> aborts the wrong instance of the timer, etc. > > This is all well known. ;) What isn't known is that this (the sleep part) > is a major problem for TCP due to being run from interrupt context. Hence > the request for some kind of busy-drain or other method prevent the sleep. > A second less severe problem are races while the lock is dropped during the > sleep. Here some other part of TCP may go into the tcpcb scheduled for > destruction. We do need to fix this -- if it can be done by fixing the callout system, I'm all for it. Otherwise we probably need to add a tcpcb GC thread that picks up the pieces in a sleepable context. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 22:56:21 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27A0916A41A; Wed, 2 Jan 2008 22:56:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D83E213C442; Wed, 2 Jan 2008 22:56:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B97DA486D8; Wed, 2 Jan 2008 17:56:19 -0500 (EST) Date: Wed, 2 Jan 2008 22:56:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <477C1604.2030905@freebsd.org> Message-ID: <20080102225534.U30578@fledge.watson.org> References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:56:21 -0000 On Wed, 2 Jan 2008, Andre Oppermann wrote: >> If you don't have the drain and softclock is trying to acquire the backing >> mutex while you have it held (before the callout_stop) then Bad Things can >> happen if you don't do the drain. Having the lock just "give up" doesn't >> work either because if the memory containing the lock is free'd and >> reinitialized such that it looks enough like a valid lock then softclock >> (or its equivalent) will still try to obtain it. Also, you need to do a >> drain so it is safe to free the callout structure to prevent it from being >> recycled and having weird races where it gets recycled and rescheduled but >> the timer code thinks it has a pending stop for that pointer and so it >> aborts the wrong instance of the timer, etc. > > This is all well known. ;) What isn't known is that this (the sleep part) > is a major problem for TCP due to being run from interrupt context. Hence > the request for some kind of busy-drain or other method prevent the sleep. > A second less severe problem are races while the lock is dropped during the > sleep. Here some other part of TCP may go into the tcpcb scheduled for > destruction. We do need to fix this -- if it can be done by fixing the callout system, I'm all for it. Otherwise we probably need to add a tcpcb GC thread that picks up the pieces in a sleepable context. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:20:41 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B8316A417 for ; Wed, 2 Jan 2008 23:20:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7962113C4CC for ; Wed, 2 Jan 2008 23:20:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81381 invoked from network); 2 Jan 2008 22:19:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 22:19:15 -0000 Message-ID: <477C1604.2030905@freebsd.org> Date: Wed, 02 Jan 2008 23:53:56 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: John Baldwin References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> In-Reply-To: <200712271805.40972.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:20:41 -0000 John Baldwin wrote: > On Sunday 02 December 2007 07:53:18 am Andre Oppermann wrote: >> Poul-Henning Kamp wrote: >>> In message <4752998A.9030007@freebsd.org>, Andre Oppermann writes: >>>> o TCP puts the timer into an allocated structure and upon close of the >>>> session it has to be deallocated including stopping of all currently >>>> running timers. >>>> [...] >>>> -> The timer facility should provide an atomic stop/remove call >>>> that prevent any further callbacks upon return. It should not >>>> do a 'drain' where the callback may be run anyway. >>>> Note: We hold the lock the callback would have to obtain. >>> It is my intent, that the implementation behind the new API will >>> only ever grab the specified lock when it calls the timeout function. >> This is the same for the current one and pretty much a given. >> >>> When you do a timeout_disable() or timeout_cleanup() you will be >>> sleeping on a mutex internal to the implementation, if the timeout >>> is currently executing. >> This is the problematic part. We can't sleep in TCP when cleaning up >> the timer. We're not always called from userland but from interrupt >> context. And when calling the cleanup we currently hold the lock the >> callout wants to obtain. We can't drop it either as the race would >> be back again. What you describe here is the equivalent of callout_ >> drain(). This is unfortunately unworkable in TCP's context. The >> callout has to go away even if it is already pending and waiting on >> the lock. Maybe that can only be solved by a flag in the lock saying >> "give up and go away". > > The reason you need to do a drain is to allow for safe destroying of the lock. > Specifically, drivers tend to do this: > > FOO_LOCK(sc); > ... > callout_stop(...); > FOO_UNLOCK(sc); > ... > callout_drain(...); > ... > mtx_destroy(&sc->foo_mtx); > > If you don't have the drain and softclock is trying to acquire the backing > mutex while you have it held (before the callout_stop) then Bad Things can > happen if you don't do the drain. Having the lock just "give up" doesn't > work either because if the memory containing the lock is free'd and > reinitialized such that it looks enough like a valid lock then softclock (or > its equivalent) will still try to obtain it. Also, you need to do a drain so > it is safe to free the callout structure to prevent it from being recycled > and having weird races where it gets recycled and rescheduled but the timer > code thinks it has a pending stop for that pointer and so it aborts the wrong > instance of the timer, etc. This is all well known. ;) What isn't known is that this (the sleep part) is a major problem for TCP due to being run from interrupt context. Hence the request for some kind of busy-drain or other method prevent the sleep. A second less severe problem are races while the lock is dropped during the sleep. Here some other part of TCP may go into the tcpcb scheduled for destruction. -- Andre From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:23:34 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF2E16A41B for ; Wed, 2 Jan 2008 23:23:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0663113C45A for ; Wed, 2 Jan 2008 23:23:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81600 invoked from network); 2 Jan 2008 22:48:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 22:48:49 -0000 Message-ID: <477C1CF3.6070301@freebsd.org> Date: Thu, 03 Jan 2008 00:23:31 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Robert Watson References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> <20080102225534.U30578@fledge.watson.org> In-Reply-To: <20080102225534.U30578@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:23:34 -0000 Robert Watson wrote: > > On Wed, 2 Jan 2008, Andre Oppermann wrote: > >>> If you don't have the drain and softclock is trying to acquire the >>> backing mutex while you have it held (before the callout_stop) then >>> Bad Things can happen if you don't do the drain. Having the lock >>> just "give up" doesn't work either because if the memory containing >>> the lock is free'd and reinitialized such that it looks enough like a >>> valid lock then softclock (or its equivalent) will still try to >>> obtain it. Also, you need to do a drain so it is safe to free the >>> callout structure to prevent it from being recycled and having weird >>> races where it gets recycled and rescheduled but the timer code >>> thinks it has a pending stop for that pointer and so it aborts the >>> wrong instance of the timer, etc. >> >> This is all well known. ;) What isn't known is that this (the sleep >> part) is a major problem for TCP due to being run from interrupt >> context. Hence the request for some kind of busy-drain or other >> method prevent the sleep. A second less severe problem are races while >> the lock is dropped during the sleep. Here some other part of TCP may >> go into the tcpcb scheduled for destruction. > > We do need to fix this -- if it can be done by fixing the callout > system, I'm all for it. Otherwise we probably need to add a tcpcb GC > thread that picks up the pieces in a sleepable context. I fear we have to go for the latter. Getting a non-sleeping callout drain seems to be non-trivial. -- Andre From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:23:35 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D4D16A469 for ; Wed, 2 Jan 2008 23:23:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1363813C467 for ; Wed, 2 Jan 2008 23:23:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81600 invoked from network); 2 Jan 2008 22:48:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 22:48:49 -0000 Message-ID: <477C1CF3.6070301@freebsd.org> Date: Thu, 03 Jan 2008 00:23:31 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Robert Watson References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> <20080102225534.U30578@fledge.watson.org> In-Reply-To: <20080102225534.U30578@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:23:36 -0000 Robert Watson wrote: > > On Wed, 2 Jan 2008, Andre Oppermann wrote: > >>> If you don't have the drain and softclock is trying to acquire the >>> backing mutex while you have it held (before the callout_stop) then >>> Bad Things can happen if you don't do the drain. Having the lock >>> just "give up" doesn't work either because if the memory containing >>> the lock is free'd and reinitialized such that it looks enough like a >>> valid lock then softclock (or its equivalent) will still try to >>> obtain it. Also, you need to do a drain so it is safe to free the >>> callout structure to prevent it from being recycled and having weird >>> races where it gets recycled and rescheduled but the timer code >>> thinks it has a pending stop for that pointer and so it aborts the >>> wrong instance of the timer, etc. >> >> This is all well known. ;) What isn't known is that this (the sleep >> part) is a major problem for TCP due to being run from interrupt >> context. Hence the request for some kind of busy-drain or other >> method prevent the sleep. A second less severe problem are races while >> the lock is dropped during the sleep. Here some other part of TCP may >> go into the tcpcb scheduled for destruction. > > We do need to fix this -- if it can be done by fixing the callout > system, I'm all for it. Otherwise we probably need to add a tcpcb GC > thread that picks up the pieces in a sleepable context. I fear we have to go for the latter. Getting a non-sleeping callout drain seems to be non-trivial. -- Andre From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:26:31 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6625816A469; Wed, 2 Jan 2008 23:26:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 165E213C4F4; Wed, 2 Jan 2008 23:26:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5921717105; Wed, 2 Jan 2008 23:26:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m02NQN8W002068; Wed, 2 Jan 2008 23:26:24 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 00:23:31 +0100." <477C1CF3.6070301@freebsd.org> Date: Wed, 02 Jan 2008 23:26:23 +0000 Message-ID: <2067.1199316383@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:26:31 -0000 In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >I fear we have to go for the latter. Getting a non-sleeping callout >drain seems to be non-trivial. There is a crucial difference between "non-sleeping" and "not sleeping on my lock" that you should be very careful about in this context. Which is your requirement ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:26:31 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6625816A469; Wed, 2 Jan 2008 23:26:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 165E213C4F4; Wed, 2 Jan 2008 23:26:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5921717105; Wed, 2 Jan 2008 23:26:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m02NQN8W002068; Wed, 2 Jan 2008 23:26:24 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 00:23:31 +0100." <477C1CF3.6070301@freebsd.org> Date: Wed, 02 Jan 2008 23:26:23 +0000 Message-ID: <2067.1199316383@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:26:31 -0000 In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >I fear we have to go for the latter. Getting a non-sleeping callout >drain seems to be non-trivial. There is a crucial difference between "non-sleeping" and "not sleeping on my lock" that you should be very careful about in this context. Which is your requirement ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:07:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093A316A46B for ; Thu, 3 Jan 2008 00:07:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 66AC313C4F7 for ; Thu, 3 Jan 2008 00:07:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81891 invoked from network); 2 Jan 2008 23:32:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 23:32:39 -0000 Message-ID: <477C2739.5000902@freebsd.org> Date: Thu, 03 Jan 2008 01:07:21 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2067.1199316383@critter.freebsd.dk> In-Reply-To: <2067.1199316383@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:07:25 -0000 Poul-Henning Kamp wrote: > In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: > >> I fear we have to go for the latter. Getting a non-sleeping callout >> drain seems to be non-trivial. > > There is a crucial difference between "non-sleeping" and "not sleeping > on my lock" that you should be very careful about in this context. > > Which is your requirement ? Calling timeout_drain() must not sleep and not drop the lock in this context (while making any pending timeout go away forever). -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:07:25 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10AF316A46E for ; Thu, 3 Jan 2008 00:07:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B38113C4F8 for ; Thu, 3 Jan 2008 00:07:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81891 invoked from network); 2 Jan 2008 23:32:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 23:32:39 -0000 Message-ID: <477C2739.5000902@freebsd.org> Date: Thu, 03 Jan 2008 01:07:21 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2067.1199316383@critter.freebsd.dk> In-Reply-To: <2067.1199316383@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:07:25 -0000 Poul-Henning Kamp wrote: > In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: > >> I fear we have to go for the latter. Getting a non-sleeping callout >> drain seems to be non-trivial. > > There is a crucial difference between "non-sleeping" and "not sleeping > on my lock" that you should be very careful about in this context. > > Which is your requirement ? Calling timeout_drain() must not sleep and not drop the lock in this context (while making any pending timeout go away forever). -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:09:52 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D7916A417; Thu, 3 Jan 2008 00:09:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2B91313C45A; Thu, 3 Jan 2008 00:09:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C0ED417105; Thu, 3 Jan 2008 00:09:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m0309oG0002224; Thu, 3 Jan 2008 00:09:50 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 01:07:21 +0100." <477C2739.5000902@freebsd.org> Date: Thu, 03 Jan 2008 00:09:50 +0000 Message-ID: <2223.1199318990@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:09:52 -0000 In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >Poul-Henning Kamp wrote: >> In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >> >>> I fear we have to go for the latter. Getting a non-sleeping callout >>> drain seems to be non-trivial. >> >> There is a crucial difference between "non-sleeping" and "not sleeping >> on my lock" that you should be very careful about in this context. >> >> Which is your requirement ? > >Calling timeout_drain() must not sleep and not drop the lock in this >context (while making any pending timeout go away forever). Ok, so if the timeouts callback function is running you propose to do what ? spin until it returns ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:09:52 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D7916A417; Thu, 3 Jan 2008 00:09:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2B91313C45A; Thu, 3 Jan 2008 00:09:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C0ED417105; Thu, 3 Jan 2008 00:09:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m0309oG0002224; Thu, 3 Jan 2008 00:09:50 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 01:07:21 +0100." <477C2739.5000902@freebsd.org> Date: Thu, 03 Jan 2008 00:09:50 +0000 Message-ID: <2223.1199318990@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:09:52 -0000 In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >Poul-Henning Kamp wrote: >> In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >> >>> I fear we have to go for the latter. Getting a non-sleeping callout >>> drain seems to be non-trivial. >> >> There is a crucial difference between "non-sleeping" and "not sleeping >> on my lock" that you should be very careful about in this context. >> >> Which is your requirement ? > >Calling timeout_drain() must not sleep and not drop the lock in this >context (while making any pending timeout go away forever). Ok, so if the timeouts callback function is running you propose to do what ? spin until it returns ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:21:33 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BECF916A46C for ; Thu, 3 Jan 2008 00:21:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E82213C46E for ; Thu, 3 Jan 2008 00:21:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81981 invoked from network); 2 Jan 2008 23:46:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 23:46:48 -0000 Message-ID: <477C2A8A.8090604@freebsd.org> Date: Thu, 03 Jan 2008 01:21:30 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2223.1199318990@critter.freebsd.dk> In-Reply-To: <2223.1199318990@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:21:33 -0000 Poul-Henning Kamp wrote: > In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >> Poul-Henning Kamp wrote: >>> In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >>> >>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>> drain seems to be non-trivial. >>> There is a crucial difference between "non-sleeping" and "not sleeping >>> on my lock" that you should be very careful about in this context. >>> >>> Which is your requirement ? >> Calling timeout_drain() must not sleep and not drop the lock in this >> context (while making any pending timeout go away forever). > > Ok, so if the timeouts callback function is running you propose to > do what ? spin until it returns ? As long as the spinning is bounded. Or it may do some magic atomic cmpset to tell the waiting timeout to give up. Which then confirms and timeout_drain then can return in peace. Some (limited?) timeout structure here may be outside of the tcpcb and get Gc'd by the timeout system asynchronously after the drain. I don't have a perfect solution handy. That's why I try to state the requirement and hope the timeout gurus can work out how to do it. ;-) -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:21:34 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E002316A474 for ; Thu, 3 Jan 2008 00:21:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3C913C461 for ; Thu, 3 Jan 2008 00:21:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81981 invoked from network); 2 Jan 2008 23:46:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 23:46:48 -0000 Message-ID: <477C2A8A.8090604@freebsd.org> Date: Thu, 03 Jan 2008 01:21:30 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2223.1199318990@critter.freebsd.dk> In-Reply-To: <2223.1199318990@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:21:35 -0000 Poul-Henning Kamp wrote: > In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >> Poul-Henning Kamp wrote: >>> In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >>> >>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>> drain seems to be non-trivial. >>> There is a crucial difference between "non-sleeping" and "not sleeping >>> on my lock" that you should be very careful about in this context. >>> >>> Which is your requirement ? >> Calling timeout_drain() must not sleep and not drop the lock in this >> context (while making any pending timeout go away forever). > > Ok, so if the timeouts callback function is running you propose to > do what ? spin until it returns ? As long as the spinning is bounded. Or it may do some magic atomic cmpset to tell the waiting timeout to give up. Which then confirms and timeout_drain then can return in peace. Some (limited?) timeout structure here may be outside of the tcpcb and get Gc'd by the timeout system asynchronously after the drain. I don't have a perfect solution handy. That's why I try to state the requirement and hope the timeout gurus can work out how to do it. ;-) -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:26:08 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D04E416A417; Thu, 3 Jan 2008 00:26:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B16E13C4DB; Thu, 3 Jan 2008 00:26:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 038B117105; Thu, 3 Jan 2008 00:26:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m030Q6ju002297; Thu, 3 Jan 2008 00:26:06 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 01:21:30 +0100." <477C2A8A.8090604@freebsd.org> Date: Thu, 03 Jan 2008 00:26:06 +0000 Message-ID: <2296.1199319966@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:26:08 -0000 In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: >>>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>>> drain seems to be non-trivial. >>>> There is a crucial difference between "non-sleeping" and "not sleeping >>>> on my lock" that you should be very careful about in this context. >>>> >>>> Which is your requirement ? >>> Calling timeout_drain() must not sleep and not drop the lock in this >>> context (while making any pending timeout go away forever). >> >> Ok, so if the timeouts callback function is running you propose to >> do what ? spin until it returns ? > >As long as the spinning is bounded [...] I don't have a perfect solution >handy. That's why I try to state the requirement and hope the timeout >gurus can work out how to do it. ;-) It's all Alan Turings fault :-) You can't have that, it's that simple. What I'm proposing is that your thread will sleep on a plain, but unrelated mutex (internal to the timeout code) until the function comes back. Based on your description above, you won't be able to tell the any difference between this and what you wish for. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:26:08 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D04E416A417; Thu, 3 Jan 2008 00:26:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B16E13C4DB; Thu, 3 Jan 2008 00:26:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 038B117105; Thu, 3 Jan 2008 00:26:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m030Q6ju002297; Thu, 3 Jan 2008 00:26:06 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 01:21:30 +0100." <477C2A8A.8090604@freebsd.org> Date: Thu, 03 Jan 2008 00:26:06 +0000 Message-ID: <2296.1199319966@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:26:09 -0000 In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: >>>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>>> drain seems to be non-trivial. >>>> There is a crucial difference between "non-sleeping" and "not sleeping >>>> on my lock" that you should be very careful about in this context. >>>> >>>> Which is your requirement ? >>> Calling timeout_drain() must not sleep and not drop the lock in this >>> context (while making any pending timeout go away forever). >> >> Ok, so if the timeouts callback function is running you propose to >> do what ? spin until it returns ? > >As long as the spinning is bounded [...] I don't have a perfect solution >handy. That's why I try to state the requirement and hope the timeout >gurus can work out how to do it. ;-) It's all Alan Turings fault :-) You can't have that, it's that simple. What I'm proposing is that your thread will sleep on a plain, but unrelated mutex (internal to the timeout code) until the function comes back. Based on your description above, you won't be able to tell the any difference between this and what you wish for. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 02:16:55 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F76F16A417 for ; Thu, 3 Jan 2008 02:16:55 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0226B13C44B for ; Thu, 3 Jan 2008 02:16:54 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so8718951fka.11 for ; Wed, 02 Jan 2008 18:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=F3y/GpUvTG1tVe06q62N4kNbtdzo1X3QX9WcElgOD6c=; b=YzjGiQaY0zC55QmgJyQpatl3M7fbC759WJrSpoUfwhruEyqrrtmR2qMwedE7RsYw9qCx0pYwaK3uwuEnxLphvJrkKXHI3MOSZjUjFmcJ75xPUL6xl+IP3iZqsBGs6VKSy4gZ4kjGLfbdOub9Yq5IEZIY2fduj7Dbp3sQZjwjxaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BUs8ZbADqzDerZp/trKHrhwv9rrhrqTxRtf5AO0NaBNy8cuk4EE0iIpVRzB6HPxPKmLHPg/8uidG09TGu+P2YenBgiaf7rCge42Ts4Rm63iUMh5ajySus2lgOlyzZtbObdWKhxlSkBQTV6/WwvFBUvWrEFdr/YTXZAJ2yf+OPVg= Received: by 10.82.112.3 with SMTP id k3mr26775831buc.15.1199324854807; Wed, 02 Jan 2008 17:47:34 -0800 (PST) Received: by 10.82.116.17 with HTTP; Wed, 2 Jan 2008 17:47:34 -0800 (PST) Message-ID: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> Date: Thu, 3 Jan 2008 09:47:34 +0800 From: "Rong-en Fan" To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Ulrich Spoerlein Subject: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 02:16:55 -0000 Hi folks, Recently, I'm looking into 100150 which reports END key does not working in mutt. With some help from ncurses author, I think this problem is caused by our termcap. To be specific, our termcap defines kH, @7 (the END key), and *6 to \EOF. ncurses has the limitation that it will only return the first matched key back. So, in ncurses based program, it receives kH instead of @7 when you hit END. I just checked NetBSD's termcap, they only defines @7 to \EOF in xterm entry. Also, on a Linux box, infocmp shows that only @7 is defined but not *6 and kH. So, I'm wondering whether we should remove those two keys (kH and @7)? Thanks, Rong-En Fan From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 10:52:06 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5571116A417 for ; Thu, 3 Jan 2008 10:52:06 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9A84213C442 for ; Thu, 3 Jan 2008 10:52:05 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so4321348mue.3 for ; Thu, 03 Jan 2008 02:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=C/6RPbT/VzE53/tVYZawp0rglHZfeG/ieN5ZIsQYo4s=; b=MpkBUzNrT+z0fLazeyv5X6bJ4woLf18eGZQqeH84n/EOUT4DDQ9Ados/GVyoeJEt8l18US/yPvj8EJTBmwGbKjvWcP5jThul7jZy/XLq0V5Q8Wfy3KXwmLDSp9ZV6umJcDJ16Sdl+5zApu4nWFRjTiArcmqM3SdkM5+Y8HvkRTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=bBN7sa4Npew67o9WBeW9dgmIBr86uPp2lPzkms/z98Us3r/1zd7vLa11pqMDnBeUp+/l8zwb0ALhrU96K5l4R84j0NtkqxF+Xz/1mnyFutsYyokJVFySGcWzQ8qMmqrwX9HPe2+z7HUACE/mtZhOTCxTkYK+hqvtplS6aqrDGL8= Received: by 10.78.190.10 with SMTP id n10mr17850619huf.37.1199357512921; Thu, 03 Jan 2008 02:51:52 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id f3sm21288519nfh.15.2008.01.03.02.51.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2008 02:51:52 -0800 (PST) From: Nikolay Pavlov To: freebsd-security@freebsd.org Date: Thu, 3 Jan 2008 12:51:49 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <477277FF.30504@googlemail.com> <20071228200428.J6052@odysseus.silby.com> <477BFF43.6060003@googlemail.com> In-Reply-To: <477BFF43.6060003@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801031251.49378.qpadla@gmail.com> Cc: arch@freebsd.org Subject: Re: ProPolice/SSP in 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 10:52:06 -0000 On Wednesday 02 January 2008 23:16:51 Gunther Mayer wrote: > Thanks everyone for answering my questions so far. > > Mike Silbersack wrote: > > It's too late to make that sort of change for FreeBSD 7.0, but I think > > that's a good goal for FreeBSD 8.0. > > > > Here's what I think you could do: > > > > 1. Verify that enabling SSP works properly. > > Ok, I will certainly do that once 7.0 is out and I can run it for a > while on our testing box. > > > 2. Convince Kris Kennaway to run his mysql benchmarks on a FreeBSD 8 > > system both with and without SSP to verify that there is no > > significant slowdown. > > Hmm, I guess Kris is not subscribed to -security? Maybe I'll have to > post in -questions then... But you can cc him directly. > > > 3. Get it enabled on FreeBSD 8 by default. > > 4. Request that the change be made to FreeBSD 7.1 or 7.2 after it has > > proven to not cause problems on FreeBSD 8. > > Ok, but what's the best way to go about that? Don't see that being > documented in the handbook. Do you suggest a post on -questions or a > send-pr or both? Since this change is related to whole the system the arch would be a better place. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 15:30:37 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB23516A421; Thu, 3 Jan 2008 15:30:37 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1894913C4EB; Thu, 3 Jan 2008 15:30:36 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 8583610459F; Thu, 3 Jan 2008 21:12:20 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxvKPxzaM4J5; Thu, 3 Jan 2008 21:12:17 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 507381044D0; Thu, 3 Jan 2008 21:12:17 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 21:12:17 +0600 Received: from nuclight.avtf.net ([78.140.2.250]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 21:12:17 +0600 Date: Thu, 03 Jan 2008 21:12:12 +0600 To: "Julian Elischer" , "Ivo Vachkov" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <477416CC.4090906@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Jan 2008 15:12:17.0135 (UTC) FILETIME=[072A37F0:01C84E1B] Cc: arch@freebsd.org, FreeBSD Net , Robert Watson , Qing Li Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 15:30:37 -0000 28.12.07 @ 03:19 Julian Elischer wrote: > By the way, I might add that in the 6.x compat. version I may end up > limiting the feature to 8 tables. This is because I need to store some > stuff in an efficient way in the mbuf, and in a compatible manner this > is easiest done by stealing the top 4 bits in the mbuf dlags word > and defining them as: > > #define M_HAVEFIB 0x10000000 > #define M_FIBMASK 0x07 > #define M_FIBNUM 0xe0000000 > #define M_FIBSHIFT 29 > #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? > ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) > #M_SETFIB(_m, _fib) do { \ > _m->m_flags &= ~M_FIBNUM; \ > _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ > } while (0) > > This then becomes very easy to change to use a tag or > whatever is needed in later versions , and the number can > be expanded past 8 predefined FIBs at that time.. If you want it to be a tag, why spent bits in m_flags and not just do it as a tag at once? Or it is supposed to completely throw away 6.x (possibly 7.x too) implementation in favor of right thing in 8.0 ? >>> This brings us as to how the correct FIB is selected for an outgoing >>> IPV4 packet. >>> >>> Packets fall into one of a number of classes. >>> 1/ locally generated packets, coming from a socket/PCB. >>> Such packets select a FIB from a number associated with the >>> socket/PCB. This in turn is inherited from the process, >>> but can be changed by a socket option. The process in turn >>> inherits it on fork. I have written a utility call setfib >>> that acts a bit like nice.. >>> >>> setfib -n 3 ping target.example.com # will use fib 3 for ping. Pretty cool! >>> 2/ packets received on an interface for forwarding. >>> By default these packets would use table 0, >>> (or possibly a number settable in a sysctl(not yet)). >>> but prior to routing the firewall can inspect them (see below). >>> >>> 3/ packets inspected by a packet classifier, which can arbitrarily >>> associate a fib with it on a packet by packet basis. >>> A fib assigned to a packet by a packet classifier >>> (such as ipfw) would over-ride a fib associated by >>> a more default source. (such as cases 1 or 2). Sounds good. I like idea to do routing decisions in firewall, to not double kernel code and userspace utilities, like in Linux' iproute2 (which, however, still have a few parameters and relies on firewall marks for others). However, there are some cases, I think, where it could be done outisde firewall. For example, make an ifconfig option to use a specific FIB as a default for all packets outgoing from this interface's address. But here arises another related question - Linux allows to select a specific src IP based on a routing table entry - destination address (thoughts about pf reply-to/route-ro, huh). In relation to this I can remember multipath routing (different metrics?), addresses from one subnet on different ifaces (mask wider /32) and so on. Also it is interesting, how multiple FIBs would interact with host-wide events, such as ICMP redirects (which table should be updated?), storing of TCP stack metrics (MTU, etc.) and hostcache, and so on. How these and above will be solved?.. per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, multipath/metrics, tcp stack parameters interaction, iproute2 >>> Routing messages would be associated with their >>> process, and thus select one FIB or another. This is not clear. How should the 'route' command work with different FIBs, if they are supposed by admin to be used for forwarding, and not the straight per-process? I think a setfib option is more consistent than running route under setfib command. Also, routing sockets and routing daemons - should they work with only one table?.. >>> I have not yet added the changes to ipfw. Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? There were thoughts (I heard,t as a hack before multiple FIBs) about making an additional, say, 'nexthop' ipfw action, which acts like fwd, but does not accept packet, allowing to continue it through firewall ruleset - thus making it more comfortable to separate routing (imagine 'nexthop tablearg') and filtering. There are questions with both fwd and new supposed option: will fwd still survive? Will it change the output interface, like as complete rerouting before calling pfil(9) hooks, so that *oif will be changed to be mathed iin rules below? pf route-to/reply-to is hanging around... >>> pf has some similar changes already but they seem to rely on >>> the various FIBs having symbolic names. Which I do not plan to support >>> in the first version of these changes. I think this is what pf team should care about, not we, as it lives in ../contrib. Though they can use something like sysctl with symbolic-name-to-system-FIB-number translator or such. >>> Interaction with the ARP layer/ LL layer would need to be >>> revisited as well. Qing Li has been working on this already. Oh yes, L2 interaction is interesting. How it should work in case of planned separation of routing and ARP tables?.. -- WBR, Vadim Goncharov From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 15:48:38 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6DC616A597 for ; Thu, 3 Jan 2008 15:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 6B98813C448 for ; Thu, 3 Jan 2008 15:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4131958fgg.35 for ; Thu, 03 Jan 2008 07:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=gaebBOGftdSZwl0ZjfQcB1g8LUk5X9es14amhi7fnV8=; b=caH611FuaGOnQ8+0CmXFP/DnZRYuV5fowjTd7knlwoZkq4GJDl32ACRc1KiUn9YVHr71ctV/1jrsE7TM75d+K5nZKaNcR1pEHfarYRzkujYATw6am2wijF1mJPM2K3K/bdWxjUxxCZSRV/ytJ0FnOCGMDPb8FUdajn4zFagl+Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N9oWBzKZuU/THEzvJUeCDqBUogC6OILD2rOxyGWV2eOitEiFmMYtCi08C2VN25U3QKuGUvzxvJJGPbFfbktlOWcu3DU3B0uVA9oo5/ZVcFplyzgaOkV/lZGaSmgRPqe9p7837sMmYO6SU6kSUagyOCPuLNshJmWMLCJdUmSl1RA= Received: by 10.86.95.20 with SMTP id s20mr15727182fgb.46.1199375317170; Thu, 03 Jan 2008 07:48:37 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 3 Jan 2008 07:48:37 -0800 (PST) Message-ID: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> Date: Thu, 3 Jan 2008 16:48:37 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <2296.1199319966@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477C2A8A.8090604@freebsd.org> <2296.1199319966@critter.freebsd.dk> X-Google-Sender-Auth: fe728188f4acfb7d Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 15:48:39 -0000 2008/1/3, Poul-Henning Kamp : > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > > >>>>> I fear we have to go for the latter. Getting a non-sleeping callout > >>>>> drain seems to be non-trivial. > >>>> There is a crucial difference between "non-sleeping" and "not sleeping > >>>> on my lock" that you should be very careful about in this context. > >>>> > >>>> Which is your requirement ? > >>> Calling timeout_drain() must not sleep and not drop the lock in this > >>> context (while making any pending timeout go away forever). > >> > >> Ok, so if the timeouts callback function is running you propose to > >> do what ? spin until it returns ? > > > >As long as the spinning is bounded [...] I don't have a perfect solution > >handy. That's why I try to state the requirement and hope the timeout > >gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but > unrelated mutex (internal to the timeout code) until the function > comes back. > > Based on your description above, you won't be able to tell the > any difference between this and what you wish for. This will be hardly feasible. Internal callout subsystem locks probabilly need to be spinlocks in order to avoid lock mismatches against sleepable locks. callout_drain() so far works good just because it assumes no locks held while sleeping. A solution for this is not trivial and needs to be better through. If someone can propose a real and working prototype the discussion would be more productive as, really, current callout code has a lot of little constraints not trivial if not analyzed in practice. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 15:48:39 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABF616A5AB for ; Thu, 3 Jan 2008 15:48:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 99DA413C4CE for ; Thu, 3 Jan 2008 15:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4131959fgg.35 for ; Thu, 03 Jan 2008 07:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=gaebBOGftdSZwl0ZjfQcB1g8LUk5X9es14amhi7fnV8=; b=caH611FuaGOnQ8+0CmXFP/DnZRYuV5fowjTd7knlwoZkq4GJDl32ACRc1KiUn9YVHr71ctV/1jrsE7TM75d+K5nZKaNcR1pEHfarYRzkujYATw6am2wijF1mJPM2K3K/bdWxjUxxCZSRV/ytJ0FnOCGMDPb8FUdajn4zFagl+Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N9oWBzKZuU/THEzvJUeCDqBUogC6OILD2rOxyGWV2eOitEiFmMYtCi08C2VN25U3QKuGUvzxvJJGPbFfbktlOWcu3DU3B0uVA9oo5/ZVcFplyzgaOkV/lZGaSmgRPqe9p7837sMmYO6SU6kSUagyOCPuLNshJmWMLCJdUmSl1RA= Received: by 10.86.95.20 with SMTP id s20mr15727182fgb.46.1199375317170; Thu, 03 Jan 2008 07:48:37 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 3 Jan 2008 07:48:37 -0800 (PST) Message-ID: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> Date: Thu, 3 Jan 2008 16:48:37 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <2296.1199319966@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477C2A8A.8090604@freebsd.org> <2296.1199319966@critter.freebsd.dk> X-Google-Sender-Auth: fe728188f4acfb7d Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 15:48:39 -0000 2008/1/3, Poul-Henning Kamp : > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > > >>>>> I fear we have to go for the latter. Getting a non-sleeping callout > >>>>> drain seems to be non-trivial. > >>>> There is a crucial difference between "non-sleeping" and "not sleeping > >>>> on my lock" that you should be very careful about in this context. > >>>> > >>>> Which is your requirement ? > >>> Calling timeout_drain() must not sleep and not drop the lock in this > >>> context (while making any pending timeout go away forever). > >> > >> Ok, so if the timeouts callback function is running you propose to > >> do what ? spin until it returns ? > > > >As long as the spinning is bounded [...] I don't have a perfect solution > >handy. That's why I try to state the requirement and hope the timeout > >gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but > unrelated mutex (internal to the timeout code) until the function > comes back. > > Based on your description above, you won't be able to tell the > any difference between this and what you wish for. This will be hardly feasible. Internal callout subsystem locks probabilly need to be spinlocks in order to avoid lock mismatches against sleepable locks. callout_drain() so far works good just because it assumes no locks held while sleeping. A solution for this is not trivial and needs to be better through. If someone can propose a real and working prototype the discussion would be more productive as, really, current callout code has a lot of little constraints not trivial if not analyzed in practice. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 16:28:32 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C59F16A417; Thu, 3 Jan 2008 16:28:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 02CB113C45A; Thu, 3 Jan 2008 16:28:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227143444-1834499 for multiple; Thu, 03 Jan 2008 11:26:36 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m03GSLgu028899; Thu, 3 Jan 2008 11:28:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 3 Jan 2008 11:05:50 -0500 User-Agent: KMail/1.9.6 References: <18378.1196596684@critter.freebsd.dk> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> In-Reply-To: <477C1604.2030905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801031105.52354.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 03 Jan 2008 11:28:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5348/Thu Jan 3 00:26:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , arch@freebsd.org, Poul-Henning Kamp , Andre Oppermann , Robert Watson Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 16:28:32 -0000 On Wednesday 02 January 2008 05:53:56 pm Andre Oppermann wrote: > John Baldwin wrote: > > On Sunday 02 December 2007 07:53:18 am Andre Oppermann wrote: > >> Poul-Henning Kamp wrote: > >>> In message <4752998A.9030007@freebsd.org>, Andre Oppermann writes: > >>>> o TCP puts the timer into an allocated structure and upon close of the > >>>> session it has to be deallocated including stopping of all currently > >>>> running timers. > >>>> [...] > >>>> -> The timer facility should provide an atomic stop/remove call > >>>> that prevent any further callbacks upon return. It should not > >>>> do a 'drain' where the callback may be run anyway. > >>>> Note: We hold the lock the callback would have to obtain. > >>> It is my intent, that the implementation behind the new API will > >>> only ever grab the specified lock when it calls the timeout function. > >> This is the same for the current one and pretty much a given. > >> > >>> When you do a timeout_disable() or timeout_cleanup() you will be > >>> sleeping on a mutex internal to the implementation, if the timeout > >>> is currently executing. > >> This is the problematic part. We can't sleep in TCP when cleaning up > >> the timer. We're not always called from userland but from interrupt > >> context. And when calling the cleanup we currently hold the lock the > >> callout wants to obtain. We can't drop it either as the race would > >> be back again. What you describe here is the equivalent of callout_ > >> drain(). This is unfortunately unworkable in TCP's context. The > >> callout has to go away even if it is already pending and waiting on > >> the lock. Maybe that can only be solved by a flag in the lock saying > >> "give up and go away". > > > > The reason you need to do a drain is to allow for safe destroying of the lock. > > Specifically, drivers tend to do this: > > > > FOO_LOCK(sc); > > ... > > callout_stop(...); > > FOO_UNLOCK(sc); > > ... > > callout_drain(...); > > ... > > mtx_destroy(&sc->foo_mtx); > > > > If you don't have the drain and softclock is trying to acquire the backing > > mutex while you have it held (before the callout_stop) then Bad Things can > > happen if you don't do the drain. Having the lock just "give up" doesn't > > work either because if the memory containing the lock is free'd and > > reinitialized such that it looks enough like a valid lock then softclock (or > > its equivalent) will still try to obtain it. Also, you need to do a drain so > > it is safe to free the callout structure to prevent it from being recycled > > and having weird races where it gets recycled and rescheduled but the timer > > code thinks it has a pending stop for that pointer and so it aborts the wrong > > instance of the timer, etc. > > This is all well known. ;) What isn't known is that this (the > sleep part) is a major problem for TCP due to being run from > interrupt context. Hence the request for some kind of busy-drain > or other method prevent the sleep. A second less severe problem > are races while the lock is dropped during the sleep. Here some > other part of TCP may go into the tcpcb scheduled for destruction. My point is that there isn't really a good way to fix this that doesn't involve sleeping. If you just spin you may spin forever (netisr has a higher priority than softclock IIRC). One option is to not destroy pcb's directly in interrupt context but instead to queue them and let a task on a taskqueue finish the destruction in a context where it can sleep if necessary. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 16:28:32 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C59F16A417; Thu, 3 Jan 2008 16:28:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 02CB113C45A; Thu, 3 Jan 2008 16:28:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227143444-1834499 for multiple; Thu, 03 Jan 2008 11:26:36 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m03GSLgu028899; Thu, 3 Jan 2008 11:28:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 3 Jan 2008 11:05:50 -0500 User-Agent: KMail/1.9.6 References: <18378.1196596684@critter.freebsd.dk> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> In-Reply-To: <477C1604.2030905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801031105.52354.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 03 Jan 2008 11:28:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5348/Thu Jan 3 00:26:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , arch@freebsd.org, Poul-Henning Kamp , Andre Oppermann , Robert Watson Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 16:28:32 -0000 On Wednesday 02 January 2008 05:53:56 pm Andre Oppermann wrote: > John Baldwin wrote: > > On Sunday 02 December 2007 07:53:18 am Andre Oppermann wrote: > >> Poul-Henning Kamp wrote: > >>> In message <4752998A.9030007@freebsd.org>, Andre Oppermann writes: > >>>> o TCP puts the timer into an allocated structure and upon close of the > >>>> session it has to be deallocated including stopping of all currently > >>>> running timers. > >>>> [...] > >>>> -> The timer facility should provide an atomic stop/remove call > >>>> that prevent any further callbacks upon return. It should not > >>>> do a 'drain' where the callback may be run anyway. > >>>> Note: We hold the lock the callback would have to obtain. > >>> It is my intent, that the implementation behind the new API will > >>> only ever grab the specified lock when it calls the timeout function. > >> This is the same for the current one and pretty much a given. > >> > >>> When you do a timeout_disable() or timeout_cleanup() you will be > >>> sleeping on a mutex internal to the implementation, if the timeout > >>> is currently executing. > >> This is the problematic part. We can't sleep in TCP when cleaning up > >> the timer. We're not always called from userland but from interrupt > >> context. And when calling the cleanup we currently hold the lock the > >> callout wants to obtain. We can't drop it either as the race would > >> be back again. What you describe here is the equivalent of callout_ > >> drain(). This is unfortunately unworkable in TCP's context. The > >> callout has to go away even if it is already pending and waiting on > >> the lock. Maybe that can only be solved by a flag in the lock saying > >> "give up and go away". > > > > The reason you need to do a drain is to allow for safe destroying of the lock. > > Specifically, drivers tend to do this: > > > > FOO_LOCK(sc); > > ... > > callout_stop(...); > > FOO_UNLOCK(sc); > > ... > > callout_drain(...); > > ... > > mtx_destroy(&sc->foo_mtx); > > > > If you don't have the drain and softclock is trying to acquire the backing > > mutex while you have it held (before the callout_stop) then Bad Things can > > happen if you don't do the drain. Having the lock just "give up" doesn't > > work either because if the memory containing the lock is free'd and > > reinitialized such that it looks enough like a valid lock then softclock (or > > its equivalent) will still try to obtain it. Also, you need to do a drain so > > it is safe to free the callout structure to prevent it from being recycled > > and having weird races where it gets recycled and rescheduled but the timer > > code thinks it has a pending stop for that pointer and so it aborts the wrong > > instance of the timer, etc. > > This is all well known. ;) What isn't known is that this (the > sleep part) is a major problem for TCP due to being run from > interrupt context. Hence the request for some kind of busy-drain > or other method prevent the sleep. A second less severe problem > are races while the lock is dropped during the sleep. Here some > other part of TCP may go into the tcpcb scheduled for destruction. My point is that there isn't really a good way to fix this that doesn't involve sleeping. If you just spin you may spin forever (netisr has a higher priority than softclock IIRC). One option is to not destroy pcb's directly in interrupt context but instead to queue them and let a task on a taskqueue finish the destruction in a context where it can sleep if necessary. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 18:52:23 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3DBC16A420 for ; Thu, 3 Jan 2008 18:52:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id CDBD213C447 for ; Thu, 3 Jan 2008 18:52:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 10:52:21 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B0748126DE4; Thu, 3 Jan 2008 10:52:20 -0800 (PST) Message-ID: <477D2EF3.2060909@elischer.org> Date: Thu, 03 Jan 2008 10:52:35 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , Qing Li , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 18:52:23 -0000 Vadim Goncharov wrote: > 28.12.07 @ 03:19 Julian Elischer wrote: > >> By the way, I might add that in the 6.x compat. version I may end up >> limiting the feature to 8 tables. This is because I need to store some >> stuff in an efficient way in the mbuf, and in a compatible manner this >> is easiest done by stealing the top 4 bits in the mbuf dlags word >> and defining them as: >> >> #define M_HAVEFIB 0x10000000 >> #define M_FIBMASK 0x07 >> #define M_FIBNUM 0xe0000000 >> #define M_FIBSHIFT 29 >> #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? >> ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) >> #M_SETFIB(_m, _fib) do { \ >> _m->m_flags &= ~M_FIBNUM; \ >> _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ >> } while (0) >> >> This then becomes very easy to change to use a tag or >> whatever is needed in later versions , and the number can >> be expanded past 8 predefined FIBs at that time.. > > If you want it to be a tag, why spent bits in m_flags and not just do it > as a tag at once? Or it is supposed to completely throw away 6.x > (possibly 7.x too) implementation in favor of right thing in 8.0 ? basically yes.. I'm looking at just doing tags to start with, but haven't done it yet.. I'm looking for a good bit of tag code to copy :-) > >>>> This brings us as to how the correct FIB is selected for an outgoing >>>> IPV4 packet. >>>> >>>> Packets fall into one of a number of classes. >>>> 1/ locally generated packets, coming from a socket/PCB. >>>> Such packets select a FIB from a number associated with the >>>> socket/PCB. This in turn is inherited from the process, >>>> but can be changed by a socket option. The process in turn >>>> inherits it on fork. I have written a utility call setfib >>>> that acts a bit like nice.. >>>> >>>> setfib -n 3 ping target.example.com # will use fib 3 for ping. > > Pretty cool! or, (and I've done this) setfib 3 /bin/sh now by default everythign you do uses table 3. or even setfib 3 jail {blah} and all the procs in the jail use table 3. You also need to do setfib 3 jexec xxx for extra processes you add to the jail afterwards. > >>>> 2/ packets received on an interface for forwarding. >>>> By default these packets would use table 0, >>>> (or possibly a number settable in a sysctl(not yet)). >>>> but prior to routing the firewall can inspect them (see below). >>>> >>>> 3/ packets inspected by a packet classifier, which can arbitrarily >>>> associate a fib with it on a packet by packet basis. >>>> A fib assigned to a packet by a packet classifier >>>> (such as ipfw) would over-ride a fib associated by >>>> a more default source. (such as cases 1 or 2). > > Sounds good. I like idea to do routing decisions in firewall, to not > double kernel code and userspace utilities, like in Linux' iproute2 > (which, however, still have a few parameters and relies on firewall > marks for others). However, there are some cases, I think, where it > could be done outisde firewall. For example, make an ifconfig option to > use a specific FIB as a default for all packets outgoing from this > interface's address. But here arises another related question - Linux > allows to select a specific src IP based on a routing table entry - > destination address (thoughts about pf reply-to/route-ro, huh). that is default here too if I understand what you are talking about. teh src address is selected from the routing table's exit interface. In the code I'm showing in perforce, that address would depend on which table your process was associated with. (or just the socket if you have used the socket option on it before doing the bind/connect) > In > relation to this I can remember multipath routing (different metrics?), > addresses from one subnet on different ifaces (mask wider /32) and so on. > Also it is interesting, how multiple FIBs would interact with host-wide > events, such as ICMP redirects (which table should be updated?), storing > of TCP stack metrics (MTU, etc.) and hostcache, and so on. How these and > above will be solved?.. > I'm not really too knowledgeable about multicast.. > per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, > multipath/metrics, tcp stack parameters interaction, iproute2 I'm not trying to solve problems that need vimage to solve them.. > >>>> Routing messages would be associated with their >>>> process, and thus select one FIB or another. > > This is not clear. How should the 'route' command work with different > FIBs, if they are supposed by admin to be used for forwarding, and not > the straight per-process? I think a setfib option is more consistent > than running route under setfib command. Also, routing sockets and > routing daemons - should they work with only one table?.. if you do setfib 3 route get 1.1.1.1 you may get a different result from setfib 2 route get 1.1.1.1 I will add a fibnum argument to route itself as well but it's not needed immediately as long as I have the setfib command. > >>>> I have not yet added the changes to ipfw. > > Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? > There were thoughts (I heard,t as a hack before multiple FIBs) about > making an additional, say, 'nexthop' ipfw action, which acts like fwd, > but does not accept packet, allowing to continue it through firewall > ruleset - thus making it more comfortable to separate routing (imagine > 'nexthop tablearg') and filtering. There are questions with both fwd and > new supposed option: will fwd still survive? Will it change the output > interface, like as complete rerouting before calling pfil(9) hooks, so > that *oif will be changed to be mathed iin rules below? pf > route-to/reply-to is hanging around... The 'nexthop' cal you suggest is problematic because it needs to return information immediately. which is why it is terminal. As for the setfib ipfw action, I have now done this in p4. ipfw add 200 setfib 3 ip from any to any in receive em0 now works. This lessens the need for associating a fib with an interface as the firewall can do that too.. the setfib rule is not terminal. (hmm need to check I did that right.) you can also do ipfw add 200 skipto 300 ip from any to any hasfib # to select on a packet that has a fib associated with it already. ipfw add 200 skipto 300 ip from any to any fib 4 # to slelect packets that are associated with fib 4 ipfw add 200 clrfib ip from any to any # to remove a fib association from the packet. > >>>> pf has some similar changes already but they seem to rely on >>>> the various FIBs having symbolic names. Which I do not plan to support >>>> in the first version of these changes. > > I think this is what pf team should care about, not we, as it lives in > ../contrib. Though they can use something like sysctl with > symbolic-name-to-system-FIB-number translator or such. > >>>> Interaction with the ARP layer/ LL layer would need to be >>>> revisited as well. Qing Li has been working on this already. > > Oh yes, L2 interaction is interesting. How it should work in case of > planned separation of routing and ARP tables?.. > From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 01:19:23 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCF816A417; Fri, 4 Jan 2008 01:19:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2641213C465; Fri, 4 Jan 2008 01:19:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E320B47954; Thu, 3 Jan 2008 20:19:21 -0500 (EST) Date: Fri, 4 Jan 2008 01:19:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <2296.1199319966@critter.freebsd.dk> Message-ID: <20080104011149.M42109@fledge.watson.org> References: <2296.1199319966@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@freebsd.org, Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:19:23 -0000 > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > >>>>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>>>> drain seems to be non-trivial. >>>>> There is a crucial difference between "non-sleeping" and "not sleeping >>>>> on my lock" that you should be very careful about in this context. >>>>> >>>>> Which is your requirement ? >>>> Calling timeout_drain() must not sleep and not drop the lock in this >>>> context (while making any pending timeout go away forever). >>> >>> Ok, so if the timeouts callback function is running you propose to do what >>> ? spin until it returns ? >> >> As long as the spinning is bounded [...] I don't have a perfect solution >> handy. That's why I try to state the requirement and hope the timeout >> gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but unrelated > mutex (internal to the timeout code) until the function comes back. > > Based on your description above, you won't be able to tell the any > difference between this and what you wish for. In a world of bounded mutex-length sleeps and unbounded I/O-length sleeps, waiting a mutex-length sleep for callout_stop() to cancel and drain the callout is fine. However, callout_stop() needs to be done while holding locks that the callout may acquire (global tcbinfo and local inpcb locks), which in the current world order would lead rapidly to deadlock. In the model you have in mind, is it OK to hold locks that the callout being canceled using the call to callout_stop() might acquire? The following pseudo-code snippets captures what I'm probably putting into words poorly: TCP input path: mtx_lock(&tcbinfo); ... mtx_lock(inp->inp_mtx); ... /* * NB: We can't drop the locks here or there will be races, and we * also can't msleep() or related sorts of things as we're running in * an ithread. */ callout_stop(inp->inp_callout); mtx_destroy(inp->inp_mtx); free(inp); TCP timer path: mtx_lock(&tcbinfo); ... mtx_lock(inp->inp_mtx); ... mtx_unlock(inp->inp_mtx); ... mtx_unlock(&tcbinfo); Right now, we callout_stop() but not callout_drain() in the input path on the basis that we can't msleep(), and for better and mostly worse, we accept the resulting race. We'd like to eliminate that race. One way to do that is to hand the inpcb off to another kthread that *can* msleep() doing a callout_drain(), and have it GC the data structure when done. That's sort of ugly, and means that we're freeing the memory asynchronously which is somewhat undesirable. If it were possible to have the above callout_stop() also guarantee that once it returns, the timer is not currently running and will never run again, then we wouldn't need that. We may also have cases where we want to free the inpcb from within the timer... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 01:19:23 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCF816A417; Fri, 4 Jan 2008 01:19:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2641213C465; Fri, 4 Jan 2008 01:19:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E320B47954; Thu, 3 Jan 2008 20:19:21 -0500 (EST) Date: Fri, 4 Jan 2008 01:19:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <2296.1199319966@critter.freebsd.dk> Message-ID: <20080104011149.M42109@fledge.watson.org> References: <2296.1199319966@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@freebsd.org, Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:19:23 -0000 > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > >>>>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>>>> drain seems to be non-trivial. >>>>> There is a crucial difference between "non-sleeping" and "not sleeping >>>>> on my lock" that you should be very careful about in this context. >>>>> >>>>> Which is your requirement ? >>>> Calling timeout_drain() must not sleep and not drop the lock in this >>>> context (while making any pending timeout go away forever). >>> >>> Ok, so if the timeouts callback function is running you propose to do what >>> ? spin until it returns ? >> >> As long as the spinning is bounded [...] I don't have a perfect solution >> handy. That's why I try to state the requirement and hope the timeout >> gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but unrelated > mutex (internal to the timeout code) until the function comes back. > > Based on your description above, you won't be able to tell the any > difference between this and what you wish for. In a world of bounded mutex-length sleeps and unbounded I/O-length sleeps, waiting a mutex-length sleep for callout_stop() to cancel and drain the callout is fine. However, callout_stop() needs to be done while holding locks that the callout may acquire (global tcbinfo and local inpcb locks), which in the current world order would lead rapidly to deadlock. In the model you have in mind, is it OK to hold locks that the callout being canceled using the call to callout_stop() might acquire? The following pseudo-code snippets captures what I'm probably putting into words poorly: TCP input path: mtx_lock(&tcbinfo); ... mtx_lock(inp->inp_mtx); ... /* * NB: We can't drop the locks here or there will be races, and we * also can't msleep() or related sorts of things as we're running in * an ithread. */ callout_stop(inp->inp_callout); mtx_destroy(inp->inp_mtx); free(inp); TCP timer path: mtx_lock(&tcbinfo); ... mtx_lock(inp->inp_mtx); ... mtx_unlock(inp->inp_mtx); ... mtx_unlock(&tcbinfo); Right now, we callout_stop() but not callout_drain() in the input path on the basis that we can't msleep(), and for better and mostly worse, we accept the resulting race. We'd like to eliminate that race. One way to do that is to hand the inpcb off to another kthread that *can* msleep() doing a callout_drain(), and have it GC the data structure when done. That's sort of ugly, and means that we're freeing the memory asynchronously which is somewhat undesirable. If it were possible to have the above callout_stop() also guarantee that once it returns, the timer is not currently running and will never run again, then we wouldn't need that. We may also have cases where we want to free the inpcb from within the timer... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 01:59:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B0216A418 for ; Fri, 4 Jan 2008 01:59:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id E590E13C447 for ; Fri, 4 Jan 2008 01:59:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 17:59:43 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 64276126E01 for ; Thu, 3 Jan 2008 17:59:43 -0800 (PST) Message-ID: <477D931D.4000303@elischer.org> Date: Thu, 03 Jan 2008 17:59:57 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:59:45 -0000 I would like to extend the current SYSCTL_INT() with SYSCTL_INT_CLAMPED() or similar, where you also supply a maximum acceptable value. (and maybe a clue as to what to say if it is a bad value). so many users of SYSCTL_INT don't check for bad values because it's so much harder (you need to supply your own handler), and so many simple handlers exist fo rthe people that DO check that it seems to me that we should provide a pre-canned way to do this.... we are limited to using the existing structure, but as we have no existing callers we can redefine one element.... I would suggest: I'd like to test for a minimum too but I think I can only squeeze one field out of the existing struct sysctl_oid. SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) ^^^^ anyone think it's a bad idea? After all the macros are evaluated, (etc.) it would call: ( off the top of my head ) int sysctl_handle_int_max(SYSCTL_HANDLER_ARGS) { int error = 0; error = SYSCTL_OUT(req, arg1, sizeof(int)); if (error || !req->newptr) return (error); if (*(int *)arg1 > (int)arg2) error = EDOOFUS; else error = SYSCTL_IN(req, arg1, sizeof(int)); return (error); } From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:21:33 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B4CB16A421 for ; Fri, 4 Jan 2008 02:21:33 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 56DD713C4D9 for ; Fri, 4 Jan 2008 02:21:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 323691A4D82; Thu, 3 Jan 2008 18:19:05 -0800 (PST) Date: Thu, 3 Jan 2008 18:19:05 -0800 From: Alfred Perlstein To: Julian Elischer Message-ID: <20080104021905.GE76698@elvis.mu.org> References: <477D931D.4000303@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477D931D.4000303@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:21:33 -0000 Yes, but EINVAL please. Another idea would be a simplified SYSCTL_INT_PROC that allowed one to define a function like so: int sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min) { } If this function returned '0' then 'newval' would be accepted. Otherwise the function should return an error, most likely EINVAL. The point being that a lot of these maximums may take a calculation and we should make it as easy as possible to do this calculation and provide the function for doing so. One would also set the min/max values so that one could query the acceptable bounds of a tunable, or even the bounds of of the tuneable. (Note: if *newval == NULL, we're just querying max/min, not doing a set operation.) (Note 2: "handle" is so you can have a common handler and possibly switch() off of handle for multiple sysctl ints to reduce the number of functions required.) -Alfred * Julian Elischer [080103 17:57] wrote: > I would like to extend the current SYSCTL_INT() with > SYSCTL_INT_CLAMPED() or similar, where you also supply a > maximum acceptable value. (and maybe a clue as to what to say if it is > a bad value). > > so many users of SYSCTL_INT don't check for bad values because it's so > much harder (you need to supply your own handler), and so many > simple handlers exist fo rthe people that DO check that it seems to > me that we should provide a pre-canned way to do this.... > > we are limited to using the existing structure, > but as we have no existing callers we can redefine > one element.... > > I would suggest: > > I'd like to test for a minimum too but I think I can only squeeze one > field out of the existing struct sysctl_oid. > > SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) > ^^^^ > > anyone think it's a bad idea? > After all the macros are evaluated, (etc.) it would call: > ( off the top of my head ) > > int > sysctl_handle_int_max(SYSCTL_HANDLER_ARGS) > { > int error = 0; > > error = SYSCTL_OUT(req, arg1, sizeof(int)); > > if (error || !req->newptr) > return (error); > > if (*(int *)arg1 > (int)arg2) > error = EDOOFUS; > else > error = SYSCTL_IN(req, arg1, sizeof(int)); > return (error); > } > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:26:03 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA2F16A46D for ; Fri, 4 Jan 2008 02:26:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7331413C457 for ; Fri, 4 Jan 2008 02:26:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 18:26:02 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D1AFA126E0F; Thu, 3 Jan 2008 18:26:01 -0800 (PST) Message-ID: <477D9948.3050508@elischer.org> Date: Thu, 03 Jan 2008 18:26:16 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> In-Reply-To: <20080104021905.GE76698@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:26:03 -0000 Alfred Perlstein wrote: > Yes, but EINVAL please. > > Another idea would be a simplified SYSCTL_INT_PROC > that allowed one to define a function like so: > > int > sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min) > { > > > } > > If this function returned '0' then 'newval' would be accepted. > Otherwise the function should return an error, most likely EINVAL. > > The point being that a lot of these maximums may take a calculation > and we should make it as easy as possible to do this calculation > and provide the function for doing so. yes I was thinking about that.. something that allowed one to supply a simple comparison snippet. the limit is in the fields that are stored in the sysctl_oid structure. > > One would also set the min/max values so that one could query > the acceptable bounds of a tunable, or even the bounds of of > the tuneable. > > (Note: if *newval == NULL, we're just querying max/min, not > doing a set operation.) > > (Note 2: "handle" is so you can have a common handler and > possibly switch() off of handle for multiple sysctl ints to > reduce the number of functions required.) > > -Alfred > > * Julian Elischer [080103 17:57] wrote: >> I would like to extend the current SYSCTL_INT() with >> SYSCTL_INT_CLAMPED() or similar, where you also supply a >> maximum acceptable value. (and maybe a clue as to what to say if it is >> a bad value). >> >> so many users of SYSCTL_INT don't check for bad values because it's so >> much harder (you need to supply your own handler), and so many >> simple handlers exist fo rthe people that DO check that it seems to >> me that we should provide a pre-canned way to do this.... >> >> we are limited to using the existing structure, >> but as we have no existing callers we can redefine >> one element.... >> >> I would suggest: >> >> I'd like to test for a minimum too but I think I can only squeeze one >> field out of the existing struct sysctl_oid. >> >> SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) >> ^^^^ >> >> anyone think it's a bad idea? >> After all the macros are evaluated, (etc.) it would call: >> ( off the top of my head ) >> >> int >> sysctl_handle_int_max(SYSCTL_HANDLER_ARGS) >> { >> int error = 0; >> >> error = SYSCTL_OUT(req, arg1, sizeof(int)); >> >> if (error || !req->newptr) >> return (error); >> >> if (*(int *)arg1 > (int)arg2) >> error = EDOOFUS; >> else >> error = SYSCTL_IN(req, arg1, sizeof(int)); >> return (error); >> } >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:27:28 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED4FD16A417 for ; Fri, 4 Jan 2008 02:27:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id D132C13C44B for ; Fri, 4 Jan 2008 02:27:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 18:27:28 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 93301126E0E; Thu, 3 Jan 2008 18:27:27 -0800 (PST) Message-ID: <477D999E.5080704@elischer.org> Date: Thu, 03 Jan 2008 18:27:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> In-Reply-To: <20080104021905.GE76698@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:27:29 -0000 Alfred Perlstein wrote: > Yes, but EINVAL please. I wondered who would be the first to complain about that.. "Gee you Juniper people have no sense of humour" :-) :-) > > Another idea would be a simplified SYSCTL_INT_PROC > that allowed one to define a function like so: > > int > sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min) > { > > > } > > If this function returned '0' then 'newval' would be accepted. > Otherwise the function should return an error, most likely EINVAL. > > The point being that a lot of these maximums may take a calculation > and we should make it as easy as possible to do this calculation > and provide the function for doing so. > > One would also set the min/max values so that one could query > the acceptable bounds of a tunable, or even the bounds of of > the tuneable. > > (Note: if *newval == NULL, we're just querying max/min, not > doing a set operation.) > > (Note 2: "handle" is so you can have a common handler and > possibly switch() off of handle for multiple sysctl ints to > reduce the number of functions required.) > > -Alfred > > * Julian Elischer [080103 17:57] wrote: >> I would like to extend the current SYSCTL_INT() with >> SYSCTL_INT_CLAMPED() or similar, where you also supply a >> maximum acceptable value. (and maybe a clue as to what to say if it is >> a bad value). >> >> so many users of SYSCTL_INT don't check for bad values because it's so >> much harder (you need to supply your own handler), and so many >> simple handlers exist fo rthe people that DO check that it seems to >> me that we should provide a pre-canned way to do this.... >> >> we are limited to using the existing structure, >> but as we have no existing callers we can redefine >> one element.... >> >> I would suggest: >> >> I'd like to test for a minimum too but I think I can only squeeze one >> field out of the existing struct sysctl_oid. >> >> SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) >> ^^^^ >> >> anyone think it's a bad idea? >> After all the macros are evaluated, (etc.) it would call: >> ( off the top of my head ) >> >> int >> sysctl_handle_int_max(SYSCTL_HANDLER_ARGS) >> { >> int error = 0; >> >> error = SYSCTL_OUT(req, arg1, sizeof(int)); >> >> if (error || !req->newptr) >> return (error); >> >> if (*(int *)arg1 > (int)arg2) >> error = EDOOFUS; >> else >> error = SYSCTL_IN(req, arg1, sizeof(int)); >> return (error); >> } >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:31:36 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3996216A419 for ; Fri, 4 Jan 2008 02:31:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACAE13C457 for ; Fri, 4 Jan 2008 02:31:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0E65D1A4D82; Thu, 3 Jan 2008 18:29:10 -0800 (PST) Date: Thu, 3 Jan 2008 18:29:10 -0800 From: Alfred Perlstein To: Julian Elischer Message-ID: <20080104022910.GF76698@elvis.mu.org> References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> <477D999E.5080704@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477D999E.5080704@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:31:36 -0000 * Julian Elischer [080103 18:25] wrote: > Alfred Perlstein wrote: > >Yes, but EINVAL please. > > I wondered who would be the first to complain about that.. > > "Gee you Juniper people have no sense of humour" :-) :-) I just don't see any point in prefering one non-descriptive error message over another, other than to confuse/annoy people. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:33:40 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC60F16A41A for ; Fri, 4 Jan 2008 02:33:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CD93113C459 for ; Fri, 4 Jan 2008 02:33:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 9EEDA1A4D82; Thu, 3 Jan 2008 18:31:14 -0800 (PST) Date: Thu, 3 Jan 2008 18:31:14 -0800 From: Alfred Perlstein To: Julian Elischer Message-ID: <20080104023114.GG76698@elvis.mu.org> References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> <477D9948.3050508@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477D9948.3050508@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:33:40 -0000 * Julian Elischer [080103 18:23] wrote: > Alfred Perlstein wrote: > >Yes, but EINVAL please. > > > >Another idea would be a simplified SYSCTL_INT_PROC > >that allowed one to define a function like so: > > > >int > >sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min) > >{ > > > > > >} > > > >If this function returned '0' then 'newval' would be accepted. > >Otherwise the function should return an error, most likely EINVAL. > > > >The point being that a lot of these maximums may take a calculation > >and we should make it as easy as possible to do this calculation > >and provide the function for doing so. > > yes I was thinking about that.. > something that allowed one to supply a simple comparison snippet. > > the limit is in the fields that are stored in the sysctl_oid > structure. Whichever you decide, I think either would be a step forward. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 04:51:47 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1506716A419; Fri, 4 Jan 2008 04:51:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8F73013C458; Fri, 4 Jan 2008 04:51:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m044pdgl027819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 15:51:41 +1100 Date: Fri, 4 Jan 2008 15:51:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alfred Perlstein In-Reply-To: <20080104022910.GF76698@elvis.mu.org> Message-ID: <20080104154326.H20228@delplex.bde.org> References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> <477D999E.5080704@elischer.org> <20080104022910.GF76698@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Julian Elischer Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 04:51:47 -0000 On Thu, 3 Jan 2008, Alfred Perlstein wrote: > * Julian Elischer [080103 18:25] wrote: >> Alfred Perlstein wrote: >>> Yes, but EINVAL please. >> >> I wondered who would be the first to complain about that.. >> >> "Gee you Juniper people have no sense of humour" :-) :-) > > I just don't see any point in prefering one non-descriptive error > message over another, other than to confuse/annoy people. The correct errno (ERANGE) would be descriptive and wouldn't conflict with the documented meaning of EINVAL. Checking bounds is good in theory, but the only time I had a problem with a bound in sysctl was when it enforced an unnecessarily high lower bound for an interrupt moderation timeout. It took an edit to test all values that the hardware supports. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 10:38:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09EBC16A46D for ; Fri, 4 Jan 2008 10:38:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BFF7E13C442 for ; Fri, 4 Jan 2008 10:38:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6A90117105; Fri, 4 Jan 2008 10:38:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04Acgrp005065; Fri, 4 Jan 2008 10:38:42 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 17:59:57 PST." <477D931D.4000303@elischer.org> Date: Fri, 04 Jan 2008 10:38:42 +0000 Message-ID: <5064.1199443122@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:38:45 -0000 In message <477D931D.4000303@elischer.org>, Julian Elischer writes: >I would like to extend the current SYSCTL_INT() with >SYSCTL_INT_CLAMPED() or similar, where you also supply a >maximum acceptable value. (and maybe a clue as to what to say if it is >a bad value). I'm not sure I think it is a good idea. Next you'll want SYSCTL_INT_BITMAP(), SYSCTL_INT_POWERS_OF_PI() and so on. A much better idea would be to add a code argument to a version of SYSCTL_INT(), so that people could write something like: SYSCTL_INT(_debug, OID_AUTO, foobar, ORD_WR, &foobar, 0, "mumble desc mumble", { if (newval < 3 || newval > 70 || newval == 59) return (EINVAL); } ) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 10:40:46 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AAE16A421; Fri, 4 Jan 2008 10:40:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFA913C469; Fri, 4 Jan 2008 10:40:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2141D17105; Fri, 4 Jan 2008 10:40:45 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04Aeil4005078; Fri, 4 Jan 2008 10:40:44 GMT (envelope-from phk@critter.freebsd.dk) To: "Attilio Rao" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 16:48:37 +0100." <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> Date: Fri, 04 Jan 2008 10:40:44 +0000 Message-ID: <5077.1199443244@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:40:46 -0000 In message <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com>, "Atti lio Rao" writes: >2008/1/3, Poul-Henning Kamp : >> What I'm proposing is that your thread will sleep on a plain, but >> unrelated mutex (internal to the timeout code) until the function >> comes back. >> >> Based on your description above, you won't be able to tell the >> any difference between this and what you wish for. > >This will be hardly feasible. >Internal callout subsystem locks probabilly need to be spinlocks in >order to avoid lock mismatches against sleepable locks. callouts will not be allowed to sleep, they never should have been able to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 10:40:46 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AAE16A421; Fri, 4 Jan 2008 10:40:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFA913C469; Fri, 4 Jan 2008 10:40:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2141D17105; Fri, 4 Jan 2008 10:40:45 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04Aeil4005078; Fri, 4 Jan 2008 10:40:44 GMT (envelope-from phk@critter.freebsd.dk) To: "Attilio Rao" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Jan 2008 16:48:37 +0100." <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> Date: Fri, 04 Jan 2008 10:40:44 +0000 Message-ID: <5077.1199443244@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:40:46 -0000 In message <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com>, "Atti lio Rao" writes: >2008/1/3, Poul-Henning Kamp : >> What I'm proposing is that your thread will sleep on a plain, but >> unrelated mutex (internal to the timeout code) until the function >> comes back. >> >> Based on your description above, you won't be able to tell the >> any difference between this and what you wish for. > >This will be hardly feasible. >Internal callout subsystem locks probabilly need to be spinlocks in >order to avoid lock mismatches against sleepable locks. callouts will not be allowed to sleep, they never should have been able to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 15:43:31 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51E316A4B3 for ; Fri, 4 Jan 2008 15:43:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 949F013C44B for ; Fri, 4 Jan 2008 15:43:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227269493-1834499 for multiple; Fri, 04 Jan 2008 10:41:39 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m04FhLSk039965; Fri, 4 Jan 2008 10:43:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 4 Jan 2008 10:42:09 -0500 User-Agent: KMail/1.9.6 References: <477D931D.4000303@elischer.org> In-Reply-To: <477D931D.4000303@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041042.09573.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Jan 2008 10:43:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 08:37:27 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Julian Elischer Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 15:43:31 -0000 On Thursday 03 January 2008 08:59:57 pm Julian Elischer wrote: > I would like to extend the current SYSCTL_INT() with > SYSCTL_INT_CLAMPED() or similar, where you also supply a > maximum acceptable value. (and maybe a clue as to what to say if it is > a bad value). > > so many users of SYSCTL_INT don't check for bad values because it's so > much harder (you need to supply your own handler), and so many > simple handlers exist fo rthe people that DO check that it seems to > me that we should provide a pre-canned way to do this.... > > we are limited to using the existing structure, > but as we have no existing callers we can redefine > one element.... In HEAD you can change the ABI of struct sysctl_oid. Or even better, you could do something like this: : struct sysctl_int_validator { int (*siv_validator)(void *arg, int newvalue); void *siv_arg; int *siv_data; } #define SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, validator, arg, descr) \ struct sysctl_int_validator siv__##parent##_##name = { \ (validator), (arg), (ptr) }; \ SYSCTL_OID(parent, nbr, name, CTLTYPE_INT|(access), \ &siv__##parent##_##name, 0, sysctl_handle_validated_int, \ "I", descr) int sysctl_handle_validated_int(SYSCTL_HANDLER_ARGS); kern/kern_sysctl.c: int sysctl_handle_validated_int(SYSCTL_HANDLER_ARGS) { struct sysctl_int_validator *siv; int error, tmp; siv = arg1; if (!siv) return (EINVAL); tmp = *siv->siv_data; error = sysctl_handle_int(oidp, &tmp, 0, req); if (error || !req->newptr) return (error); error = siv->siv_validator(siv->siv_arg, tmp); if (error == 0) *siv->siv_data = tmp; return (error); } You can repeat this for the various sysctl types adding a validator handler for each type. This gives you a framework to add simple validation. You could then add wrappers to that for specific cases if they are common. For example, you could implement the _CLAMPED variant like so: : SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) \ SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ sysctl_validate_clamped_int, (void *)max, descr) int sysctl_validate_clamped_int(void *arg, int newvalue); kern/kern_sysctl.c: int sysctl_validate_clamped_int(void *arg, int newvalue) { int max = (intptr_t)arg; if (newvalue > max) return (ERANGE); return (0); } You could even add min/max boundaries if desired: : struct sysctl_int_bounds = { int sib_min; int sib_max; }; SYSCTL_INT_BOUNDED(parent, nbr, name, access, ptr, min, max, descr) \ struct sysctl_int_bounds sib__##parent##_##name = { \ (min), (max) }; \ SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ sysctl_validate_bounded_int, &sib__##parent##_##name, \ descr) int sysctl_validate_bounded_int(void *arg, int newvalue); kern/kern_sysctl.c: int sysctl_validate_bounded_int(void *arg, int newwvalue) { struct sysctl_bounded_int *sib; sib = arg; if (newvalue < sib->sib_min || newvalue > sib->sib_max) return (ERANGE); return (0); } It would be nice to allow the validator function to be an anonymous routine like phk suggests. Perhaps something like: #define SYSCTL_INT_VALIDATOR(parent, nbr, name, access, ptr, descr, validator) \ int \ validate__##parent##_##name(int newvalue) \ validator \ SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ &validate__##parent##_##name, 0, descr) would work, though I'm not sure how cpp(1) would really handle that. You could also inline sysctl_handle_int() into sysctl_handle_validated_int() if you wanted. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:00:29 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8AA16A41A for ; Fri, 4 Jan 2008 16:00:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6811513C469 for ; Fri, 4 Jan 2008 16:00:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 04 Jan 2008 08:00:28 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 075FE126E14; Fri, 4 Jan 2008 08:00:27 -0800 (PST) Message-ID: <477E582A.2060106@elischer.org> Date: Fri, 04 Jan 2008 08:00:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Poul-Henning Kamp References: <5064.1199443122@critter.freebsd.dk> In-Reply-To: <5064.1199443122@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:00:29 -0000 Poul-Henning Kamp wrote: > In message <477D931D.4000303@elischer.org>, Julian Elischer writes: >> I would like to extend the current SYSCTL_INT() with >> SYSCTL_INT_CLAMPED() or similar, where you also supply a >> maximum acceptable value. (and maybe a clue as to what to say if it is >> a bad value). > > I'm not sure I think it is a good idea. > > Next you'll want SYSCTL_INT_BITMAP(), SYSCTL_INT_POWERS_OF_PI() and > so on. > > A much better idea would be to add a code argument to a version of > SYSCTL_INT(), so that people could write something like: > > SYSCTL_INT(_debug, OID_AUTO, foobar, ORD_WR, &foobar, 0, > "mumble desc mumble", > { > if (newval < 3 || newval > 70 || newval == 59) > return (EINVAL); > } > ) > I actually considered that already.. It has the advantage of being flexible.. but is more intrusive to implement. I think you'd have to extend the sysctl_oid structure. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:05:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89DB16A469 for ; Fri, 4 Jan 2008 16:05:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9B98113C457 for ; Fri, 4 Jan 2008 16:05:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1A2AA17105; Fri, 4 Jan 2008 16:05:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04G5FAn006533; Fri, 4 Jan 2008 16:05:15 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 08:00:42 PST." <477E582A.2060106@elischer.org> Date: Fri, 04 Jan 2008 16:05:15 +0000 Message-ID: <6532.1199462715@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:05:17 -0000 In message <477E582A.2060106@elischer.org>, Julian Elischer writes: >Poul-Henning Kamp wrote: >> In message <477D931D.4000303@elischer.org>, Julian Elischer writes: >>> I would like to extend the current SYSCTL_INT() with >>> SYSCTL_INT_CLAMPED() or similar, where you also supply a >>> maximum acceptable value. (and maybe a clue as to what to say if it is >>> a bad value). >> >> I'm not sure I think it is a good idea. >> >> Next you'll want SYSCTL_INT_BITMAP(), SYSCTL_INT_POWERS_OF_PI() and >> so on. >> >> A much better idea would be to add a code argument to a version of >> SYSCTL_INT(), so that people could write something like: >> >> SYSCTL_INT(_debug, OID_AUTO, foobar, ORD_WR, &foobar, 0, >> "mumble desc mumble", >> { >> if (newval < 3 || newval > 70 || newval == 59) >> return (EINVAL); >> } >> ) >> > > >I actually considered that already.. It has the advantage of being >flexible.. but is more intrusive to implement. I think you'd have to >extend the sysctl_oid structure. No, you'd just expand the macro to a sysctl-function and declare the oid as such. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:15:14 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107B616A420 for ; Fri, 4 Jan 2008 16:15:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id E84F813C447 for ; Fri, 4 Jan 2008 16:15:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 04 Jan 2008 08:04:45 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 46839126E0A; Fri, 4 Jan 2008 08:04:45 -0800 (PST) Message-ID: <477E592B.9040106@elischer.org> Date: Fri, 04 Jan 2008 08:04:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: John Baldwin References: <477D931D.4000303@elischer.org> <200801041042.09573.jhb@freebsd.org> In-Reply-To: <200801041042.09573.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:15:14 -0000 John Baldwin wrote: > On Thursday 03 January 2008 08:59:57 pm Julian Elischer wrote: >> I would like to extend the current SYSCTL_INT() with >> SYSCTL_INT_CLAMPED() or similar, where you also supply a >> maximum acceptable value. (and maybe a clue as to what to say if it is >> a bad value). >> >> so many users of SYSCTL_INT don't check for bad values because it's so >> much harder (you need to supply your own handler), and so many >> simple handlers exist fo rthe people that DO check that it seems to >> me that we should provide a pre-canned way to do this.... >> >> we are limited to using the existing structure, >> but as we have no existing callers we can redefine >> one element.... > > In HEAD you can change the ABI of struct sysctl_oid. Or even better, you > could do something like this: > > : > > struct sysctl_int_validator { > int (*siv_validator)(void *arg, int newvalue); > void *siv_arg; > int *siv_data; > } > > #define SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, validator, arg, descr) \ > struct sysctl_int_validator siv__##parent##_##name = { \ > (validator), (arg), (ptr) }; \ > SYSCTL_OID(parent, nbr, name, CTLTYPE_INT|(access), \ > &siv__##parent##_##name, 0, sysctl_handle_validated_int, \ > "I", descr) > > int sysctl_handle_validated_int(SYSCTL_HANDLER_ARGS); > > kern/kern_sysctl.c: > > int > sysctl_handle_validated_int(SYSCTL_HANDLER_ARGS) > { > struct sysctl_int_validator *siv; > int error, tmp; > > siv = arg1; > if (!siv) > return (EINVAL); > tmp = *siv->siv_data; > error = sysctl_handle_int(oidp, &tmp, 0, req); > if (error || !req->newptr) > return (error); > error = siv->siv_validator(siv->siv_arg, tmp); > if (error == 0) > *siv->siv_data = tmp; > return (error); > } > > You can repeat this for the various sysctl types adding a validator handler > for each type. This gives you a framework to add simple validation. You > could then add wrappers to that for specific cases if they are common. For > example, you could implement the _CLAMPED variant like so: > > : > > SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) \ > SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ > sysctl_validate_clamped_int, (void *)max, descr) > > int sysctl_validate_clamped_int(void *arg, int newvalue); > > kern/kern_sysctl.c: > > int > sysctl_validate_clamped_int(void *arg, int newvalue) > { > int max = (intptr_t)arg; > > if (newvalue > max) > return (ERANGE); > return (0); > } > > > You could even add min/max boundaries if desired: > > : > > struct sysctl_int_bounds = { > int sib_min; > int sib_max; > }; > > SYSCTL_INT_BOUNDED(parent, nbr, name, access, ptr, min, max, descr) \ > struct sysctl_int_bounds sib__##parent##_##name = { \ > (min), (max) }; \ > SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ > sysctl_validate_bounded_int, &sib__##parent##_##name, \ > descr) > > int sysctl_validate_bounded_int(void *arg, int newvalue); > > kern/kern_sysctl.c: > > int > sysctl_validate_bounded_int(void *arg, int newwvalue) > { > struct sysctl_bounded_int *sib; > > sib = arg; > if (newvalue < sib->sib_min || newvalue > sib->sib_max) > return (ERANGE); > return (0); > } > > It would be nice to allow the validator function to be an anonymous routine > like phk suggests. Perhaps something like: > > #define SYSCTL_INT_VALIDATOR(parent, nbr, name, access, ptr, descr, validator) \ > int \ > validate__##parent##_##name(int newvalue) \ > validator \ > SYSCTL_INT_VALIDATED(parent, nbr, name, access, ptr, \ > &validate__##parent##_##name, 0, descr) > > would work, though I'm not sure how cpp(1) would really handle that. > > You could also inline sysctl_handle_int() into sysctl_handle_validated_int() > if you wanted. > right, so you've solved that one.. now for global warming.. You might as well go ahead and commit it I think.. :-) From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:18:31 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7356316A420; Fri, 4 Jan 2008 16:18:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3424313C4DD; Fri, 4 Jan 2008 16:18:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 63E7417105; Fri, 4 Jan 2008 16:18:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04GIT3W006600; Fri, 4 Jan 2008 16:18:29 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 08:04:59 PST." <477E592B.9040106@elischer.org> Date: Fri, 04 Jan 2008 16:18:29 +0000 Message-ID: <6599.1199463509@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:18:31 -0000 In message <477E592B.9040106@elischer.org>, Julian Elischer writes: >John Baldwin wrote: >right, so you've solved that one.. Please no! This is far more complicated and wasteful than it needs to be. Please just include the code in the macro call and instantiate a function with that code inlined. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:55:38 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1A1E16A41B for ; Fri, 4 Jan 2008 16:55:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 458EC13C448 for ; Fri, 4 Jan 2008 16:55:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4380611fgg.35 for ; Fri, 04 Jan 2008 08:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8avo0QwecX4UD9dsEyNxRdRFEVNdmxs6z3+7e3Si5HY=; b=qesOwwD+Y5WUxag0ypQAFA/X2n3RNgT113u2YaaFChVbykw9jv4B0Xp1nKESrYif4AuhPUm9Ceod2ZfOtH8ImvIRqjHgKrWE5ogNI8mC/YUSDkqHrhjb5li/hZinXuLjZ7PlVnfg6xh7mU90yeJ8NFgasrsg0Hh7Esce0F2+u3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jBlArumWXeJUhJYDiXSqUwcy1ppJwbsB+LO5gAEV8GsaLvJsJjpmnVnarcahGg4p5yD4dm+YO1ff63ffysZEJFFtr5+ZkpiKbEN4lW7uSfA8h/bWk5YihSoww8IuFundDbLk4gVtDFwgPU+FYs/bH1cDYCN0BXZYK52RQSV+aJI= Received: by 10.86.80.5 with SMTP id d5mr16951595fgb.20.1199465736943; Fri, 04 Jan 2008 08:55:36 -0800 (PST) Received: by 10.86.28.19 with HTTP; Fri, 4 Jan 2008 08:55:36 -0800 (PST) Message-ID: <3bbf2fe10801040855o29088986w99e2caacff5082bb@mail.gmail.com> Date: Fri, 4 Jan 2008 17:55:36 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <5077.1199443244@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> <5077.1199443244@critter.freebsd.dk> X-Google-Sender-Auth: cfc34c94c63db1d5 Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:55:38 -0000 2008/1/4, Poul-Henning Kamp : > In message <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com>, "Atti > lio Rao" writes: > >2008/1/3, Poul-Henning Kamp : > > >> What I'm proposing is that your thread will sleep on a plain, but > >> unrelated mutex (internal to the timeout code) until the function > >> comes back. > >> > >> Based on your description above, you won't be able to tell the > >> any difference between this and what you wish for. > > > >This will be hardly feasible. > >Internal callout subsystem locks probabilly need to be spinlocks in > >order to avoid lock mismatches against sleepable locks. > > callouts will not be allowed to sleep, they never should have been > able to. I meant 'blocking' locks. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 16:55:38 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2AC616A420 for ; Fri, 4 Jan 2008 16:55:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 466F013C45D for ; Fri, 4 Jan 2008 16:55:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4380612fgg.35 for ; Fri, 04 Jan 2008 08:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8avo0QwecX4UD9dsEyNxRdRFEVNdmxs6z3+7e3Si5HY=; b=qesOwwD+Y5WUxag0ypQAFA/X2n3RNgT113u2YaaFChVbykw9jv4B0Xp1nKESrYif4AuhPUm9Ceod2ZfOtH8ImvIRqjHgKrWE5ogNI8mC/YUSDkqHrhjb5li/hZinXuLjZ7PlVnfg6xh7mU90yeJ8NFgasrsg0Hh7Esce0F2+u3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jBlArumWXeJUhJYDiXSqUwcy1ppJwbsB+LO5gAEV8GsaLvJsJjpmnVnarcahGg4p5yD4dm+YO1ff63ffysZEJFFtr5+ZkpiKbEN4lW7uSfA8h/bWk5YihSoww8IuFundDbLk4gVtDFwgPU+FYs/bH1cDYCN0BXZYK52RQSV+aJI= Received: by 10.86.80.5 with SMTP id d5mr16951595fgb.20.1199465736943; Fri, 04 Jan 2008 08:55:36 -0800 (PST) Received: by 10.86.28.19 with HTTP; Fri, 4 Jan 2008 08:55:36 -0800 (PST) Message-ID: <3bbf2fe10801040855o29088986w99e2caacff5082bb@mail.gmail.com> Date: Fri, 4 Jan 2008 17:55:36 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <5077.1199443244@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> <5077.1199443244@critter.freebsd.dk> X-Google-Sender-Auth: cfc34c94c63db1d5 Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:55:38 -0000 2008/1/4, Poul-Henning Kamp : > In message <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com>, "Atti > lio Rao" writes: > >2008/1/3, Poul-Henning Kamp : > > >> What I'm proposing is that your thread will sleep on a plain, but > >> unrelated mutex (internal to the timeout code) until the function > >> comes back. > >> > >> Based on your description above, you won't be able to tell the > >> any difference between this and what you wish for. > > > >This will be hardly feasible. > >Internal callout subsystem locks probabilly need to be spinlocks in > >order to avoid lock mismatches against sleepable locks. > > callouts will not be allowed to sleep, they never should have been > able to. I meant 'blocking' locks. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 17:09:15 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6779116A468 for ; Fri, 4 Jan 2008 17:09:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 12BD513C4E1 for ; Fri, 4 Jan 2008 17:09:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227283412-1834499 for multiple; Fri, 04 Jan 2008 12:07:00 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m04H8dCN040565; Fri, 4 Jan 2008 12:08:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Poul-Henning Kamp" Date: Fri, 4 Jan 2008 11:50:49 -0500 User-Agent: KMail/1.9.6 References: <6599.1199463509@critter.freebsd.dk> In-Reply-To: <6599.1199463509@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041150.49541.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Jan 2008 12:08:41 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 08:37:27 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:09:15 -0000 On Friday 04 January 2008 11:18:29 am Poul-Henning Kamp wrote: > In message <477E592B.9040106@elischer.org>, Julian Elischer writes: > >John Baldwin wrote: > > >right, so you've solved that one.. > > Please no! > > This is far more complicated and wasteful than it needs to be. > > Please just include the code in the macro call and instantiate > a function with that code inlined. Your code body in the example though is the just the validation step, it doesn't have all the copyin/copyout goop (nor should it). Are you really worried about the overhead of having a worker function call a function containing the validation code? Provided enough validated sysctls you'd actually result in less actual kernel text (1 copy of the copyin/copyout vs N, same reason we don't inline sysctl_handle_int() everywhere). I would probably just start with the FOO_VALIDATED at first and maybe FOO_VALIDATOR (that takes the code inline) if cpp(1) is happy with it and not worry about _CLAMPED and _BOUNDED. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 17:13:02 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16DBB16A418; Fri, 4 Jan 2008 17:13:02 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C958F13C455; Fri, 4 Jan 2008 17:13:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2CCDD17105; Fri, 4 Jan 2008 17:13:00 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04HCxKb006796; Fri, 4 Jan 2008 17:12:59 GMT (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 11:50:49 EST." <200801041150.49541.jhb@freebsd.org> Date: Fri, 04 Jan 2008 17:12:59 +0000 Message-ID: <6795.1199466779@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:13:02 -0000 In message <200801041150.49541.jhb@freebsd.org>, John Baldwin writes: >On Friday 04 January 2008 11:18:29 am Poul-Henning Kamp wrote: >> In message <477E592B.9040106@elischer.org>, Julian Elischer writes: >> >John Baldwin wrote: >> >> >right, so you've solved that one.. >> >> Please no! >> >> This is far more complicated and wasteful than it needs to be. >> >> Please just include the code in the macro call and instantiate >> a function with that code inlined. > >Your code body in the example though is the just the validation step, it >doesn't have all the copyin/copyout goop (nor should it). Of course not, the SYSCTL_INT_CODE() macro should instantiate that in the new function. >Are you really >worried about the overhead of having a worker function call a function >containing the validation code? No, I'm appalled at another clutch of weird data structures to encapsulate what is really a piece of code as a number of weird fields. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 18:43:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6682B16A417 for ; Fri, 4 Jan 2008 18:43:59 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id F295713C45B for ; Fri, 4 Jan 2008 18:43:58 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180173059.adsl.alicedsl.de [85.180.173.59]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id m04I4Yiv052801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jan 2008 19:04:35 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m04I4VQJ002815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 19:04:31 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m04I4UGe002814; Fri, 4 Jan 2008 19:04:30 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Fri, 4 Jan 2008 19:04:29 +0100 From: Ulrich Spoerlein To: Rong-en Fan Message-ID: <20080104180429.GA1496@roadrunner.spoerlein.net> Mail-Followup-To: Rong-en Fan , freebsd-arch@freebsd.org References: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-arch@freebsd.org Subject: Re: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 18:43:59 -0000 Hi Rong-en, On Thu, 03.01.2008 at 09:47:34 +0800, Rong-en Fan wrote: > Hi folks, > > Recently, I'm looking into 100150 which reports END key does not working in > mutt. With some help from ncurses author, I think this problem is caused by > our termcap. To be specific, our termcap defines kH, @7 (the END key), and *6 > to \EOF. ncurses has the limitation that it will only return the first matched > key back. So, in ncurses based program, it receives kH instead of @7 when you > hit END. Thanks for taking up the ball! It is not only the END key, though. The KP_Enter is missing, too. Is there some documentation on what kH, @7, etc. all means? I see that Home (^[OH) and End (^[OF) are there in /etc/termcap but only Return (^M) and not KP_Enter (^[OM). What would be the symbol required to map ^[OM to? I see that vt100 has @8=\EOM, is this what I'm looking for and do we want it in the xterm definition? > I just checked NetBSD's termcap, they only defines @7 to \EOF in xterm entry. > Also, on a Linux box, infocmp shows that only @7 is defined but not *6 and kH. > So, I'm wondering whether we should remove those two keys (kH and @7)? They also define @8=\EOM right next to @7. I wonder, though, how do I activate the change? I changed /etc/termcap, opened a new xterm but mutt's behaviour hasn't changed ... Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 19:50:22 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D1216A46B for ; Fri, 4 Jan 2008 19:50:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id CC5E113C4E9 for ; Fri, 4 Jan 2008 19:50:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m04JoJF6027539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 06:50:20 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m04JoJLj019634; Sat, 5 Jan 2008 06:50:19 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m04JoI8w019633; Sat, 5 Jan 2008 06:50:18 +1100 (EST) (envelope-from peter) Date: Sat, 5 Jan 2008 06:50:18 +1100 From: Peter Jeremy To: Rong-en Fan , freebsd-arch@freebsd.org Message-ID: <20080104195018.GN947@server.vk2pj.dyndns.org> References: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> <20080104180429.GA1496@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C" Content-Disposition: inline In-Reply-To: <20080104180429.GA1496@roadrunner.spoerlein.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 19:50:22 -0000 --IbVRjBtIbJdbeK1C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 07:04:29PM +0100, Ulrich Spoerlein wrote: >Is there some documentation on what kH, @7, etc. all means? See terminfo(5). Note that this only documents what capabilities are available to describe terminals. It doesn't mean that those capabilities are actually used by a specific application. >Home (^[OH) and End (^[OF) are there in /etc/termcap but only Return >(^M) and not KP_Enter (^[OM). What would be the symbol required to map >^[OM to? There's only provision for a single 'key_enter' (enter/send key) code - "@8" in termcap. >I wonder, though, how do I activate the change? I changed /etc/termcap, >opened a new xterm but mutt's behaviour hasn't changed ... Check if you have $TERMCAP as the terminal's expanded termcap entry. TERMCAP=3D'...' mutt works for me. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --IbVRjBtIbJdbeK1C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfo36/opHv/APuIcRAi+jAJ9uA7ksAOak2TFX0UDggKuMubnS+QCfQnWJ x9ezcVgwZ9basJEHtoma/fk= =GG08 -----END PGP SIGNATURE----- --IbVRjBtIbJdbeK1C-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 19:56:40 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D8516A420 for ; Fri, 4 Jan 2008 19:56:40 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id E701013C4E1 for ; Fri, 4 Jan 2008 19:56:39 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:56761 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JAsPn-0006PF-8i for freebsd-arch@freebsd.org; Fri, 04 Jan 2008 20:41:12 +0100 Received: (qmail 57099 invoked from network); 4 Jan 2008 20:41:09 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 4 Jan 2008 20:41:09 +0100 Received: (qmail 47867 invoked by uid 1001); 4 Jan 2008 20:41:09 +0100 Date: Fri, 4 Jan 2008 20:41:09 +0100 From: Erik Trulsson To: Rong-en Fan , freebsd-arch@freebsd.org Message-ID: <20080104194108.GA47714@owl.midgard.homeip.net> Mail-Followup-To: Rong-en Fan , freebsd-arch@freebsd.org References: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> <20080104180429.GA1496@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080104180429.GA1496@roadrunner.spoerlein.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1JAsPn-0006PF-8i. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1JAsPn-0006PF-8i 3fc3b5defa9a2b0367dc76fdcd62f09c Cc: Subject: Re: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 19:56:40 -0000 On Fri, Jan 04, 2008 at 07:04:29PM +0100, Ulrich Spoerlein wrote: > Hi Rong-en, > > On Thu, 03.01.2008 at 09:47:34 +0800, Rong-en Fan wrote: > > Hi folks, > > > > Recently, I'm looking into 100150 which reports END key does not working in > > mutt. With some help from ncurses author, I think this problem is caused by > > our termcap. To be specific, our termcap defines kH, @7 (the END key), and *6 > > to \EOF. ncurses has the limitation that it will only return the first matched > > key back. So, in ncurses based program, it receives kH instead of @7 when you > > hit END. > > Thanks for taking up the ball! It is not only the END key, though. The > KP_Enter is missing, too. > > Is there some documentation on what kH, @7, etc. all means? I see that > Home (^[OH) and End (^[OF) are there in /etc/termcap but only Return > (^M) and not KP_Enter (^[OM). What would be the symbol required to map > ^[OM to? > > I see that vt100 has @8=\EOM, is this what I'm looking for and do we > want it in the xterm definition? Read the termcap(5) and terminfo(5) manpages. They should include all information you might need about terminal capabilities. > > > I just checked NetBSD's termcap, they only defines @7 to \EOF in xterm entry. > > Also, on a Linux box, infocmp shows that only @7 is defined but not *6 and kH. > > So, I'm wondering whether we should remove those two keys (kH and @7)? > > They also define @8=\EOM right next to @7. > > I wonder, though, how do I activate the change? I changed /etc/termcap, > opened a new xterm but mutt's behaviour hasn't changed ... > I believe most programs look in /usr/share/misc/termcap.db (built from /usr/share/misc/termcap with cap_mkdb(1)) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-arch@FreeBSD.ORG Sat Jan 5 18:21:49 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4454116A421 for ; Sat, 5 Jan 2008 18:21:49 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id EB4A013C44B for ; Sat, 5 Jan 2008 18:21:48 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so10374025fka.11 for ; Sat, 05 Jan 2008 10:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dovyTqmnCbs6lfMw+NkZDCtmkXg8DbVBXDwWhDcC9bI=; b=K+HpED9eQxEyU/lz2q1ppH+dIthj85l4rDkb6D0jlQDIaYhroWeRjKjPD8Ye/BjjzHlZt8GUq1dILclDDXHvsTcXnK45vGA/fRbQ48JM7pSo3OlV3USGQjMyorsd4TXYCQGkvv7L0RI9PyXdwvskvUJFqX7egTyle655j5daFMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=abDzKjOKftm3HFZYRU5GHpqKSy3XChjQwQNSdcWvFn7ItR/kyJYuu/qn0tRSwygmUoct5auUuNMpT5AI7QxGMrTsJ/o81ijvHvvoUHmG6+w4eQCd8k/9DrK0rpvHB6mq8dq7S88agbtdHU5698YXwbcVdY/AgyDTNI7DU920rkI= Received: by 10.82.146.14 with SMTP id t14mr32114532bud.9.1199557307221; Sat, 05 Jan 2008 10:21:47 -0800 (PST) Received: by 10.82.116.17 with HTTP; Sat, 5 Jan 2008 10:21:47 -0800 (PST) Message-ID: <6eb82e0801051021s7161766bm6b98bbdc5b9e8748@mail.gmail.com> Date: Sun, 6 Jan 2008 02:21:47 +0800 From: "Rong-en Fan" To: freebsd-arch@freebsd.org In-Reply-To: <20080104180429.GA1496@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> <20080104180429.GA1496@roadrunner.spoerlein.net> Subject: Re: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 18:21:49 -0000 On Jan 5, 2008 2:04 AM, Ulrich Spoerlein wrote: > Hi Rong-en, > > On Thu, 03.01.2008 at 09:47:34 +0800, Rong-en Fan wrote: > > Hi folks, > > > > Recently, I'm looking into 100150 which reports END key does not working in > > mutt. With some help from ncurses author, I think this problem is caused by > > our termcap. To be specific, our termcap defines kH, @7 (the END key), and *6 > > to \EOF. ncurses has the limitation that it will only return the first matched > > key back. So, in ncurses based program, it receives kH instead of @7 when you > > hit END. > > Thanks for taking up the ball! It is not only the END key, though. The > KP_Enter is missing, too. > > Is there some documentation on what kH, @7, etc. all means? I see that > Home (^[OH) and End (^[OF) are there in /etc/termcap but only Return > (^M) and not KP_Enter (^[OM). What would be the symbol required to map > ^[OM to? > > I see that vt100 has @8=\EOM, is this what I'm looking for and do we > want it in the xterm definition? > > > I just checked NetBSD's termcap, they only defines @7 to \EOF in xterm entry. > > Also, on a Linux box, infocmp shows that only @7 is defined but not *6 and kH. > > So, I'm wondering whether we should remove those two keys (kH and @7)? > > They also define @8=\EOM right next to @7. > > I wonder, though, how do I activate the change? I changed /etc/termcap, > opened a new xterm but mutt's behaviour hasn't changed ... I'm proposing the following change: http://people.freebsd.org/~rafan/termcap-xterm.diff which removes kH, *6 from xterm and adds @8 (enter key) to it. Any objections? Thanks, Rong-En Fan > > Cheers, > Ulrich Spoerlein > -- > It is better to remain silent and be thought a fool, > than to speak, and remove all doubt. > From owner-freebsd-arch@FreeBSD.ORG Sat Jan 5 20:30:08 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0CCF16A417; Sat, 5 Jan 2008 20:30:08 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [194.67.23.200]) by mx1.freebsd.org (Postfix) with ESMTP id 57BD513C455; Sat, 5 Jan 2008 20:30:08 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=2959 helo=nuclight.avtf.net) by mx34.mail.ru with esmtp id 1JBFeg-000FAk-00; Sat, 05 Jan 2008 23:30:06 +0300 Date: Sun, 06 Jan 2008 02:30:02 +0600 To: "Julian Elischer" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <477D2EF3.2060909@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , Qing Li , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 20:30:09 -0000 04.01.08 @ 00:52 Julian Elischer wrote: >>> By the way, I might add that in the 6.x compat. version I may end up >>> limiting the feature to 8 tables. This is because I need to store some >>> stuff in an efficient way in the mbuf, and in a compatible manner this >>> is easiest done by stealing the top 4 bits in the mbuf dlags word >>> and defining them as: >>> >>> #define M_HAVEFIB 0x10000000 >>> #define M_FIBMASK 0x07 >>> #define M_FIBNUM 0xe0000000 >>> #define M_FIBSHIFT 29 >>> #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? >>> ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) >>> #M_SETFIB(_m, _fib) do { \ >>> _m->m_flags &= ~M_FIBNUM; \ >>> _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ >>> } while (0) >>> >>> This then becomes very easy to change to use a tag or >>> whatever is needed in later versions , and the number can >>> be expanded past 8 predefined FIBs at that time.. >> If you want it to be a tag, why spent bits in m_flags and not just do >> it as a tag at once? Or it is supposed to completely throw away 6.x >> (possibly 7.x too) implementation in favor of right thing in 8.0 ? > > basically yes.. > > I'm looking at just doing tags to start with, but haven't done it yet.. > I'm looking for a good bit of tag code to copy :-) Look at ipfw's O_ALTQ/O_TAG/O_TAGGED (ands some other parts), ng_tag.c, ng_ipfw.c, ng_ksocket.c and some other stuff :-) Tags are simple, if 16 bits are enough to you then even do not have to allocate data, just use tag_id member. Also they are easy to manipulate within netgraph with ng_tag, etc. But as drawback - you have to allocate memory for them, an as it is M_NOWAIT, malloc() can return NULL in interrupt threads... So a new field in mbuf (or flags) would be better in terms of performance, but it will break ABI :( I don't have m_tag_alloc() measurements, though. Doing 'ipfw add 1 tag 1 ip from any to any' on a 15 kpps 6.2 router didn't cause any noticeable slowdown while looking for half a minute at 'systat -vm 1'... > setfib 3 /bin/sh > > now by default everythign you do uses table 3. > or even > > setfib 3 jail {blah} > > and all the procs in the jail use table 3. You also need to do > setfib 3 jexec xxx > for extra processes you add to the jail afterwards. May be introduce a field in a struct prison to make it possible without additional commands? >>>>> 2/ packets received on an interface for forwarding. >>>>> By default these packets would use table 0, >>>>> (or possibly a number settable in a sysctl(not yet)). >>>>> but prior to routing the firewall can inspect them (see below). >>>>> >>>>> 3/ packets inspected by a packet classifier, which can arbitrarily >>>>> associate a fib with it on a packet by packet basis. >>>>> A fib assigned to a packet by a packet classifier >>>>> (such as ipfw) would over-ride a fib associated by >>>>> a more default source. (such as cases 1 or 2). >> Sounds good. I like idea to do routing decisions in firewall, to not >> double kernel code and userspace utilities, like in Linux' iproute2 >> (which, however, still have a few parameters and relies on firewall >> marks for others). However, there are some cases, I think, where it >> could be done outisde firewall. For example, make an ifconfig option to >> use a specific FIB as a default for all packets outgoing from this >> interface's address. But here arises another related question - Linux >> allows to select a specific src IP based on a routing table entry - >> destination address (thoughts about pf reply-to/route-ro, huh). > > that is default here too if I understand what you are talking about. > teh src address is selected from the routing table's exit interface. > In the code I'm showing in perforce, that address would depend on which > table your process was associated with. (or just the socket if you have > used the socket option on it before doing the bind/connect) What I'm talking about is adding possibility for future MPLS/VRF/etc. For example, if we make an interface option to use a specific FIB on that interface, for every incoming packet (put a tag on early input?), then ARP replies, ICMP redirects (yes, make stack to process them to particular FIB if specified, not to main) and so on will affect only this table. Then, it will be possible, say, to have 192.168.0.0/24 on em0 and also have 192.168.0.0/24 on em1, but that networks are completely independent of each other on both L2 and L3 (different customers) - after that, a change allowing to have the same IP address on different interfaces will lead to complete virtual independence. Without any vimages - why do we need separate TCP stacks etc. copies on a router without any jails, under a single administrator's control? Yes, this may be difficult with planned L2/L3 separation (currently ARP table is in fact part of FIB), but it is solvable - say, by binding an ARP table to one or several FIBs. Moreover, I think that complete stack virtulization in each jail/vimage is waste of resources - instead one or several FIBs/interfaces/ARP tables can be bound to each vimage/jail, possibly with write permissions. And even all of above is considered a far future and/or will be made different way, FIB binding to interface is still useful for (both incoming and) outgoing packets to make a firewall ruleset simpler. >> In relation to this I can remember multipath routing (different >> metrics?), addresses from one subnet on different ifaces (mask wider >> /32) and so on. >> Also it is interesting, how multiple FIBs would interact with host-wide >> events, such as ICMP redirects (which table should be updated?), >> storing of TCP stack metrics (MTU, etc.) and hostcache, and so on. How >> these and above will be solved?.. > > I'm not really too knowledgeable about multicast.. Is multicast and multipath routing the same? >> per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, >> multipath/metrics, tcp stack parameters interaction, iproute2 > > I'm not trying to solve problems that need vimage to solve them.. Umm, what vimage?.. :) I forgot to clear these keywords written for myself when writing draft and expaining them in detail,sorry :) >>>>> Routing messages would be associated with their >>>>> process, and thus select one FIB or another. >> This is not clear. How should the 'route' command work with different >> FIBs, if they are supposed by admin to be used for forwarding, and not >> the straight per-process? I think a setfib option is more consistent >> than running route under setfib command. Also, routing sockets and >> routing daemons - should they work with only one table?.. > > if you do > setfib 3 route get 1.1.1.1 > > you may get a different result from > > setfib 2 route get 1.1.1.1 > > I will add a fibnum argument to route itself as well but it's not needed > immediately as long as I have the setfib command. OK, but we should think about it in the future. In theory, routing socket's messages are easily extendable with FIB number in uint16_t, as message keeps it's length... >>>>> I have not yet added the changes to ipfw. >> Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? >> There were thoughts (I heard,t as a hack before multiple FIBs) about >> making an additional, say, 'nexthop' ipfw action, which acts like fwd, >> but does not accept packet, allowing to continue it through firewall >> ruleset - thus making it more comfortable to separate routing (imagine >> 'nexthop tablearg') and filtering. There are questions with both fwd >> and new supposed option: will fwd still survive? Will it change the >> output interface, like as complete rerouting before calling pfil(9) >> hooks, so that *oif will be changed to be mathed iin rules below? pf >> route-to/reply-to is hanging around... > > The 'nexthop' cal you suggest is problematic because it needs to return > information immediately. which is why it is terminal. Um, why? Why it can't continue through ruleset? I don't know implementation details of routing and 'ipfw fwd', alas, > As for the setfib ipfw action, I have now done this in p4. > > ipfw add 200 setfib 3 ip from any to any in receive em0 > > now works. > This lessens the need for associating a fib with an interface as the > firewall can do that too.. > > the setfib rule is not terminal. (hmm need to check I did that right.) Oh, it it works, that's cool. > you can also do > ipfw add 200 skipto 300 ip from any to any hasfib > # to select on a packet that has a fib associated with it already. > ipfw add 200 skipto 300 ip from any to any fib 4 > # to slelect packets that are associated with fib 4 > ipfw add 200 clrfib ip from any to any > # to remove a fib association from the packet. Do we need a separate keyword 'clrfib' while it could be 'setfib 0' ? Or at least save one opcode in kernel's ipfw. Also, it would be nice to have 'setfib tablearg' together with reserving 16 bits for FIB number - some systems with hundreds of vlans will want to have more than 256 tables, I think... >>>>> Interaction with the ARP layer/ LL layer would need to be >>>>> revisited as well. Qing Li has been working on this already. >> Oh yes, L2 interaction is interesting. How it should work in case of >> planned separation of routing and ARP tables?.. I've explained my views about it above... -- WBR, Vadim Goncharov From owner-freebsd-arch@FreeBSD.ORG Sat Jan 5 21:34:54 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8557216A41A for ; Sat, 5 Jan 2008 21:34:54 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id 21D5913C447 for ; Sat, 5 Jan 2008 21:34:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180182129.adsl.alicedsl.de [85.180.182.129]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id m05LYoFt064533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Jan 2008 22:34:52 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m05LQpDU007257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 22:26:52 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m05LQp2J007256; Sat, 5 Jan 2008 22:26:51 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sat, 5 Jan 2008 22:26:51 +0100 From: Ulrich Spoerlein To: Rong-en Fan Message-ID: <20080105212651.GA7006@roadrunner.spoerlein.net> Mail-Followup-To: Rong-en Fan , freebsd-arch@freebsd.org References: <6eb82e0801021747w73a04d5ckc0a7ef623a806302@mail.gmail.com> <20080104180429.GA1496@roadrunner.spoerlein.net> <6eb82e0801051021s7161766bm6b98bbdc5b9e8748@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6eb82e0801051021s7161766bm6b98bbdc5b9e8748@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-arch@FreeBSD.org Subject: Re: removing kH and *6 from xterm X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 21:34:54 -0000 On Sun, 06.01.2008 at 02:21:47 +0800, Rong-en Fan wrote: > On Jan 5, 2008 2:04 AM, Ulrich Spoerlein wrote: > > I wonder, though, how do I activate the change? I changed /etc/termcap, > > opened a new xterm but mutt's behaviour hasn't changed ... > > I'm proposing the following change: > > http://people.freebsd.org/~rafan/termcap-xterm.diff > > which removes kH, *6 from xterm and adds @8 (enter key) to it. > > Any objections? I'm running with the exact same patch right now, and after cap_mkdb (Thanks Erik!) the keys in mutt work like expected. I don't know what side-effects this may cause, but wider testing on -CURRENT could probably be fine? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt.