Message-Id: <200210302042.g9UKgLS02419@localhost.localdomain>
To: Steven Dake <sdake@mvista.com>
cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org,
       linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SCSI and FibreChannel Hotswap for linux 2.5.44-bk2 
In-Reply-To: Message from Steven Dake <sdake@mvista.com> 
   of "Wed, 30 Oct 2002 11:54:47 MST." <3DC02AF7.6020209@mvista.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 30 Oct 2002 15:42:21 -0500
From: James Bottomley <James.Bottomley@steeleye.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1327
Lines: 32

sdake@mvista.com said:
>  This patch has been reviewed by Alan Cox, Greg KH, Christoph Hellwig,
>  Patrick Mansfield, Rob Landly, Jeff Garzik, Scott Murray, James
> Bottomley, Mike Anderson, Randy Dunlap and Patrick Mochel. 

Well, I reviewed it but my though was that it should be built on the emerging 
hotplug infrastructure.

I'm currently trying to move things like this into the user layer, so from a 
design principle I don't want to have 90% using the user space stuff and 10% 
using its in-kernel equivalent because that means we have two mechanisms to 
maintain, thus doubling the work.

The problem you had with this was the 10ms requirement from removal 
notification to removal completion.  Several people have already suggested 
that if that really is a hard and fast requirement, then you could simply 
treat the removal as a surprise removal rather than a planned one and work on 
fixing our surprise removal problems instead.

The bottom line is that I'm not convinced this can't be done using the 
existing infrastructure or a generic enhancement to it.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/