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
prev parent 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.