From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932202AbWF0Md0 (ORCPT ); Tue, 27 Jun 2006 08:33:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932205AbWF0Md0 (ORCPT ); Tue, 27 Jun 2006 08:33:26 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:49316 "EHLO 2ka.mipt.ru") by vger.kernel.org with ESMTP id S932202AbWF0MdZ (ORCPT ); Tue, 27 Jun 2006 08:33:25 -0400 Date: Tue, 27 Jun 2006 16:33:25 +0400 From: Evgeniy Polyakov To: Matt Helsley Cc: LKML , Guillaume Thouvenin Subject: Re: [RFC][PATCH 0/3] Process events biarch bug: Intro Message-ID: <20060627123325.GA26716@2ka.mipt.ru> References: <1151408822.21787.1807.camel@stark> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1151408822.21787.1807.camel@stark> User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [0.0.0.0]); Tue, 27 Jun 2006 16:33:26 +0400 (MSD) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2006 at 04:47:01AM -0700, Matt Helsley (matthltc@us.ibm.com) wrote: > The events sent by Process Events from a 64-bit kernel are not binary compatible > with what a 32-bit userspace program would expect to recieve because the timespec > struct (used to send a timestamp) is not the same. This means that fields stored > after the timestamp are offset and programs that don't take this into account > break under these circumstances. > > This is a problem for 32-bit userspace programs running with 64-bit kernels on > ppc64, s390, x86-64.. any "biarch" system. > > This series: > > 1 - Gives a name to the union of the process events structure so it may be used > to work around the problem from userspace. > 2 - Comments on the bug and describes a userspace workaround in > Documentation/connector/process_events.txt > 3 - Implements a second connector interface without the problem > (Removing the old interface or changing the definition would break > binary compatibility) If you are sure binary compatibility on this stage of process notification connector is really major issue, then I agree that above is correct, otherwise I would recommend to just replace broken code with fixed size objects. Btw, __u64 is not the best choice for some arches too due to it's alignment (64bit code requires u64 to be aligned to 64 bit, while 32bit code will only align it to 32 bits), so you will need attribute ((aligned(8)))) for your own ___u64. -- Evgeniy Polyakov