On Mon, 2009-08-10 at 13:29 +0200, Robert Millan wrote:
On Sat, Aug 08, 2009 at 04:48:32PM +0200, Yves Blusseau wrote:
diff --git a/include/grub/symbol.h b/include/grub/symbol.h
index 68d9f00..5fba549 100644
--- a/include/grub/symbol.h
+++ b/include/grub/symbol.h
@@ -21,6 +21,8 @@
On Thu, 2009-07-30 at 11:57 +0200, Vladimir 'phcoder' Serbinenko wrote:
This wasn't specific for the patch. Neither was it a requirement, but
more an idea. It's your work and you can choose to do it the way you
like.
OK then. The patches have been committed.
Since Yves is interested
On Wed, 2009-08-12 at 16:25 +0100, Colin Watson wrote:
I'm having persistent problems with grub.cfg and core.img getting out of
sync. The usual pattern is:
* Some shiny new feature appears in core.img
* We extend grub-mkconfig to use it
* User runs update-grub but not grub-install
On Thu, Aug 13, 2009 at 02:54:29AM -0400, Pavel Roskin wrote:
On Wed, 2009-08-12 at 16:25 +0100, Colin Watson wrote:
I'm having persistent problems with grub.cfg and core.img getting out of
sync. The usual pattern is:
* Some shiny new feature appears in core.img
* We extend
On Thu, Aug 13, 2009 at 1:42 AM, Vladimir 'phcoder'
Serbinenkophco...@gmail.com wrote:
On Wed, Aug 12, 2009 at 7:42 PM, J. Bakshibaksh...@gmail.com wrote:
Hello list,
HDT (Hardware Detection Tool) is a Syslinux com32 module designed to display
low-level information for any x86 compatible
On Mon, Aug 10, 2009 at 05:10:31PM +0200, Robert Millan wrote:
On Mon, Aug 10, 2009 at 12:55:05PM +0100, Colin Watson wrote:
If we default to verbose, we could also have an option to turn it off from
/etc/default/grub, if that makes life easier for you.
Slightly, I suppose. I thought
Considering that vbe.c and sdl.c currently aren't affected a lot
whether there is or there isn't encapsulation in place, I'm ok tih
encapsulating it but if any driver needs the breach of encapsulation
it will be broken and I'll post no opposition to it.
I'll do the encapsulation tomorrow.
ufs1 and ufs2 mainly differ by some structure definitions. Putting
them into the same module and checking on runtime creates continuous
if ( ... == UFS1) { ... }
By using preprocessor it's possible to avoid most of such ifs
Additionally user needs only one FS in core so we save some space
core.img
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
ufsfix
Description: Binary data
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Aug 13, 2009 at 05:59:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Considering that vbe.c and sdl.c currently aren't affected a lot
whether there is or there isn't encapsulation in place, I'm ok tih
encapsulating it but if any driver needs the breach of encapsulation
it will be
On Thu, Aug 13, 2009 at 06:03:44PM +0200, Vladimir 'phcoder' Serbinenko wrote:
ufs1 and ufs2 mainly differ by some structure definitions. Putting
them into the same module and checking on runtime creates continuous
if ( ... == UFS1) { ... }
By using preprocessor it's possible to avoid most of
On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
This looks a bit odd (a mask applied to an integer?), but if it's really
this way, please go ahead with it.
Btw, your mailer marked this attachment as application/octet-stream (I can't
context-reply :-( )
--
Robert
On Thu, Aug 13, 2009 at 10:45:48AM +0100, Colin Watson wrote:
On Mon, Aug 10, 2009 at 05:10:31PM +0200, Robert Millan wrote:
On Mon, Aug 10, 2009 at 12:55:05PM +0100, Colin Watson wrote:
If we default to verbose, we could also have an option to turn it off
from
/etc/default/grub,
When you commit this, could you please follow logical order with
ifdef/else/endif? The negation is less intuitive to read.
Ok
+#ifdef MODE_UFS2
+ grub_uint64_t indir[UFS_BLKSZ (sblock) / sizeof (grub_uint64_t)];
+#else
+ grub_uint32_t indir[UFS_BLKSZ (sblock) / sizeof
Hi,
Yes, that's really the way it is :).
--S
Quoting Robert Millan, who wrote the following on Thu, 13 Aug 2009:
On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
This looks a bit odd (a mask applied to an integer?), but if it's really
this way, please go
Hi Yves,
Please could you include plain text in your mail? HTML-only is difficult
to quote (see below)
On Wed, Aug 12, 2009 at 02:26:47PM +0200, Yves Blusseau wrote:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
meta content=text/html;charset=ISO-8859-1
On Thu, Aug 13, 2009 at 10:05 PM, Robert Millanr...@aybabtu.com wrote:
On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
This looks a bit odd (a mask applied to an integer?), but if it's really
this way, please go ahead with it.
It's the so-called skewness.
Let's
On Wed, Aug 12, 2009 at 09:35:13AM +0100, Colin Watson wrote:
On Mon, Aug 10, 2009 at 06:10:40PM +0200, Robert Millan wrote:
I think it's time we begin the discussion on GRUB 1.97. What do we want to
see in it, and a rough schedule. 1.97 is meant to be a point release,
without
any
On Wed, Aug 12, 2009 at 11:39:01AM +0200, Michal Suchanek wrote:
I wonder, it here any firmware that supports multiple partition formats?
GRUB does (GRUB+coreboot is a firmware). Anyhow, we were talking about
BIOS, which is partmap-agnostic.
--
Robert Millan
The DRM opt-in fallacy: Your
Please go ahead (I assume it raises no warnings and it's well tested).
I tested the latest version with gfxterm and xnu loader. I use
previous version in my daily bootloader. I'll run another series of
tests before comitting.
One small detail:
+ grub_free (mode_list);
+ mode_list = 0;
I
On Wed, Aug 12, 2009 at 02:52:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
On Wed, Aug 12, 2009 at 2:38 AM, Robert Millanr...@aybabtu.com wrote:
On Tue, Aug 11, 2009 at 03:33:13PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
Hello. A bug was filed that embedding code in grub-setup.c was
On Wed, Aug 12, 2009 at 04:25:09PM +0100, Colin Watson wrote:
I'm having persistent problems with grub.cfg and core.img getting out of
sync. The usual pattern is:
* Some shiny new feature appears in core.img
* We extend grub-mkconfig to use it
* User runs update-grub but not
On Thu, Aug 13, 2009 at 09:22:14AM +0100, Colin Watson wrote:
What do people think about this general approach?
There is already a version hardcoded into the uncompressed part of
core.img. See kern/i386/pc/startup.S. Unfortunately, there is no
policy when the version should be
Oh, I didn't know there was a BIOS callback for this. Disregard what
I said about at_keyboard then...
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to
Hi,
I know this isn't on the 1.97 roadmap, but I was wondering about the status
of changing the grub.cfg format. I'm currently trying to plan GRUB2 work for
Solaris and I'd like to minimize as much code change as I can.
Thanks,
--S
___
On Wed, Aug 12, 2009 at 02:45:19PM +0200, Vladimir 'phcoder' Serbinenko wrote:
- Low memory heap (useful to move code off kern/i386/pc/startup.S).
Originally I thought of a path relocator32-relocator users-mm
relocator32 is ready for next round of review but is untested. Now I
think
Hi,
Can this go in util/i386/pc/ instead? This is basicaly ad-hoc code and
doesn't seem very meaningful in generic partmap/*.c.
We may want to embed more in the future. Actually I think it's not
ad-hoc. Basically partition map defines a function which gives back
the sectors available for
On Wed, Aug 12, 2009 at 11:14:31PM +0100, Colin Watson wrote:
On Wed, Aug 12, 2009 at 06:10:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Colin Watson wrote:
This is based on previous work in GRUB Legacy by Kristian and Peter
(CCed). Peter tells me that Red Hat has an assignment
On Thu, Aug 13, 2009 at 03:00:51PM +0530, J.Bakshi wrote:
Rather than porting, I like to boot it from grub but it is a syslinux
module and I don't know if it works at all. Can I use the chainloader
to boot syslinux and let it do the rest of the thing ?
Why don't you port it to Multiboot
On Thu, Aug 13, 2009 at 10:12:34PM +0200, Vladimir 'phcoder' Serbinenko wrote:
When you commit this, could you please follow logical order with
ifdef/else/endif? The negation is less intuitive to read.
Ok
+#ifdef MODE_UFS2
+ grub_uint64_t indir[UFS_BLKSZ (sblock) / sizeof
On Thu, Aug 13, 2009 at 10:25:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
On Thu, Aug 13, 2009 at 10:05 PM, Robert Millanr...@aybabtu.com wrote:
On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
This looks a bit odd (a mask applied to an integer?), but
On Thu, Aug 13, 2009 at 10:36:37PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Please go ahead (I assume it raises no warnings and it's well tested).
I tested the latest version with gfxterm and xnu loader. I use
previous version in my daily bootloader. I'll run another series of
tests before
But available memory is several orders of magnitude bigger than the largest
block a loader will need. So is this really an issue?
It's not always the case. Two examples
1) Solaris. At least some distributions of solaris use a big (70 MiB
compressed, around 200 MiB compressed) initrd which has
On Thu, Aug 13, 2009 at 01:45:17PM -0700, Seth Goldberg wrote:
Hi,
I know this isn't on the 1.97 roadmap, but I was wondering about the
status of changing the grub.cfg format. I'm currently trying to plan
GRUB2 work for Solaris and I'd like to minimize as much code change as I
can.
We
On Thu, Aug 13, 2009 at 10:53:23PM +0200, Vladimir 'phcoder' Serbinenko wrote:
We may want to embed more in the future. Actually I think it's not
ad-hoc. Basically partition map defines a function which gives back
the sectors available for embedding.
Is embedding useful elsewhere?
Yes.
Hi,
Quoting Robert Millan, who wrote the following on Thu, 13 Aug 2009:
On Thu, Aug 13, 2009 at 01:45:17PM -0700, Seth Goldberg wrote:
Hi,
I know this isn't on the 1.97 roadmap, but I was wondering about the
status of changing the grub.cfg format. I'm currently trying to plan
GRUB2 work
On Thu, Aug 13, 2009 at 10:52:05PM +0200, Robert Millan wrote:
On Wed, Aug 12, 2009 at 11:14:31PM +0100, Colin Watson wrote:
On Wed, Aug 12, 2009 at 06:10:18PM +0200, Vladimir 'phcoder' Serbinenko
wrote:
Colin Watson wrote:
This is based on previous work in GRUB Legacy by Kristian and
2009/8/13 Vladimir 'phcoder' Serbinenko phco...@gmail.com:
Considering that vbe.c and sdl.c currently aren't affected a lot
whether there is or there isn't encapsulation in place, I'm ok tih
encapsulating it but if any driver needs the breach of encapsulation
it will be broken and I'll post no
On Fri, Aug 14, 2009 at 2:24 AM, Robert Millanr...@aybabtu.com wrote:
On Thu, Aug 13, 2009 at 03:00:51PM +0530, J.Bakshi wrote:
Rather than porting, I like to boot it from grub but it is a syslinux
module and I don't know if it works at all. Can I use the chainloader
to boot syslinux and let
Dear list,
It is nice to see that grub 1.97 is on its way. Everyone is waiting
for this power pack. But we also need a good doc for it.
The wiki is out-dated.
___
Grub-devel mailing list
Grub-devel@gnu.org
40 matches
Mail list logo
