From nobody Sun May 21 19:41:40 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QPWDf2P8cz4CP2r for ; Sun, 21 May 2023 19:41:54 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QPWDd53pMz42Qc for ; Sun, 21 May 2023 19:41:53 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-3f42d937d2eso31597255e9.2 for ; Sun, 21 May 2023 12:41:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684698111; x=1687290111; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z40xkHQf9aBfc6RDT43sO/1h+N0ROqGnUnByFPfFFEA=; b=GwuErRPjw85TbCJMW+DMtuQC71fbZK1OnvbHCEl8BbndyHsFM6SjjQS7bew7sF/J5K yguUohh9UPqu4q+rNPi37y83PzUOcg/d23R3kzGgm9QkF4YJjLX3/Oqd/G543aI80MzI 4ElYGNY5DtdRGsXbR7DmHIhQBePODcyw7VOgioy3tV4AOeLRVyWgW15GeoT13no93qLL aDgdO0k/ClrE/npkzyHIBOPZzuIdFIWEF0dCX1RU0IgUehl+H3GUN2EoKMaCEwj8IBfd SY9dm1fsk6llZZLIFqWxyYWmSJtThVXxQh007OAS0CQ9SduDPGxRkBrB/DWQBK8Cc4Um MgTA== X-Gm-Message-State: AC+VfDxLWQaNxpBxuJDU383y8LpxtOUA+W/YUBlsa0aQnpbeLPvToc14 Y90TUecThpMasPT3WYh4eRdXxA== X-Google-Smtp-Source: ACHHUZ7vsLUl+MSWrvr0xjytx8jF65tgXic+kqB9cIxRb0j3bn8SgG5ikmobxkLbiwfa1p8uH8+ELA== X-Received: by 2002:a05:600c:220d:b0:3f6:3bc:8562 with SMTP id z13-20020a05600c220d00b003f603bc8562mr1250071wml.1.1684698111350; Sun, 21 May 2023 12:41:51 -0700 (PDT) Received: from smtpclient.apple ([131.111.5.246]) by smtp.gmail.com with ESMTPSA id l13-20020a7bc44d000000b003f42328b5d9sm5970983wmi.39.2023.05.21.12.41.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 May 2023 12:41:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: git: 805d759338a2 - main - mlx4: Move DEFINE_MUTEX() outside function body. From: Jessica Clarke In-Reply-To: Date: Sun, 21 May 2023 20:41:40 +0100 Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2BF2F7CF-82E6-4D98-800D-C35D7C29E948@freebsd.org> References: <202305211621.34LGLsup059861@gitrepo.freebsd.org> <54EF67D8-2A79-4EAB-8EFB-232F14FFE792@freebsd.org> <21c9532e-4ca7-a7fe-1ff6-07a94cbad6ab@freebsd.org> <3066464F-E4C6-4B84-ADFF-E578AFAFE622@freebsd.org> <26465813-3B51-4E52-9E9D-F93A0F2AF6BD@freebsd.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4QPWDd53pMz42Qc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 21 May 2023, at 20:13, Hans Petter Selasky = wrote: >=20 > On 5/21/23 20:02, Jessica Clarke wrote: >> On 21 May 2023, at 18:46, Hans Petter Selasky = wrote: >>>=20 >>> On 5/21/23 19:05, Jessica Clarke wrote: >>>> On 21 May 2023, at 17:57, Hans Petter Selasky = wrote: >>>>> If you want to change from static structures to global symbols, = then my change is correct. >>>> Which will bloat symbol tables excessively. But you didn=E2=80=99t = state this as your goal, you stated it as a behavioural change *today*, = which it=E2=80=99s not (other than changing the scope). Your commit = message was entirely nonsense, and so I told you that. If your goal is = instead to allow for future changes, put that in your commit message. I = am not a mind reader, nor is anyone else. It is extremely unhelpful to = have commits that say one thing but intend to achieve a different thing. >>>=20 >>> Hi Jess, >>>=20 >>> To me the word "avoid" is agnostic of time. And that's why I used it = there. It doesn't mean there is a bug, but there may easily be a bug = there. >> I strongly disagree. Your wording heavily implied that you were = avoiding something that currently occurs. >=20 > Hi Jess, >=20 > Thanks for sharing your view. I know some words in English have = multiple meanings, and should not be used, because the receiver may pick = a different interpretation than you intended at the time of writing. The = way you react makes me think "avoid" is one more of those words. I have = a list of do-not-use words already. And it grows from time to time. >=20 > Maybe an automated tool exists, to analyze texts for frequent multiple = meanings, not just spell-checking. >=20 >>> If you have time, I can add you for review more often. Let me know = what you prefer. >> Code review is encouraged by the project, whether from me or anyone = else. >=20 > OK, no problem. >=20 >>> When the kernel uses dynamic linking, you end up having tons of = relocation entries in the resulting ELF file. Getting rid of symbol = names doesn't stop relocation entries from piling up. >>>=20 >>> For example declaring a static mutex: >>>=20 >>> At first you have the static mutex. Then the sysinit structure needs = one relocation to refer to the static mutex. Then after that the dataset = mechanism needs another relocation to refer to the sysinit structure. >>>=20 >>> sysinit's work, but there may be better ways to do it. >> I am well aware of how relocations work. I am a compiler and linker = developer (and co-chair of RISC-V=E2=80=99s psABI task group); my = expertise lies in the world of linking. Relocations serve a purpose at = run time. Symbols like this do not. Moreover they now risk clashing as = they=E2=80=99re now visible outside the translation unit. For example, = ib_addr.c and ib_cma.c both have static DEFINE_MUTEX(lock); and that = needs to work as-is because Linux=E2=80=99s DEFINE_MUTEX lets you do = that. So shoving a bunch of symbols into the global namespace is a = non-starter. >=20 > Yes, that is correct for Linux (and possibly other OS'es), but not for = FreeBSD! Maybe I can take this opportunity to give you some insight. >=20 > In the Linux kernel there may be multiple C- and object files = resulting from compilation, sharing the same basename. Linux and FreeBSD = both compile C-files into object files by substituting the ".c" suffix = by ".o" (or something very similar). It depends a bit. >=20 > In FreeBSD there are two modes of compilation: >=20 > 1) Monotolith: /boot/kernel/kernel > 2) Modules: /boot/kernel/*.ko >=20 > If there is a kernel module, there is also a corresponding = configuration keyword to include that kernel module into the = monotolithic kernel. See for example "sys/amd64/conf/GENERIC". There are = very few exceptions. The LINT target builds almost all sources into a = monotolithic kernel. >=20 > One difference between Linux and FreeBSD when doing the monotolithic = kernel build: FreeBSD puts all object files resulting from compilation = into the same object directory. This implies there cannot be two object = files sharing the same name as a result of compilation. This in turn = implies all source file names are unique across the whole of "sys/*", = because converting a source file name into the corresponding object file = name, is simply done by changing the suffix of the file in question. I am aware of all of this. Please do not talk to me like I am an idiot. = Your tone here is extremely patronising. > If you are worried multiple DEFINE_MUTEX(lock) will result in multiple = global symbols having the same "lock" name, all you need to do is pass = through the ${.TARGET} variable from "make" as a define, stripping a few = invalid characters, and macro-concat that to the locally generated = global variable name, and you are all good. You could. But that=E2=80=99s a pretty gross hack IMO, and depending on = how you do it may still not be unique. Not to mention it=E2=80=99s going = to further bloat the symbol tables with these long names. Given the sysinit subsystem still needs to be able to merge in new = sysinits registered dynamically, one might as well just do the sort = dynamically, it=E2=80=99s very little added complexity on top, = especially when sorting functions are just a libkern call away. Much = less complexity than all this scripting to generate tables. > Your comment is correct based on your prior knowledge about Linux and = compilers. But at this point FreeBSD is different. That's why porting = code from Linux to FreeBSD is sometimes difficult, because you need to = keep track of how source files are renamed. You cannot just use "meld = Linux/blah FreeBSD/blah" to compare directories ... DEFINE_MUTEX is Linux=E2=80=99s API, implemented in LinuxKPI. So = Linux=E2=80=99s behaviour is absolutely relevant. Any deviation from = Linux=E2=80=99s semantics is an incompatibility that requires patching = any sources that are built for FreeBSD using LinuxKPI. It is generally = best to minimise that. So, once again, I am asking you to revert your change. Jess