linux-kernel - Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

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]

Date:	Fri, 18 Jul 2008 11:48:03 +0300 (EEST)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
cc:	cl@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Matt Mackall <mpm@...enic.com>
Subject: Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

Hi Eduard-Gabriel,

On Thu, 17 Jul 2008, Eduard - Gabriel Munteanu wrote:
> > > +struct kmemtrace_event {
> > 
> > So why don't we have the ABI version embedded here like blktrace has
> > so that user-space can check if the format matches its expectations?
> > That should be future-proof as well: as long as y ou keep the existing
> > fields where they're at now, you can always add new fields at the end
> > of the struct.
> 
> You can't add fields at the end, because the struct size will change and
> reads will be erroneous. Also, stamping every 'packet' with ABI version
> looks like a huge waste of space.

It's an ABI so you want to make it backwards compatible and extensible. 
Yes, it's just for debugging, so the rules are bit more relaxed here but 
that's not an excuse for not designing the ABI properly.

I really wish we would follow the example set by blktrace here. It uses a 
fixed-length header that knows the length of the rest of the packet.

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