| |||||||||||||
The flag is the codeThe flag is the codePosted Dec 7, 2012 23:19 UTC (Fri) by man_ls (subscriber, #15091)In reply to: Only the flag. Not the code. by zlynx Parent article: A FALLOC_FL_NO_HIDE_STALE followup What do you mean exactly? Frankly I am lost. Flags don't need a technical reason to be reserved? Or that reserving flags can be done by maintainers without discussion?
(Log in to post comments)
A flag is a name for a bit position. Not code. Posted Dec 8, 2012 3:39 UTC (Sat) by zlynx (subscriber, #2285) [Link]
I mean it is a flag in a field that isn't short of flags. No one else wants that flag. It hurts no one to use that bit.
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.
A flag is a name for a bit position. Not code. Posted Dec 9, 2012 21:54 UTC (Sun) by nevets (subscriber, #11875) [Link]
> And FYI, code gets changed by maintainers without discussion all the time. Whenever there's a merge conflict between trees is one example.
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.
A flag is a name for a bit position. Not code. Posted Dec 9, 2012 22:09 UTC (Sun) by zlynx (subscriber, #2285) [Link]
That is why the change that was NACK'd wasn't merged. That would have been the feature and all its code. The flag reservation is what, 1 line, and really not worth all of this noise.
A flag is a name for a bit position. Not code. Posted Dec 10, 2012 0:56 UTC (Mon) by nevets (subscriber, #11875) [Link]
The change itself was obviously still controversial. It's reserving a bit to a system call that affects all filesystems, and it was pushed in by one filesystem maintainer because his company needed it for out of tree code that was NACKed.
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.
|
|||||||||||||