Tejun Heo wrote:
Heh... Maybe I'm just reluctant to let go of my patches. Anyways, I'll
now stand down and see how things go and try to help.
Note that my email simply describes a long term target. For the short
term, and perhaps medium term, libata will continue to use
->eh_strategy_hand
Hi, Jeff.
Jeff Garzik wrote:
Tejun,
In an email I cannot find anymore, you asked why I was interested in
converting libata to use the fine-grained EH hooks in the SCSI layer,
rather than continued with the current ->eh_strategy_handler() method.
Several reasons:
1) The fine-grained hook
Tejun,
In an email I cannot find anymore, you asked why I was interested in
converting libata to use the fine-grained EH hooks in the SCSI layer,
rather than continued with the current ->eh_strategy_handler() method.
Several reasons:
1) The fine-grained hooks of the SCSI layer are somewhat
On 08/18/05 14:48, [EMAIL PROTECTED] wrote:
>
> This is a heck of a statement... The customers don't see it as SAS vs FC
> vs SPI, they just see it as SCSI, and there's a lot of expectations on
> consistent behavior. We take a lot of heat defending the community's
> position, even from companies t
On 08/18/05 13:56, Christoph Hellwig wrote:
> I was trying to avoid the need for an rport object, but I'm not yet sure
> it's feasible. We certainly won't put in target-persistency support
> similar to FC, that was just a hack to get the existing drivers migrated
> without lots of complaints, it's
On 8/18/05, Greg KH <[EMAIL PROTECTED]> wrote:
> @@ -500,9 +519,13 @@ int class_device_add(struct class_device
>}
>
>class_device_add_attrs(class_dev);
> - if (class_dev->dev)
> + if (class_dev->dev) {
> + class_name = make_class_name(class_dev);
>
On 08/17/05 18:45, James Bottomley wrote:
> I admit that the whole thing will get hugely complex if configuration
> becomes allowable via this class, but at the moment I'm just trying to
> get at useful information display ... configuration can come later.
James are you saying that you do not have
[EMAIL PROTECTED] wrote:
What we might need an rport for is to support SMP. I'm
not yet sure how to do SMP passthrough, but we will need some object
to represent SMP ports.
Depending on how SATA support is implemented, it may be useful for that.
You can already see how SATA support is impl
> I was trying to avoid the need for an rport object, but I'm
> not yet sure
> it's feasible. We certainly won't put in target-persistency support
> similar to FC, that was just a hack to get the existing
> drivers migrated
> without lots of complaints, it's not going in for new transports like
On Thu, Aug 18, 2005 at 10:02:21AM -0400, [EMAIL PROTECTED] wrote:
> In tracking how you were using the patch, it highlighted that you
> were skipping a step. The api is such that it does not expect remote
> SAS ports to be instantiated. They should have be (just like FC).
> Your api is written
One more thing missing...
As there is a transport object between the scsi_host and scsi_target,
the transport needs to pick up the changes made to deal with scans
made outside of the transport (after a scsi_target has been removed).
The fix that got merged into the scsi-misc tree can be seen at:
Index: scsi-misc-2.6/drivers/message/fusion/lsi/mpi_cnfg.h
===
--- scsi-misc-2.6.orig/drivers/message/fusion/lsi/mpi_cnfg.h2005-08-17
12:03:52.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/lsi/mpi_cnfg.h 2005-08-17
12:
This brings over some updates from LSIs driver that will be needed
for SAS support.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: scsi-misc-2.6/drivers/message/fusion/mptbase.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptbase.c 2005-08-18
15:24:27.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptbase.c 2005-08-18
15:24:28.000
Index: scsi-misc-2.6/drivers/message/fusion/mptspi.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptspi.c 2005-08-17
19:46:11.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptspi.c 2005-08-17
19:46:46.
Assorted endianess fixes. I'll work on full endianess annotations
later.
Index: scsi-misc-2.6/drivers/message/fusion/mptbase.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptbase.c 2005-08-17
19:47:15.0 +0200
+++ scsi
I don't agree with the need for this patch.
See http://marc.theaimsgroup.com/?l=linux-scsi&m=112437379823295&w=2
I think it's also a wart to add this to the scan logic, and error prone.
The error (or inconsistency) exists when the scan is not initiated by
the transport, and the target doesn't exi
Ok, so I'm going to have to revert my statement. After perusing the
sas transport, I went to the previous patch, which added pre-init
data to scsi_scan_target calls. I didn't understand why this was
needed.
In tracking how you were using the patch, it highlighted that you
were skipping a step.
On Wed, Aug 17, 2005 at 06:45:25PM -0400, James Bottomley wrote:
> > Add hotspare-0, hotspare-1 ... to the list?
>
> Yes ... I only have two disks though, so I've reached the limit of what
> I can do with my current fusion setup. The whole of the component
> display has to be reworked anyway (I o
Christoph,
I like it, and have no real complaints.
As familiar as this looks, there were a couple of conventions in the FC
transport that I thought should have carried over here. Namely, I saw
not all attributes being the same, thus I created 3 categories of
attributes:
Private:
These are
On Thu, Aug 18, 2005 at 12:04:42AM -0700, Greg KH wrote:
> Matthew, this work for you?
Yep, that's fine by me. Thanks.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will
I can live with this. I would have liked the "class:" prefix, but the name
does start to get long, and this is ok.
-- james s
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 18, 2005 2:37 AM
> To: James Bottomley
> Cc: Matthew Wilcox; Smart, James;
> They are class devices called ttyS0, ttyS1, ttyS2 so you can say
> they're uniquely named.
>
> The problem is that Matthew wants to add a symlink from the device
> device to the class device to complement the class device to device
> symlink, since we end up with multiple symlinks in the devices
On Thu, Aug 18, 2005 at 07:50:27AM +0100, Russell King wrote:
> On Wed, Aug 17, 2005 at 11:41:29PM -0700, Greg KH wrote:
> > On Thu, Aug 18, 2005 at 07:30:50AM +0100, Russell King wrote:
> > > On Wed, Aug 17, 2005 at 10:21:56PM -0700, Greg KH wrote:
> > > > On Mon, Aug 15, 2005 at 09:32:44AM +0100,
24 matches
Mail list logo
