Re: any chance of 2.6.0-test*?

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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.