either!
> Fixes: 7c02bc4088af ("tools/nolibc: add support for clock_nanosleep() and
> nanosleep()")
> Signed-off-by: Thomas Weißschuh
Acked-by: Willy Tarreau
Willy
Hi Thomas,
On Sat, Jul 19, 2025 at 05:38:28PM +0200, Thomas Weißschuh wrote:
> The toplevel Makefile is capable of calculating CC from CROSS_COMPILE
> and/or ARCH.
>
> Stop passing the unnecessary variable.
(...)
> # Execute the toplevel kernel Makefile
> -KBUILD_MAKE = $(MAKE) -C $(srctree) AR
mitting invalid object code.
>
> Signed-off-by: Thomas Weißschuh
For the series, once the help message is adjusted:
Acked-by: Willy Tarreau
Thanks!
Willy
rect type.
>
> Signed-off-by: Thomas Weißschuh
Great! I didn't know we could support x32 and thought it was phased out.
But if it works it can be convenient for those seeking smaller binaries.
Both patches look good to me, for the whole series:
Acked-by: Willy Tarreau
Thanks!
Willy
dif
I don't know which archs do not have clock_nanosleep, but if it becomes
needed on some of them, we could probably fall back to pslelect() if
available, of course, and ignore the clockid.
Acked-by: Willy Tarreau
Cheers,
Willy
On Fri, Jul 04, 2025 at 03:43:11PM +0200, Thomas Weißschuh wrote:
> When an error is encountered by printf() it needs to be reported.
>
> Signed-off-by: Thomas Weißschuh
Good catch!
Acked-by: Willy Tarreau
Willy
Hi Adrian,
On Tue, Jun 24, 2025 at 08:03:47AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Thomas,
>
> On Mon, 2025-06-23 at 23:15 +0200, Thomas Weißschuh wrote:
> > Add support for SuperH/"sh" to nolibc.
> > Only sh4 is tested for now.
> >
> > This is only tested on QEMU so far.
> > Additional
arning.
>
> It would also be possible to use __attribute__((nonstring)) but that
> would require some ifdeffery to work with older compilers.
I agree with you, that's not an important enough fight to spend time
on :-)
> Fixes: 1063649cf531 ("selftests/nolibc: Add tests
s-is.
>
> Sounds good. Could you give a formal Ack for the patch/series?
Sure, as usual, for the relevant parts of the series:
Acked-by: Willy Tarreau
Cheers,
Willy
On Sat, Jun 21, 2025 at 10:34:38AM +0200, Thomas Weißschuh wrote:
> On 2025-06-21 06:14:21+0200, Willy Tarreau wrote:
> > Hi Thomas,
> >
> > On Fri, Jun 20, 2025 at 11:39:32PM +0200, Thomas Weißschuh wrote:
> > > The nolibc tests are not real kselftests, they work d
Hi Thomas,
On Fri, Jun 20, 2025 at 11:39:32PM +0200, Thomas Weißschuh wrote:
> The nolibc tests are not real kselftests, they work differently and
> provide a different interface. Users trying to use them like real
> selftests may be confused and the tests are not executed by CI systems.
>
> To m
e pipes. Here I think it's OK, however,
I'm wondering if "file:$(CURDIR)/run.out" wouldn't be clearer, and also
encourage future changes to stick to a file and avoid piping the output
to a filter command. No strong opinion though.
In any case: Acked-by: Willy Tarreau
Thanks,
Willy
here the correct mode is the only supported one and therefore the
> flag is not implemented.
>
> Switch to a more dynamic probing mechanism.
> This correctly enables stack protectors for mips, loongarch and m68k.
>
> Signed-off-by: Thomas Weißschuh
(...)
Acked-by: Willy Tarreau
Willy
;t
> work where the correct mode is the only supported one and therefore the
> flag is not implemented.
>
> Switch to a more dynamic probing mechanism.
> This correctly enables stack protectors for mips, loongarch and m68k.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Willy Tarreau
Thanks,
Willy
o the same in my init code once I'm in vacation, it's
likely that it will be sufficient as well now.
For the series: Acked-by: Willy Tarreau
Thanks!
Willy
e small comments, you can take my ack for the whole
series: Acked-by: Willy Tarreau
Thanks!
Willy
On Wed, Apr 23, 2025 at 05:01:43PM +0200, Thomas Weißschuh wrote:
> +static __attribute__((unused))
> +FILE *fopen(const char *pathname, const char *mode)
> +{
> + int flags, fd;
> +
> + if (!strcmp(mode, "r"))
> + flags = O_RDONLY;
> + else if (!strcmp(mode, "w"))
> +
On Wed, Apr 23, 2025 at 05:01:42PM +0200, Thomas Weißschuh wrote:
> This is used in various selftests and will be handy when integrating
> those with nolibc.
It could be useful to add a small note here mentioning that the test
takes care of the optional OS support, and will run it only if started
On Wed, Apr 23, 2025 at 05:01:41PM +0200, Thomas Weißschuh wrote:
> This is used in various selftests and will be handy when integrating
> those with nolibc.
>
> Signed-off-by: Thomas Weißschuh
> ---
> tools/include/nolibc/time.h | 7 +++
> tools/testing/selftests/nolibc/nol
On Wed, Apr 23, 2025 at 05:01:40PM +0200, Thomas Weißschuh wrote:
> diff --git a/tools/include/nolibc/sys/timerfd.h
> b/tools/include/nolibc/sys/timerfd.h
> new file mode 100644
> index
> ..2d61fc76fe9a9ba7571f52ff157a8a4807d7d9c9
> --- /dev/null
> +++ b/to
Hi Thomas,
On Wed, Apr 23, 2025 at 05:01:35PM +0200, Thomas Weißschuh wrote:
> --- /dev/null
> +++ b/tools/include/nolibc/sys/random.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
> +/*
> + * random definitions for NOLIBC
> + * Copyright (C) 2025 Thomas Weißschuh
> + */
>
y
great solution. I think that your approach is the right one, indeed,
to include it out of the guards will force to respect ordering. That's
a great idea. I'm all for it!
Acked-by: Willy Tarreau
Willy
Hi Thomas,
On Tue, Apr 22, 2025 at 10:48:28AM +0200, Thomas Weißschuh wrote:
> Hi,
>
> On Fri, Apr 11, 2025 at 11:00:24AM +0200, Thomas Weißschuh wrote:
> > Nolibc is useful for selftests as the test programs can be very small,
> > and compiled with just a kernel crosscompiler, without userspace
ce size of fixes to i{64,}toa_r()
> - Link to v1:
> https://lore.kernel.org/r/20250416-nolibc-ubsan-v1-0-c4704bb23...@weissschuh.net
Wow that was a fast turn-around! Looks good. For the whole series:
Acked-by: Willy Tarreau
Thank you Thomas!
Willy
On Sat, Apr 19, 2025 at 12:10:24PM +0200, Thomas Weißschuh wrote:
> On 2025-04-19 11:06:31+0200, Willy Tarreau wrote:
> > On Wed, Apr 16, 2025 at 08:40:17PM +0200, Thomas Weißschuh wrote:
> > > Both constructors and main() may be executed with different function
> > &g
e pretty useful, I agree it's a good idea.
Acked-by: Willy Tarreau
Thanks,
Willy
On Wed, Apr 16, 2025 at 08:40:19PM +0200, Thomas Weißschuh wrote:
> In twos complement the most negative number can not be negated.
well, if we're picky, that's not really an int overflow since it's only
used as an unsigned in the end, so -2^(N-1) == 2^(N-1) in twos complement.
> @@ -271,16 +271,
the line, to keep
declarations alignes, even if that makes longer lines. If alignment concerns
come back often, we could maybe have __nolibc_align() and maybe even
__nolibc_align_as() to slightly shorten the lines. Just an idea.
In any case: Acked-by: Willy Tarreau
Willy
On Wed, Apr 16, 2025 at 08:40:17PM +0200, Thomas Weißschuh wrote:
> Both constructors and main() may be executed with different function
> signatures than they are actually using.
> This is intentional but trips up UBSAN.
>
> Disable the function sanitizer of UBSAN in _start_c().
>
> Signed-off-b
On Wed, Apr 02, 2025 at 11:38:58PM +0200, Thomas Weißschuh wrote:
> If no explicit XARCH is specified, use the toolchains default.
The series looks good to me, thank you Thomas. For the whole series:
Acked-by: Willy Tarreau
Willy
include
> >
> > ---
> > base-commit: bceb73904c855c78402dca94c82915f078f259dd
> > change-id: 20250324-nolibc-ioperm-155646560b95
> >
> > Best regards,
>
> Acked-by: Shuah Khan
Fine for me as well.
Acked-by: Willy Tarreau
Thanks,
willy
On Mon, Mar 17, 2025 at 06:57:01PM -0700, Chris Torek wrote:
> On Mon, Mar 17, 2025 at 11:38 AM Willy Tarreau wrote:
> > OK thanks, but that remains quite strange to me. How can we end up
> > here with such an unaligned stack ? At the very minimum I'd expect
> > all o
On Mon, Mar 17, 2025 at 06:52:57PM +0100, Thomas Weißschuh wrote:
> On 2025-03-17 08:37:46+0100, Willy Tarreau wrote:
> > On Sun, Mar 16, 2025 at 02:55:02PM +0100, Thomas Weißschuh wrote:
> > > Add support for 32bit and 64bit SPARC to nolibc.
> >
> > Oh nice!
&g
sure what it
refers to, but if we can safely erase parts of the stack because too
much was preserved, maybe some more explanation about the initial and
target layouts is deserved here.
> + "b,a _start_c\n" /* transfer to c runtime */
OK great, the delayed slot is covered! (that type of thing can work
by pure luck in one test and fail in another one depending on what
bytes follow the jump).
Thanks!
Acked-by: Willy Tarreau
Willy
Stop validating the order and instead only validate that all
> constructors are executed.
>
> Reported-by: Willy Tarreau
> Closes: https://lore.kernel.org/lkml/20250301110735.ga18...@1wt.eu/
> Signed-off-by: Thomas Weißschuh
Awesome, thank you very much, Thomas!
Willy
Hi Thomas,
On Thu, Mar 06, 2025 at 06:22:45PM +0100, Thomas Weißschuh wrote:
> Hi Willy,
>
> On 2025-03-04 09:11:16+0100, Willy Tarreau wrote:
> > On Tue, Mar 04, 2025 at 07:58:15AM +, Louis Taylor wrote:
> > > openat is useful to avoid needing to construct relative
On Thu, Mar 06, 2025 at 06:00:17PM +0100, Thomas Weißschuh wrote:
> On 2025-03-04 07:58:19+, Louis Taylor wrote:
> > It was mentioned that a new test_ function should be static, so go back
> > over existing functions and mark those static as well.
>
> Actually Willy wants these non-static for
On Wed, Mar 05, 2025 at 08:25:14AM +0100, Thomas Weißschuh wrote:
> On Tue, Mar 04, 2025 at 08:54:29AM +0100, Willy Tarreau wrote:
> > On Tue, Mar 04, 2025 at 08:10:54AM +0100, Thomas Weißschuh wrote:
> > > diff --git a/tools/include/nolibc/getopt.h b/tools/include/nolibc/getop
On Tue, Mar 04, 2025 at 12:08:56PM +0100, Thomas Weißschuh wrote:
> On Tue, Mar 04, 2025 at 08:37:42AM +0100, Willy Tarreau wrote:
> > Hi Thomas,
> >
> > On Tue, Mar 04, 2025 at 08:10:45AM +0100, Thomas Weißschuh wrote:
> > > The printf format checking in the compi
Hi Thomas,
On Tue, Mar 04, 2025 at 08:10:30AM +0100, Thomas Weißschuh wrote:
> Nolibc is useful for selftests as the test programs can be very small,
> and compiled with just a kernel crosscompiler, without userspace support.
> Currently nolibc is only usable with kselftest.h, not the more
> conve
x27;s OK:
Acked-by: Willy Tarreau
Thomas, since you already have plenty of changes in queue, do you mind
if I let you pick this series ?
Thanks!
Willy
On Tue, Mar 04, 2025 at 08:10:57AM +0100, Thomas Weißschuh wrote:
> +static int _sprintf_cb(intptr_t _state, const char *buf, size_t size)
So logically we should have "nolibc" in that name as well.
Willy
On Tue, Mar 04, 2025 at 08:10:55AM +0100, Thomas Weißschuh wrote:
> Decouple the formatting logic from the writing logic to later enable
> writing straight to a buffer in sprintf().
>
> Signed-off-by: Thomas Weißschuh
> ---
> tools/include/nolibc/stdio.h | 21 +
> 1 file chan
On Tue, Mar 04, 2025 at 08:10:54AM +0100, Thomas Weißschuh wrote:
> diff --git a/tools/include/nolibc/getopt.h b/tools/include/nolibc/getopt.h
> new file mode 100644
> index
> ..35aee582681b79e21bce8ddbf634ae9dfdef8f1d
> --- /dev/null
> +++ b/tools/include/n
Hi Thomas,
On Tue, Mar 04, 2025 at 08:10:45AM +0100, Thomas Weißschuh wrote:
> The printf format checking in the compiler uses the intmax types from
> the compiler, not libc. This can lead to compiler errors.
>
> Instead use the types already provided by the compiler.
>
> Example issue with clan
of Arm cross
compilers are configured to produce thumb2 code by default since it's
generally faster and quite smaller.
Tested-by: Willy Tarreau
Willy
On Sat, Mar 01, 2025 at 03:47:52PM +, Maciej W. Rozycki wrote:
> On Sat, 1 Mar 2025, Willy Tarreau wrote:
>
> > > Introduce support for the N32 and N64 ABIs. As preparation, the
> > > entrypoint is first simplified significantly. Thanks to Maciej for all
> &
stack alignments were not needed
and that the cleanup is quite welcome!
Tested-by: Willy Tarreau
Willy
Hi Thomas!
On Tue, Feb 25, 2025 at 10:37:24AM +0100, Thomas Weißschuh wrote:
> > > The tests are written specifically to test for execution order.
> > > While we can not rely on the order for other libcs, the idea was to
> > > expect a given order for the nolibc implementation.
> >
> > OK.
> >
>
mbols available.
>
> Signed-off-by: Thomas Weißschuh
Works fine here. Pick any combination you'd like of those below ;-)
Acked-by: Willy Tarreau
Tested-by: Willy Tarreau
Thanks!
Willy
On Mon, Feb 03, 2025 at 05:14:37PM +0100, Thomas Weißschuh wrote:
> On Mon, Feb 03, 2025 at 04:43:22PM +0100, Christophe Leroy wrote:
>
>
> > Do you have any plan to get it work with nolibc for all test programs in
> > selftests/vDSO, not only the standalone x86 test ?
>
> Not directly as next s
On Mon, Feb 03, 2025 at 10:05:14AM +0100, Thomas Weißschuh wrote:
> nolibc does not provide this header, instead its definitions are
> available unconditionally.
Please think about reminding which one you're talking about so that a
simple "git log" shows what header you're talking about (limits.h)
Hi Thomas,
On Mon, Feb 17, 2025 at 10:24:11PM +0100, Thomas Weißschuh wrote:
> On 2025-02-16 10:39:40+0100, Willy Tarreau wrote:
> > On Wed, Feb 12, 2025 at 07:01:01PM +0100, Thomas Weißschuh wrote:
> > > The nolibc testsuite can be run against other libcs to test for
> >
Mi Maciej,
On Mon, Feb 17, 2025 at 11:23:11PM +, Maciej W. Rozycki wrote:
> > > Why is this code breaking stack alignment just to have to fix it up two
> > > instructions down the line? Or is it that the incoming $sp is not
> > > aligned
> > > in the first place (in which case we're havin
>*/
> +#endif
> +
> + /* ABI requires current function address in $t9 */
> +#if defined(_ABIO32) || defined(_ABIN32)
> + "lui $t9, %hi(_start_c)\n"
> "ori $t9, %lo(_start_c)\n"
> +#else
This one indeed covers only _ABI64
> + "lui $t9, %highest(_start_c)\n"
> + "ori $t9, %higher(_start_c)\n"
> + "dsll $t9, 0x10\n"
> + "ori $t9, %hi(_start_c)\n"
> + "dsll $t9, 0x10\n"
> + "ori $t9, %lo(_start_c)\n"
> +#endif
With the tiny details above, this looks fine. It's great that syscall
numbers didn't change so that you can cover an extra arch with only a
few ifdefs. I have not tested but I guess you did :-) So that's OK for
me:
Acked-by: Willy Tarreau
Thanks!
Willy
== 3,
and that the args were passed via &4==4). That would allow to further
refine the tests if desired so that we can keep the differences in mind.
In any case all of this can also be done later, and I'm obviously fine
with this immediate adjustement.
> Signed-off-by: Thomas Weißschuh
Acked-by: Willy Tarreau
Willy
testcase
> - Add some comments
> - Expand commit message
> - Link to v1:
> https://lore.kernel.org/r/20240731-nolibc-scanf-v1-0-f71bcc4ab...@weissschuh.net
Looks good. For the whole series:
Acked-by: Willy Tarreau
Thanks!
Willy
d_name
> - Implement readdir_r() instead of readdir()
> - Expand commit message
> - Link to v1:
> https://lore.kernel.org/r/20250130-nolibc-dir-v1-0-ea9950b52...@weissschuh.net
Nice!
Acked-by: Willy Tarreau
Willy
On Sat, Feb 01, 2025 at 11:41:58AM +0100, Thomas Weißschuh wrote:
> On 2025-02-01 11:34:38+0100, Willy Tarreau wrote:
> > On Thu, Jan 30, 2025 at 08:54:03PM +0100, Thomas Weißschuh wrote:
> > > From: Thomas Weißschuh
> > >
> > > Add an allocation-free imp
On Thu, Jan 30, 2025 at 08:54:03PM +0100, Thomas Weißschuh wrote:
> From: Thomas Weißschuh
>
> Add an allocation-free implementation of readdir() and related
> functions. The implementation is modelled after the one for FILE.
I think you'd need to mention/remind the two important points that
com
mands with side-effects
> together.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Willy Tarreau
Willy
On Thu, Jan 23, 2025 at 08:37:37AM +0100, Thomas Weißschuh wrote:
> kbuild already contains logic to merge predefines snippets into a
> defconfig file. This already works nicely with the current "defconfig"
> target. Make use of the snippet and drop the custom logic.
>
> Signed-off-by: Thomas Weiß
On Sat, Feb 01, 2025 at 11:17:28AM +0100, Thomas Weißschuh wrote:
> On 2025-02-01 11:13:05+0100, Willy Tarreau wrote:
> > On Thu, Jan 23, 2025 at 08:37:37AM +0100, Thomas Weißschuh wrote:
> > > kbuild already contains logic to merge predefines snippets into a
> > > d
ts to double-check anything, given that
he initially contributed the s390 support.
Acked-by: Willy Tarreau
Thanks!
Willy
; Avoid this by introducing ordering dependencies between the defconfig
> and some other targets.
I didn't know these ordered dependencies of makefiles, we learn every
day ;-)
Acked-by: Willy Tarreau
Willy
ault is painful and I also hate doing
that.
So maybe better get rid of it indeed, and leave it to the user to decide to
clean or not.
Acked-by: Willy Tarreau
Willy
annot say for sure
when, but I did definitely discover it when trying to fix some build
issues. It's very possible that the issues that it used to fix have
long been fixed and that it remained in fingers memory, so I'm fine
with dropping it and we'll see. If we ever discover we nee
On Thu, Jan 23, 2025 at 09:10:41PM +0100, Thomas Weißschuh wrote:
> Make nolibc compatible with -Wmissing-prototypes
Nice, ack for all the series:
Acked-by: Willy Tarreau
Thank you Thomas,
Willy
On Wed, Jan 22, 2025 at 08:00:28PM +0100, Thomas Weißschuh wrote:
> Hi Willy!
>
> On 2025-01-22 19:52:06+0100, Willy Tarreau wrote:
> > On Wed, Jan 22, 2025 at 07:41:48PM +0100, Thomas Weißschuh wrote:
> > > @@ -173,7 +170,7 @@ test_arch() {
> > >
Hi Thomas!
On Wed, Jan 22, 2025 at 07:41:48PM +0100, Thomas Weißschuh wrote:
> @@ -173,7 +170,7 @@ test_arch() {
> exit 1
> esac
> printf '%-15s' "$arch:"
> - swallow_output "${MAKE[@]}" CFLAGS_EXTRA="$CFLAGS_EXTRA" "$test_target"
> V=1
> + swallow_output
Hi Thomas!
On Sun, Dec 22, 2024 at 12:39:01PM +0100, Thomas Weißschuh wrote:
> > Maybe it will be time for us to run an overall audit of arch-dependent
> > syscalls we currently have, to make sure that the common ones continue
> > to work fine there (and waitpid() definitely is as common a syscall
Hi Thomas!
On Sat, Dec 21, 2024 at 03:44:28PM +0100, Thomas Weißschuh wrote:
> waitid() is the modern variant of the family of wait-like syscalls.
> Some architectures have dropped support for wait(), wait4() and waitpid()
> but all of them support waitid().
> It is more flexible and easier to use
On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-apply-to-stable", typing
> > instea
Hi Thomas,
On Sun, Sep 10, 2023 at 09:29:01PM +0200, Thomas Weißschuh wrote:
> Newer versions of glibc annotate the poll() function with
> __attribute__(access) which triggers a compiler warning inside the
> testcase poll_fault.
> Avoid this by using a plain NULL which is enough for the testcase.
On Tue, Apr 20, 2021 at 07:56:18AM +0200, Greg Kroah-Hartman wrote:
> I would LOVE it if some "executives" would see the above presentations,
> because then they would maybe actually fund developers to fix bugs and
> maintain the kernel code, instead of only allowing them to add new
> features.
>
Hi Nick,
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> I don't think the introduction of Rust made Firefox _more_ insecure.
> https://wiki.mozilla.org/Oxidation#Within_Firefox
Browsers are human interfaces and do not fundamentally require low
level access to memory/hardware/
On Sun, Apr 18, 2021 at 07:25:08PM +0200, Fawad Lateef wrote:
> I tried booting the userspace compiled with gcc-9.1 and kernel
> compiled with gcc-5.5. But seems like the kernel 3.4.111 is not
> compatible with user-space compiled with gcc-9.1.
> During boot getting error: "FATAL: kernel too old."
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote:
> Sure, there are better ways to handle the reassembly cache overflowing, but
> that is pretty unrelated to the fact that waiting 30 full seconds for a
> fragment to come in doesn't really make sense in today's networks (the 30
> second
On Sat, Apr 17, 2021 at 04:24:43PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 17, 2021 at 01:46:23PM +0200, Willy Tarreau wrote:
> > For me the old trick of casting one side as long long still works:
> >
> > unsigned long long mul3264(unsigned int a, unsigned int b)
>
On Sat, Apr 17, 2021 at 02:53:10PM +0100, Wedson Almeida Filho wrote:
> > > Note that this is
> > > another area where Rust offers advantages: read-only guards (in C, if you
> > > take a
> > > read lock, nothing prevents you from making changes to fields you should
> > > only be
> > > allowed to
On Sat, Apr 17, 2021 at 01:17:21PM +0200, Peter Zijlstra wrote:
> Well, I think the rules actually make sense, at the point in the syntax
> tree where + happens, we have 'unsigned char' and 'int', so at that
> point we promote to 'int'. Subsequently 'int' gets shifted and bad
> things happen.
That
On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
> How about at least allow the existing queue to finish? Currently a tiny new
> fragment would potentially invalid all previous fragments by letting them
> timeout without allowing the fragments to come in to finish the assembly.
Because th
On Sat, Apr 17, 2021 at 06:44:40AM +0200, Eric Dumazet wrote:
> On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
> >
> > [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
>
> I think this has been discussed already. There is no strategy that
> makes IP reassembly units immune to DDOS at
On Sat, Apr 17, 2021 at 01:46:35AM +0200, Miguel Ojeda wrote:
> On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
> >
> > But my point remains that the point of extreme care is at the interface
> > with the rest of the kernel because there is a change of semantics
> &
On Fri, Apr 16, 2021 at 11:39:00PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
> >
> > No, two:
> > - ok in %rax (seems like it's "!ok" technically speaking since it
> > returns 1 on !ok and 0 on ok)
> >
On Fri, Apr 16, 2021 at 03:34:50PM -0500, Connor Kuehl wrote:
> On 4/16/21 3:22 PM, Willy Tarreau wrote:
> > So it simply does the equivalent of:
> >
> > #define EINVAL -1234
> >
> > struct result {
> > int status;
> > int error;
> &
On Fri, Apr 16, 2021 at 08:57:07PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
> >
> > How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> > along the lines of "if argument matches Err(_), return Err(_)", the types
> > shouldn't be an issue,
Hi Miguel,
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> And by having the compiler enforce this safe-unsafe split, you can
> review safe code without having to constantly worry about UB; and be
> extra alert when dealing with `unsafe` blocks.
I do appreciate this safe/unsafe sp
On Fri, Apr 16, 2021 at 04:33:51PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote:
> > Does this also not prohibit constructs where modification must be done
> > while holding two locks, but reading can be done while holding either
> > lock?
>
>
On Fri, Apr 16, 2021 at 10:16:05AM +0200, Michal Kubecek wrote:
> And I don't see how the two languages might coexist peacefully without
> rust toolchain being necessary for building any kernel useful in
> practice and anyone seriously involved in kernel development having to
> be proficient in bot
erity: ("Unused value")
> Signed-off-by: Colin Ian King
Indeed you're right.
Acked-by: Willy Tarreau
Willy
On Thu, Apr 15, 2021 at 06:43:43AM +0200, Borislav Petkov wrote:
> On Wed, Apr 14, 2021 at 05:57:22PM -0400, Len Brown wrote:
> > I'm pretty sure that the "it isn't my use case of interest, so it
> > doesn't matter" line of reasoning has long been established as -EINVAL
> > ;-)
>
> I have only a v
On Wed, Apr 14, 2021 at 11:58:04AM +0200, Borislav Petkov wrote:
> On Tue, Apr 13, 2021 at 03:51:50PM -0400, Len Brown wrote:
> > AMX does the type of matrix multiplication that AI algorithms use. In
> > the unlikely event that you or one of the libraries you call are doing
> > the same, then you w
On Mon, Apr 12, 2021 at 07:46:06PM -0400, Len Brown wrote:
> On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote:
>
> > AMX: Multiplying a 4x4 matrix probably looks *great* in a
> > microbenchmark. Do it once and you permanently allocate 8kB (is that
> > even a constant? can it grow in newer
On Mon, Mar 29, 2021 at 11:51:38AM +0200, Gustavo Pimentel wrote:
> Signed-off-by: Gustavo Pimentel
Please make an effort, this is in no way an acceptable commit description
for a patch. The subject is already extremely vague "FIX driver" with no
context at all, and there is no description of the
On Sun, Mar 28, 2021 at 11:14:05PM +0300, Andy Shevchenko wrote:
> On Sunday, March 28, 2021, Willy Tarreau wrote:
>
> > Hi Thomas,
> >
> > On Sun, Mar 28, 2021 at 03:07:24AM +0200, Thomas Gleixner wrote:
> > > On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
&
On Sun, Mar 28, 2021 at 03:30:29PM +0200, Willy Tarreau wrote:
> On Sun, Mar 28, 2021 at 02:37:55PM +0200, Mateusz Jonczyk wrote:
> > W dniu 28.03.2021 o 00:25, Willy Tarreau pisze:
> > > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> > > 32-bit.
On Sun, Mar 28, 2021 at 02:37:55PM +0200, Mateusz Jonczyk wrote:
> W dniu 28.03.2021 o 00:25, Willy Tarreau pisze:
> > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> > 32-bit. I had already tried in the past but wanted to give it a try
> > again in
Hi Thomas,
On Sun, Mar 28, 2021 at 03:07:24AM +0200, Thomas Gleixner wrote:
> On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
> > On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> >
Hi,
On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> W dniu 27.03.2021 o 21:32, Mateusz Jonczyk pisze:
> > Hello,
> >
> > There are some netbooks with Intel Atom processors that have 64-bit
> > support disabled by BIOS. Theoretically, the processor supports 64-bit
> > operation,
1 - 100 of 2132 matches
Mail list logo
