David wrote:
> That doesn't logically follow because the aggregate of the mode and the
> optional flags _are_ the policy itself.
I give up ... I still don't agree, but that's ok.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
On Tue, 12 Feb 2008, Paul Jackson wrote:
> ==> If each time I look at some 'flags' field, I have to think of it
> as a couple of things glued together that I will have to pick apart to
> use, that's more mental work than seeing those two things explicit and
> separate, through most of the
> I do not subscribe to the theory that just because we have a couple extra
> bytes of space somewhere in struct mempolicy that we have to use it
> immediately.
Good grief ... I'm not lobbying for separate flag fields because the
space is there. I was just dealing with one possible obection,
On Tue, 12 Feb 2008, Paul Jackson wrote:
> However, once inside the kernel, how we store this flag in struct mempolicy,
> and how we pass it about between kernel routines, is our choice.
>
> We can leave it packed, and unpack and repack it each time we consider the
> flag and mode bits, or we
David wrote:
> The enum has already been removed, as I've said a few times.
Yup. Sorry ... beating dead horses is too much fun.
> The 'flags' field would be wrong because you're ignoring that these flags
> are both passed by the user to the kernel and by the kernel to the user as
> part of
On Tue, 12 Feb 2008, Paul Jackson wrote:
> Christoph wrote:
> > Good. And remove the enum.
> >
> > It would be better to add some sort of flags field?
>
> On the other hand, despite my brilliant (hah!) endorsement
> of bit field flags in my reply a few minutes ago, I'd settle
> for (1) removing
Christoph wrote:
> Good. And remove the enum.
>
> It would be better to add some sort of flags field?
On the other hand, despite my brilliant (hah!) endorsement
of bit field flags in my reply a few minutes ago, I'd settle
for (1) removing the enum, and (2) using a flags field and
more defines
Christoph wrote:
> We usually do that with unsigned XXX and constants. You may want to check
> multiple flags at once or do other fancy things.
Both are common in the kernel. I see 241 ":1" bit fields in include/linux/*.h.
One can do Boolean expressions with either form, bitfields or defines.
On Tue, 12 Feb 2008, Paul Jackson wrote:
> I'm inclined toward the original types for the 'policy' field.
Good. And remove the enum.
> Specifically, I'd suggest adding the one line for 'mode_f_static_nodes'
> as below, and leaving the code involving the encoding of the policy
> field alone.
>
On Tue, 12 Feb 2008, Paul Jackson wrote:
> I tend to agree with Lee on this one. If I recall correctly, Christoph
> said something similar, regarding the change of the 'policy' field
> of struct mempolicy from a short to an enum.
>
I've already made the change in my patchset as a result of
Lee wrote:
> Why not leave it as an int. Will simplify this and subsequent patch.
I tend to agree with Lee on this one. If I recall correctly, Christoph
said something similar, regarding the change of the 'policy' field
of struct mempolicy from a short to an enum.
I'm inclined toward the
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
> The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
> and MPOL_INTERLEAVE, are better declared as part of an enum for type
> checking.
>
> The policy member of struct mempolicy is also converted from type short
> to
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
The policy member of struct mempolicy is also converted from type short
to type
David wrote:
That doesn't logically follow because the aggregate of the mode and the
optional flags _are_ the policy itself.
I give up ... I still don't agree, but that's ok.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
On Tue, 12 Feb 2008, Paul Jackson wrote:
== If each time I look at some 'flags' field, I have to think of it
as a couple of things glued together that I will have to pick apart to
use, that's more mental work than seeing those two things explicit and
separate, through most of the mempolicy.c
I do not subscribe to the theory that just because we have a couple extra
bytes of space somewhere in struct mempolicy that we have to use it
immediately.
Good grief ... I'm not lobbying for separate flag fields because the
space is there. I was just dealing with one possible obection, by
On Tue, 12 Feb 2008, Paul Jackson wrote:
However, once inside the kernel, how we store this flag in struct mempolicy,
and how we pass it about between kernel routines, is our choice.
We can leave it packed, and unpack and repack it each time we consider the
flag and mode bits, or we can
Christoph wrote:
Good. And remove the enum.
It would be better to add some sort of flags field?
On the other hand, despite my brilliant (hah!) endorsement
of bit field flags in my reply a few minutes ago, I'd settle
for (1) removing the enum, and (2) using a flags field and
more defines for
Christoph wrote:
We usually do that with unsigned XXX and constants. You may want to check
multiple flags at once or do other fancy things.
Both are common in the kernel. I see 241 :1 bit fields in include/linux/*.h.
One can do Boolean expressions with either form, bitfields or defines.
For
David wrote:
The enum has already been removed, as I've said a few times.
Yup. Sorry ... beating dead horses is too much fun.
The 'flags' field would be wrong because you're ignoring that these flags
are both passed by the user to the kernel and by the kernel to the user as
part of the
On Tue, 12 Feb 2008, Paul Jackson wrote:
I tend to agree with Lee on this one. If I recall correctly, Christoph
said something similar, regarding the change of the 'policy' field
of struct mempolicy from a short to an enum.
I've already made the change in my patchset as a result of
Lee wrote:
Why not leave it as an int. Will simplify this and subsequent patch.
I tend to agree with Lee on this one. If I recall correctly, Christoph
said something similar, regarding the change of the 'policy' field
of struct mempolicy from a short to an enum.
I'm inclined toward the
On Tue, 12 Feb 2008, Paul Jackson wrote:
I'm inclined toward the original types for the 'policy' field.
Good. And remove the enum.
Specifically, I'd suggest adding the one line for 'mode_f_static_nodes'
as below, and leaving the code involving the encoding of the policy
field alone.
On Tue, 12 Feb 2008, Paul Jackson wrote:
Christoph wrote:
Good. And remove the enum.
It would be better to add some sort of flags field?
On the other hand, despite my brilliant (hah!) endorsement
of bit field flags in my reply a few minutes ago, I'd settle
for (1) removing the enum,
On Mon, 11 Feb 2008, David Rientjes wrote:
> On Mon, 11 Feb 2008, Christoph Lameter wrote:
>
> > Then you could follow through with the enum mempolicy thing
> > throughtout. Why not use enum mempolicy in struct mempolicy?
> >
>
> Mempolicy flags, as I implemented them in patch 2 in this
On Mon, 11 Feb 2008, Christoph Lameter wrote:
> Then you could follow through with the enum mempolicy thing
> throughtout. Why not use enum mempolicy in struct mempolicy?
>
Mempolicy flags, as I implemented them in patch 2 in this series, are not
integer constants that are enumerated starting
On Mon, 11 Feb 2008, David Rientjes wrote:
> > The second paragraphs seems to indicate that such an approach does not
> > work since we also use MPOL_xx constants to set flags in the memory
> > policies?
> >
>
> Not sure I'm understanding your question, sorry.
>
> Mempolicy modes have always
On Mon, 11 Feb 2008, Christoph Lameter wrote:
> > 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
On Mon, 11 Feb 2008, David Rientjes wrote:
> The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
> and MPOL_INTERLEAVE, are better declared as part of an enum for type
> checking.
>
> The policy member of struct mempolicy is also converted from type short
> to type unsigned
On Mon, 11 Feb 2008, Andi Kleen wrote:
> > The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
> > and MPOL_INTERLEAVE, are better declared as part of an enum for type
> > checking.
>
> What type checking? There is none in standard C for enums.
>
"Type checking" probably
On Monday 11 February 2008 16:30:32 David Rientjes wrote:
> The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
> and MPOL_INTERLEAVE, are better declared as part of an enum for type
> checking.
What type checking? There is none in standard C for enums.
-Andi
--
To unsubscribe
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
The policy member of struct mempolicy is also converted from type short
to type unsigned short. A negative policy does not have any legitimate
On Mon, 11 Feb 2008, David Rientjes wrote:
On Mon, 11 Feb 2008, Christoph Lameter wrote:
Then you could follow through with the enum mempolicy thing
throughtout. Why not use enum mempolicy in struct mempolicy?
Mempolicy flags, as I implemented them in patch 2 in this series, are not
On Mon, 11 Feb 2008, Christoph Lameter wrote:
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.
On Mon, 11 Feb 2008, Andi Kleen wrote:
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
What type checking? There is none in standard C for enums.
Type checking probably isn't the best
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
The policy member of struct mempolicy is also converted from type short
to type unsigned short. A negative policy does not have any legitimate
On Mon, 11 Feb 2008, David Rientjes wrote:
The second paragraphs seems to indicate that such an approach does not
work since we also use MPOL_xx constants to set flags in the memory
policies?
Not sure I'm understanding your question, sorry.
Mempolicy modes have always been int
On Monday 11 February 2008 16:30:32 David Rientjes wrote:
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
What type checking? There is none in standard C for enums.
-Andi
--
To unsubscribe
On Mon, 11 Feb 2008, David Rientjes wrote:
The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND,
and MPOL_INTERLEAVE, are better declared as part of an enum for type
checking.
The policy member of struct mempolicy is also converted from type short
to type unsigned short.
On Mon, 11 Feb 2008, Christoph Lameter wrote:
Then you could follow through with the enum mempolicy thing
throughtout. Why not use enum mempolicy in struct mempolicy?
Mempolicy flags, as I implemented them in patch 2 in this series, are not
integer constants that are enumerated starting at
40 matches
Mail list logo
