All of lore.kernel.org
 help / color / mirror / Atom feed
* Coding style question
@ 2007-02-09 10:32 Pavel Pisa
  2007-02-09 11:18 ` Jesper Juhl
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Pavel Pisa @ 2007-02-09 10:32 UTC (permalink / raw)
  To: Russell King - ARM Linux, linux-kernel; +Cc: Sascha Hauer, Pierre Ossman

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 0x00000

/* The register field mask */
#define REGISTER_FUNCTION_m 0x00000

/* The register field starting bit */
#define REGISTER_FUNCTION_b 0x00

I am used to use this over many of our embedded
targets mainly developed without operating system.
I would like to use this for Linux drivers as well.

The naming convention has advantage, that it
prevents mistakes, when mask value (*_m) is used
in bit set/clear function without notice instead
of bitnumber (*_b).

The SUBSYSTEM_REGISTER -> REGISTER_FUNCTION
prevents mistakes, when field defined for one register
is used with incorrect register by mistake.

I would like to use this style in i.MX SDHC to
allow support both controllers on MX21.
I would like to use it in other areas as well.

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)))

__raw_writel(REGISTER_SINGLEBIT_m |
             __val2mfld(REGISTER_MULTIBIT_m,value),
             periph_base + SUBSYSTEM_REGISTER_o)

x = __mfld2val(REGISTER_MULTIBIT_m,
           _raw_readl(periph_base + SUBSYSTEM_REGISTER_o))

The macros seems to be complicated, but they generate optimal
code for constant fields masks. I am not aware, that there
is some commonly available alternative in Linux kernel
header files.

Suggestions, names corrections etc. are welcomed.
If you think, that it is not good idea to introduce
yet another style, I would try to follow actual style
found in each source file. If you prefer some already
utilized style, direct me to right examples, please.

Best wishes

              Pavel Pisa

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Coding style question
  2007-02-09 10:32 Coding style question Pavel Pisa
@ 2007-02-09 11:18 ` Jesper Juhl
  2007-02-09 16:02 ` Stefan Richter
  2007-02-09 20:46 ` Haavard Skinnemoen
  2 siblings, 0 replies; 13+ messages in thread
From: Jesper Juhl @ 2007-02-09 11:18 UTC (permalink / raw)
  To: Pavel Pisa
  Cc: Russell King - ARM Linux, linux-kernel, Sascha Hauer, Pierre Ossman

On 09/02/07, Pavel Pisa <pisa@cmp.felk.cvut.cz> 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 functions are preferred over macros.

[...snip...]
> found in each source file. If you prefer some already
> utilized style, direct me to right examples, please.
>
Documentation/CodingStyle : Chapter 12: Macros, Enums and RTL

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Coding style question
  2007-02-09 10:32 Coding style question Pavel Pisa
  2007-02-09 11:18 ` Jesper Juhl
@ 2007-02-09 16:02 ` Stefan Richter
  2007-02-09 20:46 ` Haavard Skinnemoen
  2 siblings, 0 replies; 13+ messages in thread
From: Stefan Richter @ 2007-02-09 16:02 UTC (permalink / raw)
  To: Pavel Pisa
  Cc: Russell King - ARM Linux, linux-kernel, Sascha Hauer, Pierre Ossman

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.
http://lxr.linux.no/source/Documentation/CodingStyle?v=2.6.18#L133

Consider longer names (and to partially counteract column consumption,
omit the leading underscores) or at least spell their purpose out in a
short comment at the macro definitions.
-- 
Stefan Richter
-=====-=-=== --=- -=--=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Coding style question
  2007-02-09 10:32 Coding style question Pavel Pisa
  2007-02-09 11:18 ` Jesper Juhl
  2007-02-09 16:02 ` Stefan Richter
@ 2007-02-09 20:46 ` Haavard Skinnemoen
  2 siblings, 0 replies; 13+ messages in thread
From: Haavard Skinnemoen @ 2007-02-09 20:46 UTC (permalink / raw)
  To: Pavel Pisa
  Cc: Russell King - ARM Linux, linux-kernel, Sascha Hauer, Pierre Ossman

On 2/9/07, Pavel Pisa <pisa@cmp.felk.cvut.cz> 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)                                  \
        (1 << MACB_##name##_OFFSET)
#define MACB_BF(name,value)                             \
        (((value) & ((1 << MACB_##name##_SIZE) - 1))    \
         << MACB_##name##_OFFSET)
#define MACB_BFEXT(name,value)\
        (((value) >> MACB_##name##_OFFSET)              \
         & ((1 << MACB_##name##_SIZE) - 1))
#define MACB_BFINS(name,value,old)                      \
        (((old) & ~(((1 << MACB_##name##_SIZE) - 1)     \
                    << MACB_##name##_OFFSET))           \
         | MACB_BF(name,value))

where BF stands for bitfield, EXT for extract and INS for insert.

The macros are butt ugly, but code using them is hopefully quite easy
to read (I'm of course not qualified to judge code I wrote myself.)
The somewhat excessive pasting ensures that if you ever switch the
name and value arguments, the compiler will let you know.

Example usage:

macb_writel(bp, REG, MACB_BF(FIELD, value));
regval = macb_readl(bp, REG);
value = MACB_BFEXT(FIELD, regval);

Haavard

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 22:40     ` Patrick Mansfield
@ 2004-02-26 16:09       ` Clay Haapala
  0 siblings, 0 replies; 13+ messages in thread
From: Clay Haapala @ 2004-02-26 16:09 UTC (permalink / raw)
  To: linux-scsi

On Wed, 25 Feb 2004, Patrick Mansfield outgrape:
> On Wed, Feb 25, 2004 at 11:40:27AM -0700, Jay Denebeim wrote:
>> On Wed, 25 Feb 2004, Matthew Wilcox wrote:
>> 
>> > On Wed, Feb 25, 2004 at 06:16:48PM +0000, Jay Denebeim wrote:
>> (I mentioned typedefs being removed)
>> > > what was the reasoning for this?
>> > 
>> > We hate typedefs.
>> 
>> Well, that's certainly convincing.  Funny that, I don't recall
>> hating typedefs, in fact I distinctly recall liking them and being
>> happy when they were added to Lattice's Amiga compiler back in the
>> stone age.  Is there some particular reason 'we' hate them?
> 
> Hi here's part of Greg's presentation from some time back:
> 
> http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/mgp00024.html
> 
> Really you want the next slide off the above ;-)
> 

"... and we hates hobbitses."

Sorry, just couldn't resist, but that voice popped into my head.
-- 
Clay Haapala (chaapala@cisco.com) Cisco Systems SRBU +1 763-398-1056
   6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD
 "You thought there wouldn't be a nuclear war?  There have been
  *seventeen* of them!"
   -- from "Millenium", by John Varley

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 18:40   ` Jay Denebeim
  2004-02-25 19:29     ` Randy.Dunlap
  2004-02-25 22:40     ` Patrick Mansfield
@ 2004-02-26  1:28     ` Jeff Garzik
  2 siblings, 0 replies; 13+ messages in thread
From: Jeff Garzik @ 2004-02-26  1:28 UTC (permalink / raw)
  To: Jay Denebeim; +Cc: linux-scsi

Two reasons I can think of off the top of my head:
* POSIX prefers "struct foo" as opposed to "foo" or "foo_t"

* typedefs obscure the fact that a data structure is in fact a 
structure, and not a native machine type.  Typically typedefs are best 
used for discrete elements those contents are either opaque or a single 
value.

	Jeff




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 19:37       ` Jay Denebeim
@ 2004-02-26  0:02         ` Bryan Henderson
  0 siblings, 0 replies; 13+ messages in thread
From: Bryan Henderson @ 2004-02-26  0:02 UTC (permalink / raw)
  To: Jay Denebeim; +Cc: linux-scsi

>Personally I
>never found that it did that for me, the 'struct' always seemed
>redundant.

I don't find it redundant at all -- it tells me the type is a structure as 
opposed to a scalar or pointer.  Realistically, no one studies the 
declarations of types before reading the code that uses them.  When I see 
a variable foo, it helps me a lot to guess what the variable is if I know 
it is a structure.

For that reason, the usual anti-typedef rule is just "we hate typedefs for 
structs," since the only difference between "struct foo" and "foo_t" is 
that one uses slightly fewer characters and obscures the fact that it is a 
structure.  On the other hand, the difference between "int" and "pid_t" is 
much greater.  The name "pid_t" carries a lot of information in it that 
"int" does not.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 18:40   ` Jay Denebeim
  2004-02-25 19:29     ` Randy.Dunlap
@ 2004-02-25 22:40     ` Patrick Mansfield
  2004-02-26 16:09       ` Clay Haapala
  2004-02-26  1:28     ` Jeff Garzik
  2 siblings, 1 reply; 13+ messages in thread
From: Patrick Mansfield @ 2004-02-25 22:40 UTC (permalink / raw)
  To: Jay Denebeim; +Cc: linux-scsi

On Wed, Feb 25, 2004 at 11:40:27AM -0700, Jay Denebeim wrote:
> On Wed, 25 Feb 2004, Matthew Wilcox wrote:
> 
> > On Wed, Feb 25, 2004 at 06:16:48PM +0000, Jay Denebeim wrote:
> (I mentioned typedefs being removed)
> > > what was the reasoning for this?
> > 
> > We hate typedefs.
> 
> Well, that's certainly convincing.  Funny that, I don't recall hating
> typedefs, in fact I distinctly recall liking them and being happy when
> they were added to Lattice's Amiga compiler back in the stone age.  Is
> there some particular reason 'we' hate them?

Hi here's part of Greg's presentation from some time back:

http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/mgp00024.html

Really you want the next slide off the above ;-)

-- Patrick Mansfield

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 19:29     ` Randy.Dunlap
@ 2004-02-25 19:37       ` Jay Denebeim
  2004-02-26  0:02         ` Bryan Henderson
  0 siblings, 1 reply; 13+ messages in thread
From: Jay Denebeim @ 2004-02-25 19:37 UTC (permalink / raw)
  To: linux-scsi

In article <20040225112905.33bfdea8.rddunlap@osdl.org>,
Randy.Dunlap <rddunlap@osdl.org> wrote:

>For anything other than very basic types, they hide/obfuscate data
>structures.  If it's a struct, we had rather see a struct used there.

Okay, that's more or less what I figured it was, thanks.  Personally I
never found that it did that for me, the 'struct' always seemed
redundant.  That's just my opinion though, and I can certainly
understand others.

Thanks for the answer.
Jay
-- 
* Jay Denebeim  Moderator       rec.arts.sf.tv.babylon5.moderated *
* newsgroup submission address: b5mod@deepthot.org                *
* moderator contact address:    b5mod-request@deepthot.org        *
* personal contact address:     denebeim@deepthot.org             *

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 18:40   ` Jay Denebeim
@ 2004-02-25 19:29     ` Randy.Dunlap
  2004-02-25 19:37       ` Jay Denebeim
  2004-02-25 22:40     ` Patrick Mansfield
  2004-02-26  1:28     ` Jeff Garzik
  2 siblings, 1 reply; 13+ messages in thread
From: Randy.Dunlap @ 2004-02-25 19:29 UTC (permalink / raw)
  To: Jay Denebeim; +Cc: linux-scsi

On Wed, 25 Feb 2004 11:40:27 -0700 (MST) Jay Denebeim wrote:

| On Wed, 25 Feb 2004, Matthew Wilcox wrote:
| 
| > On Wed, Feb 25, 2004 at 06:16:48PM +0000, Jay Denebeim wrote:
| (I mentioned typedefs being removed)
| > > what was the reasoning for this?
| > 
| > We hate typedefs.
| 
| Well, that's certainly convincing.  Funny that, I don't recall hating
| typedefs, in fact I distinctly recall liking them and being happy when
| they were added to Lattice's Amiga compiler back in the stone age.  Is
| there some particular reason 'we' hate them?

For anything other than very basic types, they hide/obfuscate
data structures.  If it's a struct, we had rather see a struct
used there.

--
~Randy

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 18:25 ` Matthew Wilcox
@ 2004-02-25 18:40   ` Jay Denebeim
  2004-02-25 19:29     ` Randy.Dunlap
                       ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Jay Denebeim @ 2004-02-25 18:40 UTC (permalink / raw)
  Cc: linux-scsi

On Wed, 25 Feb 2004, Matthew Wilcox wrote:

> On Wed, Feb 25, 2004 at 06:16:48PM +0000, Jay Denebeim wrote:
(I mentioned typedefs being removed)
> > what was the reasoning for this?
> 
> We hate typedefs.

Well, that's certainly convincing.  Funny that, I don't recall hating
typedefs, in fact I distinctly recall liking them and being happy when
they were added to Lattice's Amiga compiler back in the stone age.  Is
there some particular reason 'we' hate them?

Jay
-- 
* Jay Denebeim  Moderator       rec.arts.sf.tv.babylon5.moderated *
* newsgroup submission address: b5mod@deepthot.org                *
* moderator contact address:    b5mod-request@deepthot.org        *
* personal contact address:     denebeim@deepthot.org             *


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: coding style question
  2004-02-25 18:16 coding " Jay Denebeim
@ 2004-02-25 18:25 ` Matthew Wilcox
  2004-02-25 18:40   ` Jay Denebeim
  0 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2004-02-25 18:25 UTC (permalink / raw)
  To: Jay Denebeim; +Cc: linux-scsi

On Wed, Feb 25, 2004 at 06:16:48PM +0000, Jay Denebeim wrote:
> I've noticed that in 2.6 many of the constructs like:
> 
> typedef struct foo { blah }
> 
> have been changed to 
> 
> struct foo { blah }
> 
> what was the reasoning for this?

We hate typedefs.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

^ permalink raw reply	[flat|nested] 13+ messages in thread

* coding style question
@ 2004-02-25 18:16 Jay Denebeim
  2004-02-25 18:25 ` Matthew Wilcox
  0 siblings, 1 reply; 13+ messages in thread
From: Jay Denebeim @ 2004-02-25 18:16 UTC (permalink / raw)
  To: linux-scsi

I've noticed that in 2.6 many of the constructs like:

typedef struct foo { blah }

have been changed to 

struct foo { blah }

what was the reasoning for this?

Thanks
Jay
-- 
* Jay Denebeim  Moderator       rec.arts.sf.tv.babylon5.moderated *
* newsgroup submission address: b5mod@deepthot.org                *
* moderator contact address:    b5mod-request@deepthot.org        *
* personal contact address:     denebeim@deepthot.org             *

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2007-02-09 20:46 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-09 10:32 Coding style question Pavel Pisa
2007-02-09 11:18 ` Jesper Juhl
2007-02-09 16:02 ` Stefan Richter
2007-02-09 20:46 ` Haavard Skinnemoen
  -- strict thread matches above, loose matches on Subject: below --
2004-02-25 18:16 coding " Jay Denebeim
2004-02-25 18:25 ` Matthew Wilcox
2004-02-25 18:40   ` Jay Denebeim
2004-02-25 19:29     ` Randy.Dunlap
2004-02-25 19:37       ` Jay Denebeim
2004-02-26  0:02         ` Bryan Henderson
2004-02-25 22:40     ` Patrick Mansfield
2004-02-26 16:09       ` Clay Haapala
2004-02-26  1:28     ` Jeff Garzik

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.