On Thu, Jun 20, 2019 at 11:11:05PM -0600, Logan Gunthorpe wrote: > > > On 2019-06-20 8:57 p.m., Nicholas Johnson wrote: > >> Adding two new parameters sounds like a good idea to me. > > Yeah, that is basically what I did originally (except I depreciated the > > old ones rather than keeping them). > > > > I did it this way on your direct advice in keeping with minimal lines of > > diff, minimal disruption, etc. If I were to do this, the number of lines > > of diff will increase and then I will be fielding complaints that it is > > too large to sign off. > > > > I am already scrambling to make last minute changes before end of > > release to the other patches and I am not even convinced that that stuff > > is going to get accepted based on proximity to deadline and how many > > change requests are flying around. > > Friendly advice: Linux Kernel development doesn't really work on > deadlines. The patch I linked you to has already been around a couple of > cycles and has missed a couple of merge windows. It's not that big of a > deal. I try to make it better, if I can, and resubmit it once or twice > a cycle. It will get in when other people understand it and it meets the > community's standards. I had one patch set I submitted for more than a > year and a half, or 25 times, and it eventually got picked up. It's not > always the best experience but patience, persistence and openness to > feedback are what works. > > New kernel parameters are important to get right because they are user > facing interfaces and we are stuck with them forever -- breaking > existing users is simply not accepted here. Deprecating features is an > extreme action that the Linux community takes pains to avoid. If we cede > to deadlines to get a new parameter in, and it turns out to be > non-ideal, then we are stuck supporting it forever and it's painful for > everyone. > > Logan Thanks for advice. I do believe you are correct. I guess it is my inexperience - I have trouble telling what is normal and what to expect from the process. But I am not feeling like this is any closer to submission than on day one - no sense of progress. It is not reassuring and I do wonder if I will ever manage to get it right. None of this is technically Thunderbolt-specific, but that is the use case, and if a single one of these patches does not make it in then the use case of Thunderbolt without firmware support will remain broken. The only benefit of a partial acception is patch #1 which fixes a bug report by Mika Westerberg on its own, so I guess that would be a win. If it has to wait another cycle then I will live with it, but this is the cause of my anxiety. I can look at this patch again, but my concerns are the following: - If we avoid depreciation, then that implies this patch is ideal - we are not breaking anything for existing users. We can set MMIO on its own with pci=hpmemsize and by setting pci=hpmemprefsize to the default size of 2M (so it remains unchanged). - If we have two sets of parameters, then we have to support having two sets for eternity, and the loss of minimalism and the potential for confusion. The description in kernel-parameters.txt will become confusing with a lot of "if this" and "if that". - How do we deal with order if both are specified? It will become unclean. - If we make two new ones, then what should they be called? I propose hp_mmio_size and hp_mmio_pref_size from my original submission. Then should hpiosize be aliased to hp_io_size to keep the consistency? - I am quite surprised that when 64-bit window support was added to the kernel, that this was not done then, although I am not good enough at navigating the mailing list to see what actually happened. Should I perhaps forward my original submission for this patch again and you can see if there is anything to salvage from that that? Cheers
