On 13/02/2023 20.27, Rasmus Villemoes wrote:
> The .su files generated with -fstack-usage are arguably debug info. In
> order to make builds more reproducible, apply the same remapping logic
> to the recorded file names as for when producing the debug info
> embedded in the
The .su files generated with -fstack-usage are arguably debug info. In
order to make builds more reproducible, apply the same remapping logic
to the recorded file names as for when producing the debug info
embedded in the object files.
To this end, teach print_decl_identifier() a new
On 02/11/2022 16.45, Jeff Law wrote:
>
> On 11/2/22 06:35, Rasmus Villemoes wrote:
>> However, when I try to push the new master branch I get
>>
>> $ git push origin master
>> fatal: remote error: service not enabled: /git/gcc.git
>>
>> I do gcc
On 01/11/2022 21.11, Jeff Law wrote:
>
> On 8/29/22 03:29, Rasmus Villemoes wrote:
>> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
>> and -fdebug-prefix-map. However, when building .S or .s files, gas is
>> not called with the appropriate --debu
On 27/09/2022 08.54, Rasmus Villemoes wrote:
> On 12/09/2022 11.46, Rasmus Villemoes wrote:
>> On 29/08/2022 11.29, Rasmus Villemoes wrote:
>>> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
>>> and -fdebug-prefix-map. However, when b
On 12/09/2022 11.46, Rasmus Villemoes wrote:
> On 29/08/2022 11.29, Rasmus Villemoes wrote:
>> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
>> and -fdebug-prefix-map. However, when building .S or .s files, gas is
>> not called with the appropriate --de
On 29/08/2022 11.29, Rasmus Villemoes wrote:
> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
> and -fdebug-prefix-map. However, when building .S or .s files, gas is
> not called with the appropriate --debug-prefix-map option when
> -ffile-prefix-map is used
-ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
and -fdebug-prefix-map. However, when building .S or .s files, gas is
not called with the appropriate --debug-prefix-map option when
-ffile-prefix-map is used.
While the user can specify -fdebug-prefix-map when building assembly
There doesn't seem to be any reason for this TU to include
, and it causes errors when the resulting libstdc++ is used
on our VxWorks 5.5 target - presumably because now libstdc++ itself
contains an instance of std::ios_base::Init. Which should be mostly
harmless, but apparently isn't, and from a
Hi
While trying to upgrade our vxworks 5.5 compiler to gcc12, I've hit a
problem when loading the libstdc++ module on target. It manifests as
[00] tShell memPartFree: invalid block 8bf72c in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf38c in partition 9605dc.
[00]
On 10/12/2021 19.24, Olivier Hainque wrote:
> For the toolchains we build, this is achieved with a few
> configure options like:
>
> --with-sysroot
> --with-build-sysroot=${WIND_BASE}/target
So forward-porting our private patches up until
7bf710b5116 - libstdc++: Add support for '?' in
On 17/12/2021 15.12, Olivier Hainque wrote:
> Hi Rasmus
>
>> On 17 Dec 2021, at 13:49, Rasmus Villemoes
>> wrote:
>
>> I'm not sure what to do. But this patch will definitely break our build
>> - primarily because we've done a private workaround.
>
&g
On 17/12/2021 13.14, Olivier Hainque wrote:
> Hello,
>
> yvals.h on VxWorks expects the toolchain to provide its own
> version of the header, which we don't do.
>
> The attached patch adds a fixincludes hack to arrange to fallback
> on the common system definitions instead.
>
> We were able to
On 17/12/2021 13.10, Olivier Hainque wrote:
> Hello,
>
> The attached patch adds a fixincludes add for VxWorks
> to add missing FP_ constant definition to math.h, intended
> for old versions of the kernel math.h header.
Don't you also need to add an fpclassify() macro? There's a
checking for
On 17/12/2021 13.01, Olivier Hainque wrote:
> Hello,
>
> The attach patch adds a fixincludes "hack" for VxWorks
> to expose a more flexible (varargs) function prototype for 'open',
> able to accept calls with 2 or 3 arguments as we observe
> during libraries builds for powerpc vxworks 6.9.
>
>
On 10/12/2021 16.06, Olivier Hainque wrote:
> Hello,
>
> The attached patch for libstdc++ / VxWorks helps building
> the library for old versions of the OS, as witnessed with
> VxWorks 6.9 in particular.
>
> It explicitly requests C99 features from old system headers,
> on which libstc++ relies
On 10/12/2021 15.20, Olivier Hainque wrote:
> Hi again Rasmus,
>
>> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>>
>> When the translation unit itself creates pointers to the ctors/dtors
>> in a specific section handled by the linker (whether .init_array or
&
On 10/12/2021 14.08, Olivier Hainque wrote:
> Hello,
>
> The attached patch is the one originally sent by Rasmus at
>
> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
>
> and which escaped the radar at the time.
>
> The change looked good and turned out helpful in
On 02/12/2021 16.29, Olivier Hainque wrote:
> Hi Rasmus,
>
> Some new on this.
>
>> On 20 Nov 2021, at 09:07, Olivier Hainque wrote:
>>
>> I'll check how our build sequence proceeds.
>
> Turns out our build succeeds thanks to the presence
> of a vendor version of stdint.h in the VxWorks6/7
The transposition nolto -> notlo is confusing and it makes the long
name even harder to read than it already is - I kept reading it as
"not lo" until I realized it was a simple typo.
Fixes: 5269b24605b1 (Silence warning in LTO mode on VxWorks)
lto-plugin/
* lto-plugin.c: Fix
On 01/12/2021 14.17, Richard Biener wrote:
> On Wed, Dec 1, 2021 at 12:08 PM Rasmus Villemoes
> wrote:
>>
>> The transposition nolto -> notlo is confusing and it makes the long
>> name even harder to read than it already is - I kept reading it as
>> "not lo&
The transposition nolto -> notlo is confusing and it makes the long
name even harder to read than it already is - I kept reading it as
"not lo" until I realized it was a simply typo.
Fixes: 5269b24605b1 (Silence warning in LTO mode on VxWorks)
lto-plugin/
* lto-plugin.c: Fix
On 19/11/2021 19.11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 12 Nov 2021, at 17:35, Olivier Hainque wrote:
>
> Your error triggers on O2ggnu++0x.gch and we configure with
> --disable-libstdcxx-pch.
>
> Can you see if adding this to your configuration options helps
> on your end?
ISTR I
Commit bbbc05957e (Arrange to preinclude yvals.h ahead of stdint on
VxWorks 7) breaks the build of libstdc++ for our VxWorks 5 platform.
In file included from
.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72,
from
According to
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-03/msg01698.html, the
TLS support, including the __tls_lookup function, was added to VxWorks
in 6.6.
It certainly doesn't exist on our VxWorks 5 platform, but the fallback
code in eh_globals.cc using __gthread_key_create() etc. used to
On 05/11/2021 16.12, Olivier Hainque wrote:
>
>
>> On 5 Nov 2021, at 15:12, Rasmus Villemoes wrote:
> We happen to also have a few fixincludes hunks around. Some of
> them have been there for years now and I thought would be nice to
> propagate at some point.
>
> Do
On 05/11/2021 15.08, Olivier Hainque wrote:
>
>
>> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote:
>> Applied to master and pushed - hope I've done it right.
>
> AFAICS, yes.
>
>> How about the gcc-11 branch, can it be applied there as well,
>
>
On 05/11/2021 09.08, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote:
>>
>> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
>> Thus we need to test its value, not its definedness.
>>
>> F
The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
Thus we need to test its value, not its definedness.
Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6).
gcc/ChangeLog:
* config/vx-common.h: Test value of TARGET_VXWORKS7 rather
than definedness.
---
When vxcrtstuff.c was created, the set of #includes was copied from
crtstuff.c. But crtstuff.c also has a bunch of #undefs after the first
#include, because, as the comment says, including auto-host.h when
building objects that are meant for target is technically not
correct.
This manifests when
When the translation unit itself creates pointers to the ctors/dtors
in a specific section handled by the linker (whether .init_array or
.ctors.*), there's no reason for the functions to have external
linkage. That ends up polluting the symbol table in the running
kernel.
This makes vxcrtstuff.c
These declarations prevent the priority given in the
constructor/destructor attributes from taking effect, thus emitting
the function pointers in the ordinary (lowest-priority)
.init_array/.fini_array sections.
libgcc/
* config/vxcrtstuff.c: Remove constructor/destructor
Since commit 78e49fb1bc (Introduce vxworks specific crtstuff support),
the generic crtbegin.o/crtend.o have been unnecessary to build. So
remove them from extra_parts.
This is effectively a revert of commit 9a5b8df70 (libgcc: add
crt{begin,end} for powerpc-wrs-vxworks target).
libgcc/
*
From: Rasmus Villemoes
A few things I hit when trying to upgrade our VxWorks5 toolchain. I
don't think these can break anything for VxWorks 6+, and patch 2
should be an improvement for all in that the current code doesn't get
compiled as it was clearly intended - though the real bug is likely
On 15/04/2020 10.52, Olivier Hainque wrote:
> Hi Rasmus,
>
> Thanks for your proposal.
>
> This is an issue we discussed a bit very recently
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html
>
> and it's nice to see a proposal not requiring
> the replication of all the link
On 06/04/2020 23.18, Joseph Myers wrote:
> On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
>
>> +#ifndef OUTFILES_SPEC
>> +#define OUTFILES_SPEC "%o"
>> +#endif
>
> A new target macro needs to be documented in tm.texi.in,
Will do.
> with tm.texi then bei
o override all of the
link_command, but that's a lot of logic to copy-paste and keep in
sync.
gcc/ChangeLog:
2020-04-04 Rasmus Villemoes
* gcc.c (OUTFILES_SPEC): New spec, hook for wrapping or
overriding %o.
---
I'm not quite up to speed on how the gcc repo w
On 12/09/2019 23.54, Nick Desaulniers wrote:
> On Sat, Sep 7, 2019 at 6:11 AM Segher Boessenkool
> wrote:
>>
>> On Fri, Sep 06, 2019 at 06:04:54PM -0700, Nick Desaulniers wrote:
>>
>>> How would you even write a version check for that?
>>
>> I wouldn't. Please stop using that straw man. I'm not
On 05/09/2019 15.45, Segher Boessenkool wrote:
> Hi Rasmus,
>
> On Thu, Sep 05, 2019 at 01:07:11PM +0200, Rasmus Villemoes wrote:
>> On 05/09/2019 02.18, Nick Desaulniers wrote:
>>> Is it too late to ask for a feature test macro? Maybe one already
>>> exists
On 05/09/2019 02.18, Nick Desaulniers wrote:
> On Fri, Aug 30, 2019 at 4:15 PM Rasmus Villemoes
> wrote:
>>
>> This adds an asm_inline macro which expands to "asm inline" [1] when gcc
>> is new enough (>= 9.1), and just asm for older gccs and other
>
Currently, .cfi_endproc and FUNC_END(__trampoline_setup) are placed
inside the #else branch of an "#if defined (__VXWORKS__) ...", so
non-pic vxworks does not get proper CFI nor a .size directive for
__trampoline_setup. I assume there's no magic reason for that (which
would warrant a comment), so
Just as one needs run-time initialization of mutexes, one needs to
destroy them properly to allow the OS to release resources associated
with the semaphore.
==changelog==
libgcc/
* config/gthr-vxworks.h (__gthread_mutex_destroy): Call semDelete.
---
libgcc/config/gthr-vxworks.h | 3 ++-
One target file (config/c6x/t-elf) lists _printf and _gcc_bcmp in
LIB2FUNCS_EXCLUDE, but that does not have any effect, since those are
not filtered away from LIB2FUNCS_ST. Another option is to do as in
config/rl78/t-rl78, which explicitly sets LIB2FUNCS_ST
# Remove __gcc_bcmp from LIB2FUNCS_ST
VxWorks doesn't use the __eabi function (in fact, the ecrti.o and
ecrtn.o files are not added to extra_parts). This means that the
__SBSS_END__ etc. symbols in eabi.S are always undefined. This is mostly
harmless, but it is inconvenient when one wants to create a libgcc
runtime module by doing a
A quick experiment reveals that this hack is needed for C code - simply
removing this hack entirely breaks the build of libstdc++, since
regs.h (more accurately, the cpu-specific header it pulls in) defines
structs in terms of types from vxTypesOld. Those definitions are
properly guarded by
On 2018-09-14 14:39, Olivier Hainque wrote:
>
>
>> On 13 Sep 2018, at 00:25, Rasmus Villemoes wrote:
>
>>> What happens on your end if you just remove the hack ?
>
>> Unfortunately, the libstdc++ build breaks:
>>
>> In file included from
>>
On 2018-09-05 11:38, Olivier Hainque wrote:
> Hi Rasmus,
>
> I think we should either do a fixinclude that would "work" for
> C and ASM (like #include vxCpu for ASM, vxTypesOld otherwise), or
> simply remove this hack (just using the fixinclude parlance here).
>
> My inclination would be for the
On 2018-09-03 14:11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 27 Jun 2018, at 16:27, Rasmus Villemoes wrote:
>> * inclhack.def (AAB_vxworks_regs_vxtypes): Guard include of
>> types/vxTypesOld.h by #ifndef _ASMLANGUAGE.
>> * fixincl.x: Reg
On 2018-06-28 10:43, Rasmus Villemoes wrote:
> In order to allow ZCX on VxWorks, we need the frame_dummy function to do
> the register_frame_info(). So make sure crtbegin.o and crtend.o are
> available for use with a custom spec file.
Hi Olivier
Can I also have your explicit ok for
On 2018-08-10 17:59, Olivier Hainque wrote:
> Hello Rasmus,
>
>> On 28 Jun 2018, at 10:43, Rasmus Villemoes wrote:
>>
>> Assume that if the user passed --enable-initfini-array when building
>> gcc, the rest of the toolchain (including the link spec and linker
>
The rationale for the fixinclude ioctl macro wrapper is, as far as I can
tell (https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01619.html)
Fix 2: Add hack for ioctl() on VxWorks.
ioctl() is supposed to be variadic, but VxWorks only has a three
argument version with the third argument of type
* functions.
2018-06-01 Rasmus Villemoes
gcc/
* config/vxworks.h: Guard vxworks_asm_out_constructor and
vxworks_asm_out_destructor by !HAVE_INITFINI_ARRAY_SUPPORT
* config/vxworks.c: Likewise.
---
gcc/config/vxworks.c | 2 ++
gcc/config/vxworks.h | 2 ++
2 files
In order to allow ZCX on VxWorks, we need the frame_dummy function to do
the register_frame_info(). So make sure crtbegin.o and crtend.o are
available for use with a custom spec file.
2018-06-04 Rasmus Villemoes
libgcc/
* config.host: Add crtbegin.o and crtend.o for
powerpc
ional) use of .init_array.*
sections instead of .ctors.* - however, that is the case regardless of this
patch.
2018-06-04 Rasmus Villemoes
gcc/
config/vxworks.c: Set targetm.have_ctors_dtors if
HAVE_INITFINI_ARRAY_SUPPORT.
config/vxworks.h: Set SUPPORTS_INI
-nostdinc), since that flag will now
be ignored. I can't know whether that will break anything, but I do
believe it makes sense to have the defaults actually usable without
expecting all invocations to add -I/-isystem flags.
2018-06-04 Rasmus Villemoes
gcc/
* config/vxworks.h: Add $
code
from the compiler binary. But the preprocessor directives also serve
as a reminder that the custom vxworks functions will not be used if
the compiler is built with --enable-initfini-array.
Rasmus Villemoes (4):
vxworks: add target/h/wrn/coreip to the set of system include paths
libgcc: add
On 2018-06-27 21:22, Rainer Orth wrote:
> Hi Jeff,
>
>>> So add an option for disabling build and install of libgcov and the
>>> related host tools.
>>>
>>> 2018-06-10 Rasmus Villemoes
>>>
>>> gcc/
>>> * con
VxWorks' regs.h does include some files that need types defined in
vxTypesOld.h, and it does not itself include that header, directly or
indirectly. Moreover, vxTypesOld.h ends up pulling in definitions of
various cpufamily macros (from types/vxCpu.h) that are also needed
directly by regs.h.
On 2018-06-19 18:45, Olivier Hainque wrote:
> Hi Rasmus,
>
>
> 1/6:
>> vxworks: add target/h/wrn/coreip to the set of system include paths
>
> As we discussed on the message dedicated to this patch, this
> one is ok.
>
> For the rest, I still have concerns for part of the patches. Some
>
When adding the vxworks_iolib_include_unistd hack I failed to add the
appropriate hunk to the tests/base/ioLib.h file, causing "make
check-fixincludes" to fail.
OK for trunk?
2018-06-26 Rasmus Villemoes
fixincludes/
* tests/base/ioLib.h [VXWORKS_IOLIB_INCLUDE_UNISTD_C
@@ -1,3 +1,7 @@
+2018-06-26 Rasmus Villemoes
+
+ * MAINTAINERS (write after approval): Add myself.
+
2018-06-19 Nick Clifton
* zlib/configure.ac: Restore old behaviour of only enabling
diff --git a/MAINTAINERS b/MAINTAINERS
index 928f5cb37ae..f50f61ffb0e 100644
--- a/MAINTAINERS
On 2018-06-20 14:35, Martin Liška wrote:
> On 06/20/2018 02:19 PM, Tom de Vries wrote:
>> Hi,
>>
>> for make check-fixincludes I'm seeing:
>> ...
>> cmp: EOF on
>> /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
>> *** ioLib.h 2018-06-20 14:14:40.035956737 +0200
>> ---
On 2018-06-12 23:34, Olivier Hainque wrote:
>
>
>> On 12 Jun 2018, at 23:12, Jeff Law wrote:
>>
>> I'm going to defer to Olivier on all 6 parts of this kit. He knows
>> vxworks far better than I.
>
> No pb. I haven't forgotten about this :)
>
> As I mentioned on another
> thread, exceptions
to not be
compiled.
So add an option for disabling build and install of libgcov and the
related host tools.
2018-06-10 Rasmus Villemoes
gcc/
* configure.ac: Add --disable-gcov option.
* configure: Regenerate.
* Makefile.in: Honour @enable_gcov@.
* doc/install.texi
to have any purpose,
since $@ is not used afterwards. Remove that logic to not confuse a
reader.
There's no (longer) any autogen package at the gcc/infrastucture
URL. Update to the folder pointed to by the downloads link on
autogen's webpage.
2018-06-09Rasmus Villemoes
fixincludes
underlying __assert
function just takes a single string, so we can't get completely rid of
the stringifying macros. I left the names alone since the risk of
clashing with real user code is quite minimal, and somebody might even
have used them.
2018-06-07Rasmus Villemoes
fixinclude/
2018-05-26 Rasmus Villemoes <rasmus.villem...@prevas.dk>
libgcc/
* crtstuff.c: Remove declaration of _Jv_RegisterClasses.
---
libgcc/crtstuff.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 5e894455e16..d81c527a455
2018-05-26 Rasmus Villemoes <rasmus.villem...@prevas.dk>
gcc/
* config/vx-common.h (USE_TM_CLONE_REGISTRY): #define to 0.
---
gcc/config/vx-common.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h
index 7a05b
reject --coverage and -fprofile-arcs, but I couldn't find an easy way to
do that. Also, the similar --disable-libsanitizer does not make the
compiler complain about use of -fsanitize=xyz.
2018-05-25 Rasmus Villemoes <rasmus.villem...@prevas.dk>
gcc/doc/
* install.texi: Document --d
reject --coverage and -fprofile-arcs, but I couldn't find an easy way to
do that.
2018-05-25 Rasmus Villemoes <rasmus.villem...@prevas.dk>
libgcc/
* Makefile.in: Honour @enable_libgcov@
* configure.ac: Add --disable-libgcov option
* configure: Regenerate.
---
system limits.h. So this round-about
does seem to work for limits.h, but I'm wondering why that header file
alone gets special treatment by the gcc build system.
Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk>
---
fixincludes/inclhack.def | 16
1 file changed, 16 ins
2017-10-01 Rasmus Villemoes <r...@rasmusvillemoes.dk>
PR preprocessor/64965
* gcc.c-torture/compile/pr64965.c: New test.
If the current filename contains a newline character, __FILE__ would
expand to a string literal containing an actual embedded newline,
which is of
On Thu, Jan 22 2015, Richard Biener richard.guent...@gmail.com wrote:
On Wed, Jan 21, 2015 at 9:00 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
(sorry for the broken thread, for some reason I haven't received any email
from gcc since about 10am, I'll investigate later)
+/* x ~(x y)
-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk
---
gcc/match.pd | 6 +
gcc/testsuite/gcc.dg/20150120-1.c | 51 +++
2 files changed, 57 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/20150120-1.c
diff --git gcc/match.pd gcc
know almost nothing about the internals of gcc, so 4/4 may very well
be considered ugly - it was what I could stitch together from pieces I
picked up here and there.
Rasmus Villemoes (4):
match.pd: Add x + (x 1) - (x + 1) ~1 pattern
match.pd: Add x ~(x y) - x ~y pattern
match.pd: Add x
Generalizing the x+(x1) pattern, one can round up x to a multiple of
a 2^k by adding the negative of x modulo 2^k. But it is fewer
instructions, and presumably requires fewer registers, to do the more
common (x+m)~m where m=2^k-1.
Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk
---
gcc
it is
spelled x - (x y) or x ^ (x y).
Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk
---
gcc/match.pd | 6 ++
gcc/testsuite/gcc.dg/20150120-2.c | 32
2 files changed, 38 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/20150120-2.c
gcc.dg/20150120-3.c: New test
This is simply the 'dual' of the previous pattern, added for
completeness.
Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk
---
gcc/match.pd | 6 ++
gcc/testsuite/gcc.dg/20150120-3.c | 32
2 files
On Wed, Jan 14 2015, Richard Biener richard.guent...@gmail.com wrote:
On Tue, Jan 13, 2015 at 11:47 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Jan 13, 2015 at 2:41 PM, Rasmus Villemoes r...@rasmusvillemoes.dk
wrote:
[My first attempt at submitting a patch for gcc, so please forgive
[My first attempt at submitting a patch for gcc, so please forgive me
if I'm not following the right protocol.]
Sometimes rounding a variable to the next even integer is written x += x
1. This usually means using an extra register (and hence at least an
extra mov instruction) compared to the
On Thu, Dec 18 2014, H. Peter Anvin h...@zytor.com wrote:
On 12/18/2014 09:43 AM, H.J. Lu wrote:
Peter, please feel free to use my kernel patch or create a different
one.
Great, thanks!
Thanks for accepting this idea, and especially to H.J. for already
having done all the work.
Minor
81 matches
Mail list logo
