8000 uname processor and hwplatform · Issue #2041 · uutils/coreutils · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

uname processor and hwplatform #2041

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dm9pZCAq opened this issue Apr 6, 2021 · 7 comments · Fixed by #3537
Closed

uname processor and hwplatform #2041

dm9pZCAq opened this issue Apr 6, 2021 · 7 comments · Fixed by #3537

Comments

@dm9pZCAq
Copy link
dm9pZCAq commented Apr 6, 2021 •
edited
Loading

for me GNU uname return correct processor and hwplatform in 3 of 5 x86_64 machines

coreutils/src/uu/uname/src/uname.rs

Lines 139 to 150 in 20d071a

if processor || all {
// According to https://stackoverflow.com/posts/394271/revisions
// Most of the time, it returns unknown
output.push_str("unknown");
output.push(' ');
}
if hwplatform || all {
// According to https://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html
// Most of the time, it returns unknown
output.push_str("unknown");
output.push(' ');
}

also here is code from GNU uname, it's actually do something to determine this info and not just print "unknown":
@LevitatingBusinessMan
Copy link
Contributor
LevitatingBusinessMan commented Apr 6, 2021 •
edited
Loading

We'd have to think about how we should retrieve this information per platform.
For Linux systems we can use sysinfo from libc.
MacOS has a library sysctl.
I am not sure what to use on windows.

Anyway on my machine uname has no clue about any of those.

@dm9pZCAq
Copy link
Author
dm9pZCAq commented Apr 6, 2021

I am not sure what to use on windows.

maybe this can help

@stale
Copy link
stale bot commented Apr 6, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Apr 6, 2022
@tertsdiepraam
Copy link
Member

Still an issue. It'd be cool if we could do better than GNU in this area. Maybe to unblock this a bit, we could implement this for Linux first and think about other platforms later?

@stale stale bot removed the wontfix label Apr 7, 2022
@LevitatingBusinessMan
Copy link
Contributor

@tertsdiepraam I'd care to work on this. Gotta have to find some free time first though. Maybe sometime later in this month.

@dm9pZCAq
Copy link
Author
dm9pZCAq commented Apr 8, 2022

in linux you can get it from parsing /proc/cpuinfo

here is how i do this

@LevitatingBusinessMan
Copy link
Contributor
LevitatingBusinessMan commented May 17, 2022 •
edited
Loading

This might be a bit harder than I thought. So I wasn't able to find any x86_64 machine of my own that had results for "processor" or "hwplatform". I had a few friends test their results for me, but it doesn't help that MacOS uses a different uname.

n/a means the version of uname used didn't support that flag.

My ryzen 3

machine: x86_64
processor: unknown
hwplatform: unknown

M1 Macbook

machine: arm64
processor: arm
hwplatform: n/a

Android

machine: aarch64
processor: unknown
hwplatform: unknown

A different Android

machine: armv8l
processor: n/a
hwplatform: n/a

Intel Macbook I think

machine: x86_64
processor: i386
hwplatform: n/a

So first we have to figure out what we want these flags to even do exactly.

What does GNU do?

processor (-p)

Before this commit GNU relied on a sysinfo found in <sys/systeminfo.h> (if it existed). I couldn't find much out about this, I am assuming it's extremely deprecated? GNU uses it to fetch the SI_ARCHITECTURE variable.

Then it tries using sysctl, which has been deprecated since Linux 2.6.24 and was removed in Linux 5.5. GNU tries to fetch UNAME_PROCESSOR here.

So no wonder that it doesn't work on anything I tested it on.

Man pages tell us to use /proc/sys instead.

hardware (-p)

Exact same stuff. But it fetches SI_PLATFORM or UNAME_HARDWARE_PLATFORM.

So we're sailing uncharted waters here. Cool.

I think we should maybe consider dropping these flags. They don't currently do anything in uname on modern systems, and I don't see their significance either. And all of the other settings just pull info from <sys/utsname.h> (where you'd expect them to come from).

Edit: When it comes to MacOS, GNU just fetches hw.cputype via sysctlbyname for the processor flag. It does nothing for the hwplatform flag. Not sure if the syscall is still in use, but if the same syscall is used in the implementation of uname as seen in my testing from before its results are not really impressive.

Edit 2: This thread sylvestre linked in the source code is also interesting:

https://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00053.html

The discussion here mostly consists of "should these options produce an error or keep producing 'unknown'". Apparently Debian already uses a patch to remove these options entirely. The discussion resulted in a commit being made where the output of these options is not shown when it is unknown, which is where we are know.

In our case I think it's best to hide them from the help page, but still have them function. I will make a PR with this change and also prevent "unknown" from being printed in the total overview like GNU.

Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

uname: hide processor and hwplatform options LevitatingBusinessMan/coreutils
3 participants
@tertsdiepraam @LevitatingBusinessMan @dm9pZCAq
0