From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC 1/4] ASoC: topology: Add topology UAPI header. Date: Tue, 21 Apr 2015 17:23:36 +0200 Message-ID: References: <1429217295.7100.19.camel@loki> <20150420213048.GT14892@sirena.org.uk> <1429609673.3793.14.camel@loki> <1429620227.3793.31.camel@loki> <20150421150342.GJ22845@sirena.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 5D928261493 for ; Tue, 21 Apr 2015 17:23:39 +0200 (CEST) In-Reply-To: <20150421150342.GJ22845@sirena.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: Liam Girdwood , "Koul, Vinod" , "alsa-devel@alsa-project.org" List-Id: alsa-devel@alsa-project.org At Tue, 21 Apr 2015 16:03:42 +0100, Mark Brown wrote: > > On Tue, Apr 21, 2015 at 01:43:47PM +0100, Liam Girdwood wrote: > > On Tue, 2015-04-21 at 12:02 +0200, Takashi Iwai wrote: > > > At Tue, 21 Apr 2015 10:47:53 +0100, > > > > > > Not got a massively strong opinion here but given that we have ABI > > > > > versioning can we just skip the 128 bytes of reserved space in most of > > > > > the structs? Doesn't seem to be doing much except making the files > > > > > bigger. > > > > > We had a similar discussion in Nuremburg last week, the intention is to > > > > keep the size of the structures constant so wont dont break older > > > > kernels with newer userspace ABIs etc. > > > > Maybe a question is whether the size is sensible. But the argument > > > here was "memory is cheap nowadays". > > > Ok, we can reduce the size here. I think Vinod wanted at least 4 * 4 > > byte words (i.e. 16 bytes) minimum IIRC, what about 16 bytes ? That > > would give us at least 4 new members for the future ? > > That's sounding like an awfully small number if we're trying to be > infititely future proof (obviously the default value for that is 640k!). > We'd also need to go through and give *all* the structures padding. How > about just adding length fields instead with a rule that if the > structure is bigger than you know about just ignore anything at the end? In theory, having only "abi" field should be enough, as we can know the size predefined for each ABI version. But I agree that it'd be friendlier for a parser if the header itself declares its size, e.g. via a header_size field or embedding the size into some check field like ioctl. Takashi