On Sat, 2003-01-11 at 12:27, Andi Kleen wrote:
> Can you quickly summarize what is broken with IDE ?
> Are just some low level drivers broken or are there some generic
> nasty problems.
>
> If it is just some broken low level drivers I guess they can
> be marked dangerous or CONFIG_EXPERIMENTAL.
Low level drivers are basically sorted.
The main problems are
- Incorrect locking all over the place
- Incorrect timings on some phases
- Some ioctls can cause crashes due to locking
- ISAPnP IDE doesn't work right now
- Flaws in error recovery paths in certain situations
- 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)
- 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
- PCI IDE driver registration needs busy checks
- PCI layer needs some stuff from 2.4
- PCI layer in 2.4/2.5 needs an IRQ bug fixing
- ACPI doesn't seem to handle compatibility IRQ mode
- We don't handle a few errata (MWDMA on 450NX for example)
- IDE raid hasn't been ported to 2.5 at all yet
Thats off the top of my head right now.
> How does it differ from the code that was just merged into 2.4.21pre3
> (has the later all the problems fixed?)
No, although some don't show up in the same ways in 2.4 - eg the pcmcia
unload race is rare in 2.4 for other reasons. Endianism should all
be cured in 2.4, and I sent that to Linus. The PCI i/o assignment code
in 2.4 is done. I hope to have some of the locking and also the timing
path work Ross Biro has done in for 2.4.22 proper
> > broken and nobody has even started fixing it. Just try a mass of parallel
> > tty/pty activity . It was problematic before, pre-empt has taken it to dead,
> > defunct and buried.
>
> Can someone shortly describe what is the main problem with TTY?
>
> >From what I can see the high level tty code mostly takes lock_kernel
> before doing anything.
Which works really well with all the IRQ paths on it
> On reads access to file->private_data is not serialized, but it at
> least shouldn't go away because VFS takes care of struct file
> reference counting.
The refcounting bugs are/were in the ldisc stuff. I thought the
bluetooth folks (Max and co) fixed that one
If we can lock_kernel the tty layer for now (I'm bothered about
the ldisc end of tht which is IRQ context) then great, tty scaling
is suddenelly a 2.7 problem.
-
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/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:37 EST