From patchwork Tue Dec 25 07:37:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shmulik Ladkani X-Patchwork-Id: 208102 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B8E4E2C007D for ; Tue, 25 Dec 2012 18:39:41 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TnP5c-0005NI-5a; Tue, 25 Dec 2012 07:38:16 +0000 Received: from mail-wi0-f171.google.com ([209.85.212.171]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TnP5Y-0005N1-Ut for linux-mtd@lists.infradead.org; Tue, 25 Dec 2012 07:38:13 +0000 Received: by mail-wi0-f171.google.com with SMTP id hn14so6708246wib.16 for ; Mon, 24 Dec 2012 23:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:x-mailer; bh=WEL1lmZPZkSumuL+ECWUadGMjCuMdDuotMyEW8RMQOM=; b=nmfIyPiDKQ2hBFqlbucZvgobcKfP1VjMe4JP7KspWgPhzWCUnOqN5UfWQa+3YirU1W ZX0bIn4mqlC4e++xYxTIj9PsXqGdej8Zo3We8E5JCgY89NsDAMDMjvrx03u9ldB7mMXj H6PJVpZYpz6m5e1IpqMjvVBjvoVbYZUjwS1h7sDhGjsKpBZSIb18RTDN7ek5YEuN0M2g +fzG4uvXXSLOwku0EOl6nhfDga7J/iahNnBKTLNMRQoyuFcH5GXeIRS4lVZdhtsWkXaw X9DYjkCTGC/ADw1FYcIqg9qczDM2s77ZZ490CIw/2UgQCLbkC8d7RIu3wjSKBbI9cbQX aFMg== X-Received: by 10.180.108.236 with SMTP id hn12mr37697411wib.6.1356421088952; Mon, 24 Dec 2012 23:38:08 -0800 (PST) Received: from pixies.home.jungo.com (212-150-239-254.bb.netvision.net.il. [212.150.239.254]) by mx.google.com with ESMTPS id dw4sm37120747wib.1.2012.12.24.23.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 23:38:08 -0800 (PST) From: Shmulik Ladkani To: Artem Bityutskiy Subject: [PATCH] mtd-www: remove any references to dtype/UBI_SHORTTERM/UBI_LONGTTERM Date: Tue, 25 Dec 2012 09:37:05 +0200 Message-Id: <1356421025-10968-1-git-send-email-shmulik.ladkani@gmail.com> X-Mailer: git-send-email 1.7.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20121225_023813_152699_65DD3F3E X-CRM114-Status: UNSURE ( 8.54 ) X-CRM114-Notice: Please train this message. X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shmulik.ladkani[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.171 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: linux-mtd@lists.infradead.org, Shmulik Ladkani X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org These no longer exist. Signed-off-by: Shmulik Ladkani --- 1. Artem, this patch completely removes these parts of the documentation. Would you prefer to keep, with a statement they no longer exist since [whatever kernel version]? 2. Piggy backed is a tiny style fix at the affected area:

. to .

I assumed no need for a separate patch, but let me know if you prefer a separate patch. diff --git a/doc/ubi.xml b/doc/ubi.xml index 13b8174..d912b8f 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -974,28 +974,7 @@ go to the mapped PEB.

The LEB map operation is available via the ubi_leb_map() UBI kernel API function, or via the UBI_IOCEBMAP volume character device ioctl command. However, thie ioctl interface is available only starting -from kernel version 2.6.29

. - -

The LEB map operation accepts the dtype parameter which suggests -UBI which type of data the LEB will contain. Namely, dtype may be -one of:

- -
    -
  • UBI_SHORTTERM - the LEB will store short-term data, - which means that it will be erased soon; UBI will map this LEB to a - PEB with low erase counter, so it will grow relative to other PEB - erase counters;
  • -
  • UBI_LONGTTERM - the LEB will store long-term data and - will not be erased soon; UBI will map this LEB to a PEB with high erase - counter, so it will go down relative to other PEB erase counters;
  • -
  • UBI_UNKNOWN - should be used most of the time, when - you are not sure whether the data are long-term or short term.
  • -
- -

Bear in mind that dtype is only a hint. Please, use -UBI_UNKNOWN if unsure. And note, UBI authors never really tested -the effects of using UBI_SHORTTERM and UBI_LONGTTERM, -so there is not guarantee they improve anything.

+from kernel version 2.6.29.

One of the possible use-cases of the LEB map operation is making sure the old LEB contents goes away forever. As it was explained in @@ -1109,8 +1088,6 @@ struct ubi_leb_change_req req; req.lnum = lnum_to_change; req.len = data_len; -req.dtype = UBI_LONGTERM; /* data persistency (may also be UBI_SHORTTERM - and UBI_UNKNOWN) */ fd = open("/dev/my_volume"); ioctl(fd, UBI_IOCEBCH, &req); write(fd, data_buf, data_len);