All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Mike Frysinger <vapier@gentoo.org>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	Michael Opdenacker <michael.opdenacker@free-electrons.com>,
	linux-mtd@lists.infradead.org,
	Piergiorgio Beruto <piergiorgio.beruto@gmail.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>, Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH v5 0/1] ubi: Introduce block devices for UBI volumes
Date: Fri, 14 Feb 2014 10:11:45 +0200	[thread overview]
Message-ID: <1392365505.12215.38.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1392321426-18256-1-git-send-email-ezequiel.garcia@free-electrons.com>

Thanks Ezequiel,

On Thu, 2014-02-13 at 16:57 -0300, Ezequiel Garcia wrote:
> As soon as this gets merged into UBI kernel core, I'll submit the mtd-utils
> userspace tools, as well as start preparing some documentation for the mtd
> website, and the docbook.

Ideally the docs should come along with the driver.

> I'd be willing to drop read-support is that makes this feature acceptable;
> but I guess that would make it pretty useless :-)

Well, it was your decision.

I only asked to remove the compile-time option. And if there are
limitations, document them.

I pointed that there is a standard 'blkdev' tool which has '--setro' and
'--setrw' options, and you could try to use that for _run-time_ RO/RW
toggling.

>   * Dropped write-support

Fine with me too, thanks, but please, do not allude you was pushed to do
this.

>   * Dropped cached access

Thanks. This little tiny compile options make more harm than benefit.
They break from time, because people usually use one of the
configurations, and rarely test the changed.

If you want to save people 128KiB of ram or something, do it a better
way. For example, we have memory shrinker in the kernel. Register your
your shrinker and free that buffer in case of memory pressure. Allocate
it back if needed later using "gentle" allocation techniques (NORETRY,
NOFS, etc).

Anyway, thanks for this too.


-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2014-02-14  8:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13 19:57 [PATCH v5 0/1] ubi: Introduce block devices for UBI volumes Ezequiel Garcia
2014-02-14  8:11 ` Artem Bityutskiy [this message]
2014-02-14 10:29   ` Ezequiel Garcia
2014-02-13 19:57 Ezequiel Garcia

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=1392365505.12215.38.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael.opdenacker@free-electrons.com \
    --cc=piergiorgio.beruto@gmail.com \
    --cc=richard.weinberger@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=vapier@gentoo.org \
    --cc=w@1wt.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.