> Your patches just shove another extra into the existing code base > without doing any consolidation work and without any consideration of > problems we need to urgently solve in this area.
I fixed the problems in CPA I was aware of -- I'm not aware of any other current ones (urgent or not). > Your only care is to get stuff merged which is interesting for you. Very true -- by definition I'm not interested in things I'm not interested in. Thanks for reminding me of that :-) However it would surprise me if that was different for you or anybody else. > can understand that, but it should be entirely clear to you as an > engineer that ignoring the existing problems and adding more (even Can you elaborate on the existing problems in the CPA code? (excluding issues already fixed in my CPA patch series) I'm truly curious what these are. > PAT is high on the requirements list, not because it's not complex (it > definitely is), but simply because Linux has a years long of backlog > (it's the only modern OS on the planet still not using PAT) and > hardware makers are stepping beyond the limits of MTRRs. There is an > increasing number of systems which don't work under Linux properly due > to the MTRR limitations, but work perfectly fine with other > OSs. Actually I'm not aware of any shipping box that doesn't work currently on Linux because of no PAT or MTRRs. Do you have an example? I know BIOS people have been grumbling about it, but I don't think there were any real show stoppers so far. It is pretty hard to imagine that ever being the case anyways. We already did non caching mappings for quite some time using the page tables (although admittedly not fully correct and a little unsafe, but probably well enough in practice). The only value add that you get from true PAT support is write-combining and write combining over uncacheable is always only an optimization; nothing required to make boxes work. Admittedly it is helpful for 3d graphics, but the current state is that the big out of tree 3d stuff reprograms the PAT registers on its own. While replacing that with an in tree solution will be a good idea it is not really all that urgent. But I'm not saying that that PAT shouldn't be merged anyways -- i wouldn't have worked on these patches earlier if that was the case -- i'm just disagreeing on you saying it is more important than anything else. I also think it will take longer to make it really stable enough to be mergeable (.26 target would be probably ambitious) so I don't think other patches should be delayed for such a long time just because of it. > While PAT is a 10 years old hardware feature, gbpages is a feature for > a brand new chip, which is not even available to mere mortals in a > useable form. And there is no real problem with not having gbpages for AMD shipped over 400k of them last quarter and they are perfectly usable if you run them with an uptodate BIOS. > some time. So where is the pressure to get that in? For me it's mostly that I was sitting too long on that patch (ok that's my own fault) so I finally want to get it out. Also I don't know of any real reason to delay it much longer -- it is not particularly tricky and contrary to your claims it does not actually interact in a great way with with PAT or anything else pretty much. Ok there are some changes to CPA, but they're IMNSHO quite straight forward extensions of already existing code in there. > Just because it > can be done and happens to work on some test machine? When a patch kit works and does not cause any big risks and is clean code and there are no fundamental design problems what use is there in delaying it unnecessarily? -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
