Hi,
On Sun, Aug 17, 2008 at 10:43 AM, y.volta <[EMAIL PROTECTED]> wrote:
> Hi,
>
>I made a small patch for grub2 using a romfs file ( zip compressing
> support ). there are 3 files added:
>
> -/commands/i386/pc/romfst.c command to mount
> a romfs image file.
Hi,
I made a small patch for grub2 using a romfs file ( zip compressing
support ). there are 3 files added:
-/commands/i386/pc/romfst.c command to mount a
romfs image file.
-/fs/i386/pc/romfs.c fs and
disk lay
Hi,
On Aug/13/2008, Marco Gerards wrote:
> Hi,
>
> Carles Pina i Estany <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > 2008-08-06 Carles Pina i Estany <[EMAIL PROTECTED]>
> >
> > * menu/normal.c (run_menu): Add Home and End keys in grub-menu.
>
>
> This looks fine to me at first sight.
On Sat, Aug 16, 2008 at 8:16 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 16, 2008 at 05:07:00PM +0800, Bean wrote:
>> Hi,
>>
>> This new patch seperates raid5 and raid6 recover code from raid.c, and
>> place them in module raid5rec.mod and raid6rec.mod. The recover code
>> is only ne
Am Donnerstag, den 14.08.2008, 19:54 +0200 schrieb Robert Millan:
> Anyway, please let's not waste time in this discussion. It's only a matter
> on which patch goes first. If Bean wants to checkin his code first, then
> it just means we'll need to adjust the raid.c part a bit, and that's all.
>
Robert Millan <[EMAIL PROTECTED]> writes:
> On Wed, Aug 13, 2008 at 07:52:59PM +0200, Marco Gerards wrote:
>> > #include
>> > #include
>> > +#include/* For struct grub_mmap_entry, which is
>> > also
>> > + needed by Multiboot. */
>>
>> Isn't it better to
On Sat, Aug 16, 2008 at 02:33:17PM +0200, Robert Millan wrote:
> On Fri, Aug 15, 2008 at 10:11:09PM -0500, David Fries wrote:
> > [...]. Until I have an
> > application for it, I'll have to let someone else implement support
> > for grub_cpu_idle.
>
> We have 4 ports on i386. A proper implementa
On Thu, 14 Aug 2008 22:27:07 -0500
David Fries <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 13, 2008 at 11:34:22AM +0200, Marco Gerards wrote:
> > Please do not add .mk changes in a patch, it is a generated file :-)
>
> What's a generated file doing in the repository if people aren't
> supposed to se
On Sat, Aug 16, 2008 at 02:43:13PM +0200, Felix Zielcke wrote:
> Am Samstag, den 16.08.2008, 15:32 +0300 schrieb Vesa Jääskeläinen:
> >
> > Please use what ever we have on grub source code already. Then it work
> > fine also in standalone grub.
>
> Maybe this time my mail was a bit too short? :)
Felix Zielcke wrote:
> But yeah maybe there's even in the kernel a use for asprintf,
> so maybe a good idea to make a grub_asprintf?
> This could be then either always used even if the util/*.c use the
> library functions normally or it could be done as with my
> grub_print_error change :)
It woul
Committed. Same for disk/lvm.c as well.
On Thu, Aug 14, 2008 at 09:13:52PM +0200, Robert Millan wrote:
>
> Hi,
>
> After Felix's grub_print_error() fix, it is now possible to handle and
> report errors properly in raid. This patch enables that.
>
> --
> Robert Millan
>
> The DRM opt-in f
Am Samstag, den 16.08.2008, 14:39 +0200 schrieb Robert Millan:
> On Sat, Aug 16, 2008 at 02:05:25PM +0200, Felix Zielcke wrote:
> > I just talked with Marco on IRC.
> >
> > I have just used asprintf in one of my patches, but now I discovered:
> > http://grub.enbug.org/BuildingOnNonGnu
> >
> > So
Am Samstag, den 16.08.2008, 15:32 +0300 schrieb Vesa Jääskeläinen:
>
> Please use what ever we have on grub source code already. Then it work
> fine also in standalone grub.
Maybe this time my mail was a bit too short? :)
especially, I ask for asprintf in util/misc.c so just GRUB_UTIL.
But Marco
On Sat, Aug 16, 2008 at 03:32:28PM +0300, Vesa Jääskeläinen wrote:
>
> Please use what ever we have on grub source code already. Then it work
> fine also in standalone grub.
I think he was referring to util/ code.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will dec
On Sat, Aug 16, 2008 at 02:05:25PM +0200, Felix Zielcke wrote:
> I just talked with Marco on IRC.
>
> I have just used asprintf in one of my patches, but now I discovered:
> http://grub.enbug.org/BuildingOnNonGnu
>
> So I became a bit unsure now if it's okay to just use asprintf.
IIRC, asprintf
On Fri, Aug 15, 2008 at 10:11:09PM -0500, David Fries wrote:
> [...]. Until I have an
> application for it, I'll have to let someone else implement support
> for grub_cpu_idle.
We have 4 ports on i386. A proper implementation of grub_cpu_idle
should work fine on all of them. When I say "proper"
Felix Zielcke wrote:
> I just talked with Marco on IRC.
>
> I have just used asprintf in one of my patches, but now I discovered:
> http://grub.enbug.org/BuildingOnNonGnu
>
> So I became a bit unsure now if it's okay to just use asprintf.
>
> Is it okay to just use and don't care about enviromen
On Thu, Aug 14, 2008 at 10:27:07PM -0500, David Fries wrote:
> /*
> + * void grub_cpu_idle (void)
> + * Change to real mode to enable interrupts and hlt until the next interrupt.
> + */
Hi David,
Did you read the mail in which I said the problem with hlt is not about real
mode, but about our ina
On Fri, Aug 15, 2008 at 11:00:17PM +0800, Bean wrote:
> I think we can improve
> the test of (fd0) so that it won't appear in machine that don' t have
> floppy,
That would be nice. But are you sure this is possible with biosdisk? Perhaps
we need hardware access like Linux does (and even then, so
On Fri, Aug 15, 2008 at 07:03:18PM +0200, Javier Martín wrote:
> El vie, 15-08-2008 a las 19:31 +0300, Vesa Jääskeläinen escribió:
> > Javier Martín wrote:
> > > WRT "kernel and modules going hand by hand", think about external
> > > modules: if the drivemap module is finally rejected for introduct
On Sat, Aug 16, 2008 at 05:07:00PM +0800, Bean wrote:
> Hi,
>
> This new patch seperates raid5 and raid6 recover code from raid.c, and
> place them in module raid5rec.mod and raid6rec.mod. The recover code
> is only needed when some of the disk are missing or corrupted, which
> is not common. But
I just talked with Marco on IRC.
I have just used asprintf in one of my patches, but now I discovered:
http://grub.enbug.org/BuildingOnNonGnu
So I became a bit unsure now if it's okay to just use asprintf.
Is it okay to just use and don't care about enviroments which don't
use/have glibc?
Or sh
Isaac Dupree wrote:
> if you rely on a property of the kernel, you should document it
> somewhere in the kernel, and document everyone (hopefully) who relies on
> that property; or the users could have some symbol in the source that
> you can search for. It doesn't have to be a function that takes
23 matches
Mail list logo
