From owner-freebsd-arch Sat May 4 10:49:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A046137B416; Sat, 4 May 2002 10:49:07 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g44HmTQ4037981; Sat, 4 May 2002 19:48:39 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Wes Peters , John Baldwin , Terry Lambert , arch@FreeBSD.ORG Subject: Re: savcore dump names? In-Reply-To: Your message of "Sat, 04 May 2002 10:35:15 PDT." <20020504173515.4109D3811@overcee.wemm.org> Date: Sat, 04 May 2002 19:48:29 +0200 Message-ID: <37980.1020534509@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020504173515.4109D3811@overcee.wemm.org>, Peter Wemm writes: >My concerns are pretty simple. You're chopping stuff out of a particularly >hairy bit of timing sensitive device driver code, not being able to test it >on the hardware that needs it, and all this for no apparent reason other >than that you do not like (or do not understand) it. ie: we do not gain >anything by it except risking breakage when the code gets used by more than >a handful of people. Well, I think reality is slightly different: I have removed a piece of code which I have spent the better part of 70 hours investigating, during which time I have not found one single place where it did anything of any difference. It is, by the way not at all timing sensitive, unless you do the next-page processing in software, which I am pretty certain we do not do anywhere in sys/dev/mii since the API wouldn't support it, neither at boot time nor later. By leaving it in, we risk having it copied & pasted to even more PHY drivers where it will only clutter up the source and prevent people from understanding what is going on. >In the light of the savecore fiasco, I'm worried that you are going to >simply respond and and say "Not my problem" when all hell breaks loose in 6 >to 12 months from now. When somebody upgrades their 4.x box to 5.0-REL and >their 'tl' card stops working because of your "simplification", will you >fix it? If you commit to that, then I'm no longer worried. I think there is a big difference. savecore is a userland program only slightly more complex than hello.c which anyone can make changes to, so saying "not my problem" is not a project disaster, despite what the totally out of proportion email trafic on the subject might lead one to belive. If this breaks the tl network driver, then it is not because I removed this code, then it is because the problem were not fixed in if_tl.c where it should have been originally, and if somebody reports such breakage I will do what I can to fix the problem. >This is not quite the same thing as userconfig. [...] You make this sound like resurrecting things from CVS is impossible, something both you, I and everybody else know is just plain wrong. I actually think it is quite the same as USERCONFIG. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message