From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Date: Tue, 7 Mar 2017 09:27:50 +0100 Message-ID: <20170307082750.GA1695@gmail.com> References: <20170217104757.28588-1-jslaby@suse.cz> <20170301093855.GA27152@gmail.com> <20170301102754.GA13374@gmail.com> <39064F86-5BE2-417F-8A28-2B4CB5177D7D@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <39064F86-5BE2-417F-8A28-2B4CB5177D7D@zytor.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: hpa@zytor.com Cc: Juergen Gross , Len Brown , Andrew Morton , linux-pm@vger.kernel.org, Linus Torvalds , x86@kernel.org, "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, mingo@redhat.com, Pavel Machek , jpoimboe@redhat.com, xen-devel@lists.xenproject.org, Thomas Gleixner , Jiri Slaby , Boris Ostrovsky , Peter Zijlstra List-Id: linux-pm@vger.kernel.org CiogaHBhQHp5dG9yLmNvbSA8aHBhQHp5dG9yLmNvbT4gd3JvdGU6Cgo+IE9uIE1hcmNoIDEsIDIw MTcgMjoyNzo1NCBBTSBQU1QsIEluZ28gTW9sbmFyIDxtaW5nb0BrZXJuZWwub3JnPiB3cm90ZToK Cj4gPj4gPiBTbyBob3cgYWJvdXQgdXNpbmcgbWFjcm8gbmFtZXMgdGhhdCBhY3R1YWxseSBzaG93 IHRoZSBwdXJwb3NlLCBpbnN0ZWFkIG9mIAo+ID4+ID4gaW1wb3J0aW5nIGFsbCB0aGUgY3JhcHB5 LCBoaXN0b3JpYywgZXNzZW50aWFsbHkgcmFuZG9tbHkgY2hvc2VuIGRlYnVnIAo+ID4+ID4gc3lt Ym9sIG1hY3JvIG5hbWVzIGZyb20gdGhlIGJpbnV0aWxzIGFuZCBvbGRlciBrZXJuZWxzPwo+ID4+ ID4gCj4gPj4gPiBTb21ldGhpbmcgc2FuZSwgbGlrZToKPiA+PiA+IAo+ID4+ID4gCVNZTV9fRlVO Q1RJT05fU1RBUlQKPiA+PiAKPiA+PiBTYW5lIHdvdWxkIGJlOgo+ID4+IAo+ID4+ICAgICAgCVNZ TV9GVU5DVElPTl9TVEFSVAo+ID4+IAo+ID4+IFRoZSBkb3VibGUgdW5kZXJzY29yZSBpcyBqdXN0 IG5vdCBnaXZpbmcgYW55IHZhbHVlLgo+ID4KPiA+IFNvIHRoZSBkb3VibGUgdW5kZXJzY29yZSAo YXQgbGVhc3QgaW4gbXkgdmlldykgaGFzIHR3byBhZHZhbnRhZ2VzOgo+ID4KPiA+IDEpIGl0IGhl bHBzIHNlcGFyYXRlIHRoZSBwcmVmaXggZnJvbSB0aGUgcG9zdGZpeC4KPiA+Cj4gPiBJLmUuIGl0 J3MgYSAnc3ltYm9scycgbmFtZXNwYWNlLCBhbmQgYSAnZnVuY3Rpb24gc3RhcnQnLCBub3QgdGhl ICdzdGFydCcgb2YgYSAKPiA+ICdzeW1ib2wgZnVuY3Rpb24nLgo+ID4KPiA+IDIpIEl0IGFsc28g aGVscHMgZWFzeSBncmVwcGFiaWxpdHkuCj4gPgo+ID4gVHJ5IHRoaXMgaW4gbGF0ZXN0IC10aXA6 Cj4gPgo+ID4gICAgZ2l0IGdyZXAgZTgyMF9fCj4gPgo+ID4gVG8gc2VlIGFsbCB0aGUgRTgyMCBB UEkgY2FsbHMgLSB3aXRoIG5vIGZhbHNlIHBvc2l0aXZlcyEKPiA+Cj4gPiAnZ2l0IGdyZXAgZTgy MF8nIG9uIHRoZSBvdGhlciBoYW5kIGlzIGEgbG90IGxlc3MgcmVsaWFibGUuLi4KPiAKPiBJTU8g dGhlc2UgbGl0dGxlICJuYW1lc3BhY2UgdHJpY2tzIiBlc3BlY2lhbGx5IGZvciBzbWFsbCBjb21t b24gbWFjcm9zIGxpa2Ugd2UgCj4gYXJlIHRha2luZyBhYm91dCBoZXJlIG1ha2UgdGhlIGNvZGUg dmVyeSBmcnVzdHJhdGluZyB0byByZWFkLCBhbmQgZXZlbiBtb3JlIHRvIAo+IHdyaXRlLiAgTm9v bmUgd291bGQgZGVzaWduIGEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgdGhhdCB3YXksIGFuZCB0aGlu Z3MgbGlrZSBQUk9DIAo+IGFyZSByZWFsbHkganVzdCBzdWJzdGl0dXRlcyBmb3IgcHJvcGVyIGxh bmd1YWdlIGZlYXR1cmVzIChhbmQgY291bGQgZXZlbiBiZSBhcyAKPiBhc3NlbWJseSByYXRoZXIg dGhhbiBjcHAgbWFjcm9zLikKClRoaXMgaXMgYSB0b3RhbGx5IGRpZmZlcmVudCB0aGluZyBmcm9t IGxhbmd1YWdlIGtleXdvcmRzIHdoaWNoIG5lZWRzIHRvIGJlIHNob3J0IAphbmQgY29uY2lzZSBm b3Igb2J2aW91cyByZWFzb25zLgoKS2V5d29yZHMgb2YgbGFuZ3VhZ2VzIGdldCBuZXN0ZWQgYW5k IGFyZSB1c2VkIGFsbCB0aGUgdGltZSwgYW5kIGV2ZXJ5b25lIG5lZWRzIHRvIAprbm93IHRoZW0g YW5kIHRoZXkgbmVlZCB0byBzdGF5IG91dCBvZiB0aGUgd2F5LiBUaGUgc3ltYm9sIHN0YXJ0L2Vu ZCBtYWNyb3Mgd2UgYXJlIAp0YWxraW5nIGFib3V0IGhlcmUgYXJlIF9NVUNIXyBsZXNzIGNvbW1v biwgYW5kIHRoZXkgYXJlIG9ubHkgZXZlciB1c2VkIGluIGEgc2luZ2xlIApuZXN0aW5nIGxldmVs OgoKICAgICAgICBTWU1fX0ZVTkNfU1RBUlQoc29tZV9rZXJuZWxfYXNtX2Z1bmN0aW9uKQogICAg ICAgIC4uLgogICAgICAgIFNZTV9fRlVOQ19FTkQoc29tZV9rZXJuZWxfYXNtX2Z1bmN0aW9uKQoK TW9zdCBrZXJuZWwgZGV2ZWxvcGVycyB3cml0aW5nIG5ldyBhc3NlbWJseSBjb2RlIHJhcmVseSBr bm93IHRoZXNlIGNvbnN0cnVjdHMgYnkgCmhlYXJ0LCB0aGV5IGp1c3QgbG9vayB0aGVtIHVwIGFu ZCBjYXJib24gY29weSBleGlzdGluZyBwcmFjdGljZXMuIEFuZCBndWVzcyB3aGF0LCAKdGhlICds b29raW5nIHRoZW0gdXAnIGdldHMgaGFyZGVyIGlmIHRoZSBtYWNybyBuYW1pbmcgc2NoZW1lIGlz IGFuIGlkb3N5bmNyYXRpYyAKbGVmdG92ZXIgZnJvbSBsb25nIGFnby4KCktlcm5lbCBkZXZlbG9w ZXJzIF9yZWFkaW5nXyBhc3NlbWJseSBjb2RlIHdpbGwga25vdyB0aGUgZXhhY3QgcHVycG9zZSBv ZiB0aGUgCm1hY3JvcyBldmVuIGxlc3MsIGVzcGVjaWFsbHkgaWYgdGhleSBhcmUgbmFtZWQgaW4g YW4gYW1iaWd1b3VzLCBpbGxvZ2ljYWwgZmFzaGlvbi4KCkZ1cnRoZXJtb3JlLCB5b3VyIHN1Z2dl c3Rpb24gb2Y6Cgo+IFBST0MuLkVORFBST0MsIExPQ0FMUFJPQy4uRU5EUFJPQyBhbmQgREFUQS4u RU5EREFUQS4gIENsZWFyLCB1bmFtYmlndW91cyBhbmQgCj4gYmFsYW5jZWQuCgpBcmUgbmVpdGhl ciBjbGVhciwgbm90IHVuYW1iaWd1b3VzIG5vciBiYWxhbmNlZCEgSSBtZWFuLCB0aGV5IGFyZSB0 aGUgX2V4YWN0XyAKb3Bwb3NpdGU6CgogLSAnUFJPQycgaXMgYWN0dWFsbHkgYW1iaWd1b3VzIGlu IHRoZSBrZXJuZWwgc291cmNlIGNvZGUgY29udGV4dCwgYXMgaXQgY2xhc2hlcyAKICAgd2l0aCBj b21tb24gYWJicmV2aWF0aW9ucyBvZiAncHJvY2ZzJyBhbmQgJ3Byb2Nlc3MnLgoKICAgSXQncyBh bHNvIGFuIHVubmVjZXNzYXJ5IGFiYnJldmlhdGlvbiBvZiBhIHdvcmQgKCdwcm9jZWR1cmUnKSB0 aGF0IGlzIG5vdCAKICAgYWN0dWFsbHkgdXNlZCBhIF9zaW5nbGUgdGltZV8gaW4gdGhlIEMgSVNP L0lFQyA5ODk5OlRDMiBzdGFuZGFyZCAtIGluIGFsbCBoYWxmIAogICB0aG91c2FuZCsgcGFnZXMg b2YgaXQuICghKSBXaHkgdGhlIGhlbGwgZG9lcyB0aGlzIGhhdmUgdG8gYmUgdXNlZCBpbiB0aGUg CiAgIGtlcm5lbD8KCiAtIEl0J3MgdmlzdWFsbHkgYW5kIHNlbWFudGljYWxseSBpbWJhbGFuY2Vk LCBiZWNhdXNlIHNvbWUgdGVybXMgaGF2ZSBhbiAnRU5EJyAKICAgcHJlZml4LCBidXQgdGhlcmUn cyBubyBtYXRjaGluZyAnU1RBUlQnIG9yICdCRUdJTicgcHJlZml4IGZvciB0aGVpciAKICAgY291 bnRlcnBhcnRzLiBUaGlzIG1ha2VzIGl0IGVhc3kgdG8gY29tbWl0IHZhcmlvdXMgc3ltYm9sIGRl ZmluaXRpb24gCiAgIHRlcm1pbmF0aW9uIGVycm9ycywgbGlrZToKCglQUk9DKHNvbWVfa2VybmVs X2FzbV9mdW5jdGlvbikKCS4uLgoKICAgSGVyZSBpdCdzIG5vdCBvYnZpb3VzIHRoYXQgaXQgbmVl ZHMgYW4gRU5EUFJPQy4gV2hpbGUgaWYgaXQncyB3cml0dGVuIGFzOgoKICAgICAgICBTWU1fX0ZV TkNfU1RBUlQoc29tZV9rZXJuZWxfYXNtX2Z1bmN0aW9uKQogICAgICAgIC4uLgoKICAgLi4uIGl0 J3MgcHJldHR5IG9idmlvdXMgYXQgZmlyc3Qgc2lnaHQgdGhhdCBhbiAnX0VORCcgaXMgbWlzc2lu ZyEKCiAtIFdoYXQgeW91IHN1Z2dlc3QgYWxzbyBoYXMgc2Vuc2VsZXNzbHkgbWlzc2luZyB1bmRl cnNjb3Jlcywgd2hpY2ggbWFrZXMgaXQgCiAgIF9tb3JlXyBjbHV0dGVyZWQgYW5kIGxlc3MgY2xl YXIuIFdlIGNsZWFybHkgZG9uJ3QgaGF2ZSBhZGR0b3dhaXRxdWV1ZSgpIGFuZAogICByZW1vdmVm cm9td2FpdHF1ZXVlKCkgZnVuY3Rpb24gbmFtZXMgaW4gdGhlIGtlcm5lbCwgcmlnaHQ/IFdoeSBz aG91bGQgd2UgaGF2ZQogICAnRU5EUFJPQycgYW5kICdFTkREQVRBJyBtYWNybyBuYW1lcz8KCiAt IEhpZXJhcmNoaWNhbCBuYW1pbmcgc2NoZW1lcyBnZW5lcmFsbHkgdGVuZCB0byBwdXQgdGhlIG1v cmUgZ2VuZXJpYyBjYXRlZ29yeQogICBuYW1lIGZpcnN0LCBub3QgbGFzdC4gU28gaXQnczoKCglt dXRleF9pbml0KCkKCW11dGV4X2xvY2soKQoJbXV0ZXhfdW5sb2NrKCkKCW11dGV4X3RyeWxvY2so KQoKICAgSXQncyBfTk9UXyB0aGUgb3RoZXIgd2F5IGFyb3VuZDoKCglpbml0X211dGV4KCkKCWxv Y2tfbXV0ZXgoKQoJdW5sb2NrX211dGV4KCkKCXRyeWxvY2tfbXV0ZXgoKQoKICAgVGhlIHByZWZp eCBuYW1pbmcgc2NoZW1lIGlzIGVhc2llciB0byByZWFkIGJvdGggdmlzdWFsbHkvdHlwb2dyYXBo aWNhbGx5IAogICAoYmVjYXVzZSBpdCBhbGlnbnMgdmVydGljYWxseSBpbiBhIG5hdHVyYWwgZmFz aGlvbiBzbyBpdCdzIGVhc2llciB0byBwYXR0ZXJuIAogICBtYXRjaCksIGFuZCBhbHNvIHNlbWFu dGljYWxseTogYmVjYXVzZSB3aGVuIHJlYWRpbmcgaXQgaXQncyBlYXN5IHRvIHNraXAgdGhlIAog ICBsaW5lIG9uY2UgeW91ciBicmFpbiByZWFkcyB0aGUgZ2VuZXJpYyBjYXRlZ29yeSBvZiAnbXV0 ZXgnLgoKICAgQnV0IHdpdGggJ0VORFBST0MnIG15IGJyYWluIGJvdGggaGFzIHRvIG5lZWRsZXNz bHkgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgoKCS0gZGlzYW1iaWd1YXRlIHRoZSAnRU5E JyBhbmQgdGhlICdQUk9DJwoKCS0gZmlsbCBpbiB0aGUgbWlzc2luZyB1bmRlcnNjb3JlCgoJLSBh bmQgZmluYWxseSB3aGVuIGFycml2aW5nIGF0IHRoZSBnZW5lcmljIHRlcm0gJ1BST0MnLCBkaXNj YXJkIGl0IGFzCgkgIHVuaW50ZXJlc3RpbmcKCiAtIFNob3J0IG5hbWVzIGhhdmUgZ29vZCB1c2Ug aW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCBiZWNhdXNlIGV2ZXJ5b25lIHdobyB1c2VzCiAgIHRo YXQgbGFuZ3VhZ2Uga25vd3Mgd2hhdCB0aGV5IGFyZSBhbmQgdGhleSBiZWNvbWUgYSB2aXN1YWwg c3Vic3RpdHV0ZSBmb3IgdGhlCiAgIGxhbmd1YWdlIGVsZW1lbnQuCgogICBCdXQgYXNzZW1ibHkg bWFjcm9zIGFyZSBfTk9UXyBhIG5ldyBsYW5ndWFnZSBpbiB0aGlzIHNlbnNlLCB0aGV5IGFyZSBh Y3R1YWxseSAKICAgbW9yZSBzaW1pbGFyIHRvIGxpYnJhcnkgZnVuY3Rpb24gbmFtZXM6IHdoZXJl IGJyZXZpdHkgaXMgYWN0dWFsbHkKICAgY291bnRlcmludHVpdGl2ZSBhbmQgaGFybWZ1bCwgYmVj YXVzZSB0aGV5IGFyZSBhbWJpZ3VvdXMgYW5kIHBvbGx1dGUgdGhlIAogICBnZW5lcmljIG5hbWVz cGFjZS4gSWYgeW91IGxvb2sgYXQgQyBsaWJyYXJ5IEFQSSBmdW5jdGlvbiBuYW1lIGJlc3QgcHJh Y3RpY2VzCiAgIHlvdSdsbCBzZWUgdGhhdCB0aGUgYmVzdCBvbmVzIGFyZSBhbGwgaGllcmFyY2hp Y2FsbHkgbmFtZWQgYW5kIGNhdGVnb3JpemVkLAogICB3aXRoIHRoZSBtb3JlIGdlbmVyaWMgY2F0 ZWdvcnkgcHV0IGZpcnN0LCB0aGV5IGFyZSB1bmFtYmlndW91c2x5IGJhbGFuY2VkIGV2ZW4KICAg aWYgdGhhdCBtYWtlcyB0aGUgbmFtZXMgbG9uZ2VyLCB0aGV5IGFyZSBjbGVhciBhbmQgdXNlIHVu ZGVyc2NvcmVzLgoKRm9yIGFsbCB0aGVzZSByZWFzb25zIHRoZSBuYW1pbmcgc2NoZW1lIHlvdSBz dWdnZXN0IGlzIG9uZSBvZiB0aGUgd29yc3Qgd2UgY291bGQgCmNvbWUgdXAgd2l0aCEgSSBtZWFu LCBpZiBJIGhhZCB0byBfaW50ZW50aW9uYWxseV8gZW5naW5lZXIgc29tZXRoaW5nIGFzIGhhcm1m dWwgYXMgCnBvc3NpYmxlIHRvIHJlYWRhYmlsaXR5IGFuZCBtYWludGFpbmFiaWxpdHkgdGhpcyB3 b3VsZCBiZSBwcmV0dHkgY2xvc2UgdG8gaXQuLi4KCkknbSB1cHNldCwgYmVjYXVzZSBldmVuIGEg c2luZ2xlIG1pbnV0ZSBvZiByZWZsZWN0aW9uIHNob3VsZCBoYXZlIHRvbGQgeW91IGFsbCAKdGhp cy4gSSBtZWFuLCBJTUhPIGl0J3Mgbm90IGV2ZW4gYSBjbG9zZSBhcmd1bWVudDogeW91ciBzdWdn ZXN0ZWQgbmFtaW5nIHNjaGVtZSBpcyAKYmxlZWRpbmcgZnJvbSBoYWxmIGEgZG96ZW4gb2YgbW9y dGFsIHdvdW5kcy4uLgoKSSBjYW4gYmUgY29udmluY2VkIHRvIGRyb3AgdGhlIGRvdWJsZSB1bmRl cnNjb3JlcyAoSSBzZWVtIHRvIGJlIGluIHRoZSBtaW5vcml0eSAKcmVnYXJkIHRoZW0pLCBhbmQg SSBjYW4gYmUgY29udmluY2VkIHRoYXQgJ0ZVTkMnIGlzIHNob3J0ZXIgYW5kIHN0aWxsIGVhc3kg dG8gCnVuZGVyc3RhbmQgaW5zdGVhZCBvZiAnRlVOQ1RJT04nLCBidXQgb3RoZXIgdGhhbiB0aGF0 IHBsZWFzZSBzdG9wIHRoZSBuYW1pbmcgCm1hZG5lc3MhCgpUaGFua3MsCgoJSW5nbwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5vcmcveGVu LWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754562AbdCGIas (ORCPT ); Tue, 7 Mar 2017 03:30:48 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33008 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579AbdCGIaj (ORCPT ); Tue, 7 Mar 2017 03:30:39 -0500 Date: Tue, 7 Mar 2017 09:27:50 +0100 From: Ingo Molnar To: hpa@zytor.com Cc: Thomas Gleixner , Jiri Slaby , mingo@redhat.com, x86@kernel.org, jpoimboe@redhat.com, linux-kernel@vger.kernel.org, Boris Ostrovsky , Juergen Gross , xen-devel@lists.xenproject.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org, Linus Torvalds , Andrew Morton , Peter Zijlstra Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Message-ID: <20170307082750.GA1695@gmail.com> References: <20170217104757.28588-1-jslaby@suse.cz> <20170301093855.GA27152@gmail.com> <20170301102754.GA13374@gmail.com> <39064F86-5BE2-417F-8A28-2B4CB5177D7D@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39064F86-5BE2-417F-8A28-2B4CB5177D7D@zytor.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * hpa@zytor.com wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >> > So how about using macro names that actually show the purpose, instead of > >> > importing all the crappy, historic, essentially randomly chosen debug > >> > symbol macro names from the binutils and older kernels? > >> > > >> > Something sane, like: > >> > > >> > SYM__FUNCTION_START > >> > >> Sane would be: > >> > >> SYM_FUNCTION_START > >> > >> The double underscore is just not giving any value. > > > > So the double underscore (at least in my view) has two advantages: > > > > 1) it helps separate the prefix from the postfix. > > > > I.e. it's a 'symbols' namespace, and a 'function start', not the 'start' of a > > 'symbol function'. > > > > 2) It also helps easy greppability. > > > > Try this in latest -tip: > > > > git grep e820__ > > > > To see all the E820 API calls - with no false positives! > > > > 'git grep e820_' on the other hand is a lot less reliable... > > IMO these little "namespace tricks" especially for small common macros like we > are taking about here make the code very frustrating to read, and even more to > write. Noone would design a programming language that way, and things like PROC > are really just substitutes for proper language features (and could even be as > assembly rather than cpp macros.) This is a totally different thing from language keywords which needs to be short and concise for obvious reasons. Keywords of languages get nested and are used all the time, and everyone needs to know them and they need to stay out of the way. The symbol start/end macros we are talking about here are _MUCH_ less common, and they are only ever used in a single nesting level: SYM__FUNC_START(some_kernel_asm_function) ... SYM__FUNC_END(some_kernel_asm_function) Most kernel developers writing new assembly code rarely know these constructs by heart, they just look them up and carbon copy existing practices. And guess what, the 'looking them up' gets harder if the macro naming scheme is an idosyncratic leftover from long ago. Kernel developers _reading_ assembly code will know the exact purpose of the macros even less, especially if they are named in an ambiguous, illogical fashion. Furthermore, your suggestion of: > PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and > balanced. Are neither clear, not unambiguous nor balanced! I mean, they are the _exact_ opposite: - 'PROC' is actually ambiguous in the kernel source code context, as it clashes with common abbreviations of 'procfs' and 'process'. It's also an unnecessary abbreviation of a word ('procedure') that is not actually used a _single time_ in the C ISO/IEC 9899:TC2 standard - in all half thousand+ pages of it. (!) Why the hell does this have to be used in the kernel? - It's visually and semantically imbalanced, because some terms have an 'END' prefix, but there's no matching 'START' or 'BEGIN' prefix for their counterparts. This makes it easy to commit various symbol definition termination errors, like: PROC(some_kernel_asm_function) ... Here it's not obvious that it needs an ENDPROC. While if it's written as: SYM__FUNC_START(some_kernel_asm_function) ... ... it's pretty obvious at first sight that an '_END' is missing! - What you suggest also has senselessly missing underscores, which makes it _more_ cluttered and less clear. We clearly don't have addtowaitqueue() and removefromwaitqueue() function names in the kernel, right? Why should we have 'ENDPROC' and 'ENDDATA' macro names? - Hierarchical naming schemes generally tend to put the more generic category name first, not last. So it's: mutex_init() mutex_lock() mutex_unlock() mutex_trylock() It's _NOT_ the other way around: init_mutex() lock_mutex() unlock_mutex() trylock_mutex() The prefix naming scheme is easier to read both visually/typographically (because it aligns vertically in a natural fashion so it's easier to pattern match), and also semantically: because when reading it it's easy to skip the line once your brain reads the generic category of 'mutex'. But with 'ENDPROC' my brain both has to needlessly perform the following steps: - disambiguate the 'END' and the 'PROC' - fill in the missing underscore - and finally when arriving at the generic term 'PROC', discard it as uninteresting - Short names have good use in programming languages, because everyone who uses that language knows what they are and they become a visual substitute for the language element. But assembly macros are _NOT_ a new language in this sense, they are actually more similar to library function names: where brevity is actually counterintuitive and harmful, because they are ambiguous and pollute the generic namespace. If you look at C library API function name best practices you'll see that the best ones are all hierarchically named and categorized, with the more generic category put first, they are unambiguously balanced even if that makes the names longer, they are clear and use underscores. For all these reasons the naming scheme you suggest is one of the worst we could come up with! I mean, if I had to _intentionally_ engineer something as harmful as possible to readability and maintainability this would be pretty close to it... I'm upset, because even a single minute of reflection should have told you all this. I mean, IMHO it's not even a close argument: your suggested naming scheme is bleeding from half a dozen of mortal wounds... I can be convinced to drop the double underscores (I seem to be in the minority regard them), and I can be convinced that 'FUNC' is shorter and still easy to understand instead of 'FUNCTION', but other than that please stop the naming madness! Thanks, Ingo