On Sun, Feb 9, 2014 at 7:48 PM, Peter Maydell wrote:
> Ah, sorry, I hadn't spotted that. OK, then I think we should use that
> code (and I'll test the MacOS X version), but it should go in a
> called-once-from main init function that stashes the answer in
> a static variable, and then the 'get the
On 9 February 2014 06:46, Paolo Bonzini wrote:
> Il 09/02/2014 01:18, Peter Maydell ha scritto:
>
>> Haven't checked it yet. I just don't really see what the point is
>> in having a huge amount of OS specific code to do something
>> which we already do in a portable way. It might be nice to abstra
Il 09/02/2014 10:26, Fam Zheng ha scritto:
> The executable directory is not found once and for all, it's recomputed on
> any call to module_load or os_find_datadir.
>
How about compute it for once in main() and load in module_call_init()?
Sure, that's what Peter's suggesting.
Paolo
On Sun, Feb 9, 2014 at 7:36 AM, Paolo Bonzini wrote:
> Il 08/02/2014 18:46, Peter Maydell ha scritto:
>
>>> This adds parameter "argv0" in calling path from main() to
>>> > module_call_init(). So that module loader knows the location of
>>> > executable.
>>
>> This patch looks kind of odd to me. W
On Sun, Feb 9, 2014 at 2:46 PM, Paolo Bonzini wrote:
> Il 09/02/2014 01:18, Peter Maydell ha scritto:
>
>> Haven't checked it yet. I just don't really see what the point is
>> in having a huge amount of OS specific code to do something
>> which we already do in a portable way. It might be nice to
Il 09/02/2014 01:18, Peter Maydell ha scritto:
Haven't checked it yet. I just don't really see what the point is
in having a huge amount of OS specific code to do something
which we already do in a portable way. It might be nice to abstract
out stashing initial-argv0 and adding a utility function
On 8 February 2014 23:36, Paolo Bonzini wrote:
> Il 08/02/2014 18:46, Peter Maydell ha scritto:
>> It's not obvious why
>> the block layer should be handing argv0 around through bdrv_init
>> in order to (re-?) initialise modules.
>
> The executable directory is not found once and for all, it's rec
Il 08/02/2014 18:46, Peter Maydell ha scritto:
This adds parameter "argv0" in calling path from main() to
> module_call_init(). So that module loader knows the location of
> executable.
This patch looks kind of odd to me. Why are there so many
different places calling module_call_init() and pass
On 8 February 2014 04:40, Fam Zheng wrote:
> This adds parameter "argv0" in calling path from main() to
> module_call_init(). So that module loader knows the location of
> executable.
This patch looks kind of odd to me. Why are there so many
different places calling module_call_init() and passing
On 08.02.2014, at 18:16, Andreas Färber wrote:
> Am 08.02.2014 05:40, schrieb Fam Zheng:
>> This adds parameter "argv0" in calling path from main() to
>> module_call_init(). So that module loader knows the location of
>> executable.
>>
>> Suggested-by: Paolo Bonzini
>> Signed-off-by: Fam Zheng
Am 08.02.2014 05:40, schrieb Fam Zheng:
> This adds parameter "argv0" in calling path from main() to
> module_call_init(). So that module loader knows the location of
> executable.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Fam Zheng
[...]
> diff --git a/bsd-user/main.c b/bsd-user/main.c
>
On Sat, Feb 8, 2014 at 10:12 PM, Paolo Bonzini wrote:
> Il 08/02/2014 05:40, Fam Zheng ha scritto:
>
>> This adds parameter "argv0" in calling path from main() to
>> module_call_init(). So that module loader knows the location of
>> executable.
>>
>> Suggested-by: Paolo Bonzini
>
>
> Really? :)
Il 08/02/2014 05:40, Fam Zheng ha scritto:
This adds parameter "argv0" in calling path from main() to
module_call_init(). So that module loader knows the location of
executable.
Suggested-by: Paolo Bonzini
Really? :)
Reviewed-by: Paolo Bonzini
Paolo
Signed-off-by: Fam Zheng
---
block.c
This adds parameter "argv0" in calling path from main() to
module_call_init(). So that module loader knows the location of
executable.
Suggested-by: Paolo Bonzini
Signed-off-by: Fam Zheng
---
block.c| 8
bsd-user/main.c| 2 +-
include/block/blo
14 matches
Mail list logo