Move from todo on wiki is done except UltraSparc.
David Miller: these todos seem to be very outdated by your work. If some
of them or new tasks are applicable could you add them to task tracker?
# Install on disk
# Grub emu
# Boot something
# Write a grub-install script to install grub and con
From: phcoder
Date: Wed, 01 Apr 2009 09:43:01 +0200
> Move from todo on wiki is done except UltraSparc.
> David Miller: these todos seem to be very outdated by your work. If some of
> them or new tasks are applicable could you add them to task tracker?
> # Install on disk
> # Grub emu
> # Boot s
From: "Yoshinori K. Okuji"
Date: Sat, 28 Mar 2009 23:34:25 +0900
> On Saturday 28 March 2009 22:39:48 Robert Millan wrote:
> > Unless there's someone else in the list who is knowledgeable about sparc
> > assembly and is going to review this part of David's patch, I'm going to
> > assume it's fine
David Miller wrote:
From: phcoder
Date: Wed, 01 Apr 2009 09:43:01 +0200
Move from todo on wiki is done except UltraSparc.
David Miller: these todos seem to be very outdated by your work. If some of
them or new tasks are applicable could you add them to task tracker?
# Install on disk
# Grub e
On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote:
> On Saturday 28 March 2009 22:13:06 Robert Millan wrote:
> > Do we need the memory map to be sorted? AFAIK loadees can cope with
> > unsorted maps fine; is there an exception?
>
> As I wrote in the draft, a boot loader should s
On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote:
> From: "Yoshinori K. Okuji"
> Date: Sat, 28 Mar 2009 23:34:25 +0900
>
> > On Saturday 28 March 2009 22:39:48 Robert Millan wrote:
> > > Unless there's someone else in the list who is knowledgeable about sparc
> > > assembly and is goi
On Sun, Mar 29, 2009 at 05:39:36PM +0900, Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 11:31:29 Robert Millan wrote:
> > This patch adds GRUB_GFXMODE_LINUX user variable to make it easy for
> > users to set graphical mode before booting Linux.
>
> Is this really Linux-specific? It look some
On Sun, Mar 29, 2009 at 07:09:56PM +0900, Yoshinori K. Okuji wrote:
>
> Indeed. I don't understand this tendency about splitting modules at all. What
> is the motivation behind? What is the real benefit for the user?
>
> From my point of view, it is wrong to force the user to manually load
> mo
On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote:
> On Tue, 2009-03-31 at 01:06 +0900, Yoshinori K. Okuji wrote:
> > On Monday 30 March 2009 23:35:52 phcoder wrote:
> > > I confirm. I suppose that this check and message is bypassed with 32-bit
> > > loading mode. IMO grub2 should provid
On Tue, Mar 31, 2009 at 01:06:25AM +0900, Yoshinori K. Okuji wrote:
> I don't know any reliable way. Some candidates:
>
> - The ramdisk max value. On 32-bit, initrd may not be loaded onto over 2GB.
> This is hard to change in Linux, so we can expect that this will not change.
> On 64-bit, curren
On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> With a new swing in normal.mod splitting I think we should reconsider
> this patch. It's useless to keep loader.c in kernel without boot
> command. IMO it should be moved either to a perate boot.mod (my
> preference) or to minicmd.mod (not a good o
On Tuesday 31 March 2009 05:04:19 Centurion Computer Technology (2005) Ltd
wrote:
> Hi,
>
> I have a raid array named /dev/md/d0
>
> The comand
>
> grub-setup -r "(md0,1)" "(md0)" fails with:
> grub-setup: error: Can't open /dev/md0: No such file or directory.
>
> I have traced this down to lines
On Wednesday 01 April 2009 21:57:55 Robert Millan wrote:
> On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote:
> > On Saturday 28 March 2009 22:13:06 Robert Millan wrote:
> > > Do we need the memory map to be sorted? AFAIK loadees can cope with
> > > unsorted maps fine; is there a
On Wednesday 01 April 2009 22:01:11 Robert Millan wrote:
> On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote:
> > From: "Yoshinori K. Okuji"
> > Date: Sat, 28 Mar 2009 23:34:25 +0900
> >
> > > On Saturday 28 March 2009 22:39:48 Robert Millan wrote:
> > > > Unless there's someone else in
On Wednesday 01 April 2009 22:05:57 Robert Millan wrote:
> On Sun, Mar 29, 2009 at 05:39:36PM +0900, Yoshinori K. Okuji wrote:
> > On Sunday 29 March 2009 11:31:29 Robert Millan wrote:
> > > This patch adds GRUB_GFXMODE_LINUX user variable to make it easy for
> > > users to set graphical mode befor
On Wed, 2009-04-01 at 15:23 +0200, Robert Millan wrote:
> On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote:
> >
> > If we are circumventing the standard Linux bootloader, perhaps we should
> > communicate this to the Linux developers.
>
> This is not circumvention. We're using a 32-bi
On Wednesday 01 April 2009 18:22:46 phcoder wrote:
> ok, thanks. Now everything is in savannah task tracker. As for command
> list I added important missing commands to task tracker and skipped
> not-so-useful ones. As there is some subjectivity involved if you don't
> agree with my choice just say
On Wednesday 01 April 2009 22:19:00 Robert Millan wrote:
> GRUB is in dire need of an active project lead. I'm happy to see what you
> plan to take back on that role. Over the last few months, I tried to cover
> up for some of the work you and Marco weren't doing, like processing the
> patches no
On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote:
> On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> > With a new swing in normal.mod splitting I think we should reconsider
> > this patch. It's useless to keep loader.c in kernel without boot
> > command. IMO it should be moved e
On Wed, Apr 01, 2009 at 10:04:44AM -0400, Pavel Roskin wrote:
> On Wed, 2009-04-01 at 15:23 +0200, Robert Millan wrote:
> > On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote:
> > >
> > > If we are circumventing the standard Linux bootloader, perhaps we should
> > > communicate this to t
On Wednesday 01 April 2009 23:19:32 Robert Millan wrote:
> On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote:
> > On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> > > With a new swing in normal.mod splitting I think we should reconsider
> > > this patch. It's useless to keep load
This usage case isn't the main target case. If you embed the loader
(which tend to be quite big) then you already have an overhead from
loader module. Why are you so concerned with overhead of boot.mod?
But on the other hand this forces all the people in other cases to have
boot code in core.img
phcoder wrote:
> This usage case isn't the main target case. If you embed the loader
> (which tend to be quite big) then you already have an overhead from
> loader module. Why are you so concerned with overhead of boot.mod?
> But on the other hand this forces all the people in other cases to have
>
I was thinking about something more finished like the possibility of
handling multiple preboot and to undo the operations in case of failed
or returned boot. Potentially it could be moved to a separate module but
it results in a reverse dependency and somewhat ugly code
Vesa Jääskeläinen wrote:
On Mon, 2009-01-05 at 01:09 -0600, Jerone Young wrote:
> http://lists.gnu.org/archive/html/grub-devel/2008-12/msg00024.html
>
> It is the attachment.
Applied.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.o
Yoshinori K. Okuji wrote:
On Wednesday 01 April 2009 18:22:46 phcoder wrote:
ok, thanks. Now everything is in savannah task tracker. As for command
list I added important missing commands to task tracker and skipped
not-so-useful ones. As there is some subjectivity involved if you don't
agree wi
From: "Yoshinori K. Okuji"
Date: Wed, 1 Apr 2009 22:59:03 +0900
> David, I can give you a permission, if you tell me your account on Savannah.
It is simply "davem"
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/g
From: Robert Millan
Date: Wed, 1 Apr 2009 15:01:11 +0200
> On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote:
> > From: "Yoshinori K. Okuji"
> > Date: Sat, 28 Mar 2009 23:34:25 +0900
> >
> > > On Saturday 28 March 2009 22:39:48 Robert Millan wrote:
> > > > Unless there's someone else
1) Window save was done wrongly, but no matter we don't even
need to allocate a register window for such a simple routine,
there are enough registers available to do this
2) 'flush' operates on at least 8 bytes at a time, as defined
by V9, so 8 byte align the extremities of the region an
2009-04-01 David S. Miller
* kern/sparc64/dl.c (grub_arch_dl_relocate_symbols): Add
support for R_SPARC_OLO10 relocations. Fix compile warning for
R_SPARC_WDISP30 case.
---
kern/sparc64/dl.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff -
30 matches
Mail list logo
