Joshua C. wrote: > ok guys, > > then it is up to whether the patch is "clean" enough to go in the > mainstream kernel. Yes, that is basically it. > I think the decision about a custom dsdt table in the kernel has > been taken long time ago. and the answer is the option that enables > the kernel to load a custom table. what the patch does is that it > pospones the loading of the table until the initram is loaded. so > the custom dsdt can be read from it. > > If someone thinks the patch isn't good enough, then he should > suggest his own patch. but for now this is the only one available. > Either in the kernel or in the initram, in both cases we can load > our custom dsdt table. the only difference is that the kernel > recompilation takes about 30 mins (compared to the 2mins for the > repacking of the initram). I really don't see any objections to > simplifying this process. > > Please, prove me wrong, but I'm just trying to make it easier to > run linux on my machine. And the patch simlifies this process. There's really nothing to prove. Fedora isn't in the business of maintaining patches not in upstream for long periods of time; it hurts Fedora because of the maintenance load, and it hurts the kernel in general because the problem isn't being fixed at the source. So if there's something you need, find a way to help it get upstream. Probably the best thing you could do would be to email the patch author, test the patch he plans to submit next time, and when he does, chime in with the fact that it works well for you. If people have concerns about ways it might break, see if you can break it in those ways, etc. I do understand that the functionality provided by the patch makes your life easier, but these things have to be done in maintainable ways. It looks like there's a decent chance the patch will be upstream soon, then we can all be happy. :) -Eric -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
