public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Wagner <david.wagner@free-electrons.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: dedekind1@gmail.com,
	linux-embedded <linux-embedded@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Tim Bird <tim.bird@am.sony.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI
Date: Thu, 01 Sep 2011 14:55:12 +0200	[thread overview]
Message-ID: <4E5F80B0.9060908@free-electrons.com> (raw)
In-Reply-To: <201108251712.40894.arnd@arndb.de>

On 08/25/2011 05:12 PM, Arnd Bergmann wrote:
> The cost of a block device node in the kernel is rather low. Nowadays,
> sysfs does not even permanently use inodes for entries, it has a much
> more compact internal representation IIRC.
> 
> The main advantage of this approach is not having to set up the 
> block device at all, it would just be there, which e.g. makes it
> possible to put a root file system on it or do something else without
> requiring a user space tool to issue an ioctl.

Before patch v3, every existing and new UBI volumes were "proxyfied" by
ubiblk and it was, indeed, one of our goal to be able to have a rootfs
on it.  Patch v3 hinders that goal but it could still be achievable by
adding a module parameter that would explicitly create a ubiblk device
for a UBI volume at boot time.

I for one am fine with both solutions (keep the ioctl + add a kernel
parameter and throwing the ioctl away and go back "automatically create
a ubiblk for each UBI volume").  However, I agree that it doesn't make
sense to create a ubiblk device on top of UBI volumes containing, for
instance, a ubifs.

	Best Regards,
	David.

-- 
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2011-09-01 12:51 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24 13:34 [RFC] ubiblk: read-only block layer on top of UBI david.wagner
2011-06-24 13:34 ` [PATCH] UBI: new module ubiblk: " david.wagner
2011-06-27 19:26   ` Artem Bityutskiy
2011-06-28 11:35     ` David Wagner
2011-06-29  6:52       ` Artem Bityutskiy
2011-06-28 14:50     ` Matthieu CASTET
2011-06-28 15:32       ` David Wagner
2011-06-29  6:25         ` Artem Bityutskiy
2011-06-24 13:45 ` [Addendum][RFC] ubiblk: read-only " David Wagner
2011-06-27 19:14 ` [RFC] " Artem Bityutskiy
2011-06-28 15:24 ` [RFC PATCHv2] UBI: new module ubiblk: " david.wagner
2011-06-29  6:54   ` Artem Bityutskiy
2011-07-26 12:27 ` [PATCH] " David Wagner
2011-07-26 12:34   ` Christoph Hellwig
2011-07-26 12:58     ` David Wagner
2011-07-28  6:14   ` Artem Bityutskiy
2011-08-15 11:56   ` Artem Bityutskiy
2011-08-17 13:17 ` [PATCHv3] " david.wagner
2011-08-17 14:20   ` [PATCH] Tools for controling ubiblk David Wagner
2011-08-22  7:39   ` [PATCHv3] UBI: new module ubiblk: block layer on top of UBI Artem Bityutskiy
2011-08-22  7:42   ` Artem Bityutskiy
2011-08-24 16:23     ` Arnd Bergmann
2011-08-25  7:06       ` Artem Bityutskiy
2011-08-25 15:12         ` Arnd Bergmann
2011-09-01 12:55           ` David Wagner [this message]
2011-09-06  3:44           ` Artem Bityutskiy
2011-09-06  4:10             ` Artem Bityutskiy
2011-09-06  4:29               ` Artem Bityutskiy
2011-09-08 15:26               ` Arnd Bergmann
2011-09-09 11:53                 ` Artem Bityutskiy
2011-09-09 12:02                   ` Artem Bityutskiy
2011-09-09 14:25                   ` Arnd Bergmann
2011-09-09 15:27                     ` Artem Bityutskiy
2011-09-09 14:41                   ` David Wagner
2011-09-09 14:51                     ` Arnd Bergmann
2011-09-11 10:18                     ` Artem Bityutskiy
2011-09-11 10:35                       ` David Wagner
2011-08-24 16:15 ` [PATCHv4] " david.wagner
2011-08-24 16:21   ` [PATCH] document ubiblk's usage of the same ioctl magic as a part " David Wagner
2011-09-06  4:58     ` Artem Bityutskiy
2011-09-06  4:55   ` [PATCHv4] UBI: new module ubiblk: block layer on top " Artem Bityutskiy
2011-09-12  9:51 ` [PATCHv5] " David Wagner
2011-09-19  4:50   ` Artem Bityutskiy
2011-09-22  7:58 ` [PATCHv6] " David Wagner
2011-09-23 10:58   ` Artem Bityutskiy
2011-09-26 12:58     ` David Wagner
2011-09-26  9:17   ` Ricard Wanderlof
2011-09-26 12:38 ` [PATCHv7] " David Wagner
2011-09-26 13:20   ` Artem Bityutskiy
2011-09-26 14:25 ` [PATCHv8] " David Wagner
2011-09-26 14:36   ` Artem Bityutskiy
2011-09-26 14:40 ` [PATCHv9] " David Wagner
2011-10-01 14:08   ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E5F80B0.9060908@free-electrons.com \
    --to=david.wagner@free-electrons.com \
    --cc=arnd@arndb.de \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox