Date: Sat, 18 Apr 2020 14:07:00 +0200 From: =?utf-8?B?UGF3ZcWC?= Jasiak <pawel@jasiak.xyz> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org Subject: Re: Arguments format Message-ID: <20200418120700.GA47913@gmail.com> In-Reply-To: <20200417184725.b49109b7.freebsd@edvax.de> References: <20200417160556.GA44862@gmail.com> <20200417184725.b49109b7.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Thanks for your response!
On 17/04/20, Polytropon wrote:
> On Fri, 17 Apr 2020 18:05:56 +0200, Pawe=C5=82 Jasiak wrote:
> > 1. In sys/mips/mips/autoconf.c we have functions
> >=20
> > static void configure_first(dummy)
> > static void configure(dummy)
> > static void configure_final(dummy)
> >=20
> > 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?
>=20
> 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
>=20
> SYSINIT(configure1, SI_SUB_CONFIGURE, SI_ORDER_FIRST, configure_first, N=
ULL);
>=20
> in /usr/src/sys/powerpc/powerpc/autoconf.c which might
> be the reason why there has to be a dummy parameter...
>=20
> Okay, further investigation. ;-)
>=20
> According to "man 9 SYSINIT", the definition is
>=20
> SYSINIT(uniquifier, enum sysinit_sub_id subsystem,
> enum sysinit_elem_order order, sysinit_cfunc_t func,
> const void *ident);
>=20
> and the type sysinit_cfunc_t is defined as
>=20
> typedef void (*sysinit_cfunc_t)(const void *);
>=20
> 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".
Thanks, I didn't really pay attention to SYSINIT but still don't=20
understand why we don't mark the arguments as __unused.
> > 2. Above functions have strange definition for arguments.
> >=20
> > static void
> > configure(dummy)
> > void *dummy;
> > {
> > ...
> > }
> >=20
> > Why we are not using
> >=20
> > static void
> > configure(void *dummy)
> > {
> > ...
> > }
> >=20
> > like in other places?
>=20
> 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:
>=20
> return-type function-name(arg1, arg2, arg3, ...)
> type arg1;
> type arg2;
> type arg3;
> ...
> {
> function-body
> }
>=20
> 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.
>=20
> See "man 9 style" for details.
>=20
> Still, this style is not being followed consistently:
>=20
> % 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)
> /usr/src/sys/mips/mips/autoconf.c:configure_first(dummy)
>=20
> Some use "K&R C" style, others use "ANSI C" style.
Thanks, I know both styles and I was worried about mixing them.
> > 3. In sys/mips/mips/octeon_cop2.c we are having
> >=20
> > struct octeon_cop2_state *
> > octeon_cop2_alloc_ctx()
> > {
> > ...
> > }
> > but it's declaration in sys/mips/include/octeon_cop2.h is
> >=20
> > struct octeon_cop2_state* octeon_cop2_alloc_ctx(void);
> >=20
> > Question is if we should change octeon_cop2_alloc_ctx() into
> > octeon_cop2_alloc_ctx(void)?
>=20
> 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".
I know the difference again ;)=20
% grep -nr "octeon_cop2_alloc_ctx"
sys/mips/mips/vm_machdep.c:164: td2->td_md.md_cop2 =3D octeon_c=
op2_alloc_ctx();
sys/mips/mips/vm_machdep.c:169: td2->td_md.md_ucop2 =3D octeon_=
cop2_alloc_ctx();
sys/mips/mips/octeon_cop2.c:53:octeon_cop2_alloc_ctx()
sys/mips/mips/trap.c:942: td->td_md.md_cop2 =3D octeon_co=
p2_alloc_ctx();
sys/mips/mips/trap.c:995: td->td_md.md_ucop2 =3D =
octeon_cop2_alloc_ctx();
sys/mips/include/octeon_cop2.h:208:struct octeon_cop2_state* octeon_cop2_al=
loc_ctx(void);
I believe that all uses of the octeon_cop2_alloc_ctx function so I still
don't understand why we have different signatures.
Thanks!
--=20
Pawe=C5=82 Jasiak
--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEENIqkLxDcCMlLMdi0FzfmQudzVTgFAl6a7WAACgkQFzfmQudz
VTg2phAAj1VuhTNQzDbyvrMl1IYzuw0fAEjoQRXFuZ2mlumnvBEbr9AqS4PJZ8wf
+DLwxw0mpjOYkjs3/3UaJYGVSBW53jY2XlrgKMVUm6r/dEQySmxbRSzJjV1nk6bB
d30WUK01yNn519Yj//qK19OHC6KxnzBtnwQx2VX9h5bU7rVr5CROhMppuvgAc029
rJ4THXwdghBRgTLvw/vZ0dxVNOBW5MKQybFMEsIHmHpNlkrFMdq0MFPonE7ukYcT
T2oP079USjKtaqHlMBJioY3Pm+V0Hf3PT6ndovvYBJnz7G3robJv3UwrY0/0sJ+G
l/sVT4wtZThcybE3ZslfOPAqW4Hyqk90D42m4OTYZNc7uqAU9DlpJCUPBVPnqcF4
A2o+JJxkY6qDrFxa1b1/08FfXS115N848N4GlqReKqg+tjHyvoQKzgidtswJeXJT
oyfssBu627731nVCqccxvNpLe1/tWtIPBMf2O+7z16uHjTkiA/QXPfEktBEGjaoB
rbckNkeTC39JwzEWMUvPX3/jDhP7RZ5uNwI2cv43qYeaPpbP3VyU9/VSEV/ZFlXI
KVGZw0C/5aGyF+XxOCDgQVz8pwRcklzEJ6SPGds0i12LT0aqSDKDoKKoFhJcRYSW
DAtZUvAbKGMikpeE2qTReO01pi8/uVM7g8kuApM1US24PSuiVZY=
=LgTT
-----END PGP SIGNATURE-----
--k+w/mQv8wyuph6w0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200418120700.GA47913>