[Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Philippe Gerum]

Resending here since this is a general project issue.

-------- Original Message --------
Subject: Re: [Xenomai-help] timeout in native API calls          (cond, sem, 
mutex, etc).
Date: Fri, 21 Oct 2005 18:45:59 +0200
From: Philippe Gerum <rpm@xenomai.org>
Organization: Xenomai
To: Jan Kiszka <kiszka@domain.hid>
CC: xenomai@xenomai.org
References: <4357C3E1.1040701@domain.hid> 
<4357C9F7.2060808@domain.hid>	<4357CF67.8080601@domain.hid> 
<4357DF0F.3060806@domain.hid>	<435896AA.1060103@domain.hid> 
<4358C829.5050304@domain.hid>	<4358DDAE.2090703@domain.hid>

Jan Kiszka wrote:
> Ignacio García Pérez wrote:
> 
>>...
>>P.S: As a side note, wouldn't be a good practice to expand tabs to
>>spaces in all the code?
> 
> 
> My opinion is yes - but it's a nasty work. Would you provide such
> patches...?
> 

Actually, there is a more general problem with the current coding style used
throughout the code base: it's mine, it's not that standard, and now thatmore
people are contributing to it, I'm pondering whether we should just adoptthe
conventional kernel coding style, without the ludicrous 8-space tabs, that is.

-- 

Philippe.

_______________________________________________
Xenomai-help mailing list
Xenomai-help@domain.hid
https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.

Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Heikki Lindholm]

Philippe Gerum kirjoitti:
> 
> Resending here since this is a general project issue.
> 
> -------- Original Message --------
> Subject: Re: [Xenomai-help] timeout in native API calls          (cond, 
> sem, mutex, etc).
> Date: Fri, 21 Oct 2005 18:45:59 +0200
> From: Philippe Gerum <rpm@xenomai.org>
> Organization: Xenomai
> To: Jan Kiszka <kiszka@domain.hid>
> CC: xenomai@xenomai.org
> References: <4357C3E1.1040701@domain.hid> 
> <4357C9F7.2060808@domain.hid>    <4357CF67.8080601@domain.hid> 
> <4357DF0F.3060806@domain.hid>    <435896AA.1060103@domain.hid> 
> <4358C829.5050304@domain.hid>    <4358DDAE.2090703@domain.hid>
> 
> Jan Kiszka wrote:
> 
>> Ignacio García Pérez wrote:
>>
>>> ...
>>> P.S: As a side note, wouldn't be a good practice to expand tabs to
>>> spaces in all the code?
>>
>>
>>
>> My opinion is yes - but it's a nasty work. Would you provide such
>> patches...?
>>
> 
> Actually, there is a more general problem with the current coding style 
> used
> throughout the code base: it's mine, it's not that standard, and now 
> thatmore
> people are contributing to it, I'm pondering whether we should just 
> adoptthe
> conventional kernel coding style, without the ludicrous 8-space tabs, 
> that is.

I'm pro kernel style. Now the style is bit of a mixed bag, especially 
where there is code copied from somewhere else. I don't even have 
anything against them 8-spaced tab stops.

-- Heikki Lindholm

Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Dmitry Adamushko]

On Friday 21 October 2005 19:35, Philippe Gerum wrote:
>
> Actually, there is a more general problem with the current coding style
> used throughout the code base: it's mine, it's not that standard,

then what's standard in this case?

> and now 
> thatmore people are contributing to it, I'm pondering whether we should
> just adoptthe conventional kernel coding style, without the ludicrous
> 8-space tabs, that is.

The "kernel coding style" is just yet another codding style. If more people 
are contributing to the project, then it should be a standard that satisfies 
the most part of them. Is it necessarily the linux way?
As I told you once, the important thing is how easily the code may be read, 
hence, understood. IMHO, how/where the braces, etc. are placed is not the 
matter of the first instance.
The use of any codding style doesn't result in neat and well-readable code 
automagically.

Nevertheless, if the ideas are as follows:

1) linux codding style as a part of the seamless integration with the linux 
kernel. err.., what about a possibility to be merged with the mainline 
kernel? ok, sounds almost impossible :) ;

2) linux people are reading/will read the code, there are a lot of 
style-adherents amongst them, so let's keep them satisfied and our mail boxes 
free of the messages like "first change your codding style before submitting 
anything" (btw, I remember one of the answers after publishing of first 
i-pipe patch was of that kind). btw, there are some parts of the kernel (e.g. 
some filesystems, if I'm not wrong) that use another style;

3) ok, I may assume, that if a person is familiar with some codding style, 
he/she gets a few percent speed-up when reading the code that is of the same 
style. At least, for the first few minutes :) But here we must assume that 
the most part of the potential readers/contributors like the linux codding 
way.

err.. to sum it up, I like the current codding style, but if 1-3) + smth else 
are worthy things, then why not. I'll get used to another style, if the code 
will remain err. well-readable :)

>
> --

>
> Philippe.
>

---
Best regards,
Dmitry

Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Philippe Gerum]

Dmitry Adamushko wrote:
> On Friday 21 October 2005 19:35, Philippe Gerum wrote:
> 
>>Actually, there is a more general problem with the current coding style
>>used throughout the code base: it's mine, it's not that standard,
> 
> 
> then what's standard in this case?
> 

By standard, I mean the one which is the most widely used in the context of 
kernel development, which is relevant to the larger and most active part of the 
Xenomai codebase.

> 
>>and now 
>>thatmore people are contributing to it, I'm pondering whether we should
>>just adoptthe conventional kernel coding style, without the ludicrous
>>8-space tabs, that is.
> 
> 
> The "kernel coding style" is just yet another codding style. If more people 
> are contributing to the project, then it should be a standard that satisfies 
> the most part of them. Is it necessarily the linux way?
> As I told you once, the important thing is how easily the code may be read, 
> hence, understood. IMHO, how/where the braces, etc. are placed is not the 
> matter of the first instance.
> The use of any codding style doesn't result in neat and well-readable code 
> automagically.
> 
> Nevertheless, if the ideas are as follows:
> 
> 1) linux codding style as a part of the seamless integration with the linux 
> kernel. err.., what about a possibility to be merged with the mainline 
> kernel? ok, sounds almost impossible :) ;
> 

Maybe on April 1st.

> 2) linux people are reading/will read the code, there are a lot of 
> style-adherents amongst them, so let's keep them satisfied and our mail boxes 
> free of the messages like "first change your codding style before submitting 
> anything" (btw, I remember one of the answers after publishing of first 
> i-pipe patch was of that kind). btw, there are some parts of the kernel (e.g. 
> some filesystems, if I'm not wrong) that use another style;
> 

Allowing people to agree on a common coding style, which is basically K&R for 
the presentation part, and a few recommendations which belong to common sense, 
is usually the best way to avoid further ludicrous flamewars and unsmart 
assaults from smart asses about the cosmological importance of brace placement 
in the dynamic balance of things in the universe...


> 3) ok, I may assume, that if a person is familiar with some codding style, 
> he/she gets a few percent speed-up when reading the code that is of the same 
> style. At least, for the first few minutes :) But here we must assume that 
> the most part of the potential readers/contributors like the linux codding 
> way.
>

As you pointed out, this is also about allowing people used to K&R style to read 
this code as they would do with any contributed kernel code without any useless 
stylistic barrier on entry, would they be interested in doing so, that is. 
Reading some comments on the LKML about real-time extensions (by opposition to 
native real-time support a la PREEMPT_RT), it seems that there is a fair amount 
of confusion, misinformation and urban legends still going there. Part of the 
reasons for this is very likely that very few actually ever tried to look at the 
code. There must be some reason for that, aside of "they don't care", that is.

> err.. to sum it up, I like the current codding style, but if 1-3) + smth else 
> are worthy things, then why not. I'll get used to another style, if the code 
> will remain err. well-readable :)
> 

The basic idea I had for RTAI/fusion has not changed with Xenomai "reloaded": we 
are working hard to have the highest possible level of integration with the 
Linux kernel while keeping the advantages the co-scheduling approach still has 
over any purely native implementation. In order to achieve this, it would make 
sense to share as many (reasonable) conventions as possible with the kernel people.

> 
>>--
> 
> 
>>Philippe.
>>
> 
> 
> ---
> Best regards,
> Dmitry
> 


-- 

Philippe.

Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]

Philippe Gerum wrote:
> Dmitry Adamushko wrote:
> 
>> On Friday 21 October 2005 19:35, Philippe Gerum wrote:
>>
>>> Actually, there is a more general problem with the current coding style
>>> used throughout the code base: it's mine, it's not that standard,
>>
>>
>>
>> then what's standard in this case?
>>
> 
> By standard, I mean the one which is the most widely used in the context
> of kernel development, which is relevant to the larger and most active
> part of the Xenomai codebase.
> 
>>
>>> and now thatmore people are contributing to it, I'm pondering whether
>>> we should
>>> just adoptthe conventional kernel coding style, without the ludicrous
>>> 8-space tabs, that is.
>>
>>
>>
>> The "kernel coding style" is just yet another codding style. If more
>> people are contributing to the project, then it should be a standard
>> that satisfies the most part of them. Is it necessarily the linux way?
>> As I told you once, the important thing is how easily the code may be
>> read, hence, understood. IMHO, how/where the braces, etc. are placed
>> is not the matter of the first instance.
>> The use of any codding style doesn't result in neat and well-readable
>> code automagically.
>>
>> Nevertheless, if the ideas are as follows:
>>
>> 1) linux codding style as a part of the seamless integration with the
>> linux kernel. err.., what about a possibility to be merged with the
>> mainline kernel? ok, sounds almost impossible :) ;
>>
> 
> Maybe on April 1st.
> 
>> 2) linux people are reading/will read the code, there are a lot of
>> style-adherents amongst them, so let's keep them satisfied and our
>> mail boxes free of the messages like "first change your codding style
>> before submitting anything" (btw, I remember one of the answers after
>> publishing of first i-pipe patch was of that kind). btw, there are
>> some parts of the kernel (e.g. some filesystems, if I'm not wrong)
>> that use another style;
>>
> 
> Allowing people to agree on a common coding style, which is basically
> K&R for the presentation part, and a few recommendations which belong to
> common sense, is usually the best way to avoid further ludicrous
> flamewars and unsmart assaults from smart asses about the cosmological
> importance of brace placement in the dynamic balance of things in the
> universe...
> 
> 
>> 3) ok, I may assume, that if a person is familiar with some codding
>> style, he/she gets a few percent speed-up when reading the code that
>> is of the same style. At least, for the first few minutes :) But here
>> we must assume that the most part of the potential
>> readers/contributors like the linux codding way.
>>
> 
> As you pointed out, this is also about allowing people used to K&R style
> to read this code as they would do with any contributed kernel code
> without any useless stylistic barrier on entry, would they be interested
> in doing so, that is. Reading some comments on the LKML about real-time
> extensions (by opposition to native real-time support a la PREEMPT_RT),
> it seems that there is a fair amount of confusion, misinformation and
> urban legends still going there. Part of the reasons for this is very
> likely that very few actually ever tried to look at the code. There must
> be some reason for that, aside of "they don't care", that is.
> 
>> err.. to sum it up, I like the current codding style, but if 1-3) +
>> smth else are worthy things, then why not. I'll get used to another
>> style, if the code will remain err. well-readable :)
>>
> 
> The basic idea I had for RTAI/fusion has not changed with Xenomai
> "reloaded": we are working hard to have the highest possible level of
> integration with the Linux kernel while keeping the advantages the
> co-scheduling approach still has over any purely native implementation.
> In order to achieve this, it would make sense to share as many
> (reasonable) conventions as possible with the kernel people.
> 

I don't see an urgent need to go and change the whole code to kernel
coding style, I only see the need to keep one consistent style across
the code. This just may require a bit more iterations for "third-party"
contributed patches.

Ok, the ipipe patch as the part being integrated in the kernel, that one
should conform to kernel style to make it easier readable for inflexible
kernel hackers. But for the rest (which will very likely never made it
into the kernel), we should decide based on a broader basis than just
"follow the kernel herd".

Personally, I don't like hard-tabs (think they are too often misused to
format text alignment instead of just indenting code blocks), but I can
live with any style - as long as it is consistent and comprehensible.
Now as we already have such a style, why to change it right now? I would
say: just enforce it.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > I don't see an urgent need to go and change the whole code to kernel
 > coding style, I only see the need to keep one consistent style across
 > the code. This just may require a bit more iterations for "third-party"
 > contributed patches.
 > 
 > Ok, the ipipe patch as the part being integrated in the kernel, that one
 > should conform to kernel style to make it easier readable for inflexible
 > kernel hackers. But for the rest (which will very likely never made it
 > into the kernel), we should decide based on a broader basis than just
 > "follow the kernel herd".
 > 
 > Personally, I don't like hard-tabs (think they are too often misused to
 > format text alignment instead of just indenting code blocks), but I can
 > live with any style - as long as it is consistent and comprehensible.
 > Now as we already have such a style, why to change it right now? I would
 > say: just enforce it.

I don't like hard-tabs either, I guess kernel people are using them to
save disk space, but since Xenomai sources are not large, we have no
reason to use them.

As for braces placement, I used to dislike Xenomai style (where
does it come from anyway, BSD ?), but got accustomed to it; after all,
it is readable. Anyway, I prefer the kernel style, except for the 8
spaces "c-basic-offset" to talk in emacs cc-mode language...

I would also prefer avoiding the stupid naming rules I had to follow in
some companies.

-- 


					    Gilles Chanteperdrix.