Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Some people seem to be arguing against this patch as if it was the implementation code. Stop.
The flag is the code
Posted Dec 7, 2012 23:19 UTC (Fri) by man_ls (subscriber, #15091)
A flag is a name for a bit position. Not code.
Posted Dec 8, 2012 3:39 UTC (Sat) by zlynx (subscriber, #2285)
So there is no valid technical reason to exclude the flag and there IS a good reason to include it, just as syscall, ioctl and device numbers have been reserved in the past. So that new feature patches don't get created that use the same bit. So that future authors writing out of tree code don't end up with a user-space that has to be recompiled when they merge other kernel features.
Objecting to the "process violation" is one thing, and perhaps deserves a post or two. But what then? For ignoring the bureaucracy it seems people want to administer "punishment" by not including the flag. Which is ridiculous at this point because by NOW there HAS been a lot of discussion. Linus has reviewed the patch and accepted it. So the discussion has all been done and the "process" has been successfully followed.
And FYI, code gets changed by maintainers without discussion all the time. Whenever there's a merge conflict between trees is one example.
Posted Dec 9, 2012 21:54 UTC (Sun) by nevets (subscriber, #11875)
Except this was a controversial change that was NACKed previously. Slipping trivial changes and merge conflict resolutions in without review is one thing. Slipping a change that has been previously NACKed by other maintainers is something completely different.
Posted Dec 9, 2012 22:09 UTC (Sun) by zlynx (subscriber, #2285)
Posted Dec 10, 2012 0:56 UTC (Mon) by nevets (subscriber, #11875)
It still should have been posted for comments. Even if it suffered more NACKs, Ted could have posted it to Linus and stated that this is the best solution so far, and it's currently in use by Google. Linus currently seems to be fine with the change, and could have pulled it regardless of the NACKs by other maintainers. He's done things like that before. If that had happened, the other maintainers may have their feelings hurt, but at least everything was out in the open and honest.
I go back to my original statement. It may be a one-liner, but its against a system call and for out of tree code that has been NACKed before. It's not a trivial fix nor a merge conflict. It should have been discussed.
Only the flag. Not the code.
Posted Dec 8, 2012 13:43 UTC (Sat) by ricwheeler (subscriber, #4980)
The bigger issue is not the flag. The core is that this "feature" is not even used by its advocates - exposing unwritten, stale data.
The only justification for the feature or the flag is to take advantage of the side effect which makes ext4 go faster.
Note that on the ext4 list we did debate multiple techniques to fix the actual performance problem at the core here (whether or not random, single fs block writes to a preallocated file are a critical use case).
The problem with the flag itself is that people will use google, etc to search for "ext4 is slow" and suddenly come across the maintainer talking about how to make it faster by using this feature without proper context. Even the name of the flag is misleading - "no hide" sounds like we are doing something fishy.
Better to use a name like "show me other peoples data to make my workload go faster" :)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds