From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39F5EC56202 for ; Wed, 18 Nov 2020 09:32:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFEA320855 for ; Wed, 18 Nov 2020 09:32:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="fFTiyRf+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725823AbgKRJcS (ORCPT ); Wed, 18 Nov 2020 04:32:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:50370 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725772AbgKRJcR (ORCPT ); Wed, 18 Nov 2020 04:32:17 -0500 Received: from localhost (unknown [89.205.136.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 651A320855; Wed, 18 Nov 2020 09:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1605691936; bh=z9AARqxEifx27ZSfSqyQtp5/QTEI/AENwIGCm/wc71c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fFTiyRf+lNKL9ST4txcSeaDrCIqy8sGZqtdcsNAnsGly1+5GYCQkd5b0dJtsVNXW7 Ty+UOKz4POaIjvZvW72SkGo52lChY2pkhIjug9dEhWmDqtz52fKjvNwDSvPQKw5/EX XjQbNqUIRf7iTd7GfCLBQpWa8uhdec/9xDR/QuiU= Date: Wed, 18 Nov 2020 10:32:12 +0100 From: Greg KH To: Jan Beulich Cc: Christoph Hellwig , Tejun Heo , Josef Bacik , Konrad Rzeszutek Wilk , Coly Li , Mike Snitzer , dm-devel@redhat.com, Richard Weinberger , Jan Kara , linux-block@vger.kernel.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Jens Axboe Subject: Re: merge struct block_device and struct hd_struct Message-ID: References: <20201118084800.2339180-1-hch@lst.de> <22ca5396-0253-f286-9eab-d417b2e0b3ad@suse.com> <20201118085804.GA20384@lst.de> <1ded2079-f1be-6d5d-01df-65754447df78@suse.com> <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote: > On 18.11.2020 10:09, Greg KH wrote: > > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote: > >> On 18.11.2020 09:58, Christoph Hellwig wrote: > >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote: > >>>> since this isn't the first series from you recently spamming > >>>> xen-devel, may I ask that you don't Cc entire series to lists > >>>> which are involved with perhaps just one out of the many patches? > >>>> IMO Cc lists should be compiled on a per-patch basis; the cover > >>>> letter may of course be sent to the union of all of them. > >>> > >>> No way. Individual CCs are completely broken as they don't provide > >>> the reviewer a context. > >> > >> That's the view of some people, but not all. Context can be easily > >> established by those who care going to one of the many archives on > >> which the entire series lands. Getting spammed, however, can't be > >> avoided by the dozens or hundreds of list subscribers. > > > > kernel patches are never "spam", sorry, but for developers to try to > > determine which lists/maintainers want to see the whole series and which > > do not is impossible. > > > > Patches in a series are easily deleted from sane mail clients with a > > single click/keystroke all at once, they aren't a problem that needs to > > be reduced in volume. > > This doesn't scale, neither in the dimension of recipients nor in > the dimension of possible sources of such series. Again, trying to figure out what subsystem does, and does not, want stuff like this does not scale either. Remember, we had 4000 developers last year, how are you going to tell all of them what the special rules are for your subsystem and how they differ from any other subsystem? And why does it matter? We are all working on the same project, why wouldn't you want to see core block device handling patches? What hurts with that, someone might notice something in one of them that a different developer did not. > While it may seem small, it's also a waste of resources to have mails > sent to hundreds of even thousands of people. So while from a > technical content perspective I surely agree with you saying 'kernel > patches are never "spam"', they still are from the perspective of > what "spam mail" originally means: Mail the recipients did not want > to receive. Anyone on a kernel subsystem mailing list should expect to see kernel patches, that's part of the process, and always has been. Kernel subsystems are not silos, people on them should be aware of what else is going on in order to stay informed. And again, if it's a huge problem, one click/keystroke and they are gone, no waste. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DB4FC5519F for ; Wed, 18 Nov 2020 09:33:26 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D73AB20855 for ; Wed, 18 Nov 2020 09:33:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="g0HoATRc"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="fFTiyRf+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D73AB20855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wGgDTZ6Sg+TLBM+Hz48frfnpq+W8C0rfmljxEYvBQwA=; b=g0HoATRci+4rj0GK7Z9a26Otz nRRMOiAgWcmnpqzPvKf2gfzcjgU05KQYH4datDPa/3FEPIsVw5dN1bdQnDv4Z+YesYozHGm1Kf8rZ gYxnYJhJf7yu9OVJY0UR9JubcuWT59nnoBwrLBZ9gYTBukNaNVXwNfC8G9qAWkY5qj3Cn+qsXFZBs RIAp+QG6m010dQKggIEhqMtVDaLybYOQZivM93PIaozaYNA4PbMMa/B6a62w5F6Sb1sICrIBcglWr m4CeddLhHYlhocgorVSwtdBlxcCUqDnR0ZaVunZTyiJrzyHP1HNk/0pNB9vboJipNqBXbdLlcyw1+ 77LMtKlRw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfJp5-0003oU-K8; Wed, 18 Nov 2020 09:32:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfJp3-0003o7-GX for linux-mtd@lists.infradead.org; Wed, 18 Nov 2020 09:32:18 +0000 Received: from localhost (unknown [89.205.136.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 651A320855; Wed, 18 Nov 2020 09:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1605691936; bh=z9AARqxEifx27ZSfSqyQtp5/QTEI/AENwIGCm/wc71c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fFTiyRf+lNKL9ST4txcSeaDrCIqy8sGZqtdcsNAnsGly1+5GYCQkd5b0dJtsVNXW7 Ty+UOKz4POaIjvZvW72SkGo52lChY2pkhIjug9dEhWmDqtz52fKjvNwDSvPQKw5/EX XjQbNqUIRf7iTd7GfCLBQpWa8uhdec/9xDR/QuiU= Date: Wed, 18 Nov 2020 10:32:12 +0100 From: Greg KH To: Jan Beulich Subject: Re: merge struct block_device and struct hd_struct Message-ID: References: <20201118084800.2339180-1-hch@lst.de> <22ca5396-0253-f286-9eab-d417b2e0b3ad@suse.com> <20201118085804.GA20384@lst.de> <1ded2079-f1be-6d5d-01df-65754447df78@suse.com> <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201118_043217_769211_1616C469 X-CRM114-Status: GOOD ( 27.57 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-bcache@vger.kernel.org, Jens Axboe , Mike Snitzer , Konrad Rzeszutek Wilk , Richard Weinberger , Josef Bacik , Coly Li , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@redhat.com, linux-mtd@lists.infradead.org, linux-mm@kvack.org, Jan Kara , Tejun Heo , xen-devel@lists.xenproject.org, Christoph Hellwig Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote: > On 18.11.2020 10:09, Greg KH wrote: > > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote: > >> On 18.11.2020 09:58, Christoph Hellwig wrote: > >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote: > >>>> since this isn't the first series from you recently spamming > >>>> xen-devel, may I ask that you don't Cc entire series to lists > >>>> which are involved with perhaps just one out of the many patches? > >>>> IMO Cc lists should be compiled on a per-patch basis; the cover > >>>> letter may of course be sent to the union of all of them. > >>> > >>> No way. Individual CCs are completely broken as they don't provide > >>> the reviewer a context. > >> > >> That's the view of some people, but not all. Context can be easily > >> established by those who care going to one of the many archives on > >> which the entire series lands. Getting spammed, however, can't be > >> avoided by the dozens or hundreds of list subscribers. > > > > kernel patches are never "spam", sorry, but for developers to try to > > determine which lists/maintainers want to see the whole series and which > > do not is impossible. > > > > Patches in a series are easily deleted from sane mail clients with a > > single click/keystroke all at once, they aren't a problem that needs to > > be reduced in volume. > > This doesn't scale, neither in the dimension of recipients nor in > the dimension of possible sources of such series. Again, trying to figure out what subsystem does, and does not, want stuff like this does not scale either. Remember, we had 4000 developers last year, how are you going to tell all of them what the special rules are for your subsystem and how they differ from any other subsystem? And why does it matter? We are all working on the same project, why wouldn't you want to see core block device handling patches? What hurts with that, someone might notice something in one of them that a different developer did not. > While it may seem small, it's also a waste of resources to have mails > sent to hundreds of even thousands of people. So while from a > technical content perspective I surely agree with you saying 'kernel > patches are never "spam"', they still are from the perspective of > what "spam mail" originally means: Mail the recipients did not want > to receive. Anyone on a kernel subsystem mailing list should expect to see kernel patches, that's part of the process, and always has been. Kernel subsystems are not silos, people on them should be aware of what else is going on in order to stay informed. And again, if it's a huge problem, one click/keystroke and they are gone, no waste. thanks, greg k-h ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11307C56202 for ; Wed, 18 Nov 2020 09:32:39 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5F75F20855 for ; Wed, 18 Nov 2020 09:32:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F75F20855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-rZdONjJwOmONloHNqd8u9g-1; Wed, 18 Nov 2020 04:32:31 -0500 X-MC-Unique: rZdONjJwOmONloHNqd8u9g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C2FF68042A4; Wed, 18 Nov 2020 09:32:27 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1988D18426; Wed, 18 Nov 2020 09:32:27 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 738C65813B; Wed, 18 Nov 2020 09:32:26 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0AI9WOkg024913 for ; Wed, 18 Nov 2020 04:32:24 -0500 Received: by smtp.corp.redhat.com (Postfix) id 2761AB17D9; Wed, 18 Nov 2020 09:32:24 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 22146B17DB for ; Wed, 18 Nov 2020 09:32:21 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8BF74185A78B for ; Wed, 18 Nov 2020 09:32:21 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-444-c4wY8jFvN2aavp-IvtYbEg-1; Wed, 18 Nov 2020 04:32:19 -0500 X-MC-Unique: c4wY8jFvN2aavp-IvtYbEg-1 Received: from localhost (unknown [89.205.136.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 651A320855; Wed, 18 Nov 2020 09:32:15 +0000 (UTC) Date: Wed, 18 Nov 2020 10:32:12 +0100 From: Greg KH To: Jan Beulich Message-ID: References: <20201118084800.2339180-1-hch@lst.de> <22ca5396-0253-f286-9eab-d417b2e0b3ad@suse.com> <20201118085804.GA20384@lst.de> <1ded2079-f1be-6d5d-01df-65754447df78@suse.com> <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> MIME-Version: 1.0 In-Reply-To: <61044f85-cd41-87b5-3f41-36e3dffb6f2a@suse.com> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-loop: dm-devel@redhat.com Cc: linux-bcache@vger.kernel.org, Jens Axboe , Mike Snitzer , Konrad Rzeszutek Wilk , Richard Weinberger , Josef Bacik , Coly Li , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@redhat.com, linux-mtd@lists.infradead.org, linux-mm@kvack.org, Jan Kara , Tejun Heo , xen-devel@lists.xenproject.org, Christoph Hellwig Subject: Re: [dm-devel] merge struct block_device and struct hd_struct X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote: > On 18.11.2020 10:09, Greg KH wrote: > > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote: > >> On 18.11.2020 09:58, Christoph Hellwig wrote: > >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote: > >>>> since this isn't the first series from you recently spamming > >>>> xen-devel, may I ask that you don't Cc entire series to lists > >>>> which are involved with perhaps just one out of the many patches? > >>>> IMO Cc lists should be compiled on a per-patch basis; the cover > >>>> letter may of course be sent to the union of all of them. > >>> > >>> No way. Individual CCs are completely broken as they don't provide > >>> the reviewer a context. > >> > >> That's the view of some people, but not all. Context can be easily > >> established by those who care going to one of the many archives on > >> which the entire series lands. Getting spammed, however, can't be > >> avoided by the dozens or hundreds of list subscribers. > > > > kernel patches are never "spam", sorry, but for developers to try to > > determine which lists/maintainers want to see the whole series and which > > do not is impossible. > > > > Patches in a series are easily deleted from sane mail clients with a > > single click/keystroke all at once, they aren't a problem that needs to > > be reduced in volume. > > This doesn't scale, neither in the dimension of recipients nor in > the dimension of possible sources of such series. Again, trying to figure out what subsystem does, and does not, want stuff like this does not scale either. Remember, we had 4000 developers last year, how are you going to tell all of them what the special rules are for your subsystem and how they differ from any other subsystem? And why does it matter? We are all working on the same project, why wouldn't you want to see core block device handling patches? What hurts with that, someone might notice something in one of them that a different developer did not. > While it may seem small, it's also a waste of resources to have mails > sent to hundreds of even thousands of people. So while from a > technical content perspective I surely agree with you saying 'kernel > patches are never "spam"', they still are from the perspective of > what "spam mail" originally means: Mail the recipients did not want > to receive. Anyone on a kernel subsystem mailing list should expect to see kernel patches, that's part of the process, and always has been. Kernel subsystems are not silos, people on them should be aware of what else is going on in order to stay informed. And again, if it's a huge problem, one click/keystroke and they are gone, no waste. thanks, greg k-h -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel