Hi,
Currently, the module dependence is determined in the build process
and inserted into the module file, there is several disadvantage about
this approach:
1, The build system is quite complicated, here are the steps required
to build module hello.mod.
a. Compile all pre modules (pre-*.o)
b. E
From: David Miller
Date: Sun, 19 Apr 2009 17:45:21 -0700 (PDT)
> Ho hum, the grub-devel "posting size monster" is likely going
> to eat this one.
It actually allowed the posting, I was just impatient :-)
___
Grub-devel mailing list
Grub-devel@gnu.org
From: David Miller
Date: Sun, 19 Apr 2009 17:42:18 -0700 (PDT)
Ho hum, the grub-devel "posting size monster" is likely going
to eat this one.
If you want to review this patch, I've put a copy up at:
http://vger.kernel.org/~davem/0004-grub-Add-sparc64-support-code.patch
> Ok, this gets
With Sun partitions, individual partitions can start at disk
address zero. That's right, zero.
This works because UFS and EXT{2,3,4} superblocks are offset
far enough into the partition that it won't overwrite the
disk label nor the boot block.
I added an, arguably hackish, heuristic to handle
I did a lot of extensive research, and had some conversations with a
few openboot engineers, to determine the top-end values for properties
and path lengths.
Using that I added some defines and got rid of the various
fixed size stack lock buffers used throughout the openfirmware
code. We now use
Under OpenBoot on sparc64:
The value of the #address-cells property in the root node is the
default value of 2. The value of the #size-cells property in the root
node is the non-default value 2. (NOTE: Since the #address-cells property
value in the root node is the default value
Hello, this is a common way to boot non GPT-aware OS on GPT systems. For
this protective MBR is replaced by a so-called hybrid mbr where first
partition entry is a protective entry and the rest contains legal
partitions. So here is the syntax:
gptsync DISK [PARTITIONSPEC1] [PARTITIONSPEC2] [PARTITI
Hello
> Do you mean run grub-emu as part of a linux installation to bless grub.ef?
> It seems to leave the problem of booting the linux installer, which is easy
> to do from grub.efi - if it is blessed.
> At present we install grub.efi manually, using only grub-mkimage to build
> grub.efi, without
Hi,
Right, we can wrap the local variables in void* and pass them in a
custom pointer, but I still think it's advantageous to put them in a
structure rather than use multiple parameters:
1, We can still use nested function. Sometimes it may seem tedious to
use external function for simple callbac
Hello, I resurrect this thread because of the recent developement in
preboot, mmap and drivemap this subject becomes very actual
On Fri, Aug 29, 2008 at 1:15 PM, Bean wrote:
> Hi,
>
> The traditional memory is quite small, and is used by real mode apps.
> By moving grub2 kernel to upper memory,
Thanks that is going to be very useful.
Just some further comment from the little I know -
On Mon, Apr 20, 2009 at 12:14 AM, Vladimir Serbinenko wrote:
>
>>
>
Now the question is how we do it. We can either keep the current syntax or
> IMO it's better to have two commands:
> intelmacbless and pp
In my opinion a far better way would be to add an additional void * argument
which is passed unchanged to the hook. Like:
struct local
{
...
};
main_func ()
{
struct local locvars;
grub_*_iterate (arg1,arg2,arg3, &locvars);
}
hook (arg1, arg2, arg3, voidparg)
{
struct local *locvars = (struc
Quoting Bean :
Yeah, I agree with you. The conversion will take some effort, but it
could payoff in the long run. Perhaps we can achieve this in two
steps:
1, Change nested function definition to accept only one parameter. For
function with multiple parameters, place them in a structure and pas
Thank you for the testing and info.
>
> Redundant info -
> I checked the OSX bless utility, it requires both folder and file, or it
> will not agree to bless the file.
>
I'm nearly sure now that folder blessing (+tbxi attribute) is used on ppc
macs and file blessing on intel macs. Now the questio
bless.diff version 2.
success.
cleared all bless on hfsplus partition in OSX.
grub> hfspbless (hd0,3)/efi/test/grub523.efi
Back to OSX -
Last login: Sun Apr 19 22:48:43 on console
im81:~ pxw$ bless --info /Volumes/hfsp
finderinfo[0]: 75 => Blessed System Folder is
finderinfo[1]: 7857 =>
I'd also like to help test this as I have a first gen macintel mac pro
that needs to run centos. It was difficult to get a 2nd gen machine to
see the os drive last time I loaded centos...
---
Drew Rosen
On Apr 19, 2009, at 3:50 AM, Vladimir Serbinenko
wrote:
Hello, thank you for the tes
Hello, thank you for the testing. Two concepts together (system folder and
system file) are clearly redundant. I thought that intel macs look which
folder is blessed and load boot.efi file from this directory. Here I attach
a patch which updates finderinfo[0] when argument is a directory and
finder
This code needed to be updated to deal with the fact that
the whole rescue thing is not being used any more.
Committed.
2009-04-19 David S. Miller
* loader/sparc64/ieee1275/linux.c: Include grub/command.h
(grub_rescue_cmd_linux): Rename to...
(grub_cmd_linux): and fix
18 matches
Mail list logo
