[OpenWrt-Devel] [PATCH v2 2/2] procd: apply official kernel clang-format style
using clang-format-9 Signed-off-by: Paul Spooren --- container.h | 5 +- inittab.c | 108 + libc-compat.h | 5 +- log.h | 12 ++-- preload.h | 49 ++- procd.c | 16 ++--- rcS.c | 18 +++--- signal.c | 22 +++ state.c | 76 --- system.c | 162 ++ sysupgrade.c | 6 +- sysupgrade.h | 2 - ubus.c| 16 ++--- watchdog.c| 14 ++--- watchdog.h| 4 +- 15 files changed, 241 insertions(+), 274 deletions(-) diff --git a/container.h b/container.h index d33fa32..749b33f 100644 --- a/container.h +++ b/container.h @@ -14,10 +14,11 @@ #ifndef __CONTAINER_H #define __CONTAINER_H -#include #include +#include -static inline bool is_container() { +static inline bool is_container() +{ return !!getenv("container"); } diff --git a/inittab.c b/inittab.c index 4b9..a2680ce 100644 --- a/inittab.c +++ b/inittab.c @@ -13,41 +13,41 @@ */ #define _GNU_SOURCE -#include -#include #include +#include +#include +#include #include +#include #include #include #include -#include -#include -#include #include +#include -#include "utils/utils.h" #include "procd.h" #include "rcS.h" +#include "utils/utils.h" #ifndef O_PATH -#define O_PATH 01000 +#define O_PATH 01000 #endif -#define TAG_ID 0 -#define TAG_RUNLVL 1 -#define TAG_ACTION 2 -#define TAG_PROCESS3 +#define TAG_ID 0 +#define TAG_RUNLVL 1 +#define TAG_ACTION 2 +#define TAG_PROCESS 3 -#define MAX_ARGS 8 +#define MAX_ARGS 8 struct init_action; char *console = NULL; struct init_handler { const char *name; - void (*cb) (struct init_action *a); + void (*cb)(struct init_action *a); int multi; }; @@ -74,7 +74,7 @@ static int dev_exist(const char *dev) { int dfd, fd; - dfd = open("/dev", O_PATH|O_DIRECTORY); + dfd = open("/dev", O_PATH | O_DIRECTORY); if (dfd < 0) return 0; @@ -109,9 +109,8 @@ static void fork_worker(struct init_action *a) } if (a->proc.pid > 0) { - DEBUG(4, "Launched new %s action, pid=%d\n", - a->handler->name, - (int) a->proc.pid); + DEBUG(4, "Launched new %s action, pid=%d\n", a->handler->name, + (int)a->proc.pid); uloop_process_add(&a->proc); } } @@ -121,7 +120,7 @@ static void child_exit(struct uloop_process *proc, int ret) struct init_action *a = container_of(proc, struct init_action, proc); DEBUG(4, "pid:%d\n", proc->pid); -uloop_timeout_set(&a->tout, a->respawn); + uloop_timeout_set(&a->tout, a->respawn); } static void respawn(struct uloop_timeout *tout) @@ -184,8 +183,7 @@ static void askconsole(struct init_action *a) console = strdup(tty); a->id = strdup(tty); - } - else { + } else { console = NULL; a->id = NULL; } @@ -209,35 +207,39 @@ static void rcrespawn(struct init_action *a) fork_worker(a); } -static struct init_handler handlers[] = { - { - .name = "sysinit", - .cb = runrc, - }, { - .name = "shutdown", - .cb = runrc, - }, { - .name = "askfirst", - .cb = askfirst, - .multi = 1, - }, { - .name = "askconsole", - .cb = askconsole, - .multi = 1, - }, { - .name = "respawn", - .cb = rcrespawn, - .multi = 1, - }, { - .name = "askconsolelate", - .cb = askconsole, - .multi = 1, - }, { - .name = "respawnlate", - .cb = rcrespawn, - .multi = 1, - } -}; +static struct init_handler handlers[] = { { + .name = "sysinit", + .cb = runrc, + }, + { + .name = "shutdown", + .cb = runrc, + }, + { + .name = "askfirst", + .cb = askfirst, + .multi = 1, + }, + { + .name = "askconsole", + .cb = askconsole, +
Re: [OpenWrt-Devel] [PATCH v2 2/2] procd: apply official kernel clang-format style
I don't think adding formatter-information into the code makes sense at this stage, as this is meant for exeptions from an otherwise applied style. Here, obviously clang-format defintions don't reflect the current style. I will show some examples: On Tue, May 14, 2019 at 05:56:11PM +0200, Paul Spooren wrote: > using clang-format-9 > @@ -209,35 +207,39 @@ static void rcrespawn(struct init_action *a) > fork_worker(a); > } > > -static struct init_handler handlers[] = { > - { > - .name = "sysinit", > - .cb = runrc, > - }, { > - .name = "shutdown", > - .cb = runrc, > - }, { > - .name = "askfirst", > - .cb = askfirst, > - .multi = 1, > - }, { > - .name = "askconsole", > - .cb = askconsole, > - .multi = 1, > - }, { > - .name = "respawn", > - .cb = rcrespawn, > - .multi = 1, > - }, { > - .name = "askconsolelate", > - .cb = askconsole, > - .multi = 1, > - }, { > - .name = "respawnlate", > - .cb = rcrespawn, > - .multi = 1, > - } > -}; > +static struct init_handler handlers[] = { { > + .name = "sysinit", > + .cb = runrc, > + }, > + { > + .name = "shutdown", > + .cb = runrc, > + }, > + { > + .name = "askfirst", > + .cb = askfirst, > + .multi = 1, > + }, > + { > + .name = "askconsole", > + .cb = askconsole, > + .multi = 1, > + }, > + { > + .name = "respawn", > + .cb = rcrespawn, > + .multi = 1, > + }, > + { > + .name = "askconsolelate", > + .cb = askconsole, > + .multi = 1, > + }, > + { > + .name = "respawnlate", > + .cb = rcrespawn, > + .multi = 1, > + } }; Now this is a bit annoying (unnessecarily high indention level) but still baerable. > diff --git a/preload.h b/preload.h > index 5e663ac..5a09db0 100644 > --- a/preload.h > +++ b/preload.h > @@ -18,39 +18,24 @@ > #endif > > #ifndef attribute_unused > -#define attribute_unused __attribute__ ((unused)) > +#define attribute_unused __attribute__((unused)) > #endif > typedef int (*main_t)(int, char **, char **); > > typedef int (*start_main_t)(main_t main, int, char *__unbounded *__unbounded, > - ElfW(auxv_t) *, > - __typeof (main), > - void (*fini) (void), > - void (*rtld_fini) (void), > - void *__unbounded stack_end); > - > -int __libc_start_main(main_t main, > - int argc, > - char **argv, > - ElfW(auxv_t) *auxvec, > - __typeof (main) init, > - void (*fini) (void), > - void (*rtld_fini) (void), > - void *stack_end); > - > - > -typedef void (*uClibc_main)(main_t main, > - int argc, > - char **argv, > - void (*app_init)(void), > - void (*app_fini)(void), > - void (*rtld_fini)(void), > - void *stack_end attribute_unused); > - > -void __uClibc_main(main_t main, > - int argc, > - char **argv, > - void (*app_init)(void), > - void (*app_fini)(void), > - void (*rtld_fini)(void), > - void *stack_end attribute_unused); > + ElfW(auxv_t) *, __typeof(main), void (*fini)(void), > + void (*rtld_fini)(void), > + void *__un
Re: [OpenWrt-Devel] [PATCH v2 2/2] procd: apply official kernel clang-format style
On 5/14/19 6:24 PM, Daniel Golle wrote: > I don't think adding formatter-information into the code makes sense > at this stage, as this is meant for exeptions from an otherwise applied > style. Here, obviously clang-format defintions don't reflect the > current style. They don't, they reflect the kernels style (at lest, as much as I understand using the .clang-configuration file). If it's ugly, it's not a matter of clang-format but of the kernels code style, not? To not spam this list to much, I pushed two branches to GitHub with default style: clang-format-7 default: https://github.com/aparcar/procd/commit/ad7a052dad6f0f6a7e429dc3c7bac4206280aafd clang-format-9 default: https://github.com/aparcar/procd/commit/fca19bb9c0d14e7da80dd9248e4dc75eedee8dc7 I'd be happy if you could give this a few minutes and send a config you like: https://zed0.co.uk/clang-format-configurator/ Sunshine, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] procd: apply official kernel clang-format style
Paul Spooren [2019-05-14 18:51:55]: > On 5/14/19 6:24 PM, Daniel Golle wrote: > > I don't think adding formatter-information into the code makes sense > > at this stage, as this is meant for exeptions from an otherwise applied > > style. Here, obviously clang-format defintions don't reflect the > > current style. > > They don't, they reflect the kernels style (at lest, as much as I > understand using the .clang-configuration file). If it's ugly, it's not > a matter of clang-format but of the kernels code style, not? FYI, quoting from https://www.kernel.org/doc/html/latest/process/clang-format.html While it might be tempting to use this to keep a file always in sync with clang-format, specially if you are writing new files or if you are a maintainer, please note that people might be running different clang-format versions or not have it available at all. Therefore, you should probably refrain yourself from using this in kernel sources; at least until we see if clang-format becomes commonplace. Remember that you can always tweak the changes afterwards in those cases where the tool did not do an optimal job. But as a first approximation, it can be very useful. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel