From owner-cvs-src@FreeBSD.ORG Thu Jan 26 19:58:15 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FB3E16A420; Thu, 26 Jan 2006 19:58:15 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D08643D6D; Thu, 26 Jan 2006 19:58:12 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k0QJw6mK040134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2006 22:58:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k0QJw6GG040133; Thu, 26 Jan 2006 22:58:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 26 Jan 2006 22:58:06 +0300 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20060126195806.GC83922@FreeBSD.org> References: <200601261306.k0QD6o4P070834@repoman.freebsd.org> <43D927B4.9040602@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <43D927B4.9040602@elischer.org> User-Agent: Mutt/1.5.6i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph ng_pppoe.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:58:15 -0000 On Thu, Jan 26, 2006 at 11:49:08AM -0800, Julian Elischer wrote: J> try not to change the behaviour of the LMI and PPPoE modules too much. J> the modules as they were, were certified by MCI as being complient with J> their J> PPPoE requirements. J> Some of the required behaviours were odd to me becasue they were not J> specified by the spec. J> (e.g. this behaviour) Ok. Should I hide the new behavior under a sysctl, turned off by default? It isn't destructive however. Is there any available test to verify whether any check is broken with new code? The other change I'm planning to do is the following - if the original PADI had empty Service-Name, and we are servicing a specific Service-Name, then return remove empty one from PADO, returning only our specific Service-Name. J> An interesting story.. J> J> I went to Dallas where their test lab was, with a laptop and the test J> box (actually 2 of them) J> (A whistle Interjet) and all the sources. When, in the first morning, J> they gave me a list of J> tests for which they wanted changes, (i.e. it failed,) I made the J> changes over the J> lunch hour on my laptop, and comiled up a new kernel and asked them to J> retest in the afternoon. They were amazed as they had never seen J> turnarund in less that 3 months J> (mainly from big companies). J> J> Needless to say, it passed with Flying colours in the second try, but J> according to the paperwork J> it passed with flying colours on the first try (from their perspective). J> Something else they J> had never seen. :-) I did the draft of this change at the D-Link office, too, while their guy was testing different gear against current FreeBSD. :) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE