On 10/20/05 12:01, Christoph Hellwig wrote:
>
> As you mentioned doing link reset and reporting stats on expanders
> is done using SMP, and thus totally independent of the driver used.
Not quite. "Dispatching to" would be driver dependent. If you implement
sdi_register_provider(struct ...); then you can make everyone happy
in the _shortest_ amount of time.
I'd suggest a reading of the SDI, SAS and SAM specs for an insight
of how it all ties together.
> It should be either implemented in the transport class or in userland.
> Doing it in the transport class has the advantage of a unified interface
> for hba phys and expander phys, doing it in userland has the advantage
> of less kernel bloat.
You already know the answer to that.
"customers" and "customer satisfaction" is a foreign
concept with the community, being the nature of Linux as it is,
but what you should want to is:
- make less applications (which you may not know of)
break,
- make less assumptions already taken break.
Those applications are already using SDI and only the interface
would change ("/dev/sg") if you were to implement
drivers/scsi/sdi.c.
> I've done a prototype using an SG_IO interface, but I'm not totally
> happy about.
Care to say why?
> I've also seen lubens interface and I'm not totally
> happy about it either.
Care to say why?
> Getting the interface right for SMP passthru is very hard.
1) You have the SDI spec which _tells you_ how to do it.
2) There are (HP) applications which already use that (1).
You have to stay focused on _what is required_.
Why are you trying to reinvent "SMP passthrough"?
Why not just make the customers happy?
If you implement drivers/scsi/sdi.c, as:
int sdi_register_provider(struct sdi_provider_struct *sdi_prov);
void sdi_unregister_provider(struct sdi_provider_struct *sdi_prov);
everyone will be _more than happy_ to plug right into it.
And those are the only 2 functions you need to EXPORT_SYMBOL_GPL.
Everything else (SDI_ functions) would be in the struct as stubs
and the provider would set them if they implement them.
LSI/HP can plug right into it with *minimum of overhead*,
testing etc, both from their application side and from kernel
side. And this is important to both customers and companies.
Luben
--
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/
-
: 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
