Re: [PATCH] dprintf implementation
On Thu, 24 Feb 2005, Hollis Blanchard wrote:
> On Feb 24, 2005, at 1:30 PM, Yoshinori K. Okuji wrote:
>
> > On Thursday 24 February 2005 09:02, Vincent Pelletier wrote:
> >> Iirc there were differences of point of view on that matter.
> >> Okuji, what do you think about that idea ?
> >
> > What I said was that you should use strings instead of bit fields.
> > [...]
> > Here you don't have to use bit fields (such as DEBUG_MODE_FS_BIT) at
> > all. When dprintf is called, dprintf simply check if a specified
> > category is included in the variable "debug". Like this:
>
> Ah ok, so the call would look like this:
> grub_dprintf("disk", "reading block %i", blockno);
>
> Although that could lend itself to difficult-to-detect typos. Perhaps a
> #define would be useful after all:
> #define GRUB_DBG_DISK "disk"
> grub_dprintf(GRUB_DBG_DISK, "reading block %i", blockno);
>
> Ah, I see Vincent's patch already does what's needed with the
> grub_dprintf macro, so it's just the conditional output he's working on
> in grub_real_dprintf. Sounds good. :)
>
> -Hollis
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
Why do you use strings instead of numbers? Use of bitmask would allow
pretty simple config file entry like debug=1231. Just a thought.
Aki Tossavainen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dprintf implementation
On Feb 24, 2005, at 1:30 PM, Yoshinori K. Okuji wrote:
On Thursday 24 February 2005 09:02, Vincent Pelletier wrote:
Iirc there were differences of point of view on that matter.
Okuji, what do you think about that idea ?
What I said was that you should use strings instead of bit fields.
[...]
Here you don't have to use bit fields (such as DEBUG_MODE_FS_BIT) at
all. When dprintf is called, dprintf simply check if a specified
category is included in the variable "debug". Like this:
Ah ok, so the call would look like this:
grub_dprintf("disk", "reading block %i", blockno);
Although that could lend itself to difficult-to-detect typos. Perhaps a
#define would be useful after all:
#define GRUB_DBG_DISK "disk"
grub_dprintf(GRUB_DBG_DISK, "reading block %i", blockno);
Ah, I see Vincent's patch already does what's needed with the
grub_dprintf macro, so it's just the conditional output he's working on
in grub_real_dprintf. Sounds good. :)
-Hollis
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FOSDEM presentation
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > On Thursday 24 February 2005 21:29, Marco Gerards wrote: >> During FOSDEM I will not read my email and I won't work on GRUB. I >> will get back on Monday or Tuesday. > > I think there was a free wifi network in last FOSDEM. Isn't it > available this year? Yes, there was. I just won't bring my laptop. :) Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dprintf implementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshinori K. Okuji wrote: | Actually, strstr is not appropriate, because it does not consider word | boundaries. I think I'll write some function to find a word in a string... There is an algorithm I would like to test. | Strings are much better because of the flexibility. I agree now that I exactly understand what you were talking about :). I'm working on it. Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHlhCFEQoKRQyjtURAhcoAJ9JSnbFh4jon7SNRbPMs52WcpR6lwCcD5qJ zDVkYGnPV6kL0DJR/4bg9FQ= =BTYg -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: FOSDEM presentation
On Thursday 24 February 2005 21:29, Marco Gerards wrote: > During FOSDEM I will not read my email and I won't work on GRUB. I > will get back on Monday or Tuesday. I think there was a free wifi network in last FOSDEM. Isn't it available this year? BTW, I added a new section into the GRUB Wiki. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Check for ncurses
Hi Pavel! I'm very happy to hear from you again. On Thursday 24 February 2005 21:38, Pavel Roskin wrote: > The CVS version of GRUB 2 doesn't compile without ncurses, but it > doesn't check for ncurses in configure. The patch adds checks for > headers and library. Thank you. Can you commit it? Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Check for ncurses
Hello! The CVS version of GRUB 2 doesn't compile without ncurses, but it doesn't check for ncurses in configure. The patch adds checks for headers and library. ChangeLog: * configure.ac: Add checks for ncurses. * util/console.c: Include config.h and the ncurses header found by configure. -- Regards, Pavel Roskin --- configure.ac +++ configure.ac @@ -97,6 +97,14 @@ AC_DEFINE([NESTED_FUNC_ATTR], [],[Catch gcc bug]) fi +# Check for ncurses. +AC_CHECK_LIB(ncurses, color_set, , [AC_MSG_ERROR([ncurses library not found])]) +ncurses_found= +AC_CHECK_HEADERS(ncurses/curses.h ncurses.h curses.h, [ncurses_found=1; break;]) +if test -z "$ncurses_found"; then + AC_MSG_ERROR([ncurses header not found]) +fi + AC_PROG_INSTALL AC_PROG_MAKE_SET AC_CHECK_TOOL(OBJCOPY, objcopy) --- util/console.c +++ util/console.c @@ -18,7 +18,16 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#include +#include + +#if defined(HAVE_NCURSES_CURSES_H) +# include +#elif defined(HAVE_NCURSES_H) +# include +#elif defined(HAVE_CURSES_H) +# include +#endif + #include #include #include ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
FOSDEM presentation
Hi, At FOSDEM I will give a small presentation about GRUB 2 for Hurd developers. It will be a technical talk. I put the presentation online: www.xs4all.nl/~mgerards/grub2.mgp I really suck at making presentations so please don't look at the code for it, it was made in a hurry and I could not get the fonts right, etc. ;) Later I will try to improve the presentation or make a better one or so. Suggestions are welcome. During FOSDEM I will not read my email and I won't work on GRUB. I will get back on Monday or Tuesday. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dprintf implementation
On Thursday 24 February 2005 09:02, Vincent Pelletier wrote: > Iirc there were differences of point of view on that matter. > Okuji, what do you think about that idea ? What I said was that you should use strings instead of bit fields. # This enables the debug mode for fs and disk. debug="fs disk" ...execute commands... # This disable the debug mode. debug="" Here you don't have to use bit fields (such as DEBUG_MODE_FS_BIT) at all. When dprintf is called, dprintf simply check if a specified category is included in the variable "debug". Like this: enabled = 0; if (grub_strstr (debug, "all")) enabled = 1; else if (grub_strstr (debug, category)) enabled = 1; Actually, strstr is not appropriate, because it does not consider word boundaries. Strings are much better because of the flexibility. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dprintf implementation
On Thu, 24 Feb 2005, Vincent Pelletier wrote: > Hollis Blanchard wrote: > > Your mailer did some bad stuff to this patch again... > > Argh. I wonder if it is because I sign my mails... > > > Weren't we going to have various flags to selectively enable debug > > messages from particular components at runtime? > > Iirc there were differences of point of view on that matter. > Okuji, what do you think about that idea ? > > What about something like : > GRUB> DEBUG=D_PARTMAP|D_FS > GRUB> DEBUG_OUTPUT=D_SCREEN > GRUB> command_to_be_watched > file.c,line (D_PARTMAP): Partmap of type 'foo' found. > file2.c,line (D_FS): Superblock valid, fs 'bar'. > [...] > > I see those points to be done : > - define | operator > - name-to-value conversion for constants (case-sensitive ?) > - value-to-name conversion for constants > > What about modules ? It should be good to make them able to add new > error constants (maybe only one per module ?) that would match their own > dprintf. > > Here are some prototypes as I think of them: > char *grub_debug_constants[sizeof(grub_debug_mask)*8]; > int grub_debug_constant_request (const char *name); >return value : -1 = no more available bit, -2 = duplicate name, >otherwise 1name (again, case sensitive ?). > void grub_dprintf (int value, char *format, ...); >"value" would be the one returned by grub_debug_constant_request. > void grub_debug_constant_release (int value); > > Vincent Pelletier > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > Signing emails does damage to dashes. It's because consecutive dashes are treated as signature boundary mark. It changes to - ---. Aki Tossavainen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dprintf implementation
Hollis Blanchard wrote: Your mailer did some bad stuff to this patch again... Argh. I wonder if it is because I sign my mails... Weren't we going to have various flags to selectively enable debug messages from particular components at runtime? Iirc there were differences of point of view on that matter. Okuji, what do you think about that idea ? What about something like : GRUB> DEBUG=D_PARTMAP|D_FS GRUB> DEBUG_OUTPUT=D_SCREEN GRUB> command_to_be_watched file.c,line (D_PARTMAP): Partmap of type 'foo' found. file2.c,line (D_FS): Superblock valid, fs 'bar'. [...] I see those points to be done : - define | operator - name-to-value conversion for constants (case-sensitive ?) - value-to-name conversion for constants What about modules ? It should be good to make them able to add new error constants (maybe only one per module ?) that would match their own dprintf. Here are some prototypes as I think of them: char *grub_debug_constants[sizeof(grub_debug_mask)*8]; int grub_debug_constant_request (const char *name); return value : -1 = no more available bit, -2 = duplicate name, otherwise 1< Vincent Pelletier ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
