From owner-svn-src-all@FreeBSD.ORG Wed Mar 21 11:50:04 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18D941065670; Wed, 21 Mar 2012 11:50:04 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 996008FC08; Wed, 21 Mar 2012 11:50:03 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q2LBo11r040964; Wed, 21 Mar 2012 12:50:02 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q2LBo1dw040963; Wed, 21 Mar 2012 12:50:01 +0100 (CET) (envelope-from marius) Date: Wed, 21 Mar 2012 12:50:01 +0100 From: Marius Strobl To: Andre Oppermann Message-ID: <20120321115001.GB37560@alchemy.franken.de> References: <201203210850.q2L8olCj062739@svn.freebsd.org> <4F699AA3.20800@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F699AA3.20800@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233273 - head/sys/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:50:04 -0000 On Wed, Mar 21, 2012 at 10:08:51AM +0100, Andre Oppermann wrote: > On 21.03.2012 09:50, Marius Strobl wrote: > >Author: marius > >Date: Wed Mar 21 08:50:47 2012 > >New Revision: 233273 > >URL: http://svn.freebsd.org/changeset/base/233273 > > > >Log: > > Exclude devices which are mutually exclusive with ATA_CAM. For better > > or worse, the former are still built as modules as part of the LINT > > builds > > > > Reviewed by: mav > > MFC after: 1 week > > Is there any schedule on deorbiting old ATA? > I'd say eventually we should as at them point in time it likely will start to collect bit rot. Currently, ATA_CAM still has some bugs and deficiencies like breaking ATAPI DMA for some controllers and generally not supporting some others (see r233274). So at present it's IMO too early to think about actually removing the !ATA_CAM bits from ata(4). Marius