Merging ATA passthru

Merging ATA passthru

[Jeff Garzik]

Folks,

Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
the ATA passthru work upstream, once 2.6.14 is released.

Since there are still some reported problems that I haven't had time to 
track down, I'm going to -- like ATAPI -- introduce a module option that 
enables passthru.  It will default to off.

Other features that follow a similar pattern -- 98% there but needs a 
few final tweaks -- will be treated in the same way.

This gets lesser-used features upstream where they can get the most 
testing, while defaulting them to off ensures that we won't perturb the 
known-working code.

This also will help me, in that I won't have to maintain a bunch of 
parallel codebases.

	Jeff

Re: Merging ATA passthru

[Arjan van de Ven]

On Fri, 2005-10-21 at 15:14 -0400, Jeff Garzik wrote:
> Folks,
> 
> Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
> the ATA passthru work upstream, once 2.6.14 is released.
> 
> Since there are still some reported problems that I haven't had time to 
> track down, I'm going to -- like ATAPI -- introduce a module option that 
> enables passthru.  It will default to off.
> 
> Other features that follow a similar pattern -- 98% there but needs a 
> few final tweaks -- will be treated in the same way.

can you get a patch into -mm that default-on's them? That way the brave
of heart get it automatic while those who play safe get them
default-off. Expands your testingbase as well ;)

Re: Merging ATA passthru

[Chris Boot]

Arjan van de Ven wrote:
> On Fri, 2005-10-21 at 15:14 -0400, Jeff Garzik wrote:
> 
>>Folks,
>>
>>Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
>>the ATA passthru work upstream, once 2.6.14 is released.
>>
>>Since there are still some reported problems that I haven't had time to 
>>track down, I'm going to -- like ATAPI -- introduce a module option that 
>>enables passthru.  It will default to off.
>>
>>Other features that follow a similar pattern -- 98% there but needs a 
>>few final tweaks -- will be treated in the same way.
> 
> 
> can you get a patch into -mm that default-on's them? That way the brave
> of heart get it automatic while those who play safe get them
> default-off. Expands your testingbase as well ;)
> 
> 
> -
> 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/

It's already there:

arcadia ~ # uname -a
Linux arcadia.lan 2.6.14-rc4-mm1 #2 Thu Oct 20 12:07:22 BST 2005 i686 
AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux

arcadia ~ # smartctl -d ata -H /dev/sda
smartctl version 5.33 [i686-pc-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

:-)

Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: Merging ATA passthru

[Jeff Garzik]

Arjan van de Ven wrote:
> On Fri, 2005-10-21 at 15:14 -0400, Jeff Garzik wrote:
> 
>>Folks,
>>
>>Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
>>the ATA passthru work upstream, once 2.6.14 is released.
>>
>>Since there are still some reported problems that I haven't had time to 
>>track down, I'm going to -- like ATAPI -- introduce a module option that 
>>enables passthru.  It will default to off.
>>
>>Other features that follow a similar pattern -- 98% there but needs a 
>>few final tweaks -- will be treated in the same way.
> 
> 
> can you get a patch into -mm that default-on's them? That way the brave
> of heart get it automatic while those who play safe get them
> default-off. Expands your testingbase as well ;)

It currently defaults to on in -mm.  I'll make sure that doesn't change...

	Jeff

Re: Merging ATA passthru

[Mark Lord]

Jeff Garzik wrote:
> 
> Folks,
> 
> Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
> the ATA passthru work upstream, once 2.6.14 is released.

Thanks, Jeff!

> Since there are still some reported problems that I haven't had time to 
> track down, I'm going to -- like ATAPI -- introduce a module option that 
> enables passthru.  It will default to off.

With passthru, it would really be much better to just leave it enabled
without any option.  It's NOT on any main code path, and users/distros
have to intentionally run "smartctl -d ata" or "hdparm /dev/sd*" to
trigger any of it.

So it is already "off", unless somebody wants to use it.
This is different from the ATAPI code.

But good to have it finally going upstream where it will get used.

Cheers!

Re: Merging ATA passthru

[Jeff Garzik]

Mark Lord wrote:
> Jeff Garzik wrote:
> 
>>
>> Folks,
>>
>> Taking Mark Lord's (and others) criticism to heart, I'm going to merge 
>> the ATA passthru work upstream, once 2.6.14 is released.
> 
> 
> Thanks, Jeff!
> 
>> Since there are still some reported problems that I haven't had time 
>> to track down, I'm going to -- like ATAPI -- introduce a module option 
>> that enables passthru.  It will default to off.
> 
> 
> With passthru, it would really be much better to just leave it enabled
> without any option.  It's NOT on any main code path, and users/distros
> have to intentionally run "smartctl -d ata" or "hdparm /dev/sd*" to
> trigger any of it.
> 
> So it is already "off", unless somebody wants to use it.

Not really true, as people constantly try (and fail) to use hdparm with 
their SATA disks today.

Anyway, I have this weird thing about not turning on something by 
default, when I know has it problems ;-)

	Jeff

Re: Merging ATA passthru

[John W. Linville]

On Fri, Oct 21, 2005 at 05:45:04PM -0400, Mark Lord wrote:

> With passthru, it would really be much better to just leave it enabled
> without any option.  It's NOT on any main code path, and users/distros
> have to intentionally run "smartctl -d ata" or "hdparm /dev/sd*" to
> trigger any of it.

Actually, that's a good point.  I'm forced to concur with my
colleague... :-)

John
-- 
John W. Linville
linville@tuxdriver.com