[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0F5B06BAB751E047AB5C87D1F77A77885CA68ED159@GVW0547EXC.americas.hpqcorp.net>
Date: Fri, 6 Mar 2009 20:00:30 +0000
From: "Miller, Mike (OS Dev)" <Mike.Miller@...com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <jens.axboe@...cle.com>,
LKML <linux-kernel@...r.kernel.org>,
LKML-scsi <linux-scsi@...r.kernel.org>,
"coldwell@...hat.com" <coldwell@...hat.com>,
"mikem@...rdog.cca.cpqcorp.net" <mikem@...rdog.cca.cpqcorp.net>
Subject: RE: [PATCH 1/2] resubmit cciss: kernel thread to detect changes on
MSA2012
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> Sent: Friday, March 06, 2009 12:24 PM
> To: Miller, Mike (OS Dev)
> Cc: Andrew Morton; Jens Axboe; LKML; LKML-scsi;
> coldwell@...hat.com; mikem@...rdog.cca.cpqcorp.net
> Subject: Re: [PATCH 1/2] resubmit cciss: kernel thread to
> detect changes on MSA2012
>
> On Fri, 2009-03-06 at 12:16 -0600, Mike Miller wrote:
> > Patch 1 of 2
> >
> > This is a resubmission of yesterdays patch to detect
> changes on the MSA2012.
> > I hope I've addressed all concerns. This patch rearranges
> some of the
> > code so we also have coverage in the sg and the ioctl paths
> as well as
> > the main data path.
> >
> > The MSA2012 cannot inform the driver of configuration changes since
> > all management is out of band. This is a departure from any
> storage we
> > have supported in the past. We need some way to detect
> changes on the
> > topology so we implement this kernel thread. In some
> instances there's
> > nothing we can do from the driver (like LUN failure) so
> just print out
> > a message. In the case where logical volumes are added or
> deleted we
> > call rebuild_lun_table to refreash the driver's view of the world.
> >
> > Please consider this for inclusion.
>
> I still don't quite see how the thread stops on module
> removal ... there needs to be an explicit kthread_stop()
> somewhere in the clean up path.
>
I thought that was probably needed, duh. Is there anything else I should address at the same time?
-- mikem--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists