Bart's efforts?

Bart's efforts?

[Greg Freemyer]

Jeff / Alan,

I mostly lurk here, but I know there is a long term effort/ToDo to
move libata away from the SCSI infrastructure.

I've also seen that Bart has been making a large number of
improvements to drivers/ide over the last little while.  From my
limited perspective, many changes appear to be to the core
infrastructure.

My question is if the drivers/ide infrastructure is slowly moving in
the direction of being leverageable by libata when/if it moves out of
scsi.  Or does the drivers/ide code simply have the wrong kind of
plumbing for libata to ever use.

Thanks
Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Bart's efforts?

[Jeff Garzik]

Greg Freemyer wrote:
> Jeff / Alan,
> 
> I mostly lurk here, but I know there is a long term effort/ToDo to
> move libata away from the SCSI infrastructure.
> 
> I've also seen that Bart has been making a large number of
> improvements to drivers/ide over the last little while.  From my
> limited perspective, many changes appear to be to the core
> infrastructure.
> 
> My question is if the drivers/ide infrastructure is slowly moving in
> the direction of being leverageable by libata when/if it moves out of
> scsi.  Or does the drivers/ide code simply have the wrong kind of
> plumbing for libata to ever use.

One of my key goals with libata was to "make a driver look like a 
driver" and greatly improve upon the IDE driver API, which was a 
complete and utter piece of garbage (this is no reflection on Bart, he 
inherited it).  As a result, each driver is a fully fledged 
PCI/SCSI/ATA/platform driver, without anything getting in the way.  That 
made things like controller hotplug trivial to support from day one.

Bart has definitely made many good improvements, but I don't think 
people would be surprised that I feel CONFIG_IDE is legacy...

	Jeff

Re: Bart's efforts?

[Greg Freemyer]

Thanks,

I was just curious.

On 11/3/07, Jeff Garzik <jeff@garzik.org> wrote:
> Greg Freemyer wrote:
> > Jeff / Alan,
> >
> > I mostly lurk here, but I know there is a long term effort/ToDo to
> > move libata away from the SCSI infrastructure.
> >
> > I've also seen that Bart has been making a large number of
> > improvements to drivers/ide over the last little while.  From my
> > limited perspective, many changes appear to be to the core
> > infrastructure.
> >
> > My question is if the drivers/ide infrastructure is slowly moving in
> > the direction of being leverageable by libata when/if it moves out of
> > scsi.  Or does the drivers/ide code simply have the wrong kind of
> > plumbing for libata to ever use.
>
> One of my key goals with libata was to "make a driver look like a
> driver" and greatly improve upon the IDE driver API, which was a
> complete and utter piece of garbage (this is no reflection on Bart, he
> inherited it).  As a result, each driver is a fully fledged
> PCI/SCSI/ATA/platform driver, without anything getting in the way.  That
> made things like controller hotplug trivial to support from day one.
>
> Bart has definitely made many good improvements, but I don't think
> people would be surprised that I feel CONFIG_IDE is legacy...
>
>         Jeff
>
>
>
>
>
>


-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Bart's efforts?

[Alan Cox]

> My question is if the drivers/ide infrastructure is slowly moving in
> the direction of being leverageable by libata when/if it moves out of
> scsi.  Or does the drivers/ide code simply have the wrong kind of
> plumbing for libata to ever use.

I don't think there is anything useful in old IDE that isn't in the new.
However libata PATA support is not all new code, its built on and from
the old IDE driver code. Similarly there is stuff recently going on in
drivers/ide that is then going into drivers/ata (eg the IVB blacklists).

The big issue with drivers/ide is the core code which simply can't cope
with SMP or modern hardware designs.   don't consider drivers/ide
anything but "legacy" but lots of older systems use it and its important
it stays maintained. Bart is doing whats actually a pretty thankless job
- working on maintaining stuff for the short term knowing it has no real
future.

Alan

Re: Bart's efforts?

[Felix Miata]

On 2007/11/03 14:10 (GMT) Alan Cox apparently typed:

> I don't think there is anything useful in old IDE that isn't in the new.

You mean besides being able to access all existing disk partitions? Google
can show you I'm not the only multiboot upgrader with far more than 14
filesystems per disk. The standard drivers should be able to provide access
to every standard partition fdisk/cfdisk/sfdisk or any other conforming
partitioning tool is able to create. LVM should not be prerequisite to using
SATA for those who need many low level logical disk subdivisions.

Disk /dev/hda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          13      104391   17  Hidden HPFS/NTFS
/dev/hda2   *          14          14        8032+   a  OS/2 Boot Manager
/dev/hda3              15          46      257040    6  FAT16
/dev/hda4              48       30401   243818505    5  Extended
/dev/hda5              48          73      208813+  83  Linux
/dev/hda6              74         188      923706   82  Linux swap / Solaris
/dev/hda7             189         800     4915858+  83  Linux
/dev/hda8            1108        1108        8001    1  FAT12
/dev/hda9            1109        1140      257008+   6  FAT16
/dev/hda10           1142        1243      819283+   7  HPFS/NTFS
/dev/hda11           1269        1523     2048256    7  HPFS/NTFS
/dev/hda12           1575        1693      955836    7  HPFS/NTFS
/dev/hda13           1694        2012     2562336    7  HPFS/NTFS
/dev/hda14           2014        2217     1638598+  83  Linux
/dev/hda15           2218        2568     2819376   83  Linux
/dev/hda16           2569        3486     7373803+  83  Linux
/dev/hda17           3487        4379     7172991   83  Linux
/dev/hda18           4380        4409      240943+  83  Linux
/dev/hda19           4410        4549     1124518+  83  Linux
/dev/hda20           4550        5187     5124703+  83  Linux
/dev/hda21          18234       18845     4915858+  83  Linux
/dev/hda22          18846       19457     4915858+  83  Linux
/dev/hda23          20383       20391       72261   83  Linux
/dev/hda24          20392       30401    80405293+  83  Linux

> However libata PATA support is not all new code, its built on and from
> the old IDE driver code. Similarly there is stuff recently going on in
> drivers/ide that is then going into drivers/ata (eg the IVB blacklists).

> The big issue with drivers/ide is the core code which simply can't cope
> with SMP or modern hardware designs.   don't consider drivers/ide
> anything but "legacy" but lots of older systems use it and its important
> it stays maintained. Bart is doing whats actually a pretty thankless job
> - working on maintaining stuff for the short term knowing it has no real
> future.
-- 
"   A patriot without religion . . . is as great a
paradox, as an honest man without the fear of God."
	                             John Adams

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/

Re: Bart's efforts?

[Mikael Pettersson]

On Sat, 3 Nov 2007 14:10:22 +0000, Alan Cox wrote:
> > My question is if the drivers/ide infrastructure is slowly moving in
> > the direction of being leverageable by libata when/if it moves out of
> > scsi.  Or does the drivers/ide code simply have the wrong kind of
> > plumbing for libata to ever use.
> 
> I don't think there is anything useful in old IDE that isn't in the new.

For semi-modern machines that might be true. However:

1) there's no libata replacement for the IDE pmac driver
2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box
3) pata_legacy doesn't release io/irq combinations for failed
   probes, causing conflicts with drivers loaded later on

(Not a complaint, just a reminder that rm -rf drivers/ide/
isn't an option yet.)

Re: Bart's efforts?

[Alan Cox]

> > I don't think there is anything useful in old IDE that isn't in the new.
> 
> You mean besides being able to access all existing disk partitions? Google

Al Viro vetoed this support in the SCSI core. Take it up with him. The
libata layer is happy with lots of partitions but it needs a change for
sparse minors, or your distribution to use device mapper to do the work.

Alan

Re: Bart's efforts?

[Alan Cox]

> 1) there's no libata replacement for the IDE pmac driver

This is true currently. David Woodhouse loaned me a Pmac to fix that but
it died so thats waiting for the PPC people to do something about it.

> 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box

Bug # ?

> 3) pata_legacy doesn't release io/irq combinations for failed
>    probes, causing conflicts with drivers loaded later on

In my tree it does but I'm still testing some bits. I've been rewriting
the legacy driver to make it a lot cleaner and easy to plug other ISA/VLB
device handlers into it.

Re: Bart's efforts?

[Mikael Pettersson]

Alan Cox wrote:
>> 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box
>
>Bug # ?

No bz # yet, but you and I had a private email conversation about
this on March 13 and 15 this year.

There's been a couple of recent reports to linux-ide with identical
(as far as I can see) issues as I get:
<http://marc.info/?l=linux-ide&m=119152811824641&w=2>
<http://marc.info/?l=linux-ide&m=118890476223188&w=2>
<http://marc.info/?l=linux-ide&m=118855473322630&w=2>

I'll add a bugzilla entry for this next week so it doesn't get lost.

>> 3) pata_legacy doesn't release io/irq combinations for failed
>>    probes, causing conflicts with drivers loaded later on
>
>In my tree it does but I'm still testing some bits.

Good news.

/Mikael

Re: Bart's efforts?

[Mark Lord]

delkin_cb is also missing from libata.

I was going to port it over once, but no longer have a cardbus slot
in either of my notebooks here.

Cheers

Re: Bart's efforts?

[Alan Cox]

On Wed, 07 Nov 2007 17:37:07 -0500
Mark Lord <liml@rtr.ca> wrote:

> delkin_cb is also missing from libata.
> 
> I was going to port it over once, but no longer have a cardbus slot
> in either of my notebooks here.

Yes I looked at it but it didn't have any proper speed setting, so I
decided it wasn't actually worth doing.

Alan

Re: Bart's efforts?

[Mark Lord]

Alan Cox wrote:
> On Wed, 07 Nov 2007 17:37:07 -0500
> Mark Lord <liml@rtr.ca> wrote:
> 
>> delkin_cb is also missing from libata.
>>
>> I was going to port it over once, but no longer have a cardbus slot
>> in either of my notebooks here.
> 
> Yes I looked at it but it didn't have any proper speed setting, so I
> decided it wasn't actually worth doing.
..

Yeah.  No docs whatsoever, but there's more than a few users
of it out there.

Cheers

Re: Bart's efforts?

[Alan Cox]

> Yeah.  No docs whatsoever, but there's more than a few users
> of it out there.

So how do we handle devices that don't support PIO4 ?

Other than the speed handling mystery the port is trivial.

Alan

Re: Bart's efforts?

[Mark Lord]

Alan Cox wrote:
>> Yeah.  No docs whatsoever, but there's more than a few users
>> of it out there.
> 
> So how do we handle devices that don't support PIO4 ?
..

I'm not actually sure that it's even running that fast (PIO4), 
as the performance is still only half of what Windoze gets.

I have a logic analyzer here, but no Cardbus extender to hook it onto.

Re: Bart's efforts?

[Mikael Pettersson]

Mikael Pettersson writes:
 > On Sat, 3 Nov 2007 14:10:22 +0000, Alan Cox wrote:
 > > > My question is if the drivers/ide infrastructure is slowly moving in
 > > > the direction of being leverageable by libata when/if it moves out of
 > > > scsi.  Or does the drivers/ide code simply have the wrong kind of
 > > > plumbing for libata to ever use.
 > > 
 > > I don't think there is anything useful in old IDE that isn't in the new.
 > 
 > For semi-modern machines that might be true. However:
 > 
...
 > 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box

See <http://bugzilla.kernel.org/show_bug.cgi?id=9337> for details.