From nobody Wed May 21 23:23:12 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 4b2nXc5twXz5whLm for ; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2nXc5QZqz3K0n; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747869792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ahoNNhp5C3Fh+maCcrO6mK5StCX0fmXf2yUFILmG1Qk=; b=aSShIbYJg4lv3AbfJ2YzFmhX6+u6tz3lW06StaHKNMiKw2sRP3WuWXcsUl/pLKbfVvJZL5 Y4QGqptRycxy/EUQ4WySGfkQwA1fI9G2139wKEDr63gaaE1L4zx8B4GpXTTZmNP6SD7Nud 10iVX9ea2n43XqHai/++RmeWTT41vrKgPUPi8uGCUnqcixBmvsd+H8tsZ4iw9LMVjd5PmA HhH1bcfMQ909himV9LEehnDU9m5id5c6an8izRhvPF91A5BarOykDg7XS+JJia3i02sl2M 2shpYk6CkqbX4y8v0URroUmjDeDR3JMwRuxsvTYUQemcPE8YeseYWK8XeVkHoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747869792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ahoNNhp5C3Fh+maCcrO6mK5StCX0fmXf2yUFILmG1Qk=; b=XqVFUxhP33DWeNIXPaFcGEaKDV+R77U5yrF2HXYmGoCHZmqp2aI/ou+xBa1/PUpbdFtxH/ qI4M7YTYN+dzFmBXQBCz5tJNK/7yS6hGE2b2uwqoDlgfHZNL2p7iPUXWmQhEO0lUEjOh1Q eOpzEFhDsMwAL3Wd0K+yQM16Jl69ur58Wnm8a+PqEb440mcN9r6WcyZI2ElM0FjVvYrpp1 9bOdExT90/3NgQcmG96d8mvMk1p6olGfr4O1LDSrfuyjxPiGfAm4giazmcqWAGbTtLal4A SJynYxHsMir2yT5KBjpi5Dgre/duJXwB3FwOe5JNtM1Ws7xxe9rfKuUIpklz1w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747869792; a=rsa-sha256; cv=none; b=KPec+e4SNkDILvfKt6SPY833nCPXGYFtDKbK/eTCkewWUsYHt/7mA7AEDCPYSgC5BbI2rL /ZvlYottpDarqM39wmBzB8rujdTQvjzVTBeU3zHxq16pBZf3BySGqY6yFbi7rTnOQOMXwf AoKMeIjIJI2k8BjjAAWHJQDuHgrPczX7F/noyPxXyizB3dTJpQVNl67e5DUBH30NwdwOkq wyONO7tjJ3/1eRzZqGrgWO/Wms8Lj9yavSurQXmF0WNxMKmqTs77V7PKYgFh4lkWyY7c5C EegQuglsfMLy3ZaS8gzB3wjNuwSRGK/Mstbyfh+4npXeXcsbrsFHmhY8/8u8Ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2nXc4tF4zHpj; Wed, 21 May 2025 23:23:12 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 357553C01A0; Wed, 21 May 2025 23:23:12 +0000 (UTC) Date: Wed, 21 May 2025 23:23:12 +0000 From: Brooks Davis To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: References: <202505210722.54L7MTqw025632@critter.freebsd.dk> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > In short, I'd love to widen the interface, but there's a number of practical > issues in the way. I think caching something in the kernel of later retrieval or adding a new return path to the ABI is the wrong way around. Instead I think the right solution is for each thread to register a userspace buffer. You end up adding one or two entries to struct thread (pointer to a structure or pointer to an buffer and length) and if the pointer is non-NULL you copyout a string to the buffer. This avoids signficant new storage in the kernel and means programs that won't use this data don't see it. It also means that the debugger can access it without needing a new PT_ argument. As a minor downside you would introduce some new error conditions if the programmer messes up registration, but we'd probably just have libthr do it in most cases (that would be more debugger friendly since you could hang it off a known location in userspace). -- Brooks