>> That's unfortunate for those using ATA. A command submitted from userland > > Required, since one cannot know the data phase of vendor-specific commands. So you are saying that this presents an unrecoverable situation? > Particularly, checking whether the kernel is doing something wrong, or wrong, > just wastes cycles. That's not a scalable way to code... if every driver > and Linux subsystem did that, things would be unbearable slow. Hmm. I've never had someone tell me that my SCSI drivers are slow. I don't think that your statement is true in the general case. My belief is that validation should occur where it is cheap and efficient to do so. More expensive checks should be pushed into diagnostic code that is disabled by default, but the code *should be there*. In any event, for RAID meta-data, we're talking about code that is *not* in the common or time critical path of the kernel. A few dozen lines of validation code there has almost no impact on the size of the kernel and yields huge benefits for debugging and maintaining the code. This is even more the case in Linux the end user is often your test lab. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
