From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 22 Apr 2016 13:53:00 +0200 Subject: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list In-Reply-To: <571A0175.2070807@nod.at> References: <1454410475-29929-1-git-send-email-hs@denx.de> <20160421105846.696b0eff@bbrezillon> <5718A6DE.6040109@denx.de> <20160421122533.7367cb7c@bbrezillon> <5718B012.8030006@denx.de> <20160421141452.4d9257d3@bbrezillon> <5719F01A.7090400@nod.at> <5719FAE6.2010603@denx.de> <571A0175.2070807@nod.at> Message-ID: <571A109C.6090206@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Richard, Am 22.04.2016 um 12:48 schrieb Richard Weinberger: > Heiko, > > Am 22.04.2016 um 12:20 schrieb Heiko Schocher: >>> Think of places where work is scheduled but the caller blocked >>> the worker because the work has to be done later. >>> Fastmap is one of these use cases but AFAIK it won't matter >>> as no CPU scheduler is involved and will interrupt Fastmap. >> >> Can you explain this a little bit? > > As I said, when you are in a code region where parallel > work must not happen as it will, for example, confuse your state > you block the worker. > But you are still allowed to schedule new work which will > executed after you unblock it. > For the fastmap example I gave it should be fine but I didn't check > all code paths in UBI for u-boot single thread safety. :-) > > What I wanted to say is that executing work directly at schedule > time does not match 1:1 the POV of Linux UBI and is error prone. > These are issues you won't notice by compile testing. Ok, thanks for the explanation! > An alternative approach would be not executing work > directly while scheduling it but in produce_free_peb(). > UBI is designed to work with the worker being disabled. > All UBI work will then happen synchronous and should also work > in u-boot. Sounds good! >>> In the long run I suggest removing the whole Linux UBI implementation >>> from u-boot and add a small (read only!) implementation which can >>> also read UBIFS. Reading UBIFS is not a big deal. Also journal reply >>> can be done in-memory. >> >> Hmm.. I think read only is not for all boards an option, as we also >> create UBI Volumes and/or write to them in U-Boot ... > > Depends. > IMHO a bootloader has exactly one job, loading a kernel > and booting it. And not being a poor man's general purpose operating > system where you can also do management stuff like managing UBI volumes. ;-) Heh... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany