From owner-freebsd-stable  Thu Nov 21  3:16:12 2002
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id DDE2737B401; Thu, 21 Nov 2002 03:16:10 -0800 (PST)
Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 36C0443E42; Thu, 21 Nov 2002 03:16:09 -0800 (PST)
	(envelope-from matthias.andree@gmx.de)
Received: from m2a2.yi.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])
	by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP
	id 5F59CA3841; Thu, 21 Nov 2002 12:16:02 +0100 (CET)
Received: by merlin.emma.line.org (Postfix, from userid 500)
	id BFC835F1C8; Thu, 21 Nov 2002 12:15:57 +0100 (CET)
Date: Thu, 21 Nov 2002 12:15:57 +0100
From: Matthias Andree <matthias.andree@gmx.de>
To: Nate Lawson <nate@root.org>
Cc: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>,
	ports@FreeBSD.ORG, stable@FreeBSD.ORG
Subject: Re: HEADSUP - change in CDRIOC.*SPEED ioctl units
Message-ID: <20021121111557.GC6603@merlin.emma.line.org>
References: <m3fztvy0p0.fsf@merlin.emma.line.org> <Pine.BSF.4.21.0211202139460.66175-100000@root.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.BSF.4.21.0211202139460.66175-100000@root.org>
User-Agent: Mutt/1.5.1i
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-stable.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-stable>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-stable>
X-Loop: FreeBSD.ORG

On Wed, 20 Nov 2002, Nate Lawson wrote:

> I'm not going to debate API since as I said before, the API is
> fundamentally limiting.  It was written to support one program
> (burncd) and thus is overly restrictive.  I took the approach of limiting
> the MMC set less, not adding another hack.

If it's really only used by baseline programs, would not it be better
then to kill it altogether than shuffling it from one limited state to
another? Some people say that software optimization is complete when
there's nothing left to remove. I tend to agree for the maintenance
involved.

-- 
Matthias Andree

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message