[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120816165027.6520c4f4@pixies.home.jungo.com>
Date: Thu, 16 Aug 2012 16:50:27 +0300
From: Shmulik Ladkani <shmulik.ladkani@...il.com>
To: dedekind1@...il.com
Cc: Richard Genoud <richard.genoud@...il.com>,
linux-mtd@...ts.infradead.org,
David Woodhouse <dwmw2@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space
parameter
On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy <dedekind1@...il.com> wrote:
> On Thu, 2012-08-16 at 11:57 +0300, Shmulik Ladkani wrote:
> >
> > For the simplest systems (those having one ubi device) that need a
> > limit
> > *other* than the default (20 per 1024), they can simply set the config
> > to their chosen value, as they were used to.
> >
> > With you approach, these system MUST pass the limit parameter via the
> > ioctl / module-parameter.
>
> Yeah, when you change the default, you usually need to do an extra step.
> It does not feel too bad, and I would not keep additional configuration
> option for a hypothetical user. If someone suffers, we can add an option
> to change the default. But I'd start without it. So, I think it is OK to
> remove this.
Yes, but the main drawback I was referring to is those platforms already
setting MTD_UBI_BEB_RESERVE other than the default, by means of kernel
configuration.
(there's one platform known to do so in its defconfig, that's
sam9_l9260_defconfig, which uses 3% instead of the "standard" 2%).
These platforms must now change their usermode code to either pass a
module parameter during the insmod or change their attach ioctl of
their application.
We force these systems to change their usermode because we changed ubi's
default BEB limit to be 20/1024 _hardcoded_ (instead of kernel
configurable as previously was).
Is this ok?
Regards,
Shmulik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists