On Fri, 17 Oct 2003, David Fox wrote: >I think that the wisest approach is, instead of suggesting a kernel >module to the XFree86 folks, you do two things. First, suggest a kernel >module to the Linux folks that implements a protocol for accessing the >resource you are trying to use. Then you go to the XFree86 folks and >suggest a module to utilize that protocol in the X server.
That's not any better. Unless someone comes up with a real problem that isn't just theoretical, and a real solution which requires or will work best being in kernel, and then implements it, and puts their money where their mouth is and proves that the solution not only works, but solves a real problem / really does improve performance, etc. they're not going to be taken seriously. You just aren't going to get anywhere with random hypothetical guesses as to what will be a magic performance boost until you crack out the tools to find performance hits, and write the code to fix them. If that can be done in XFree86 itself - great. If it can be done in the kernel, fine. If it can be done in XFree86 without requiring the kernel, and done as well or better in XFree86, even better, as then reliance on a random OS's kernel module is avoided. The kernel folk are going to tell you the same thing - that you dont just go and implement random code in the kernel and hope it fixes something. You find a problem, and you investigate potential solutions to it. If that involves the kernel - fine. Then you come to both the X developers and the kernel developers (of the particular OS kernel) and say something to the effect of: "My following attached patch that implements foo in the Linux (or BSD or whatever) kernel, and an appropriate patch for XFree86 which uses this functionality optionally is attached. I've done performance tests on <foobedoo> in X and have determined it isn't possible to improve the performance of foobedoo without an additional kernel interface. My kernel interface implements this, and does so as cleanly as I could devise. The performance gain in fooblahblah applications is n% so this is definitely worth it and not just a negligible gain. I'm interested on hearing what other developers think of the patch I have created, and what feedback they can give so I can improve it, or try alternate methods." Or something to that effect. As I said before, making random suggestions to use kernel modules abstractly like it's a godsend for performance isn't going to get anyone anywhere, wether their intentions are extremely wll intentioned or not. So to take the whole topic out of the pie-in-the-sky land, and put it on the concrete ground: What _specific_ area of XFree86 performance are you (or anyone else) thinking needs improvement, what solutions have you investigated or even thought about which could improve this performance by modifying XFree86 itself, a driver, Mesa, or other userland code? If you do think the kernel might help for this problem, what steps have you taken to determine if that is truely reasonable, and have you tested your theory? Have you discussed that one small idea with other developers to see what they think about the alleged problem, wether it even really is a problem at all, how important it is, what other solutions there might be, etc. etc. etc. All of this "lets stuff things in the kernel, because kernel code is automatically 20000 times faster right?" stuff gets boring fast. Show me the code. -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
