help-grub
[Top][All Lists]
Advanced

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

Re: Accessing external code or data from the 'console' kernel module: Ca


From: Andrei Borzenkov
Subject: Re: Accessing external code or data from the 'console' kernel module: Can it be done?
Date: Fri, 26 Jun 2015 09:08:17 +0300

В Thu, 25 Jun 2015 21:23:59 +0200
Luc Van Rompaey <address@hidden> пишет:

> 
> 
> On 24/06/15 08:37, Andrei Borzenkov wrote:
> > On Tue, Jun 23, 2015 at 8:35 PM, Luc Van Rompaey
> > <address@hidden> wrote:
> >> Make console driver export pointer to a table. This will make it
> >> possible for console driver to work without your module but provides
> >> access to this table if needed.
> >>
> >> Of course console driver will need to cope with NULL pointer (or
> >> initialize table to something meaningful).
> >>
> >> Hmmm... I think this is the one thing that I have not yet tried.
> >> If I understand correctly, I would then have to create a an EXPORT_VAR
> >> pointer variable in the console module, and let my 'setkey' module store 
> >> the
> >> appropriate value into it.
> >> The function to remap an input key, according to the contents of the table,
> >> would then be a part of the console driver.
> > It can also be a function pointer. So code in console driver would reduce to
> >
> > if (grub_setkey_xlat)
> >   grub_setkey_xlat(...)
> I'm afraid I cannot get this to work, even though I'm trying to mimic 
> some other code that appears to use the same mechanism.
> Here's what I'm doing:
> 
> In console.c (i.e., 'grub-core/term/i386/pc/console.c'), I define the 
> grub_setkey_xlat function pointer:
> 
>    int (*grub_setkey_xlat) (int key) = NULL;
> 
> Later on in the code, I do the "if (grub_setkey_xlat) blahblahblah" 
> stuff as you suggested.
> 
> These are the only changes to the 'console.c' source code, exactly as 
> what happens in 'grub-core/kern/device.c' with the 'grub_net_open' variable.
> 
> Then, in my 'setkey.h' header file, I declare the following:
> 
>    extern int (*EXPORT_VAR (grub_setkey_xlat)) (int key);
> 

does conosle include setkey.h?

> (just as the 'net.h' header file declares 'grub_net_open').
> 
> Then, similar to what 'net.c' does, in the 'GRUB_MOD_INIT(setkey)' 
> function in my 'setkey.c' source file, I assign the appropriate value to 
> the function pointer variable:
> 
>    grub_setkey_xlat = grub_setkey_xlat_real;
> 
> and in the 'GRUB_MOD_FINI(setkey)' function, I reset the variable to NULL:
> 
>    grub_setkey_xlat = NULL;
> 
> but when I try to build the software with these changes, it fails to 
> build the 'moddep.lst' target.
> The 'make' command ends with the following output:
> 
>    mv syminfo.lst.new syminfo.lst
>    cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm 
> -f moddep.lst; exit 1)
>    grub_setkey_xlat in setkey is not defined

That likely means that console does *not* include setkey.h. Variable is
exported from console driver, it is is console driver that must contain
EXPORT_VAR declaration. 

>    Makefile:42257: recipe for target 'moddep.lst' failed
>    make[3]: *** [moddep.lst] Error 1
>    make[3]: Leaving directory '/home/luvr/grubbuildx/grub/grub-core'
>    Makefile:23425: recipe for target 'all' failed
>    make[2]: *** [all] Error 2
>    make[2]: Leaving directory '/home/luvr/grubbuildx/grub/grub-core'
>    Makefile:10695: recipe for target 'all-recursive' failed
>    make[1]: *** [all-recursive] Error 1
>    make[1]: Leaving directory '/home/luvr/grubbuildx/grub'
>    Makefile:3091: recipe for target 'all' failed
> 
> I have no idea what I am missing here.
> When I grep the syminfo.lst file, I can see that 'grub_net_open' is 
> defined in the kernel:
> 
>    $ grep 'grub_net_open' 'grub/grub-core/syminfo.lst'
>    defined kernel grub_net_open

grub-core/kern/device.c:#include <grub/net.h>
...
grub-core/kern/device.c:grub_net_t (*grub_net_open) (const char *name) = NULL;

>    undefined net grub_net_open
> 

grub-core/net/net.c:  grub_net_open = grub_net_open_real;

...
> 
> Any ideas about what I'm doing wrong?

Without seeing the full patch? No.



reply via email to

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