linux-kernel - Re: changing format/size of data in TRACE_EVENT(extlog_mem

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 25 Jun 2015 00:17:28 +0200
From:	Borislav Petkov <bp@...e.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-edac@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: changing format/size of data in TRACE_EVENT(extlog_mem_event)

On Wed, Jun 24, 2015 at 02:56:49PM -0700, Luck, Tony wrote:
> So the question is - how can we update the trace event to include these
> new wider fields with the minimum pain to applications that look at it?
> I don't know if there are any other consumers besides rasdaemon at the
> moment ... but we don't want ugly transitions where you have to guess
> which version of the application you need to run to work with a given
> kernel version.

Well, can we issue an UEFI version and a binary blob which gets unpacked
in userspace depending on that version? Can tracepoints even do that?

Because the next time they change the spec, we're going to have to
deal with that PITA all over again... And if we're going to change the
tracepoint now, we better change it only once but in a way that can
accomodate future changes...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/