On Sat, Apr 11, 2009 at 01:19:14AM +0200, phcoder wrote:
> Robert Millan wrote:
>> On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
>>> Alternative: Export a symbol describing the ABI version in kernel
>>> ("grub_abi_3_14").
>>
>> That requires more bytes than a 32-bit integer.
>
Robert Millan wrote:
On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
Alternative: Export a symbol describing the ABI version in kernel
("grub_abi_3_14").
That requires more bytes than a 32-bit integer.
You export grub_abi anyway. _3_14 is 4 bytes instead of 4 but saves.
grub
Robert Millan wrote:
On Thu, Nov 06, 2008 at 09:43:09PM +0100, Christian Franke wrote:
How would the whole picture look like? Sounds like it'd mean less
complexity
in external modules at the expense of more complexity in the build system.
Here a first proof-of-concept patch, uses he
Robert Millan wrote:
On Thu, Nov 06, 2008 at 10:10:56PM +0100, Christian Franke wrote:
See attached patch for a possible fix: Each module using grub_dprintf
(here disk.c) may specify its name in 'this_file'. When all modules are
changed, the '#define this_file' and all #undefs can be removed
On Thu, Nov 06, 2008 at 09:43:09PM +0100, Christian Franke wrote:
> >
> >How would the whole picture look like? Sounds like it'd mean less
> >complexity
> >in external modules at the expense of more complexity in the build system.
>
> Here a first proof-of-concept patch, uses hello.c as the exte
On Wed, Nov 05, 2008 at 10:51:23AM +0100, Robert Millan wrote:
>
> Hi,
>
> Since it looks like the ABI part inspires more need for debate/discussion,
> I propose merging the rest first. Support for ABI tracking is not essential
> for building external modules (in Debian, it's barely necessary).
On Thu, Nov 06, 2008 at 09:43:09PM +0100, Christian Franke wrote:
>
> Here a first proof-of-concept patch, uses hello.c as the external module.
>
> If kernel is compiled with other GRUB_ABI_VER_SYM, insmod fails with:
> "error: the symbol 'grub_abi_ver_1_96' not found"
Ah, I thought it'd be more
On Thu, Nov 06, 2008 at 10:10:56PM +0100, Christian Franke wrote:
>
> See attached patch for a possible fix: Each module using grub_dprintf
> (here disk.c) may specify its name in 'this_file'. When all modules are
> changed, the '#define this_file' and all #undefs can be removed.
This adds redu
Robert Millan wrote:
On Wed, Nov 05, 2008 at 10:41:20PM +0100, Christian Franke wrote:
PS: The current use of __FILE__ may also add extra unexpected size: For
packaging, configure is often run outside of $srcdir with a absolute
path name. This may result in long __FILE__ strings, like
/home
Robert Millan wrote:
On Wed, Nov 05, 2008 at 10:41:20PM +0100, Christian Franke wrote:
Then, a module author has the option to check the ABI version by
importing this symbol
(possibly by simply adding '-u grub_abi_VERSION' to ld command)
How would the whole picture look like? Sounds
On Wed, Nov 05, 2008 at 10:41:20PM +0100, Christian Franke wrote:
>
> Then, a module author has the option to check the ABI version by
> importing this symbol
> (possibly by simply adding '-u grub_abi_VERSION' to ld command)
How would the whole picture look like? Sounds like it'd mean less comp
On Wed, Nov 05, 2008 at 10:41:20PM +0100, Christian Franke wrote:
>
> PS: The current use of __FILE__ may also add extra unexpected size: For
> packaging, configure is often run outside of $srcdir with a absolute
> path name. This may result in long __FILE__ strings, like
> /home/maintainer/pack
Robert Millan wrote:
On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
Alternative: Export a symbol describing the ABI version in kernel
("grub_abi_3_14").
That requires more bytes than a 32-bit integer.
The symbol value does not matter, the symbol name string pro
On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
>
> Alternative: Export a symbol describing the ABI version in kernel
> ("grub_abi_3_14").
That requires more bytes than a 32-bit integer.
> Access this symbol in each module (this can be hidden
> in GRUB_MOD_INIT).
And this ad
Hi,
Since it looks like the ABI part inspires more need for debate/discussion,
I propose merging the rest first. Support for ABI tracking is not essential
for building external modules (in Debian, it's barely necessary).
Here's a new patch. If nobody objects, I'll commit it in a few days.
--
Robert Millan wrote:
...
How do you treat differences in ABI ?
Dis-allow loading of module with different value of ABI ? Or were you
planning that module itself adapts to different versions of GRUB 2 ABI's?
The module itself could:
GRUB_MOD_INIT(foo)
{
if (grub_abi != GRUB_ABI)
{
On Tue, Nov 04, 2008 at 09:13:43PM +0200, Vesa Jääskeläinen wrote:
>
> Did you have some plan how to automate this ABI versioning :) ? If it is
> not automated I can almost guarantee that we get it wrong at one point
> of time :)
It's not a big problem, at least not for my intended use of this fe
Robert Millan wrote:
> On Tue, Nov 04, 2008 at 08:55:52PM +0200, Vesa Jääskeläinen wrote:
>> Robert Millan wrote:
>>> On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
Hi,
Attached patch makes it possible to build modules externally, by:
- Installing headers
On Tue, Nov 04, 2008 at 08:55:52PM +0200, Vesa Jääskeläinen wrote:
> Robert Millan wrote:
> > On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
> >> Hi,
> >>
> >> Attached patch makes it possible to build modules externally, by:
> >>
> >> - Installing headers in system include dir.
>
Robert Millan wrote:
> On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
>> Hi,
>>
>> Attached patch makes it possible to build modules externally, by:
>>
>> - Installing headers in system include dir.
>>
>> - Exporting two ABI tags (a build-time macro and a run-time variable)
>>
On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote:
>
> Hi,
>
> Attached patch makes it possible to build modules externally, by:
>
> - Installing headers in system include dir.
>
> - Exporting two ABI tags (a build-time macro and a run-time variable)
> for run-time compariso
Hi,
Attached patch makes it possible to build modules externally, by:
- Installing headers in system include dir.
- Exporting two ABI tags (a build-time macro and a run-time variable)
for run-time comparison.
- Exporting a makefile with COMMON_*FLAGS variables.
--
Robert Millan
22 matches
Mail list logo
