From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758787Ab1IIMAZ (ORCPT ); Fri, 9 Sep 2011 08:00:25 -0400 Received: from mail-yw0-f46.google.com ([209.85.213.46]:47823 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758764Ab1IIMAY (ORCPT ); Fri, 9 Sep 2011 08:00:24 -0400 Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI From: Artem Bityutskiy Reply-To: dedekind1@gmail.com To: david.wagner@free-electrons.com Cc: linux-mtd , linux-embedded , lkml , Tim Bird , David Woodhouse , Arnd Bergmann Date: Fri, 09 Sep 2011 15:02:45 +0300 In-Reply-To: <1315569206.7905.41.camel@sauron> References: <1308922482-14967-1-git-send-email-david.wagner@free-electrons.com> <1315280704.19067.14.camel@sauron> <1315282208.19067.24.camel@sauron> <201109081726.00769.arnd@arndb.de> <1315569206.7905.41.camel@sauron> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1315569770.7905.45.camel@sauron> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2011-09-09 at 14:53 +0300, Artem Bityutskiy wrote: > David, I am really busy and now, I suggest you to think about this. I'd > so far stick to the own ubiblk cdev approach, and would > analyse/prototype the approach of using UBI cdev for this. I provided > some concerns above. Also, think about race conditions like: > > 1. Someone Sorry, I wonted to talk about situations when someone opens an ubiblk device while the underlying UBI volume is being removed, but then though this is trivial and forgot to erase the last sentence. Anyway, I suggest the following algorithm: 1. Stick with the own cdev approach - the driver becomes very simple in this case - we review it. 2. Once it is ready, or in parallel, you can play with the second approach and if you find it solid/nice, you can then provide a new version and/or the delta. The idea is that on step 1 we review/deal with other things, without being blocked by the ioctl stuff. -- Best Regards, Artem Bityutskiy From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-gw0-f48.google.com ([74.125.83.48]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1R1zkw-0000HC-Uv for linux-mtd@lists.infradead.org; Fri, 09 Sep 2011 12:00:27 +0000 Received: by gwj22 with SMTP id 22so1085799gwj.21 for ; Fri, 09 Sep 2011 05:00:23 -0700 (PDT) Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI From: Artem Bityutskiy To: david.wagner@free-electrons.com Date: Fri, 09 Sep 2011 15:02:45 +0300 In-Reply-To: <1315569206.7905.41.camel@sauron> References: <1308922482-14967-1-git-send-email-david.wagner@free-electrons.com> <1315280704.19067.14.camel@sauron> <1315282208.19067.24.camel@sauron> <201109081726.00769.arnd@arndb.de> <1315569206.7905.41.camel@sauron> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1315569770.7905.45.camel@sauron> Mime-Version: 1.0 Cc: linux-embedded , Arnd Bergmann , lkml , linux-mtd , Tim Bird , David Woodhouse Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2011-09-09 at 14:53 +0300, Artem Bityutskiy wrote: > David, I am really busy and now, I suggest you to think about this. I'd > so far stick to the own ubiblk cdev approach, and would > analyse/prototype the approach of using UBI cdev for this. I provided > some concerns above. Also, think about race conditions like: > > 1. Someone Sorry, I wonted to talk about situations when someone opens an ubiblk device while the underlying UBI volume is being removed, but then though this is trivial and forgot to erase the last sentence. Anyway, I suggest the following algorithm: 1. Stick with the own cdev approach - the driver becomes very simple in this case - we review it. 2. Once it is ready, or in parallel, you can play with the second approach and if you find it solid/nice, you can then provide a new version and/or the delta. The idea is that on step 1 we review/deal with other things, without being blocked by the ioctl stuff. -- Best Regards, Artem Bityutskiy