mboost-dp1
uname -s -o
Kan det passe at uname henter nogle af sine informationer fra glibc?
Jeg oplever det "morsomme" at -s siger pyro, men -o siger Syllable.
Og når jeg spørger efter om den henter det fra glibc, så er det fordi det er det eneste der pt. er genbrugt. Kernen er rettet, så den afgiver de korrekte informationer.
Jeg oplever det "morsomme" at -s siger pyro, men -o siger Syllable.
Og når jeg spørger efter om den henter det fra glibc, så er det fordi det er det eneste der pt. er genbrugt. Kernen er rettet, så den afgiver de korrekte informationer.
På de Linux systemer jeg har adgang til kommer outputtet af -s fra kernen gennem et uname() systemkald. Til gengæld kommer outputtet af -o fra uname programfilen.
De to værdier er hhv. Linux og GNU/Linux uanset hvilket Linux system jeg kører dem på. Det ser ikke ud til at glibc har noget at sige.
De to værdier er hhv. Linux og GNU/Linux uanset hvilket Linux system jeg kører dem på. Det ser ikke ud til at glibc har noget at sige.
Jo, men han siger at -s kommer fra kernen, og det er den der siger Pyro. Det er -o der siger Syllable, og den siger han kommer fra uname programfilen.
Ellers ikke nogen dårlig ide til hvad der kunne være sket, for der er en del af de små mærkelige hacks rundt omring...
Ellers ikke nogen dårlig ide til hvad der kunne være sket, for der er en del af de små mærkelige hacks rundt omring...
Jeg ville ikke engang kalde det for et hack. Hvis man kigger på en standard som f.eks. Posix, så udtaler den sig om interfacet mellem C librariet (i dette tilfælde glibc) og opad. Det er sådanset ligegyldigt hvad APIen mellem glibc og kernen gør, så længe det er muligt for glibc at opnå den rigtige API opad.arne_v (4) skrev:Syllable/Pyro er vel ikke Unix/Linux, så hvis nu f.eks. uname manglede i kernen i started, så blev der måske lavet et lille hack i glibc.
Hvis du compilerer et C library så det kun kan køre på et specifikt OS, så er det også helt fint at det på compileringstidspunktet bliver hardcodet i librariet hvad uname skal returnere som output fra -s. Der er ingen garanti for at det fungerer på samme måde på Linux og Syllable, men der intet i tråden, som giver mig anledning til at tro der er forskel. Og på Linux returnerer uname systemkaldet oplysningerne således at et operativsystem som har en Linux kompatibilitetsmodus kan returnere et andet kernenavn til programmer, som er compileret til Linux.
Hvis strace eller noget tilsvarende findes til Syllable kan det bruges til at undersøge hvad der egentlig sker.
Er jeg så heldig, at du tilfældigvis også lige ved, hvor man normalt henter -p og -i?
Når jeg bruger -m så får jeg at vide at det er "i586", men det ser ud til at man bør bruge -p i stedet, og den returnerer "unknown", så den får tydeligvis ikke informationerne samme sted fra.
Jeg er lidt usikker på det forventede output fra -i, men jeg er rimelig sikker på at "unknown" ikke er overvældende ønskeligt.
Når jeg bruger -m så får jeg at vide at det er "i586", men det ser ud til at man bør bruge -p i stedet, og den returnerer "unknown", så den får tydeligvis ikke informationerne samme sted fra.
Jeg er lidt usikker på det forventede output fra -i, men jeg er rimelig sikker på at "unknown" ikke er overvældende ønskeligt.
Hvis man skriver "man 2 uname" på et Linux system kan man se hvilke oplysninger man får fra uname systemkaldet.
Oplysninger om CPU kommer fra /proc/cpuinfo. Jeg ved ikke om koden til at parse /proc/cpuinfo er en del af uname programmet eller om det kalder en library funktion som kan parse /proc/cpuinfo.
Oplysninger om CPU kommer fra /proc/cpuinfo. Jeg ved ikke om koden til at parse /proc/cpuinfo er en del af uname programmet eller om det kalder en library funktion som kan parse /proc/cpuinfo.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund