From: Jan Engelhardt <jengelh@inai.de> To: Sam Ravnborg <sam@ravnborg.org> Cc: "Andrew Stiegmann (stieg)" <astiegmann@vmware.com>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, pv-drivers@vmware.com, vm-crosstalk@vmware.com, cschamp@vmware.com, gregkh@linuxfoundation.org Subject: Re: [vmw_vmci 11/11] Apply the header code to make VMCI build Date: Wed, 15 Aug 2012 22:45:00 +0200 (CEST) [thread overview] Message-ID: <alpine.LNX.2.01.1208152240550.23372@frira.zrqbmnf.qr> (raw) In-Reply-To: <20120802202205.GA9096@merkur.ravnborg.org> On Thursday 2012-08-02 22:22, Sam Ravnborg wrote: >> On Friday 2012-07-27 12:34, Sam Ravnborg wrote: >> >> +#ifndef _VMCI_COMMONINT_H_ >> >> +#define _VMCI_COMMONINT_H_ >> >> + >> >> +#include <linux/printk.h> >> >> +#include <linux/vmw_vmci_defs.h> >> > >> >Use inverse chrismas tree here. >> >Longer include lines first, and soret alphabetically when >> >lines are of the same length. >> >> So that's where unreadable include lists come from. >> Depth-first lexicographically-sorted is a lot less hassle, >> especially when it comes to merging patches that each >> add one different include. >This is applied in many parts of the kernels and has some benefits: >- easy to spot duplicates >- clash is less likely when two commit adds includes Sorting already addresses the two, the christmas thing (for files in a single dir) seems like adding no extra value. >>>The kernel types are u32 not uint32_t - these types belongs in user-space. >Found the following somewhere on the net: > >| - the kernel should not depend on, or pollute user-space naming. >| YOU MUST NOT USE "uint32_t" when that may not be defined, and >| user-space rules for when it is defined are arcane and totally >| arbitrary. I can see the reasoning for header files, but it seems irrelevant for code, in particular .c files, that never practically get exposed to userspace.
WARNING: multiple messages have this Message-ID (diff)
From: Jan Engelhardt <jengelh@inai.de> To: Sam Ravnborg <sam@ravnborg.org> Cc: pv-drivers@vmware.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, vm-crosstalk@vmware.com, "Andrew Stiegmann (stieg)" <astiegmann@vmware.com>, cschamp@vmware.com Subject: Re: [vmw_vmci 11/11] Apply the header code to make VMCI build Date: Wed, 15 Aug 2012 22:45:00 +0200 (CEST) [thread overview] Message-ID: <alpine.LNX.2.01.1208152240550.23372@frira.zrqbmnf.qr> (raw) In-Reply-To: <20120802202205.GA9096@merkur.ravnborg.org> On Thursday 2012-08-02 22:22, Sam Ravnborg wrote: >> On Friday 2012-07-27 12:34, Sam Ravnborg wrote: >> >> +#ifndef _VMCI_COMMONINT_H_ >> >> +#define _VMCI_COMMONINT_H_ >> >> + >> >> +#include <linux/printk.h> >> >> +#include <linux/vmw_vmci_defs.h> >> > >> >Use inverse chrismas tree here. >> >Longer include lines first, and soret alphabetically when >> >lines are of the same length. >> >> So that's where unreadable include lists come from. >> Depth-first lexicographically-sorted is a lot less hassle, >> especially when it comes to merging patches that each >> add one different include. >This is applied in many parts of the kernels and has some benefits: >- easy to spot duplicates >- clash is less likely when two commit adds includes Sorting already addresses the two, the christmas thing (for files in a single dir) seems like adding no extra value. >>>The kernel types are u32 not uint32_t - these types belongs in user-space. >Found the following somewhere on the net: > >| - the kernel should not depend on, or pollute user-space naming. >| YOU MUST NOT USE "uint32_t" when that may not be defined, and >| user-space rules for when it is defined are arcane and totally >| arbitrary. I can see the reasoning for header files, but it seems irrelevant for code, in particular .c files, that never practically get exposed to userspace.
next prev parent reply other threads:[~2012-08-15 20:45 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-26 23:39 [vmw_vmci 00/11] VMCI for Linux Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 01/11] Apply VMCI context code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:48 ` Greg KH 2012-07-26 23:48 ` Greg KH 2012-07-27 0:01 ` Andrew Stiegmann 2012-07-27 0:01 ` Andrew Stiegmann 2012-07-26 23:39 ` [vmw_vmci 02/11] Apply VMCI datagram code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 03/11] Apply VMCI doorbell code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 04/11] Apply VMCI driver code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 05/11] Apply VMCI event code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 06/11] Apply dynamic array code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 07/11] Apply VMCI hash table Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:49 ` Greg KH 2012-07-26 23:49 ` Greg KH 2012-07-27 0:01 ` Andrew Stiegmann 2012-07-27 0:01 ` Andrew Stiegmann 2012-07-26 23:39 ` [vmw_vmci 08/11] Apply VMCI queue pairs Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 09/11] Apply VMCI resource code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 10/11] Apply vmci routing code Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:39 ` [vmw_vmci 11/11] Apply the header code to make VMCI build Andrew Stiegmann (stieg) 2012-07-26 23:39 ` Andrew Stiegmann (stieg) 2012-07-26 23:56 ` Greg KH 2012-07-26 23:56 ` Greg KH 2012-07-27 9:53 ` Alan Cox 2012-07-27 9:53 ` Alan Cox 2012-07-27 18:04 ` [Pv-drivers] " Dmitry Torokhov 2012-07-27 18:04 ` Dmitry Torokhov 2012-07-27 10:34 ` Sam Ravnborg 2012-07-27 10:34 ` Sam Ravnborg 2012-07-27 17:20 ` Andrew Stiegmann 2012-07-27 17:20 ` Andrew Stiegmann 2012-07-27 18:16 ` Greg KH 2012-07-27 18:16 ` Greg KH 2012-07-27 18:39 ` Andrew Stiegmann 2012-07-27 18:39 ` Andrew Stiegmann 2012-07-27 18:52 ` Greg KH 2012-07-27 18:52 ` Greg KH 2012-07-27 20:29 ` [Pv-drivers] " Dmitry Torokhov 2012-07-27 20:29 ` Dmitry Torokhov 2012-07-28 19:55 ` Greg KH 2012-07-28 19:55 ` Greg KH 2012-07-28 21:10 ` Dmitry Torokhov 2012-07-28 21:10 ` Dmitry Torokhov 2012-07-27 19:53 ` Sam Ravnborg 2012-07-27 19:53 ` Sam Ravnborg 2012-07-27 20:07 ` Andrew Stiegmann 2012-07-27 20:07 ` Andrew Stiegmann 2012-08-02 19:50 ` Jan Engelhardt 2012-08-02 19:50 ` Jan Engelhardt 2012-08-02 20:22 ` Sam Ravnborg 2012-08-02 20:22 ` Sam Ravnborg 2012-08-15 20:45 ` Jan Engelhardt [this message] 2012-08-15 20:45 ` Jan Engelhardt 2012-07-26 23:47 ` [vmw_vmci 00/11] VMCI for Linux Greg KH 2012-07-26 23:47 ` Greg KH 2012-07-27 1:06 ` Josh Boyer 2012-07-27 1:06 ` Josh Boyer 2012-07-27 1:46 ` Greg KH 2012-07-27 1:46 ` Greg KH 2012-07-31 12:48 ` Josh Boyer 2012-07-31 12:48 ` Josh Boyer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LNX.2.01.1208152240550.23372@frira.zrqbmnf.qr \ --to=jengelh@inai.de \ --cc=astiegmann@vmware.com \ --cc=cschamp@vmware.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pv-drivers@vmware.com \ --cc=sam@ravnborg.org \ --cc=virtualization@lists.linux-foundation.org \ --cc=vm-crosstalk@vmware.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.