ed, Feb 26, 2025, 21:39
Subject: Re: [External] Re: [PATCH] BugFix: grub menu gets stuck due to
unserialized rdtsc
To: "段亚勇"
Cc: , , <
jinke@bytedance.com>, , <
likunkun@bytedance.com>, "Li Yongqiang", "Sun
Ming"
On Tue, Feb 25, 2025 at 07:19:58PM -0800
On Thu, Nov 28, 2024 at 11:48:26AM +0800, Duan Yayong via Grub-devel wrote:
> Adding "if (grub_tsc_rate == 0)" judgement just in case other unknown
> instruction exception, so that
> "grub_tsc_calibrate_from_pit||grub_tsc_calibrate_from_efi" getting
> "grub_tsc_rate" methods have a opportunity to b
On Tue, Feb 25, 2025 at 07:19:58PM -0800, 段亚勇 via Grub-devel wrote:
> Hi,
>
> That's alright!
> May I know if the first patch is allowed to be merged? And how long will it be
> merged approximately？
> So that I can track it after that time! Thanks!
Sorry, I thought the first patch is earlier vers
, T2B, Xinjiangwan Square, Yangpu District, Shanghai
---
From: "Daniel Kiper"
Date: Tue, Feb 25, 2025, 23:35
Subject: [External] Re: [PATCH] BugFix: grub menu gets stuck due to
unserialized rdtsc
To: "段亚勇"
Cc: , ,
Hi,
On Mon, Feb 24, 2025 at 10:41:38PM -0800, 段亚勇 wrote:
> Hello Daniel,
> May I know the Merge Plan of Grub Master branch?
> From this time, we almost check grub master changes every day
> and take enough patience to wait for the bugfix to be merged.
> But we found the recent u
Hello Daniel,
May I know the *Merge Plan* of Grub Master branch?
>From this time, we almost check grub master changes every day
and take enough patience to wait for the bugfix to be merged.
But we found the recent update of master branch has no our
two bugfix patches. If there are any ex
Hi Daniel,
Sorry for disturbing you again!
May I know the ETA of my two patches arriving at grub master branch?
Because we recognized that debian 12.10 version is going to be planned in
debian community.
We sincerely hope we can use this bugfix in debian 12.10
49
Subject: [External] Re: [PATCH] BugFix: grub menu gets stuck due to
unserialized rdtsc
To: "Duan Yayong"
Cc: , , <
jinke@bytedance.com>, , <
likunkun@bytedance.com>, "Li Yongqiang", "Sun
Ming"
On Mon, Dec 09, 2024 at 02:48:32PM +0800, Duan Yayong wrote:
On Mon, Dec 09, 2024 at 02:48:32PM +0800, Duan Yayong wrote:
> This patch is used to fix grub menu gets stuck in server
> AC poweron/poweroff stress test of x86_64, which is reproduced with 1/200
> ratio. The root cause analysis as below:
>
> Q:
> What's the code logic?
> A:
> "grub_tsc_init" funct
This patch is used to fix grub menu gets stuck in server
AC poweron/poweroff stress test of x86_64, which is reproduced with 1/200
ratio. The root cause analysis as below:
Q:
What's the code logic?
A:
"grub_tsc_init" function will init tsc by setting grub_tsc_rate,
which call stack is:
grub_tsc
- Wrong coding style.
- *The sent patch was fixed before this mail.*
- *The upcoming patch about serialization instruction*
*adjustment will fix it also.*
If there are any other problems, please feel free to let me know.
Thanks for your time again.
---
Best Regards,
段亚勇 Data-SYS-STE
Adding "if (grub_tsc_rate == 0)" judgement just in case other unknown
instruction exception, so that
"grub_tsc_calibrate_from_pit||grub_tsc_calibrate_from_efi" getting
"grub_tsc_rate" methods have a opportunity to be performed but
causing grub menu stucking.
Signed-off-by: Duan Yayong
Signed-off-
On Mon, Nov 11, 2024 at 02:17:19PM +0800, Duan Yayong via Grub-devel wrote:
> This patch is used to fix grub menu gets stuck in server
> AC poweron/poweroff stress test of x86_64, which is reproduced with 1/200
> ratio. The root cause analysis as below:
>
> Q. What's the code logic?
> A. "grub_tsc_
This patch is used to fix grub menu gets stuck in server
AC poweron/poweroff stress test of x86_64, which is reproduced with 1/200
ratio. The root cause analysis as below:
Q. What's the code logic?
A. "grub_tsc_init" function will init tsc by setting grub_tsc_rate, which call
stack is:
grub_ts
On Sun, May 19, 2024 at 05:50:10PM +0200, Pascal Hambourg wrote:
> This is required if the pathname contains spaces or grub shell
> metacharacters, else the generated config file check will fail.
>
> Signed-off-by: Pascal Hambourg
Reviewed-by: Daniel Kiper
Daniel
__
This is required if the pathname contains spaces or grub shell
metacharacters, else the generated config file check will fail.
Signed-off-by: Pascal Hambourg
---
v2: Correct subject
util/grub.d/00_header.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/grub.d/00_heade
This is required if the pathname contains spaces or grub shell
metacharacters, else the generated config file check will fail.
Signed-off-by: Pascal Hambourg
---
util/grub.d/00_header.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/grub.d/00_header.in b/util/grub.d/00
On Thu, Aug 29, 2019 at 01:37:14PM -0700, BJ Black wrote:
> Hi all!
>
> I recently experienced a problem on a fleet of CentOS 6 boxes with GRUB
> 0.97 that had a dodgy CMOS battery and the RTC was broken. In this
> circumstance, the timeout on the GRUB menu never moved because GRUB
> didn't think
Hi all!
I recently experienced a problem on a fleet of CentOS 6 boxes with GRUB
0.97 that had a dodgy CMOS battery and the RTC was broken. In this
circumstance, the timeout on the GRUB menu never moved because GRUB
didn't think any time had passed... So I wrote a fix that monitors both
the 18.2H
Dne 20.12.2013 13:16, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
> On 19.12.2013 20:59, Aleš Nesrsta wrote:
>> Hi Vladimir,
>>
>> it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS
>> corrections" (12/16/2013), will be incl
On 19.12.2013 20:59, Aleš Nesrsta wrote:
> Hi Vladimir,
>
> it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS
> corrections" (12/16/2013), will be included in the final release. It
> solves serious bug.
>
Check the git, it's already there, in
Hi Vladimir,
it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS
corrections" (12/16/2013), will be included in the final release. It
solves serious bug.
I tested it on four different PCs - it is working fine, I saw no
negative results, and it helps on PCs where t
On Saturday, July 20, 2013 06:18:04 PM Andrey Borzenkov wrote:
> В Wed, 17 Jul 2013 21:55:58 +0400
>
> Vladimir Testov пишет:
> > See screenshots included.
> >
> > If the center slice is NULL then west or north slice is also NULL
>
> Why? As far as I can tell code is supposed to scale all parts
В Wed, 17 Jul 2013 21:55:58 +0400
Vladimir Testov пишет:
> See screenshots included.
>
> If the center slice is NULL then west or north slice is also NULL
Why? As far as I can tell code is supposed to scale all parts of
bitmap. What triggers this problem?
>
See screenshots included.
If the center slice is NULL then west or north slice is also NULL so the
height_n or width_w is also NULL. We can count these values from raw (non-
scaled) bitmaps. The values will be the same as before for common cases. And
the bug will be fixed.
--
With best regards
bug found and fixed
Steps to reproduce
1. more than one OS (or dummy entries as in the test stand)
2. one should have more than one kernels (so in additional options there will
be more than one entry)
3. in main boot screen there should be enough entries so the scrollbar appears
4. we should save
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> With this change grub_auth_strcmp becomes a misnomer. I would prefer to
> call it grub_auth_memcmp then. I'll also look into which other free
> secure strcmp are available
Asking developpers of project
Bean wrote:
> On Tue, Nov 10, 2009 at 10:25 PM, Duboucher Thomas
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Bean a écrit :
>>
>>> Hi,
>>>
>>> Oh, I just come up with a better way to do this:
>>>
>>> typedef char grub_password_t[1024];
>>>
>>> int
>>> grub_auth_st
Duboucher Thomas wrote:
> Bean a écrit :
> > Hi,
>
> > My previous function ensures that execution time is the same
> > regardless of the input. Although it's not necessary, I guess it's a
> > nice feature to have. BTW, the simpler function does leak one
> > information, the size of buffer as the e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
>
> Hi,
>
> My previous function ensures that execution time is the same
> regardless of the input. Although it's not necessary, I guess it's a
> nice feature to have. BTW, the simpler function does leak one
> information, the size of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
richardvo...@gmail.com a écrit :
>
> for (it = retval = 0; it < PASSPHRASE_MAXSIZE; it++, input++, key++)
>
>> After changing the parameter type, those postincrements won't do what
>> you expect.
>
Damn examinations; I really need to sleep! =)
On Tue, Nov 10, 2009 at 8:25 AM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bean a écrit :
>> Hi,
>>
>> Oh, I just come up with a better way to do this:
>>
>> typedef char grub_password_t[1024];
>>
>> int
>> grub_auth_strcmp (const grub_password_t s1, const grub_
On Tue, Nov 10, 2009 at 10:25 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bean a écrit :
>> Hi,
>>
>> Oh, I just come up with a better way to do this:
>>
>> typedef char grub_password_t[1024];
>>
>> int
>> grub_auth_strcmp (const grub_password_t s1, const grub
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
> Hi,
>
> Oh, I just come up with a better way to do this:
>
> typedef char grub_password_t[1024];
>
> int
> grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
> {
> char r1 = 0;
> char r2 = 0;
> char *p;
> int
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = &r1;
c = 0;
for (i = 0; i < sizeof (grub_password_t); i++, s1++, s2++)
On Tue, Nov 10, 2009 at 4:52 PM, Bean wrote:
> Hi,
>
> Perhaps this one, it's more symmetrical:
>
> typedef char grub_password_t[1024];
>
> int
> grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
> {
> char r1 = 0;
> char r2 = 0;
> char r3 = 0;
> char *p1, *p2;
> int i;
>
On Tue, Nov 10, 2009 at 4:46 PM, Bean wrote:
> Hi,
>
> Just in case p2 is optimized out by gcc:
>
> typedef char grub_password_t[1024];
>
> int
> grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
> {
> char r1 = 0;
> char r2 = 0;
> char r3 = 0;
> char *p1, *p2;
> int i;
>
On Tue, Nov 10, 2009 at 4:28 PM, Bean wrote:
> On Tue, Nov 10, 2009 at 1:39 PM, Bean wrote:
>> On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
>> wrote:
>>> But now it has a technical problem: it may read post array definitions.
>>> If any of post-array memory is MMIO or absent re
On Tue, Nov 10, 2009 at 1:39 PM, Bean wrote:
> On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
> wrote:
>> But now it has a technical problem: it may read post array definitions.
>> If any of post-array memory is MMIO or absent reading from it may have
>> peculiar consequences
>>>
On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
wrote:
> But now it has a technical problem: it may read post array definitions.
> If any of post-array memory is MMIO or absent reading from it may have
> peculiar consequences
>> Also, because s1 and s2 have two differents roles,
richardvo...@gmail.com wrote:
Hello,
I'd be concerned about (s1 != s2). Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?. I'd be worried about all the ways (and future ways) compilers
might help us and introduce time differe
> Hello,
>
> I'd be concerned about (s1 != s2). Depending on how efficiently this
> compiles, could not branch prediction make this faster for match vs. not
> match, etc?. I'd be worried about all the ways (and future ways) compilers
> might help us and introduce time differences.
I was avoiding
On Mon, Nov 9, 2009 at 4:46 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Robert Millan a écrit :
>> On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>>> Well, the only way to solve that problem would be IMHO to add a limit
>>> to the size
Duboucher Thomas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Millan a écrit :
On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
Well, the only way to solve that problem would be IMHO to add a limit
to the size of s2, and use this maximum size as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Millan a écrit :
> On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>> Well, the only way to solve that problem would be IMHO to add a limit
>> to the size of s2, and use this maximum size as an end condition for the
>> 'fo
On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
> Well, the only way to solve that problem would be IMHO to add a limit
> to the size of s2, and use this maximum size as an end condition for the
> 'for' statement. Any better idea? :)
We have a maximum line read size anyway.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> Duboucher Thomas wrote:
>> Bean a écrit :
>>> Hi,
>>> This one work:
>>> int
>>> auth_strcmp (const char *s1, const char *s2)
>>> {
>>> int result = 0;
>>> while (1)
>>> {
>>> result += (*s1 != *s
Duboucher Thomas wrote:
> Bean a écrit :
> > Hi,
>
> > This one work:
>
> > int
> > auth_strcmp (const char *s1, const char *s2)
> > {
> > int result = 0;
>
> > while (1)
> > {
> > result += (*s1 != *s2);
> > if (*s1 == 0)
> > break;
>
> > s1++;
> > s2++;
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
>
> Hi,
>
> This one work:
>
> int
> auth_strcmp (const char *s1, const char *s2)
> {
> int result = 0;
>
> while (1)
> {
> result += (*s1 != *s2);
> if (*s1 == 0)
> break;
>
> s1++;
> s2++;
>
On Tue, Nov 10, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko
wrote:
> Bean wrote:
>> On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan wrote:
>>
>>> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko
>>> wrote:
>>>
Robert Millan wrote:
> Actually, modern CPUs ar
Bean wrote:
> On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan wrote:
>
>> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>>> Robert Millan wrote:
>>>
Actually, modern CPUs are very complex and the number of operations (or
time taken by
On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan wrote:
> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Robert Millan wrote:
>> >
>> > Actually, modern CPUs are very complex and the number of operations (or
>> > time taken by them) isn't easy to predict.
>> >
>> >
On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> >
> > Actually, modern CPUs are very complex and the number of operations (or
> > time taken by them) isn't easy to predict.
> >
> >
> It's generally a good practice to do exactly same operati
Robert Millan wrote:
> On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote:
>
>> Ok, I typed this in a few minutes and I'm not confident either with
>> what I wrote; I would check that it works first. ;)
>> But the point here is that whatever the user gives as an input, it
On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote:
>
> Ok, I typed this in a few minutes and I'm not confident either with
> what I wrote; I would check that it works first. ;)
> But the point here is that whatever the user gives as an input, it is
> executed exactly n-t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> Bean wrote:
>> On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
>> wrote:
>>
>> Hi,
>>
>> int
>> grub_auth_strcmp (const char *s1, const char *s2)
>> {
>> int ret;
>> grub_uint64_t end;
>>
Bean wrote:
> On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
> wrote:
>
>> Bean wrote:
>>
>>> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan wrote:
>>>
>>>
A security problem [1] was found in our password-checking routines,
which affects GRUB 1.97. I'll be
On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
wrote:
> Bean wrote:
>> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan wrote:
>>
>>> A security problem [1] was found in our password-checking routines,
>>> which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow.
>>>
>>> Additional
On Mon, Nov 09, 2009 at 02:50:36PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> >
> > Actually, the function of grub_auth_strcmp puzzles me, why would it
> > need to wait 100 ms to return the result ?
> 10 ms actually. The goal is to take same amount of time indpendently of
> input values. But pr
On Sun, Nov 08, 2009 at 06:08:39PM -0800, Jordan Uggla wrote:
> None of the .sh scripts ( autogen.sh and the scripts it uses ) are
> executable; I needed to "chmod 744 *.sh" before I could run
> ./autogen.sh successfully. After doing that make failed with an error
> in auth.c. This was with revisio
Bean wrote:
> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan wrote:
>
>> A security problem [1] was found in our password-checking routines,
>> which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow.
>>
>> Additionally, I cherry-picked fixes for a few problems that should
>> have made it to
On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan wrote:
>
> A security problem [1] was found in our password-checking routines,
> which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow.
>
> Additionally, I cherry-picked fixes for a few problems that should
> have made it to the release, like GNU
None of the .sh scripts ( autogen.sh and the scripts it uses ) are
executable; I needed to "chmod 744 *.sh" before I could run
./autogen.sh successfully. After doing that make failed with an error
in auth.c. This was with revision 1780. I've attached the output from
./configure and make.
On Sun, N
On Mon, Nov 09, 2009 at 02:04:22AM +0100, Robert Millan wrote:
> The release branch is available in:
>
> sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/
Or via http if you don't have a Savannah account:
http://bzr.savannah.gnu.org/r/grub/branches/release_1_97/
--
Robert Mil
A security problem [1] was found in our password-checking routines,
which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow.
Additionally, I cherry-picked fixes for a few problems that should
have made it to the release, like GNU/Hurd support (see NEWS file
for details). The release branch i
On Thu, Oct 15, 2009 at 03:06:42PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
> --
> Regards
> Vladimir 'phcoder' Serbinenko
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>
> diff --git a/ChangeLog b/ChangeLog
> index b0864a9..55bdc92 100644
> --- a/ChangeLog
> +++ b/Chan
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index b0864a9..55bdc92 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2009-10-15 Vladimir Serbinenko
+ * kern/parser.c (grub_parser_split_cmd
On Fri, Jul 31, 2009 at 6:17 AM, Pavel Roskin wrote:
> On Fri, 2009-07-31 at 00:46 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> This patch fixes the parsing of two strings like following ones:
>> "echo 1 " was parsed into "echo", "1", ""
>> "echo $root" was parsed into "echo" (variable just disap
On Fri, 2009-07-31 at 00:46 +0200, Vladimir 'phcoder' Serbinenko wrote:
> This patch fixes the parsing of two strings like following ones:
> "echo 1 " was parsed into "echo", "1", ""
> "echo $root" was parsed into "echo" (variable just disappeared)
It would be helpful if you explain how to see the
This patch fixes the parsing of two strings like following ones:
"echo 1 " was parsed into "echo", "1", ""
"echo $root" was parsed into "echo" (variable just disappeared)
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLo
On Fri, Jul 24, 2009 at 05:49:19PM -0400, Pavel Roskin wrote:
> On Fri, 2009-07-24 at 23:02 +0200, Christian Franke wrote:
>
> > A correct performance-aware solution would look like:
> >
> > #ifdef DT_DIR
> > if (de->d_type == DT_DIR)
> > info.dir = 1;
> > else if (de->type == DT_FILE)
>
Pavel Roskin wrote:
On Fri, 2009-07-24 at 23:02 +0200, Christian Franke wrote:
A correct performance-aware solution would look like:
#ifdef DT_DIR
if (de->d_type == DT_DIR)
info.dir = 1;
else if (de->type == DT_FILE)
There in no DT_FILE in glibc, but there is DT_REG.
Yes
On Fri, 2009-07-24 at 23:02 +0200, Christian Franke wrote:
> A correct performance-aware solution would look like:
>
> #ifdef DT_DIR
> if (de->d_type == DT_DIR)
> info.dir = 1;
> else if (de->type == DT_FILE)
There in no DT_FILE in glibc, but there is DT_REG. DT_UNKNOWN is
present. Per
Pavel Roskin wrote:
On Thu, 2009-07-23 at 11:29 +0200, Vladimir 'phcoder' Serbinenko wrote:
-#ifdef DT_DIR
- info.dir = (de->d_type == DT_DIR);
-#else
info.dir = !! is_dir (path, de->d_name);
-#endif
Fine with me. Finally a patch that reduces the number of preprocessor
di
On Thu, 2009-07-23 at 11:29 +0200, Vladimir 'phcoder' Serbinenko wrote:
> -#ifdef DT_DIR
> - info.dir = (de->d_type == DT_DIR);
> -#else
>info.dir = !! is_dir (path, de->d_name);
> -#endif
Fine with me. Finally a patch that reduces the number of preprocessor
directives :-)
--
Rega
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index a0780ab..16aab92 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2009-07-23 Vladimir Serbinenko
+
+ * util/hostfs.c (grub_hostfs_dir):
Hello. If syntax error in menu entry occurs it oftens results in the
menu cut after first line. Here is the fix
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
diff --git a/ChangeLog b/ChangeLog
index a0780ab..8824f1c 100644
--- a/ChangeLog
Hi,
Oh right, it looks more compact. Although you should test the corner
cases to make sure no problem is introduced by the new code.
On Sun, May 3, 2009 at 9:28 PM, Vladimir 'phcoder' Serbinenko
wrote:
>
> On Sun, May 3, 2009 at 2:52 PM, Bean wrote:
>>
>> On Sun, May 3, 2009 at 8:39 PM, Vladim
On Sun, May 3, 2009 at 2:52 PM, Bean wrote:
> On Sun, May 3, 2009 at 8:39 PM, Vladimir 'phcoder' Serbinenko
> wrote:
> >
> >
> > On Sun, May 3, 2009 at 2:37 PM, Bean wrote:
> >>
> >> Hi,
> >>
> >> On Sun, May 3, 2009 at 5:12 PM, Vladimir 'phcoder' Serbinenko
> >> wrote:
> >> > Hello
> >> >
> >
On Sun, May 3, 2009 at 8:39 PM, Vladimir 'phcoder' Serbinenko
wrote:
>
>
> On Sun, May 3, 2009 at 2:37 PM, Bean wrote:
>>
>> Hi,
>>
>> On Sun, May 3, 2009 at 5:12 PM, Vladimir 'phcoder' Serbinenko
>> wrote:
>> > Hello
>> >
>> > On Sat, May 2, 2009 at 4:08 PM, Bean wrote:
>> >>
>> >> Hi,
>> >>
>
On Sun, May 3, 2009 at 2:37 PM, Bean wrote:
> Hi,
>
> On Sun, May 3, 2009 at 5:12 PM, Vladimir 'phcoder' Serbinenko
> wrote:
> > Hello
> >
> > On Sat, May 2, 2009 at 4:08 PM, Bean wrote:
> >>
> >> Hi,
> >>
> >> I think there is problem with this patch. Consider ${aa}, the closing
> >> character
Hi,
On Sun, May 3, 2009 at 5:12 PM, Vladimir 'phcoder' Serbinenko
wrote:
> Hello
>
> On Sat, May 2, 2009 at 4:08 PM, Bean wrote:
>>
>> Hi,
>>
>> I think there is problem with this patch. Consider ${aa}, the closing
>> character "}" would be left out.
>>
>> Although you can remedy this by swappin
Hello
On Sat, May 2, 2009 at 4:08 PM, Bean wrote:
> Hi,
>
> I think there is problem with this patch. Consider ${aa}, the closing
> character "}" would be left out.
>
> Although you can remedy this by swapping:
>
> { GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, ' ', 1},
> { GRUB_PARSER_S
Hi,
I think there is problem with this patch. Consider ${aa}, the closing
character "}" would be left out.
Although you can remedy this by swapping:
{ GRUB_PARSER_STATE_VARNAME, GRUB_PARSER_STATE_TEXT, ' ', 1},
{ GRUB_PARSER_STATE_VARNAME2, GRUB_PARSER_STATE_TEXT, '}', 0},
so that '}' would
Hello. A varname may be terminated by any character which isn't in a set
[A-Za-z0-9_] and not only space. Here is a fix
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/kern/parser.c b/kern/parser.c
index e931853..feaee09 100644
--- a/kern/parser.c
+++ b/kern/parser.c
@@ -71,7 +71,10 @@ grub
wrote:
Hello symbols from command.h aren't exported correctly. Here's a
bugfix. It
compiles with it but I haven't checked yet if compiled binary
works. Can
someone familiar with build system have a look at this?
Hi,
It's a little wired, why would powerpc-ieee1275.rmk has two
On Fri, 2009-04-03 at 16:48 +0200, phcoder wrote:
> rgrep revealed no use for the second kernel_elf_HEADERS, so I propose to
> remove it altogether
> Is everybody comfortable with this patch? If I hear no oppositions in
> couple of days I'll commit it.
No objections. By the way, the same proble
from command.h aren't exported correctly. Here's a
bugfix. It
compiles with it but I haven't checked yet if compiled binary
works. Can
someone familiar with build system have a look at this?
Hi,
It's a little wired, why would powerpc-ieee1275.rmk has two
kernel_elf_HEADERS in the
On Fri, Apr 3, 2009 at 2:19 AM, phcoder wrote:
> Is kernel_elf_HEADERS used for anything else than symlist.c and
> kernel-symlist,lst generation?
Hi,
I believe that kernel_elf_HEADERS is only used for symlist.c, so you
should be able to remove the second kernel_elf_HEADERS and still
compile prop
:
Bean wrote:
On Thu, Apr 2, 2009 at 8:52 PM, phcoder wrote:
Hello symbols from command.h aren't exported correctly. Here's a bugfix. It
compiles with it but I haven't checked yet if compiled binary works. Can
someone familiar with build system have a look at this?
Hi,
It's
27;t exported correctly. Here's a bugfix. It
> >> compiles with it but I haven't checked yet if compiled binary works. Can
> >> someone familiar with build system have a look at this?
> >
> > Hi,
> >
> > It's a little wired, why would powerpc-i
Bean wrote:
On Thu, Apr 2, 2009 at 8:52 PM, phcoder wrote:
Hello symbols from command.h aren't exported correctly. Here's a bugfix. It
compiles with it but I haven't checked yet if compiled binary works. Can
someone familiar with build system have a look at this?
Hi,
It&#
On Thu, Apr 2, 2009 at 8:52 PM, phcoder wrote:
> Hello symbols from command.h aren't exported correctly. Here's a bugfix. It
> compiles with it but I haven't checked yet if compiled binary works. Can
> someone familiar with build system have a look at this?
Hi,
It
Hello symbols from command.h aren't exported correctly. Here's a bugfix.
It compiles with it but I haven't checked yet if compiled binary works.
Can someone familiar with build system have a look at this?
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/conf/po
Colin D Bennett wrote:
[...]
There is still one other problem that remains with the cursor on the
menu entry editor, but it seems to be separate: When the menu entry
editor is entered, (hit 'e' on a menu entry), the cursor initially does
not show up. You have to move the cursor to make it show
Robert Millan wrote:
On Mon, Feb 09, 2009 at 05:16:52PM +0100, phcoder wrote:
- if (filetype == GRUB_FSHELP_DIR)
+ if ((filetype & GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR)
Uhm actually I don't understand why you need a mask for this. filetype is
an enum, which we define ourselves.
On Mon, Feb 09, 2009 at 05:16:52PM +0100, phcoder wrote:
> - if (filetype == GRUB_FSHELP_DIR)
> + if ((filetype & GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR)
Uhm actually I don't understand why you need a mask for this. filetype is
an enum, which we define ourselves. What's the root of
On Mon, Feb 09, 2009 at 05:16:52PM +0100, phcoder wrote:
> -
> - if (filetype == GRUB_FSHELP_DIR)
> +
> + if ((filetype & GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR)
Please don't remove those spaces, they're intentional (see
http://www.gnu.org/prep/standards/html_node/Formatting.htm
On Sun, 08 Feb 2009 10:47:34 +0200
Vesa Jääskeläinen wrote:
> phcoder wrote:
> > Hello. I've run into the bug that when editing menu entry in gfxterm
> > characters disappear after cursor moves away from its position. Here is
> > bugfix
>
> I don't think th
Robert Millan wrote:
On Wed, Mar 11, 2009 at 10:36:40AM -0400, BandiPat wrote:
Has there been any further work done on the disappearing characters in
gfxterm? I know you guys had looked at it, but the last word was it was
not fixed yet. I understand it's not a priority, but a fix would help
1 - 100 of 150 matches
Mail list logo
