Tiago Vignatti wrote:
> And regarding the patch you sent, I think it doesn't matter the name of the os
> module dir, given fbdevhw.so is sort of "portable" due the stubs version.
> Maybe we could even move it one directory above. Yeah, the ugliness is
> reigning here! :D

As far as I know the module loader's support for loading modules from subdirs
named for the OS is a holdover from the original cross-OS dream of the XFree86
custom module loader, where that would be the rare exception using OS specific
calls to kernel or libc functionality.

I also don't know any reason not to move it out of the OS-specific libdir and
up to the generic modules directory, now that all modules there use the OS'es
actual libc & system calls instead of the libcwrappers.

ajax had suggested this solution on IRC as it would be a no-op for Linux
builders and just fix other OS'es, but we didn't discuss just moving up a
level instead - which then raises the question of if there's any point having
the module loader waste time doing all those extra stat() calls during module
loading to find modules in OS-specific subdirs in a post-libcwrap Xorg.

-- 
        -Alan Coopersmith-        [email protected]
         Oracle Solaris Platform Engineering: X Window System

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to