On Fri, Mar 16, 2007 at 08:53:53AM +0100, Bodo Eggert wrote:
> Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> > For source lines I've seen both:
> >
> > source "arch/powerpc/platforms/52xx/Kconfig"
> >
> > and
> >
> > source arch/powerpc/platforms/85xx/Kconfig
> >
> > Is there a preferred style?
Kumar Gala <[EMAIL PROTECTED]> wrote:
> For source lines I've seen both:
>
> source "arch/powerpc/platforms/52xx/Kconfig"
>
> and
>
> source arch/powerpc/platforms/85xx/Kconfig
>
> Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \"|wc -l
Kumar Gala [EMAIL PROTECTED] wrote:
For source lines I've seen both:
source arch/powerpc/platforms/52xx/Kconfig
and
source arch/powerpc/platforms/85xx/Kconfig
Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \|wc -l
732
$ find .
On Fri, Mar 16, 2007 at 08:53:53AM +0100, Bodo Eggert wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
For source lines I've seen both:
source arch/powerpc/platforms/52xx/Kconfig
and
source arch/powerpc/platforms/85xx/Kconfig
Is there a preferred style? Quotes or not?
$ find
For source lines I've seen both:
source "arch/powerpc/platforms/52xx/Kconfig"
and
source arch/powerpc/platforms/85xx/Kconfig
Is there a preferred style? Quotes or not?
- k
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
For source lines I've seen both:
source arch/powerpc/platforms/52xx/Kconfig
and
source arch/powerpc/platforms/85xx/Kconfig
Is there a preferred style? Quotes or not?
- k
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
2007/3/12, David Schwartz <[EMAIL PROTECTED]>:
> NULL has the same bit pattern as the number zero. (I'm not saying the bit
> pattern is all zeroes. And I am not even sure if NULL ought to
> have the same
> pattern as zero.) So C++ could use (void *)0, if it would let itself :p
They don't have
2007/3/12, David Schwartz [EMAIL PROTECTED]:
NULL has the same bit pattern as the number zero. (I'm not saying the bit
pattern is all zeroes. And I am not even sure if NULL ought to
have the same
pattern as zero.) So C++ could use (void *)0, if it would let itself :p
They don't have to
On Mon, 12 Mar 2007, Jan Engelhardt wrote:
>
> On Mar 12 2007 13:37, Cong WANG wrote:
> >
> > The following code is picked from drivers/kvm/kvm_main.c:
> >
> > static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
> > {
> > struct kvm_vcpu *vcpu = >vcpus[vcpu_slot];
> >
> >
On Mon, 2007-03-12 at 06:40 +0100, Jan Engelhardt wrote:
> On Mar 12 2007 13:37, Cong WANG wrote:
> >
> > The following code is picked from drivers/kvm/kvm_main.c:
> >
> > static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
> > {
> > struct kvm_vcpu *vcpu = >vcpus[vcpu_slot];
> >
> >
On Mar 12 2007 13:37, Cong WANG wrote:
>
> The following code is picked from drivers/kvm/kvm_main.c:
>
> static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
> {
> struct kvm_vcpu *vcpu = >vcpus[vcpu_slot];
>
> mutex_lock(>mutex);
> if (unlikely(!vcpu->vmcs)) {
>
2007/3/12, Jan Engelhardt <[EMAIL PROTECTED]>:
On Mar 11 2007 22:15, Cong WANG wrote:
>
> I have a question about coding style in linux kernel. In
> Documention/CodingStyle, it is said that "Linux style for comments is
> the C89 "/* ... */" style. Don't use C99-style "// ..." comments."
> _But_
On Mar 11, 2007, at 21:32:00, Jan Engelhardt wrote:
On Mar 11 2007 21:27, Kyle Moffett wrote:
On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
On Mar 11 2007 18:01, Kyle Moffett wrote:
On the other hand when __cplusplus is defined they define it to the
"__null" builtin, which GCC uses to
On Mar 11 2007 21:27, Kyle Moffett wrote:
> On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
>> On Mar 11 2007 18:01, Kyle Moffett wrote:
>> > On the other hand when __cplusplus is defined they define it to the
>> > "__null" builtin, which GCC uses to give type conversion errors for
>> > "int
On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
On Mar 11 2007 18:01, Kyle Moffett wrote:
On the other hand when __cplusplus is defined they define it to
the "__null" builtin, which GCC uses to give type conversion
errors for "int foo = NULL" but not "char *foo = NULL". A "((void
On Mar 11 2007 18:01, Kyle Moffett wrote:
> On Mar 11, 2007, at 16:41:51, Daniel Hazelton wrote:
>> On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
>> > On Mar 11 2007 22:15, Cong WANG wrote:
>> > > So can I say using NULL is better than 0 in kernel?
>> >
>> > On what basis? Do you even
On Mar 11, 2007, at 16:41:51, Daniel Hazelton wrote:
On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
On Mar 11 2007 22:15, Cong WANG wrote:
So can I say using NULL is better than 0 in kernel?
On what basis? Do you even know what NULL is defined as in (C, not
C++) userspace? Think
On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
> On Mar 11 2007 22:15, Cong WANG wrote:
> > Another question is about NULL. AFAIK, in user space, using NULL is
> > better than directly using 0 in C. In kernel, I know it used its own
> > NULL, which may be defined as ((void*)0), but it's
On Mar 11 2007 22:15, Cong WANG wrote:
>
> I have a question about coding style in linux kernel. In
> Documention/CodingStyle, it is said that "Linux style for comments is
> the C89 "/* ... */" style. Don't use C99-style "// ..." comments."
> _But_ I see a lot of '//' style comments in current
Cong WANG wrote:
Hi, list!
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that "Linux style for comments is
the C89 "/* ... */" style. Don't use C99-style "// ..." comments."
_But_ I see a lot of '//' style comments in current kernel code.
Which is
On Sun, 2007-03-11 at 22:15 +0800, Cong WANG wrote:
[...]
> Another question is about NULL. AFAIK, in user space, using NULL is
> better than directly using 0 in C. In kernel, I know it used its own
> NULL, which may be defined as ((void*)0),
Userspace has the usually same definition.
>
Hi, list!
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that "Linux style for comments is
the C89 "/* ... */" style. Don't use C99-style "// ..." comments."
_But_ I see a lot of '//' style comments in current kernel code.
Which is wrong? The
Hi, list!
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that Linux style for comments is
the C89 /* ... */ style. Don't use C99-style // ... comments.
_But_ I see a lot of '//' style comments in current kernel code.
Which is wrong? The documentions
On Sun, 2007-03-11 at 22:15 +0800, Cong WANG wrote:
[...]
Another question is about NULL. AFAIK, in user space, using NULL is
better than directly using 0 in C. In kernel, I know it used its own
NULL, which may be defined as ((void*)0),
Userspace has the usually same definition.
Cong WANG wrote:
Hi, list!
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that Linux style for comments is
the C89 /* ... */ style. Don't use C99-style // ... comments.
_But_ I see a lot of '//' style comments in current kernel code.
Which is
On Mar 11 2007 22:15, Cong WANG wrote:
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that Linux style for comments is
the C89 /* ... */ style. Don't use C99-style // ... comments.
_But_ I see a lot of '//' style comments in current kernel code.
On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
On Mar 11 2007 22:15, Cong WANG wrote:
Another question is about NULL. AFAIK, in user space, using NULL is
better than directly using 0 in C. In kernel, I know it used its own
NULL, which may be defined as ((void*)0), but it's _still_
On Mar 11, 2007, at 16:41:51, Daniel Hazelton wrote:
On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
On Mar 11 2007 22:15, Cong WANG wrote:
So can I say using NULL is better than 0 in kernel?
On what basis? Do you even know what NULL is defined as in (C, not
C++) userspace? Think
On Mar 11 2007 18:01, Kyle Moffett wrote:
On Mar 11, 2007, at 16:41:51, Daniel Hazelton wrote:
On Sunday 11 March 2007 16:35:50 Jan Engelhardt wrote:
On Mar 11 2007 22:15, Cong WANG wrote:
So can I say using NULL is better than 0 in kernel?
On what basis? Do you even know what NULL is
On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
On Mar 11 2007 18:01, Kyle Moffett wrote:
On the other hand when __cplusplus is defined they define it to
the __null builtin, which GCC uses to give type conversion
errors for int foo = NULL but not char *foo = NULL. A ((void
*)0)
On Mar 11 2007 21:27, Kyle Moffett wrote:
On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
On Mar 11 2007 18:01, Kyle Moffett wrote:
On the other hand when __cplusplus is defined they define it to the
__null builtin, which GCC uses to give type conversion errors for
int foo = NULL but
On Mar 11, 2007, at 21:32:00, Jan Engelhardt wrote:
On Mar 11 2007 21:27, Kyle Moffett wrote:
On Mar 11, 2007, at 19:16:59, Jan Engelhardt wrote:
On Mar 11 2007 18:01, Kyle Moffett wrote:
On the other hand when __cplusplus is defined they define it to the
__null builtin, which GCC uses to
2007/3/12, Jan Engelhardt [EMAIL PROTECTED]:
On Mar 11 2007 22:15, Cong WANG wrote:
I have a question about coding style in linux kernel. In
Documention/CodingStyle, it is said that Linux style for comments is
the C89 /* ... */ style. Don't use C99-style // ... comments.
_But_ I see a lot
On Mar 12 2007 13:37, Cong WANG wrote:
The following code is picked from drivers/kvm/kvm_main.c:
static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
{
struct kvm_vcpu *vcpu = kvm-vcpus[vcpu_slot];
mutex_lock(vcpu-mutex);
if (unlikely(!vcpu-vmcs)) {
On Mon, 2007-03-12 at 06:40 +0100, Jan Engelhardt wrote:
On Mar 12 2007 13:37, Cong WANG wrote:
The following code is picked from drivers/kvm/kvm_main.c:
static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
{
struct kvm_vcpu *vcpu = kvm-vcpus[vcpu_slot];
On Mon, 12 Mar 2007, Jan Engelhardt wrote:
On Mar 12 2007 13:37, Cong WANG wrote:
The following code is picked from drivers/kvm/kvm_main.c:
static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
{
struct kvm_vcpu *vcpu = kvm-vcpus[vcpu_slot];
mutex_lock(vcpu-mutex);
On 2/9/07, Pavel Pisa <[EMAIL PROTECTED]> wrote:
#define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask))
#define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1)))
Looks a bit similar to the style I tend to use a lot:
/* Bit manipulation macros */
#define MACB_BIT(name)
Pavel Pisa wrote:
> There are tightly copled two macros for preparation
> and acquisition of muti-bit masked fields values
>
> #define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask))
>
> #define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1)))
The macro names are awkward.
On 09/02/07, Pavel Pisa <[EMAIL PROTECTED]> wrote:
Hello All,
I have question if next style of macros definitions
for hardware registers is acceptable (tastefull for
maintainers) for Linux kernel.
It is generally preferred to keep macro names all uppercase.
Also, when possible, static inline
Hello All,
I have question if next style of macros definitions
for hardware registers is acceptable (tastefull for
maintainers) for Linux kernel.
/* Register offset against peripheral base */
#define SUBSYSTEM_REGISTER_o 0x0
/* The register field mask */
#define REGISTER_FUNCTION_m 0x0
Hello All,
I have question if next style of macros definitions
for hardware registers is acceptable (tastefull for
maintainers) for Linux kernel.
/* Register offset against peripheral base */
#define SUBSYSTEM_REGISTER_o 0x0
/* The register field mask */
#define REGISTER_FUNCTION_m 0x0
On 09/02/07, Pavel Pisa [EMAIL PROTECTED] wrote:
Hello All,
I have question if next style of macros definitions
for hardware registers is acceptable (tastefull for
maintainers) for Linux kernel.
It is generally preferred to keep macro names all uppercase.
Also, when possible, static inline
Pavel Pisa wrote:
There are tightly copled two macros for preparation
and acquisition of muti-bit masked fields values
#define __val2mfld(mask,val) (((mask)~((mask)1))*(val)(mask))
#define __mfld2val(mask,val) (((val)(mask))/((mask)~((mask)1)))
The macro names are awkward.
On 2/9/07, Pavel Pisa [EMAIL PROTECTED] wrote:
#define __val2mfld(mask,val) (((mask)~((mask)1))*(val)(mask))
#define __mfld2val(mask,val) (((val)(mask))/((mask)~((mask)1)))
Looks a bit similar to the style I tend to use a lot:
/* Bit manipulation macros */
#define MACB_BIT(name)
44 matches
Mail list logo
