On Tue 28-04-20 10:09:37, Vlastimil Babka wrote: > On 4/27/20 8:33 PM, Andrew Morton wrote: > > On Mon, 27 Apr 2020 20:04:29 +0200 Vlastimil Babka <vba...@suse.cz> wrote: > > > > > ... > > > + sysctl.*= [KNL] > > > + Set a sysctl parameter, right before loading the init > > > + process, as if the value was written to the respective > > > + /proc/sys/... file. Both '.' and '/' are recognized as > > > + separators. Unrecognized parameters and invalid values > > > + are reported in the kernel log. Sysctls registered > > > + later by a loaded module cannot be set this way. > > > + Example: sysctl.vm.swappiness=40 > > > > Why support "."? I think only supporting "/" is perfectly adequate and > > simplifies documentation. It aligns the command-line syntax with the > > rest of the sysctl documentation. I'm not seeing the need to provide > > two ways of doing the same thing? > > AFAIK the "." is traditional, and "/" is a newer artefact of moving from the > binary syscall form to procfs based form. So by "command-line syntax" you > mean echo and cat, not sysctl tool? Because "man sysctl" says: > > variable > The name of a key to read from. An example is kernel.ostype. The '/' > separator is also accepted in place of a '.'. > > So I'm not strongly against supporting only / but I expect most people are > used to the . and it will take them two attempts to pass the sysctl boot > parameter correctly if they don't use it regularly - first trying . form, > wonder why it doesn't work, then read the doc and realize it's not > supported?
Yes, I do agree. I have only recently learned that sysctl supports / as well. Most people are simply used to . notation. The copy of the arch and . -> / substitution is a trivial operation and I do not think it is a real reason to introduce unnecessarily harder to use interface. -- Michal Hocko SUSE Labs
