> Does the notion of a kernel module have ANY merit at all? Or was the idea > complete garbage?
Obviously your idea isn't complete rubbish, but you are preaching to a very particular crowd, so you need to make sure you're ideas aren't contrary to their personal biases, sad isn't it? Ok, now that we have that over with, on with my response. I think the concept of having kernel modules handling some tasks has merit, but two things should smack you in the face whenever you conceder it. Note, DRI is basically what you are looking for, but I like to rant, so here goes: 1. Portability Since the module would have to be kernel dependent, porting an XServer to another platform becomes difficult. It is already difficult enough to support new platforms as it is in X. The stipulation to get into XFree is that any platform dependent changes to the server must be optional. If the functionality you are requesting applies to changing the baseline X Server, you better make sure that it works on all the platforms Xfree Supports, which is a lot. The way I read your comment, it seemed like a broad strokes change to the entire system. 2. Change Control If you know anything about Xfree86, you will see that the maintainers don't like to depend on code externally. Making a kernel module, you are taking the ability of the XFree developers to have total control over the timing and release procedures of the module. This is also a bad candidate for versioning incompatibilities inside the current iteration of the system. <soap_box flame_rating="100%"> I really with that there were more "well defined API's" in Xfree which would mitigate any need for compiling module X for server Y. It is really stifling to work with an open source system that only introduces changes once a year. I am not talking about the X Protocol specs, but the basic building blocks of the server itself. It would be nice to add a newly developed extension, form of encryption, or whatever without having to get everything rebuilt for me. Following the comments from a previous commenter, X is too big for mear mortals to manage is a whole, and it'd be better IMHO to see some basic separation put in, and have some document like "the architecture and framework of the Xfree86 server" which ties all the discrete parts together. I can only imagine that the original goal of Xfree86 was to make a fully self-contained X server to compete with the big guys in the market. The problem is that today there are throngs of people making things in the user / toolkit space that are now redundant with those in Xfree and barely maintained. An example breakup for binary releases: Xfree86 Server Xfree86 Server feature <insert feature here> Xfree86 Server module <insert module here> XFree86 Client Xfree86 Common XFree86 Client Tools Xfree86 Server Devel Xfree86 Client Devel Xfree86 Common Devel XFree86 Fonts How you define features is sadly ambigious, maybe something a little broader than just X extensions. This may never be possible with Xfree's architecture, I am not versed enough to make a call. Core system changes are fine at 1 year, Feature updates can be released quarterly, Driver releases should be monthly Of course the implementation of such a scheme involves a lot discussion larger than my soap box. </soap_box> _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
