From nobody Wed May 21 17:07:09 2025 X-Original-To: freebsd-current@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 4b2dBy4hDJz5wD3d for ; Wed, 21 May 2025 17:07:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2dBy2XmHz3gNs for ; Wed, 21 May 2025 17:07:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-b0db0b6a677so6011609a12.2 for ; Wed, 21 May 2025 10:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1747847241; x=1748452041; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2lYUjSLRUFOt1rYvgm33hvFcOt9HdASTz6mq+ROhLgk=; b=AKpoVvf03KqRD/yE2VqBSQX+ur+qOlNjNn7OYdoAIySXuZ8OR9d8zdOGlgHUViWEUu lSd+5JDrV2n0TYEUpTipRDB0C7pRGol1BDEIWyIYVKFlKBqeGsAKzfrmERB7GBkGFPgO lAD0n62fNtKos26jBo8x+tVfU9ZSvdmRKMikrnIvRItlwZK3PGbn7lLsmrkvUMTBQ2ag 0BpUZWt0IP3jI0yH6yx1PdCa2Qv2vWJGaOot1N6B/uesAj5SJxNRYNUf7eG9L75i9n5r hQv+0IcB5HdMx5YMuJrjPGxsoJoad5ON34LKmQuqKz0YFT4uiSMj//k2c05qo4PESWhy 76uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747847241; x=1748452041; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2lYUjSLRUFOt1rYvgm33hvFcOt9HdASTz6mq+ROhLgk=; b=vdHZIaAPmcRtRE+oe5ZQ7lhtgSd7LYwvrlxTcZ8e0sWyKzBbnRnQxRoQmMSoABVJ8b TdP05lNLPmyq012a4zXq1ylx6a9+pcESJ/6kK/qLnXjunDUkZ7rxQW19C8G6liM57LBh U8XcRWU06XTv/LqHdjGAKCt4lQ7nfMxHEx7i8/8rURwW3T8mvuJJ66NFpnX8SAZIOeqw /2m57dkJ45rEMluIcaCWHMvzQCyIgjqNhoO8iCRR7mtqfgA6jGNUHSnTskDHtmxjith3 /Eugnu3hiOoIh+LMnyoppfDwAYkzrpRAM2l7Bvh/WDBP2HZovP19VOcI6l28uohNZRyv qqUQ== X-Gm-Message-State: AOJu0Yy5xbT2+wajHUdPmH3rOd9xi/4D3GYRB8GgH8eytR6gDtn33I7F 7zAKNn1tivHIwsvjXG3GfqpgG7rqIPcCSDEwJDbyVgXEgHY+AZf1vj29hLedrM2Yn8zQ4eu1rOk eq3OarFVIPPzf2Fy0qrKNktA7bcEm6T2KORSy5g7mWvVQft3/txVNjBw= X-Gm-Gg: ASbGnctxxHGkHNilFKRyuBGgju//E074MGxL9M6aW2RVzRw+zGcaOcxft6bo7/pZLeC 2P05pRkiBYo0EgyLTyy5B2UmDEB8P72WbeCDZNioW8MIQZ9Pmzt9P22+2DnQ0W8084qq0QtsTZ+ d67cgunyraVX7rGC1bmObNDIYq+7p1zwMS X-Google-Smtp-Source: AGHT+IH4+27pFnbfqoSOuQMo6jlQ2DHSktW+7afqz2GKLj/Rz4EPAX5zlBelaW3ugFdIuewnMX8Xwu2PuG2eQCAteuo= X-Received: by 2002:a17:90b:58ee:b0:30e:6ac1:3716 with SMTP id 98e67ed59e1d1-30e7d5bb679mr26231208a91.34.1747847240713; Wed, 21 May 2025 10:07:20 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202505210722.54L7MTqw025632@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Wed, 21 May 2025 11:07:09 -0600 X-Gm-Features: AX0GCFuplHz85Cgdc_umqc_fhvuifQoxm22RNu6mW-7eQigOeRLKKN8R0slytUw Message-ID: Subject: Re: Un-sucking EINVAL To: Andriy Gapon Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4b2dBy2XmHz3gNs X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: ---- On Wed, May 21, 2025 at 10:23=E2=80=AFAM Andriy Gapon wro= te: > > On 21/05/2025 10:28, Lexi Winter wrote: > > you are completely right. since we (for some reason, that i don't > > really understand) can't add new error codes to errno, we should stop > > using errno to indicate errors except where POSIX requires this. One of the problems with new errno values is that they break our ABI. This is a paradoxical result on its surface, but the last time we added a new errno value this issue showed up. The big issue, IIRC, is for statically linked binaries could get errno values that would overflow the arrays of error messages. > I once had this idea, probably not original, that if we usually use 32-bi= t > variables to pass around error / status codes, then why not split up thos= e bits > for some special uses. > > E.g., lowest 10 or 12 bits could be actual error codes. > > But highest, say, 8 or 10 bits could encode a domain of interpretation (t= o use a > term borrowed from IPsec). > Domain number zero would be a POSIX or legacy domain and error codes in i= t would > be the standard errno codes. > Then we could have a different domain (or several) for FreeBSD-specific e= rror codes. > > Some middle bits could be used to further subdivide a domain into modules= or > subsystems with their own error codes. > There could be some private (application specific) domains. > > But, of course, a larger repertoire of error codes is still not as flexib= le and > powerful as an ability to pass a specific error string along with an erro= r code. VMS did variations of this... It was both good and bad. It was a sharp edge that you needed to understand when writing C code in early versions of VAX-C because sometimes it was hidden nicely behind the traditional Unix interfaces, and other times it wasn't. We could pass additional data back to userland. However, that too would be an ABI change. We could pass it in "R0" like we do errno, but then any assembler would need to mask it like the mask we'd add to libc. errno itself can't change: you can't require clients to mask the values and all accesses in the tree to errno are via the errno macro. However, go and rust do their own thing and would need to be modified if we tried to expand the reported value out. The other way to report this would be via something new. There's no new register we can report this on in most architectures: they all have proscri= bed roles that we can't change (or that would be unwise for use to change). The= re's some temp registers on some architectures we might get away with using since their values aren't preserved across system call boundaries. But if w= e can't use a register, then we'd have to make a note of it in the threads structure so we could add a. system call to return it, which does start to get messy = since the thread structure is somewhat optimized for size and fitting in cache li= nes. And if we're going to grow the thread structure, we'd want to maybe just store the string (though memory management issues popup).... In short, I'd love to widen the interface, but there's a number of practica= l issues in the way. Warner