From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: PAUL BENNETT <paul.bennett@usa.net>, linux-kernel@vger.kernel.org
Subject: Re: 2.5 IDE Whitepaper?
Date: 22 Aug 2002 00:51:52 +0100 [thread overview]
Message-ID: <1029973912.26845.266.camel@irongate.swansea.linux.org.uk> (raw)
In-Reply-To: <3D64231C.6050407@mandrakesoft.com>
On Thu, 2002-08-22 at 00:32, Jeff Garzik wrote:
> PAUL BENNETT wrote:
> > 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?
>
> <chuckle> 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 :)
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.
prev parent reply other threads:[~2002-08-21 23:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-21 18:38 PAUL BENNETT
2002-08-21 23:32 ` Jeff Garzik
2002-08-21 23:51 ` Alan Cox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1029973912.26845.266.camel@irongate.swansea.linux.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.bennett@usa.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®