From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI Date: Tue, 06 Sep 2011 07:29:51 +0300 Message-ID: <1315283397.19067.37.camel@sauron> References: <1308922482-14967-1-git-send-email-david.wagner@free-electrons.com> <201108241823.20904.arnd@arndb.de> <1314256010.18988.18.camel@sauron> <201108251712.40894.arnd@arndb.de> <1315280704.19067.14.camel@sauron> <1315282208.19067.24.camel@sauron> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:message-id :mime-version; bh=9U7y+eSPxRaPKiRA0dv39kDE9XpIAjwiblCSMGD8aVg=; b=kxLWmYb8h9oe3qimeOj7SBZjAwSLucbaZ0NManSH3tpvXvG+oiom+/+F0Qi8NmsZDu H3/Z1Odaq9FXuD/9nWF7KtE3AvLCAe9GYKQgRcTTyDsuXetDJFjIHko0TRGyWFGQq4He wpEcvFZi3ja3MflvCBtA+VTjlbdNUSHZCPa9o= In-Reply-To: <1315282208.19067.24.camel@sauron> Sender: linux-embedded-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Arnd Bergmann Cc: david.wagner@free-electrons.com, linux-mtd , linux-embedded , lkml , Tim Bird , David Woodhouse On Tue, 2011-09-06 at 07:10 +0300, Artem Bityutskiy wrote: > On Tue, 2011-09-06 at 06:44 +0300, Artem Bityutskiy wrote: > > > It's not a dummy bus, in this approach it would be a the bus that gets > > > used by all ubiblk devices, which is a very common concept by itself. > > > It's more like the classic understanding of a 'device class' that Greg > > > wants to see get replaced by bus_types in the kernel. > > > > Yes, this sounds OK. Although UBI already has notifiers, so we could > > just add 2 more events. > > Hmm, with notifications the error handling becomes a problem - we want > the ioctls for creating/removing the block device to be synchronous, > and, should an error occur, we want to return the error code to the > user-space. So the existing notifications mechanism does not work well. ... but we can change it a little and have error codes handling, this is just UB implementation issues. -- Best Regards, Artem Bityutskiy From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-iy0-f177.google.com ([209.85.210.177]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1R0nMd-0001zv-1W for linux-mtd@lists.infradead.org; Tue, 06 Sep 2011 04:34:23 +0000 Received: by iacb35 with SMTP id b35so8497132iac.36 for ; Mon, 05 Sep 2011 21:34:21 -0700 (PDT) Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI From: Artem Bityutskiy To: Arnd Bergmann Date: Tue, 06 Sep 2011 07:29:51 +0300 In-Reply-To: <1315282208.19067.24.camel@sauron> References: <1308922482-14967-1-git-send-email-david.wagner@free-electrons.com> <201108241823.20904.arnd@arndb.de> <1314256010.18988.18.camel@sauron> <201108251712.40894.arnd@arndb.de> <1315280704.19067.14.camel@sauron> <1315282208.19067.24.camel@sauron> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1315283397.19067.37.camel@sauron> Mime-Version: 1.0 Cc: linux-embedded , david.wagner@free-electrons.com, 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 Tue, 2011-09-06 at 07:10 +0300, Artem Bityutskiy wrote: > On Tue, 2011-09-06 at 06:44 +0300, Artem Bityutskiy wrote: > > > It's not a dummy bus, in this approach it would be a the bus that gets > > > used by all ubiblk devices, which is a very common concept by itself. > > > It's more like the classic understanding of a 'device class' that Greg > > > wants to see get replaced by bus_types in the kernel. > > > > Yes, this sounds OK. Although UBI already has notifiers, so we could > > just add 2 more events. > > Hmm, with notifications the error handling becomes a problem - we want > the ioctls for creating/removing the block device to be synchronous, > and, should an error occur, we want to return the error code to the > user-space. So the existing notifications mechanism does not work well. ... but we can change it a little and have error codes handling, this is just UB implementation issues. -- Best Regards, Artem Bityutskiy