istribution.
>
> ./scripts/mkcompile_h: line 38: hostname: command not found
>
> Use `uname -n` instead, which is more likely to be available (and
> mandated by standards).
>
> Signed-off-by: Chris Down
> Cc: Masahiro Yamada
> Cc: Michal Marek
> Cc: lin
`hostname` may not be present on some systems as it's not mandated by
POSIX/SUSv4. This isn't just a theoretical problem: on Arch Linux,
`hostname` is provided by `inetutils`, which isn't part of the base
distribution.
./scripts/mkcompile_h: line 38: hostname: command not found
Hi Tuomas,
On Wed, Oct 18, 2017 at 06:07:22PM +0300, Tuomas Tynkkynen wrote:
> Hi,
>
> For our distro (NixOS), I've experimented with building packages for ARMv6
> on ARMv7 hardware. This has generally worked fine, except that some build
> scripts (in coreutils, for example
Hi,
For our distro (NixOS), I've experimented with building packages for
ARMv6 on ARMv7 hardware. This has generally worked fine, except that
some build scripts (in coreutils, for example) notice that `uname -m`
returns 'armv7l' and thus decide to e.g. add some ARMv7-spec
scripting python: Add ppc64le to audit uname list
Before patch:
$ uname -m
ppc64le
$ ./perf script -s ./scripts/python/syscall-counts.py
Install the audit-libs-python package to get syscall names.
For example:
# apt-get install python-audit (Ubuntu)
# yum install audit-libs-python
From: "Naveen N. Rao"
Before patch:
$ uname -m
ppc64le
$ ./perf script -s ./scripts/python/syscall-counts.py
Install the audit-libs-python package to get syscall names.
For example:
# apt-get install python-audit (Ubuntu)
# yum install audit-libs-python (Fedor
On 15 March 2017 at 17:56, Shuah Khan wrote:
> Hi Fathi,
>
> On 03/15/2017 07:15 AM, Fathi Boudra wrote:
>> powerpc selftests allow to override ARCH for cross-compilation by making
>> the first ARCH assignment weak.
>> Use the same approach in breakpoints, ipc and prctl
Hi Fathi,
On 03/15/2017 07:15 AM, Fathi Boudra wrote:
> powerpc selftests allow to override ARCH for cross-compilation by making
> the first ARCH assignment weak.
> Use the same approach in breakpoints, ipc and prctl tests to:
> - keep uname usage consistent across selftests
> -
powerpc selftests allow to override ARCH for cross-compilation by making
the first ARCH assignment weak.
Use the same approach in breakpoints, ipc and prctl tests to:
- keep uname usage consistent across selftests
- make it easier to cross-compile
Signed-off-by: Fathi Boudra
---
tools/testing
Execute 'uname -a' using the awk system() function.
Signed-off-by: Alexander Kapshuk
---
scripts/ver_linux | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/ver_linux b/scripts/ver_linux
index 2f1d494..c509f09 100755
--- a/scripts/ver_linux
+++ b/scripts
ath from the release
>>>> from uname(2). Because we use the UNAME26 personality, we need perf to
>>>> find modules located at the same path as the system tools.
>>>
>>> I guess it's easy to google this up, but could you
>>> please state in t
On Wed, Oct 07, 2015 at 11:19:17AM +0300, Adrian Hunter wrote:
> On 07/10/15 11:18, Jiri Olsa wrote:
> > On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote:
> >> Tools in kmod (e.g. modprobe) compose the module path from the release
> >> from uname(2).
On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote:
> Tools in kmod (e.g. modprobe) compose the module path from the release
> from uname(2). Because we use the UNAME26 personality, we need perf to
> find modules located at the same path as the system tools.
May be easier to j
On 07/10/15 11:18, Jiri Olsa wrote:
> On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote:
>> Tools in kmod (e.g. modprobe) compose the module path from the release
>> from uname(2). Because we use the UNAME26 personality, we need perf to
>> find modules located at
On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote:
> Tools in kmod (e.g. modprobe) compose the module path from the release
> from uname(2). Because we use the UNAME26 personality, we need perf to
> find modules located at the same path as the system tools.
I guess it's
Tools in kmod (e.g. modprobe) compose the module path from the release
from uname(2). Because we use the UNAME26 personality, we need perf to
find modules located at the same path as the system tools.
Signed-off-by: Matt Mullins
Cc: Vinson Lee
---
tools/perf/util/machine.c | 28
> Thus, I decided to fake a Linux-like answer on this syscall, and
> implement another syscall where I could put what I wanted. In practice,
> I currently identify myself as "Linux 2.6.35" through uname(2), but
> "Manux 0.0.5" through my uname_vect(2) syscall.
&g
been reimplemented
(keyctl(8), for example, proudly returns -ENOSYS), but the implemented
ones are faithfully following the Linux specification.
Well, nearly. That is, besides potential bugs (and unimplemented
features), I have done one notable modification, to the uname(2) syscall.
When I initially wro
3.7-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
commit f1b99392caf120d7533da260318fae0eb5053737 upstream.
By popular demand, arch/aarch64 is now known as arch/arm64. However,
uname -m (and indeed the GNU triplet) still use
0 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
v9ses->afid = option;
break;
case Opt_uname:
- match_strlcpy(v9ses->uname, &args[0], PATH_MAX);
+
On Sun, 24 Feb 2008 09:37:23 -0600 "Eric Van Hensbergen" <[EMAIL PROTECTED]>
wrote:
> On Sat, Feb 23, 2008 at 2:07 AM, Andrew Morton
> <[EMAIL PROTECTED]> wrote:
> >
> > It would be better to present this as two patches. One adds the new core
> > APIs and the other uses those APIs in v9fs. Th
On Sat, Feb 23, 2008 at 2:07 AM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
>
> It would be better to present this as two patches. One adds the new core
> APIs and the other uses those APIs in v9fs. The patches would take
> separate routes into mainline.
>
> I guess I can sneak this one in as-i
gt;
>
> diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
> index fbb12da..e42948b 100644
> --- a/fs/9p/v9fs.c
> +++ b/fs/9p/v9fs.c
> @@ -135,10 +135,10 @@ static void v9fs_parse_options(struct v9fs_session_info
> *v9ses)
> v9ses->trans = v9fs_
9ses)
v9ses->trans = v9fs_match_trans(&args[0]);
break;
case Opt_uname:
- match_strcpy(v9ses->uname, &args[0]);
+ match_strlcpy(v9ses->uname, &args[0], PATH_MAX);
9ses)
v9ses->trans = v9fs_match_trans(&args[0]);
break;
case Opt_uname:
- match_strcpy(v9ses->uname, &args[0]);
+ match_strlcpy(v9ses->uname, &args[0], PATH_MAX);
On Mar 20 2007 09:17, Oliver Falk wrote:
>
> But on i386 it reports:
> [EMAIL PROTECTED] ~]$ uname -mpi
> i686 i686 i386
Reports this for me:
$ uname -mpi
i686 athlon i386
> And I remember that it used to report alphaev67 or alphaev56...
Jan
--
-
To unsubscribe from this list
Hi Eric!
On 03/19/2007 06:44 PM, Eric W. Biederman wrote:
Oliver Falk <[EMAIL PROTECTED]> writes:
[ ... ]
The kernel uname function at least does not have fields that
report processor or hardware platform.
But on i386 it reports:
[EMAIL PROTECTED] ~]$ uname -mpi
i686 i686 i386
Oliver Falk <[EMAIL PROTECTED]> writes:
> Hi!
>
> We have a discussion on alpha mailinglist at the moment, because of uname
> -mpi.
>
> AFAIK, uname -m should do some glibc call, which calls kernel, right?
>
> However, I have two machines:
>
> AS1000A:
>
Hi!
We have a discussion on alpha mailinglist at the moment, because of
uname -mpi.
AFAIK, uname -m should do some glibc call, which calls kernel, right?
However, I have two machines:
AS1000A:
[EMAIL PROTECTED] ~]# uname -mpi && cat /proc/cpuinfo | grep model
alpha alpha alpha
c
Hi, Keith!
> A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or
> 2.x.y.save to preserve a working kernel. But renaming the image does
> not change the value of uname -r so it still tries to use modules
> 2.x.y, which defeats the purpose of saving an working kernel
On Sun, May 06, 2001 at 01:36:05AM -0700, Mike Castle wrote:
> On Sun, May 06, 2001 at 10:12:17AM +0200, Lars Marowsky-Bree wrote:
> > You assign a new EXTRAVERSION to the new kernel you are building, and keep the
> > old kernel at the old name.
>
> Except that some patches (ie, RAID, -ac) use EX
On Sun, 6 May 2001, Keith Owens wrote:
>>On Sun, 6 May 2001, Keith Owens wrote:
>>>A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or
>>>2.x.y.save to preserve a working kernel.
>>
>>I don't see how this patch is necessary when we have
>>"EXTRAVERSION" available. Change EXTRAVERSI
On 2001-05-06T01:36:05,
Mike Castle <[EMAIL PROTECTED]> said:
> On Sun, May 06, 2001 at 10:12:17AM +0200, Lars Marowsky-Bree wrote:
> > You assign a new EXTRAVERSION to the new kernel you are building, and keep the
> > old kernel at the old name.
>
> Except that some patches (ie, RAID, -ac) u
On Sun, May 06, 2001 at 10:12:17AM +0200, Lars Marowsky-Bree wrote:
> You assign a new EXTRAVERSION to the new kernel you are building, and keep the
> old kernel at the old name.
Except that some patches (ie, RAID, -ac) use EXTRAVERSION. There needs to
be a new variable, say USERVERSION, that wi
On 2001-05-06T17:45:06,
Keith Owens <[EMAIL PROTECTED]> said:
> You already have a working kernel which you want to rename to use as a
> backup version. Changing EXTRAVERSION and recompiling builds a new
> kernel and adds uncertainty about whether the kernel still works - did
> you change any
On Sun, 6 May 2001 03:35:34 -0400 (EDT),
"Mike A. Harris" <[EMAIL PROTECTED]> wrote:
>On Sun, 6 May 2001, Keith Owens wrote:
>>A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or
>>2.x.y.save to preserve a working kernel.
>
>I don't see how this patch is necessary when we have
>"EXT
On Sun, 6 May 2001, Keith Owens wrote:
>Date: Sun, 06 May 2001 17:15:45 +1000
>From: Keith Owens <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: [patch] 2.4 add suffix for uname -r
>
>A frequent requirement is to rename
A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or
2.x.y.save to preserve a working kernel. But renaming the image does
not change the value of uname -r so it still tries to use modules
2.x.y, which defeats the purpose of saving an working kernel.
Normally I would say that this
e machine type CPU TYPE. The choices
for CPU TYPE are the same as for `-mcpu'. Moreover, specifying
`-march=CPU TYPE' implies `-mcpu=CPU TYPE'.
> I started rebuilding SRPMS with these as optflags, just to find out that
> some packages don't use optflags, but u
Few days ago, I found an incredibly usable option in latest gcc versions.
gcc -march=k6 -mcpu=k6
I started rebuilding SRPMS with these as optflags, just to find out that
some packages don't use optflags, but use -march=`uname -m`.
So ...
What about uname -m and non-Intel processors? Is
"Mr. Shannon Aldinger" <[EMAIL PROTECTED]> writes:
|> On Sun, 15 Apr 2001, it was written:
|>
|> > elfie:~ # uname -p
|> > unknown
|> >
|> > elfie:~ # uname -a
|> > Linux elfie 2.4.3 #1 Fri Apr 13 21:08:29 CEST 2001 i586 unknown
|> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 15 Apr 2001, it was written:
> elfie:~ # uname -p
> unknown
>
> elfie:~ # uname -a
> Linux elfie 2.4.3 #1 Fri Apr 13 21:08:29 CEST 2001 i586 unknown
>
I get the same on my Sun Ultra 1, and various x86 boxes. I'm sure t
On Sun Apr 15 2001, joker wrote:
> i have this problem using intel 850mhz and 333mhz
> any know where to get update version of uname ?
http://www.tuxfinder.com
Btw:
elfie:~ # uname --version
uname (GNU sh-utils) 2.0.11
Written by David MacKenzie.
Copyright (C) 2000 Free Software Foun
i have this problem using intel 850mhz and 333mhz
any know where to get update version of uname ?
Ishikawa wrote:
> Hi,
>
> On my athlong K7 optimized kernel prints "unknown" fir oricessir type.
> (I have not realized what this "unknown" stood for until today.)
&
uname has printed unknown for the cpu vendor for as long as I can
remember.
There is a hacked uname.c distributed as "nuname" that works for cyrix
intel and amd, maybe others.
http://cds.duke.edu/pub/sunsite/utils/shell/nuname-1.0.tar.gz
I *think* Cyrix shows up as CyrixInstead
Dual
BTW this is also the case for AMD-K6-3 and I would imagine all other AMD
processors.
B.
On Sun, 15 Apr 2001, Ishikawa wrote:
> Hi,
>
> On my athlong K7 optimized kernel prints "unknown" fir oricessir type.
> (I have not realized what this "unknown" stood
Hi,
On my athlong K7 optimized kernel prints "unknown" fir oricessir type.
(I have not realized what this "unknown" stood for until today.)
#uname -p
unknown
#uname -a
Linux duron 2.4.3 #2 Fri Apr 6 04:38:35 JST 2001 i686 unknown
It would be nice to have the processor na
Since 2.2.18pre20, the symlink /lib/modules/`uname -r`/build is not
created because of a non-escaped $ in Makefile.
Patch:
--- linux/Makefile.orig Fri Dec 1 01:39:24 2000
+++ linux/Makefile Fri Dec 1 01:39:32 2000
@@ -335,7 +335,7 @@
MODLIB=$(INSTALL_MOD_PATH)/lib/modules
> Little question about 'uname'. Does it read data from kernel, /proc or
> get its data from other source ?
'strace' was made to answer questions like this.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, 23 Nov 2000, J . A . Magallon wrote:
> Little question about 'uname'. Does it read data from kernel, /proc or
> get its data from other source ?
uname(1) utility calls uname(2) syscall.
--
Alex
--
Hi everyone.
Little question about 'uname'. Does it read data from kernel, /proc or
get its data from other source ?
uname info page:
$ uname -a
Linux hayley 1.0.4 #3 Thu May 12 18:06:34 1994 i486
my system:
uname -a
Linux werewolf 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET
51 matches
Mail list logo
