[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
