linux-kernel - Re: [patch 1/4] mempolicy: convert MPOL constants to enum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080212205944.86ab2dc7.pj@sgi.com>
Date:	Tue, 12 Feb 2008 20:59:44 -0600
From:	Paul Jackson <pj@....com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	clameter@....com, Lee.Schermerhorn@...com,
	akpm@...ux-foundation.org, ak@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/4] mempolicy: convert MPOL constants to enum

> 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
noting that it wouldn't cost us in terms of struct mempolicy size.

> It makes the kernel code simpler, in a way.
> 
> Now we only have to pass a single actual among functions that include both 
> the mode and optional flags (there are a lot of them and they span not 
> only the VM but also filesystem code).

This gets closer to the key issue.

We both agree we want "simpler", but disagree on what that means.

We don't measure complexity -solely- by counting the size of parameter lists.
If we did that, we'd be packing all manner of sub-integer fields into single
'int' parameters.

I tend to measure complexity a level up from the bits and bytes,
and more in terms of how I think about things.  If I think of a routine
as taking two values, such as in this case an mempolicy mode (such as
MPOL_BIND or MPOL_INTERLEAVE) and this new flag (MPOL_F_STATIC_NODES),
which have a different sort of affect.

==> 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 code <==

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