linux-kernel - Re: [PATCH V4] mtd: Add DiskOnChip G3 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y5x4hpkz.fsf@free.fr>
Date:	Sat, 01 Oct 2011 14:19:08 +0200
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	dedekind1@...il.com, dwmw2@...radead.org,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4] mtd: Add DiskOnChip G3 support

Arnd Bergmann <arnd@...db.de> writes:

> I generally recommend removing debug messages like this entirely from
> production code. If you need them on production systems, that is an indication
> that the code quality is not good enough.
Perhaps.
But when you create a driver without any specification, and you release it to
the communauty, there will be unmet behaviours. So, when someone will ask me
"why in my board XXX my docg3 can't read data ?" how can I improve the driver
without any traces ?

> Enabling the debug output like
> this also creates a lot of almost identical strings, which you don't need
> if you turn it into an extern function that does
>
> 	static const char docseq[] = {
> 		[DOC_SEQ_RESET]		 = "reset",
> 		[DOC_SEQ_PAGE_SIZE_532]	 = "page_size_532",
> 	};
> 	dev_dbg(dev, "doc_flashSequence: %02x %s\n", docseq[seq]);
> with exactly the same output.
That doesn't look very good, as the sequence numbers are sparse numbers, and we
can finish with an array with values (0, 3, 8, 0xff) filled, and all the
remaining are null pointers (as these sequence numbers don't exist).


> Or you could turn the entire tracing into trace events and do the parsing
> in user space, which seems appropriate if you frequently need to trace
> these.
This looks much much better. I'll have a peek into that, as only (io_address,
read/write, width, value) could be dumped, and userland application could
translate it into sequence/nop/flashcontrol ... etc ...

-- 
Robert
--
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/