[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use symbol database to maintain module dependence

From: Bean
Subject: Re: [PATCH] Use symbol database to maintain module dependence
Date: Mon, 4 May 2009 14:21:12 +0800

On Mon, May 4, 2009 at 8:18 AM, Vladimir 'phcoder' Serbinenko
<address@hidden> wrote:
> On Mon, Apr 27, 2009 at 9:58 PM, Bean <address@hidden> wrote:
>> On Tue, Apr 28, 2009 at 2:13 AM, Vladimir 'phcoder' Serbinenko
>> <address@hidden> wrote:
>> > symdb code seems to duplicate your list code. Perhaps you could reuse
>> > the
>> > file from kernel thus making maintaining easier
>> Hi,
>> I'm planning to use kern/list.c at first, but there is some issue.
>> list.c uses grub_strcmp, which means we need to add kern/misc.c as
>> well. But kern/misc.c uses environment and terminal output, etc. I end
>> up adding a lot of unrelated stuff just to satisfy the dependence. So
>> perhaps it'd be better to keep it simple for now.
> why not just do
> int
> grub_strcmp (....)
> {
>   return strcmp(...);
> }
> like it's done it other utils?


Or perhaps just define macro in header files:

#ifdef GRUB_UTIL
#define grub_strcmp strcmp

I remember grub legacy used to do this.

>> A better solution is to move the string function to a separate source
>> file, such as kern/string.c. But this is the subject of another patch.
> Also now I'm looking into compiling of grub2 with Apple's gcc and binutils
> and this patch makes this easier. Was it done in perspective of compiling
> with Apple's tools? Do you work on this? If you do we could share the effort

My original plan for this patch is to lay the foundation for external
module support. I haven't try the apple build tools yet. In fact, I
scratched osx in testing sometime ago, and having find the time to
reinstall it yet.

> --
> Regards
> Vladimir 'phcoder' Serbinenko
> _______________________________________________
> Grub-devel mailing list
> address@hidden


reply via email to

[Prev in Thread] Current Thread [Next in Thread]