From: Shmulik Ladkani <shmulik.ladkani@gmail.com> To: Richard Genoud <richard.genoud@gmail.com>, Artem Bityutskiy <dedekind1@gmail.com> Cc: linux-mtd@lists.infradead.org, David Woodhouse <dwmw2@infradead.org>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter Date: Thu, 16 Aug 2012 13:42:34 +0300 [thread overview] Message-ID: <20120816134234.32b468f6@pixies.home.jungo.com> (raw) In-Reply-To: <CACQ1gAhFJ6AKYJpc1ZiHm+3Y=APnwUmVL3f0KW=OFMDMWzCVJg@mail.gmail.com> Hi Richard, Artem, On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud <richard.genoud@gmail.com> wrote: > > With you approach, these system MUST pass the limit parameter via the > > ioctl / module-parameter. > That's right. > We can add a kernel config option to change the max_beb_per1024 > default value (actually, this is almost the patch I send first). > But I see something disturbing with that: > It means that an ubi_attach call from userspace, without specifying > max_beb_per1024, won't have the same result, depending of the default > config value the kernel has been compiled with. > (Or maybe this behavior is acceptable). Well, that was the previous behavior of MTD_UBI_BEB_RESERVE, long before our patchsets. I think it is acceptable, given the fact it simplifies the configuration for most simple systems. Anyway I'm just pointing out the consequences of your change and try to suggest other alternatives. Artem should decide as he's the maintainer. > > Also, since max_beb_per1024 is always set, how one may specify a zero > > limit? > You can't. > Do you think we need that ? Well again, originally, prior our patchsets, one *could* set a zero MTD_UBI_BEB_RESERVE for his system. So we're introducing a change that affects the possible ways an ubi system can be configured, banning a configuration that was valid in the past. Does it make sense to set a zero limit? dunno. For testing purposes, maybe. Artem, what do you think? prohibit a zero beb limit? Regards, Shmulik
WARNING: multiple messages have this Message-ID (diff)
From: Shmulik Ladkani <shmulik.ladkani@gmail.com> To: Richard Genoud <richard.genoud@gmail.com>, Artem Bityutskiy <dedekind1@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org>, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter Date: Thu, 16 Aug 2012 13:42:34 +0300 [thread overview] Message-ID: <20120816134234.32b468f6@pixies.home.jungo.com> (raw) In-Reply-To: <CACQ1gAhFJ6AKYJpc1ZiHm+3Y=APnwUmVL3f0KW=OFMDMWzCVJg@mail.gmail.com> Hi Richard, Artem, On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud <richard.genoud@gmail.com> wrote: > > With you approach, these system MUST pass the limit parameter via the > > ioctl / module-parameter. > That's right. > We can add a kernel config option to change the max_beb_per1024 > default value (actually, this is almost the patch I send first). > But I see something disturbing with that: > It means that an ubi_attach call from userspace, without specifying > max_beb_per1024, won't have the same result, depending of the default > config value the kernel has been compiled with. > (Or maybe this behavior is acceptable). Well, that was the previous behavior of MTD_UBI_BEB_RESERVE, long before our patchsets. I think it is acceptable, given the fact it simplifies the configuration for most simple systems. Anyway I'm just pointing out the consequences of your change and try to suggest other alternatives. Artem should decide as he's the maintainer. > > Also, since max_beb_per1024 is always set, how one may specify a zero > > limit? > You can't. > Do you think we need that ? Well again, originally, prior our patchsets, one *could* set a zero MTD_UBI_BEB_RESERVE for his system. So we're introducing a change that affects the possible ways an ubi system can be configured, banning a configuration that was valid in the past. Does it make sense to set a zero limit? dunno. For testing purposes, maybe. Artem, what do you think? prohibit a zero beb limit? Regards, Shmulik
next prev parent reply other threads:[~2012-08-16 10:42 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-10 16:23 [PATCH 0/4] UBI: Use the whole NAND device to calculate max bad block number Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-07-10 16:23 ` [PATCH 1/4] mtd_is_partition: struct mtd_info should be const Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-08-15 14:02 ` Artem Bityutskiy 2012-08-15 14:02 ` Artem Bityutskiy 2012-07-10 16:23 ` [PATCH 2/4] MTD parts: introduce mtd_get_device_size() Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-07-10 16:23 ` [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-07-18 6:50 ` Artem Bityutskiy 2012-07-18 6:50 ` Artem Bityutskiy 2012-07-18 8:30 ` Richard Genoud 2012-07-18 8:30 ` Richard Genoud 2012-08-15 12:53 ` Artem Bityutskiy 2012-08-15 12:53 ` Artem Bityutskiy 2012-08-15 15:08 ` Artem Bityutskiy 2012-08-15 15:08 ` Artem Bityutskiy 2012-08-16 8:13 ` Richard Genoud 2012-08-16 8:13 ` Richard Genoud 2012-08-16 12:00 ` Artem Bityutskiy 2012-08-16 12:00 ` Artem Bityutskiy 2012-08-16 8:25 ` Shmulik Ladkani 2012-08-16 8:25 ` Shmulik Ladkani 2012-08-16 10:35 ` Richard Genoud 2012-08-16 10:35 ` Richard Genoud 2012-08-16 11:58 ` Artem Bityutskiy 2012-08-16 11:58 ` Artem Bityutskiy 2012-08-16 11:56 ` Artem Bityutskiy 2012-08-16 11:56 ` Artem Bityutskiy 2012-08-16 8:32 ` Shmulik Ladkani 2012-08-16 8:32 ` Shmulik Ladkani 2012-08-16 11:58 ` Artem Bityutskiy 2012-08-16 11:58 ` Artem Bityutskiy 2012-08-16 11:58 ` Richard Genoud 2012-08-16 11:58 ` Richard Genoud 2012-07-10 16:23 ` [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-08-15 14:57 ` Artem Bityutskiy 2012-08-15 14:57 ` Artem Bityutskiy 2012-08-16 14:52 ` [PATCH 0/2] splitting "UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter" Richard Genoud 2012-08-16 14:52 ` Richard Genoud 2012-08-16 14:52 ` [PATCH 1/2] UBI: replace MTD_UBI_BEB_LIMIT with module parameter Richard Genoud 2012-08-16 14:52 ` Richard Genoud 2012-08-17 8:22 ` Artem Bityutskiy 2012-08-17 8:22 ` Artem Bityutskiy 2012-08-17 10:27 ` Richard Genoud 2012-08-17 10:27 ` Richard Genoud 2012-08-16 14:52 ` [PATCH 2/2] UBI: add ioctl for max_beb_per1024 Richard Genoud 2012-08-16 14:52 ` Richard Genoud 2012-08-17 8:28 ` Artem Bityutskiy 2012-08-17 8:28 ` Artem Bityutskiy 2012-08-16 8:57 ` [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter Shmulik Ladkani 2012-08-16 8:57 ` Shmulik Ladkani 2012-08-16 10:07 ` Richard Genoud 2012-08-16 10:07 ` Richard Genoud 2012-08-16 10:42 ` Shmulik Ladkani [this message] 2012-08-16 10:42 ` Shmulik Ladkani 2012-08-16 13:33 ` Artem Bityutskiy 2012-08-16 13:33 ` Artem Bityutskiy 2012-08-19 7:09 ` Shmulik Ladkani 2012-08-19 7:09 ` Shmulik Ladkani 2012-08-19 19:04 ` Artem Bityutskiy 2012-08-19 19:04 ` Artem Bityutskiy 2012-08-20 6:55 ` Richard Genoud 2012-08-20 6:55 ` Richard Genoud 2012-08-20 8:17 ` Artem Bityutskiy 2012-08-20 8:17 ` Artem Bityutskiy 2012-08-20 8:27 ` Richard Genoud 2012-08-20 8:27 ` Richard Genoud 2012-08-16 13:28 ` Artem Bityutskiy 2012-08-16 13:28 ` Artem Bityutskiy 2012-08-16 13:50 ` Shmulik Ladkani 2012-08-16 13:50 ` Shmulik Ladkani 2012-08-16 14:30 ` Richard Genoud 2012-08-16 14:30 ` Richard Genoud 2012-08-16 14:54 ` [PATCH] UBI: use a config value for default BEB limit Richard Genoud 2012-08-16 14:54 ` Richard Genoud 2012-08-17 7:34 ` [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter Artem Bityutskiy 2012-08-17 7:34 ` Artem Bityutskiy 2012-08-17 7:06 ` Artem Bityutskiy 2012-08-17 7:06 ` Artem Bityutskiy 2012-07-10 16:23 ` [PATCH] ubiattach: introduce max_beb_per1024 in UBI_IOCATT Richard Genoud 2012-07-10 16:23 ` Richard Genoud 2012-08-17 9:37 ` Artem Bityutskiy 2012-08-17 9:37 ` Artem Bityutskiy 2012-08-16 13:10 ` [PATCH 1/2] UBI: use the whole MTD device size to get bad_peb_limit Artem Bityutskiy 2012-08-16 13:10 ` [PATCH 2/2] arm: sam9_l9260_defconfig: adjust UBI bad eraseblocks limit 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=20120816134234.32b468f6@pixies.home.jungo.com \ --to=shmulik.ladkani@gmail.com \ --cc=dedekind1@gmail.com \ --cc=dwmw2@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=richard.genoud@gmail.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: linkBe 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.