Hello! Attached is the patch that changes the default ssid from 0xffffffff to 0 as discussed in previous emails. Signed-off-by: Reiner Sailer <sailer@us.ibm.com> Signed-off-by: Stefan Berger <stefanb@us.ibm.com> Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Please make sure to increment the DOM0_INTERFACE_VERSION when this is committed. Thanks, Anthony Liguori Stefan Berger wrote:>Hello! > >Attached is the patch that changes the default ssid from 0xffffffff to 0 >as discussed in previous emails. > >Signed-off-by: Reiner Sailer <sailer@us.ibm.com> >Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > Stefan > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/25/05, Stefan Berger <stefanb@us.ibm.com> wrote:> Hello! > > Attached is the patch that changes the default ssid from 0xffffffff to 0 > as discussed in previous emails. > > Signed-off-by: Reiner Sailer <sailer@us.ibm.com> > Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > Stefan >+ for(j=0; j<= CWALL_MAX_SSIDREFS; j++) + if ((0 < j) &&( j <= CWALL_MAX_TYPES)) + ssidrefs[j*CWALL_MAX_TYPES + j - 1] = htons(1); + why dont you run the loop from j=1? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/25/05, Stefan Berger <stefanb@us.ibm.com> wrote:> Hello! > > Attached is the patch that changes the default ssid from 0xffffffff to 0 > as discussed in previous emails. > > Signed-off-by: Reiner Sailer <sailer@us.ibm.com> > Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > Stefanlooks like this patch (and also many other codes in the tree) mixed of tabs and spaces for indentation :-(. especially this code will be in mainline in the future. is it time for us to have a official *coding style guide*, and all the patches sent in must comply with the guide in order to be picked up ??? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sunday 26 June 2005 02:45, aq wrote:> looks like this patch (and also many other codes in the tree) mixed of > tabs and spaces for indentation :-(. especially this code will be in > mainline in the future. > > is it time for us to have a official *coding style guide*, and all the > patches sent in must comply with the guide in order to be picked up > ???It seems sensible for XenLinux code to follow the Linux CodingStyle document (although I''m not sure all the drivers do this yet). Xen-related C code that isn''t destined for the Linux kernel itself has a different coding style: * we indent in blocks of 4 spaces and don''t use tabs * { and } are always on a new line, unlike K&R style * we put a space between an if and the open parenthesis, and between the parentheses and the boolean: if ( murble ) There may be a few other things but I can''t think of them right now ;-) Fancy starting a Wiki page to collect coding style information? Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/25/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> On Sunday 26 June 2005 02:45, aq wrote: > > looks like this patch (and also many other codes in the tree) mixed of > > tabs and spaces for indentation :-(. especially this code will be in > > mainline in the future. > > > > is it time for us to have a official *coding style guide*, and all the > > patches sent in must comply with the guide in order to be picked up > > ??? > > It seems sensible for XenLinux code to follow the Linux CodingStyle document > (although I''m not sure all the drivers do this yet). > > Xen-related C code that isn''t destined for the Linux kernel itself has a > different coding style: > * we indent in blocks of 4 spaces and don''t use tabs > * { and } are always on a new line, unlike K&R style > * we put a space between an if and the open parenthesis, and between the > parentheses and the boolean: if ( murble )i think it is very bad idea to have 2 coding styles for code in kernel and out of kernel. because people work on all those code must always remember to adjust the editor configuration, depend on the code in or out of kernel, which is a nightmare :-( how about this simple guide? - C code complies Linux kernel coding style - Python code can use (4) spaces for indentation (as in currently) regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> i think it is very bad idea to have 2 coding styles for code in kernel > and out of kernel. because people work on all those code must always > remember to adjust the editor configuration, depend on the code in or > out of kernel, which is a nightmare :-(Yes, it''s an extra thing to think about. It also means that code imported from Linux needs adjusting to fit with the Xen coding convention. OTOH, we don''t just work with the Linux kernel any more, so there will be multiple coding conventions anyhow. I just set up emacs so I can type "M-x xen-c-mode" or "M-x linux-c-mode".> how about this simple guide? > - C code complies Linux kernel coding styleI don''t think this is likely to happen any time soon - it''d require patches to all of Xen and the tools :-( (and probably to some of the Linux code but that''s arguably desirable)> - Python code can use (4) spaces for indentation (as in currently)Definitely a good plan! Messing with Python''s indentation rules is playing with fire... Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Message: 7 > Date: Sat, 25 Jun 2005 20:39:20 -0500 > From: aq <aquynh@gmail.com> > Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0 > To: Stefan Berger <stefanb@us.ibm.com> > Cc: xen-devel@lists.xensource.com > Message-ID: <9cde8bff05062518394eab73cb@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 6/25/05, Stefan Berger <stefanb@us.ibm.com> wrote: > > Hello! > > > > Attached is the patch that changes the default ssid from 0xffffffff to0> > as discussed in previous emails. > > > > Signed-off-by: Reiner Sailer <sailer@us.ibm.com> > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > > > Stefan > > > > > > + for(j=0; j<= CWALL_MAX_SSIDREFS; j++) > + if ((0 < j) &&( j <= CWALL_MAX_TYPES)) > + ssidrefs[j*CWALL_MAX_TYPES + j - 1] = htons(1); > + > > why dont you run the loop from j=1?because row j=0 is the new default ssid and has no types set. We start with row j=1 and set the "diagonal" types to one.> regards, > aqThanks Reiner __________________________________________________________ Reiner Sailer, Research Staff Member, Secure Systems Department IBM T J Watson Research Ctr, 19 Skyline Drive, Hawthorne NY 10532 Phone: 914 784 6280 (t/l 863) Fax: 914 784 6205, sailer@us.ibm.com http://www.research.ibm.com/people/s/sailer/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/26/05, Reiner Sailer <sailer@us.ibm.com> wrote:> > Message: 7 > > Date: Sat, 25 Jun 2005 20:39:20 -0500 > > From: aq <aquynh@gmail.com> > > Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0 > > To: Stefan Berger <stefanb@us.ibm.com> > > Cc: xen-devel@lists.xensource.com > > Message-ID: <9cde8bff05062518394eab73cb@mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 6/25/05, Stefan Berger <stefanb@us.ibm.com> wrote: > > > Hello! > > > > > > Attached is the patch that changes the default ssid from 0xffffffff to > 0 > > > as discussed in previous emails. > > > > > > Signed-off-by: Reiner Sailer <sailer@us.ibm.com> > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > > > > > Stefan > > > > > > > > > > > + for(j=0; j<= CWALL_MAX_SSIDREFS; j++) > > + if ((0 < j) &&( j <= CWALL_MAX_TYPES)) > > + ssidrefs[j*CWALL_MAX_TYPES + j - 1] = htons(1); > > + > > > > why dont you run the loop from j=1? > > > because row j=0 is the new default ssid and has no types set. > We start with row j=1 and set the "diagonal" types to one.i meant in the above loop, if start from j=1 you can eliminate the check (if 0<j), because in case j=0 you does nothing. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/26/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > i think it is very bad idea to have 2 coding styles for code in kernel > > and out of kernel. because people work on all those code must always > > remember to adjust the editor configuration, depend on the code in or > > out of kernel, which is a nightmare :-( > > Yes, it''s an extra thing to think about. It also means that code imported > from Linux needs adjusting to fit with the Xen coding convention. > > OTOH, we don''t just work with the Linux kernel any more, so there will be > multiple coding conventions anyhow. I just set up emacs so I can type "M-x > xen-c-mode" or "M-x linux-c-mode". > > > how about this simple guide? > > - C code complies Linux kernel coding style > > I don''t think this is likely to happen any time soon - it''d require patches to > all of Xen and the tools :-( (and probably to some of the Linux code but > that''s arguably desirable) >yes, that is too bad. but at least if we have an official style, we can enforce the rules *from now on*. the old code can be fix later (if possible). regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Reiner Sailer wrote:>>From: aq <aquynh@gmail.com>>>+ for(j=0; j<= CWALL_MAX_SSIDREFS; j++) >>+ if ((0 < j) &&( j <= CWALL_MAX_TYPES)) >>+ ssidrefs[j*CWALL_MAX_TYPES + j - 1] = htons(1); >>+ >> >>why dont you run the loop from j=1? > > because row j=0 is the new default ssid and has no types set. > We start with row j=1 and set the "diagonal" types to one.I think aq''s point was that the above loop is equivalent to: #include <stdlib.h> // for ''min'' for (j = 1; j <= min(CWALL_MAX_SSIDREFS, CWALL_MAX_TYPES); j++) { ssidrefs[j*CWALL_MAX_TYPES + j - 1] = htons(1); } which is arguably clearer. -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
xen-devel-bounces@lists.xensource.com wrote on 06/25/2005 09:49:18 PM:> On Sunday 26 June 2005 02:45, aq wrote: > > looks like this patch (and also many other codes in the tree) mixed of > > tabs and spaces for indentation :-(. especially this code will be in > > mainline in the future. > > > > is it time for us to have a official *coding style guide*, and all the > > patches sent in must comply with the guide in order to be picked up > > ??? > > It seems sensible for XenLinux code to follow the Linux CodingStyledocument> (although I''m not sure all the drivers do this yet). > > Xen-related C code that isn''t destined for the Linux kernel itself has a> different coding style: > * we indent in blocks of 4 spaces and don''t use tabsThe drivers in the Linux sparse directory, are they falling under this category?> * { and } are always on a new line, unlike K&R style > * we put a space between an if and the open parenthesis, and between the> parentheses and the boolean: if ( murble )If there was a script that we could run over the code, it would make life easier. Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26 Jun 2005, at 17:10, Stefan Berger wrote:> The drivers in the Linux sparse directory, are they falling under this > category?Yes, and I think at least some of them are now mostly Linux style. It''ll be trivial to run them all through indent, plus a quick manual pass, before pushing upstream. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Keir Fraser (Keir.Fraser@cl.cam.ac.uk) wrote:> On 26 Jun 2005, at 17:10, Stefan Berger wrote: > >The drivers in the Linux sparse directory, are they falling under this > >category? > > Yes, and I think at least some of them are now mostly Linux style. > It''ll be trivial to run them all through indent, plus a quick manual > pass, before pushing upstream.Agreed, I had done this a while back, but dropped it since it was a large patch and seemed pointless at the time. thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 2005-06-26 at 12:10 -0400, Stefan Berger wrote:> xen-devel-bounces@lists.xensource.com wrote on 06/25/2005 09:49:18 PM: > > * { and } are always on a new line, unlike K&R style > > * we put a space between an if and the open parenthesis, and between the > > parentheses and the boolean: if ( murble ) > > If there was a script that we could run over the code, it would make life > easier.I agree; I would suggest that in addition to the english description of the coding style, there should be a list of the flags to pass to GNU indent to make it generate the desired style. - Josh Triplett _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel