Arguments format

Polytropon freebsd at
Fri Apr 17 16:47:30 UTC 2020

On Fri, 17 Apr 2020 18:05:56 +0200, Paweł Jasiak wrote:
> 1. In sys/mips/mips/autoconf.c we have functions
> static void configure_first(dummy)
> static void configure(dummy)
> static void configure_final(dummy)
> and we are not using argument. We are having those functions also in
> ricv, arm, arm64, powerpc and x86 and in non of them we are using dummy,
> so maybe we can just remove it? Or if it is necessary why we don't mark
> it as __unused like in other functions?

I haven't checked any further, but I could imagine that
is has to do with the requirement of those functions
being able - at least in their declaration - to accept
a parameter; the type void * is a "somewhat universal"
type. Note that the functions are being mentioned in
macros, such as

	SYSINIT(configure1, SI_SUB_CONFIGURE, SI_ORDER_FIRST, configure_first, NULL);

in /usr/src/sys/powerpc/powerpc/autoconf.c which might
be the reason why there has to be a dummy parameter...

Okay, further investigation. ;-)

According to "man 9 SYSINIT", the definition is

     SYSINIT(uniquifier, enum sysinit_sub_id subsystem,
         enum sysinit_elem_order order, sysinit_cfunc_t func,
         const void *ident);

and the type sysinit_cfunc_t is defined as

	typedef void (*sysinit_cfunc_t)(const void *);

in /usr/src/sys/sys/kernel.h, so this is the reaon why
the configure_first(), configure(), and configure_final()
functions have to be "compatible".

> 2. Above functions have strange definition for arguments.
>     static void
>     configure(dummy)
>         void *dummy;
>     {
>         ...
>     }
> Why we are not using
>     static void
>     configure(void *dummy)
>     {
>         ...
>     }
> like in other places?

That is not a strange format, it's an older dialect of C,
usually called "K&R C", where the definition of a function
typically is:

	return-type function-name(arg1, arg2, arg3, ...)
		type arg1;
		type arg2;
		type arg3;

A convention also is to put the function's return type on
an individual line, so the function's name always starts
at column 1.

See "man 9 style" for details.

Still, this style is not being followed consistently:

% grep "^configure_first" `find /usr/src/sys -name autoconf.c`
/usr/src/sys/x86/x86/autoconf.c:configure_first(void *dummy)
/usr/src/sys/arm64/arm64/autoconf.c:configure_first(void *dummy)
/usr/src/sys/arm/arm/autoconf.c:configure_first(void *dummy)
/usr/src/sys/riscv/riscv/autoconf.c:configure_first(void *dummy)
/usr/src/sys/sparc64/sparc64/autoconf.c:configure_first(void *dummy)
/usr/src/sys/powerpc/powerpc/autoconf.c:configure_first(void *dummy)

Some use "K&R C" style, others use "ANSI C" style.

> 3. In sys/mips/mips/octeon_cop2.c we are having
>     struct octeon_cop2_state *
>     octeon_cop2_alloc_ctx()
>     {
>         ...
>     }
> but it's declaration in sys/mips/include/octeon_cop2.h is
>     struct octeon_cop2_state* octeon_cop2_alloc_ctx(void);
> Question is if we should change octeon_cop2_alloc_ctx() into
> octeon_cop2_alloc_ctx(void)?

There is a difference between () and (void) which _might_ be
intended; however, prototype and declaration should in fact
have the same signature. If the argument is (), the function
will accept any parameters, including none ("any parameters
list"); if it's (void), the function will refuse to accept
any parameters ("emtpy parameter list"), which is explicit
for "it doesn't use any parameters".

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list