e small comments, you can take my ack for the whole
series: Acked-by: Willy Tarreau
Thanks!
Willy
switch (*mode) {
case 'r": flags = O_RDONLY; break;
case 'w': flags = O_WRONLY | O_CREAT | O_TRUNC; break;
case 'a': flags = O_WRONLY | O_CREAT | O_APPEND; break;
default : SET_ERRNO(EINVAL); return NULL;
}
if (mode[1] == '+')
flags = (flags & ~(O_RDONLY|O_WRONLY)) | O_RDWR;
I think it does the same but should be significantly lighter.
Willy
tarted
as root.
Willy
EXPECT_EQ(1, abs(-10), 10);
> break;
> CASE_TEST(abs_noop);EXPECT_EQ(1, abs(10), 10);
> break;
> + CASE_TEST(difftime);EXPECT_EQ(1, difftime(200.,
> 100.), 100.); break;
Then here maybe test it in reverse to make sure the types don't cause trouble:
CASE_TEST(difftime);EXPECT_EQ(1, difftime(100.,
200.), -100.); break;
Willy
from the other
series here.
> +#ifndef _NOLIBC_SYS_TIMERFD_H
> +#define _NOLIBC_SYS_TIMERFD_H
> +
> +#include "../sys.h"
> +#include "../time.h"
Willy
to "only" multiple seconds. I'm not seeing any easy solution to this,
but we need to keep an eye on this one, and in case of bad reports,
maybe have this test as an opt-in or something like this. Anyway the
best way to know is to have it right now and wait for reports to
arrive.
Willy
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
e
> further patches on. For that I'd like to pick up all the nolibc patches from
> this series through the nolibc tree. They got Acks from Willy.
>
> Any objections?
No objection on my side!
Willy
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
len++;
}
len += utoa_r(uin, buffer);
return len;
}
I'm also seeing a way to make it even smaller than the original by
changing utoa_r() so that it takes the original buffer in a 3rd
argument and emits the difference at the end as the length. This
allows to always perform a tail call, though I'm not sure we really
need it.
Thanks,
Willy
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
_attribute__((no_sanitize("function")))
> +#endif
I'm wondering if it wouldn't be more reliable with:
#if __nolibc_has_attribute(no_sanitize)
__attribute__((no_sanitize("function")))
#endif
Because in the end, what you want is to always place that attribute
whenever it's supported, no ?
> void _start_c(long *sp)
> {
> long argc;
Willy
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
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
inux-nolibc.git/log/?h=next
Really nice work, thank you, particularly for making the waitpid() and
printf() families more standard. Please accept my Acked-by on all the
nolibc parts. As usual, proceed as you see fit for the ones I commented
and assume the Acked-by for adjustments following the same spirit ;-)
Cheers,
Willy
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
^^^
Here as well, since it's not meant to be exposed to the application.
> +static int _fprintf_cb(intptr_t state, const char *buf, size_t size)
Likewise here I think.
Willy
or leave a blank line between each
declaration.
> +static __inline__
> +int getopt(int argc, char * const argv[], const char *optstring)
It would be better marked with the usual unused attribute. That's a
bit large for inlining, and I'm not convinced that the compiler will
see any opportunity for simplifying it given that it acts on a list
of actions taken from a string.
Willy
" that's expected to be 64 bits:
CASE_TEST(uintmax_t);EXPECT_VFPRINTF(20, "18446744073709551615", "%ju",
0xULL); break;
Do we really have guarantees that a compiler will always declare
it as a 64-bit or unsigned long long ? E.g. we could see new
compilers decide that uintmax_t becomes 128-bit. Well, maybe in
that case it will simply be a matter of updating the test case
after all...
Willy
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
milarly on gcc-5.5
(ld-2.27) and gcc-6.5 (ld-2.32), but work for gcc-7.5 with ld-2.32, while
other combinations do work:
$ ./nolibc-test|grep -i cst
17 linkage_cst = 1[OK]
18 linkage_cst_ord = 18 [OK]
All of
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
ed some discussion)
BTW, I wanted to thank you for this work. Originally when I started with
nolibc, I thought the vdso was out of reach due to the many missing
definitions. Turns out you were braver than me ;-)
Cheers,
Willy
vide the various limits we rely on. I remember that in
the early days of nolibc-test we had to exclude it as well for nolibc.
What do you think? The less we need to patch programs to insert #ifndef
NOLIBC, the better.
Cheers,
Willy
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
> >
the first place (in which case we're having a deeper problem).
> >
> > nolibc itself does not assume that $sp is aligned.
> > Maybe Willy can explain the historical background.
>
> I'm all ears.
I had a look, that's interesting. Actually this started in the
>*/
> +#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
t.d_name, ldir->d_name, sizeof(dirent.d_name));
Just out of curiosity, could this copy fail, and if so, should we handle
it (e.g. NAME_MAX != 255) ? My guess here is that if it could almost never
fail and checking it would needlessly complicate the function, let's just
handle it with a comment for now. And if it cannot at all, let's mention
why on top of it as well.
Thanks,
Willy
mands with side-effects
> together.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Willy Tarreau
Willy
longer needed thanks to your change above, but to we really
want to get rid of that feature allowing anyone to add their own extra
config ? I'm not sure. For example maybe the current build script helps
on bare metal, when trying to add support for new archs or other features
not yet in defconfig ? We could leave EXTRACONFIG_* empty by default and
user-defined, as I don't feel like it blocks anything to keep it.
Just my two cents,
Willy
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() {
> > >
before the original one and get these
guarantees (and also make them explicit). That's also less edit when
copy-pasting from the terminal to the shell when trying to debug.
Just my few cents ;-)
Willy
t
open() ...
etc. I could try to work on such a thing if you're interested as well, but
not now as I don't have the time at the moment.
Cheers,
Willy
to make sure that the common ones continue
to work fine there (and waitpid() definitely is as common a syscall as
open() since it's the good old and portable one).
Cheers,
Willy
quot; or
"no backport needed unless blablabla" for everything that is only
relevant to the dev tree, and that's a huge time saver for those working
on the backports later.
Maybe "not-for-stable" would be both shorter and easier to remember BTW ?
Regards,
Willy
ight be emulated.
Feel free to push it to the shared repo.
Thanks!
Willy
es clear about mainlining drivers and what to expect for
users (in which case the end of support would be clear and nobody
would be surprised if the driver is removed at the end of its
maintenance, barring a switch to a community maintainer).
Just my two cents,
Willy
r compiler, or
if the only response will have to be between "let's disable this driver
that does not compile" or "please force distros to upgrade their
compilers".
But we'll see :-/
Regards,
Willy
n gcc. So you should use the most
recent libc that still claims to support that kernel, and use the
most recent compiler your libc can be built with (maybe yours is
OK but I don't know).
Hoping this helps,
Willy
datagrams need to wait that long, then new datagrams systematically
prevent the oldest one from being reassembled, and none gest reassembled.
With a random approach at least your success ratio converges towards 1/e
(i.e. 36%) which is better.
Willy
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)
>
our code with what they think is better for you, (including
nothing), so I guess all of this is really not for someone like me.
However while I'm pretty sure that based on our respective experiences
we'd probably disagree forever on a wide number of approaches when it
comes to deciding whether the developer or the compiler should have the
last say, I sincerely appreciate that you take the time to calmly explain
your differing views and the rationale behind, so many thanks for this!
Willy
mov0x8(%esp),%eax
4: f7 64 24 04 mull 0x4(%esp)
8: c3ret
x86_64:
:
0: 89 f8 mov%edi,%eax
2: 89 f7 mov%esi,%edi
4: 48 0f af c7 imul %rdi,%rax
8: c3retq
Or maybe you had something else in mind ?
Willy
resources that are unusuable by others.
Willy
ution is to make sure they
can store all the traffic they receive during a reassembly period.
Legitimate traffic mostly reassembles quickly so keeping 1 second of
traffic at 10 Gbps is only 1.25 GB of RAM after all...
Willy
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;
> &
result you'd do something like this:
result = foo_alloc();
if (!result)
return -ENOMEM;
So it might possibly be safer to stick to the usually expected return
values instead of introducing composite ones.
I tend to agree that composite results can be better from new projects
started from scratch when all the API follows this principle, but here
there's quite a massive code base that was not designed along these
lines and I easily see how this can become a source of trouble over
time.
Willy
usage, I'm really not convinced at all it's suited for
low-level development. I understand the interest of the experiment
to help the language evolve into that direction, but I fear that
the kernel will soon be as bloated and insecure as a browser, and
that's really not to please me.
Cheers,
Willy
behind. What is important
in my opinion is to let developers express what they want and report
suspicious constructs, not to force them to dirtily work around rules
that conflict with their use case :-/
Willy
eviews of the
boundaries between the two languages almost inexistent. This is precisely
what will become the new playground of attackers, and I predict a
significant increase of vulnerabilities past this point. Time will tell,
hoping it's never too late to rollback if it gets crazy. As long as the
code remains readable, it could be rewritten in C to regain control...
> Michal
Willy
erity: ("Unused value")
> Signed-off-by: Colin Ian King
Indeed you're right.
Acked-by: Willy Tarreau
Willy
option, which I'm perfectly fine with. But
conversely not being interested in a feature is also an argument for
insisting that its adoption doesn't harm other use cases (generally
speaking, not this specific case here).
Willy
the Linux machines out there doing AI with
> AMX - at least not anytime soon. If it becomes ubiquitous later, we can
> make it automatic then.
And change jobs :-)
Willy
c part must run as
fast as possible, and even some runtime detection at various points
but do not want to have to deal with extra dependencies that further
increase the test matrix and combinations in bug reports.
Just my two cents,
Willy
escription of the intent here. What is
someone supposed to think about the risk of keeping or reverting it if a
bisect section would end on this one ?
Thanks,
Willy
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
> >
uspected that they
employ cheaper, low-grade CPUs, possibly having been subject to reduced
tests where x86_64-specific parts were not even verified and might be
defective. This may explain why they forcefully disable long mode there,
but that's just speculation.
Cheers,
Willy
On Mon, Mar 22, 2021 at 05:34:48PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 22, 2021 at 5:26 PM Willy Tarreau wrote:
> > On Mon, Mar 22, 2021 at 05:18:23PM +0100, Arnd Bergmann wrote:
> > > and a lot mostly harmless code like
> > >
> > > #ifdef
printk() into no_printk() means we can catch
> the wrong format string during compile testing.
Hmmm OK for this one. With this said, given how plenty of warnings seem
to consider indent and whatever, I wouldn't be surprised if a difference
is made between a totally empty body and one that results from an empty
macro. But indeed this one can represent a real bug.
Willy
:-(
I predict we'll soon see warning such as "this comment looks like valid
C code, if you really intended to comment it out, use #if 0 instead". Oh
well, let's hope I have not given a new idea here...
Willy
On Sat, Feb 27, 2021 at 02:58:18PM -0800, Randy Dunlap wrote:
> On 2/27/21 2:44 PM, Bhaskar Chowdhury wrote:
> >
> > s/occured/occurred/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
Oops, seems like I missed this one, now queued, thanks to you both!
Willy
actly the same. Have you really compared the compiled output code to
explain the difference ? I strongly suspect you'll find no difference at
all.
Thus for me it's certainly not an optimization, it could be qualified as
a cleanup to improve code readability however.
Willy
efinition of the syscalls as defined by POSIX or as commonly
found on other OSes, and this regardless of the platform.
For example look at recv(), it takes an int, a pointer, a size_t and an
int. It requires to be defined like this for portability, but at the OS
level all these will typically be passed as a register each.
Hoping this helps,
Willy
ad531c9d net: macb: Fix passing zero to 'PTR_ERR'
> 0012eeb370f8 net: macb: fix NULL dereference due to no pcs_config method
> e4e143e26ce8 net: macb: add support for high speed interface
In addition, it's worth mentioning that the driver has multiple rx/tx/irq
functions depending on the platforms or chip variants, and that based on
this it should be easy to further reduce this list.
Just my two cents,
Willy
'kernel/uImage'
> kernel/uImage not found!
>
> Strange that I need to run same command twice and that uImage also can not be
> loaded from SystemB
So indeed that has nothing to do with Linux. Maybe your image is much larger
than the previous one and a bug in the u-boot code used to load the image
makes it randomly fail.
Hoping this helps,
Willy
hs ago, I don't remember having
met that issue anymore, so it was likely related to the driver. All I can
say is that 4.19.68 was exhibiting this issue. I can't say for older ones
because I didn't use wifi before.
Just my two cents,
Willy
On Thu, Feb 18, 2021 at 12:16:50PM -0800, Scott Branden wrote:
> On 2021-02-18 10:36 a.m., Greg Kroah-Hartman wrote:
> > On Thu, Feb 18, 2021 at 07:20:50PM +0100, Willy Tarreau wrote:
> >> On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote:
> >>> On T
their use case), it already offloads a lot
of work. I don't think the extra work requires to be much organized if
there are enough participants to share the efforts.
Regards,
Willy
te frankly this is unrivaled, and it illustrates the huge benefit
in almost blindly following LTS this way! More quality, less work, and
faster response to critical bugs! For sure there's no "kernel hero" in
our dev team, but who really wants that anyway ?
Cheers,
Willy
On Thu, Feb 18, 2021 at 04:15:11PM +0200, Jari Ruusu wrote:
> Willy Tarreau wrote:
> > The only set of fixes that can be trusted are the "official" stable
> > kernels, because they are the only ones that are approved by the patches
> > authors themselves. Adding more
ble kernels is fine
(and done at your own risk), but randomly dropping stuff from stable
kernels just because you don't think you need that is totally non-sense
and must not be done anymore!
Willy
ging as
it includes a minimalistic shell. Do you think something like this could
be of any use in your development sessions ? If so I can discuss this
with you in a separate thread so as not to annoy everyone. Just let me
know :-)
Cheers,
Willy
1 - 100 of 2123 matches
Mail list logo
