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: <A961433CDFF2F640A2866803152E61F9516EE7B0@G4W3218.americas.hpqcorp.net>
Date:	Mon, 3 Dec 2012 21:13:49 +0000
From:	"Ortiz, Lance E" <lance.oritz@...com>
To:	Borislav Petkov <bp@...en8.de>
CC:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"lance_ortiz@...mail.com" <lance_ortiz@...mail.com>,
	"jiang.liu@...wei.com" <jiang.liu@...wei.com>,
	"tony.luck@...el.com" <tony.luck@...el.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Zhang Yanmin <yanmin.zhang@...el.com>
Subject: RE: [PATCH v3 1/3] aerdrv: Trace Event for AER

> 
> Maybe we should ask Yanmin who added those strings in
> 6c2b374d74857e892080ee726184ec1d15e7d4e4; CCed.
> 
> Also, it would make a lot of sense to have those string definitions
> at one place and then reuse them instead of define them again in the
> tracepoint header and they get out of sync and have needless
> duplication
> in the kernel, etc, etc.
> 
> So, instead, you could define some macros which can generate your
> strings above like this:
> 
> #define aer_uncor_err_str(bitnum)	\
> 	{ BIT(bitnum), aer_uncorrectable_error_string(bitnum) }
> 
> and use that macro for the __print_flags flag_array argument.
> 
> Or something to that effect.
> 
> Even better would it be if the error strings in
> <drivers/pci/pcie/aer/aerdrv_errprint.c> could be shared with the
> tracepoint ones. That would require a bit more changes though but
> something like using an array of trace_print_flags instead an array of
> strings could be doable.
> 
> Then, when you need the string, you do uncor_err_array[i].name and so
> on.

This a fine idea.  I'm thinking we might want to implement that in a later patch since it is a bigger change and we still need to see about adding additional strings.  I can send out one more version of the patch with the comment header changes you suggested, and the comments Joe had and maybe we can move forward with that.

Lance 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ