lkml.org 
[lkml]   [2002]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IDE?

On Fri, 16 Aug 2002, Alexander Viro wrote:
>
> Sigh... What we need with IDE is
> a) translator/bogon filter between hardware folks and the rest of
> us. If Jens or Alan are willing to do that for a while - wonderful.

Agreed.

> b) review of code structure in existing code. Doing that.

Hey, my secret plan is to make sure those IDE people are kept in check, by
having AL flame them to smithereens if they do something stupid..

> c) careful massage (as opposed to grand rewrite) of said structure
> into something sane. With series of small provable equivalent transformations.
> And whoever does that is in serious risk of burnout - current spaghetty in
> there is a fscking mess. I'll try to help with that - I know how to do such
> work, but I don't promise to get it all the way to sanity.

Good luck, but I think those init rules etc are really horribly subtle.

I really would suggest an alternate (but not necessarily very different)
approach.

The approach I'd advocate is to

- move the major number registration out of the IDE code, and changing
all device numbers into indexes + a queue. This can be done without
actually changing any of the _IO_ the drivers do, and should be doable
with a transformation that doesn't change behaviur _at_all_.

This, btw, is an area that a certain Al is fairly intimate with anyway ;)

- once the IDE drivers don't even know about major and minor numbers
(right now it has 10 major numbers assigned to it, I think) and doesn't
register a block device with "register_blkdev()" at all, but instead
registers the controllers it finds one by one through some indirect
agent, we can now try phase 2.

- phase 2: IDE-TNG. Leave the current IDE code unchanged, and plan to
obsolete it. It's the "stable IDE", and by virtue of being stable,
nobody will mind work on new drivers that (by definition) cannot screw
up unless you use them.

IDE-TNG would:
- be controller-specific (ie one driver for one controller family)
- be able to say "screw it" for old or broken setups (which are left
fot the old IDE code)
- in particular, it would only bother with PCI (or better)
controllers, and with UDMA-only setups.

The point of IDE-TNG would be to only support the major controllers this
way, but let those major controllers have a driver that is meant for
_them_ and doesn't have to worry about historical baggage.

And then in five years, in Linux-3.2, we might finally just drop support
for the old IDE code with PIO etc. Inevitably some people will still use
it (the same way some people still use Linux-2.0 with hd.c), but it won't
have been in the way for making a cleaner driver in the meantime.

And yes, by now this all is obviously 2.7.x material.

Linus

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.134 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site