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
