5 ms·

Linux's is very long in comparison to the BSD's. It seems to have weird edge-cases and possibly unnecessary explanations. https://www.kernel.org/doc/Documentat

by feld 12y ago

Linux's is very long in comparison to the BSD's. It seems to have weird edge-cases and possibly unnecessary explanations. https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle Example: Why is the comment style different in net/? It seems to serve no obvious purpose. Too many cooks :-)

Alupis 12y ago
Likely because /net was done before the coding standard and by some 3rd party contributor -- and doing non-functional whitespace/formatting commits is a no-no in most large projects.
- xfs 12y ago
  Linux kernel does have a lot of non-functional formatting commits. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=formatting https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... These non-functional commits happen more in areas under active development, while established and inactive projects with less than enough watching eyes want to avoid this kind of non-essential changes.
  - Alupis 12y ago
    the link you provided has no "just formatting only" changes. The non-functional changes you see there are updating documentation in comments. That is a big difference. You won't ever see "i just felt like we should have an extra blank line here" changes.
    - 3JPLW 12y ago
      Hunh? Try the staging: unisys: fix formatting in timskmod.h patch - e5700df52 [1] diff --git a/drivers/staging/unisys/include/timskmod.h b/drivers/staging/unisys/include/timskmod.h index b20fc9d..59144ba 100644 --- a/drivers/staging/unisys/include/timskmod.h +++ b/drivers/staging/unisys/include/timskmod.h @@ -293,6 +293,7 @@ static inline struct cdev *cdev_alloc_init(struct module *owner, const struct file_operations *fops) { struct cdev *cdev = NULL; + cdev = cdev_alloc(); if (!cdev) return NULL; (This commit just happened to be the only one I peeked at from the link above - and is particularly apropos) 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5700df5238577e4e570d08a8ee1aa126731dae7 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
      - Alupis 12y ago
        well i stand corrected it seems. although if that is from staging, then it will likely get squashed before merged into mainline (meaning this commit won't actually stay in the history).
        cesarb 12y ago
        Staging is an exception. Staging is a place to put low-quality drivers developed outside the Linux kernel community, to be fixed to Linux kernel standards before being moved into the normal tree. One of the many things done to a driver in staging is to fix the source code formatting. The commits won't get squashed, since it's part of the mainline git repository, which is never squashed. So yeah, on staging you can expect to see lots of non-functional changes, mixed with functional changes.
- feld 12y ago
  If style issues are missed in FreeBSD before commit they're graciously accepted afterwards from what I've witnessed
- feld 12y ago
  Taking in large contributions that violate style(9) is a really bad idea, though.

by feld 12y ago

Alupis 12y ago

Likely because /net was done before the coding standard and by some 3rd party contributor -- and doing non-functional whitespace/formatting commits is a no-no in most large projects.

xfs 12y ago
Linux kernel does have a lot of non-functional formatting commits. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=formatting https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... These non-functional commits happen more in areas under active development, while established and inactive projects with less than enough watching eyes want to avoid this kind of non-essential changes.
- Alupis 12y ago
  the link you provided has no "just formatting only" changes. The non-functional changes you see there are updating documentation in comments. That is a big difference. You won't ever see "i just felt like we should have an extra blank line here" changes.
  - 3JPLW 12y ago
    Hunh? Try the staging: unisys: fix formatting in timskmod.h patch - e5700df52 [1] diff --git a/drivers/staging/unisys/include/timskmod.h b/drivers/staging/unisys/include/timskmod.h index b20fc9d..59144ba 100644 --- a/drivers/staging/unisys/include/timskmod.h +++ b/drivers/staging/unisys/include/timskmod.h @@ -293,6 +293,7 @@ static inline struct cdev *cdev_alloc_init(struct module *owner, const struct file_operations *fops) { struct cdev *cdev = NULL; + cdev = cdev_alloc(); if (!cdev) return NULL; (This commit just happened to be the only one I peeked at from the link above - and is particularly apropos) 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5700df5238577e4e570d08a8ee1aa126731dae7 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
    - Alupis 12y ago
      well i stand corrected it seems. although if that is from staging, then it will likely get squashed before merged into mainline (meaning this commit won't actually stay in the history).
      - cesarb 12y ago
        Staging is an exception. Staging is a place to put low-quality drivers developed outside the Linux kernel community, to be fixed to Linux kernel standards before being moved into the normal tree. One of the many things done to a driver in staging is to fix the source code formatting. The commits won't get squashed, since it's part of the mainline git repository, which is never squashed. So yeah, on staging you can expect to see lots of non-functional changes, mixed with functional changes.
feld 12y ago
If style issues are missed in FreeBSD before commit they're graciously accepted afterwards from what I've witnessed
feld 12y ago
Taking in large contributions that violate style(9) is a really bad idea, though.