Re: [PATCH] dpt_i2o changes for 2.6.2 kernel in support of 64 bit and bitrot (part 1)

[Christoph Hellwig <hch@infradead.org>]

On Tue, Apr 06, 2004 at 10:03:58AM -0400, Salyzyn, Mark wrote:
> OEMs and their users are virtually *all* we are concerned about. If we can not qualify our products within their needs, we disappear, or at least we disappear on operating systems that fail to provide for the needs of the users.

Well, bad luck for adaptec then.  It's not like there aren't other RAID HBA
vendors.

> I loose sleep at night thinking about these poor souls. No, to be honest, actually it is because our OEM's test group thinks out fantastic scenarios of ways to break yours and my products and hold us accountable for such failures. "Deleting array causes kernel ooops" news at 11 ...

Again, where do you see that oops?  if I remove the lun under a filesystem
that one spews EIO all over and becomes unusable.  But if you get a panic
that's a bug in the filesystem driver.

> Which reason do we ascribe to this failure of the operating system to provide the service of knowing if a drive is currently in-use:
> 
> 1) system has been architected in such a manner that it would be impossible at this juncture to add?
> 2) Someone made a conscientious decision to not provide this functionality?
> 3) There is a way to tell, it just is not clear to any of us at this moment?
> 4) There is a way to tell, but it would be an ugly hack that will no doubt break upon the next revision (as this hack has done traversing from 2.4 to 2.6)?
> 5) Pride?

There is a way to tell whether it's inuse, but it's a different defintion of
inuse than you want, and it's not a public interface so it could break all
the time.  Probably as soon as some out of tree driver gets the bright idea
to use it inspite everyone telling them not to.