H.Seto wrote:I too don't have a strong preference either way ... just a bias toward keeping the exposed per-cpuset flags as simple and generic as practical. Exposing internal details that don't need to be exposed has two downsides: 1) it makes using the flags slightly more difficult, as the user has to figure out more details, and 2) it exposes some internal details that we didn't need to expose, thereby possibly making future changes more difficult. We can change internal hidden detail anytime we want, but exposed interfaces are locked in with a high barrier to incompatible change. I too would welcome comments from others. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| H. Peter Anvin | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Christoph Lameter | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Christoph Hellwig | Re: [PATCH 06/32] IGET: Mark iget() and read_inode() as being obsolete [try #2] |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
