Re: dpt_i2o driver

['Christoph Hellwig' <hch@infradead.org>]

On Tue, Sep 02, 2003 at 12:41:52PM -0400, Salyzyn, Mark wrote:
> 'Christoph Hellwig' [mailto:hch@infradead.org] writes:
> >> 	- use_new_eh_code was initialized thus because some kernels would
> >> have
> >> 	  the (smp) lock, but not the (up) interrupts disabled; by
> >> initializing
> >> 	  after the fact one got consistent io_request_lock behavior. Will
> >> need
> >> 	  to instrument and test the current crop of kernels I build for to
> >> see
> >> 	  if this issue is no longer there.
> >-ENOCONTEXT.  Can you quote what this is the reply to?
> 
> Context of dropping manual initialization of use_new_eh_code and proc_dir in
> the detect code. The former was a result of a workaround for some errant
> kernel trees; the later was a `mistake' resulting from the structure member
> not being present in all trees thinking that was the only reason for the
> use_new_eh_code's original inclusion. A hack with a penalty, will need to
> dehack and make sure the problem is not present in modern kernels.

Ah, okay.  I'm pretty sure 2.2 and 2.4 took io_request_lock with local
irqs disabled and 2.6 doesn't take it at all.  But who knows what fucked
up vendor trees are around..

> Hmmm, lets just delete this (mounted) array. I want to take this (mounted)
> drive to expand an array's capacity. This call is used to inform the user
> that the action that one is about to be asked to perform is being blocked
> because it would cause damage to the operating system.

In Linux 2.6 userspace should get hotplug events as soon as the the last
reference is gone and the device is deleted.  As the device is freed at
the same time you ioctl won't find it anymore anyway and thus fail..

The hotplug even is picked up by the hotplug script which currently
unfortunately are distro-specific.