Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 12 Jul 2002 15:03:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 12 Jul 2002 15:03:49 -0400 Received: from mion.elka.pw.edu.pl ([194.29.160.35]:58775 "EHLO mion.elka.pw.edu.pl") by vger.kernel.org with ESMTP id ; Fri, 12 Jul 2002 15:03:46 -0400 Date: Fri, 12 Jul 2002 21:06:12 +0200 (MET DST) From: Bartlomiej Zolnierkiewicz To: "H. Peter Anvin" cc: Linus Torvalds , Martin Dalecki , Subject: Re: IDE/ATAPI in 2.5 In-Reply-To: <3D2F20DD.1030704@zytor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1921 Lines: 54 On Fri, 12 Jul 2002, H. Peter Anvin wrote: > Linus Torvalds wrote: > > > > On Fri, 12 Jul 2002, Martin Dalecki wrote: > > > >>So Linus what's your opinnion please? > > > > > > I will violently oppose anything that implies that the IDE layer uses the > > SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing > > that should be scrapped is ide-scsi. > > > > The higher layers already have much of what the SCSI layer does, and the > > SCSI layer itself is slowly moving in that direction. > > Then *please* make a *compatible* interface available to user space. > This certainly can be done; the parallel port IDE interface stuff had > exactly such an interface (/dev/pg*) -- we could have a /dev/hg* > interface presumably. That is an acceptable solution. > > Note again that this discussion (and it's a discussion, not a voting > session -- technical pros and cons is what applies) apply to ATAPI (SCSI > over IDE) only. Alan has already brought up the fact of non-hard disk Please stop calling ATAPI as SCSI over IDE, it is not. It is Packet Interface over ATA (IDE). Some ATAPI/SCSI devices are functionally equivalent because they support the same command set (i.e. MMC). > non-ATAPI devices, and IMO those devices are explicitly out of scope. > Maturity of drivers is another, but right now we're suffering through > having to deal with multiple drivers for the same hardware, or with user Where multiple means two? ;-) > space having to choose different interfaces depending on connection > interface, and either which way that's pretty pathetic. It is in fact. Generic higher level interface is a solution. Greets -- Bartlomiej > > -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/