Project

General

Profile

Actions

Bug #595

closed

uname -m bug ?

Added by elekktretterr almost 19 years ago. Updated almost 19 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi there,
Shouldnt uname -m say pc32 and uname -p say i386 ?

At least according to the kernel configuration file

platform pc32
machine i386

I get i386 for both -m and -p.

Cheers,
Petr

Actions #1

Updated by elekktretterr almost 19 years ago

By the way, what's the difference between machine and machine_arch?

Petr

Actions #2

Updated by dillon almost 19 years ago

:By the way, what's the difference between machine and machine_arch?
:
:Petr

When I first separated the nameing scheme out it seemed to work fine,
but then we started to hit snags with third party applications getting
confused. MACHINE and MACHINE_ARCH (and uname) were very badly designed
and the fact that both returned the same string 'i386' in many cases
made it worse. So many applications use the two interchangably now that
we have no choice but to follow a scheme that returns the same results
as other unixes.
Due to all of these problems I reverted the naming scheme before our
most recent release. Our build system still uses a 'platform'
abstraction with its own naming scheme, but if you look at the files in
/usr/src/sys/config/ you will notice that we have three naming directives
now instead of two. e.g.:
platform        vkernel         # platform architecture (i386, vkernel, etc)
machine i386
machine_arch i386 # cpu architecture (i386, etc)
If you were to ask me what the difference is between machine and
machine_arch... oh wait, you DID ask what the difference was! Well,
I don't think any answer I give would make much sense.
-Matt
Matthew Dillon
<>
Actions #3

Updated by TGEN almost 19 years ago

'Hysterical raisins' properly fits the bill imho :).

Cheers,
--
Thomas E. Spanjaard

Actions #4

Updated by elekktretterr almost 19 years ago

So we are keeping both machine and machine_arch due to compatibility
reasons so that 3rd party apps dont get confused by pc32, is that so?

Offtopic:
I didnt wanna start another thread, so i shall just ask now (i asked
this before but got no answer), how do i switch between 1:1 and M:1? Is
there an easy way to try the new beast without screwing up much with my
system?

Cheers,
Petr

Actions #5

Updated by dillon almost 19 years ago

:Matthew Dillon wrote:
:> If you were to ask me what the difference is between machine and
:> machine_arch... oh wait, you DID ask what the difference was! Well,
:> I don't think any answer I give would make much sense.
:>
:> -Matt
:> Matthew Dillon
:> <>
:>
:>
:So we are keeping both machine and machine_arch due to compatibility
:reasons so that 3rd party apps dont get confused by pc32, is that so?
:
:Offtopic:
:I didnt wanna start another thread, so i shall just ask now (i asked
:this before but got no answer), how do i switch between 1:1 and M:1? Is
:there an easy way to try the new beast without screwing up much with my
:system?
:
:Cheers,
:Petr

libthread_xu is the basis for 1:1 threading.  libc_r will remain the
basis for M:1 threading.
-Matt
Matthew Dillon
&lt;&gt;
Actions #6

Updated by dillon almost 19 years ago

:So we are keeping both machine and machine_arch due to compatibility
:reasons so that 3rd party apps dont get confused by pc32, is that so?

Right.
-Matt
Matthew Dillon
&lt;&gt;
Actions #7

Updated by elekktretterr almost 19 years ago

Well, what I was wondering though is how do I switch app X to use
libthread_xu?

Thanks
Petr

Actions #8

Updated by corecode almost 19 years ago

nothing. libthread_xu still needs a little bit of work and switching the threading lib has to be implemented.

cheers
simon

Actions

Also available in: Atom PDF