Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 11 Jan 2003 09:36:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 11 Jan 2003 09:36:29 -0500 Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([213.105.254.86]:43412 "EHLO irongate.swansea.linux.org.uk") by vger.kernel.org with ESMTP id ; Sat, 11 Jan 2003 09:36:26 -0500 Subject: Re: any chance of 2.6.0-test*? From: Alan Cox To: Andi Kleen Cc: Linux Kernel Mailing List In-Reply-To: <20030111140602.GA20221@averell> References: <20030110165441$1a8a@gated-at.bofh.it> <20030110165505$38d9@gated-at.bofh.it> <1042295999.2517.10.camel@irongate.swansea.linux.org.uk> <20030111140602.GA20221@averell> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042299059.2517.29.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 (1.2.1-2) Date: 11 Jan 2003 15:31:00 +0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 58 On Sat, 2003-01-11 at 14:06, Andi Kleen wrote: > > The main problems are > > - Incorrect locking all over the place > > Hmm bad. Is it that hard to fix ? Very. Just read the settings/proc code for an example > > - Incorrect timings on some phases > > Can't you just take out the timings in that case? > My (not very informed) understanding is: > everything should work with the BIOS timings and generic IDE, > having own timings is just an optimization to squeeze out a bit > more speed. These are timing for phases not drive timings. Drive timings from the BIOS are also frequently questionable. These have to be fixed and as boxes get faster it becomes more important they are > > - Lots of random oopses on boot/remove that were apparently > > introduced by the kobject/sysfs people and need chasing > > down. (There are some non sysfs ones mostly fixed) > > I guess the kobject/sysfs stuff could be ripped out if it doesn't > work - it is probably not a "must have" feature. Without a doubt. > > - ide-scsi needs some cleanup to fix switchover ide-cd/scsi > > (We can't dump ide-scsi) > > - Unregister path has races which cause all the long > > standing problems with pcmcia and prevents pci unreg > > Can't you just disable module unloading for the release ? Only if I can also nail shut your PCMCIA slot, disallow SATA and remove some ioctls people use for docking. > > - IDE raid hasn't been ported to 2.5 at all yet > > Vendor problem ? It needs a rewrite to the new bio layer or rewriting to use the device mapper, which is a distinct option here. > > Which works really well with all the IRQ paths on it > > Then 2.0/2.2/2.4 would have been racy too :-) Apparently they worked though. Long ago lock_kernel had meaning against IRQ paths. TTY never caught up. - 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/