IDE?

IDE?

[Martin J. Bligh]

So did Linus get disk corruption or is something else afoot?

9 hours  axboe  1.456.34.40  Delete 2.5 IDE core
9 hours  axboe  1.456.34.41  Add 2.4 IDE core, based on late 2.4.19-pre-acX version  

Re: IDE?

[Linus Torvalds]

In article <2444170000.1029531611@flay>,
Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
>So did Linus get disk corruption or is something else afoot?

Martin gave up the fight he had to do all the time, so..

		Linus

Re: IDE?

[Matthias Andree]

On Fri, 16 Aug 2002, Linus Torvalds wrote:

> In article <2444170000.1029531611@flay>,
> Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> >So did Linus get disk corruption or is something else afoot?
> 
> Martin gave up the fight he had to do all the time, so..

Not having seen much of all the work, this sounds like it is a sad day,
for Martin who contributed a lot of his time to work on the issues,
while people seemed not to be too grateful, screaming from either end of
the road, this must wear people out.

Is there a way how the improvements that parts of the stuff have
received can be rescued somehow? Or at least the knowledge of which can
be used somewhat directly for a IDE-TNG driver? I'd find it really sad
to just let go of so much time that had been invested into the project
-- but keep in mind I have NO knowledge of the gory details of the last
2.5 IDE stuff.

-- 
Matthias Andree

Re: IDE? IDE-TNG driver

[Andre Hedrick]

I will hand it to you guys on a silver platter IDE-TNG.

Below yields modular chipsets and channel index registration.
Selectable IOPS for arch independent Taskfile Transport layers.
Now to finish the job with device class link lists to address fully
modular subdrivers.  It also includes 1st generation of device open and
select calls of subdrivers.

You have ide-cd registered on a cdrw and you want to burn a cd?
open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
open(/dev/sg) and burn baby burn.
close(/dev/sg) releases transform_subdriver_scsi
open(/dev/hdX) load native atapi transport.

Will do it for TAPE-FLOPPY-DVDCD/RW ...


Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SiI680: IDE controller on PCI bus 00 dev 90
SiI680: chipset revision 1
SiI680: not 100% native mode: will probe irqs later
SiI680: BASE CLOCK == 133
    ide0: MMIO-DMA at 0xe080df00-0xe080df07, BIOS settings: hda:pio, hdb:pio
    ide1: MMIO-DMA at 0xe080df08-0xe080df0f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 4G160J8, ATA DISK drive
hdb: Maxtor 4G160J8, ATA DISK drive
ide0 at 0xe080df80-0xe080df87,0xe080df8a on irq 9
hda: host protected area => 1
hda: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdb: host protected area => 1
hdb: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdc: Maxtor 4G160J8, ATA DISK drive
hdd: Maxtor 4G160J8, ATA DISK drive
ide1 at 0xe080dfc0-0xe080dfc7,0xe080dfca on irq 9
hdc: host protected area => 1
hdc: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdd: host protected area => 1
hdd: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xffa0-0xffa7, BIOS settings: hde:DMA, hdf:DMA
    ide3: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdg:pio, hdh:pio
hde: ATAPI 44X CDROM, ATAPI CD/DVD-ROM drive
hdf: CREATIVEDVD5240E-1, ATAPI CD/DVD-ROM drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
hde: ATAPI 40X CD-ROM drive, 128kB Cache, (U)DMA
Uniform CD-ROM driver Revision: 3.12
hdf: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1
 /dev/ide/host0/bus0/target1/lun0: p1
 /dev/ide/host0/bus1/target0/lun0: p1
 /dev/ide/host0/bus1/target1/lun0: p1


If this is what you want, this is what I have to put on the table.
If you do not I will delete the code.


Regards,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 17 Aug 2002, Matthias Andree wrote:

> On Fri, 16 Aug 2002, Linus Torvalds wrote:
> 
> > In article <2444170000.1029531611@flay>,
> > Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> > >So did Linus get disk corruption or is something else afoot?
> > 
> > Martin gave up the fight he had to do all the time, so..
> 
> Not having seen much of all the work, this sounds like it is a sad day,
> for Martin who contributed a lot of his time to work on the issues,
> while people seemed not to be too grateful, screaming from either end of
> the road, this must wear people out.
> 
> Is there a way how the improvements that parts of the stuff have
> received can be rescued somehow? Or at least the knowledge of which can
> be used somewhat directly for a IDE-TNG driver? I'd find it really sad
> to just let go of so much time that had been invested into the project
> -- but keep in mind I have NO knowledge of the gory details of the last
> 2.5 IDE stuff.
> 
> -- 
> Matthias Andree
> -
> 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/
> 

Re: IDE? IDE-TNG driver

[Skip Ford]

Andre Hedrick wrote:
> 
> I will hand it to you guys on a silver platter IDE-TNG.
>
[snip]
> 
> If this is what you want, this is what I have to put on the table.
> If you do not I will delete the code.

Can't you just create a patch and send it to the list?  I for one would
like to try out your code.  Just diff it and send it without the song
and dance please.

-- 
Skip

Re: IDE? IDE-TNG driver

[Matthew D. Pitts]

I agree. Send a patch and I will test it, too.

----- Original Message -----
From: "Skip Ford" <skip.ford@verizon.net>
To: "Andre Hedrick" <andre@linux-ide.org>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, August 17, 2002 9:56 AM
Subject: Re: IDE? IDE-TNG driver


> Andre Hedrick wrote:
> >
> > I will hand it to you guys on a silver platter IDE-TNG.
> >
> [snip]
> >
> > If this is what you want, this is what I have to put on the table.
> > If you do not I will delete the code.
>
> Can't you just create a patch and send it to the list?  I for one would
> like to try out your code.  Just diff it and send it without the song
> and dance please.
>
> --
> Skip
> -
> 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/

Re: IDE? IDE-TNG driver

[Alan Cox]

You can do the switch (one way only right now) in 2.4.20-pre2-ac3.
Ultimately for 2.4 I want to get to the point where open() tries to
switch between srfoo and hdfoo and locks out the other user. For 2.5 we
can get more esoteric. 2.4 has to continue to just work

Re: IDE? IDE-TNG driver

[Ruth Ivimey-Cook]

On Sat, 17 Aug 2002, Andre Hedrick wrote:

>
>I will hand it to you guys on a silver platter IDE-TNG.
>
>Below yields modular chipsets and channel index registration.
>Selectable IOPS for arch independent Taskfile Transport layers.
...
>You have ide-cd registered on a cdrw and you want to burn a cd?
>open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
>open(/dev/sg) and burn baby burn.
>close(/dev/sg) releases transform_subdriver_scsi
>open(/dev/hdX) load native atapi transport.


Andre, I see the thought, but surely this is prine to races and other 
difficulties.

Wouldn't it be better to provide an IDE ioctl() that enables the caller to use 
set the SCSI transport on an open FD, so your sequence becomes:

 open(/dev/hdX)
 ioctl(transform_subdriver_scsi)
 ioctl(scsi_ops)
 write(data)
 close(/dev/hdX)

Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: IDE? IDE-TNG driver

[Andre Hedrick]

ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

Where bool does the subdriver switch.
Just that ioctl's are being blasted and people using are frowned upon.

This was a feature Alan Cox poked me for to try and move away from how
modules are basically an all or nothing grab-all.

Regards,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 17 Aug 2002, Ruth Ivimey-Cook wrote:

> On Sat, 17 Aug 2002, Andre Hedrick wrote:
> 
> >
> >I will hand it to you guys on a silver platter IDE-TNG.
> >
> >Below yields modular chipsets and channel index registration.
> >Selectable IOPS for arch independent Taskfile Transport layers.
> ...
> >You have ide-cd registered on a cdrw and you want to burn a cd?
> >open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
> >open(/dev/sg) and burn baby burn.
> >close(/dev/sg) releases transform_subdriver_scsi
> >open(/dev/hdX) load native atapi transport.
> 
> 
> Andre, I see the thought, but surely this is prine to races and other 
> difficulties.
> 
> Wouldn't it be better to provide an IDE ioctl() that enables the caller to use 
> set the SCSI transport on an open FD, so your sequence becomes:
> 
>  open(/dev/hdX)
>  ioctl(transform_subdriver_scsi)
>  ioctl(scsi_ops)
>  write(data)
>  close(/dev/hdX)
> 
> Ruth
> 
> -- 
> Ruth Ivimey-Cook
> Software engineer and technical writer.
> 
> -
> 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/
> 

Re: IDE? IDE-TNG driver

[Ruth Ivimey-Cook]

On Sat, 17 Aug 2002, Andre Hedrick wrote:
>
>ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

Seems fine to me...

>Where bool does the subdriver switch.
>Just that ioctl's are being blasted and people using are frowned upon.

? so how is cdrecord (or whatever) supposed to do its stuff -- is it ioctl()  
-> fcntl()? If so, I suppose that's ok, but the basic premise still exists,
surely?

>This was a feature Alan Cox poked me for to try and move away from how
>modules are basically an all or nothing grab-all.

I don't think modules are the answer to any of this:
 a) some people want basically module-less kernels
 b) in some environments, you need to be able to select the IO mechanism 
    without the ability to select the module to load.

anyway...

<slightly confused by it all>


Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: IDE? IDE-TNG driver

[Andre Hedrick]

On Sat, 17 Aug 2002, Ruth Ivimey-Cook wrote:

> On Sat, 17 Aug 2002, Andre Hedrick wrote:
> >
> >ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)
> 
> Seems fine to me...
> 
> >Where bool does the subdriver switch.
> >Just that ioctl's are being blasted and people using are frowned upon.
> 
> ? so how is cdrecord (or whatever) supposed to do its stuff -- is it ioctl()  
> -> fcntl()? If so, I suppose that's ok, but the basic premise still exists,
> surely?
> 
> >This was a feature Alan Cox poked me for to try and move away from how
> >modules are basically an all or nothing grab-all.
> 
> I don't think modules are the answer to any of this:
>  a) some people want basically module-less kernels

This is designed to work regardless.

/dev/hdc == ide-cd builtin
insmod ide-scsi

ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

converts /dev/hdc == ide-cd builtin to ide-scsi(add-in-module).

>  b) in some environments, you need to be able to select the IO mechanism 
>     without the ability to select the module to load.

See above, I think it solves the problem.
Once ide-scsi is added to the ide_module link list it is as good as
built-in.

> anyway...
> 
> <slightly confused by it all>

Me too, because I do not know the direction goal so I am doing the very
best I can.  What I really need is an active development team.

Before me:

Mark Lord, Gadi Oxman, Eric Anderson worked well.

ML ide-disk and ide.c global.
GO ide-floppy, ide-tape, ide-scsi
EA ide-cd

Anyways that was long before transport layer w/ all the hardware issues
began to dominate things.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: IDE? IDE-TNG driver

[Erik Andersen]

On Sat Aug 17, 2002 at 04:06:46PM -0700, Andre Hedrick wrote:
> Mark Lord, Gadi Oxman, Eric Anderson worked well.

All these years later, I'm still known to submit 
the occasional patch....

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: IDE? IDE-TNG driver

[Scott Bronson]

On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
>  a) some people want basically module-less kernels

Everyone I've heard advocating a moduleless kernel uses an argument that
boils down to "it's slightly more secure."  Does anybody have a GOOD
reason for not using modules?  Obsolete or embedded hardware arguments
don't count.


>  b) in some environments, you need to be able to select the IO mechanism 
>     without the ability to select the module to load.

If that's the case, won't a kernel parameter suffice?  Can you
elaborate?

    - Scott

Re: IDE? IDE-TNG driver

[Scott Bronson]

> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  Obsolete or embedded hardware arguments
> don't count.

Someone replied off-list saying that initrds are too hard to create.

That's true.  They are.  One day, hopefully that will change.

Any other reasons?

    - Scott

Re: IDE? IDE-TNG driver

[Thomas Molina]

On 17 Aug 2002, Scott Bronson wrote:

> > Everyone I've heard advocating a moduleless kernel uses an argument that
> > boils down to "it's slightly more secure."  Does anybody have a GOOD
> > reason for not using modules?  Obsolete or embedded hardware arguments
> > don't count.
> 
> Someone replied off-list saying that initrds are too hard to create.
> 
> That's true.  They are.  One day, hopefully that will change.
> 
> Any other reasons?

Wouldn't the logic be a lot simpler if kernel developers didn't have to 
worry about whether their module was built in or inserted at some point in 
the future?  All the bits could be assembled and symbols would be resolved 
at compile time.

ICBW but it appears the largest percentage of users have modules inserted 
at boot time, never to be ejected or disturbed.  The modules might as well 
be built in.

I've never really grokked the whole initrd anyway.  What is the point of 
building a kernel minus the bits it needs to actually boot the system?  
That just forces this ludicrous jerry-rigged mess to provide the 
capabilities that should have been built in at compile time.

Of course, we're never going to get away from modules now anyway, so the 
argument is probably moot.  With PCCARD, USB, Firewire, and Hotplug PCI 
there are too many ways to add components not present when the system is 
built on an adhoc basis.  The alternative would be a bloated monstrosity 
with dead code not needed by most people.  I remember my early days of 
Linux and seeing literally dozens of kernels compiled with different 
options, with no clue how to choose the right one for my system.

Re: IDE? IDE-TNG driver

[CaT]

On Sat, Aug 17, 2002 at 08:47:30PM -0700, Scott Bronson wrote:
> > Everyone I've heard advocating a moduleless kernel uses an argument that
> > boils down to "it's slightly more secure."  Does anybody have a GOOD
> > reason for not using modules?  Obsolete or embedded hardware arguments
> > don't count.
> 
> Someone replied off-list saying that initrds are too hard to create.
> 
> That's true.  They are.  One day, hopefully that will change.
> 
> Any other reasons?

Because I shouldn't have to use a feature if I don't need to use a
feature?

I dunno... I've not once heard a decent argument as to why I should
modulerise the ide subsystem, or ext3 or the video drivers and so on.

Where I -do- need to use it though, I do happily use it. One case is to
reset the eepro100 driver so that it works after my computer is brought
out of suspend mode (either RAM or disk).

But why should I -not- make a monolithic kernel when I don't have any
reason to do so? If you can provide me with some decent ones, I'll
happily start...

-- 
   "There was a moo from under the blanket, and I knew it was not a person,
   but a calf."
         - http://www.iol.co.za/index.php?art_id=qw1028795041273B265

Re: IDE? IDE-TNG driver

[David Lang]

A couple things in favor of a monlithic kernel.

there is a slight performance advantage becouse the calls don't
have to be far calls

there is a slight memory advantage becouse you don't have the fraction of
a page of ram lost per module

with a monolithic kernel there's no chance of making a mistake and trying
to use incompatable modules with your kernel (and before you say that this
can be fixed with the kernel build remember that for many people the build
machine is not where the kernel will be run)

David Lang


On 17 Aug 2002, Scott
Bronson wrote:

> Date: 17 Aug 2002 17:28:38 -0700
> From: Scott Bronson <bronson@rinspin.com>
> To: Ruth Ivimey-Cook <Ruth.Ivimey-Cook@ivimey.org>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: IDE?  IDE-TNG driver
>
> On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
> >  a) some people want basically module-less kernels
>
> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  Obsolete or embedded hardware arguments
> don't count.
>
>
> >  b) in some environments, you need to be able to select the IO mechanism
> >     without the ability to select the module to load.
>
> If that's the case, won't a kernel parameter suffice?  Can you
> elaborate?
>
>     - Scott
>
>
>
> -
> 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/
>

Re: IDE? IDE-TNG driver

[Helge Hafting]

Scott Bronson wrote:
> 
> On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
> >  a) some people want basically module-less kernels
> 
> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  

1. "No need".  Doesn't apply to everybody of course, but
   many have enough memory and don't plug in much new stuff.
   Recompiling & booting for the rare occation where you
   bought a new usb device is ok.  

2. A simpler setup.  No /etc/modules.conf to worry about.
   Compiling ALSA into the kernel surely made life easier.
   even more so when also using devfs...

3. Performance.  Compiled-in stuff is always there, and
   on x86 it exists in the kernel's 4M page so no
   TLB loading overhead either.

> Someone replied off-list saying that initrds are too hard to create.
Actually, that isn't an argument for linking everything in.
All you need is the drivers for your root fs and root device.
The rest may still be modular, loaded from /lib/modules on
that root fs.


Helge Hafting

Re: IDE?

[Russell King]

On Sat, Aug 17, 2002 at 01:52:43PM +0200, Matthias Andree wrote:
> Is there a way how the improvements that parts of the stuff have
> received can be rescued somehow?

There were a few bits I submitted that should probably go in - I'll
look at reviving them when I'm less busy and the direction of IDE
stuff has settled down a bit.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: IDE?

[Marc-Christian Petersen]

Hi Linus,

> In article <2444170000.1029531611@flay>,
> Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> > So did Linus get disk corruption or is something else afoot?
> Martin gave up the fight he had to do all the time, so..

I am beside my self with laughing, sorry :P

I really can imagine what are you dreaming of. Like:
"shit, f*ck, why the hell I kicked André Hedrick in the ass
 and why, for heaven's sake, I said jump in the lake to him?!!?"

Sorry, couldn't resist. ;)


-- 
Kind regards
        Marc-Christian Petersen

http://sourceforge.net/projects/wolk

PGP/GnuPG Key: 1024D/569DE2E3DB441A16
Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16
Key available at www.keyserver.net. Encrypted e-mail preferred.

Re: IDE?

[Linus Torvalds]

On Sat, 17 Aug 2002, Marc-Christian Petersen wrote:
> 
> I am beside my self with laughing, sorry :P
> 
> I really can imagine what are you dreaming of. Like:

Actually, you apparently can't.

I'm dreaming of an IDE maintainer that people (including, very much, me)
can work with. I don't know why, but IDE has pretty much since day one
been a fairly problematic area, and has caused a lot more maintainer
headache than the rest of the kernel put together..

There's been one fairly smooth IDE transition (the original transition
from hd.c to ide.c), and calling even that "smooth" is pretty much all
hindsight - at the time people thought it was horribly stupid to not allow
big controversial changes to hd.c, and the resulting code duplication was
considered a disaster.

Right now it looks like Alan is at least for the moment willing to work on
the IDE code, which is obviously great. I just wonder how long he'll stand
it (he's maintained various IDE buglists etc issues for years, so we can
hope).

			Linus

Re: IDE?

[Larry McVoy]

On Fri, Aug 16, 2002 at 04:34:14PM -0700, Linus Torvalds wrote:
> I'm dreaming of an IDE maintainer that people (including, very much, me)
> can work with. I don't know why, but IDE has pretty much since day one
> been a fairly problematic area, and has caused a lot more maintainer
> headache than the rest of the kernel put together..

This may be politically incorrect, but could you (or anyone) provide a 
history of the IDE maintainers to date and why they didn't work out 
and what would need to change to make them work out?  I'm sticking my
nose in where I know nothing but maybe one of them could rise up to
the necessary level if it were spelled out what that level was.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: IDE?

[Linus Torvalds]

On Fri, 16 Aug 2002, Larry McVoy wrote:
> On Fri, Aug 16, 2002 at 04:34:14PM -0700, Linus Torvalds wrote:
> > I'm dreaming of an IDE maintainer that people (including, very much, me)
> > can work with. I don't know why, but IDE has pretty much since day one
> > been a fairly problematic area, and has caused a lot more maintainer
> > headache than the rest of the kernel put together..
> 
> This may be politically incorrect, but could you (or anyone) provide a 
> history of the IDE maintainers to date and why they didn't work out 
> and what would need to change to make them work out?

I actually don't think it's the people as much as it is the ridiculous 
linkages inside ide.c and the hugely complicated rules. The code is messy.

The network drivers have various setups that share the same chipset, but 
there they tend to be individual drivers that just share helper routines. 
Each driver still does their own PCI driver registration etc. In contrast, 
when it comes to IDE, you're supposed to be an IDE driver first, and a PCI 
chipset driver second, and that putting o fthe cart before the horse 
results in problems.

Even something as simple as a PIIX driver (which _should_ just register 
itself as a driver for the piix chipsets) doesn't do that. Instead, we 
have ide-pci.c, which has a list of all the chipsets it knows about, and 
then does initialization and calls the init routines that it knows about. 
That's just incestuous.

And we all know where incest leads. Hereditary insanity.

		Linus

Re: IDE?

[Linus Torvalds]

On Fri, 16 Aug 2002, Linus Torvalds wrote:
> 
> I actually don't think it's the people as much as it is the ridiculous 
> linkages inside ide.c and the hugely complicated rules. The code is messy.

Note: it _is_ the people too, don't get me wrong. But in other areas we 
have people like Al Viro, who can drive grown men to cry (and drink) with 
his not-very-polite postings. And in those areas it hasn't been a huge 
problem, even though some people probably take a valium or two before they 
dare open emails from Al.

So the messiness and interconnectedness of the IDE layer just seems to
bring the people problem to a sharp and ugly point. The absolute lack of
communication skills wrt IDE among the people who have worked on it has
been stunning, and that probably _is_ because the code is so hard to even 
talk about.

		Linus

Re: IDE?

[Alexander Viro]

On Fri, 16 Aug 2002, Linus Torvalds wrote:

> 
> On Fri, 16 Aug 2002, Linus Torvalds wrote:
> > 
> > I actually don't think it's the people as much as it is the ridiculous 
> > linkages inside ide.c and the hugely complicated rules. The code is messy.
> 
> Note: it _is_ the people too, don't get me wrong. But in other areas we 
> have people like Al Viro, who can drive grown men to cry (and drink) with 
> his not-very-polite postings. And in those areas it hasn't been a huge 
> problem, even though some people probably take a valium or two before they 
> dare open emails from Al.
> 
> So the messiness and interconnectedness of the IDE layer just seems to
> bring the people problem to a sharp and ugly point. The absolute lack of
> communication skills wrt IDE among the people who have worked on it has
> been stunning, and that probably _is_ because the code is so hard to even 
> talk about.

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.
	b) review of code structure in existing code.  Doing that.
	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.

When we will have sane structure and sane interfaces, the life will get easier.
Until then full-time maintainership of drivers/ide/* is a one-way ticket to
Bedlam.

Re: IDE?

[Linus Torvalds]

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

Re: IDE?

[Pavel Machek]

Hi

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

Would it be possible to use martin's IDE as starting point for IDE-TNG? Awfull
lot of cleanups went to that code...
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: IDE?

[Alexander Viro]

On Fri, 16 Aug 2002, Linus Torvalds wrote:

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

They are, but there is a buttload of amazingly convoluted C on top of them.
And I'd like to shave _that_ off.  After that we'll be left with real
complexity imposed by hardware - $DEITY witness, there's enough of it to
make the things nasty; no need to further complicate control flow...

Let me put it another way: I feel that a lot of things can be un-obfuscated
by pure equivalent transformations that would treat almost all driver as
block box - making sure that same functions are called with the same
arguments in the same order and not even thinking about possible
reordering/changes inside the "payload" part.

IOW, there is high-level logics that
	(a) is sufficiently separate from the guts
	(b) would be worth IOCCC submission if it passed the size limit
	(c) manages to mask and obfuscate _real_ complexity present in there.

And yes, I'd like that to be gone.  After that... at the very least we will
see what's really going on in there.  I'm rather sceptical about IDE-TNG -
grand rewrites _might_ be necessary at some point, but right now the mess
in the interfaces and in the way top-level code is organized is the worst
problem.  Any work with real guts of the driver is complicated by that and
IMO any decisions on what to do with the guts should wait until we _see_
said guts.

Re: IDE?

[Andries Brouwer]

On Fri, Aug 16, 2002 at 10:32:10PM -0400, Alexander Viro wrote:

> Let me put it another way: I feel that a lot of things can be un-obfuscated
> by pure equivalent transformations that would treat almost all driver as
> block box

Yes.

(But things here are a bit more subtle than for example VFS,
since there are timing restrictions.)

Re: IDE?

[Russell King]

On Fri, Aug 16, 2002 at 06:35:29PM -0700, Linus Torvalds wrote:
> 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.

I think you're being too ""mainstream" orientated" here.  Let's look
at something called PCMCIA.  PCMCIA CF cards.  They're IDE devices
that only do PIO.

The majority of ARM platforms being actively produced today provide a
PCMCIA or CF (_not_ cardbus) socket.  Neither PCI nor Cardbus makes any
sense in these machines.  Why?  Because they're not your average power
hungry desktop box that's always plugged into the mains supply.

I think we're going to have PIO mode IDE around for a fair (ten at
least?) number of years yet.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: IDE?

[Vojtech Pavlik]

On Sat, Aug 17, 2002 at 09:22:39AM +0100, Russell King wrote:

> On Fri, Aug 16, 2002 at 06:35:29PM -0700, Linus Torvalds wrote:
> > 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.
> 
> I think you're being too ""mainstream" orientated" here.  Let's look
> at something called PCMCIA.  PCMCIA CF cards.  They're IDE devices
> that only do PIO.
> 
> The majority of ARM platforms being actively produced today provide a
> PCMCIA or CF (_not_ cardbus) socket.  Neither PCI nor Cardbus makes any
> sense in these machines.  Why?  Because they're not your average power
> hungry desktop box that's always plugged into the mains supply.
> 
> I think we're going to have PIO mode IDE around for a fair (ten at
> least?) number of years yet.

We'll need PIO for control commands anyways, but the thing is that we
won't need to speed optimize PIO and will be able to kill multi-sector
PIO completely probably.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Russell King]

On Sat, Aug 17, 2002 at 11:59:42PM +0200, Vojtech Pavlik wrote:
> We'll need PIO for control commands anyways, but the thing is that we
> won't need to speed optimize PIO and will be able to kill multi-sector
> PIO completely probably.

Well, I'll probably be maintaining multi-sector PIO externally to the
main kernel in that case.  95% of ARM machines have either PIO only or
in the case of those that do have PCI DMA support (netwinders) the
southbridge is soo messed up that DMA is useless on most boxes produced.

Multi-sector PIO is a fundamental requirement that I require.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: IDE?

[Vojtech Pavlik]

On Sun, Aug 18, 2002 at 01:52:18AM +0100, Russell King wrote:

> > We'll need PIO for control commands anyways, but the thing is that we
> > won't need to speed optimize PIO and will be able to kill multi-sector
> > PIO completely probably.
> 
> Well, I'll probably be maintaining multi-sector PIO externally to the
> main kernel in that case.  95% of ARM machines have either PIO only or
> in the case of those that do have PCI DMA support (netwinders) the
> southbridge is soo messed up that DMA is useless on most boxes produced.
> 
> Multi-sector PIO is a fundamental requirement that I require.

Good to know that.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Rogier Wolff]

On Fri, Aug 16, 2002 at 06:35:29PM -0700, Linus Torvalds wrote:
> And yes, by now this all is obviously 2.7.x material.

Linus, 

I sure hope that you're talking about "finishing" your project plan,
and not about "starting it". I would really prefer to have work on
the IDE-TNG started soonish, rather than defered another year or so.

There will be plenty of bugs to be found, which can benefit from a
longer testing-period by people daring enough to try the new and
experimental driver.....

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: IDE?

[Mike Dresser]

>    IDE-TNG would:

As long as we don't have IDE-Voy, or IDE-DS9, this should be good.

Mike

Re: IDE?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Fri, 2002-08-16 18:35:29 -0700, Linus Torvalds <torvalds@transmeta.com>
wrote in message <Pine.LNX.4.44.0208161822130.1674-100000@home.transmeta.com>:
> On Fri, 16 Aug 2002, Alexander Viro wrote:

>     - in particular, it would only bother with PCI (or better) 
>       controllers, and with UDMA-only setups.
[...]
> 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 

That's bad. Then, you're nailed to use old kernels without having
possibilities of recent kernels only because you're working with eg. old
Alphas, PCMCIA-IDE things or so? Bad, bad, badhorribly bad. Even it's
sloooow, there'll always some need for PIO-only controller support...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IDE?

[Andre Hedrick]

One of the issues I am addressing is how to deal w/ VDMA or PIO over
PCI-DMA or FP-DMA issues.  First Party DMA is how things will get done,
and regardless there will still be an need for PIO.

As long as ther transport layer requires it regardless of the wrapper or
pipe it is run down, it shall be around.

Regards,

Andre Hedrick
LAD Storage Consulting Group


On Sat, 17 Aug 2002, Jan-Benedict Glaw wrote:

> On Fri, 2002-08-16 18:35:29 -0700, Linus Torvalds <torvalds@transmeta.com>
> wrote in message <Pine.LNX.4.44.0208161822130.1674-100000@home.transmeta.com>:
> > On Fri, 16 Aug 2002, Alexander Viro wrote:
> 
> >     - in particular, it would only bother with PCI (or better) 
> >       controllers, and with UDMA-only setups.
> [...]
> > 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 
> 
> That's bad. Then, you're nailed to use old kernels without having
> possibilities of recent kernels only because you're working with eg. old
> Alphas, PCMCIA-IDE things or so? Bad, bad, badhorribly bad. Even it's
> sloooow, there'll always some need for PIO-only controller support...
> 
> MfG, JBG
> 
> -- 
> Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
> 	 -- New APT-Proxy written in shell script --
> 	   http://lug-owl.de/~jbglaw/software/ap2/
> 

Re: IDE?

[Anton Altaparmakov]

At 19:16 17/08/02, Jan-Benedict Glaw wrote:
>On Fri, 2002-08-16 18:35:29 -0700, Linus Torvalds <torvalds@transmeta.com>
>wrote in message <Pine.LNX.4.44.0208161822130.1674-100000@home.transmeta.com>:
> > On Fri, 16 Aug 2002, Alexander Viro wrote:
>
> >     - in particular, it would only bother with PCI (or better)
> >       controllers, and with UDMA-only setups.
>[...]
> > 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
>
>That's bad. Then, you're nailed to use old kernels without having
>possibilities of recent kernels only because you're working with eg. old
>Alphas, PCMCIA-IDE things or so? Bad, bad, badhorribly bad. Even it's
>sloooow, there'll always some need for PIO-only controller support...

I don't think it is possible to have DMA only drivers. On DMA 
failure/timeouts/whatever, the current DMA drivers always fall back to PIO 
mode and this is a good thing. Otherwise many transfers would simply fail. 
Dropping PIO mode fallback would mean a lot of IO errors. Any system put 
under stress will at some point fall back to PIO mode (at least judgjing 
from the limited number of systems I have) because it doesn't manage to do 
the DMA transfers in time. That was very visible during the period when 
Andre's new IDE core went into 2.5.something_early and it turned out that 
PIO was broken at that point. For example my VIA box was running just fine 
then in DMA mode but as soon as I put it under stress it blew up due to it 
falling out of DMA and the then broken PIO mode... And VIA686b is 
mainstream hardware...

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: IDE?

[Andre Hedrick]

Anton,

They will become PIO over DMA, and it will become interesting.
But you are correct, we are stuck wit PIO regardless.

Andre Hedrick
LAD Storage Consulting Group

On Sat, 17 Aug 2002, Anton Altaparmakov wrote:

> At 19:16 17/08/02, Jan-Benedict Glaw wrote:
> >On Fri, 2002-08-16 18:35:29 -0700, Linus Torvalds <torvalds@transmeta.com>
> >wrote in message <Pine.LNX.4.44.0208161822130.1674-100000@home.transmeta.com>:
> > > On Fri, 16 Aug 2002, Alexander Viro wrote:
> >
> > >     - in particular, it would only bother with PCI (or better)
> > >       controllers, and with UDMA-only setups.
> >[...]
> > > 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
> >
> >That's bad. Then, you're nailed to use old kernels without having
> >possibilities of recent kernels only because you're working with eg. old
> >Alphas, PCMCIA-IDE things or so? Bad, bad, badhorribly bad. Even it's
> >sloooow, there'll always some need for PIO-only controller support...
> 
> I don't think it is possible to have DMA only drivers. On DMA 
> failure/timeouts/whatever, the current DMA drivers always fall back to PIO 
> mode and this is a good thing. Otherwise many transfers would simply fail. 
> Dropping PIO mode fallback would mean a lot of IO errors. Any system put 
> under stress will at some point fall back to PIO mode (at least judgjing 
> from the limited number of systems I have) because it doesn't manage to do 
> the DMA transfers in time. That was very visible during the period when 
> Andre's new IDE core went into 2.5.something_early and it turned out that 
> PIO was broken at that point. For example my VIA box was running just fine 
> then in DMA mode but as soon as I put it under stress it blew up due to it 
> falling out of DMA and the then broken PIO mode... And VIA686b is 
> mainstream hardware...
> 
> Best regards,
> 
>          Anton
> 
> 
> -- 
>    "I've not lost my mind. It's backed up on tape somewhere." - Unknown
> -- 
> Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
> WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
> 
> -
> 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/
> 

Re: IDE?

[Dana Lacoste]

On Sat, 2002-08-17 at 14:16, Jan-Benedict Glaw wrote:
> That's bad. Then, you're nailed to use old kernels without having
> possibilities of recent kernels only because you're working with eg. old
> Alphas, PCMCIA-IDE things or so? Bad, bad, badhorribly bad. Even it's
> sloooow, there'll always some need for PIO-only controller support...

Correct me if I'm wrong, but isn't this already the case?

Are there not several uses of 2.0.x that are not compatible with
2.2/2.4?  And if 2.0 is working, then why are you worried about
being able to use 3.2?  Why do we need to maintain compatibility
with OLD (not 'low-end' but OLD) hardware if there's an existing
kernel that meets that hardware's needs already?

Dana Lacoste
Ottawa

Re: IDE?

[Tomas Szepe]

> Are there not several uses of 2.0.x that are not compatible with
> 2.2/2.4?  And if 2.0 is working, then why are you worried about
> being able to use 3.2?  Why do we need to maintain compatibility
> with OLD (not 'low-end' but OLD) hardware if there's an existing
> kernel that meets that hardware's needs already?

Because new userspace won't roll with old kernels (reliably|at all).

T.

Re: IDE?

[Alan Cox]

On Mon, 2002-08-19 at 14:57, Dana Lacoste wrote:
> Are there not several uses of 2.0.x that are not compatible with
> 2.2/2.4?  And if 2.0 is working, then why are you worried about
> being able to use 3.2?  Why do we need to maintain compatibility
> with OLD (not 'low-end' but OLD) hardware if there's an existing
> kernel that meets that hardware's needs already?

How about because in many cases only 2.4 has needed features and also
runs better. On my 20Mb 486 running Xfce 2.4 is materially faster than
2.0

Re: IDE?

[Willy Tarreau]

On Mon, Aug 19, 2002 at 09:57:11AM -0400, Dana Lacoste wrote:
> Why do we need to maintain compatibility
> with OLD (not 'low-end' but OLD) hardware if there's an existing
> kernel that meets that hardware's needs already?
 
because we always need new features, even on older hardware. If 2.4 didn't
support my 386sx, I would have had to either port iptables, cramfs, pppoe
and such things to 2.0 (or 2.2), or replace this solid-state, silent box
with a new, noisy and power hungry one. I'm really happy that this box is
still supported and hope it will still run 2.6.

Cheers,
Willy

Re: IDE?

[Thunder from the hill]

Hi,

On Fri, 16 Aug 2002, Linus Torvalds wrote:
>  - phase 2: IDE-TNG.

Couldn't we give it another name? Such as LUI - Linux Unified IDE? 
Whatever? TNG is too much mainstream and sounds just too clumsy...

			Thunder
-- 
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-

Re: IDE?

[Sean Neakums]

commence  Thunder from the hill quotation:

> Hi,
>
> On Fri, 16 Aug 2002, Linus Torvalds wrote:
>>  - phase 2: IDE-TNG.
>
> Couldn't we give it another name? Such as LUI - Linux Unified IDE? 
> Whatever? TNG is too much mainstream and sounds just too clumsy...

Call it IDE-DS9, then.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: IDE?

[Larry McVoy]

> I actually don't think it's the people as much as it is the ridiculous 
> linkages inside ide.c and the hugely complicated rules. The code is messy.

So of all the people you know floating around in "active hacker" state, who
seems like the sort of person who could handle this mess?  If there is no
person, is there a description which is more specific than "wanted: person
who wants thankless abusive non-payed job to clean up what is inherently a
mess"?  

People are pretty amazing and I've found if you spell out exactly what
you are looking for you can sometimes get it.  People tend to step
up to the plate more willingly if they know what is expected of them.
You are the master of getting people to do that, so this is sort of the
blind suggesting a path to the sighted, but this area seems harder than
normal so maybe it can benefit from a more defined description.  Dunno.
Can't hurt.  I hate to see more crap piled on Alan, he's a finite and
useful resource.  Seems like spreading the load around would be good.

Another question: is there any operating system out there which handles
the IDE mess well?  I suppose Windows is as good as it gets, right?  Or
does Solaris/x86 do a good job?  If so, maybe we can get them to donate 
their work to Linux, since they seem to be looking for "we're good guys"
press coverage.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: IDE?

[Alan Cox]

On Sat, 2002-08-17 at 01:09, Larry McVoy wrote:
> > I actually don't think it's the people as much as it is the ridiculous 
> > linkages inside ide.c and the hugely complicated rules. The code is messy.
> 
> So of all the people you know floating around in "active hacker" state, who
> seems like the sort of person who could handle this mess?  If there is no
> person, is there a description which is more specific than "wanted: person
> who wants thankless abusive non-payed job to clean up what is inherently a
> mess"?  

IMHO you need
	-	An understanding of ATA (which is the protocol
		equivalent of object oriented cobol)
	-	The ability to work with vendors (it needs to be someone
		at a company because many vendors won't NDA with 
		individuals even if they are happy with GPL code off 
		their data sheet)
	-	Someone who has taste in code and understands how to
		beat code into shape without breaking it
	-	The ability to deduce the other errata the vendor forgot
		to tell you about or doesn't want to admit exists for 
		fear of US lawsuits (I kid you not)
	-	A good understanding of the block layer and its locking
		especially because IDE has a heirarchy of contention 
		problems:
			two drives one bus
			two channels one DMA engine
			two controllers one I/O at a time
			ISA IRQ sharing locks

Re: IDE?

[Alan Cox]

On Sat, 2002-08-17 at 01:02, Linus Torvalds wrote:
> Even something as simple as a PIIX driver (which _should_ just register 
> itself as a driver for the piix chipsets) doesn't do that. Instead, we 
> have ide-pci.c, which has a list of all the chipsets it knows about, and 
> then does initialization and calls the init routines that it knows about. 
> That's just incestuous.

The pci scan can't go away to get the nasty BIOS ordering crap right.
Andre now has that code as it should be however. The scan loop is
basically no more than

	pci_foreach_device_in_weird_ide_order()
	{
		call probe function(dev)
	}

Which also means we are really really close to hot plug ide controllers.

The probe function->generic pci init->driver->generic->driver-> chain is
still too ugly but its getting better and lives in a struct now

Re: IDE?

[Andries Brouwer]

On Fri, Aug 16, 2002 at 04:36:42PM -0700, Larry McVoy wrote:

> This may be politically incorrect, but could you (or anyone) provide a 
> history of the IDE maintainers to date and why they didn't work out 
> and what would need to change to make them work out?  I'm sticking my
> nose in where I know nothing but maybe one of them could rise up to
> the necessary level if it were spelled out what that level was.

Prehistory: Linus and others.

Since start of 1994: Mark Lord. Everybody was happy until mid 1998 (2.1.111),
when, after a discussion about problems a few people had with DMA
Linus patched linux/drivers/block/Config.in:

-        bool '     Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA
+       # Either the DMA code is buggy or the DMA hardware is unreliable. FIXME.
+        #bool '     Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA

and Mark wrote: "I will not be updating the IDE driver again until the
linux/drivers/block/Config.in file is restored to its pre-111 state."

Since Fall 1998 (2.1.122): Andre Hedrick.

Recent history is known.

(Lots of other people also did useful work on IDE. I will not try to list
names since I would forget some.)

Of course, "IDE maintainer" implies work on the interface with the hardware
and work on the interface with the block I/O subsystem of the kernel.
Some people know all about the hardware, others know much less about
hardware but have good ideas about the driver interface.
There is no reason to force the "IDE maintainer" to be a single person.

Andries

Re: IDE?

[Linus Torvalds]

On Sat, 17 Aug 2002, Andries Brouwer wrote:
> 
> Of course, "IDE maintainer" implies work on the interface with the hardware
> and work on the interface with the block I/O subsystem of the kernel.
> Some people know all about the hardware, others know much less about
> hardware but have good ideas about the driver interface.
> There is no reason to force the "IDE maintainer" to be a single person.

There isn't in theory, but because a minor change to one part will make
other drivers fail subtly, one person has to be the one that holds the bag 
in the end. Because somebody _will_ be the one that everybody looks at 
when something breaks.

That is probably one of the largest reasons for the "IDE disease". The
symptoms of the disease is that people complain about the stuff not
working, and the maintainer eventually getting so fed up with the
complaints that he stops interacting with reality, and starts worrying
about compliance with the documentation instead, hoping that that will fix
everything.

Which would work fine, except a lot of the time the problems aren't due to 
things in the documentation, but simply due to hardware that isn't really 
in spec and needs to have workarounds etc. So once the "this is how it is 
documented, and if it doesn't work your machine is broken" disease starts, 
it's all downhill from there.

I will claim that this happens for a lot of other hardware too, but in
other hardware there often isn't quite as much baggage (people in the end
throw out the core and start on a new one without historical cruft), and
the inter-driver linkages do not exist to _nearly_ the same degree. When a
developer can work with just one chipset, it's still possible to believe
that you can keep up. But when you get blamed for all the different IDE
problems, you crawl into your shell and go away.

This is why I believe that the only sane result in the end is to have
independent drivers that probably end up having a lot of duplication (the
same way hd.c and ide.c started out with a lot of duplication), but where
there truly _can_ be multiple people in charge of their own drivers (and
also clear _whose_ problem it is when one IDE controller driver doesn't
work).

(Some of the infrastructure could be made truly generic, but the generic
part should _only_ be for stuff that is truly hardware-independent, and
simply _cannot_ be impacted by quirks and outright bugs in the hw
implementations. In short, only stuff that can be argued about on a
logical and clear level, and where the rules are made up by us, not by
quirky hardware).

		Linus

Re: IDE?

[Anton Altaparmakov]

On Fri, 16 Aug 2002, Linus Torvalds wrote:
> I'm dreaming of an IDE maintainer that people (including, very much, me)
> can work with. I don't know why, but IDE has pretty much since day one
> been a fairly problematic area, and has caused a lot more maintainer
> headache than the rest of the kernel put together..
> 
> There's been one fairly smooth IDE transition (the original transition
> from hd.c to ide.c), and calling even that "smooth" is pretty much all
> hindsight - at the time people thought it was horribly stupid to not allow
> big controversial changes to hd.c, and the resulting code duplication was
> considered a disaster.
> 
> Right now it looks like Alan is at least for the moment willing to work on
> the IDE code, which is obviously great. I just wonder how long he'll stand
> it (he's maintained various IDE buglists etc issues for years, so we can
> hope).

Linus,

Out of curiosity, who is going to be IDE 2.5 kernel maintainer now?

I am assuming you still maintain that working with Andre is difficult for
you...

Further, I am assuming that Alan is not going to be wanting to be IDE 2.5
maintainer. (I may be completely wrong of course... Alan?)

Jens perhaps? Again I assume he doesn't want the job. (Again, I may be
completely wrong... Jens?)

How about Bartlomiej Zolnierkiewicz as IDE 2.5 maintainer? He seems to be
happy to talk to Andre. And you are perhaps able to work with him well?
He has been submitting bug fixes to Martin and seems to generally know
what he is doing with IDE, certainly a lot better than many of us...

If you can work with him, then it would seem he would be well suited for
the job... Assuming he wants it... Bartlomiej?

Just my curious 2p...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: IDE?

[Anton Altaparmakov]

[Apologies for the repost but I got Alan's address wrong first time
round... silly cut'n'paste error...]

On Fri, 16 Aug 2002, Linus Torvalds wrote:
> I'm dreaming of an IDE maintainer that people (including, very much, me)
> can work with. I don't know why, but IDE has pretty much since day one
> been a fairly problematic area, and has caused a lot more maintainer
> headache than the rest of the kernel put together..
> 
> There's been one fairly smooth IDE transition (the original transition
> from hd.c to ide.c), and calling even that "smooth" is pretty much all
> hindsight - at the time people thought it was horribly stupid to not allow
> big controversial changes to hd.c, and the resulting code duplication was
> considered a disaster.
> 
> Right now it looks like Alan is at least for the moment willing to work on
> the IDE code, which is obviously great. I just wonder how long he'll stand
> it (he's maintained various IDE buglists etc issues for years, so we can
> hope).

Linus,

Out of curiosity, who is going to be IDE 2.5 kernel maintainer now?

I am assuming you still maintain that working with Andre is difficult for
you...

Further, I am assuming that Alan is not going to be wanting to be IDE 2.5
maintainer. (I may be completely wrong of course... Alan?)

Jens perhaps? Again I assume he doesn't want the job. (Again, I may be
completely wrong... Jens?)

How about Bartlomiej Zolnierkiewicz as IDE 2.5 maintainer? He seems to be
happy to talk to Andre. And you are perhaps able to work with him well?
He has been submitting bug fixes to Martin and seems to generally know
what he is doing with IDE, certainly a lot better than many of us...

If you can work with him, then it would seem he would be well suited for
the job... Assuming he wants it... Bartlomiej?

Just my curious 2p...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: IDE?

[Linus Torvalds]

On Sat, 17 Aug 2002, Anton Altaparmakov wrote:
> 
> Out of curiosity, who is going to be IDE 2.5 kernel maintainer now?

Well, as I implied, Alan seems to be not completely unwilling to work on 
it, and unlike me he _can_ interact with Andre most of the time. Possibly 
Jens will do the 2.5.x side, of it (with Alan working on 2.4), but we've 
not talked it through.

I'd like Vojtech to be a bit involved too, he seemed to do some
much-needed cleanups for PIIX4 IDE (now gone, since we couldn't save just
those parts..)

		Linus

Re: IDE?

[Jens Axboe]

On Fri, Aug 16 2002, Linus Torvalds wrote:
> 
> On Sat, 17 Aug 2002, Anton Altaparmakov wrote:
> > 
> > Out of curiosity, who is going to be IDE 2.5 kernel maintainer now?
> 
> Well, as I implied, Alan seems to be not completely unwilling to work on 
> it, and unlike me he _can_ interact with Andre most of the time. Possibly 
> Jens will do the 2.5.x side, of it (with Alan working on 2.4), but we've 
> not talked it through.

I'd never want to be the maintainer, but I do not mind taking care of
2.5 ide in the sense that 2.4-ac (or whatever) gets adapted, split to
digestible pieces (Andre's stuff always appears in big globs) and pushed
upstream.

> I'd like Vojtech to be a bit involved too, he seemed to do some
> much-needed cleanups for PIIX4 IDE (now gone, since we couldn't save just
> those parts..)

Me too. And Bartlomiej too, for that matter.

-- 
Jens Axboe

Re: IDE?

[Alan Cox]

On Sat, 2002-08-17 at 01:10, Linus Torvalds wrote:
> I'd like Vojtech to be a bit involved too, he seemed to do some
> much-needed cleanups for PIIX4 IDE (now gone, since we couldn't save just
> those parts..)

If he does please co-ordinate with me. I've already done a chunk of
cleanup there (and Andre has done a load too). 

I want order to this. That means all the driver cleanup goes into 2.4-ac
(or "2.4-ide" or some suitable branch) first where we can verify we
aren't hitting 2.5 generic bugs and ide corruption is a meaningful
problem report. It means someone (not me) is the appointed 2.5 person
and handles stuff going to 2.5 (I'm happy to identify stuff that tests
ok in 2.4 as candidates). It also means random patches not going past
me.

If we can do it that way I'll do the job. If Linus applies random IDE
"cleanup" patches to his 2.5 tree that don't pass through Jens and me
then I'll just stop listening to 2.5 stuff.

Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
controllers would also be much appreciated. That way we can get good
coverage tests and catch badness immediately

Alan

Re: IDE?

[Anton Altaparmakov]

At 20:56 17/08/02, Alan Cox wrote:
>Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
>controllers would also be much appreciated. That way we can get good
>coverage tests and catch badness immediately

If you tell me the kernel version and patches to apply which you want 
tested, and what options to run cerberus with (never used it before...), I 
have control over a currently idle dual Athlon MP 2000+ with an AMD-768 
(rev 04) IDE controller and 3G of RAM. It has only one HD, a ST340810A 
(ATA-100, 37G) attached.

btw. Is this where I get cerberus from?
         http://sourceforge.net/projects/va-ctcs/

The machine won't be in use for a few more weeks (until I find the time to 
configure all the software and the database server it will be connecting 
to...) so I can do tests during that period.

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: IDE?

[Arnaldo Carvalho de Melo]

Em Sat, Aug 17, 2002 at 11:11:14PM +0100, Anton Altaparmakov escreveu:
> At 20:56 17/08/02, Alan Cox wrote:
> >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> >controllers would also be much appreciated. That way we can get good
> >coverage tests and catch badness immediately

> If you tell me the kernel version and patches to apply which you want 
> tested, and what options to run cerberus with (never used it before...), I 
> have control over a currently idle dual Athlon MP 2000+ with an AMD-768 
> (rev 04) IDE controller and 3G of RAM. It has only one HD, a ST340810A 
> (ATA-100, 37G) attached.

I have a dual p100 with a CMD640 so I'll test 2.4-ac or whatever you name it,
as soon as I get back from vacation (in two weeks) and I get another old disk
for this test machine. It behaves with 2.4 but loses a lot of interrupts with
2.5-MD (haven't tested after Jens got 2.4 forward port into 2.5).

- Arnaldo

Re: IDE?

[John Weber]

Arnaldo Carvalho de Melo wrote:
> Em Sat, Aug 17, 2002 at 11:11:14PM +0100, Anton Altaparmakov escreveu:
> 
>>At 20:56 17/08/02, Alan Cox wrote:
>>
>>>Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
>>>controllers would also be much appreciated. That way we can get good
>>>coverage tests and catch badness immediately
>>
> 
>>If you tell me the kernel version and patches to apply which you want 
>>tested, and what options to run cerberus with (never used it before...), I 
>>have control over a currently idle dual Athlon MP 2000+ with an AMD-768 
>>(rev 04) IDE controller and 3G of RAM. It has only one HD, a ST340810A 
>>(ATA-100, 37G) attached.
> 
> 
> I have a dual p100 with a CMD640 so I'll test 2.4-ac or whatever you name it,
> as soon as I get back from vacation (in two weeks) and I get another old disk
> for this test machine. It behaves with 2.4 but loses a lot of interrupts with
> 2.5-MD (haven't tested after Jens got 2.4 forward port into 2.5).
> 

I have a dual Ppro200 with a PIIX ide chip, and a PIII 866 with a VIA 
686B.  I'll test anything you want on these boxes.

Re: IDE?

[Thomas Molina]

On Sat, 17 Aug 2002, Anton Altaparmakov wrote:

> At 20:56 17/08/02, Alan Cox wrote:
> >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> >controllers would also be much appreciated. That way we can get good
> >coverage tests and catch badness immediately
> 
> If you tell me the kernel version and patches to apply which you want 
> tested, and what options to run cerberus with (never used it before...), I 
> have control over a currently idle dual Athlon MP 2000+ with an AMD-768 
> (rev 04) IDE controller and 3G of RAM. It has only one HD, a ST340810A 
> (ATA-100, 37G) attached.
> 
> btw. Is this where I get cerberus from?
>          http://sourceforge.net/projects/va-ctcs/
> 
> The machine won't be in use for a few more weeks (until I find the time to 
> configure all the software and the database server it will be connecting 
> to...) so I can do tests during that period.

I'm not familiar with Cerebus, but I'm willing to pitch in with any 
testing you feel necessary.  I just finished rebuilding my system with 
removable hard drives, originally to beat against Martin's IDE code.  I 
now have a known good stable system I can do production with as well as a 
dev drive I can restore to pristine in about 15 minutes.  System is an 
Athlon 1.3 GHz on Asus A7V with 384MB RAM.

Is it going to be more desireable to beat on 2.4 IDE or 2.5 IDE?  

Re: IDE?

[Linus Torvalds]

On 17 Aug 2002, Alan Cox wrote:
> 
> If we can do it that way I'll do the job. If Linus applies random IDE
> "cleanup" patches to his 2.5 tree that don't pass through Jens and me
> then I'll just stop listening to 2.5 stuff.

That may work for the low-level driver stuff, but not for things like the
partitioning fixes. Especially as some of that is different in 2.5.x 
relative to 2.4.x.

In other words, I'll clearly apply anything that comes from Al, at the 
very least.

		Linus

Re: IDE?

[Alexander Viro]

On Sat, 17 Aug 2002, Linus Torvalds wrote:

> 
> On 17 Aug 2002, Alan Cox wrote:
> > 
> > If we can do it that way I'll do the job. If Linus applies random IDE
> > "cleanup" patches to his 2.5 tree that don't pass through Jens and me
> > then I'll just stop listening to 2.5 stuff.
> 
> That may work for the low-level driver stuff, but not for things like the
> partitioning fixes. Especially as some of that is different in 2.5.x 
> relative to 2.4.x.
> 
> In other words, I'll clearly apply anything that comes from Al, at the 
> very least.

I'm going to run these patches by Alan first anyway, so...

BTW, most of partitioning patches apply to both branches - it's preliminary
cleanup part that is tricky; some of partitioning stuff is already in Jens
code and the rest will be a matter of not moving add_gendisk()/del_gendisk()
in 2.4 branch and leaving the calls of grok_partitions()/wipe_partitions()
in ide_revalidate() (2.4) while removing them in 2.5.

Cleanup that comes before that stage is common for 2.4 and 2.5, makes sense
in both and will be synced with Alan - if nothing else, to keep PITA for
Jens minimal.

Look at the patches for other drivers - gendisk splitup / removal of
BLKRRPART handling / removal of ad-hackery in open/reread partitions /
removal of grok_partitions() and wipe_partitions() is fairly small
_if_ driver has clean rules for places where it used to register disks.
That's the main trouble with IDE for my current purposes - and fixing it
makes sense for 2.4 as well as for 2.5.

Re: IDE?

[Vojtech Pavlik]

On Fri, Aug 16, 2002 at 05:10:12PM -0700, Linus Torvalds wrote:

> On Sat, 17 Aug 2002, Anton Altaparmakov wrote:
> > 
> > Out of curiosity, who is going to be IDE 2.5 kernel maintainer now?
> 
> Well, as I implied, Alan seems to be not completely unwilling to work on 
> it, and unlike me he _can_ interact with Andre most of the time. Possibly 
> Jens will do the 2.5.x side, of it (with Alan working on 2.4), but we've 
> not talked it through.
> 
> I'd like Vojtech to be a bit involved too, he seemed to do some
> much-needed cleanups for PIIX4 IDE (now gone, since we couldn't save just
> those parts..)

I'll make patches for 2.5 to bring the low-level driver cleanups back.
Not just piix.c - also aec62xx.c and amd74xx.c - the last one was in 2.5
for a LONG time already and I'm not particularly happy it got lost.

If desirable (What's your opinion, Alan?) I can make equivalent patches
for 2.4 as well.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Alan Cox]

On Sun, 2002-08-18 at 12:15, Vojtech Pavlik wrote:
> I'll make patches for 2.5 to bring the low-level driver cleanups back.
> Not just piix.c - also aec62xx.c and amd74xx.c - the last one was in 2.5
> for a LONG time already and I'm not particularly happy it got lost.
> 
> If desirable (What's your opinion, Alan?) I can make equivalent patches
> for 2.4 as well.

Look at 2.4.20-pre2-ac3 before you start doing that. A lot of cleanup
has been done, although there is plenty more left. A starter is to fix
the the ratemask/ratefilter stuff to not use silly while loops on the
aec/amd drivers if you are hacking on those, stick in the static
variables and document anything relevant looking.

Simple stuff first.

Alan

Re: IDE?

[Vojtech Pavlik]

On Sun, Aug 18, 2002 at 01:16:04PM +0100, Alan Cox wrote:
> On Sun, 2002-08-18 at 12:15, Vojtech Pavlik wrote:
> > I'll make patches for 2.5 to bring the low-level driver cleanups back.
> > Not just piix.c - also aec62xx.c and amd74xx.c - the last one was in 2.5
> > for a LONG time already and I'm not particularly happy it got lost.
> > 
> > If desirable (What's your opinion, Alan?) I can make equivalent patches
> > for 2.4 as well.
> 
> Look at 2.4.20-pre2-ac3 before you start doing that. A lot of cleanup
> has been done, although there is plenty more left. A starter is to fix
> the the ratemask/ratefilter stuff to not use silly while loops on the
> aec/amd drivers if you are hacking on those, stick in the static
> variables and document anything relevant looking.
> 
> Simple stuff first.

I have completely rewritten (and very well tested) versions of the amd
and piix pci ide drivers.

I'm now looking through 2.4.20-pre2-ac5 and your version of via82cxxx.c,
and all looks quite good to me, except for some of the indentation
changes which seem to make the code fit into 78 columns at the loss of
readability. Was the file run through indent?

I'm planning to adapt the amd and piix driver to the new framework for
IDE drivers and then send you a patch.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Alan Cox]

On Wed, 2002-08-21 at 11:17, Vojtech Pavlik wrote:
> I have completely rewritten (and very well tested) versions of the amd
> and piix pci ide drivers.

I have completely non-rewritten piix drivers that work extremely well
are now easy to read, commented and have done for a very long time. Why
do I want rewritten ones ?
 
> I'm now looking through 2.4.20-pre2-ac5 and your version of via82cxxx.c,
> and all looks quite good to me, except for some of the indentation
> changes which seem to make the code fit into 78 columns at the loss of
> readability. Was the file run through indent?

Andre may have indented it a bit. I've probably caused a bit of noise in
checking all the static's etc

Re: IDE?

[Vojtech Pavlik]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Wed, Aug 21, 2002 at 02:20:07PM +0100, Alan Cox wrote:
>  
> On Wed, 2002-08-21 at 11:17, Vojtech Pavlik wrote:
> > I have completely rewritten (and very well tested) versions of the amd
> > and piix pci ide drivers.
> 
> I have completely non-rewritten piix drivers that work extremely well
> are now easy to read, commented and have done for a very long time. Why
> do I want rewritten ones ?

Even nicer? Easier to add new devices? Not having switch(deviceid)
everywhere? Don't know. I believe they're better. In any case it's a lot
of good work thrown away, yours or mine. :(

The two drivers in question attached in their form suitable for
2.4-non-ac, you can take a look. If there is a chance to get them into
2.4-ac/2.5, I can change them to fit the kernels as needed.

> > I'm now looking through 2.4.20-pre2-ac5 and your version of via82cxxx.c,
> > and all looks quite good to me, except for some of the indentation
> > changes which seem to make the code fit into 78 columns at the loss of
> > readability. Was the file run through indent?
> 
> Andre may have indented it a bit. I've probably caused a bit of noise in
> checking all the static's etc

It's awful in my opinion, others may differ. Would you mind if I sent
you patch that'd put the indentation back, while keeping all the code as
you have it now? 

-- 
Vojtech Pavlik
SuSE Labs

[-- Attachment #2: piix.c --]
[-- Type: text/plain, Size: 16256 bytes --]

/*
 * Version 1.4
 *
 * Intel PIIX/ICH and Efar Victory66 IDE driver for Linux.
 *
 * Copyright (c) 2000-2002 Vojtech Pavlik
 * Copyright (c) 1998-2000 Andre Hedrick
 * Copyright (c) 1998-1999 Andrzej Krzysztofowicz
 *
 *  Thanks to Daniela Egbert for advice on PIIX bugs.
 */

/*
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation; either version 2 of the License.
 */

#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/blkdev.h>
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/ide.h>
#include <asm/io.h>

#include "ide-timing.h"

#define PIIX_IDETIM0		0x40
#define PIIX_IDETIM1		0x42
#define PIIX_SIDETIM		0x44
#define PIIX_IDESTAT		0x47
#define PIIX_UDMACTL		0x48
#define PIIX_UDMATIM		0x4a
#define PIIX_IDECFG		0x54

#define PIIX_UDMA		0x07
#define PIIX_UDMA_NONE		0x00
#define PIIX_UDMA_33		0x01
#define PIIX_UDMA_66		0x02
#define PIIX_UDMA_100		0x03
#define PIIX_UDMA_133		0x04
#define PIIX_NO_SITRE		0x08	/* Chip doesn't have separate slave timing */
#define PIIX_PINGPONG		0x10	/* Enable ping-pong buffers */
#define PIIX_VICTORY		0x20	/* Efar Victory66 has a different UDMA setup */
#define PIIX_CHECK_REV		0x40	/* May be a buggy revision of PIIX */
#define PIIX_NODMA		0x80	/* Don't do DMA with this chip */

/*
 * Intel IDE chips
 */

static struct piix_ide_chip {
	unsigned short id;
	unsigned char flags;
} piix_ide_chips[] = {
	{ PCI_DEVICE_ID_INTEL_82801DB_9,	PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801DB ICH4 */
	{ PCI_DEVICE_ID_INTEL_82801CA_11,	PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801CA ICH3/ICH3-S */
	{ PCI_DEVICE_ID_INTEL_82801CA_10,	PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801CAM ICH3-M */
	{ PCI_DEVICE_ID_INTEL_82801E_9,		PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801E C-ICH */
	{ PCI_DEVICE_ID_INTEL_82801BA_9,	PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801BA ICH2 */
	{ PCI_DEVICE_ID_INTEL_82801BA_8,	PIIX_UDMA_100 | PIIX_PINGPONG },                    /* Intel 82801BAM ICH2-M */
	{ PCI_DEVICE_ID_INTEL_82801AB_1,	PIIX_UDMA_33  | PIIX_PINGPONG },                    /* Intel 82801AB ICH0 */
	{ PCI_DEVICE_ID_INTEL_82801AA_1,	PIIX_UDMA_66  | PIIX_PINGPONG },                    /* Intel 82801AA ICH */
	{ PCI_DEVICE_ID_INTEL_82372FB_1,	PIIX_UDMA_66 },	                                    /* Intel 82372FB PIIX5 */
	{ PCI_DEVICE_ID_INTEL_82443MX_1,	PIIX_UDMA_33 },                                     /* Intel 82443MX MPIIX4 */
	{ PCI_DEVICE_ID_INTEL_82371AB,		PIIX_UDMA_33 },                                     /* Intel 82371AB/EB PIIX4/PIIX4E */
	{ PCI_DEVICE_ID_INTEL_82371SB_1,	PIIX_UDMA_NONE },                                   /* Intel 82371SB PIIX3 */
	{ PCI_DEVICE_ID_INTEL_82371FB_1,	PIIX_UDMA_NONE | PIIX_NO_SITRE | PIIX_CHECK_REV },  /* Intel 82371FB PIIX */
	{ PCI_DEVICE_ID_EFAR_SLC90E66_1,	PIIX_UDMA_66 | PIIX_VICTORY },                      /* Efar Victory66 */
	{ 0 }
};

static struct piix_ide_chip *piix_config;
static unsigned char piix_enabled;
static unsigned int piix_80w;
static unsigned int piix_clock;

static char *piix_dma[] = { "MWDMA16", "UDMA33", "UDMA66", "UDMA100", "UDMA133" };

/*
 * PIIX/ICH /proc entry.
 */

#ifdef CONFIG_PROC_FS

#include <linux/stat.h>
#include <linux/proc_fs.h>

byte piix_proc;
int piix_base;
static struct pci_dev *bmide_dev;
extern int (*piix_display_info)(char *, char **, off_t, int); /* ide-proc.c */

#define piix_print(format, arg...) p += sprintf(p, format "\n" , ## arg)
#define piix_print_drive(name, format, arg...)\
	p += sprintf(p, name); for (i = 0; i < 4; i++) p += sprintf(p, format, ## arg); p += sprintf(p, "\n");

static int piix_get_info(char *buffer, char **addr, off_t offset, int count)
{
	int speed[4], cycle[4], active[4], recover[4], dmaen[4], uen[4], udma[4], umul;
	struct pci_dev *dev = bmide_dev;
	unsigned int i, u;
	unsigned short c, d, e;
	unsigned char t;
	char *p = buffer;

	piix_print("----------PIIX BusMastering IDE Configuration---------------");

	piix_print("Driver Version:                     1.4");
	piix_print("South Bridge:                       %s", bmide_dev->name);

	pci_read_config_byte(dev, PCI_REVISION_ID, &t);
	piix_print("Revision:                           IDE %#x", t);
	piix_print("Highest DMA rate:                   %s", piix_config->flags & PIIX_NODMA ? "No DMA"
								: piix_dma[piix_config->flags & PIIX_UDMA]);

	piix_print("BM-DMA base:                        %#x", piix_base);
	piix_print("PCI clock:                          %d.%dMHz", piix_clock / 1000, piix_clock / 100 % 10);

	piix_print("-----------------------Primary IDE-------Secondary IDE------");

	pci_read_config_word(dev, PIIX_IDETIM0, &d);
	pci_read_config_word(dev, PIIX_IDETIM1, &e);
	piix_print("Enabled:               %10s%20s", (d & 0x8000) ? "yes" : "no", (e & 0x8000) ? "yes" : "no");

	c = inb(piix_base + 0x02) | (inb(piix_base + 0x0a) << 8);
	piix_print("Simplex only:          %10s%20s", (c & 0x80) ? "yes" : "no", (c & 0x8000) ? "yes" : "no");

	piix_print("Cable Type:            %10s%20s", (piix_80w & 1) ? "80w" : "40w", (piix_80w & 2) ? "80w" : "40w");

	if (!piix_clock)
                return p - buffer;

	piix_print("-------------------drive0----drive1----drive2----drive3-----");

	piix_print_drive("Prefetch+Post: ", "%10s", (((i & 2) ? d : e) & (1 << (2 + ((i & 1) << 2)))) ? "yes" : "no");

	for (i = 0; i < 4; i++) {

		pci_read_config_word(dev, PIIX_IDETIM0 + (i & 2), &d);
		if (~piix_config->flags & PIIX_NO_SITRE)
			pci_read_config_byte(dev, PIIX_SIDETIM, &t);

		umul = 4;
		udma[i] = uen[i] = 0;
		active[i] = 12;
		recover[i] = 18;

		switch (i & 1) {
			case 1: if (~d & 0x10) break;
				if ((~piix_config->flags & PIIX_NO_SITRE) && (d & 0x4000)) {
					active[i]  = 5 - ((t >> (((i & 2) << 1) + 2)) & 3); 
					recover[i] = 4 - ((t >> (((i & 2) << 1) + 0)) & 3); 
					break;
				}

			case 0: if (~d & 0x01) break;
				active[i] =  5 - ((d >> 12) & 3);
				recover[i] = 4 - ((d >> 8) & 3);
		}

		dmaen[i] = (c & ((i & 1) ? 0x40 : 0x20) << ((i & 2) << 2));
		cycle[i] = 1000000 / piix_clock * (active[i] + recover[i]);
		speed[i] = 2 * piix_clock / (active[i] + recover[i]);

		if (!(piix_config->flags & PIIX_UDMA))
			continue;

		pci_read_config_byte(dev, PIIX_UDMACTL, &t);
		uen[i]  = (t & (1 << i)) ? dmaen[i] : 0;

		if (!uen[i])
			continue;

		pci_read_config_word(dev, PIIX_UDMATIM, &e);
		pci_read_config_dword(dev, PIIX_IDECFG, &u);

		if (~piix_config->flags & PIIX_VICTORY) {
			if ((piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_66 && (u & (1 << i))) umul = 2;
			if ((piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_100 && (u & (1 << (i + 12)))) umul = 1;
			udma[i] = (4 - ((e >> (i << 2)) & 3)) * umul;
		} else  udma[i] = (8 - ((e >> (i << 2)) & 7)) * 2;

		speed[i] = 8 * piix_clock / udma[i];
		cycle[i] = 250000 * udma[i] / piix_clock;
	}

	piix_print_drive("Transfer Mode: ", "%10s", dmaen[i] ? (uen[i] ? "UDMA" : "DMA") : "PIO");

	piix_print_drive("Address Setup: ", "%8dns", (1000000 / piix_clock) * 3);
	piix_print_drive("Cmd Active:    ", "%8dns", (1000000 / piix_clock) * 12);
	piix_print_drive("Cmd Recovery:  ", "%8dns", (1000000 / piix_clock) * 18);
	piix_print_drive("Data Active:   ", "%8dns", (1000000 / piix_clock) * active[i]);
	piix_print_drive("Data Recovery: ", "%8dns", (1000000 / piix_clock) * recover[i]);
	piix_print_drive("Cycle Time:    ", "%8dns", cycle[i]);
	piix_print_drive("Transfer Rate: ", "%4d.%dMB/s", speed[i] / 1000, speed[i] / 100 % 10);

	return p - buffer;	/* hoping it is less than 4K... */
}

#endif

/*
 * piix_set_speed() writes timing values to the chipset registers
 */

static void piix_set_speed(struct pci_dev *dev, unsigned char dn, struct ide_timing *timing, int umul)
{
	unsigned short t;
	unsigned char u;
	unsigned int c;

	pci_read_config_word(dev, PIIX_IDETIM0 + (dn & 2), &t);

	switch (dn & 1) {

		case 1: 
			if (timing->cycle > 9) {
				t &= ~0x30;
				break;
			}

			if (~piix_config->flags & PIIX_NO_SITRE) {
				pci_read_config_byte(dev, PIIX_SIDETIM, &u);
				u &= ~(0xf << ((dn & 2) << 1));
				t |= 0x30;
				u |= (4 - FIT(timing->recover, 1, 4)) << ((dn & 2) << 1);
				u |= (5 - FIT(timing->active, 2, 5)) << (((dn & 2) << 1) + 2);
				pci_write_config_byte(dev, PIIX_SIDETIM, u);
				break;
			}

		case 0:
			if ((~dn & 1) && timing->cycle > 9) {
				t &= ~0x03;
				break;
			}

			t &= 0xccff;
			t |= 0x03 << ((dn & 1) << 2);
			t |= (4 - FIT(timing->recover, 1, 4)) << 8;
			t |= (5 - FIT(timing->active, 2, 5)) << 12;
	}

	pci_write_config_word(dev, PIIX_IDETIM0 + (dn & 2), t);

	if (!(piix_config->flags & PIIX_UDMA)) return;

	pci_read_config_byte(dev, PIIX_UDMACTL, &u);
	u &= ~(1 << dn);

	if (timing->udma) {

		u |= 1 << dn;

		pci_read_config_word(dev, PIIX_UDMATIM, &t);

		if (piix_config->flags & PIIX_VICTORY) {
			t &= ~(0x07 << (dn << 2));
			t |= (8 - FIT(timing->udma, 2, 8)) << (dn << 2);
		} else {
			t &= ~(0x03 << (dn << 2));
			t |= (4 - FIT(timing->udma, 2, 4)) << (dn << 2);
		}

		pci_write_config_word(dev, PIIX_UDMATIM, t);

		if ((piix_config->flags & PIIX_UDMA) > PIIX_UDMA_33
			&& ~piix_config->flags & PIIX_VICTORY) {

			pci_read_config_dword(dev, PIIX_IDECFG, &c);
			
			if ((piix_config->flags & PIIX_UDMA) > PIIX_UDMA_66)
				c &= ~(1 << (dn + 12));
			c &= ~(1 << dn);

			switch (umul) {
				case 2: c |= 1 << dn;		break;
				case 4: c |= 1 << (dn + 12);	break;
			}

			pci_write_config_dword(dev, PIIX_IDECFG, c);
		}
	}

	pci_write_config_byte(dev, PIIX_UDMACTL, u);
}

/*
 * piix_set_drive() computes timing values configures the drive and
 * the chipset to a desired transfer mode. It also can be called
 * by upper layers.
 */

static int piix_set_drive(ide_drive_t *drive, unsigned char speed)
{
	ide_drive_t *peer = drive->channel->drives + (~drive->dn & 1);
	struct ide_timing t, p;
	int err, T, UT, umul = 1;

	if (speed != XFER_PIO_SLOW && speed != drive->current_speed)
		if ((err = ide_config_drive_speed(drive, speed)))
			return err;

	if (speed > XFER_UDMA_2 && (piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_66)
		umul = 2;
	if (speed > XFER_UDMA_4 && (piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_100)
		umul = 4;
	
	T = 1000000000 / piix_clock;
	UT = T / umul;

	ide_timing_compute(drive, speed, &t, T, UT);

	if ((piix_config->flags & PIIX_NO_SITRE) && peer->present) {
			ide_timing_compute(peer, peer->current_speed, &p, T, UT);
			if (t.cycle <= 9 && p.cycle <= 9)
				ide_timing_merge(&p, &t, &t, IDE_TIMING_ALL);
	}

	piix_set_speed(drive->channel->pci_dev, drive->dn, &t, umul);

	if (!drive->init_speed)	
		drive->init_speed = speed;
	drive->current_speed = speed;

	return 0;
}

/*
 * piix_tune_drive() is a callback from upper layers for
 * PIO-only tuning.
 */

static void piix_tune_drive(ide_drive_t *drive, unsigned char pio)
{
	if (!((piix_enabled >> drive->channel->unit) & 1))
		return;

	if (pio == 255) {
		piix_set_drive(drive, ide_find_best_mode(drive, XFER_PIO | XFER_EPIO));
		return;
	}

	piix_set_drive(drive, XFER_PIO_0 + min_t(byte, pio, 5));
}

#ifdef CONFIG_BLK_DEV_IDEDMA

/*
 * piix_dmaproc() is a callback from upper layers that can do
 * a lot, but we use it for DMA/PIO tuning only, delegating everything
 * else to the default ide_dmaproc().
 */

int piix_dmaproc(ide_dma_action_t func, struct ide_device *drive, struct request *rq)
{

	if (func == ide_dma_check) {

		short w80 = drive->channel->udma_four;

		short speed = ide_find_best_mode(drive,
			XFER_PIO | XFER_EPIO | 
			(piix_config->flags & PIIX_NODMA ? 0 : (XFER_SWDMA | XFER_MWDMA |
			(piix_config->flags & PIIX_UDMA ? XFER_UDMA : 0) |
			(w80 && (piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_66 ? XFER_UDMA_66 : 0) |
			(w80 && (piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_100 ? XFER_UDMA_100 : 0) |
			(w80 && (piix_config->flags & PIIX_UDMA) >= PIIX_UDMA_133 ? XFER_UDMA_133 : 0))));

		piix_set_drive(drive, speed);

		func = (drive->channel->autodma && (speed & XFER_MODE) != XFER_PIO)
			? ide_dma_on : ide_dma_off_quietly;

	}

	return ide_dmaproc(func, drive, rq);
}

#endif /* CONFIG_BLK_DEV_IDEDMA */

/*
 * The initialization callback. Here we determine the IDE chip type
 * and initialize its drive independent registers.
 */

unsigned int __init pci_init_piix(struct pci_dev *dev, const char *name)
{
	unsigned int u;
	unsigned short w;
	unsigned char t;
	int i;

/*
 * Find out which Intel IDE this is.
 */

	for (piix_config = piix_ide_chips; piix_config->id != 0; ++piix_config)
		if (dev->device == piix_config->id)
			break;

	if (!piix_config->id) {
		printk(KERN_WARNING "PIIX: Unknown PIIX/ICH chip %#x, disabling DMA.\n", dev->device);
		return -ENODEV;
	}

/*
 * Check for possibly broken DMA configs.
 */

	{
		struct pci_dev *orion = NULL;

		if (piix_config->flags & PIIX_CHECK_REV) {
			pci_read_config_byte(dev, PCI_REVISION_ID, &t);
			if (t < 2) {
				printk(KERN_INFO "PIIX: Found buggy old PIIX rev %#x, disabling DMA\n", t);
				piix_config->flags |= PIIX_NODMA;
			}
		}

		if ((orion = pci_find_device(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454GX, NULL))) {
			pci_read_config_byte(orion, PCI_REVISION_ID, &t);
			if (t < 4) {
				printk(KERN_INFO "PIIX: Found buggy 82454GX Orion bridge rev %#x, disabling DMA\n", t);
				piix_config->flags |= PIIX_NODMA;
			}
		}
	}

/*
 * Check 80-wire cable presence.
 */

	switch (piix_config->flags & PIIX_UDMA) {

		case PIIX_UDMA_66:
			if (piix_config->flags && PIIX_VICTORY) {
				pci_read_config_byte(dev, PIIX_IDESTAT, &t);
				piix_80w = ((t & 2) ? 1 : 0) | ((t & 1) ? 2 : 0);
				break;
			}

		case PIIX_UDMA_100:
		case PIIX_UDMA_133:
			pci_read_config_dword(dev, PIIX_IDECFG, &u);
			piix_80w = ((u & 0x30) ? 1 : 0) | ((u & 0xc0) ? 2 : 0);
			break;
	}

/*
 * Enable ping-pong buffers where applicable.
 */

	if (piix_config->flags & PIIX_PINGPONG) {
		pci_read_config_dword(dev, PIIX_IDECFG, &u);
		u |= 0x400; 
		pci_write_config_dword(dev, PIIX_IDECFG, u);
	}

/*
 * Detect enabled interfaces, enable slave separate timing if possible.
 */

	for (i = 0; i < 2; i++) {
		pci_read_config_word(dev, PIIX_IDETIM0 + (i << 1), &w);
		piix_enabled |= (w & 0x8000) ? (1 << i) : 0;
		w &= 0x8c00;
		if (~piix_config->flags & PIIX_NO_SITRE) w |= 0x4000;
		w |= 0x44;
		pci_write_config_word(dev, PIIX_IDETIM0 + (i << 1), w);
	}

/*
 * Determine the system bus clock.
 */

	piix_clock = system_bus_speed * 1000;

	switch (piix_clock) {
		case 33000: piix_clock = 33333; break;
		case 37000: piix_clock = 37500; break;
		case 41000: piix_clock = 41666; break;
	}

	if (piix_clock < 20000 || piix_clock > 50000) {
		printk(KERN_WARNING "PIIX: User given PCI clock speed impossible (%d), using 33 MHz instead.\n", piix_clock);
		printk(KERN_WARNING "PIIX: Use ide0=ata66 if you want to assume 80-wire cable\n");
		piix_clock = 33333;
	}

/*
 * Print the boot message.
 */

	printk(KERN_INFO "PIIX: %s %s controller on pci%s\n",
		dev->name, piix_dma[piix_config->flags & PIIX_UDMA], dev->slot_name);

/*
 * Register /proc/ide/piix entry
 */

#ifdef CONFIG_PROC_FS
	if (!piix_proc) {
		piix_base = pci_resource_start(dev, 4);
		bmide_dev = dev;
		piix_display_info = &piix_get_info;
		piix_proc = 1;
	}
#endif

	return 0;
}

unsigned int __init ata66_piix(ide_hwif_t *hwif)
{
	return ((piix_enabled & piix_80w) >> hwif->unit) & 1;
}

void __init ide_init_piix(ide_hwif_t *hwif)
{
	int i;

	hwif->tuneproc = &piix_tune_drive;
	hwif->speedproc = &piix_set_drive;
	hwif->autodma = 0;
	hwif->io_32bit = 1;
	hwif->unmask = 1;
	for (i = 0; i < 2; i++) {
		hwif->drives[i].autotune = 1;
		hwif->drives[i].dn = hwif->unit * 2 + i;
	}

#ifdef CONFIG_BLK_DEV_IDEDMA
	if (hwif->dma_base) {
		hwif->highmem = 1;
		hwif->udma = piix_dmaproc;
#ifdef CONFIG_IDEDMA_AUTO
		if (!noautodma)
			hwif->autodma = 1;
#endif
	}
#endif /* CONFIG_BLK_DEV_IDEDMA */
}

/*
 * We allow the BM-DMA driver only work on enabled interfaces,
 * and only if DMA is safe with the chip and bridge.
 */

void __init ide_dmacapable_piix(ide_hwif_t *hwif, unsigned long dmabase)
{
	if (((piix_enabled >> hwif->unit) & 1)
		&& !(piix_config->flags & PIIX_NODMA))
			ide_setup_dma(hwif, dmabase, 8);
}

[-- Attachment #3: amd74xx.c --]
[-- Type: text/plain, Size: 13027 bytes --]

/*
 * Version 2.9
 *
 * AMD 755/756/766/8111 and nVidia nForce IDE driver for Linux.
 * 
 * Copyright (c) 2000-2002 Vojtech Pavlik
 * Copyright (c) 1999-2000 Andre Hedrick
 *
 */

/*
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/blkdev.h>
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/ide.h>
#include <asm/io.h>

#include "ide-timing.h"

#define AMD_IDE_ENABLE		(0x00 + amd_config->base)
#define AMD_IDE_CONFIG		(0x01 + amd_config->base)
#define AMD_CABLE_DETECT	(0x02 + amd_config->base)
#define AMD_DRIVE_TIMING	(0x08 + amd_config->base)
#define AMD_8BIT_TIMING		(0x0e + amd_config->base)
#define AMD_ADDRESS_SETUP	(0x0c + amd_config->base)
#define AMD_UDMA_TIMING		(0x10 + amd_config->base)

#define AMD_UDMA		0x07
#define AMD_UDMA_33		0x01
#define AMD_UDMA_66		0x02
#define AMD_UDMA_100		0x03
#define AMD_BAD_SWDMA		0x08
#define AMD_BAD_FIFO		0x10

/*
 * AMD SouthBridge chips.
 */

static struct amd_ide_chip {
	unsigned short id;
	unsigned char rev;
	unsigned int base;
	unsigned char flags;
} amd_ide_chips[] = {
	{ PCI_DEVICE_ID_AMD_8111_IDE,  0x00, 0x40, AMD_UDMA_100 },			/* AMD-8111 */
	{ PCI_DEVICE_ID_AMD_OPUS_7441, 0x00, 0x40, AMD_UDMA_100 },			/* AMD-768 Opus */
	{ PCI_DEVICE_ID_AMD_VIPER_7411, 0x00, 0x40, AMD_UDMA_100 | AMD_BAD_FIFO },	/* AMD-766 Viper */
	{ PCI_DEVICE_ID_AMD_VIPER_7409, 0x07, 0x40, AMD_UDMA_66 },			/* AMD-756/c4+ Viper */
	{ PCI_DEVICE_ID_AMD_VIPER_7409, 0x00, 0x40, AMD_UDMA_66 | AMD_BAD_SWDMA },	/* AMD-756 Viper */
	{ PCI_DEVICE_ID_AMD_COBRA_7401, 0x00, 0x40, AMD_UDMA_33 | AMD_BAD_SWDMA },	/* AMD-755 Cobra */
	{ PCI_DEVICE_ID_NVIDIA_NFORCE_IDE, 0x00, 0x50, AMD_UDMA_100 },			/* nVidia nForce */
	{ 0 }
};

static struct amd_ide_chip *amd_config;
static unsigned char amd_enabled;
static unsigned int amd_80w;
static unsigned int amd_clock;

static unsigned char amd_cyc2udma[] = { 6, 6, 5, 4, 0, 1, 1, 2, 2, 3, 3 };
static unsigned char amd_udma2cyc[] = { 4, 6, 8, 10, 3, 2, 1, 1 };
static char *amd_dma[] = { "MWDMA16", "UDMA33", "UDMA66", "UDMA100" };

/*
 * AMD /proc entry.
 */

#ifdef CONFIG_PROC_FS

#include <linux/stat.h>
#include <linux/proc_fs.h>

byte amd74xx_proc;
int amd_base;
static struct pci_dev *bmide_dev;
extern int (*amd74xx_display_info)(char *, char **, off_t, int); /* ide-proc.c */

#define amd_print(format, arg...) p += sprintf(p, format "\n" , ## arg)
#define amd_print_drive(name, format, arg...)\
	p += sprintf(p, name); for (i = 0; i < 4; i++) p += sprintf(p, format, ## arg); p += sprintf(p, "\n");

static int amd_get_info(char *buffer, char **addr, off_t offset, int count)
{
	int speed[4], cycle[4], setup[4], active[4], recover[4], den[4],
		 uen[4], udma[4], active8b[4], recover8b[4];
	struct pci_dev *dev = bmide_dev;
	unsigned int v, u, i;
	unsigned short c, w;
	unsigned char t;
	char *p = buffer;

	amd_print("----------AMD BusMastering IDE Configuration----------------");

	amd_print("Driver Version:                     2.9");
	amd_print("South Bridge:                       %s", bmide_dev->name);

	pci_read_config_byte(dev, PCI_REVISION_ID, &t);
	amd_print("Revision:                           IDE %#x", t);
	amd_print("Highest DMA rate:                   %s", amd_dma[amd_config->flags & AMD_UDMA]);

	amd_print("BM-DMA base:                        %#x", amd_base);
	amd_print("PCI clock:                          %d.%dMHz", amd_clock / 1000, amd_clock / 100 % 10);
	
	amd_print("-----------------------Primary IDE-------Secondary IDE------");

	pci_read_config_byte(dev, AMD_IDE_CONFIG, &t);
	amd_print("Prefetch Buffer:       %10s%20s", (t & 0x80) ? "yes" : "no", (t & 0x20) ? "yes" : "no");
	amd_print("Post Write Buffer:     %10s%20s", (t & 0x40) ? "yes" : "no", (t & 0x10) ? "yes" : "no");

	pci_read_config_byte(dev, AMD_IDE_ENABLE, &t);
	amd_print("Enabled:               %10s%20s", (t & 0x02) ? "yes" : "no", (t & 0x01) ? "yes" : "no");

	c = inb(amd_base + 0x02) | (inb(amd_base + 0x0a) << 8);
	amd_print("Simplex only:          %10s%20s", (c & 0x80) ? "yes" : "no", (c & 0x8000) ? "yes" : "no");

	amd_print("Cable Type:            %10s%20s", (amd_80w & 1) ? "80w" : "40w", (amd_80w & 2) ? "80w" : "40w");

	if (!amd_clock)
                return p - buffer;

	amd_print("-------------------drive0----drive1----drive2----drive3-----");

	pci_read_config_byte(dev, AMD_ADDRESS_SETUP, &t);
	pci_read_config_dword(dev, AMD_DRIVE_TIMING, &v);
	pci_read_config_word(dev, AMD_8BIT_TIMING, &w);
	pci_read_config_dword(dev, AMD_UDMA_TIMING, &u);

	for (i = 0; i < 4; i++) {
		setup[i]     = ((t >> ((3 - i) << 1)) & 0x3) + 1;
		recover8b[i] = ((w >> ((1 - (i >> 1)) << 3)) & 0xf) + 1;
		active8b[i]  = ((w >> (((1 - (i >> 1)) << 3) + 4)) & 0xf) + 1;
		active[i]    = ((v >> (((3 - i) << 3) + 4)) & 0xf) + 1;
		recover[i]   = ((v >> ((3 - i) << 3)) & 0xf) + 1;

		udma[i] = amd_udma2cyc[((u >> ((3 - i) << 3)) & 0x7)];
		uen[i]  = ((u >> ((3 - i) << 3)) & 0x40) ? 1 : 0;
		den[i]  = (c & ((i & 1) ? 0x40 : 0x20) << ((i & 2) << 2));

		if (den[i] && uen[i] && udma[i] == 1) {
			speed[i] = amd_clock * 3;
			cycle[i] = 666666 / amd_clock;
			continue;
		}

		speed[i] = 4 * amd_clock / ((den[i] && uen[i]) ? udma[i] : (active[i] + recover[i]) * 2);
		cycle[i] = 1000000 * ((den[i] && uen[i]) ? udma[i] : (active[i] + recover[i]) * 2) / amd_clock / 2;
	}

	amd_print_drive("Transfer Mode: ", "%10s", den[i] ? (uen[i] ? "UDMA" : "DMA") : "PIO");

	amd_print_drive("Address Setup: ", "%8dns", 1000000 * setup[i] / amd_clock);
	amd_print_drive("Cmd Active:    ", "%8dns", 1000000 * active8b[i] / amd_clock);
	amd_print_drive("Cmd Recovery:  ", "%8dns", 1000000 * recover8b[i] / amd_clock);
	amd_print_drive("Data Active:   ", "%8dns", 1000000 * active[i] / amd_clock);
	amd_print_drive("Data Recovery: ", "%8dns", 1000000 * recover[i] / amd_clock);
	amd_print_drive("Cycle Time:    ", "%8dns", cycle[i]);
	amd_print_drive("Transfer Rate: ", "%4d.%dMB/s", speed[i] / 1000, speed[i] / 100 % 10);

	return p - buffer;	/* hoping it is less than 4K... */
}

#endif

/*
 * amd_set_speed() writes timing values to the chipset registers
 */

static void amd_set_speed(struct pci_dev *dev, unsigned char dn, struct ide_timing *timing)
{
	unsigned char t;

	pci_read_config_byte(dev, AMD_ADDRESS_SETUP, &t);
	t = (t & ~(3 << ((3 - dn) << 1))) | ((FIT(timing->setup, 1, 4) - 1) << ((3 - dn) << 1));
	pci_write_config_byte(dev, AMD_ADDRESS_SETUP, t);

	pci_write_config_byte(dev, AMD_8BIT_TIMING + (1 - (dn >> 1)),
		((FIT(timing->act8b, 1, 16) - 1) << 4) | (FIT(timing->rec8b, 1, 16) - 1));

	pci_write_config_byte(dev, AMD_DRIVE_TIMING + (3 - dn),
		((FIT(timing->active, 1, 16) - 1) << 4) | (FIT(timing->recover, 1, 16) - 1));

	switch (amd_config->flags & AMD_UDMA) {
		case AMD_UDMA_33:  t = timing->udma ? (0xc0 | (FIT(timing->udma, 2, 5) - 2)) : 0x03; break;
		case AMD_UDMA_66:  t = timing->udma ? (0xc0 | amd_cyc2udma[FIT(timing->udma, 2, 10)]) : 0x03; break;
		case AMD_UDMA_100: t = timing->udma ? (0xc0 | amd_cyc2udma[FIT(timing->udma, 1, 10)]) : 0x03; break;
		default: return;
	}

	pci_write_config_byte(dev, AMD_UDMA_TIMING + (3 - dn), t);
}

/*
 * amd_set_drive() computes timing values configures the drive and
 * the chipset to a desired transfer mode. It also can be called
 * by upper layers.
 */

static int amd_set_drive(ide_drive_t *drive, unsigned char speed)
{
	ide_drive_t *peer = HWIF(drive)->drives + (~drive->dn & 1);
	struct ide_timing t, p;
	int T, UT;

	if (speed != XFER_PIO_SLOW && speed != drive->current_speed)
		if (ide_config_drive_speed(drive, speed))
			printk(KERN_WARNING "ide%d: Drive %d didn't accept speed setting. Oh, well.\n",
				drive->dn >> 1, drive->dn & 1);

	T = 1000000000 / amd_clock;
	UT = T / min_t(int, max_t(int, amd_config->flags & AMD_UDMA, 1), 2);

	ide_timing_compute(drive, speed, &t, T, UT);

	if (peer->present) {
		ide_timing_compute(peer, peer->current_speed, &p, T, UT);
		ide_timing_merge(&p, &t, &t, IDE_TIMING_8BIT);
	}

	if (speed == XFER_UDMA_5 && amd_clock <= 33333) t.udma = 1;

	amd_set_speed(HWIF(drive)->pci_dev, drive->dn, &t);

	if (!drive->init_speed)	
		drive->init_speed = speed;
	drive->current_speed = speed;

	return 0;
}

/*
 * amd74xx_tune_drive() is a callback from upper layers for
 * PIO-only tuning.
 */

static void amd74xx_tune_drive(ide_drive_t *drive, unsigned char pio)
{
	if (!((amd_enabled >> HWIF(drive)->channel) & 1))
		return;

	if (pio == 255) {
		amd_set_drive(drive, ide_find_best_mode(drive, XFER_PIO | XFER_EPIO));
		return;
	}

	amd_set_drive(drive, XFER_PIO_0 + min_t(byte, pio, 5));
}

#ifdef CONFIG_BLK_DEV_IDEDMA

/*
 * amd74xx_dmaproc() is a callback from upper layers that can do
 * a lot, but we use it for DMA/PIO tuning only, delegating everything
 * else to the default ide_dmaproc().
 */

int amd74xx_dmaproc(ide_dma_action_t func, ide_drive_t *drive)
{

	if (func == ide_dma_check) {

		short w80 = HWIF(drive)->udma_four;

		short speed = ide_find_best_mode(drive,
			XFER_PIO | XFER_EPIO | XFER_MWDMA | XFER_UDMA |
			((amd_config->flags & AMD_BAD_SWDMA) ? 0 : XFER_SWDMA) |
			(w80 && (amd_config->flags & AMD_UDMA) >= AMD_UDMA_66 ? XFER_UDMA_66 : 0) |
			(w80 && (amd_config->flags & AMD_UDMA) >= AMD_UDMA_100 ? XFER_UDMA_100 : 0));

		amd_set_drive(drive, speed);

		func = (HWIF(drive)->autodma && (speed & XFER_MODE) != XFER_PIO)
			? ide_dma_on : ide_dma_off_quietly;
	}

	return ide_dmaproc(func, drive);
}

#endif /* CONFIG_BLK_DEV_IDEDMA */

/*
 * The initialization callback. Here we determine the IDE chip type
 * and initialize its drive independent registers.
 */

unsigned int __init pci_init_amd74xx(struct pci_dev *dev, const char *name)
{
	unsigned char t;
	unsigned int u;
	int i;

/*
 * Find out what AMD IDE is this.
 */

	for (amd_config = amd_ide_chips; amd_config->id; amd_config++) {
			pci_read_config_byte(dev, PCI_REVISION_ID, &t);
			if (dev->device == amd_config->id && t >= amd_config->rev)
				break;
		}

	if (!amd_config->id) {
		printk(KERN_WARNING "AMD_IDE: Unknown AMD IDE Chip %#x, disabling DMA.\n", dev->device);
		return -ENODEV;
	}

/*
 * Check 80-wire cable presence.
 */

	switch (amd_config->flags & AMD_UDMA) {

		case AMD_UDMA_100:
			pci_read_config_byte(dev, AMD_CABLE_DETECT, &t);
			amd_80w = ((u & 0x3) ? 1 : 0) | ((u & 0xc) ? 2 : 0);
			for (i = 24; i >= 0; i -= 8)
				if (((u >> i) & 4) && !(amd_80w & (1 << (1 - (i >> 4))))) {
					printk(KERN_WARNING "AMD_IDE: Bios didn't set cable bits corectly. Enabling workaround.\n");
					amd_80w |= (1 << (1 - (i >> 4)));
				}
			break;

		case AMD_UDMA_66:
			pci_read_config_dword(dev, AMD_UDMA_TIMING, &u);
			for (i = 24; i >= 0; i -= 8)
				if ((u >> i) & 4)
					amd_80w |= (1 << (1 - (i >> 4)));
			break;
	}

	pci_read_config_dword(dev, AMD_IDE_ENABLE, &u);
	amd_enabled = ((u & 1) ? 2 : 0) | ((u & 2) ? 1 : 0);

/*
 * Take care of prefetch & postwrite.
 */

	pci_read_config_byte(dev, AMD_IDE_CONFIG, &t);
	pci_write_config_byte(dev, AMD_IDE_CONFIG,
		(amd_config->flags & AMD_BAD_FIFO) ? (t & 0x0f) : (t | 0xf0));

/*
 * Determine the system bus clock.
 */

	amd_clock = system_bus_speed * 1000;

	switch (amd_clock) {
		case 33000: amd_clock = 33333; break;
		case 37000: amd_clock = 37500; break;
		case 41000: amd_clock = 41666; break;
	}

	if (amd_clock < 20000 || amd_clock > 50000) {
		printk(KERN_WARNING "AMD_IDE: User given PCI clock speed impossible (%d), using 33 MHz instead.\n", amd_clock);
		printk(KERN_WARNING "AMD_IDE: Use ide0=ata66 if you want to assume 80-wire cable\n");
		amd_clock = 33333;
	}

/*
 * Print the boot message.
 */

	pci_read_config_byte(dev, PCI_REVISION_ID, &t);
	printk(KERN_INFO "AMD_IDE: %s (rev %02x) %s controller on pci%s\n",
		dev->name, t, amd_dma[amd_config->flags & AMD_UDMA], dev->slot_name);

/*
 * Register /proc/ide/amd74xx entry
 */

#ifdef CONFIG_PROC_FS
	if (!amd74xx_proc) {
		amd_base = pci_resource_start(dev, 4);
		bmide_dev = dev;
		amd74xx_display_info = &amd_get_info;
		amd74xx_proc = 1;
	}
#endif

	return 0;
}

unsigned int __init ata66_amd74xx(ide_hwif_t *hwif)
{
	return ((amd_enabled & amd_80w) >> hwif->channel) & 1;
}

void __init ide_init_amd74xx(ide_hwif_t *hwif)
{
	int i;

	hwif->tuneproc = &amd74xx_tune_drive;
	hwif->speedproc = &amd_set_drive;
	hwif->autodma = 0;

	for (i = 0; i < 2; i++) {
		hwif->drives[i].io_32bit = 1;
		hwif->drives[i].unmask = 1;
		hwif->drives[i].autotune = 1;
		hwif->drives[i].dn = hwif->channel * 2 + i;
	}

#ifdef CONFIG_BLK_DEV_IDEDMA
	if (hwif->dma_base) {
		hwif->highmem = 1;
		hwif->dmaproc = &amd74xx_dmaproc;
#ifdef CONFIG_IDEDMA_AUTO
		if (!noautodma)
			hwif->autodma = 1;
#endif
	}
#endif /* CONFIG_BLK_DEV_IDEDMA */
}

/*
 * We allow the BM-DMA driver only work on enabled interfaces.
 */

void __init ide_dmacapable_amd74xx(ide_hwif_t *hwif, unsigned long dmabase)
{
	if ((amd_enabled >> hwif->channel) & 1)
		ide_setup_dma(hwif, dmabase, 8);
}

Re: IDE?

[Alan Cox]

On Wed, 2002-08-21 at 14:27, Vojtech Pavlik wrote:
> Even nicer? Easier to add new devices? Not having switch(deviceid)
> everywhere? Don't know. I believe they're better. In any case it's a lot
> of good work thrown away, yours or mine. :(

I don't mind a few deviceid switches. I don't find them annoying and
I'll take the stability of using known good code with the daft bits like
the rate filter while loop fixed over the unknowns of changing the code.

Once its in 2.4 and 2.5 and it works then I'm all ears, because at that
point we can actively quantify and test for regressions

Re: IDE?

[Vojtech Pavlik]

On Wed, Aug 21, 2002 at 03:06:18PM +0100, Alan Cox wrote:

> On Wed, 2002-08-21 at 14:27, Vojtech Pavlik wrote:
> > Even nicer? Easier to add new devices? Not having switch(deviceid)
> > everywhere? Don't know. I believe they're better. In any case it's a lot
> > of good work thrown away, yours or mine. :(
> 
> I don't mind a few deviceid switches. I don't find them annoying and
> I'll take the stability of using known good code with the daft bits like
> the rate filter while loop fixed over the unknowns of changing the code.
> 
> Once its in 2.4 and 2.5 and it works then I'm all ears, because at that
> point we can actively quantify and test for regressions

I can wait. I've done the rewrite back in 2000, so a couple more months ...
Also, I don't necessarily push it into 2.4. However, if you want to keep
a common IDE base in both, there is no other way.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Rik van Riel]

On Sat, 17 Aug 2002, Marc-Christian Petersen wrote:
> > In article <2444170000.1029531611@flay>,
> > Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> > > So did Linus get disk corruption or is something else afoot?
> > Martin gave up the fight he had to do all the time, so..
>
> I am beside my self with laughing, sorry :P

Having thrown away months and months of hard work, or
giving up on months of hard work is NOT FUN.

I'm thankful Martin tried to make the IDE layer better.

His method of removing things to "add a better implementation
later" may not have worked out in the end, but I'm thankful
he tried.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: IDE?

[Andrew Morton]

Rik van Riel wrote:
> 
> On Sat, 17 Aug 2002, Marc-Christian Petersen wrote:
> > > In article <2444170000.1029531611@flay>,
> > > Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> > > > So did Linus get disk corruption or is something else afoot?
> > > Martin gave up the fight he had to do all the time, so..
> >
> > I am beside my self with laughing, sorry :P
> 
> Having thrown away months and months of hard work, or
> giving up on months of hard work is NOT FUN.
> 
> I'm thankful Martin tried to make the IDE layer better.
> 
> His method of removing things to "add a better implementation
> later" may not have worked out in the end, but I'm thankful
> he tried.
> 

Yes.   Martin starkly demonstrated how much work is needed in
there, and how much cruft has accumulated.  That is valuable.

And I take back my bugreport regarding failure to read the final
eight sectors of my 80 gig maxtors on HPT374.  Linus' current
tree has the same failure.

(gdb) bt
#0  __lock_page (page=0xc108141c) at /usr/src/25/include/asm/bitops.h:136
#1  0xc012d313 in lock_page (page=0xc3ff48c0) at filemap.c:710
#2  0xc012e561 in read_cache_page (mapping=0xc2f6d3c4, index=7, filler=0xc0143dc0 <blkdev_readpage>, data=0x0)
    at filemap.c:1765
#3  0xc016488e in read_dev_sector (bdev=0xc2f11f60, n=63, p=0xc3fdbe38) at check.c:458
#4  0xc0164a3b in parse_extended (state=0xc2f02000, bdev=0xc2f11f60, first_sector=63, first_size=48243132)
    at msdos.c:106
#5  0xc0164d7f in msdos_partition (state=0xc2f02000, bdev=0xc2f11f60) at msdos.c:433
#6  0xc01646a6 in check_partition (hd=0xc2fb73c0, bdev=0xc2f11f60) at check.c:288
#7  0xc0164840 in grok_partitions (dev={value = 8448}, size=160086528) at check.c:448
#8  0xc01647b6 in register_disk (gdev=0xc2fb73c0, dev={value = 8448}, minors=64, ops=0xc0322660, size=160086528)
    at check.c:422
#9  0xc0212193 in idedisk_attach (drive=0xc03895dc) at ide-disk.c:1492
#10 0xc020a751 in subdriver_match (channel=0xc03894b0, ops=0xc03230e0) at main.c:526
#11 0xc020aac6 in register_ata_driver (driver=0xc03230e0) at main.c:1090
#12 0xc033f3dd in idedisk_init () at ide-disk.c:1503
#13 0xc033d914 in ata_module_init () at main.c:1377
#14 0xc033da27 in init_ata () at main.c:1417


(And grep bio drivers/ide/ataraid.c || echo drat)

Re: IDE?

[Adam J. Richter]

	I just looked at the patch to switch to "2.4 forward port"
version of drivers/ide.  If I got my shell commands right, Martin's
tree is 8606 lines shorter than the 2.4 forward port.

	2.4 forward port	49,205 lines
	Martin's version	40,599 lines
				------------
				 8,606 lines difference

	It's often amazing how much cleaning up it takes to shrink
code a little bit.  Shrinking the IDE tree this much is a lot of
work to throw away.

	In comparison, I think Niklaus Wirth's Modula-2 compiler for
the Lilith machine was 5,000 lines.

	Is the 2.5.31 IDE tree that buggy?  I would hope that stamping
out bugs from Martin's tree would be less work than cleaning up
the 2.4 version to that point again.

>If you can work with him, then it would seem he would be well suited for
>the job... Assuming he wants it... Bartlomiej?

	I'd be quite relieved if we could convince Bartlomiej to
adopt Martin's tree and continue with Martin's tree as at least
a configuration option.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: IDE?

[Alexander Kellett]

[shortening cc:'s as they are probably not interested in me :) ]

On Sat, Aug 17, 2002 at 06:02:16AM -0700, Adam J. Richter wrote:
> 	I'd be quite relieved if we could convince Bartlomiej to
> adopt Martin's tree and continue with Martin's tree as at least
> a configuration option.

Couldn't agree more here. Although I usually hate <aol>-like
me too posts. I think that its really quite important for the 
state of the ide layer that the work thats already gone into
it isn't lost.

IMO this is not something that you can see a positive, or as a 
lesson learned. This to me just seems like a lot of hard work 
going down the drain.

So, pleeease Bartlomiej/Alan/Jens, whoever. Someone step up
to get most/some of Marcin' cleanup patches into 2.5 again.

Alex

Re: IDE?

[Andre Hedrick]

On Sat, 17 Aug 2002, Alexander Kellett wrote:

> [shortening cc:'s as they are probably not interested in me :) ]
> 
> IMO this is not something that you can see a positive, or as a 
> lesson learned. This to me just seems like a lot of hard work 
> going down the drain.

This one of my arguments against deleting Marcin work.
There are things he did which are good and real cleanups.

> So, pleeease Bartlomiej/Alan/Jens, whoever. Someone step up
> to get most/some of Marcin' cleanup patches into 2.5 again.

I have addressed most of his work which was sane and did not violate
transport protocols.

Regards,

Andre Hedrick
LAD Storage Consulting Group

Re: IDE?

[Alan Cox]

On Sat, 2002-08-17 at 14:22, Alexander Kellett wrote:
> So, pleeease Bartlomiej/Alan/Jens, whoever. Someone step up
> to get most/some of Marcin' cleanup patches into 2.5 again.

Not interested. Its easier to go back to functionally correct code and
do the job nicely than to fix the 2.5.3x code. Right now I'm working on
Andre's current code in 2.4.20pre2-ac* starting off with only provably
identical transforms between AndreCode and C and documenting it.

Alan

Re: IDE?

[Alexander Kellett]

On Sat, Aug 17, 2002 at 08:51:09PM +0100, Alan Cox wrote:
> On Sat, 2002-08-17 at 14:22, Alexander Kellett wrote:
> > So, pleeease Bartlomiej/Alan/Jens, whoever. Someone step up
> > to get most/some of Marcin' cleanup patches into 2.5 again.
> 
> Not interested. Its easier to go back to functionally correct code and
> do the job nicely than to fix the 2.5.3x code. Right now I'm working on
> Andre's current code in 2.4.20pre2-ac* starting off with only provably
> identical transforms between AndreCode and C and documenting it.

Better point, I realized my mistake right after reading Al's 
"tranformation" post and grasping the sense in it. Much better approach.  

Alex

Re: IDE?

[Andreas Dilger]

On Aug 17, 2002  06:02 -0700, Adam J. Richter wrote:
> 	I just looked at the patch to switch to "2.4 forward port"
> version of drivers/ide.  If I got my shell commands right, Martin's
> tree is 8606 lines shorter than the 2.4 forward port.
> 
> 	2.4 forward port	49,205 lines
> 	Martin's version	40,599 lines
> 				------------
> 				 8,606 lines difference
> 
> 	It's often amazing how much cleaning up it takes to shrink
> code a little bit.  Shrinking the IDE tree this much is a lot of
> work to throw away.
> 
> 	In comparison, I think Niklaus Wirth's Modula-2 compiler for
> the Lilith machine was 5,000 lines.
> 
> 	Is the 2.5.31 IDE tree that buggy?  I would hope that stamping
> out bugs from Martin's tree would be less work than cleaning up
> the 2.4 version to that point again.

Why don't we just start with the now-discarded 2.5 IDE code as IDE-TNG?
If people want to develop/hack then they can use that, and if they
want to hack on other things they use the old code.  You just need to
make the two config options mutually exclusive until the drivers learn
to play well together (by being able to control separate drives/ctrlr).

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: IDE?

[Vojtech Pavlik]

On Sat, Aug 17, 2002 at 12:26:38PM -0600, Andreas Dilger wrote:
> On Aug 17, 2002  06:02 -0700, Adam J. Richter wrote:
> > 	I just looked at the patch to switch to "2.4 forward port"
> > version of drivers/ide.  If I got my shell commands right, Martin's
> > tree is 8606 lines shorter than the 2.4 forward port.
> > 
> > 	2.4 forward port	49,205 lines
> > 	Martin's version	40,599 lines
> > 				------------
> > 				 8,606 lines difference
> > 
> > 	It's often amazing how much cleaning up it takes to shrink
> > code a little bit.  Shrinking the IDE tree this much is a lot of
> > work to throw away.
> > 
> > 	In comparison, I think Niklaus Wirth's Modula-2 compiler for
> > the Lilith machine was 5,000 lines.
> > 
> > 	Is the 2.5.31 IDE tree that buggy?  I would hope that stamping
> > out bugs from Martin's tree would be less work than cleaning up
> > the 2.4 version to that point again.
> 
> Why don't we just start with the now-discarded 2.5 IDE code as IDE-TNG?
> If people want to develop/hack then they can use that, and if they
> want to hack on other things they use the old code.  You just need to
> make the two config options mutually exclusive until the drivers learn
> to play well together (by being able to control separate drives/ctrlr).

Well, because it might be easier to just start from scratch.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE?

[Adam J. Richter]

On 2002-08-17, Alan Cox wrote:
>Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
>controllers would also be much appreciated. That way we can get good
>coverage tests and catch badness immediately

	From visiting the osdl.org booth a LinuxWorld, I understand
that they have a farm of 150 deliberately differently configured
computers on which you are supposed to be able to run your own
kernel tests on your own kernels.

	They have a procedure for adding new tests described at
http://www.osdl.org/stp/HOWTO.Port_Tests.html.

	I think it would be informative to run 2.4 ported code and
Martin's stack against IDE tests on this system.  With this, you could
not only spot problems, but see problems happening in a certain pattern
which could sometimes simplify finding a bug.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: IDE?

[Andre Hedrick]

OSDL does not support IDE.

See, I asked some time ago about testing raid arrays and a possible thread
driver.  All you will find there is onboard hosts, and I do not believe
they stock the all the junk systems out there.

150 systems is a not a large enough sample.

500 ++ w/ various add-in cards * (the number of drive models per vendor) *
the number vendors  eek stop ....

Add in ATAPI devices, CFA, etc ...

You see the combination are of a scale unchecked.

I started at one point trying to have a single drive vendor with at least
1000 or more systems in one lab to test their product over the host
hardware base, to run kernel checks.  The task was beyond scale.

All it takes is a bus analyzer and a few systems known to be good to
perfect the driver.  Then you deal with all the exceptions of the crap
combinations.

That is how I do it, since I have a code base that has been run over a
bus analyzer I know it works.

Cheers,


On Sun, 18 Aug 2002, Adam J. Richter wrote:

> On 2002-08-17, Alan Cox wrote:
> >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> >controllers would also be much appreciated. That way we can get good
> >coverage tests and catch badness immediately
> 
> 	From visiting the osdl.org booth a LinuxWorld, I understand
> that they have a farm of 150 deliberately differently configured
> computers on which you are supposed to be able to run your own
> kernel tests on your own kernels.
> 
> 	They have a procedure for adding new tests described at
> http://www.osdl.org/stp/HOWTO.Port_Tests.html.
> 
> 	I think it would be informative to run 2.4 ported code and
> Martin's stack against IDE tests on this system.  With this, you could
> not only spot problems, but see problems happening in a certain pattern
> which could sometimes simplify finding a bug.
> 
> Adam J. Richter     __     ______________   575 Oroville Road
> adam@yggdrasil.com     \ /                  Milpitas, California 95035
> +1 408 309-6081         | g g d r a s i l   United States of America
>                          "Free Software For The Rest Of Us."
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: IDE?

[Timothy D. Witham]

On Sun, 2002-08-18 at 16:38, Andre Hedrick wrote:
> 
> OSDL does not support IDE.
> 
  Well, some of the test systems only have IDE but no we
aren't in the "try all of the IDE chip set" support business.

> See, I asked some time ago about testing raid arrays and a possible thread
> driver.  All you will find there is onboard hosts, and I do not believe
> they stock the all the junk systems out there.
> 

  I'm always open to proposals but I've only really seen requests of
"I would like to test vendor A's hardware".  In my mind that is
a Vendor A problem not a generic OS or driver issue.  Now after
saying that if there is a class of issues that require a configuration
I'm happy to look at providing that.

> 150 systems is a not a large enough sample.
> 

  Agreed even if they are all different chip sets and controllers.

  On a side note:

	I am impressed with the serial ATA and the couple of products
that I've seen so far.  I think that this could remove the last barrier
for ATA drives in larger systems and wait to see what products people
come up with in the near future. 



> 500 ++ w/ various add-in cards * (the number of drive models per vendor) *
> the number vendors  eek stop ....
> 
> Add in ATAPI devices, CFA, etc ...
> 
> You see the combination are of a scale unchecked.
> 
> I started at one point trying to have a single drive vendor with at least
> 1000 or more systems in one lab to test their product over the host
> hardware base, to run kernel checks.  The task was beyond scale.
> 
> All it takes is a bus analyzer and a few systems known to be good to
> perfect the driver.  Then you deal with all the exceptions of the crap
> combinations.
> 
> That is how I do it, since I have a code base that has been run over a
> bus analyzer I know it works.
> 
> Cheers,
> 
> 
> On Sun, 18 Aug 2002, Adam J. Richter wrote:
> 
> > On 2002-08-17, Alan Cox wrote:
> > >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> > >controllers would also be much appreciated. That way we can get good
> > >coverage tests and catch badness immediately
> > 
> > 	From visiting the osdl.org booth a LinuxWorld, I understand
> > that they have a farm of 150 deliberately differently configured
> > computers on which you are supposed to be able to run your own
> > kernel tests on your own kernels.
> > 
> > 	They have a procedure for adding new tests described at
> > http://www.osdl.org/stp/HOWTO.Port_Tests.html.
> > 
> > 	I think it would be informative to run 2.4 ported code and
> > Martin's stack against IDE tests on this system.  With this, you could
> > not only spot problems, but see problems happening in a certain pattern
> > which could sometimes simplify finding a bug.
> > 
> > Adam J. Richter     __     ______________   575 Oroville Road
> > adam@yggdrasil.com     \ /                  Milpitas, California 95035
> > +1 408 309-6081         | g g d r a s i l   United States of America
> >                          "Free Software For The Rest Of Us."
> > -
> > 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/
> > 
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 
> -
> 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/
-- 
Timothy D. Witham - Lab Director - wookie@osdlab.org
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

Re: IDE?

[Andre Hedrick]

Hi Tim "The Wookie"!

As you know I have release SATA 1.0 which was funded by Silicon Image.
I saw at LWE last week the Intel SATA raid card using SiI SATALink.
Maybe SiI might be able to help you out in that direction.
You at least know you will have quality driver support.

Cheers,

Andre Hedrick
Linux Serial ATA Solutions
LAD Storage Consulting Group



On 19 Aug 2002, Timothy D. Witham wrote:

> On Sun, 2002-08-18 at 16:38, Andre Hedrick wrote:
> > 
> > OSDL does not support IDE.
> > 
>   Well, some of the test systems only have IDE but no we
> aren't in the "try all of the IDE chip set" support business.
> 
> > See, I asked some time ago about testing raid arrays and a possible thread
> > driver.  All you will find there is onboard hosts, and I do not believe
> > they stock the all the junk systems out there.
> > 
> 
>   I'm always open to proposals but I've only really seen requests of
> "I would like to test vendor A's hardware".  In my mind that is
> a Vendor A problem not a generic OS or driver issue.  Now after
> saying that if there is a class of issues that require a configuration
> I'm happy to look at providing that.
> 
> > 150 systems is a not a large enough sample.
> > 
> 
>   Agreed even if they are all different chip sets and controllers.
> 
>   On a side note:
> 
> 	I am impressed with the serial ATA and the couple of products
> that I've seen so far.  I think that this could remove the last barrier
> for ATA drives in larger systems and wait to see what products people
> come up with in the near future. 
> 
> 
> 
> > 500 ++ w/ various add-in cards * (the number of drive models per vendor) *
> > the number vendors  eek stop ....
> > 
> > Add in ATAPI devices, CFA, etc ...
> > 
> > You see the combination are of a scale unchecked.
> > 
> > I started at one point trying to have a single drive vendor with at least
> > 1000 or more systems in one lab to test their product over the host
> > hardware base, to run kernel checks.  The task was beyond scale.
> > 
> > All it takes is a bus analyzer and a few systems known to be good to
> > perfect the driver.  Then you deal with all the exceptions of the crap
> > combinations.
> > 
> > That is how I do it, since I have a code base that has been run over a
> > bus analyzer I know it works.
> > 
> > Cheers,
> > 
> > 
> > On Sun, 18 Aug 2002, Adam J. Richter wrote:
> > 
> > > On 2002-08-17, Alan Cox wrote:
> > > >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> > > >controllers would also be much appreciated. That way we can get good
> > > >coverage tests and catch badness immediately
> > > 
> > > 	From visiting the osdl.org booth a LinuxWorld, I understand
> > > that they have a farm of 150 deliberately differently configured
> > > computers on which you are supposed to be able to run your own
> > > kernel tests on your own kernels.
> > > 
> > > 	They have a procedure for adding new tests described at
> > > http://www.osdl.org/stp/HOWTO.Port_Tests.html.
> > > 
> > > 	I think it would be informative to run 2.4 ported code and
> > > Martin's stack against IDE tests on this system.  With this, you could
> > > not only spot problems, but see problems happening in a certain pattern
> > > which could sometimes simplify finding a bug.
> > > 
> > > Adam J. Richter     __     ______________   575 Oroville Road
> > > adam@yggdrasil.com     \ /                  Milpitas, California 95035
> > > +1 408 309-6081         | g g d r a s i l   United States of America
> > >                          "Free Software For The Rest Of Us."
> > > -
> > > 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/
> > > 
> > 
> > Andre Hedrick
> > LAD Storage Consulting Group
> > 
> > -
> > 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/
> -- 
> Timothy D. Witham - Lab Director - wookie@osdlab.org
> Open Source Development Lab Inc - A non-profit corporation
> 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
> (503)-626-2455 x11 (office)    (503)-702-2871     (cell)
> (503)-626-2436     (fax)
> 

Re: IDE?

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

Am Mon, 2002-08-19 um 22.23 schrieb Timothy D. Witham:

> 	I am impressed with the serial ATA and the couple of products
> that I've seen so far.  I think that this could remove the last barrier
> for ATA drives in larger systems and wait to see what products people
> come up with in the near future. 

Not unless manufacturers like IBM stop producing cheesy ATA drives which
are not meant for real productive use.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IDE?

[Gunther Mayer]

Andre Hedrick wrote:

>
>That is how I do it, since I have a code base that has been run over a
>bus analyzer I know it works.
>
It would be interesting to run on a bus simulator to show the driver
behaves correct on all allowed conditions and sensible on error conditions
(i.e. printk and return an error to the application; don't hang the system).

Re: IDE?

[Andre Hedrick]

On Tue, 20 Aug 2002, Gunther Mayer wrote:

> Andre Hedrick wrote:
> 
> >
> >That is how I do it, since I have a code base that has been run over a
> >bus analyzer I know it works.
> >
> It would be interesting to run on a bus simulator to show the driver
> behaves correct on all allowed conditions and sensible on error conditions
> (i.e. printk and return an error to the application; don't hang the system).

Greets Gunther,

Hmmm, would you expand on the direction you are point to go?

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: IDE?

[Timothy D. Witham]

  Actually while we have a variety of chip sets and systems are
goal is not to have 150 different system configurations.  

  We tend to stick with multiple systems of the same type. For
example when we buy some 4 ways we buy 3 or 4 of the same one
at the same time. There are some very good reasons for this.
The 1st being trying to keep a bunch of different chip sets
and I/O controllers functioning while the development kernel
rolls forward underneath us is hard enough when you limit 
your configurations and would be impossible with 150 different
system types.  Second since we are trying to do performance
and functionality testing the ability to assign a returning
user to any one of a group of systems instead of having them
wait for the exact one they used before makes scheduling a 
lot easier. :-)

  While a large number of systems in you lab do use IDE
for at least there primary disk we really aren't trying
to provide variety for the "does this chip set work" type
of testing.

Tim


  
On Sun, 2002-08-18 at 15:49, Adam J. Richter wrote:
> On 2002-08-17, Alan Cox wrote:
> >Volunteers willing to run Cerberus test sets on 2.4 boxes with IDE
> >controllers would also be much appreciated. That way we can get good
> >coverage tests and catch badness immediately
> 
> 	From visiting the osdl.org booth a LinuxWorld, I understand
> that they have a farm of 150 deliberately differently configured
> computers on which you are supposed to be able to run your own
> kernel tests on your own kernels.
> 
> 	They have a procedure for adding new tests described at
> http://www.osdl.org/stp/HOWTO.Port_Tests.html.
> 
> 	I think it would be informative to run 2.4 ported code and
> Martin's stack against IDE tests on this system.  With this, you could
> not only spot problems, but see problems happening in a certain pattern
> which could sometimes simplify finding a bug.
> 
> Adam J. Richter     __     ______________   575 Oroville Road
> adam@yggdrasil.com     \ /                  Milpitas, California 95035
> +1 408 309-6081         | g g d r a s i l   United States of America
>                          "Free Software For The Rest Of Us."
> -
> 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/
-- 
Timothy D. Witham - Lab Director - wookie@osdlab.org
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

Re: IDE?

[Adam J. Richter]

Andre Hedrick writes:
>150 systems is a not a large enough sample.

	Sorry if I wasn't clear.  I did not mean "instead of" other
testing, I meant "in addition to."

	Anyhow, I'm glad to hear that you had already checked out osdl.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."