On Thu, 2005-06-09 at 17:27 -0600, Moore, Eric Dean wrote: > Are you considering this for inclusion into the kernel? No, that's why I said in the email: > This code is more posted as an illustration of how to do > things than an > actual patch for submission. However, I've tested this and it does > actually work: > (1)We need to hold off on that till we sort out supporting > integrated raid first in the spi transport. Also, can the transport > support receiving asyn event form scsi lld for triggering dv on disk that > was just added to degraded volume(raid 1)? Also queising IO to > the volume, is that supported; I believe that is, but just asking. I thought the idea was we'd use the no_uld_attach flag. dv can be triggered from any event in the driver (it needs user context, but there's a spi_schedule_dv_device that works from irq context via workqueues). And yes, quiescing is supported. > (2) Does this patch dependent on the previous patch to work; e.g. > "update spi transport class so that u320 Domain Validation works" > Just wondering if there were any backward compatibility for this patch this > to work. Yes, it was the engine I used to validate the work. > (3) I need to review our source to confirm what work arounds in our code are > going to be > backed out by using your generic dv. I know of sep devices known to freeze > the bus > when too large inquiry data is requested. Wondering if generic dv will > freeze the bus. > Also known are mixed mode devices on the bus getting starved when qas is > enabled, > e.g. u320 and non-u320 disk devices on same bus. > I'm not sure whether generic dv is disabling qas in that case. > I think there are other concerns, I will have to check and post them later. I think you'll find the generic code is incredibly careful about inquiry lengths. DV is to a single device, it's hardly able to tell if there's a qas/non- qas starvation issue. However, with the transport class, QAS policy becomes the province of the user. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
