Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:
+   /* add additional MPOL_* modes here */

That doesn't explicitly say what I was most worried about saying, which
is that those MPOL_* terms have values visible in the kernel's public
API, and it does say more than might be true, and it doesn't explain
why it says what it says.

It kinda looks like an ugly "maybe this will shut Paul up patch
".  I'd rather leave the code the way it was than add that
comment ... sorry.

>  I'd like to avoid respinning this set

Ah - now we get to the real issue ?;).

There would be no need to respin; one could do just as you proposed
doing with the above change, queue a little add-on patch to the
existing set.

Really ... look around the kernel.  I believe you'll see many instances
of enum values being spelled out, even ones that count 0, 1, 2, ...,
in situations where the values are constrained by outside forces.
People really do avoid relying on the default enum behaviour having any
particular numbering.

Whatever ... do as you will.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
On Mon, 25 Feb 2008, Paul Jackson wrote:

> Eh ... each bit of added clarity to the code reduces
> errors.
> 
> Looking around the kernel, it really seems to me to be
> a common coding to explicitly spell out enum values
> when for some reason they actually matter.
> 
> Like most coding mechanisms, nothing guarantees anything.
> 
> It just nicely represents one particular detail, that
> the values of these MPOL_* terms are not arbitrary.
> 

Of course the MPOL_* modes aren't arbitrary; they are defined in an enum 
that has a well-defined and explicit behavior for how they are mapped to 
int values based on a standard.

I have more mempolicy patches that add additional behavior and cleanups so 
I can queue the following for a later posting.  I'd like to avoid 
respinning this set unless there are actual design or implementation 
concerns that are raised. 
---
 include/linux/mempolicy.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -20,7 +20,9 @@ enum {
MPOL_PREFERRED,
MPOL_BIND,
MPOL_INTERLEAVE,
-   MPOL_MAX,   /* always last member of enum */
+   /* add additional MPOL_* modes here */
+
+   MPOL_MAX,
 };
 
 /* Flags for set_mempolicy */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:
> I don't suspect that a kernel developer is going
> to make such an egregious error.

Eh ... each bit of added clarity to the code reduces
errors.

Looking around the kernel, it really seems to me to be
a common coding to explicitly spell out enum values
when for some reason they actually matter.

Like most coding mechanisms, nothing guarantees anything.

It just nicely represents one particular detail, that
the values of these MPOL_* terms are not arbitrary.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
On Mon, 25 Feb 2008, Paul Jackson wrote:

> +enum {
> + MPOL_DEFAULT,
> + MPOL_PREFERRED,
> + MPOL_BIND,
> + MPOL_INTERLEAVE,
> + MPOL_MAX,   /* always last member of enum */
> 
> Aren't the values that these constants take part of the
> user visible kernel API?
> 
> In other words, if someone added another MPOL_* in the middle
> of this enum, it would break mbind/set_mempolicy/get_mempolicy
> users, right:
> 
> +enum {
> + MPOL_DEFAULT,
> + MPOL_PREFERRED,
> + MPOL_YET_ANOTHER_FLAG,  /* <== added flag ... oops */
> + MPOL_BIND,
> + MPOL_INTERLEAVE,
> + MPOL_MAX,   /* always last member of enum */
> 

I don't suspect that a kernel developer is going to make such an egregious 
error.  The user would need to be using a new linux/mempolicy.h with an 
old kernel to get the wrong behavior.

> I'm thinking that we should still specify the specific value
> of each of these flags, by way of documenting these necessary
> values, as in:
> 
> +enum {
> + MPOL_DEFAULT = 0,
> + MPOL_PREFERRED = 1,
> + MPOL_BIND = 2,
> + MPOL_INTERLEAVE = 3,
> + MPOL_MAX,   /* always last member of enum */
> 

That looks overly redundant to me and doesn't protect against adding 
MPOL_YET_ANOTHER_FLAG in the middle of preferred and bind to get two mode 
values with the int value of 1.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:

+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */

Aren't the values that these constants take part of the
user visible kernel API?

In other words, if someone added another MPOL_* in the middle
of this enum, it would break mbind/set_mempolicy/get_mempolicy
users, right:

+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_YET_ANOTHER_FLAG,  /* <== added flag ... oops */
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */

I'm thinking that we should still specify the specific value
of each of these flags, by way of documenting these necessary
values, as in:

+enum {
+   MPOL_DEFAULT = 0,
+   MPOL_PREFERRED = 1,
+   MPOL_BIND = 2,
+   MPOL_INTERLEAVE = 3,
+   MPOL_MAX,   /* always last member of enum */


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum since they
are sequentially numbered and cannot be combined.

The policy member of struct mempolicy is also converted from type short
to type unsigned short.  A negative policy does not have any legitimate
meaning, so it is possible to change its type in preparation for adding
optional mode flags later.

The equivalent member of struct shmem_sb_info is also changed from int
to unsigned short.

For compatibility, the policy formal to get_mempolicy() remains as a
pointer to an int:

int get_mempolicy(int *policy, unsigned long *nmask,
  unsigned long maxnode, unsigned long addr,
  unsigned long flags);

although the only possible values is the range of type unsigned short.

Cc: Paul Jackson <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Lee Schermerhorn <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
 include/linux/mempolicy.h |   19 ++-
 include/linux/shmem_fs.h  |2 +-
 mm/mempolicy.c|   27 ---
 mm/shmem.c|9 +
 4 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -9,12 +9,13 @@
  */
 
 /* Policies */
-#define MPOL_DEFAULT   0
-#define MPOL_PREFERRED 1
-#define MPOL_BIND  2
-#define MPOL_INTERLEAVE3
-
-#define MPOL_MAX MPOL_INTERLEAVE
+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */
+};
 
 /* Flags for get_mem_policy */
 #define MPOL_F_NODE(1<<0)  /* return next IL mode instead of node mask */
@@ -62,7 +63,7 @@ struct mm_struct;
  */
 struct mempolicy {
atomic_t refcnt;
-   short policy;   /* See MPOL_* above */
+   unsigned short policy;  /* See MPOL_* above */
union {
struct zonelist  *zonelist; /* bind */
shortpreferred_node; /* preferred */
@@ -133,7 +134,7 @@ struct shared_policy {
spinlock_t lock;
 };
 
-void mpol_shared_policy_init(struct shared_policy *info, int policy,
+void mpol_shared_policy_init(struct shared_policy *info, unsigned short policy,
nodemask_t *nodes);
 int mpol_set_shared_policy(struct shared_policy *info,
struct vm_area_struct *vma,
@@ -200,7 +201,7 @@ static inline int mpol_set_shared_policy(struct 
shared_policy *info,
 }
 
 static inline void mpol_shared_policy_init(struct shared_policy *info,
-   int policy, nodemask_t *nodes)
+   unsigned short policy, nodemask_t *nodes)
 {
 }
 
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -34,7 +34,7 @@ struct shmem_sb_info {
uid_t uid;  /* Mount uid for root directory */
gid_t gid;  /* Mount gid for root directory */
mode_t mode;/* Mount mode for root directory */
-   int policy; /* Default NUMA memory alloc policy */
+   unsigned short policy;  /* Default NUMA memory alloc policy */
nodemask_t policy_nodes;/* nodemask for preferred and bind */
 };
 
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -114,7 +114,7 @@ static void mpol_rebind_policy(struct mempolicy *pol,
const nodemask_t *newmask);
 
 /* Do sanity checking on a policy */
-static int mpol_check_policy(int mode, nodemask_t *nodes)
+static int mpol_check_policy(unsigned short mode, nodemask_t *nodes)
 {
int was_empty, is_empty;
 
@@ -159,6 +159,8 @@ static int mpol_check_policy(int mode, nodemask_t *nodes)
if (!was_empty && is_empty)
return -EINVAL;
break;
+   default:
+   BUG();
}
return 0;
 }
@@ -201,7 +203,7 @@ static struct zonelist *bind_zonelist(nodemask_t *nodes)
 }
 
 /* Create a new policy */
-static struct mempolicy *mpol_new(int mode, nodemask_t *nodes)
+static struct mempolicy *mpol_new(unsigned short mode, nodemask_t *nodes)
 {
struct mempolicy *policy;
 
@@ -235,6 +237,8 @@ static struct mempolicy *mpol_new(int mode, nodemask_t 
*nodes)
return error_code;
}
break;
+   default:
+   BUG();
}
policy->policy = mode;
policy->cpuset_mems_allowed = cpuset_mems_allowed(current);
@@ -479,7 +483,7 @@ static void mpol_set_task_struct_flag(void)
 }
 
 /* Set the process memory policy */
-static long

[patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum since they
are sequentially numbered and cannot be combined.

The policy member of struct mempolicy is also converted from type short
to type unsigned short.  A negative policy does not have any legitimate
meaning, so it is possible to change its type in preparation for adding
optional mode flags later.

The equivalent member of struct shmem_sb_info is also changed from int
to unsigned short.

For compatibility, the policy formal to get_mempolicy() remains as a
pointer to an int:

int get_mempolicy(int *policy, unsigned long *nmask,
  unsigned long maxnode, unsigned long addr,
  unsigned long flags);

although the only possible values is the range of type unsigned short.

Cc: Paul Jackson [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Cc: Lee Schermerhorn [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
 include/linux/mempolicy.h |   19 ++-
 include/linux/shmem_fs.h  |2 +-
 mm/mempolicy.c|   27 ---
 mm/shmem.c|9 +
 4 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -9,12 +9,13 @@
  */
 
 /* Policies */
-#define MPOL_DEFAULT   0
-#define MPOL_PREFERRED 1
-#define MPOL_BIND  2
-#define MPOL_INTERLEAVE3
-
-#define MPOL_MAX MPOL_INTERLEAVE
+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */
+};
 
 /* Flags for get_mem_policy */
 #define MPOL_F_NODE(10)  /* return next IL mode instead of node mask */
@@ -62,7 +63,7 @@ struct mm_struct;
  */
 struct mempolicy {
atomic_t refcnt;
-   short policy;   /* See MPOL_* above */
+   unsigned short policy;  /* See MPOL_* above */
union {
struct zonelist  *zonelist; /* bind */
shortpreferred_node; /* preferred */
@@ -133,7 +134,7 @@ struct shared_policy {
spinlock_t lock;
 };
 
-void mpol_shared_policy_init(struct shared_policy *info, int policy,
+void mpol_shared_policy_init(struct shared_policy *info, unsigned short policy,
nodemask_t *nodes);
 int mpol_set_shared_policy(struct shared_policy *info,
struct vm_area_struct *vma,
@@ -200,7 +201,7 @@ static inline int mpol_set_shared_policy(struct 
shared_policy *info,
 }
 
 static inline void mpol_shared_policy_init(struct shared_policy *info,
-   int policy, nodemask_t *nodes)
+   unsigned short policy, nodemask_t *nodes)
 {
 }
 
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -34,7 +34,7 @@ struct shmem_sb_info {
uid_t uid;  /* Mount uid for root directory */
gid_t gid;  /* Mount gid for root directory */
mode_t mode;/* Mount mode for root directory */
-   int policy; /* Default NUMA memory alloc policy */
+   unsigned short policy;  /* Default NUMA memory alloc policy */
nodemask_t policy_nodes;/* nodemask for preferred and bind */
 };
 
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -114,7 +114,7 @@ static void mpol_rebind_policy(struct mempolicy *pol,
const nodemask_t *newmask);
 
 /* Do sanity checking on a policy */
-static int mpol_check_policy(int mode, nodemask_t *nodes)
+static int mpol_check_policy(unsigned short mode, nodemask_t *nodes)
 {
int was_empty, is_empty;
 
@@ -159,6 +159,8 @@ static int mpol_check_policy(int mode, nodemask_t *nodes)
if (!was_empty  is_empty)
return -EINVAL;
break;
+   default:
+   BUG();
}
return 0;
 }
@@ -201,7 +203,7 @@ static struct zonelist *bind_zonelist(nodemask_t *nodes)
 }
 
 /* Create a new policy */
-static struct mempolicy *mpol_new(int mode, nodemask_t *nodes)
+static struct mempolicy *mpol_new(unsigned short mode, nodemask_t *nodes)
 {
struct mempolicy *policy;
 
@@ -235,6 +237,8 @@ static struct mempolicy *mpol_new(int mode, nodemask_t 
*nodes)
return error_code;
}
break;
+   default:
+   BUG();
}
policy-policy = mode;
policy-cpuset_mems_allowed = cpuset_mems_allowed(current);
@@ -479,7 +483,7 @@ static void mpol_set_task_struct_flag(void)
 }
 
 /* Set the process memory policy */
-static long do_set_mempolicy(int mode,

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:

+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */

Aren't the values that these constants take part of the
user visible kernel API?

In other words, if someone added another MPOL_* in the middle
of this enum, it would break mbind/set_mempolicy/get_mempolicy
users, right:

+enum {
+   MPOL_DEFAULT,
+   MPOL_PREFERRED,
+   MPOL_YET_ANOTHER_FLAG,  /* == added flag ... oops */
+   MPOL_BIND,
+   MPOL_INTERLEAVE,
+   MPOL_MAX,   /* always last member of enum */

I'm thinking that we should still specify the specific value
of each of these flags, by way of documenting these necessary
values, as in:

+enum {
+   MPOL_DEFAULT = 0,
+   MPOL_PREFERRED = 1,
+   MPOL_BIND = 2,
+   MPOL_INTERLEAVE = 3,
+   MPOL_MAX,   /* always last member of enum */


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.940.382.4214
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
On Mon, 25 Feb 2008, Paul Jackson wrote:

 +enum {
 + MPOL_DEFAULT,
 + MPOL_PREFERRED,
 + MPOL_BIND,
 + MPOL_INTERLEAVE,
 + MPOL_MAX,   /* always last member of enum */
 
 Aren't the values that these constants take part of the
 user visible kernel API?
 
 In other words, if someone added another MPOL_* in the middle
 of this enum, it would break mbind/set_mempolicy/get_mempolicy
 users, right:
 
 +enum {
 + MPOL_DEFAULT,
 + MPOL_PREFERRED,
 + MPOL_YET_ANOTHER_FLAG,  /* == added flag ... oops */
 + MPOL_BIND,
 + MPOL_INTERLEAVE,
 + MPOL_MAX,   /* always last member of enum */
 

I don't suspect that a kernel developer is going to make such an egregious 
error.  The user would need to be using a new linux/mempolicy.h with an 
old kernel to get the wrong behavior.

 I'm thinking that we should still specify the specific value
 of each of these flags, by way of documenting these necessary
 values, as in:
 
 +enum {
 + MPOL_DEFAULT = 0,
 + MPOL_PREFERRED = 1,
 + MPOL_BIND = 2,
 + MPOL_INTERLEAVE = 3,
 + MPOL_MAX,   /* always last member of enum */
 

That looks overly redundant to me and doesn't protect against adding 
MPOL_YET_ANOTHER_FLAG in the middle of preferred and bind to get two mode 
values with the int value of 1.

David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:
 I don't suspect that a kernel developer is going
 to make such an egregious error.

Eh ... each bit of added clarity to the code reduces
errors.

Looking around the kernel, it really seems to me to be
a common coding to explicitly spell out enum values
when for some reason they actually matter.

Like most coding mechanisms, nothing guarantees anything.

It just nicely represents one particular detail, that
the values of these MPOL_* terms are not arbitrary.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.940.382.4214
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread David Rientjes 
On Mon, 25 Feb 2008, Paul Jackson wrote:

 Eh ... each bit of added clarity to the code reduces
 errors.
 
 Looking around the kernel, it really seems to me to be
 a common coding to explicitly spell out enum values
 when for some reason they actually matter.
 
 Like most coding mechanisms, nothing guarantees anything.
 
 It just nicely represents one particular detail, that
 the values of these MPOL_* terms are not arbitrary.
 

Of course the MPOL_* modes aren't arbitrary; they are defined in an enum 
that has a well-defined and explicit behavior for how they are mapped to 
int values based on a standard.

I have more mempolicy patches that add additional behavior and cleanups so 
I can queue the following for a later posting.  I'd like to avoid 
respinning this set unless there are actual design or implementation 
concerns that are raised. 
---
 include/linux/mempolicy.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -20,7 +20,9 @@ enum {
MPOL_PREFERRED,
MPOL_BIND,
MPOL_INTERLEAVE,
-   MPOL_MAX,   /* always last member of enum */
+   /* add additional MPOL_* modes here */
+
+   MPOL_MAX,
 };
 
 /* Flags for set_mempolicy */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/6] mempolicy: convert MPOL constants to enum

2008-02-25 Thread Paul Jackson 
David wrote:
+   /* add additional MPOL_* modes here */

That doesn't explicitly say what I was most worried about saying, which
is that those MPOL_* terms have values visible in the kernel's public
API, and it does say more than might be true, and it doesn't explain
why it says what it says.

It kinda looks like an ugly maybe this will shut Paul up patch
grin.  I'd rather leave the code the way it was than add that
comment ... sorry.

  I'd like to avoid respinning this set

Ah - now we get to the real issue ?;).

There would be no need to respin; one could do just as you proposed
doing with the above change, queue a little add-on patch to the
existing set.

Really ... look around the kernel.  I believe you'll see many instances
of enum values being spelled out, even ones that count 0, 1, 2, ...,
in situations where the values are constrained by outside forces.
People really do avoid relying on the default enum behaviour having any
particular numbering.

Whatever ... do as you will.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.940.382.4214
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/