From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938716AbcKWOiF (ORCPT ); Wed, 23 Nov 2016 09:38:05 -0500 Received: from omzsmtpe03.verizonbusiness.com ([199.249.25.208]:26206 "EHLO omzsmtpe03.verizonbusiness.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936535AbcKWOhi (ORCPT ); Wed, 23 Nov 2016 09:37:38 -0500 X-IronPort-Anti-Spam-Filtered: false X-IronPort-AV: E=Sophos;i="5.31,538,1473120000"; d="scan'208";a="123561362" From: alexander.levin@verizon.com X-Host: discovery.odc.vzwcorp.com To: Dmitry Vyukov CC: "tglx@linutronix.de" , "scientist@fb.com" , "glider@google.com" , "andreyknvl@google.com" , "rostedt@goodmis.org" , "arnd@arndb.de" , "mathieu.desnoyers@efficios.com" , "daniel.vetter@ffwll.ch" , "linux-kernel@vger.kernel.org" , "Nicholas Mc Guire" Subject: Re: [RFC 0/3] ABI spec - verification Thread-Topic: [RFC 0/3] ABI spec - verification Thread-Index: AQHSRZcKpO9sNzwvekKNDVJ41HJsrw== Date: Wed, 23 Nov 2016 14:36:56 +0000 Message-ID: <20161123143703.GC3218@sasha-lappy> References: <1479317803-17220-1-git-send-email-alexander.levin@verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mutt/1.5.24 (2015-08-30) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <7767D9CFD66DA2469085C8771E0CEF4B@vzwcorp.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uANEc9gt004716 On Mon, Nov 21, 2016 at 03:25:05PM +0100, Dmitry Vyukov wrote: > On Wed, Nov 16, 2016 at 6:37 PM, wrote: > > As discussed at plumbers, having a standard spec for the kernel's ABI has > > quite a few uses and enough people wanted it to get the ball rolling. > > > > We agreed that it's desirable to have something that can be used from code > > rather than just a spec on paper both for validation and allowing other users > > (like fuzzers, userspace libraries, and various userspace tools) to build > > on that. > > > > What we ended up deciding on at plumbers is: > > > > - I'll do a few kernel bits do demonstrate how we can validate the spec from > > the kernel. > > - Dmitry Vyukov will provide a way to translate syzkaller's syscall > > documentation into something that can be easily used in the kernel and > > userspace. > > - Various projects will attempt to integrate it to make sure that the > > framework works for them. > > > > Once those bits are done we can focus on getting the spec right, and we'll > > have a good way to validate our work both in userspace and in the kernel. > > > > This patchset is a basic draft of said kernel bits. I mostly want to make > > sure that Dmitry and myself are on the same page as to how integration will > > look like, but also to open it to criticism and suggestions (bikeshedding). > > > Looks like a good starting point! > > Do you have a git repo with this somewhere? I have problems applying > the patches, seems that my gmail messed them with some weird escaping. I've pushed it to https://git.kernel.org/cgit/linux/kernel/git/sashal/linux.git/log/?h=abi_spec , will try to keep it updated. > Is the intention that these descriptions are written by hand, or > generated from some DSL? > I benefited from easier to write descriptions, also I changed several > times what code generator generates without changing descriptions. > However, an additional level of indirection in the form of code > generator introduces own pain to maintain. So I am not too strong > here. I would really to have the descriptions written in just *one* place, either by hand the way I did in that example, or in DSL. I understand your point about another level of indirection, but I'm afraid that if we don't force a monolithic spec we'll end up with way more than 2 different descriptions to maintain. -- Thanks, Sasha