Likely I messed up again :)
I agree with Andrew Morton, that it had small amount of documentation, so I extended it. I also fixed long lines and other cleanups. But I did not change some spaces/braces issues.
Like
for (i=0; i<10; ++i) to
for (i = 0; i < 10; ++i)
and
struct abcde { int a, b, c; };
struct abcde { int a, b, c; };
I have to admit, that I actually behaved very stupid, and referring to other places in the code was not too smart either, but this is not the code, which people comment on, but whitespaces and braces. In other places spaces (as long as in DST) are not even detected without using checkpatch.pl script.
And this is the code, which I will maintain, since no one asked (ever) about how things are implmeneted except Andrew, but he did that only because there were no comments. Of course I agree, that having completely different coding style will hurt, since even simple review process will be disturbed by switching between, but above example of spaces and braces is just beyond the resonable.
As an example, I was asked to read this string:
whattheheckwaswrittenhere
and now compare it to
w h a t t h e h e c k w a s w r i t t e n h e r e
IMHO both are crappy, that's why resonable amount of brain power should be applied to whatever we are doing. Not too much, and not too little.
I really do think that some coding styles are vastly superior, however, I've also found it much easier to go with the flow. It helps to mentally compartmentalize what project you are working on. It'd be like defining a macro '#define printf printk" because you are used to typing printf.
The crux of the issue is that styles go beyond simple whitespace issues, they extend to calling conventions, error handling, string tokenizing, resource management, etc. In my mind, when I see code of a particular style, it puts my mind in the right mode for the rest of the conventions in the project. Course, my brain has a related problem where I switch from DVORAK to QWERTY whenever I think I'm doing something windowsey.
Since it simplifies code review if any, that's why I do not have (and really do not like) JavaLikeCapitalLetterNames and so on. But some pieces of code are just convenient to write the way I do. I do not care much about it, really, just do not understand people whoe put this into the main corner, and force others to stupidly try to work it out, discuss and so on...
If anything could be uglier than:
for (i=1; i<10; ++i) {
It would be:
for (i=1; i<10 ++i) {
int check = 5;
if (check == 5)
{
j++;
[etc]
Mixing different styles into an existing project always looks worse than just sticking with the bad style.
All fucntions are called
all loops are called
see additional space and brace on the same line.
Structure's braces can look like loop or like function. I prefer the former, others - the latter.
This is only a matter of author's taste, and while it should not break existing conventions, it should be flexible enough for the person who actually write the code and is supposed to maintain it.
for (i=0; i<10; ++i)
is fucking ugly
И да, забыл спросить, тут можно материться? (:
Functions for example are called that way, i.e.
func(int a, int b) and not
func (int a, int b) or even with additional spaces near the parentheses.
Можно все :)
i was about the absence of spaces surround operators: i=1 vs. i = 1
Воруй! Убивай! (:
This was first time I made a rebase, which happend to be not that complex:
This sequence resulted the DST tree made against 2.6.27 kernel.
A small caveats though: I did not find the way to rebase if there is no additional branch, and pushing this tree does not endup updating remote side, one should manually rebase that tree, and then push local rebased tree.
Current git tree contains all needed changes.
Hi!
Sorry I disturb you, I could find the post to lkml before the documentation update, but I could not find the one after the documentation update (I'm not suscribed, just quick-searching in google :). Do you have any links ?
Anyway, I asume that if it has been merged upstream you would blog about it (or update DST project page, or something like that), so I guess its not. But would be nice to see why not. In any case, do you plan re-submitting for 2.6.29 ?
Thanks a lot,
Rodrigo
Documentation update post did not receive any feedback, so essentially things are stuck. I will resubmit it soon after rebase against mainline release or the latest git to date, but I think result will be pretty much the same.
The latest comments analysis says that whitespace issues are showstoppers for the inclusion, since there were no technical objections. And even they were mostly fixed, but still no comments. Project is likely perfect :), just like it was with kevent.
Thanks a lot for the link
I don't know about kevent, but it's closed, it would be a pitty if dst it's closed too :(
I'm kidding of course.
Most of the time it is not related to technical side. I'm trying to move to contact, to make some progress, but not always succeed. This is my fault too.