Andrew,
Here's cpuflags v2 (x86 version) :
[/proc/cpuflags snippet]
no sse2
no ss
no ht
no tm
no ia64
no pbe
yes syscall
yes mp
no nx
yes mmxext
no lm
yes 3dnowext
Regards,
FabF
On Mon, Jun 28, 2004 at 11:55:06AM +0200, FabF wrote:
> Andrew,
>
> Here's cpuflags v2 (x86 version) :
>
> [/proc/cpuflags snippet]
> no sse2
> no ss
> no ht
> no tm
> no ia64
> no pbe
> yes syscall
> yes mp
> no nx
> yes mmxext
> no lm
> yes 3dnowext
This can be done just as easily (if not easier) in userspace.
I see no value in adding a duplicate flag mechanism to the kernel.
Dave
On Tue, Jun 29, 2004 at 10:42:04AM +0200, [email protected] 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