Hello,
The use of "new" as a variable name in the macro "__cmpxchg" breaks
builds of other programs that link to include/asm-i386/system.h
I'd like to request that this be renamed to something else, like mynew
or krnew.
Thanks.
John Gilbert
[email protected]
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
On Tue, 2005-05-17 at 17:51 -0700, Gilbert, John wrote:
> Hello,
> The use of "new" as a variable name in the macro "__cmpxchg" breaks
> builds of other programs that link to include/asm-i386/system.h
> I'd like to request that this be renamed to something else, like mynew
> or krnew.
The kernel is written in C. "new" is not reserved in C. Userspace
programs should not include kernel headers anyway.
Lee
On Tue, May 17, 2005 at 05:51:36PM -0700, Gilbert, John wrote:
> The use of "new" as a variable name in the macro "__cmpxchg" breaks
> builds of other programs that link to include/asm-i386/system.h I'd
> like to request that this be renamed to something else, like mynew
> or krnew.
there are plenty of similar examples where tokens used are reserved
words in c++ --- it's quite a lot of invasive work to clean these up
properly for little or no apparent gain
On Tue, 2005-05-17 at 17:51 -0700, Gilbert, John wrote:
> Hello,
> The use of "new" as a variable name in the macro "__cmpxchg" breaks
> builds of other programs that link to include/asm-i386/system.h
> I'd like to request that this be renamed to something else, like mynew
> or krnew.
mynew is for beginner programmers (and perl scripts!). The normal
convention is to add a "k" as in printk or ksoftirqd, so it should be
"knew". But who knew?
Besides, what programs are you compiling that are using kernel headers?
That's always a no-no. Although I did notice that errno.h on debian
includes bits/errno.h which includes linux/errno.h. But that's the
distribution's linux headers, and I don't see any header including
asm/system.h
> Thanks.
> John Gilbert
> [email protected]
>
> -----------------------------------------
> This message (including any attachments) may contain confidential
> information intended for a specific individual and purpose. If you are not
> the intended recipient, delete this message. If you are not the intended
> recipient, disclosing, copying, distributing, or taking any action based on
> this message is strictly prohibited.
Is this a joke? It doesn't make sense sending a disclaimer like this to
a mailing list!
-- Steve
On Tue, May 17, 2005 at 10:51:22PM -0400, Steven Rostedt wrote:
> On Tue, 2005-05-17 at 17:51 -0700, Gilbert, John wrote:
> (...)
> > -----------------------------------------
> > This message (including any attachments) may contain confidential
> > information intended for a specific individual and purpose. If you are not
> > the intended recipient, delete this message. If you are not the intended
> > recipient, disclosing, copying, distributing, or taking any action based on
> > this message is strictly prohibited.
>
> Is this a joke? It doesn't make sense sending a disclaimer like this to
> a mailing list!
Perhaps he did not send this mail to the list after all, so we should all
ignore it. I don't see my address in the To: field anyway :-)
Willy
On Tuesday 17 May 2005 10:51 pm, Steven Rostedt wrote:
> > -----------------------------------------
> > This message (including any attachments) may contain confidential
> > information intended for a specific individual and purpose. If you are
> > not the intended recipient, delete this message. If you are not the
> > intended recipient, disclosing, copying, distributing, or taking any
> > action based on this message is strictly prohibited.
>
> Is this a joke? It doesn't make sense sending a disclaimer like this to
> a mailing list!
A lot of buisnesses have their MTAs setup to automatically add that
attachment. IMHO it is a /very/ bad idea to do so, and is probably some form
of violation of the employees' free speech rights.
That, and since he sent it to the lkml, everyone subscribed is the intended
recipient. ;)
--
Patrick "Diablo-D3" McFarland || [email protected]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
On 5/18/05, Patrick McFarland <[email protected]> wrote:
> On Tuesday 17 May 2005 10:51 pm, Steven Rostedt wrote:
> > > -----------------------------------------
> > > This message (including any attachments) may contain confidential
> > > information intended for a specific individual and purpose. If you are
> > > not the intended recipient, delete this message. If you are not the
> > > intended recipient, disclosing, copying, distributing, or taking any
> > > action based on this message is strictly prohibited.
> >
> > Is this a joke? It doesn't make sense sending a disclaimer like this to
> > a mailing list!
>
> A lot of buisnesses have their MTAs setup to automatically add that
> attachment. IMHO it is a /very/ bad idea to do so, and is probably some form
> of violation of the employees' free speech rights.
>
> That, and since he sent it to the lkml, everyone subscribed is the intended
> recipient. ;)
Everyone else don't subscribe but reading from an archive are not the
intended recipients? mort de rire
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
There is some M$ crap mail-server that can be configured to
put that junk on the end of all the mail. There is no way
for an ordinary user to prevent it except by changing job.
On Wed, 18 May 2005, Patrick McFarland wrote:
> On Tuesday 17 May 2005 10:51 pm, Steven Rostedt wrote:
>>> -----------------------------------------
>>> This message (including any attachments) may contain confidential
>>> information intended for a specific individual and purpose. If you are
>>> not the intended recipient, delete this message. If you are not the
>>> intended recipient, disclosing, copying, distributing, or taking any
>>> action based on this message is strictly prohibited.
>>
>> Is this a joke? It doesn't make sense sending a disclaimer like this to
>> a mailing list!
>
> A lot of buisnesses have their MTAs setup to automatically add that
> attachment. IMHO it is a /very/ bad idea to do so, and is probably some form
> of violation of the employees' free speech rights.
>
> That, and since he sent it to the lkml, everyone subscribed is the intended
> recipient. ;)
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
> all be running around in darkened rooms, munching magic pills and listening to
> repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Hello all,
Sorry about the automatic disclaimer at the bottom of these emails, it's
part of working here at Dolby. I'm sure it doesn't apply to this
discussion.
I had a few responses to this bug fix request (which I did mail to this
list), none were what I was hoping for, namely "This will be fixed in
the next release", so allow me to clarify.
The problem: Linux kernel headers use C++ reserved words as variable
names. This breaks builds of C++ code that include kernel headers.
Examples: The use of "new" in the macro __cmpxchg in system.h. This hits
MySQL which links into the kernel headers to determine if the platform
is SMP aware or not (don't ask me why.)
The use of "virtual" in the structure drm_buf_map in drm.h, used
by drm_bufs.c. This hits C++ code that uses the DRI interface to lock
with vertical retrace.
The solution: rename these variables, keep C++ reserved words out of
headers, make this practice part of the style guide.
I'm not advocating writing parts of the kernel in C++, or cleaning out
reserved words in the entire kernel. I know the one and only true
language is C, but for Linux to achieve world domination it needs to be
inclusive at running (and building) any software in whatever language.
As to the comments stating that "Userspace code shouldn't include kernel
headers", that's fine in the "Hello, World", but in the real world,
applications need access to devices and system resources, which means
communicating with the kernel with the proper ioctls, flags, system
configuration, data structures, etc., which are kept in kernel headers.
For this reason, breaking these apart from the application build
environment is a really bad idea, no mater what Linus Torvalds has to
say about it (see
http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html). It needs to
be an fully integrated system for everything to run correctly.
Besides, I don't have time to rewrite MySQL in C to make it "correct".
I've got more important things to do. ;^)
So please, keep your headers clean.
John Gilbert
[email protected]
Ignore the sig.
###############
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
On Wed, May 18, 2005 at 11:23:33AM -0700, Gilbert, John wrote:
> Hello all,
Hi John,
>...
> Examples: The use of "new" in the macro __cmpxchg in system.h. This hits
> MySQL which links into the kernel headers to determine if the platform
> is SMP aware or not (don't ask me why.)
>...
I haven't ever seen MySQL doing something that stupid (stupid because
if it's required, it _really_ has to be done at runtime).
Which version of MySQL have you seen such an SMP check in?
> John Gilbert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
This looks like the source of some stupidity.
http://bugs.mysql.com/bug.php?id=555
Which is even more fun when you see this.
http://bugs.mysql.com/bug.php?id=10364
I think it's been in there a while, but only really blows up when built
under recent kernels.
I agree, it's probably not the right way to go.
John G.
-----Original Message-----
From: Adrian Bunk [mailto:[email protected]]
Sent: Wednesday, May 18, 2005 12:02 PM
To: Gilbert, John
Cc: [email protected]
Subject: Re: Illegal use of reserved word in system.h
On Wed, May 18, 2005 at 11:23:33AM -0700, Gilbert, John wrote:
> Hello all,
Hi John,
>...
> Examples: The use of "new" in the macro __cmpxchg in system.h. This
>hits MySQL which links into the kernel headers to determine if the
>platform is SMP aware or not (don't ask me why.) ...
I haven't ever seen MySQL doing something that stupid (stupid because if
it's required, it _really_ has to be done at runtime).
Which version of MySQL have you seen such an SMP check in?
> John Gilbert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
The subject line is invalid. We don't make law here.
The correct word is invalid, not illegal. There should
not be any "illegal" strings in the kernel either although they
sometimes creep in...
grep of `strings vmlinux`....
IllegalLengthIndication
Illegal request
<3>%s: Illegal value specified for power
Illegal mode for this track or incompatible medium
<6>tcp_parse_options: Illegal window scaling value %d >14 received.
One can't fix the "illegal request" because it's part of
the (wrong) standard for error number strings.
Now, if you want the names of structure members changed, you
are going to have to submit a patch. You will also have to
patch anything that accesses those member names in user-mode.
Nobody is going to do it for you.
The kernel headers are clean. If you don't like them, then
you can simply clean up your own copy to your own standards.
This is free software any you can't bully anybody into doing
your work for you.
It's also quite presumptuous of you that you think that you
can instruct any of the kernel developers on how to write
header files. In addition, any user-mode code that uses
kernel headers is broken by definition. There is no other
operating system except BSD that gives user mode code
access to kernel-headers. Somehow, people have been able
to write working code using those operating systems without
using kernel headers.
There are people who can instruct you in the proper methods
of interfacing with the kernel. There are even many books
that have been written. I suggest that if you have a driver
that requires access to kernel headers, when being accessed
by user-mode code, the driver is broken. Unix/linux provides
standard methods of interface to drivers. They include
open(), close(), read(), write(), mmap() and ioctl(). In
addition, there are various semaphores and signaling
mechanisms like poll(). If you are accessing devices
or kernel functions in other than these standard interfaces,
your code is broken beyond all repair.
Also kernel headers don't show if the system the SQL code
is running on is SMP aware and Ray was much better behaved.
On Wed, 18 May 2005, Gilbert, John wrote:
> Hello all,
>
> Sorry about the automatic disclaimer at the bottom of these emails, it's
> part of working here at Dolby. I'm sure it doesn't apply to this
> discussion.
>
> I had a few responses to this bug fix request (which I did mail to this
> list), none were what I was hoping for, namely "This will be fixed in
> the next release", so allow me to clarify.
>
> The problem: Linux kernel headers use C++ reserved words as variable
> names. This breaks builds of C++ code that include kernel headers.
>
> Examples: The use of "new" in the macro __cmpxchg in system.h. This hits
> MySQL which links into the kernel headers to determine if the platform
> is SMP aware or not (don't ask me why.)
> The use of "virtual" in the structure drm_buf_map in drm.h, used
> by drm_bufs.c. This hits C++ code that uses the DRI interface to lock
> with vertical retrace.
>
> The solution: rename these variables, keep C++ reserved words out of
> headers, make this practice part of the style guide.
>
> I'm not advocating writing parts of the kernel in C++, or cleaning out
> reserved words in the entire kernel. I know the one and only true
> language is C, but for Linux to achieve world domination it needs to be
> inclusive at running (and building) any software in whatever language.
>
> As to the comments stating that "Userspace code shouldn't include kernel
> headers", that's fine in the "Hello, World", but in the real world,
> applications need access to devices and system resources, which means
> communicating with the kernel with the proper ioctls, flags, system
> configuration, data structures, etc., which are kept in kernel headers.
> For this reason, breaking these apart from the application build
> environment is a really bad idea, no mater what Linus Torvalds has to
> say about it (see
> http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html). It needs to
> be an fully integrated system for everything to run correctly.
>
> Besides, I don't have time to rewrite MySQL in C to make it "correct".
> I've got more important things to do. ;^)
>
> So please, keep your headers clean.
>
> John Gilbert
> [email protected]
>
> Ignore the sig.
> ###############
>
> -----------------------------------------
> This message (including any attachments) may contain confidential
> information intended for a specific individual and purpose. If you are not
> the intended recipient, delete this message. If you are not the intended
> recipient, disclosing, copying, distributing, or taking any action based on
> this message is strictly prohibited.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
.
On Wed, May 18, 2005 at 12:07:29PM -0700, Gilbert, John wrote:
> Hi Adrian,
Hi John,
> This looks like the source of some stupidity.
> http://bugs.mysql.com/bug.php?id=555
>...
that's not a check whether the system supports SMP.
Looking at the source code of MySQL, it seems MySQL does some dirty
tricks for using the inlines from asm/atomic.h in userspace.
It's _really_ wrong to do this.
> John G.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Richard B. Johnson writes:
The subject line is invalid. We don't make law here.
The correct word is invalid, not illegal. There should not be any
"illegal" strings in the kernel either although they sometimes creep
in...
#JG
Sorry, I was borrowing the term from the g++ error that this created.
I'm not trying to imply that someone should be arrested. ;^) Also, like
a few people have already mentioned, it doesn't effect the kernel at all
as it's strictly a C program.
Now, if you want the names of structure members changed, you are going
to have to submit a patch. You will also have to patch anything that
accesses those member names in user-mode.
Nobody is going to do it for you.
#JG
They are very trivial patches, but I'll include them here.
It's also quite presumptuous of you that you think that you can instruct
any of the kernel developers on how to write header files. In addition,
any user-mode code that uses kernel headers is broken by definition.
There is no other operating system except BSD that gives user mode code
access to kernel-headers. Somehow, people have been able to write
working code using those operating systems without using kernel headers.
#JG
Including header files might be bad practice, but it's not uncommon, and
only truly broken when the kernel changes. I know many reasons for why
it's bad, but I also know that it's sometimes necessary (see below).
It's also usually not my code that breaks, but I often have to fix it if
I want to get the program to work.
There are people who can instruct you in the proper methods of
interfacing with the kernel. There are even many books that have been
written. I suggest that if you have a driver that requires access to
kernel headers, when being accessed by user-mode code, the driver is
broken. Unix/linux provides standard methods of interface to drivers.
They include open(), close(), read(), write(), mmap() and ioctl(). In
addition, there are various semaphores and signaling mechanisms like
poll(). If you are accessing devices or kernel functions in other than
these standard interfaces, your code is broken beyond all repair.
#JG
As a counter-example, I'm including a program that uses /dev/dri to
framelock to vsync. It's stupid in multiple ways but it seems to be
currently the only semi-portable way to do this under X windows. It also
uses two kernel headers, and if you read through the code, it's spin
waiting for the ioctl call to return the right value, sometimes skipping
a frame. If you patch this into a C++ program with the stock kernel
headers, it breaks (the drm.h and drm_bufs.c patches fix this).
I'd really appreciate if some kernel developer enabled the "Correct" way
to do this. If there was a way to wake a thread (a blocking read on
/dev/vsync?) on a video vsync interrupt, a lot of media players, games,
and other real-time graphics dependant programs could take less system
resources, and have better quality graphics. In the meantime however,
this mostly works today (with patched kernel headers).
Also kernel headers don't show if the system the SQL code is running on
is SMP aware and Ray was much better behaved.
#JG
According to Adrian Bunk, MySQL is using inlines from asm/atomic.h (yes,
very bad). The fact they set CONFIG_SMP manually to expose some
additional code, but not setting the cpu count variables breaks builds
under later 2.6 kernels. See http://bugs.mysql.com/bug.php?id=10364
Again, it's not my code. Tweaking a few kernel headers is easier than
fixing everyone else's bad code practices.
John Gilbert
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
Richard B. Johnson wrote:
>
> There is some M$ crap mail-server that can be configured to
> put that junk on the end of all the mail. There is no way
> for an ordinary user to prevent it except by changing job.
Why would it need to be a Microsoft mailserver in order to mangle outgoing mails
... ?
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
"Gilbert, John" <[email protected]> writes:
>
> I think it's been in there a while, but only really blows up when built
>
> under recent kernels.
>
> I agree, it's probably not the right way to go.
It's quite dangerous. I suppose it uses this for atomic.h, but it
means that a mysql compiled under a uniprocessor kernel (or rather
with a autoconf.h of a uniprocessor kernel, it can even be SMP) will
have subtle races when run on a SMP system because the atomic
instructions will miss lock prefixes. Sounds like an open
deathtrap to me.
I would suggest changing MySQL to keep its own copies of atomic.h
for the different architectures. Then they can drop the asm/system.h
includes too.
-Andi
On Thu, May 19, 2005 at 01:42:28AM +0200, Andi Kleen wrote:
> "Gilbert, John" <[email protected]> writes:
> >
> > I think it's been in there a while, but only really blows up when built
> >
> > under recent kernels.
> >
> > I agree, it's probably not the right way to go.
>
> It's quite dangerous. I suppose it uses this for atomic.h, but it
> means that a mysql compiled under a uniprocessor kernel (or rather
> with a autoconf.h of a uniprocessor kernel, it can even be SMP) will
> have subtle races when run on a SMP system because the atomic
> instructions will miss lock prefixes. Sounds like an open
> deathtrap to me.
>...
They work around this issue by doing
#ifndef CONFIG_SMP
#define CONFIG_SMP
#endif
> -Andi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Gilbert, John said:
> Hello all,
>
Hi,
FWIW, I agree with you. I have a 'sparse' extension (that
Linus mostly wrote) that detects/warns on all C++ reserved words.
This could be part of a needed general headers cleanup,
although a fairly low priority part of it.
>
> Sorry about the automatic disclaimer at the bottom of these emails, it's
>
> part of working here at Dolby. I'm sure it doesn't apply to this
>
> discussion.
>
>
>
> I had a few responses to this bug fix request (which I did mail to this
>
> list), none were what I was hoping for, namely "This will be fixed in
>
> the next release", so allow me to clarify.
>
>
>
> The problem: Linux kernel headers use C++ reserved words as variable
>
> names. This breaks builds of C++ code that include kernel headers.
>
>
>
> Examples: The use of "new" in the macro __cmpxchg in system.h. This hits
>
> MySQL which links into the kernel headers to determine if the platform
>
> is SMP aware or not (don't ask me why.)
>
> The use of "virtual" in the structure drm_buf_map in drm.h, used
>
> by drm_bufs.c. This hits C++ code that uses the DRI interface to lock
>
> with vertical retrace.
>
>
>
> The solution: rename these variables, keep C++ reserved words out of
>
> headers, make this practice part of the style guide.
>
>
>
> I'm not advocating writing parts of the kernel in C++, or cleaning out
>
> reserved words in the entire kernel. I know the one and only true
>
> language is C, but for Linux to achieve world domination it needs to be
>
> inclusive at running (and building) any software in whatever language.
>
>
>
> As to the comments stating that "Userspace code shouldn't include kernel
>
> headers", that's fine in the "Hello, World", but in the real world,
>
> applications need access to devices and system resources, which means
>
> communicating with the kernel with the proper ioctls, flags, system
>
> configuration, data structures, etc., which are kept in kernel headers.
>
> For this reason, breaking these apart from the application build
>
> environment is a really bad idea, no mater what Linus Torvalds has to
>
> say about it (see
>
> http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html). It needs to
>
> be an fully integrated system for everything to run correctly.
>
>
>
> Besides, I don't have time to rewrite MySQL in C to make it "correct".
>
> I've got more important things to do. ;^)
>
>
>
> So please, keep your headers clean.
>
>
>
> John Gilbert
>
> [email protected]
>
>
>
> Ignore the sig.
>
> ###############
>
> -----------------------------------------
>
> This message (including any attachments) may contain confidential
>
> information intended for a specific individual and purpose. If you are
> not
>
> the intended recipient, delete this message. If you are not the intended
>
> recipient, disclosing, copying, distributing, or taking any action based
> on
>
> this message is strictly prohibited.
--
~Randy
Adrian Bunk writes:
that's not a check whether the system supports SMP.
Looking at the source code of MySQL, it seems MySQL does some dirty
tricks for using the inlines from asm/atomic.h in userspace.
It's _really_ wrong to do this.
#JG
So the really, really stupid, idiotic, yet quick and effective hack to
get MySQL to build under a later 2.6 kernel is as follows. In
mysql-4.1.12/include/my_global.h, right after the three #ifndef
CONFIG_SMP lines, add these lines...
#ifndef CONFIG_NR_CPUS
#define CONFIG_NR_CPUS
#endif /* CONFIG_NR_CPUS */
This way, MySQL can continue depending on the SMP atomic macros in
asm-i386 from the Linux kernel, without going into kernel space. I
strongly doubt this is truly multithreaded (or SMP) safe, but that's how
MySQL has been running since 4.0 at least. Someone in the know should
fix this, and end this silliness.
John Gilbert
Thanks for ignoring the sig.
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
On May 18, 2005, at 15:53:37, Adrian Bunk wrote:
> Looking at the source code of MySQL, it seems MySQL does some dirty
> tricks for using the inlines from asm/atomic.h in userspace.
>
> It's _really_ wrong to do this.
A project that had some discussion a while ago was to clean up the
kernel headers and separate them from the kernel-ABI ones, such that
the ABI headers don't need to use CONFIG_* defines or anything else.
that might be iffy.
I suppose a related project would be to build a generic architecture
library (How about "libarch"?) that has a clean set of headers and
context-independent functions (ASM memset, ASM memmove, etc), with
the ability to be used directly in userspace or kernelspace, and
exported via a vDSO to userspace for applications that want it. It
could share the same memory pages between the kernel and userspace,
and with the appropriate config options, it could provide locking
and memory routines optimized for the particular architecture.
I realize that locking routines for some architectures would need to
be implemented by a libc via kernel calls, as the requisite opcodes
are unavailable under usermode, but that could easily be handled by
a wrapper library, as long as the kernel-supported functions and
inlines are provided cleanly and without clutter. The simplistic
__KERNEL__ define could just switch between privileged-opcode inlines
and unprivileged ones, including undefining them entirely and telling
the wrapper libc headers to implement them with syscalls.
This would be a major project, but I think it would make life a lot
easier for application developers. I also think that this library
would need to be licensed under the GPL, due to the existing license
on the kernel code that would be copied, but it _might_ be useable
from proprietary applications (NOTE: IANAL, and I certainly don't
claim to speak for the kernel community at large, so YMMV and you may
well get sued for such usage, but it would still be very useful in
low-latency GPL'ed software that needs atomic ops and spinlocks, and
could be used for more if we threw in the linked list implementation
and other completely arch-agnostic code.)
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$
r !y?(-)
------END GEEK CODE BLOCK------
On Wed, 18 May 2005, Matan Peled wrote:
> Richard B. Johnson wrote:
>>
>> There is some M$ crap mail-server that can be configured to
>> put that junk on the end of all the mail. There is no way
>> for an ordinary user to prevent it except by changing job.
>
> Why would it need to be a Microsoft mailserver in order to mangle outgoing mails
> ... ?
It's usually the unknowable or incompetent IT departments that
have mail-servers that mangle mail. That means they use M$ products.
>
> --
> [Name ] :: [Matan I. Peled ]
> [Location ] :: [Israel ]
> [Public Key] :: [0xD6F42CA5 ]
> [Keyserver ] :: [keyserver.kjsl.com]
> encrypted/signed plain text preferred
>
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Wed, May 18, 2005 at 10:22:24PM -0400, Kyle Moffett wrote:
>
> On May 18, 2005, at 15:53:37, Adrian Bunk wrote:
> >Looking at the source code of MySQL, it seems MySQL does some dirty
> >tricks for using the inlines from asm/atomic.h in userspace.
> >
> >It's _really_ wrong to do this.
>
> A project that had some discussion a while ago was to clean up the
> kernel headers and separate them from the kernel-ABI ones, such that
> the ABI headers don't need to use CONFIG_* defines or anything else.
> that might be iffy.
>...
The whole kernel headers issue contains real problems that have to be
solved properly.
But in this case, this is not the problem:
What MySQL uses from asm/atomic.h doesn't seem to have anything to do
with any kind of kernel <-> userspace interface (which is what userspace
might validly require kernel headers for).
> Cheers,
> Kyle Moffett
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 19 May 2005, Adrian Bunk wrote:
> On Wed, May 18, 2005 at 10:22:24PM -0400, Kyle Moffett wrote:
>>
>> On May 18, 2005, at 15:53:37, Adrian Bunk wrote:
>>> Looking at the source code of MySQL, it seems MySQL does some dirty
>>> tricks for using the inlines from asm/atomic.h in userspace.
>>>
>>> It's _really_ wrong to do this.
>>
>> A project that had some discussion a while ago was to clean up the
>> kernel headers and separate them from the kernel-ABI ones, such that
>> the ABI headers don't need to use CONFIG_* defines or anything else.
>> that might be iffy.
>> ...
>
> The whole kernel headers issue contains real problems that have to be
> solved properly.
>
> But in this case, this is not the problem:
>
> What MySQL uses from asm/atomic.h doesn't seem to have anything to do
> with any kind of kernel <-> userspace interface (which is what userspace
> might validly require kernel headers for).
>
>> Cheers,
>> Kyle Moffett
>
> cu
> Adrian
First off, I think we need a system-call that will return some of
the information that now comes from headers. PAGE_SIZE comes to
mind. You need this for mmap() but there doesn't seem to be any
way to get it. getpagesize() 'C' library just returns something
it's swiped from kernel headers when the library was compiled.
There are other things like the following that sometimes need
to be known also.
HZ
TASK_SIZE
SMP
MAXHOSTNAMELEN
_NSIG
Number of errno values
Highest ioctl value used
A default 'struct termios'
These things are gotten from 'kernel' headers used when the
'C' runtime library was built. They can all change. If these
and others were returned all at once in a structure, then
the 'C' runtime library could make a single call during
initialization and have the correct information for the
existing kernel.
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
> First off, I think we need a system-call that will return some of
> the information that now comes from headers. PAGE_SIZE comes to
> mind. You need this for mmap() but there doesn't seem to be any
> way to get it. getpagesize() 'C' library just returns something
> it's swiped from kernel headers when the library was compiled.
> There are other things like the following that sometimes need
for getpagesize() I can see the point
> to be known also.
>
> HZ
HZ may not exist. At all; people are trying to remove it. And userspace
has no business knowing about it either.
> TASK_SIZE
what for?
> SMP
userspace should not care! Any app that looks at this is buggy; remember
the fully preemptable nature of userspace
> Number of errno values
why?
> Highest ioctl value used
uhh that;s driver dependent.. and what for ?
On Thu, 19 May 2005, Arjan van de Ven wrote:
> > First off, I think we need a system-call that will return some of
> > the information that now comes from headers. PAGE_SIZE comes to
> > mind. You need this for mmap() but there doesn't seem to be any
> > way to get it. getpagesize() 'C' library just returns something
> > it's swiped from kernel headers when the library was compiled.
> > There are other things like the following that sometimes need
>
> for getpagesize() I can see the point
If that is the case, then that's a bug in that C library, which should be
reported and fixed. When starting a program, i.e. as a result of
execve(), Linux passes the current page size in use in the auxiliary
vector. That value should be retrieved and used by a C library for
platforms that support various page sizes and returned by library calls
like getconf(). For example glibc gets it right.
Maciej
On Thu, 19 May 2005, Maciej W. Rozycki wrote:
> On Thu, 19 May 2005, Arjan van de Ven wrote:
>
>>> First off, I think we need a system-call that will return some of
>>> the information that now comes from headers. PAGE_SIZE comes to
>>> mind. You need this for mmap() but there doesn't seem to be any
>>> way to get it. getpagesize() 'C' library just returns something
>>> it's swiped from kernel headers when the library was compiled.
>>> There are other things like the following that sometimes need
>>
>> for getpagesize() I can see the point
>
> If that is the case, then that's a bug in that C library, which should be
> reported and fixed. When starting a program, i.e. as a result of
> execve(), Linux passes the current page size in use in the auxiliary
> vector. That value should be retrieved and used by a C library for
> platforms that support various page sizes and returned by library calls
> like getconf(). For example glibc gets it right.
>
> Maciej
>
Would you please explain 'auxiliary' vector???
According to the documentation, the following information
is passed to a program:
#
# %edx Contains a function pointer to be registered with `atexit'.
# This is how the dynamic linker arranges to have DT_FINI
# functions called for shared libraries that have been loaded
# before this code runs.
#
# %esp The stack contains the arguments and environment:
# (%esp) argc
# 4(%esp) argv[0]
# ...
# (4*argc)(%esp) NULL
# (4*(argc+1))(%esp) envp[0]
# ...
# NULL
#
Now, where is that 'auxiliary vevtor'??? I got a pointer to
something to be executed before calling exit, I have an
argument count, then a bunch of pointers (argv), terminating
with a NULL, then another bunch of pointers (envp) terminating
with a NULL. Is there something after that??? If so, what's
the contents of this thing?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Thu, 2005-05-19 at 09:01 -0400, Richard B. Johnson wrote:
>
> Would you please explain 'auxiliary' vector???
Looking in fs/binfmt_elf.c I see that information is passed in via elf
info. But the PAGE_SIZE passed in is ELF_EXEC_PAGESIZE which may not
actually be the same as PAGE_SIZE.
-- Steve
On Thu, 2005-05-19 at 14:27 +0200, Arjan van de Ven wrote:
>
> > SMP
> userspace should not care! Any app that looks at this is buggy; remember
> the fully preemptable nature of userspace
Hmm, you seem to be assuming what userspace is looking at SMP for. Say
you might want to run some daemon on each CPU and set affinity
accordingly, or some other reason. But I guess you can get that
information from looking at /proc/cpuinfo, and maybe someplace else.
Really, what is needed is to get the kernel to give all the information
to libc that is needed via /proc, /sysfs, system calls, etc. such that
we can remove /usr/include/{linux,asm,asm-generic} and not worry about
user programs using kernel headers. Users will continue to include them
as long as they are in /usr/include. Heck what does /usr stand for
anyway? It's not /krnl/include.
-- Steve
"Richard B. Johnson" <[email protected]> writes:
> Now, where is that 'auxiliary vevtor'??? I got a pointer to
> something to be executed before calling exit, I have an
> argument count, then a bunch of pointers (argv), terminating
> with a NULL, then another bunch of pointers (envp) terminating
> with a NULL. Is there something after that??? If so, what's
> the contents of this thing?
See create_elf_tables. The aux table comes after the environment.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, 2005-05-19 at 16:06 +0200, Andreas Schwab wrote:
> "Richard B. Johnson" <[email protected]> writes:
>
> > Now, where is that 'auxiliary vevtor'??? I got a pointer to
> > something to be executed before calling exit, I have an
> > argument count, then a bunch of pointers (argv), terminating
> > with a NULL, then another bunch of pointers (envp) terminating
> > with a NULL. Is there something after that??? If so, what's
> > the contents of this thing?
>
> See create_elf_tables. The aux table comes after the environment.
As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
which may not be the same as PAGE_SIZE.
-- Steve
On Thu, 19 May 2005, Steven Rostedt wrote:
> On Thu, 2005-05-19 at 16:06 +0200, Andreas Schwab wrote:
>> "Richard B. Johnson" <[email protected]> writes:
>>
>>> Now, where is that 'auxiliary vevtor'??? I got a pointer to
>>> something to be executed before calling exit, I have an
>>> argument count, then a bunch of pointers (argv), terminating
>>> with a NULL, then another bunch of pointers (envp) terminating
>>> with a NULL. Is there something after that??? If so, what's
>>> the contents of this thing?
>>
>> See create_elf_tables. The aux table comes after the environment.
>
> As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> which may not be the same as PAGE_SIZE.
>
> -- Steve
It's also hard to see what is happening in 'C'. When I execute
this:
#include <stdio.h>
#include <stdlib.h>
int main(int cnt, char *argv[], char *env[], char *aux[])
{
printf("Aux 0 = %s\n", aux[0]);
// printf("Aux 1 = %s\n", aux[1]);
}
I get:
Aux 0 = GLIBC_2.0
The next pointer is a NULL pointer, so 'C' has dorked something.
When I play in assembler, (crt.o startup) I get a pointer that
points to:
bffffb6c - pointer of the stack
00000020 - dereferenced
This shows that ld-linux.so, that got called first, didn't
preserve the vector.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Thu, 19 May 2005, Steven Rostedt wrote:
> > See create_elf_tables. The aux table comes after the environment.
>
> As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> which may not be the same as PAGE_SIZE.
Well, AT_PAGESZ is specified as "system page size". If we pass something
else, then it's asking for troubles. What comes from AT_PAGESZ is used by
userland for stuff like masking arguments for mmap() and mprotect() so
it'd better be the right value.
Maciej
On Thu, 2005-05-19 at 10:15 -0400, Steven Rostedt wrote:
> On Thu, 2005-05-19 at 16:06 +0200, Andreas Schwab wrote:
> > "Richard B. Johnson" <[email protected]> writes:
> >
> > > Now, where is that 'auxiliary vevtor'??? I got a pointer to
> > > something to be executed before calling exit, I have an
> > > argument count, then a bunch of pointers (argv), terminating
> > > with a NULL, then another bunch of pointers (envp) terminating
> > > with a NULL. Is there something after that??? If so, what's
> > > the contents of this thing?
> >
> > See create_elf_tables. The aux table comes after the environment.
>
> As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> which may not be the same as PAGE_SIZE.
and that is good!
Some architectures have different page sizes for different
personalities, eg ia64 has 16Kb for ia64 binaries but 4kb for x86
binaries. "kernel" PAGE_SIZE would be wrong to give to x86 userspace
there.
On Thu, 2005-05-19 at 15:43 +0100, Maciej W. Rozycki wrote:
> On Thu, 19 May 2005, Steven Rostedt wrote:
>
> > > See create_elf_tables. The aux table comes after the environment.
> >
> > As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> > which may not be the same as PAGE_SIZE.
>
> Well, AT_PAGESZ is specified as "system page size". If we pass something
> else, then it's asking for troubles. What comes from AT_PAGESZ is used by
> userland for stuff like masking arguments for mmap() and mprotect() so
> it'd better be the right value.
Well, they probably are the same, but then what's the reason for the
lines in binfmt_elf.c:
#if ELF_EXEC_PAGESIZE > PAGE_SIZE
# define ELF_MIN_ALIGN ELF_EXEC_PAGESIZE
#else
# define ELF_MIN_ALIGN PAGE_SIZE
#endif
This looks to me that ELF_EXEC_PAGESIZE and PAGE_SIZE may not be the
same. And what's passed to AT_PAGESZ is ELF_EXEC_PAGESIZE. In mips (as
your email address shows you are interested in) ELF_EXEC_PAGESIZE is
simply defined as PAGE_SIZE. But in intel i386, it is defined as 4096,
which coincidentally is the same as PAGE_SIZE but there's no guarantee
that this will be the same, unless who ever changes PAGE_SIZE also
remembers to change ELF_EXEC_PAGESIZE.
In arm26 the PAGE_SIZE is configurable (16k or 32k) but the
ELF_EXEC_PAGESIZE stays as 32k. So is this a bug?
-- Steve
On Thu, 19 May 2005, Arjan van de Ven wrote:
> > As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> > which may not be the same as PAGE_SIZE.
>
> and that is good!
> Some architectures have different page sizes for different
> personalities, eg ia64 has 16Kb for ia64 binaries but 4kb for x86
> binaries. "kernel" PAGE_SIZE would be wrong to give to x86 userspace
> there.
Well, as long as that value is what Linux expects (and respects!) for
calls like mprotect().
Maciej
On Thu, 2005-05-19 at 15:58 +0100, Maciej W. Rozycki wrote:
> On Thu, 19 May 2005, Arjan van de Ven wrote:
>
> > > As I stated earlier, the page size passed in there is ELF_EXEC_PAGESIZE
> > > which may not be the same as PAGE_SIZE.
> >
> > and that is good!
> > Some architectures have different page sizes for different
> > personalities, eg ia64 has 16Kb for ia64 binaries but 4kb for x86
> > binaries. "kernel" PAGE_SIZE would be wrong to give to x86 userspace
> > there.
>
> Well, as long as that value is what Linux expects (and respects!) for
> calls like mprotect().
and that is the 4Kb/16Kb difference!
so it needs to be per elf type.. which is what is there now ;)
"Richard B. Johnson" <[email protected]> writes:
> It's also hard to see what is happening in 'C'. When I execute
> this:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int cnt, char *argv[], char *env[], char *aux[])
> {
> printf("Aux 0 = %s\n", aux[0]);
> // printf("Aux 1 = %s\n", aux[1]);
> }
There is no pointer to the aux table passed to main, you have to skip past
the environment. Also, the aux table is an array of key/value pairs.
> This shows that ld-linux.so, that got called first, didn't
> preserve the vector.
It does.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, 2005-05-19 at 17:19 +0200, Andreas Schwab wrote:
> "Richard B. Johnson" <[email protected]> writes:
>
> > It's also hard to see what is happening in 'C'. When I execute
> > this:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> > int main(int cnt, char *argv[], char *env[], char *aux[])
> > {
> > printf("Aux 0 = %s\n", aux[0]);
> > // printf("Aux 1 = %s\n", aux[1]);
> > }
>
> There is no pointer to the aux table passed to main, you have to skip past
> the environment. Also, the aux table is an array of key/value pairs.
>
> > This shows that ld-linux.so, that got called first, didn't
> > preserve the vector.
>
> It does.
>
Here's a simple program to show you your pages size ;-), Now I don't
know enough about the elfinfo size and such to make this a real program,
but it should at least prove a point!
#include <stdio.h>
int main(int argc, char **argv, char **env)
{
int i;
long *p;
for (i=0; env[i]; i++);
p = (long*)(&env[i+1]);
for (i=0; i < 10; i++) {
long type = *p++;
if (type == 6)
printf("pagesz = 0x%lx (%ld)\n",*p,*p);
p++;
}
return 0;
}
-- Steve
On Thu, 19 May 2005, Andreas Schwab wrote:
> "Richard B. Johnson" <[email protected]> writes:
>
>> It's also hard to see what is happening in 'C'. When I execute
>> this:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int cnt, char *argv[], char *env[], char *aux[])
>> {
>> printf("Aux 0 = %s\n", aux[0]);
>> // printf("Aux 1 = %s\n", aux[1]);
>> }
>
> There is no pointer to the aux table passed to main, you have to skip past
> the environment. Also, the aux table is an array of key/value pairs.
>
>> This shows that ld-linux.so, that got called first, didn't
>> preserve the vector.
>
> It does.
>
> Andreas.
Well, the first entry is supposed to be AT_HWCAP, a number 16.
This is what I get:
long value
0 = 00000020
1 = ffffe400
2 = 00000021
3 = ffffe000
4 = 00000010 Seems to start here?
5 = bfebfbff Some bits
6 = 00000006 AT_PAGESZ
7 = 00001000 Correct
8 = 00000011 AT_CLKTCK
9 = 00000064 Correct
10 = 00000003
11 = 08048034
12 = 00000004
13 = 00000020
14 = 00000005
15 = 00000003
Nothing that makes any sense with the extra stuff in front.
I don't know where it came from.
>
> --
> Andreas Schwab, SuSE Labs, [email protected]
> SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Thu, 19 May 2005, Steven Rostedt wrote:
> On Thu, 2005-05-19 at 17:19 +0200, Andreas Schwab wrote:
>> "Richard B. Johnson" <[email protected]> writes:
>>
>>> It's also hard to see what is happening in 'C'. When I execute
>>> this:
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(int cnt, char *argv[], char *env[], char *aux[])
>>> {
>>> printf("Aux 0 = %s\n", aux[0]);
>>> // printf("Aux 1 = %s\n", aux[1]);
>>> }
>>
>> There is no pointer to the aux table passed to main, you have to skip past
>> the environment. Also, the aux table is an array of key/value pairs.
>>
>>> This shows that ld-linux.so, that got called first, didn't
>>> preserve the vector.
>>
>> It does.
>>
>
> Here's a simple program to show you your pages size ;-), Now I don't
> know enough about the elfinfo size and such to make this a real program,
> but it should at least prove a point!
>
> #include <stdio.h>
>
> int main(int argc, char **argv, char **env)
> {
> int i;
> long *p;
>
> for (i=0; env[i]; i++);
> p = (long*)(&env[i+1]);
> for (i=0; i < 10; i++) {
> long type = *p++;
> if (type == 6)
> printf("pagesz = 0x%lx (%ld)\n",*p,*p);
> p++;
> }
>
> return 0;
> }
>
> -- Steve
Well this just shows that the table is somewhere on the stack
after the environment.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Thu, 2005-05-19 at 11:58 -0400, Richard B. Johnson wrote:
>
> 0 = 00000020
> 1 = ffffe400
> 2 = 00000021
> 3 = ffffe000
> 4 = 00000010 Seems to start here?
> 5 = bfebfbff Some bits
> 6 = 00000006 AT_PAGESZ
> 7 = 00001000 Correct
> 8 = 00000011 AT_CLKTCK
> 9 = 00000064 Correct
> 10 = 00000003
> 11 = 08048034
> 12 = 00000004
> 13 = 00000020
> 14 = 00000005
> 15 = 00000003
>
> Nothing that makes any sense with the extra stuff in front.
> I don't know where it came from.
>
You forgot to include ARCH_DL_INFO which is defined in asm-i386/elf.h
as:
#define ARCH_DLINFO \
do { \
NEW_AUX_ENT(AT_SYSINFO, VSYSCALL_ENTRY); \
NEW_AUX_ENT(AT_SYSINFO_EHDR, VSYSCALL_BASE); \
} while (0)
AT_SYSINFO = 32 or 0x20 and AT_SYSINFO_EHDR = 33 or 0x21
-- Steve
On Thu, 19 May 2005, Steven Rostedt wrote:
> On Thu, 2005-05-19 at 11:58 -0400, Richard B. Johnson wrote:
>
>>
>> 0 = 00000020
>> 1 = ffffe400
>> 2 = 00000021
>> 3 = ffffe000
>> 4 = 00000010 Seems to start here?
>> 5 = bfebfbff Some bits
>> 6 = 00000006 AT_PAGESZ
>> 7 = 00001000 Correct
>> 8 = 00000011 AT_CLKTCK
>> 9 = 00000064 Correct
>> 10 = 00000003
>> 11 = 08048034
>> 12 = 00000004
>> 13 = 00000020
>> 14 = 00000005
>> 15 = 00000003
>>
>> Nothing that makes any sense with the extra stuff in front.
>> I don't know where it came from.
>>
>
> You forgot to include ARCH_DL_INFO which is defined in asm-i386/elf.h
> as:
>
> #define ARCH_DLINFO \
> do { \
> NEW_AUX_ENT(AT_SYSINFO, VSYSCALL_ENTRY); \
> NEW_AUX_ENT(AT_SYSINFO_EHDR, VSYSCALL_BASE); \
> } while (0)
>
> AT_SYSINFO = 32 or 0x20 and AT_SYSINFO_EHDR = 33 or 0x21
>
> -- Steve
Okay, good. At least I have the right vector. Now to find
a clean way to use it. The whole idea was to not have to
use kernel headers, BTW.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Arjan van de Ven wrote:
> HZ may not exist. At all; people are trying to remove it. And userspace
> has no business knowing about it either.
It can be helpful to know what HZ you are running at, for instance if you care
very much about the (average) precision of a select/poll timeout.
You can hack work-arounds to poor precision here using the /dev/rtc, but
it isn't fun...
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Thu, 2005-05-19 at 13:06 -0400, Richard B. Johnson wrote:
> >
> > You forgot to include ARCH_DL_INFO which is defined in asm-i386/elf.h
> > as:
> >
> > #define ARCH_DLINFO \
> > do { \
> > NEW_AUX_ENT(AT_SYSINFO, VSYSCALL_ENTRY); \
> > NEW_AUX_ENT(AT_SYSINFO_EHDR, VSYSCALL_BASE); \
> > } while (0)
> >
> > AT_SYSINFO = 32 or 0x20 and AT_SYSINFO_EHDR = 33 or 0x21
> >
> > -- Steve
>
> Okay, good. At least I have the right vector. Now to find
> a clean way to use it. The whole idea was to not have to
> use kernel headers, BTW.
>
The real question is whether or not getpagesize uses this? This should
be information that is passed to libc and not be something that the user
program uses directly. As you noticed, this vector is also architecture
specific, and should be only used by libc. I believe that the linker is
probably the driving factor for this information and not the kernel, so
the kernel headers should not be included.
-- Steve
BTW, I'm still not getting any direct email from you.
Ben Greear wrote:
> It can be helpful to know what HZ you are running at, for instance if
> you care
> very much about the (average) precision of a select/poll timeout.
If you move the binary to a different system (or upgrade the kernel, for
that matter) the assumptions can be totally wrong.
This should be checked at runtime, not compile time.
Chris
On Mer, 2005-05-18 at 22:31, Gilbert, John wrote:
> #JG
> Sorry, I was borrowing the term from the g++ error that this created.
> I'm not trying to imply that someone should be arrested. ;^) Also, like
> a few people have already mentioned, it doesn't effect the kernel at all
> as it's strictly a C program.
And that wants submitting to the GNU compiler people as a bug I guess ;)
MySQL using kernel headers is a bit sad given that the same macros were
put into proper user mode headers and under even more open licenses by
the Mozilla people with Linus permission.
DRI one does seem to be a real bug.
Alan
Chris Friesen wrote:
> Ben Greear wrote:
>
>> It can be helpful to know what HZ you are running at, for instance if
>> you care
>> very much about the (average) precision of a select/poll timeout.
>
>
> If you move the binary to a different system (or upgrade the kernel, for
> that matter) the assumptions can be totally wrong.
>
> This should be checked at runtime, not compile time.
If course...that is why I like the idea of some system call or standard API
to get the information.
Ben
>
> Chris
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Mer, 2005-05-18 at 22:31, Gilbert, John wrote:
> #JG
> Sorry, I was borrowing the term from the g++ error that this created.
> I'm not trying to imply that someone should be arrested. ;^) Also,
> like a few people have already mentioned, it doesn't effect the kernel
> at all as it's strictly a C program.
#Alan Cox
And that wants submitting to the GNU compiler people as a bug I guess ;)
MySQL using kernel headers is a bit sad given that the same macros were
put into proper user mode headers and under even more open licenses by
the Mozilla people with Linus permission.
DRI one does seem to be a real bug.
#JG
Would that be the drm.h use of "virtual", or the lack of an standard
interrupt driven vertical sync interface?
If it's the later, I know of hundreds, if not thousands of programs that
would greatly benefit from such a feature. This, coupled with Andrew
Morton's low latency patch and the already available high resolution
timer support, and Linux could quickly become the multi-media king of
operating systems (not to mention gaming).
Thanks.
John Gilbert
[email protected]
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.
Ben Greear <[email protected]> writes:
> Chris Friesen wrote:
>> Ben Greear wrote:
>>
>>> It can be helpful to know what HZ you are running at, for instance if
>>> you care
>>> very much about the (average) precision of a select/poll timeout.
>> If you move the binary to a different system (or upgrade the kernel, for
>> that matter) the assumptions can be totally wrong.
>> This should be checked at runtime, not compile time.
>
> If course...that is why I like the idea of some system call or standard API
> to get the information.
sysconf(3)
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On 05.20, Andreas Schwab wrote:
> Ben Greear <[email protected]> writes:
>
> > Chris Friesen wrote:
> >> Ben Greear wrote:
> >>
> >>> It can be helpful to know what HZ you are running at, for instance if
> >>> you care
> >>> very much about the (average) precision of a select/poll timeout.
> >> If you move the binary to a different system (or upgrade the kernel, for
> >> that matter) the assumptions can be totally wrong.
> >> This should be checked at runtime, not compile time.
> >
> > If course...that is why I like the idea of some system call or standard API
> > to get the information.
>
> sysconf(3)
>
Yup, I do it to start a thread per core.
Stupid and portable C++ code follows:
//! Node Information
__class Node {
private:
static void init();
public:
//! Node name
static char name[MAXNAMLEN];
//! Node model name
static char model[MAXNAMLEN];
//! Node hardware architecture
static char arch[MAXNAMLEN];
//! Node Operating Node name
static char osname[MAXNAMLEN];
//! Node Operating Node release
static char osrel[MAXNAMLEN];
//! Node memory
static int ram;
//! Node number of available processors
static int nproc;
};
#ifdef __UNX__
# include <unistd.h>
# ifdef sgi
# include <sys/systeminfo.h>
# include <invent.h>
# endif
# ifdef __linux__
# include <sys/sysinfo.h>
# endif
# ifdef sun
# include <sys/systeminfo.h>
# endif
# ifdef __hpux
extern "C" {
# include <sys/mpctl.h>
}
# endif
#endif
int Node::inited = 0;
char Node::name[MAXNAMLEN];
char Node::model[MAXNAMLEN];
char Node::arch[MAXNAMLEN];
char Node::osname[MAXNAMLEN];
char Node::osrel[MAXNAMLEN];
int Node::ram;
int Node::nproc;
void Node::init()
{
if (inited) return;
nproc = 1;
ram = 0;
#if defined(__UNX__)
struct utsname sys;
uname(&sys);
strcpy(name,sys.nodename);
strcpy(model,sys.machine);
strcpy(osname,sys.sysname);
strcpy(osrel,sys.release);
# ifdef sgi
sysinfo(SI_ARCHITECTURE,arch,MAXNAMLEN);
nproc = sysconf(_SC_NPROC_ONLN);
inventory_t* ip;
while (ip=getinvent())
{
if ((ip->inv_class==INV_MEMORY) && (ip->inv_type==INV_MAIN))
ram = ip->inv_state;
}
endinvent();
# endif
# ifdef sun
sysinfo(SI_ARCHITECTURE,arch,MAXNAMLEN);
nproc = sysconf(_SC_NPROCESSORS_ONLN);
ram = sysconf(_SC_PAGESIZE)*sysconf(_SC_PHYS_PAGES);
# endif
# ifdef __linux__
strcpy(arch,"x86");
nproc = sysconf(_SC_NPROCESSORS_ONLN);
if (!nproc) nproc = 1;
ram = sysconf(_SC_PAGESIZE)*sysconf(_SC_PHYS_PAGES);
# endif
# ifdef __hpux
strcpy(arch,"PA-RISC");
nproc = mpctl(MPC_GETNUMSPUS,0,0);
ram = 0; // TODO...
# endif
#elif defined(__WIN__)
DWORD len=MAXNAMLEN;
GetComputerNameA(name,&len);
strcpy(model,"Intel");
SYSTEM_INFO sys;
GetSystemInfo(&sys);
nproc = sys.dwNumberOfProcessors;
sprintf(arch,"i%d86",sys.wProcessorLevel);
MEMORYSTATUS minfo;
GlobalMemoryStatus(&minfo);
ram = minfo.dwTotalPhys;
OSVERSIONINFO osver;
osver.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osver);
int relmaj = osver.dwMajorVersion;
int relmin = osver.dwMinorVersion;
switch(osver.dwPlatformId)
{
case VER_PLATFORM_WIN32s:
strcpy(osname,"Win3.1");
break;
case VER_PLATFORM_WIN32_WINDOWS:
sprintf(osname,"Win9%c",(relmin>0 ? '8' : '5'));
break;
case VER_PLATFORM_WIN32_NT:
strcpy(osname,"WinNT");
break;
default:
strcpy(osname,"Win??");
}
sprintf(osrel,"%d.%d (build %d) %s",
relmaj,relmin,osver.dwBuildNumber,osver.szCSDVersion);
#else
strcpy(name,"Unknown");
strcpy(model,"Unknown");
strcpy(arch,"Unknown");
strcpy(osname,"Unknown");
strcpy(osrel,"?.?");
#endif
inited = 1;
info();
}
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.11-jam19 (gcc 4.0.0 (4.0.0-3mdk for Mandriva Linux release 2006.0))
On Thu, May 19, 2005 at 10:30:32PM +0000, J.A. Magallon wrote:
> Stupid and portable C++ code follows:
>...
> # ifdef __linux__
> strcpy(arch,"x86");
These two appear to be self-contradictory, unless you define "portable"
to mean "x86 only"... which would be hardly portable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On 05.20, Russell King wrote:
> On Thu, May 19, 2005 at 10:30:32PM +0000, J.A. Magallon wrote:
> > Stupid and portable C++ code follows:
> >...
> > # ifdef __linux__
> > strcpy(arch,"x86");
>
> These two appear to be self-contradictory, unless you define "portable"
> to mean "x86 only"... which would be hardly portable.
>
Yup, portable to what I needed to port it ;). Will be refined...
It was just a note about how to get info about ram, cpu, os and so on.
Probably soft (MySQL) that needs to know on what processors is being built
just needs to know on how many is being run to start a thread on each one,
or know about the ram to size its caches...
At build time, cpp -dM /dev/null:
linux-x86:
#define i386 1
#define __i386 1
#define __i386__ 1
#define __tune_pentium__ 1
#define __tune_i586__ 1
darwin-ppc:
#define __ppc__ 1
But the interesting part would be how to know at runtime on what
processor I'm running. Will have to look at x86info...
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.11-jam19 (gcc 4.0.0 (4.0.0-3mdk for Mandriva Linux release 2006.0))
At 5/19/2005 23:10 +0000, J.A. Magallon wrote:
>But the interesting part would be how to know at runtime on what processor
>I'm running. Will have to look at x86info...
This statement is semantically void. If you were given a hypothetical
current_proc_id() function that would tell you, because a userland process
can (and normally *will*) be rescheduled at any time from one processor to
another, by the time the hypothetical function returns it's answer it may
be incorrect. What use would that be?
--
Jeff Woods <[email protected]>
Ben Greear wrote:
> Arjan van de Ven wrote:
>
>> HZ may not exist. At all; people are trying to remove it. And userspace
>> has no business knowing about it either.
>
>
> It can be helpful to know what HZ you are running at, for instance if
> you care
> very much about the (average) precision of a select/poll timeout.
>
Will knowing it help? You may find out that you don't have much precision,
but then theres nothing to do about it. And there may not even be a HZ,
as mentioned. Less cpu is used if there is no periodic interrupts when
there is nothing to do. People are trying to *not* have a regular timer
interrupt; instead, a one-shot timer can be programmed for the next
necessary timeout which may very well be quite a few "ticks" into
the future. In this case there is no notion of HZ at all.
Helge Hafting
>
> DRI one does seem to be a real bug.
Well not a bug :-) but lets call it a C++ incompatibility .. I'll see
how much work it is to change this everywhere it is used.. I don't
really want to break loads of userspace apps.. not that many drm apps
exist.. and probably very few of them use the virtual pointer...
Dave.
On Thu, 19 May 2005, Steven Rostedt wrote:
> Well, they probably are the same, but then what's the reason for the
> lines in binfmt_elf.c:
>
> #if ELF_EXEC_PAGESIZE > PAGE_SIZE
> # define ELF_MIN_ALIGN ELF_EXEC_PAGESIZE
> #else
> # define ELF_MIN_ALIGN PAGE_SIZE
> #endif
>
>
> This looks to me that ELF_EXEC_PAGESIZE and PAGE_SIZE may not be the
> same. And what's passed to AT_PAGESZ is ELF_EXEC_PAGESIZE. In mips (as
> your email address shows you are interested in) ELF_EXEC_PAGESIZE is
> simply defined as PAGE_SIZE. But in intel i386, it is defined as 4096,
And for MIPS PAGE_SIZE is also variable (currently one of: 4k, 16k, 64k).
> which coincidentally is the same as PAGE_SIZE but there's no guarantee
> that this will be the same, unless who ever changes PAGE_SIZE also
> remembers to change ELF_EXEC_PAGESIZE.
That's the maintainer's problem.
> In arm26 the PAGE_SIZE is configurable (16k or 32k) but the
> ELF_EXEC_PAGESIZE stays as 32k. So is this a bug?
I guess so. Unless these smaller pages are always handled in pairs by
Linux. That would be a legitimate case of ELF_EXEC_PAGESIZE != PAGE_SIZE.
Maciej
> Well not a bug :-) but lets call it a C++ incompatibility .. I'll see
> how much work it is to change this everywhere it is used.. I don't
> really want to break loads of userspace apps.. not that many drm apps
> exist.. and probably very few of them use the virtual pointer...
You don't have to change it - its possible to use ifdefs for C++ to
change the name only for C++ usage.
On Fri, 2005-05-20 at 11:27 +0200, Helge Hafting wrote:
> Ben Greear wrote:
>
> > Arjan van de Ven wrote:
> >
> >> HZ may not exist. At all; people are trying to remove it. And userspace
> >> has no business knowing about it either.
> >
> >
> > It can be helpful to know what HZ you are running at, for instance if
> > you care
> > very much about the (average) precision of a select/poll timeout.
> >
> Will knowing it help? You may find out that you don't have much precision,
> but then theres nothing to do about it.
Yes, it will. If you have an RT constraint and 10ms won't cut it (say,
you want to send MIDI clock) then you can use the RTC.
Lee
Lee Revell wrote:
> On Fri, 2005-05-20 at 11:27 +0200, Helge Hafting wrote:
>
>>Ben Greear wrote:
>>
>>
>>>Arjan van de Ven wrote:
>>>
>>>
>>>>HZ may not exist. At all; people are trying to remove it. And userspace
>>>>has no business knowing about it either.
>>>
>>>
>>>It can be helpful to know what HZ you are running at, for instance if
>>>you care
>>>very much about the (average) precision of a select/poll timeout.
>>>
>>
>>Will knowing it help? You may find out that you don't have much precision,
>>but then theres nothing to do about it.
>
>
> Yes, it will. If you have an RT constraint and 10ms won't cut it (say,
> you want to send MIDI clock) then you can use the RTC.
Right. For instance, before I found the 1000 HZ patch for the 2.4
kernel I would set the RTC to tick 1024 times a second, and then add
that FD to my select() fd-sets. That causes select to return after about
1ms, and I could do this in a loop to get the X ms of sleep that I needed.
This is not as nice as having a clean 1ms tick clock, but it's a hell of
a lot better than a full busy spin...
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hello Dave,
I've already searched through the 2.6.11+ kernels, it's only used in
drm_bufs.c and drm.h (see previous patches). I can't vouch for any
applications, I probably should look through xorg at least (although a
name change won't effect binaries).
John Gilbert
[email protected]
-----Original Message-----
From: Dave Airlie [mailto:[email protected]]
Sent: Friday, May 20, 2005 4:50 AM
To: Alan Cox
Cc: Gilbert, John; Linux Kernel Mailing List
Subject: Re: Illegal use of reserved word in system.h
>
> DRI one does seem to be a real bug.
Well not a bug :-) but lets call it a C++ incompatibility .. I'll see
how much work it is to change this everywhere it is used.. I don't
really want to break loads of userspace apps.. not that many drm apps
exist.. and probably very few of them use the virtual pointer...
Dave.
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.