Hi all, Il 02/04/2015 18:18, Richard Weinberger ha scritto: > Am 02.04.2015 um 18:04 schrieb Brian Norris: >> On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote: >> [1] Although there are some latent issues in these tests that are still >> getting get worked out (e.g., bad handling of 64-bit casting; too large >> of stacks; uninterruptibility). The latter two would not even exist if >> we were in user space. > > uninterruptibility got solved by my "[PATCH] mtd: Make MTD tests cancelable" > patch.
And this is something I was looking for from years! > But if we want to kill drivers/mtd/tests/ I'll happily help out. > Where shall we move these tests into? mtd-utils? I think so. I'm writing a similar read disturb test on my own, mixing already existing mtd-tools (flash_erase, nandwrite, nanddump) with some naive bash scripting. IMHO, we have a lot of pros running in userspace: * dumping data * better error/status log (which can be easily written on file, for example, while mtdtests error log is mixed with other kernel messages) * running test in parallel (if it make sense ;-) For example on read disturb I already calculate RBER, which is, AFAIK, a nice index on the quality of the NAND cell and of its data. I'm working on writing down data on a separate CSV which can be easily processed later (e.g. to make part to part comparison/statistics). There's already a test directory inside mtd-utils, I think it's better to start creating tests there, as userspace tools, whenever this is possible. Do we have any reason to have MTD tests as kernel module? (performance?) Kind Regards, -- Andrea SCIAN DAVE Embedded Systems -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/