From owner-freebsd-net Mon Sep 24 4:42:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A8D3037B40D for ; Mon, 24 Sep 2001 04:42:38 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8OBer060394; Mon, 24 Sep 2001 14:40:53 +0300 (EEST) (envelope-from ru) Date: Mon, 24 Sep 2001 14:40:53 +0300 From: Ruslan Ermilov To: Jonathan Lemon Cc: "Matthew N. Dodd" , net@FreeBSD.ORG Subject: Re: review request. Message-ID: <20010924144053.G50028@sunbay.com> References: <20010923183909.A79251@prism.flugsvamp.com> <20010923190346.B79251@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010923190346.B79251@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Sun, Sep 23, 2001 at 07:03:46PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Seconded. This should be a KASSERT() if at all. If that counts. :-) On Sun, Sep 23, 2001 at 07:03:46PM -0500, Jonathan Lemon wrote: > On Sun, Sep 23, 2001 at 07:53:20PM -0400, Matthew N. Dodd wrote: > > On Sun, 23 Sep 2001, Jonathan Lemon wrote: > > > On Sun, Sep 23, 2001 at 07:32:18PM -0400, Matthew N. Dodd wrote: > > > > On Sun, 23 Sep 2001, Jonathan Lemon wrote: > > > > > >sys/net/if.c and bpf.c have problems with if_detach() and > > > > > >bpfdetach() when they are called with a struct ifnet that has not had > > > > > >if_attach() and bpfattach() called on it. Null pointer reference -> > > > > > >*boom* etc. > > > > > > > > > > I would say that this is to be expected. Why is the system calling > > > > > the detach functions on a device that isn't attached in the first > > > > > place? > > > > > > > > Driver mistake, but I see no reason why these functions shouldn't handle > > > > this gracefully. > > > > > > Because all it does is conceal the original error. Better to catch > > > the mistake and fix the driver than paper it over. > > > > Right; rather than failing the detach routines will fuss about it so you > > know exactly how you screwed up. I don't see this papering anything over. > > Because this is not a normal operational error. If anything, the > statement should be a KASSERT(), but I don't really see the need for it. > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message