Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
On 4/19/21 2:33 PM, Len Brown via Libc-alpha wrote: the AI guys are super excited about matrix multiplication, but I have a hard time imagining why grep(1) would find a use for it. I don't. Matrix multiplication is used in modern string-searching algorithms that could be useful in running 'grep' on CPUs that have relevant hardware support. See, for example: Susanina Y, Yaveyn A, Grigorev S. Modification of Valiant’s Parsing Algorithm for the String-Searching Problem. CIBB 2019. https://doi.org/10.1007/978-3-030-63061-4_17 Although nowadays this technology is typically proposed for bioinformatics (DNA pattern matching, etc.), it's not that much of a stretch to imagine a future 'grep' or 'diff' that does matrix multiplication. After all, GNU 'diff' currently uses an algorithm designed by a DNA expert. (We now return you to the regular AMX debates. :-)
Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'
On 10/2/20 11:38 AM, Alejandro Colomar wrote: .I void * renders with a space in between. That's odd, as "man(7)" says "All of the arguments will be printed next to each other without intervening spaces". I'd play it safe and quote the arg anyway. > %p works with any object pointer type (or in POSIX, any pointer type), > not just void *. In theory, no (if otherwise, I'd like to know why): Oh, you're right. I had missed that. In GNU/Linux hosts, though, any pointer (including function pointers) can be given to %p. The only platforms where %p wouldn't work on all pointers would be platforms like IBM i, which has both 64-bit (process local) pointers and 128-bit (tagged space) pointers and where you can declare and use pointers of different widths in the same program.
Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'
On 10/2/20 8:14 AM, Alejandro Colomar wrote: +.I void * GNU style is a space between "void" and "*", so this should be '.I "void\ *"', both here and elsewhere. The backslash prevents a line break. +Conversions from and to any other pointer type are done implicitly, +not requiring casts at all. +Note that this feature prevents any kind of type checking: +the programmer should be careful not to cast a Change "cast" to "convert", since the point is that no cast is needed. +.PP +The conversion specifier for +.I void * +for the +.BR printf (3) +and the +.BR scanf (3) +families of functions is +.BR p ; +resulting commonly in +.B %p +for printing +.I void * +values. %p works with any object pointer type (or in POSIX, any pointer type), not just void *. Should also mention "void const *", "void volatile *", etc. Plus it really should talk about plain "void", saying that it's a placeholder as a return value for functions, for casting away values, and as a keyword in C11 for functions with no parameters (though this is being changed in the next C version!). I sent comments about most of this stuff already.
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On 10/2/20 2:10 AM, David Laight wrote: > Also, you should > warn that because one can convert from any pointer type to void * and > then to any other pointer type, it's a deliberate hole in C's > type-checking. That isn't what the C standard says at all. What is says is that you can cast any data pointer to 'void *' and then cast it back to the same type. I was talking about compile-time checking; you're talking about run-time behavior. We're both right in our own domains. It is a tricky area, and this suggests that perhaps we shouldn't be trying to document this stuff in a libc/kernel manual.
Re: New kernel interface for sys_tz and timewarp?
Linus Torvalds wrote: I assume/think that glibc uses (a) environment variables and (b) a filesystem-set default (per-user file with a system-wide default? I don't know what people do). glibc relies on the TZ environment variable, with a system-wide default specified in /etc/localtime or suchlike (there is no per-user default). glibc ignores the kernel's 'struct timezone' settings for of this, as 'struct timezone' is obsolete/vestigial and doesn't contain enough info to do proper conversions anyway. I've been thinking of adding NetBSD's localtime_rz etc. functions to glibc. These functions let user programs specify the time zone for each conversion between time_t and local time, and simplify and/or speed up applications dealing with many requests coming from different time zones. These functions also ignore 'struct timezone'. There's no need to put any of this stuff into the kernel.
Re: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 (posix-timers: Fix, division by zero bug). Problems with glibc.
Thomas Gleixner wrote: Can you please verify whether the issue is fixed with 4.19.19? It depends on what you mean by "verify". I looked at the Linux kernel source code and checked that the "posix-cpu-timers: Unbreak timer rearming" patch is in 4.19.19 (but not 4.19.18) and in 4.20.6 (but not 4.20.5). I did not test Emacs's CPU profiler on these kernels, as I don't have them installed. I expect to upgrade soon to 4.20.6 (whenever Fedora 29 release does - 4.20.6 was submitted for testing a couple of days ago) and plan to give it a try then.
Re: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 (posix-timers: Fix, division by zero bug). Problems with glibc.
Thanks for helping to track down this bug. Since the problem occurs only with a few Linux kernel versions and affects Emacs only when doing CPU profiling, it doesn't seem worth spending time to try to patch Emacs to work around the bug. So I installed the attached patch into emacs-26's etc/PROBLEMS file to warn users about the problem, and am closing the Emacs bug report. >From 1243188bc4f722abf16518bf73924ce5f17750cf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 1 Feb 2019 17:58:05 -0800 Subject: [PATCH] * etc/PROBLEMS: Mention profiler-report bug (Bug#34235). --- etc/PROBLEMS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/etc/PROBLEMS b/etc/PROBLEMS index cab087631c..00583f016d 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -1850,6 +1850,12 @@ term/xterm.el) for more details. ** GNU/Linux +*** GNU/Linux: profiler-report outputs nothing. + +A few versions of the Linux kernel have timer bugs that break CPU +profiling; see Bug#34235. To fix the problem, upgrade to kernel +versions 4.19.19 or 4.20.6, or later. + *** GNU/Linux: Process output is corrupted. There is a bug in Linux kernel 2.6.10 PTYs that can cause emacs to -- 2.20.1
Re: Official Linux system wrapper library?
On 11/14/18 9:40 AM, Joseph Myers wrote: Historically, there was once an attempt to rework POSIX into a separate language-independent definition and language bindings (for C, Fortran, Ada etc.), but I don't think it got anywhere, and it's probably doubtful whether the idea was ever very practical. That effort did produce IEEE Std 1003.5-1992 (Ada Bindings to IEEE Std 1003.1-1990), IEEE 1003.5b-1996 (Ada bindings for realtime extensions), and IEEE Std 1003.9-1992 (F77 Bindings to IEEE Std 1003.1-1992). The Ada group simply translated the POSIX standard from C into Ada, repeating functional text and coming up with a "thick" standard; in contrast the Fortran group did a "thin" standard that focused on Fortran mechanics and deferred underlying functionality to the main POSIX standard. The thin Fortran standard was harder to grok and was less successful in practice. As you write, these efforts were probably not worth the trouble. Non-C language systems can provide a standard way to invoke C APIs, and then let user-level programmers have at it. The performance advantage of having a pure Ada/Fortran/etc. API for POSIX are so minor that it's not worth the major hassle of standardizing and using a language-independent POSIX API.
Re: Official Linux system wrapper library?
Daniel Colascione wrote: This resistance to exposing the capabilities of the system as they are, even in flawed and warty form, is what I meant by "misplaced idealism" in my previous message. With my application-developer hat on I prefer some resistance to flaws and warts, as the resistance gives me a better feel for which functions are problematic and which can be used more reliably. If glibc is missing Linux syscall functionality that I really need then I can use syscall (with the usual caveats) and I've done that on occasion (and have regretted it later too :-). It is helpful for glibc to prefer mild curation to slavishly copying an API that can be a bit helter-skelter at times.
Re: [PATCH 3/3] y2038: rusage: use __kernel_old_timeval for process times
On 11/27/2017 09:00 AM, Arnd Bergmann wrote: b) Extend the approach taken by the x32 ABI, and use the 64-bit native structure layout for rusage on all architectures with new system calls that is otherwise compatible. A possible problem here is that we end up with incompatible definitions of rusage between /usr/include/linux/resource.h and /usr/include/bits/resource.h c) Change the definition of struct rusage to be independent of time_t. This is the easiest change, as it does not involve new system call entry points, but it has the risk of introducing compile-time incompatibilities with user space sources that rely on the type of ru_utime and ru_stime. I'm picking approch c) for its simplicity, but I'd like to hear from others whether they would prefer a different approach. (c) would break programs like GNU Emacs, which copy ru_utime and ru_stime members into struct timeval variables. All in all, (b) sounds like it would be better for programs using glibc, as it's more compatible with what POSIX apps expect. Though I'm not sure what problems are meant by "possible ... incompatible definitions"; perhaps you could elaborate.
Re: RFC: reject unknown open flags
On 03/30/2017 11:19 AM, Linus Torvalds wrote: like "dd" growing an atomic flag and setting it on stdout), 'dd' typically assumes that if a flag O_FOO is not #defined by , then 'dd' can "#define O_FOO 0" and the rest of dd's code can assume O_FOO works "well enough" on older systems. I hope this backward-compatibility hack will suffice for O_ATOMIC too. I'm assuming you'd also possible want to be able to use F_SETFL to set O_ATOMIC after the fact Just for fun, one thread can set O_ATOMIC at the same time another thread is doing a 'write'
Re: diffutils: C labels misdetected as functions
Simon Arlott <[EMAIL PROTECTED]> writes: > The patch below stops diffutils treating C labels starting in column 1 as > function names. That patch alone wouldn't suffice, since -p is documented as implying -F '^[[:alpha:]$_]'. If the behavior changes, we'd also have to change the documentation to match. I'm not sure the change is a good idea. It would complicate the documentation and therefore the user interface, without that much benefit. And it wouldn't suffice in general, since it would still mishandle labels followed by comments or by white space. Also, for long C functions some people might rather see a top-level (unindented) label highlighted than the function name highlighted, so they might prefer the current behavior. Anyway, to work around your problem without changing "diff", you can use "diff -u -F '^[[:alpha:]$_](|.*[^:])$'" instead of "diff -u -p". Or you can put a single space before the labels in question: they'll still stand out plenty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
