Xen devel - Jan 2006 - xen source files and linux coding style

Due to my recent experience submitting a linux patch to lkml, I have
become more knowledgeable wrt linux coding style :) I''ve noticed a
couple of things in Xen and Xen-linux that we should consider changing
during normal development in preparation for the upstream merge.

The most immediate problem is conforming to the linux indentation
format. In Documentation/CodingStyle there is an emacs C mode for
linux, defined as:

(defun linux-c-mode ()
  "C mode with adjusted defaults for use with the Linux kernel."
  (interactive)
  (c-mode)
  (c-set-style "K&R")
  (setq tab-width 8)
  (setq indent-tabs-mode t)
  (setq c-basic-offset 8))


This is different from what we are using in Xen: 

/*
 * Local variables:
 * mode: C
 * c-set-style: "BSD"
 * c-basic-offset: 4
 * tab-width: 4
 * indent-tabs-mode: nil
 * End:
 */

The biggest problem here is turning tabs off. Tabs need to be used
instead of spaces. As well, the indentation needs to set to 8. 

The second thing I have come across recently are typedefs. Typedefs
are not mentioned in CodingStyle, but I know that they are frowned
upon. The only typedef''s that might be "correct" are when
using
function pointers, to make the code easier to read. 

I''m certainly not an expert on linux coding style (or CodingStyle) and
will gladly accept any advice or correction on these issues. I find
myself making these changes on files that I know may need to be
submitted to lkml. 

Mike Day

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> The biggest problem here is turning tabs off. Tabs need to be used
> instead of spaces. As well, the indentation needs to set to 8.
> 
If tabs are tabs, then surely the indentation itself doesn''t matter? I
like the use of tabs as it means that I can use my personal preference
of a tab size of 1 or 2, and someone else modifying the same file can
use 8.

Personally I think that a tab size of 8 is #$%&! ridiculous, but as long
as they''re tabs I can view them however I want :)

Is there any way that cvs/svn/hg/whatever can be coding style agnostic?
I mean as long as it''s all under source control then why does coding
style even matter... it should be possible to have a filter that
converts source files to your personal coding style preference on
checkout, and then back again on checkin. But I guess that''s just a
dream :)

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Due to my recent experience submitting a linux patch to lkml, 
> I have become more knowledgeable wrt linux coding style :) 
> I''ve noticed a couple of things in Xen and Xen-linux that we 
> should consider changing during normal development in 
> preparation for the upstream merge.
Our intention is that the coding style used for the linux sparse tree
(and merge tree) should certainly be consistent with that of the rest of
linux. This includes the front/back drivers.

However, xen has never used linux style. We''ve always used BSD style 4
space tabs for xen and the tools. I believe the tree to be in a
reasonably consistent state with respect to coding style, at least for
x86. [there are however a handfull of files that are so closely derived
from linux that we''ve left the original formatting to make diffs
easier.]

I personally don''t find having a mix of coding styles in the tree
problematic, and make edits consistent with the rest of the file. The
emacs mode directives in many of the files make this even easier.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel