Messages in this thread | | | Date | Wed, 2 Apr 2008 05:39:49 -0500 | From | Paul Jackson <> | Subject | Re: [PATCH 0/3] x86: add cpuset_scnprintf function |
| |
Mike wrote: > I wanted to not break current apps unmercifully, but perhaps I should > default it to the "non-compatible" mode (and adjust the schedstat version > to indicate this)? [It's the only output that I found that seemed to care.]
It doesn't matter which way you set the default. My concerns apply either way. I don't think your reply addressed my concerns.
> I know if I'm a user and I'm really interested in understanding > the outputs when there's hundreds and hundreds of cpus, then the > more compact format is much more useful.
That's not sufficient reason to change an API visible across the kernel-user boundary.
> Plus I was under the impression that one of the basic tenets of Linux > was that API's can and will change?
Kernel internals have a relatively lower barrier to API changes.
Kernel API's visible to kernel drivers or loadable modules have a higher barrier to change.
Kernel API's visible to user space, such as this one, have a much higher barrier to incompatible change.
I hesitate to NAQ patches because I strike out more often than someone like Al Viro. But I'm getting tempted on this one.
Perhaps you could write yourself a user utility that scanned its input for masks in legacy format, converted them to list format, and passed all else unscathed?
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |