2005-10-21 19:14:24

by Jeff Garzik

[permalink] [raw]
Subject: Merging ATA passthru


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




2005-10-21 19:58:41

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Merging ATA passthru

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 ;)


2005-10-21 20:01:38

by Chris Boot

[permalink] [raw]
Subject: Re: Merging ATA passthru

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 [email protected]
> 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
[email protected]
http://www.bootc.net/

2005-10-21 20:04:28

by Jeff Garzik

[permalink] [raw]
Subject: Re: Merging ATA passthru

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



2005-10-21 21:45:13

by Mark Lord

[permalink] [raw]
Subject: Re: Merging ATA passthru

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!

2005-10-21 22:04:14

by Jeff Garzik

[permalink] [raw]
Subject: Re: Merging ATA passthru

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


2005-10-22 01:22:18

by John W. Linville

[permalink] [raw]
Subject: Re: Merging ATA passthru

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
[email protected]