On Thu, 2003-09-11 at 14:35, David Dawes wrote:
> What's the difference between this in the core executable:
>
> xf86A(pointer data)
> {
> return A(data);
> }
>
> SYMFUNC(xf86A)
>
> and this:
>
> SYMFUNCALIAS(xf86A, A)
The difference is that xf86A may massage "data" in some system specific
manner specific to the libraries the main executable is linked against.
Examples might include parameters to mmap where the base address and
size have to be adjusted for page boundaries and the mapping flags
passed. Or anything passed into an ioctl. I don't think the current set
of wrapped functions includes anything of this nature, but I thought it
was the principle behind it.
> Module independence comes from providing a more uniform ABI to the
> modules than you might get by linking directly with the functions provided
> by the system libraries.
Isn't that what I'm saying above? Xfree86 imposes its own interface
leaving the wrappers to translate when the underlying system differs.
Perhaps just as importantly since the wrappers are in the main
executable, which is the ONLY place loadable object dependencies are
enforced, its the only place you can be guaranteed that you'll be linked
to the version of shared object you're expecting!
> >If I following your reasoning then you would be happy with this
> >definition in xf86_libc.h
> Yes.
O.K. I'll make this patch and put it in the bugzilla. I'm not completely
happy with it because its not really addressing the root problem. Setjmp
may "blow up" on some other system in the future because we're ignoring
the system defined requirements. For example in the non-ia64 case
xf86jmp_buf will only be aligned on int boundaries, what if a system
needs long alignment, or some other requirement?
> I'll grant that what we're going with setjmp is a little hairy, but I
> haven't seen anything so far that says the basic approach doesn't work
> or impacts the portability of modules.
Yes, you are right setjmp is a true exception because it can't be
wrapped and thus isolate system specifics outside the module. And you're
also right its a bit hairy, it took me a while to fully understand
exactly what was going on.
As for impacting portability of modules, why isn't the following true?
libc version 1.0 requires 8 byte alignment, server XFree86 A is linked
against this library.
libc version 1.1 requires 16 byte alignment, server XFree86 B is linked
against this library.
The module in "theory" can be loaded into either XFree86 server A or B.
If the module was built against the libc 1.0 requirement it will fail
when loaded into XFree86 B. This is because unlike the system loader
which enforces the right version of the library to be loaded when
XFree86 is loaded by the system, the module loader does not deal with
version dependencies. In part because the version dependencies in theory
have been isolated in the main executable image via wrappers and
enforced by the system loader. The current setjmp implementation
violates all these assumptions which is why I conclude this negatively
impacts module portability. It is also true that if setjmp were in a
wrapper the module could be loaded into XFree86 server A or B without
issue, but thats not the case, it will crash the server if loaded in
XFree86 server B.
Granted, if we are lucky this may never bite us, there is a reasonable
chance it won't, but on the other hand to assert we haven't lost module
independence and portability is not being honest about the new situation
with modules that import xf86set_jmp.
I'm not saying I have an answer to the problem we've created for
ourselves, but I am saying we need to be honest about the impact, that
any module that imports xf86set_jmp is no longer portable, is tied the
libraries the main XFree86 is linked against, and as such we might as
well use the system definitions of jmp_buf because its the robust
solution and is no more, no less portable than inventing a jmp_buf
abstraction that inherently is not robust. So if you're not getting
portability and independence with the abstraction why sacrifice
robustness?
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
