Re: [PATCH 2.6.7-mm3] cpuflags reviewed

[Dave Jones]

On Tue, Jun 29, 2004 at 10:42:04AM +0200, fabian.frederick@xxxxxxxxx wrote:

 > I made this one in order to display flags in a clear way (ie better than
 > cpuinfo) and display \"what we have and what we don't\"
 > related to my arch. Kernel is authoritative there and gathers all
 > info.

How is this more authorative than a userspace app ?
If a new feature flag appears that the kernel doesn't know about,
it won't get picked up. Just as it won't in a userspace app.
The difference being, someone can grab the latest version of the
app without needing to update their whole kernel.

 > Having userland maintaining such stuff would be double-work
 > double-effort (ok, it's usual :) ).Let's say procps maintains flagging as
 > well, it would require all arch updates.

Updating userspace is less impact than kernel updates.

 > All this without the fact that kernel would be able to deliver such info
 > through a syscall or something I'm not aware of...

That would be even more overkill.  The cpuid driver does everything
you need, in userspace.  It has established userspace users.
Do you expect those users to switch over to /proc/cpuflags ?
It won't happen, and adding duplicate interfaces is just pointless.

 > IOW, userland requires more feed.Feed userland pls :))))

No, it does not.  All you patch brings afaics is the need to parse
ASCII (/proc/cpuflags) vs binary (/dev/cpu/n/cpuid), and we
already have a /proc/cpuinfo for that.

		Dave

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