Coding style question

Coding style question

[Pavel Pisa]

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

Re: Coding style question

[Jesper Juhl]

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

Re: Coding style question

[Stefan Richter]

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/

Re: Coding style question

[Haavard Skinnemoen]

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

coding style question

[Jay Denebeim]

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             *

Re: coding style question

[Matthew Wilcox]

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

Re: coding style question

[Jay Denebeim]

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             *

Re: coding style question

[Randy.Dunlap]

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

Re: coding style question

[Jay Denebeim]

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             *

Re: coding style question

[Bryan Henderson]

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

Re: coding style question

[Patrick Mansfield]

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

Re: coding style question

[Clay Haapala]

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

Re: coding style question

[Jeff Garzik]

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