On Thu, 2014-02-27 at 13:05 -0500, David Miller wrote: > From: "Steve Wise" <[email protected]> > Date: Thu, 27 Feb 2014 11:11:49 -0600 > > >> > >> > -static int allow_db_fc_on_t5; > >> > -module_param(allow_db_fc_on_t5, int, 0644); > >> > -MODULE_PARM_DESC(allow_db_fc_on_t5, > >> > - "Allow DB Flow Control on T5 (default = 0)"); > >> > - > >> > -static int allow_db_coalescing_on_t5; > >> > -module_param(allow_db_coalescing_on_t5, int, 0644); > >> > -MODULE_PARM_DESC(allow_db_coalescing_on_t5, > >> > - "Allow DB Coalescing on T5 (default = 0)"); > >> > >> Module parameters are a user facing interface. > >> > >> You cannot just delete, or change the semantics of, the ones you feel > >> like doing so to. > > > > I see your point on user facing interfaces. These module params were > > added initially to allow tweaking the db drop recovery for T5 devices in > > the thought that we might need it. It turns out T5 doesn't suffer from > > this issue. These params default to 0 anyway, and I doubt anyone has > > changed them. Disabling the hw db coalescing feature proved problematic > > and it turned out to even make the issue worse, so I removed it totally > > at the recommendation from the HW engineers, and put in place the new > > design which better rate controls things under heavy load. > > You have to keep the old ones around.
Setting an unknown module parameter now results in a warning (since 3.11), so removing a parameter isn't so disruptive as it used to be. Obviously this is removing a feature, but as the feature sounds like it was only marginally useful I think it's a perfectly valid change. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett
signature.asc
Description: This is a digitally signed message part
