On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote: > On Wed, May 21, 2025 at 11:23:12PM +0000, Brooks Davis wrote: > > 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). > > I mostly agree with this proposal, and can implement it. > I strongly object against blowing the kernel with MBs of strings. > > Userspace can register per-thread extended errno location, and kernel > can copyout the ext-errno when returning error.
I really want them to be strings in the kernel. Anything else is too annoying to maintain and will interact poorly with running old versions of userspace and introduce namespace complications for downstreams. If you want the option to save the space, make the interface that copies the string out a macro and provide an option to compile them away. (Using a macro would also allow you to transparently embed e.g., file, function, or line information if desired.) -- Brooks
