All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Tejun Heo <htejun@gmail.com>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: Random libata comments...
Date: Mon, 22 May 2006 19:55:10 -0400	[thread overview]
Message-ID: <44724F5E.1050007@garzik.org> (raw)
In-Reply-To: <44724D4E.5010506@gmail.com>

Tejun Heo wrote:
> Jeff Garzik wrote:
>>
>> * I agree with others that using the "ata_drive_probe_reset" can lead 
>> to confusion on the uses of the word "drive".  Replacing that with 
>> "do" or something else would be nice.
> 
> Will do.
> 
>> * As the ata_drive_probe_reset argument list continues to grow, I lean 
>> more and more towards moving all those function pointers to struct 
>> ata_port_operations.  One of the problems with the drivers/ide layer 
>> IMO is that the list of all hooks used is not immediately clear upon 
>> first read, whereas with libata it is clear -- with the notable 
>> exception of ata_drive_probe_reset().
> 
> ->error_handler() takes over all of ata_drive_probe_reset() after 
> hotplug patchset and all ->probe_reset() related stuff are killed.  The 
> same applies to ->error_handler() though.  I agree with you that the 
> arguments are ugly, but also there are already too many non-essential 
> operations in ata_port_operations.  I was hoping something can be done 
> to resolve both issues.
> 
> I'm okay with moving reset ops into ata_port_operations but we need to 
> do more than that, IMHO.

For one example of that, BMDMA-specific operations need to be moved out 
of ata_port_operations, to a BMDMA-driver-specific API.  Ultimately 
libata should be a high level ->qc_issue/ata_qc_complete() style API 
exclusively.

	Jeff




      reply	other threads:[~2006-05-22 23:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-22 23:26 Random libata comments Jeff Garzik
2006-05-22 23:46 ` Tejun Heo
2006-05-22 23:55   ` Jeff Garzik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44724F5E.1050007@garzik.org \
    --to=jeff@garzik.org \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.