Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Oct 2002 05:26:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Oct 2002 05:26:03 -0400 Received: from mail.zedat.fu-berlin.de ([130.133.1.48]:47141 "EHLO Mail.ZEDAT.FU-Berlin.DE") by vger.kernel.org with ESMTP id ; Fri, 4 Oct 2002 05:25:58 -0400 Message-Id: Content-Type: text/plain; charset=US-ASCII From: Oliver Neukum To: Greg KH Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5 Date: Fri, 4 Oct 2002 10:07:24 +0200 X-Mailer: KMail [version 1.3.2] Cc: Alexander Viro , Kevin Corry , linux-kernel@vger.kernel.org, evms-devel@lists.sourceforge.net References: <20021003161320.GA32588@kroah.com> <20021003225635.GE2289@kroah.com> In-Reply-To: <20021003225635.GE2289@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2462 Lines: 55 On Friday 04 October 2002 00:56, Greg KH wrote: > On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote: > > Perhaps this is a misunderstanding. > > You need to report changes of the actual physical medium of eg. a zip > > drive. How you want to do this from a class driver, I fail to see. > > When a "medium" goes away from the system, it is unregistered somehow, > right? So, in the disk class, that device would disappear, and cause > the /sbin/hotplug event. Well, sadly this is not the case. You can put a medium into a drive and pull it out without the kernel ever noticing. Unless of course you try to use the thing. But even in this case there's no hotplug event. Yet user space and evms have to learn about it in the long term. Changing a medium can mean that a new type of medium is inserted. A modern zip drive goes from 100M(ro) to 250M(rw) and even 750M(rw) We need to know and report. > This is assuming that we can detect media changes, which is a whole > different topic that I don't want to get involved with :) Your wishes you are entiteled to ;-) Unfortunately this is not a viable position speaking long term. > > Beside that you need of course to report things like iscsi which have > > volumes, but not really devices. > > But iscsi registers these "volumes" with the scsi layer, right? If so, > everything is fine (take a look at the driverfs scsi tree right now, > it's a bit messy, but you get the idea.). If iscsi doesn't register > these volumes with the scsi layer, how does the scsi layer know to talk > to them? I'll look at the source. > In other words, if the kernel knows about a type of device, which I'm > pretty sure it has to in order to talk to it, that device will generate > /sbin/hotplug events when it shows up and is removed. > > As for implementation details, if you see a type of device right now > that does not generate these kinds of events, please let me know. Device management is all right, but volume management operates at the medium level, or rather in between. What do you do if somebody adds drives to a SCSI-RAID converter. Evms currently polls on demand. I see no way to do it differently with the present infrastructure. Regards Oliver - 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/