From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A57FDC0218D for ; Sun, 26 Jan 2025 23:52:19 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1tcC4P-000000006Q2-2ZP8; Sun, 26 Jan 2025 18:29:37 -0500 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1tcC4N-000000006Pt-3Q6w for kernelnewbies@kernelnewbies.org; Sun, 26 Jan 2025 18:29:35 -0500 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-71e1b1767b3so2299387a34.3 for ; Sun, 26 Jan 2025 15:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737934153; x=1738538953; darn=kernelnewbies.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=ZRGX0XveGqLdFQIKGSwYgJ4q9/LqF6VBj2HypuXoxC4=; b=BgfLBK8e5TqX7hF89sHxiVpKy/xRoJK4nJ18r/F1YmQwRxbK/5ZekAu11iArbK1lGR e0oUpohx2Q4axxbIbwSNXniG+EbZFPYf7jFB1ngBAe9N4hy5zapblAHSYo9+0w0LyJj6 55jiSRStiSFrtLihOAQjQnIKWix9DKoup719si91+PUEIo0uNQx9tgM2sJx+EuM/AZkR ZwL39LVdHHq2nsiNSt9bOBimUc6rIYtlq98Z3IVPppaNyAMO3UDcxsI5ot49Ry4PrW9q rR2IeUvsEmLjOWInI4L33sdvYtlOmDaY2704CMNaSHs42Ar1DuN5xwQY2yngog+3tlzZ sKSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737934153; x=1738538953; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZRGX0XveGqLdFQIKGSwYgJ4q9/LqF6VBj2HypuXoxC4=; b=N6ge4GViCV1MqJHr9z+vzDuiyUNkd3SCw4bu6X5sYt+j+Fdq2eJQlDSjC6E6loreN5 BNA8hX/PkC/w1+NYlbKouQZsKimdUcuS61+ylF4sdofCWc4ZN/Z8XkM5802TRcoxYQsB kpEcml1veeqBR471dt3qHpYEfD+82rPXx26RxDNBzrK7eV8Q+bmhp2Lu39Jvm+ztsryW RY/YV3D0jlGqgVYKd6Bg9pEGlybzE3GFW/xu03myewYywb1g9HFWVEzYJl2cC7Brv6Iz QKf6JTjf0SP9VJTrGnkKKJRNo2S9/1uqTcXu7Y0G9ergOnjvNjc3FFuNW6M+B1/4ljUx 6s4w== X-Gm-Message-State: AOJu0YyBGvGri55fsaIol0m3C1WsL9uN+NkHbdLnCb6K7a9EPoI6JxBR l+hRowmeThqeXFP67s1Iy2KDFm8729R4iK2VfOqC5U5RF+OuWvPx33MkPK6q X-Gm-Gg: ASbGncvnSe7YuNBamCMTCPcUzQJXEgMUtKtyRqG1J+C1RKZKO91RC8Pm1RUnBHHMpHa 0cdzSHfzlHMM8QeEYF09O0Vryz5d8wNFU1gMX4PFOimFIz1H9g66TE3Z0dM6eTZzIx8KELBCaeq kkeRD7kjzRnwWMIOd96q6vMbbi9+fvG2PoGCGDmAKDl6L2lN9DL700lfLzHPcjgv11x7aj3zmDm 1Gn7onej9voN5rzxVbNtWO7+nosHfbE/PkDvpwLJFZdNG2UzNAJz/2Vhqn+VqLgt89K6oAcpE6c PsZMfOLKZhnbvpgVAstd9gw20kC+zOHl0gNzZY0RrZS/8Q== X-Google-Smtp-Source: AGHT+IFNxVv5rd+zXM7eMSDULIS6e2/UvCDKP14veB0ew3uNWaL5qR7r2bBvBvCfuLl9DdrCVL48SA== X-Received: by 2002:a05:6830:40a7:b0:71e:93c:53a0 with SMTP id 46e09a7af769-7249dae0418mr17878112a34.17.1737934153219; Sun, 26 Jan 2025 15:29:13 -0800 (PST) Received: from [192.168.1.55] (syn-072-182-129-086.res.spectrum.com. [72.182.129.86]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-5fa8b540e33sm1862188eaf.14.2025.01.26.15.29.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jan 2025 15:29:12 -0800 (PST) Message-ID: Date: Sun, 26 Jan 2025 17:29:10 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Typecasting a void pointer to unsigned long in zsmalloc.c To: kernelnewbies@kernelnewbies.org References: <2025012321-fool-blatantly-069a@gregkh> <2025012347-shorthand-october-ada2@gregkh> <2025012408-amenity-quaintly-fce5@gregkh> Content-Language: en-US From: Leam Hall In-Reply-To: X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kernelnewbies-bounces@kernelnewbies.org On 1/24/25 15:45, Sotir Danailov wrote: > I found this page which looks a bit legacy and doesn't seem to be > linked on kernel.org anywhere: https://www.kernel.org/doc/ > In here, under "Standards documents applicable to the Linux kernel", > there's an interesting line: > "LP64 standard defining the size of char, short, int, and long on > 32-bit and 64-bit platforms." and it links to this: > https://unix.org/whitepapers/64bit.html > In the link, under "64-bit Data Models", there's a table, which shows > that LP64 means: > char 8 bits, short 16 bits, int 32 bits, long 64 bits, pointer 64 bits > > This lead me to: > https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build > which explains that for "System V AMD64 ABI": > on page 12: "all pointer types are 64-bit objects (LP64)" > on page 17: there's a table showing that "unsigned long (LP64)" is 8 bytes. > > Finally, in GCC's manual for x86: > https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mabi-7 > "The default is to use the Microsoft ABI when targeting Microsoft > Windows and the SysV ABI on all other systems." > > I was wondering how it worked for other architectures, so I decided to > grep the Makefiles in the Linux tree and apparently for some > architectures it's explicitly stated: > ./arch/arm64/Makefile:53:KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) > ./arch/riscv/Makefile:33: KBUILD_CFLAGS += -mabi=lp64 > > What I found in kernelnewbies: https://kernelnewbies.org/InternalKernelDataTypes > "One thing that has caused a lot of problems, as 64-bit machines are > getting more popular, is the fact that the size of a pointer is not > the same as the size of an unsigned integer. The size of a pointer is > equal to the size of an unsigned long." > > I think there should be an explanation both on kernel.org and > kernelnewbies what determines the sizes, so that people can have a > better idea of what's going on. It should be something that is easy to > find and part of "introductions" to kernel development, because it's > not obvious at all how all of these things are setup. To me it seems > fundamental, to be able to quickly find easy to digest information > regarding the data types you're working with. Sotir, great research! Sadly, https://kernelnewbies.org is giving a "ConfigurationError". :( So I'm not sure if the reference to https://www.kernel.org/doc/ is already in place, or not. Something to check when KN is back up. I'd think pointing to good documents is better than replicating them and risk staleness, isn't it? Leam Linux Software Engineer (reuel.net/career) Scribe: The Domici War (domiciwar.net) Coding Ne'er-do-well (github.com/LeamHall) Between "can" and "can't" is a gap of "I don't know", a place of discovery. For the passionate, much of "can't" falls into "yet". -- lh Practice allows options and foresight. -- lh _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies