TASKFILE ioctl for libata?

TASKFILE ioctl for libata?

[Erik Mouw]

Hi,

Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
(security freeze, security unlock, etc.). I can't find it in Jeff's
libata-dev tree, is there somebody already working on it? Or is there a
workaround?

I've tried to identify (command 0xEC) the device through the TASKFILE
ioctl: it works on a PATA drive (/dev/hda), but with a SATA device
(/dev/sda) I get ENOTTY on the ioctl, so it appears that the TASKFILE
ioctl is indeed not (yet) implemented.

Any thoughts?


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Mark Lord]

Erik Mouw wrote:
> Hi,
> 
> Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
> (security freeze, security unlock, etc.). I can't find it in Jeff's
> libata-dev tree, is there somebody already working on it? Or is there a
> workaround?
>

If that ioctl is missing in libata, then I'll have to convert hdparm
to use SGIO to submit ATA Passthru packets instead for libata devices.

That's on my TO-DO list, and rising more quickly to the top now, it seems.

Cheers

Re: TASKFILE ioctl for libata?

[Matt Gillette]

Mark,

Thanks to Alan Cox, I now have a libata driver for my IDE controller.  
Now I'm looking into the next problem I have, which seems to be the  
same problem you're running into. I need a generic ATA passthru  
mechanism to configure our raid controller and need to send both non- 
data and data commands (with PIO and DMA).

Bartlomiej suggested using SGIO, but I haven't found any good  
documentation or examples on what I would need to do to prepare and  
send the command.

I'm not sure how much I could help (I'm still a beginner), but I just  
wanted to put in the fact that I'm interested in seeing a working  
example of the SGIO protocol and am willing to offer any help I can.

Matt


> From: Mark Lord <liml@rtr.ca>
> Date: Feb 15, 2006 11:00 AM
> Subject: Re: TASKFILE ioctl for libata?
> To: Erik Mouw <erik@harddisk-recovery.com>
> Cc: linux-ide@vger.kernel.org
>
>
> Erik Mouw wrote:
>> Hi,
>>
>> Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature  
>> set
>> (security freeze, security unlock, etc.). I can't find it in Jeff's
>> libata-dev tree, is there somebody already working on it? Or is  
>> there a
>> workaround?
>>
>
> If that ioctl is missing in libata, then I'll have to convert hdparm
> to use SGIO to submit ATA Passthru packets instead for libata devices.
>
> That's on my TO-DO list, and rising more quickly to the top now, it  
> seems.
>
> Cheers
> -
> To unsubscribe from this list: send the line "unsubscribe linux- 
> ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TASKFILE ioctl for libata?

[Tejun Heo]

Matt Gillette wrote:
> Mark,
> 
> Thanks to Alan Cox, I now have a libata driver for my IDE controller. 
> Now I'm looking into the next problem I have, which seems to be the same 
> problem you're running into. I need a generic ATA passthru mechanism to 
> configure our raid controller and need to send both non-data and data 
> commands (with PIO and DMA).
> 
> Bartlomiej suggested using SGIO, but I haven't found any good 
> documentation or examples on what I would need to do to prepare and send 
> the command.
> 
> I'm not sure how much I could help (I'm still a beginner), but I just 
> wanted to put in the fact that I'm interested in seeing a working 
> example of the SGIO protocol and am willing to offer any help I can.

Hello, Matt.

If you're looking for ATA SGIO example, smartctl source should have it. 
  smartctl uses ATA SGIO when given -d ATA option.  And, plesase don't 
top post.

-- 
tejun

Re: TASKFILE ioctl for libata?

[Erik Mouw]

On Wed, Feb 15, 2006 at 02:00:46PM -0500, Mark Lord wrote:
> Erik Mouw wrote:
> >Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
> >(security freeze, security unlock, etc.). I can't find it in Jeff's
> >libata-dev tree, is there somebody already working on it? Or is there a
> >workaround?
> 
> If that ioctl is missing in libata, then I'll have to convert hdparm
> to use SGIO to submit ATA Passthru packets instead for libata devices.

If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
functionality can be accomplished through SGIO ATA Passthru.

> That's on my TO-DO list, and rising more quickly to the top now, it seems.

OK, great.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Jeff Garzik]

Erik Mouw wrote:
> On Wed, Feb 15, 2006 at 02:00:46PM -0500, Mark Lord wrote:
> 
>>Erik Mouw wrote:
>>
>>>Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
>>>(security freeze, security unlock, etc.). I can't find it in Jeff's
>>>libata-dev tree, is there somebody already working on it? Or is there a
>>>workaround?
>>
>>If that ioctl is missing in libata, then I'll have to convert hdparm
>>to use SGIO to submit ATA Passthru packets instead for libata devices.
> 
> 
> If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
> and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
> functionality can be accomplished through SGIO ATA Passthru.

For compatibility :)  The HDIO compat ioctls are implemented internally 
via the ATA passthru SCSI command.

Although in general I resist adding compat ioctls, I think avoiding 
TASKFILE when we have TASK/CMD ioctls would be inconsistent.  If 
somebody wants to submit a tested patch...

	Jeff

Re: TASKFILE ioctl for libata?

[Tejun Heo]

Jeff Garzik wrote:
> Erik Mouw wrote:
> 
>> On Wed, Feb 15, 2006 at 02:00:46PM -0500, Mark Lord wrote:
>>
>>> Erik Mouw wrote:
>>>
>>>> Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
>>>> (security freeze, security unlock, etc.). I can't find it in Jeff's
>>>> libata-dev tree, is there somebody already working on it? Or is there a
>>>> workaround?
>>>
>>>
>>> If that ioctl is missing in libata, then I'll have to convert hdparm
>>> to use SGIO to submit ATA Passthru packets instead for libata devices.
>>
>>
>>
>> If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
>> and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
>> functionality can be accomplished through SGIO ATA Passthru.
> 
> 
> For compatibility :)  The HDIO compat ioctls are implemented internally 
> via the ATA passthru SCSI command.
> 
> Although in general I resist adding compat ioctls, I think avoiding 
> TASKFILE when we have TASK/CMD ioctls would be inconsistent.  If 
> somebody wants to submit a tested patch...
> 

Hello.

Just a side note.  Taskfile has finer granuality regarding which 
registers are written and read back than current libata does and IDE 
taskfile implementation is somewhat broken/weird in a few delicate fun 
ways, so... be careful.  Whoever tries it.

-- 
tejun

Re: TASKFILE ioctl for libata?

[Jeff Garzik]

Tejun Heo wrote:
> Just a side note.  Taskfile has finer granuality regarding which 
> registers are written and read back than current libata does and IDE 
> taskfile implementation is somewhat broken/weird in a few delicate fun 
> ways, so... be careful.  Whoever tries it.

Yes -- it opens the question about whether we care enough to fully 
support flagged taskfiles, and if not, how to best emulate that support 
under libata.

I'm told that flagging individual ATA shadow registers for modification 
(or not) is required for issuing certain specialized PATA 
vendor-specific commands.  SATA, OTOH, transmits all ATA shadow 
registers in a FIS, so flagged taskfiles are useless.

So, I'm now thinking the best route is to leave the code as it is ;-) 
Rather than imperfectly implementing the flagged taskfile ioctl, punt 
the remaining userland users to SG_IO.

I don't see lack of full flagged taskfile support as a big stumbling 
block to libata use.

	Jeff

Re: TASKFILE ioctl for libata?

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>> Just a side note.  Taskfile has finer granuality regarding which 
>> registers are written and read back than current libata does and IDE 
>> taskfile implementation is somewhat broken/weird in a few delicate fun 
>> ways, so... be careful.  Whoever tries it.

Hello, Jeff.

> Yes -- it opens the question about whether we care enough to fully 
> support flagged taskfiles, and if not, how to best emulate that support 
> under libata.

Yeah, and another difficult question is - Are we going to exactly 
replicate the behavior of IDE TASKFILE or try to fix / clean up?  I have 
no idea what should be done.  The thing with TASKFILE is that it doesn't 
have too many users but has enough annoying inconsistencies/bugs.  So, 
neither of rigorous replication or behavior cleanup feels right.

> I'm told that flagging individual ATA shadow registers for modification 
> (or not) is required for issuing certain specialized PATA 
> vendor-specific commands.  SATA, OTOH, transmits all ATA shadow 
> registers in a FIS, so flagged taskfiles are useless.
> 
> So, I'm now thinking the best route is to leave the code as it is ;-) 
> Rather than imperfectly implementing the flagged taskfile ioctl, punt 
> the remaining userland users to SG_IO.
> 
> I don't see lack of full flagged taskfile support as a big stumbling 
> block to libata use.

I agree.  HDIO_DRIVE_CMD and HDIO_DRIVE_TASK are orders simpler compared 
to HDIO_DRIVE_TASKFILE and we don't even know what's TASKFILE's correct 
behavior is.  So, I think we should just leave TASKFILE out there in the 
wilderness and watch it with sorrow as it dies slowly.

Also, as you pointed out, it's hardware-wise impossible to do 
register-level granuality with SATA and I'll be surprised if any more 
need for register-level granuality arises than there currently is.  So, 
I say we can forget about it without too much trouble.  And if such need 
EVER arises, let's hope SAT guys come up with something reasonable.

Thanks.

-- 
tejun

Re: TASKFILE ioctl for libata?

[Mark Lord]

Tejun Heo wrote:
>
> Also, as you pointed out, it's hardware-wise impossible to do 
> register-level granuality with SATA and I'll be surprised if any more 
> need for register-level granuality arises than there currently is.

I hope we can keep in mind that libata is about much more than
plain old SATA these days -- it appears about to displace my long
lost IDE subsystem and all of the PATA, Cardbus, and PC-Card devices
that it has long been the sole interface for.

Far be it from me to favour trying to implement the crazy TASKFILE
ioctl() here, though.   We just need to nudge the Passthru mechanism
in the right directions so that it can cover everyone's needs,
including those for low-level vendor commands (for drive test etc..).

Cheers

Re: TASKFILE ioctl for libata?

[Erik Mouw]

On Thu, Feb 16, 2006 at 06:30:04PM +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> >Erik Mouw wrote:
> >>If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
> >>and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
> >>functionality can be accomplished through SGIO ATA Passthru.
> >
> >For compatibility :)  The HDIO compat ioctls are implemented internally 
> >via the ATA passthru SCSI command.
> >
> >Although in general I resist adding compat ioctls, I think avoiding 
> >TASKFILE when we have TASK/CMD ioctls would be inconsistent.  If 
> >somebody wants to submit a tested patch...
> 
> Just a side note.  Taskfile has finer granuality regarding which 
> registers are written and read back than current libata does and IDE 
> taskfile implementation is somewhat broken/weird in a few delicate fun 
> ways, so... be careful.  Whoever tries it.

The few applications that use the TASKFILE ioctl I've seen don't use
that fine granularity so it might not be necessary.

What kind of delicate broken things are you referring to? The commands
I've tried so far (identify, read sector, etc.) just work.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Erik Mouw]

On Wed, Feb 15, 2006 at 09:20:46PM -0500, Jeff Garzik wrote:
> Erik Mouw wrote:
> >On Wed, Feb 15, 2006 at 02:00:46PM -0500, Mark Lord wrote:
> >
> >>Erik Mouw wrote:
> >>
> >>>Hdparm (6.3) needs the TASKFILE ioctl for the ATA security feature set
> >>>(security freeze, security unlock, etc.). I can't find it in Jeff's
> >>>libata-dev tree, is there somebody already working on it? Or is there a
> >>>workaround?
> >>
> >>If that ioctl is missing in libata, then I'll have to convert hdparm
> >>to use SGIO to submit ATA Passthru packets instead for libata devices.
> >
> >
> >If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
> >and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
> >functionality can be accomplished through SGIO ATA Passthru.
> 
> For compatibility :)  The HDIO compat ioctls are implemented internally 
> via the ATA passthru SCSI command.

OK, thanks for the hint.

> Although in general I resist adding compat ioctls, I think avoiding 
> TASKFILE when we have TASK/CMD ioctls would be inconsistent.  If 
> somebody wants to submit a tested patch...

Hmm, I might want to have a try. OTOH, Mark's suggestion to use SG_IO
also makes sense and avoids adding nasty compat ioctls.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Bartlomiej Zolnierkiewicz]

On 2/17/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> On Thu, Feb 16, 2006 at 06:30:04PM +0900, Tejun Heo wrote:
> > Jeff Garzik wrote:
> > >Erik Mouw wrote:
> > >>If SGIO can be used for ATA Passthru, then why are the HDIO_DRIVE_CMD
> > >>and HDIO_DRIVE_TASK ioctl()s implemented in libata? AFAICS, the same
> > >>functionality can be accomplished through SGIO ATA Passthru.
> > >
> > >For compatibility :)  The HDIO compat ioctls are implemented internally
> > >via the ATA passthru SCSI command.
> > >
> > >Although in general I resist adding compat ioctls, I think avoiding
> > >TASKFILE when we have TASK/CMD ioctls would be inconsistent.  If
> > >somebody wants to submit a tested patch...
> >
> > Just a side note.  Taskfile has finer granuality regarding which
> > registers are written and read back than current libata does and IDE
> > taskfile implementation is somewhat broken/weird in a few delicate fun
> > ways, so... be careful.  Whoever tries it.
>
> The few applications that use the TASKFILE ioctl I've seen don't use
> that fine granularity so it might not be necessary.
>
> What kind of delicate broken things are you referring to? The commands
> I've tried so far (identify, read sector, etc.) just work.

Documentation/ioctl/hdio.txt

Somebody can spend his time much more effectively
adding flagged taskfile support to SG_IO...

TASKFILE ioctl will be hopefully removed from drivers/ide
in few months time (and replaced by SG_IO).

Bartlomiej

Re: TASKFILE ioctl for libata?

[Erik Mouw]

On Fri, Feb 17, 2006 at 03:38:22AM -0500, Jeff Garzik wrote:
> Tejun Heo wrote:
> >Just a side note.  Taskfile has finer granuality regarding which 
> >registers are written and read back than current libata does and IDE 
> >taskfile implementation is somewhat broken/weird in a few delicate fun 
> >ways, so... be careful.  Whoever tries it.
> 
> Yes -- it opens the question about whether we care enough to fully 
> support flagged taskfiles, and if not, how to best emulate that support 
> under libata.
> 
> I'm told that flagging individual ATA shadow registers for modification 
> (or not) is required for issuing certain specialized PATA 
> vendor-specific commands.  SATA, OTOH, transmits all ATA shadow 
> registers in a FIS, so flagged taskfiles are useless.

I'd have to look at our own software to see if it's required or not.
For PATA it doesn't really matter, you can always fiddle the registers
using inb() and outb().

You're right about SATA, it doesn't make sense to use flagged
taskfiles.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Erik Mouw]

On Fri, Feb 17, 2006 at 06:15:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On 2/17/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> > What kind of delicate broken things are you referring to? The commands
> > I've tried so far (identify, read sector, etc.) just work.
> 
> Documentation/ioctl/hdio.txt

I actually meant "broken things beyond what is documented in hdio.txt"
;-)

> TASKFILE ioctl will be hopefully removed from drivers/ide
> in few months time (and replaced by SG_IO).

Note that there are two widely used programs that use TASKFILE: hdparm
and smartcl. We'd rather don't have many complaining users on this list
(or on linux-kernel), so please put the announcement in
Documentation/feature-removal-schedule.txt .


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: TASKFILE ioctl for libata?

[Bartlomiej Zolnierkiewicz]

On 2/17/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> On Fri, Feb 17, 2006 at 06:15:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On 2/17/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> > > What kind of delicate broken things are you referring to? The commands
> > > I've tried so far (identify, read sector, etc.) just work.
> >
> > Documentation/ioctl/hdio.txt
>
> I actually meant "broken things beyond what is documented in hdio.txt"
> ;-)

OK :)

Support for LBA48 PIO/DMA transfers.

> > TASKFILE ioctl will be hopefully removed from drivers/ide
> > in few months time (and replaced by SG_IO).
>
> Note that there are two widely used programs that use TASKFILE: hdparm
> and smartcl. We'd rather don't have many complaining users on this list
> (or on linux-kernel), so please put the announcement in
> Documentation/feature-removal-schedule.txt .

Sure.

Bartlomiej

Re: TASKFILE ioctl for libata?

[Timothy Thelin]

On Fri, 2006-02-17 at 03:38 -0500, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Just a side note.  Taskfile has finer granuality regarding which 
> > registers are written and read back than current libata does and IDE 
> > taskfile implementation is somewhat broken/weird in a few delicate fun 
> > ways, so... be careful.  Whoever tries it.
> 
> Yes -- it opens the question about whether we care enough to fully 
> support flagged taskfiles, and if not, how to best emulate that support 
> under libata.
> 
> I'm told that flagging individual ATA shadow registers for modification 
> (or not) is required for issuing certain specialized PATA 
> vendor-specific commands.  SATA, OTOH, transmits all ATA shadow 
> registers in a FIS, so flagged taskfiles are useless.
> 
> So, I'm now thinking the best route is to leave the code as it is ;-) 
> Rather than imperfectly implementing the flagged taskfile ioctl, punt 
> the remaining userland users to SG_IO.
> 
> I don't see lack of full flagged taskfile support as a big stumbling 
> block to libata use.
> 
> 	Jeff

FYI, Western Digital doesn't need flagged taskfile access to use its
vendor specific commands; SAT passthru works fine (although we'd
appreciate more of the protocols implemented, or at least a way to
discover at runtime which ones are implemented before trying to use
them).

- Tim Thelin