On Mon, Jan 19, 2004 at 02:23:08PM +1100, Andrew Bevitt wrote: >> 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.
What happens when you try it? The driver load fails because of unresolved dependencies. The other loaders don't care about this. The driver knows which of the dependencies it will actually use for any given invocation, and asks for them to be loaded. >> 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. Maybe using mmap() instead of malloc() in elfloader will be enough to achieve this in your case? I'm not sure if that's enough for all of the security methods that restrict what pages may be made executable. For that you probably need PIC code with the text sections mmapped read-only, which is what dlopen() would do. >> 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. The XFree86 loader model doesn't have this problem because the drivers load their immediate dependencies without any user intervention. The dlloader component doesn't function in this way because it is restricted by the behaviour of the system-provided dlopen(). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
