> This scheme doesn't work with dlloader. The current dlloader is only > useful for debugging purposes and for special cases (like the glide > driver) where an external shared library is needed.
Why doesnt the scheme work though, the interface to the module is only redefined in 3 drivers, and still I cant see how the differences effect the usage in regards to loading necesary modules / libraries. > Maybe dlloader could be rewritten to do the actual loading internally > instead of using system-provided dlopen()/dlsym(), and achieve the same > symbol resolution semantics as the other loaders. What im basically trying to do is eliminate the calls to malloc as this causes an execution on the heap, something that will not work under the enhanced security of this system. > Looking into this is on my todo list, but I'm interested in it more from > the point of view of allowing modules better access to interfaces provided > by external shared libraries. Thats fine but essentially it comes down to determining what to load without the user having to specify this manually, which is where the current dlloader model breaks down. Andrew Bevitt _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
