To enable hardware acceleration, this commit ports the feature detection
logic from libgcrypt. This allows us to check if the compiler supports
specific assembly instructions, including SSSE3, Intel SHA extensions,
SSE4.1, AVX, AVX2, AVX512, and BMI2.
To simplify the initial implementation, suppor
Borrow the code from libgcrypt to check whether the compiler supports
the assembly instructions for SSSE3, SHA extensions, SSSE4.1, AVX, AVX2,
AVX512, and BMI2.
Also tweak _gcry_get_hw_features() in include/grub/crypto.h as the
preparation to support the hardware feature detection function from
li
On Sat, Feb 04, 2023 at 06:26:07PM -0600, Glenn Washburn wrote:
> By using a shell variable that is set once by the expansion of an autoconf
> variable, the resulting script is more readable.
>
> Signed-off-by: Glenn Washburn
Reviewed-by: Daniel Ki
By using a shell variable that is set once by the expansion of an autoconf
variable, the resulting script is more readable.
Signed-off-by: Glenn Washburn
---
tests/util/grub-fs-tester.in | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/tests/util/grub-fs
On Sat, Aug 06, 2022 at 01:26:31AM -0500, Glenn Washburn wrote:
> By using shell variable that are set once by the expansion of an autoconf
> variable, the resulting shell script is more easily moved and modified
> from the build/install directory it was generated for. The resulting
&g
By using shell variable that are set once by the expansion of an autoconf
variable, the resulting shell script is more easily moved and modified
from the build/install directory it was generated for. The resulting
script is more readable as well.
Signed-off-by: Glenn Washburn
---
tests/util
This bring this test in line with the rest of the test scripts.
Signed-off-by: Glenn Washburn
---
tests/f2fs_test.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/f2fs_test.in b/tests/f2fs_test.in
index 1ea77c826..8c415db61 100644
--- a/tests/f2fs_test.in
+++ b/tests/
On Wed, Aug 25, 2021 at 02:04:02AM -0500, Glenn Washburn wrote:
> This bring this test in line with the rest of the test scripts.
>
> Signed-off-by: Glenn Washburn
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https:
This bring this test in line with the rest of the test scripts.
Signed-off-by: Glenn Washburn
---
tests/f2fs_test.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/f2fs_test.in b/tests/f2fs_test.in
index 1ea77c826..8c415db61 100644
--- a/tests/f2fs_test.in
+++ b/tests/
This bring this test in line with the rest of the test scripts.
Signed-off-by: Glenn Washburn
---
tests/f2fs_test.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/f2fs_test.in b/tests/f2fs_test.in
index 1ea77c826..8c415db61 100644
--- a/tests/f2fs_test.in
+++ b/tests/
The remark about "older versions of Autoconf" was added in 2001.
We already AC_PREREQ(2.63) which is from 2008, so we need not
worry about pre-2008 versions of Autoconf, much less about
pre-2001 versions.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/configure.ac b/configur
В Tue, 18 Nov 2014 16:03:08 +0800
Michael Chang пишет:
> Many routers have long router advertisment interval configured by
> default. The Neighbor Discovery protocol (RFC4861) has defined default
> MaxRtrAdvInterval value as 600 seconds and
> MinRtrAdvInterval as 0.33*MaxRtrAdvInterval. This make
Many routers have long router advertisment interval configured by
default. The Neighbor Discovery protocol (RFC4861) has defined default
MaxRtrAdvInterval value as 600 seconds and
MinRtrAdvInterval as 0.33*MaxRtrAdvInterval. This makes
net_ipv6_autoconf fails more often than not as currently it pas
On Sat, Nov 15, 2014 at 07:54:42PM +0300, Andrei Borzenkov wrote:
> В Thu, 13 Nov 2014 17:42:23 +0800
> Michael Chang пишет:
>
> > Many routers have long router advertisment interval configured by
> > default. The Neighbor Discovery protocol (RFC4861) has defined default
> > MaxRtrAdvInterval val
В Thu, 13 Nov 2014 17:42:23 +0800
Michael Chang пишет:
> Many routers have long router advertisment interval configured by
> default. The Neighbor Discovery protocol (RFC4861) has defined default
> MaxRtrAdvInterval value as 600 seconds and
> MinRtrAdvInterval as 0.33*MaxRtrAdvInterval. This make
Many routers have long router advertisment interval configured by
default. The Neighbor Discovery protocol (RFC4861) has defined default
MaxRtrAdvInterval value as 600 seconds and
MinRtrAdvInterval as 0.33*MaxRtrAdvInterval. This makes
net_ipv6_autoconf fails more often than not as currently it pas
ode is longer and less readable. I
> > don't think AC_TRY_COMPILE is a big problem yet. It's not like it won't
> > produce a valid test.
>
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Autoconf-Macro-Index
>
> AC_TRY_COMPILE is listed as `Obs
Am Donnerstag, den 04.09.2008, 12:44 -0400 schrieb Pavel Roskin:
> Fine, but only if we decide to fix the existing warnings. I'm not sure
> it's worth the trouble. Just because a macro is considered obsolete,
> it's not necessarily broken. End users won't run A
utoheader generates it, I just wanted to show the difference with
the newer `AC_USE_SYSTEM_EXTENSIONS' in case someone is interested :)
I saw it now even in the docs it's only supported with autoconf >= 2.60
and because I just don't know enough if it would be safe for us t
On Thu, 2008-09-04 at 09:45 +0200, Felix Zielcke wrote:
> > Okuji wrote that he uses Autoconf 2.59, so it would be nice to check
> > that your changes would still work with that version.
>
> Luckly it's still avaible in Debian oldstable (sarge)
> newest CentOS 5.2 ev
On Thu, 2008-09-04 at 13:16 +0200, Felix Zielcke wrote:
> With my configure.ac autoconf[0] topic I just got the idea to add
> `-Wall' option to `autoconf' in `autogen.sh'
>
> We're using -Wall for gcc so why not for autoconf and autoheader too?
>
> Then
With my configure.ac autoconf[0] topic I just got the idea to add
`-Wall' option to `autoconf' in `autogen.sh'
We're using -Wall for gcc so why not for autoconf and autoheader too?
Then once in a while someone will hopefully notice that something might
need a change and wil
;s not like it won't
> produce a valid test.
http://www.gnu.org/software/autoconf/manual/autoconf.html#Autoconf-Macro-Index
AC_TRY_COMPILE is listed as `Obsolete Macro'.
I attached now even a diff with autoconf 2.62 which I won't commit, but
maybe you or someone else is
Am Mittwoch, den 03.09.2008, 19:47 -0400 schrieb Pavel Roskin:
> You can get the current config.* files from CVS:
> cvs -d :pserver:[EMAIL PROTECTED]:/sources/config co config
> They are maintained in a very conservative matter, so it may be better
> to use the CVS versions. Actually, it's possi
On Wed, 2008-09-03 at 16:51 +0200, Felix Zielcke wrote:
> Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke:
> > Yes I really want to get rid of old stuff and if you even only need to
> > call `autoupdate --force' ;)
> >
>
> Oh and config.guess and config.sub have
> timestamp='2007-0
On Wed, 2008-09-03 at 15:27 +0200, Felix Zielcke wrote:
> Attached patch is generated via `autoupdate --force' from autoconf 2.61
> a svn-diff after ./autogen.sh doestn't show anything more, because
> the ./configure script in SVN is already generated with autoconf 2.61.
&g
Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke:
> Yes I really want to get rid of old stuff and if you even only need to
> call `autoupdate --force' ;)
>
Oh and config.guess and config.sub have
timestamp='2007-07-22'
whereas the versions from automake 1.9 and 1.10 have
timestamp=
Attached patch is generated via `autoupdate --force' from autoconf 2.61
a svn-diff after ./autogen.sh doestn't show anything more, because
the ./configure script in SVN is already generated with autoconf 2.61.
autoconf 2.61 is dated 17.11.2006 on ftp.gnu.org
Debian etch + lenny hav
On Sunday 03 February 2008 20:34, Pavel Roskin wrote:
> I suggest that we require Autoconf 2.61 in configure.ac. It has been
> out for over a year. It's easy to install locally without breaking
> anything. It generates more portable configure scripts than older
> version of A
Hello!
I suggest that we require Autoconf 2.61 in configure.ac. It has been
out for over a year. It's easy to install locally without breaking
anything. It generates more portable configure scripts than older
version of Autoconf (at least it's supposed to, unless there are
regression
ed the config.log output. As you can see it
> > tries to compile the test for the target machine and it uses glibc. I
> > think we have to disable the use of glibc for these autoconf tests.
> > But I am asking to make sure I am not wasting a lot of time by doing
> > th
included the config.log output. As you can see it
>> tries to compile the test for the target machine and it uses glibc. I
>> think we have to disable the use of glibc for these autoconf tests.
>> But I am asking to make sure I am not wasting a lot of time by doing
>> the
t uses glibc. I
> think we have to disable the use of glibc for these autoconf tests.
> But I am asking to make sure I am not wasting a lot of time by doing
> the wrong thing.
I think so. I guess Jeroen simply has installed 32-bit libraries, right?
Okuji
___
Hi,
Either I missed some commit and the instructions how to build on the
AMD64. Below I included the config.log output. As you can see it
tries to compile the test for the target machine and it uses glibc. I
think we have to disable the use of glibc for these autoconf tests.
But I am asking to
34 matches
Mail list logo
