From: Christoph Hellwig <hch@infradead.org>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [RFC] first cut at infrastructure for handling different device types in the sas class
Date: Sat, 4 Mar 2006 15:47:06 +0000 [thread overview]
Message-ID: <20060304154706.GA14174@infradead.org> (raw)
In-Reply-To: <1141445103.5397.19.camel@mulgrave.il.steeleye.com>
On Fri, Mar 03, 2006 at 10:05:03PM -0600, James Bottomley wrote:
> This one actually does the end devices, since that's all I really have
> to work with in my setup. However, I can do the expanders in the same
> way. The idea is to make the rphy embedded in the enveloping device
> structure, so the code which doesn't care about type can still treat the
> code as a simple rphy, and the code that does care can cast out to the
> device type.
>
> Temporarily, because mptsas doesn't do this, I've put a flag in to
> indicate whether the rphy is enveloped or not, however, if we enforce
> this for everything, then eventually that would go away.
Looks good in general, but we should probably kill the rphy naming. That was
my invention when doing the transport class, when I still thought we'd add a
remote object for every phy in wide links. We ended up having just a remote
object only under one of the phys for a wide link so we should probably
kill this naming invention. In the end we should probably just have
a sas_end_device, sas_expander and sas_sata_device (or just sata_device
if we can share code with libata) and the common subset (sas_device?)
shouldn't be exposed to userland on it's own.
> /**
> + * sas_rphy_end_device_alloc - allocate an rphy for an end device
> + *
> + * Allocates an SAS remote PHY structure, connected to @parent.
> + *
> + * Returns:
> + * SAS PHY allocated or %NULL if the allocation failed.
> + */
> +struct sas_rphy *sas_rphy_end_device_alloc(struct sas_phy *parent)
this should become sas_end_device_alloc, and so on for the other
functions.
next prev parent reply other threads:[~2006-03-04 15:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-04 4:05 [RFC] first cut at infrastructure for handling different device types in the sas class James Bottomley
2006-03-04 8:28 ` Luben Tuikov
2006-03-04 15:47 ` Christoph Hellwig [this message]
2006-03-04 18:33 ` James Bottomley
2006-03-05 3:42 ` Luben Tuikov
2006-03-04 18:17 ` [RFC] first cut at infrastructure for handling different devicetypes " Moore, Eric
2006-03-06 16:39 ` James Bottomley
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=20060304154706.GA14174@infradead.org \
--to=hch@infradead.org \
--cc=James.Bottomley@SteelEye.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).