All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Jeff Garzik <jeff@garzik.org>, linux-ide <linux-ide@vger.kernel.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexis Bruemmer <alexisb@us.ibm.com>,
	Mike Anderson <andmike@us.ibm.com>
Subject: Re: [PATCH v3] libsas: move ATA bits into a separate module
Date: Thu, 14 Sep 2006 15:40:55 -0700	[thread overview]
Message-ID: <4509DA77.7000508@us.ibm.com> (raw)
In-Reply-To: <450971D3.2040405@garzik.org>

Jeff Garzik wrote:

> I disagree completely with this approach.
> 
> You don't need a table of hooks for the case where libata is disabled in
> .config.  Thus, it's only useful for the case where libsas is loaded as
> a module, but libata is not.

Indeed, I misunderstood what James Bottomley wanted, so I reworked the
patch.  It has the same functionality as before, but this module uses
the module loader/symbol resolver for all the functions in libata, and
allows libsas to (optionally) call into sas_ata with weak references by
pushing a table of the necessary function pointers into libsas at
sas_ata load time.  Thus, libsas doesn't need to load libata/sas_ata
unless it actually finds a SATA device.

> The libsas code should directly call libata functions.  If ATA support
> in libsas is disabled in .config, then those functions will never be
> called, thus never loaded the libata module.

I certainly can (and now do) call libata functions from sas_ata.
However, there are a few cases where libsas needs to call libata (ex.
sas_ioctl); for those cases, I think the function pointers are still
necessary because I don't want to make libsas require libata.  In any
case, if ATA support is disabled in .config, sata_is_dev always returns
0, so the dead-code eliminator should zap that out of libsas entirely.

As usual, thank you for any feedback that you have.

Link to version 3:
http://sweaglesw.net/~djwong/docs/sas-ata_3.patch

--D

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>

  reply	other threads:[~2006-09-14 22:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-14  0:21 [PATCH] libsas: move ATA bits into a separate module Darrick J. Wong
2006-09-14 15:14 ` Jeff Garzik
2006-09-14 22:40   ` Darrick J. Wong [this message]
2006-09-14 22:49     ` [PATCH v3] " Jeff Garzik
2006-09-18 19:00     ` Christoph Hellwig
2006-09-18 21:47       ` Jeff Garzik
2006-09-18 18:59 ` [PATCH] " Christoph Hellwig

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=4509DA77.7000508@us.ibm.com \
    --to=djwong@us.ibm.com \
    --cc=alexisb@us.ibm.com \
    --cc=andmike@us.ibm.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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.