Both x86 and ia64 now provide a dynamically shared object (DSO) for
system call purposes (e.g., to speed up system calls and for signal
trampoline/sigreturn purposes). At the moment, the names of these
DSOs are different:
x86: linux-vsyscall.so.1
ia64: linux-gate.so.1
I think there is some value in using the same name on all platforms
that support such a DSO. vsyscall makes no sense for ia64, since
there are no virtual syscalls (instead, ia64 linux provides a fast
system call convention which, when coupled with light-weight system
call handlers, provide full syscall semantics at more or less the
speed of virtual system calls).
Not surprisingly, I like the name "linux-gate", since that is really
what this DSO is all about: it's a gateway between user and kernel
space. However, if this name isn't appropriate for x86, perhaps we
can find another name which will be acceptable to everybody.
I already checked with Roland McGrath (cc'd), and he agrees that a
common name would be good and said that he doesn't care about the
particular name that will be used.
Does anyone have any strong feelings about this? If not, I plan to
submit a patch to rename the x86 DSO to linux-gate.so.1.
Thanks,
--david
On Wed, Jun 18, 2003 at 12:12:21PM -0700, David Mosberger wrote:
> Not surprisingly, I like the name "linux-gate", since that is really
> what this DSO is all about: it's a gateway between user and kernel
> space. However, if this name isn't appropriate for x86, perhaps we
> can find another name which will be acceptable to everybody.
Hi David.
I see no clean way to share the rules between the architectures,
at least not without doing something very special for this.
The second best alternative is to have the same implementation
in all architectures supporting this, so my vote goes for the
gate name.
PS. One day I hope to find a better solution for the gross ld_flags hack..
Sam
>>>>> On Wed, 18 Jun 2003 22:32:47 +0200, Sam Ravnborg <[email protected]> said:
Sam> I see no clean way to share the rules between the architectures,
Sam> at least not without doing something very special for this.
Yes. I think that's OK.
Sam> The second best alternative is to have the same implementation
Sam> in all architectures supporting this, so my vote goes for the
Sam> gate name.
OK, noted.
--david
>>>>> On Wed, 18 Jun 2003 22:32:47 +0200, Sam Ravnborg <[email protected]> said:
Sam> so my vote goes for the gate name.
Attached is a small patch which will at least make sure that the DSO
name is the same across platforms.
Is someone willing to shepherd this patch into the official 2.5 tree?
--david
===== arch/i386/kernel/Makefile 1.44 vs edited =====
--- 1.44/arch/i386/kernel/Makefile Sun Jun 8 11:06:55 2003
+++ edited/arch/i386/kernel/Makefile Wed Jun 18 15:47:48 2003
@@ -47,7 +47,7 @@
cmd_syscall = $(CC) -nostdlib $(SYSCFLAGS_$(@F)) \
-Wl,-T,$(filter-out FORCE,$^) -o $@
-vsyscall-flags = -shared -s -Wl,-soname=linux-vsyscall.so.1
+vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1
SYSCFLAGS_vsyscall-sysenter.so = $(vsyscall-flags)
SYSCFLAGS_vsyscall-int80.so = $(vsyscall-flags)
David Mosberger <[email protected]> wrote:
>
> +++ edited/arch/i386/kernel/Makefile Wed Jun 18 15:47:48 2003
> @@ -47,7 +47,7 @@
> cmd_syscall = $(CC) -nostdlib $(SYSCFLAGS_$(@F)) \
> -Wl,-T,$(filter-out FORCE,$^) -o $@
>
> -vsyscall-flags = -shared -s -Wl,-soname=linux-vsyscall.so.1
> +vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1
What happens if one architecture decides to take this up to
linux-gate.so.2? If that is even a legit thing to do.
>>>>> On Wed, 18 Jun 2003 16:35:51 -0700, Andrew Morton <[email protected]> said:
Andrew> David Mosberger <[email protected]> wrote:
>> +++ edited/arch/i386/kernel/Makefile Wed Jun 18 15:47:48 2003 @@
>> -47,7 +47,7 @@ cmd_syscall = $(CC) -nostdlib $(SYSCFLAGS_$(@F)) \
>> -Wl,-T,$(filter-out FORCE,$^) -o $@
>>
>> -vsyscall-flags = -shared -s -Wl,-soname=linux-vsyscall.so.1
>> +vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1
Andrew> What happens if one architecture decides to take this up to
Andrew> linux-gate.so.2? If that is even a legit thing to do.
Beats me. Roland?
--david
Followup to: <[email protected]>
By author: David Mosberger <[email protected]>
In newsgroup: linux.dev.kernel
>
> Both x86 and ia64 now provide a dynamically shared object (DSO) for
> system call purposes (e.g., to speed up system calls and for signal
> trampoline/sigreturn purposes). At the moment, the names of these
> DSOs are different:
>
> x86: linux-vsyscall.so.1
> ia64: linux-gate.so.1
>
> I think there is some value in using the same name on all platforms
> that support such a DSO. vsyscall makes no sense for ia64, since
> there are no virtual syscalls (instead, ia64 linux provides a fast
> system call convention which, when coupled with light-weight system
> call handlers, provide full syscall semantics at more or less the
> speed of virtual system calls).
>
> Not surprisingly, I like the name "linux-gate", since that is really
> what this DSO is all about: it's a gateway between user and kernel
> space. However, if this name isn't appropriate for x86, perhaps we
> can find another name which will be acceptable to everybody.
>
It's a pretty ugly name, quite frankly, since it doesn't explain what
it is a gate from or to. linux-syscall.so.1 or linux-kernel.so.1
would make a lot more sense.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
>>>>> On 18 Jun 2003 23:18:02 -0700, "H. Peter Anvin" <[email protected]> said:
HPA> It's a pretty ugly name, quite frankly, since it doesn't explain what
HPA> it is a gate from or to. linux-syscall.so.1 or linux-kernel.so.1
HPA> would make a lot more sense.
Umh, it does say _linux_-gate, so I think it's pretty
self-explanatory. I considered linux-kernel.so, but think it would
cause a lot of confusion vis-a-vis, say, kernel32.dll (I didn't write
that, did I??). I'm not terribly fond of linux-syscall, but I could
live with it.
--david
David Mosberger wrote:
>>>>>>On 18 Jun 2003 23:18:02 -0700, "H. Peter Anvin" <[email protected]> said:
>
>
> HPA> It's a pretty ugly name, quite frankly, since it doesn't explain what
> HPA> it is a gate from or to. linux-syscall.so.1 or linux-kernel.so.1
> HPA> would make a lot more sense.
>
> Umh, it does say _linux_-gate, so I think it's pretty
> self-explanatory. I considered linux-kernel.so, but think it would
> cause a lot of confusion vis-a-vis, say, kernel32.dll (I didn't write
> that, did I??). I'm not terribly fond of linux-syscall, but I could
> live with it.
>
There is a lot of "linux" in userspace too, though. ld-linux.so.* to
start out with...
-hpa
>>>>> On Wed, 18 Jun 2003 23:46:25 -0700, "H. Peter Anvin" <[email protected]> said:
HPA> There is a lot of "linux" in userspace too, though. ld-linux.so.* to
HPA> start out with...
Of course, those should be ld-gnu-linux.so.*
Ducking for cover now... ;-)
--david
H. Peter Anvin wrote:
> It's a pretty ugly name, quite frankly, since it doesn't explain what
> it is a gate from or to. linux-syscall.so.1 or linux-kernel.so.1
> would make a lot more sense.
linux-syscall.so.1 makes most sense to me.
It's the only one which is correct and unambiguous.
-- Jamie
>>>>> On Thu, 19 Jun 2003 21:20:19 +0200, Jamie Lokier <[email protected]> said:
Jamie> H. Peter Anvin wrote:
>> It's a pretty ugly name, quite frankly, since it doesn't explain
>> what it is a gate from or to. linux-syscall.so.1 or
>> linux-kernel.so.1 would make a lot more sense.
Jamie> linux-syscall.so.1 makes most sense to me.
Jamie> It's the only one which is correct and unambiguous.
It's not really correct. The DSO can be used for up-calls (e.g.,
signal trampolines), too.
Like I said, I can _live_ with "syscall", but would prefer "gate",
because it's technically more accurate. It's also shorter, always a
bonus... ;-)
--david
Hi!
> HPA> It's a pretty ugly name, quite frankly, since it doesn't explain what
> HPA> it is a gate from or to. linux-syscall.so.1 or linux-kernel.so.1
> HPA> would make a lot more sense.
>
> Umh, it does say _linux_-gate, so I think it's pretty
> self-explanatory. I considered linux-kernel.so, but think it would
> cause a lot of confusion vis-a-vis, say, kernel32.dll (I didn't write
> that, did I??). I'm not terribly fond of linux-syscall, but I could
> live with it.
I agree with hpa, linux-syscall seems to be best so far.
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
> Andrew> What happens if one architecture decides to take this up to
> Andrew> linux-gate.so.2? If that is even a legit thing to do.
>
> Beats me. Roland?
As I said in my original posting of the i386 vsyscall DSO changes, nothing
as yet makes any use of the soname, version set name, or symbol names. So
at the moment you can change them to linux-mergatroid.so.23, LIGNUX_7.9,
and _StUdLy_KeRnEl_vSyScAlL et al, and Nothing Happens (well, with the
middle of those three I have a feeling *something* would happen to
*somebody* ;->).
My expectation is that if and when anything makes use of any of these
names, they will be used in the same way a normal userland DSO is used.
The namespace for sonames is considered machine-specific, though usually
kept in synch across machines when the source APIs are the same or nearly so.
The namespace for version sets is local to the soname of the containing DSO,
though likewise usually assigned in a machine-independent fashion.
sonames should be something it's reasonable to use as a file name in /lib.
Version set names are just arbitrary symbols compared for identity, and can
encode kernel version numbers or dates if you like, or not if you don't.
People see them and will want to know what set of kernels supplies a DSO
containing that set, so kernel version numbers make sense. But you can do
whatever floats your boat.
If a machine changes its kernel DSO's ABI it has two options. It can keep
the same soname, and provide compatibility entry points for the previous
ABI using the same version set name, and provide newly-flavored entry
points with a new version set name. Or it can change the soname, start
over with whatever version set name floats its boat, and not worry about
compatibility. In that case, compatibility for existing dependencies can
be provided by a normal user-level DSO stored in a regular file by the name
of the old soname. e.g., linux-mergatroid.so.22 can be a user-level
wrapper DSO that works by linking against the new linux-mergatroid.so.23
provided by the new kernel and calling its entry points after whatever
appropriate calling convention fixup is required.
If these DSO ABIs evolve independently for each machine, it doesn't make
particular sense to coordinate the soname changes between them. I mean,
using a common name prefix is wise just so people understand they are all
being used in the same way, but having the trailing number correlate across
machines only makes sense if there is some correlation with the DSO's API
changes across machines.
You'll note I haven't really told you what to do. If there is anything
else I can make more clear about how best to decide what to do, please ask.
Btw, I still don't care what names are used for anything, but
"linux-gate.so.1" sounds particularly stupid to me. (What is that, the big
scandal about that time the President hired some hamfisted goons with
taxpayer's money to violate the GPL for personal gain and sexual favors?)
"linux-kernel.so.1" is the least stupid name I have thought of (and that
still seems kind of stupid).
Enjoy,
Roland