Ahogy a múlt héten írtam a 2.5-ös fejlesztői kernel a 2.4 kernelek előre portolt IDE kódját fogja használni, miután az IDE kód maintainer Martin Dalecki nem folytatja a 2.5 IDE munkát. Több levél is érkezett az LKML-re, amelyben tudakolták, hogy hogyan is tovább. Paul Bennett küldött egy levelet a fent említett levlistára, melyben a jövőről érdeklődött: "Mi a célja a 2.5-nek? Mi az implementációs terv? Mik a problémák a 2.4-ben, és hogy lesznek ezek javítva a 2.5-ben, stb?"
A Linus korábban kijelentette, hogy a lehetséges pályázók egyike Alan Cox, aki majd kibogozza az IDE kódot: "Jelenleg úgy fest a mostani állás szerint, hogy Alan lesz az aki az IDE kódon fog dolgozni, ami nyilvánvalóan nagyszerű dolog. Én csak azon csodálkozom, hogy bírja (Ő tart karban számos IDE buglistát, fixálja a bugokat évek óta, szóval reménykedhetünk)" - mondta Linus.
Cox válaszolt Bennett levelére, melyben leírta, hogy tervei szerint az IDE kód ``megszerelése" négy fázisban fog zajlani: "Ez lehetővé teszi nekünk, hogy egy szolid, stabil IDE kódot tarthassunk magunknál a fejlesztés alatt" - írta Alan Cox. Cox megjegyezte, hogy az első fázis már szinte készen van.
Akit konkrétan érdekelnek a részletek, klikk a ``tovább"-ra.From: Paul Bennett
Subject: 2.5 IDE Whitepaper?
Date: Wed, 21 Aug 2002 14:38:07 -0400
I am looking for documentation regarding the 2.5 IDE rewrite. For example: What are the goals for 2.5. What is the implementation plan? What were the problems in 2.4, and how will they be fixed in 2.5, etc?
Thanks.
-- Paul
From: Jeff Garzik
Subject: Re: 2.5 IDE Whitepaper?
Date: Wed, 21 Aug 2002 19:32:44 -0400
I wish :)
I imagine it will happen like most things happen, Linus describes his ideas and goals and wishes in a few lkml posts, and eventually something
like it happens :)
From: Alan Cox
Subject: Re: 2.5 IDE Whitepaper?
Date: 22 Aug 2002 00:51:52 +0100
I can try, my working list approximates this (ignoring the 2.5
porting/block I/O stuff which is a chapter in itself)
Phase #1 (mostly complete)
Merge Andre's current code [DONE]
Remove all the bogus code from the PCI drivers [90% DONE]
Move all the drivers seperate from the core code [DONE]
Migrate the PCI drivers to a registration API and allow insmod
Fix bugs arising from the first bits of phase 1
Phase #2
Deal with insmod of a device currently running as legacy
Fix up the locking ready to allow rmmod of a pci driver
Allow rmmod and hotplug at the controller level
Phase #3
Complete splitting setup-pci functions into smaller bits of code
and replace deep magic and callbacks with functions called from each driver. Get all the if device==foo out of the PCI code paths
Phase #4
Do something about the ide_register/unregister end of the world and legacy chipset stuff. The PPC folks may tackle this in advance
Get us to the point we can foo = ide_attach(); ide_remove(foo) for arbitary interfaces
And then (when the setup is turned the right way out and not before) begin looking at turning the actual block I/O engine the right way out. (That is driver calls helpers not midlayer and magic)
That should allow us to keep solid stable IDE along the way.