Re: GPL version 3
On Wed, Jul 04, 2007 at 09:40:15PM +0200, Yoshinori K. Okuji wrote: > > So what do you think? As said in my other mails in this thread, I don't think it makes sense to switch to GPLv3 unless we do it all the way, including GRUB Legacy. (and I'm all for switching rather than staying with GPLv2) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
On Wed, Jul 04, 2007 at 11:10:06PM +0200, Jeroen Dekkers wrote: > At Wed, 4 Jul 2007 21:40:15 +0200, > Yoshinori K. Okuji wrote: > > So I bet that GRUB Legacy should remain under GPLv2. But this can cause > > some > > problem potentially. Let's say, we find the same bug both in GRUB Legacy > > and > > in GRUB 2. In the current trend, the bug would be fixed in GRUB 2 sooner. > > But > > this fix may not be backported to GRUB Legacy as it is, once GRUB 2 > > migrates > > to GPLv3, because of the license incompatibility. Thus this means that the > > maintenance of GRUB Legacy would be harder. > > Are you sure about this? Given that we've assigned copyright to the > FSF, the FSF can decide under which free software license to license > that code. So I don't really see why we can't release the same code > under GPLv2 or later in GRUB Legacy and under GPLv3 or later in GRUB2. This also defeats the point of making GRUB 2 GPLv3, since when we backport it to GRUB Legacy we're licensing this feature in GPLv2, and then it's no longer protected against Treacherous Computing, etc. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
On Thu, Jul 05, 2007 at 12:58:42AM +0200, Stefan Reinauer wrote: > > 2. Just have all the patches GPLv2 or later, and it will automatically >be GPLv3 or GPLv2, whatever applies. This defeats the point of making GRUB GPLv3, because other parties can easily avoid the additional restrictions by taking the GPLv2 version and appliing all these 2-or-later patches. I certainly don't want to contribute patches in this way, since I'm completely against things like DRM or patent deals, and I don't want my code to be used for these purposes. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: CD-ROM booting staus update
On Wed, Jul 04, 2007 at 08:10:29PM -0400, Alex Roman wrote: > On 04/07/07, Alex Roman <[EMAIL PROTECTED]> wrote: > >On 04/07/07, Uwe Hermann <[EMAIL PROTECTED]> wrote: > >> On Tue, Jul 03, 2007 at 11:14:40PM -0400, Alex Roman wrote: > >That will be the second stage of my Summer of Code project... Provided > >people have no objections against my patch, and all is well, I will > >soon start working on an ATA driver that will allow directly reading > >from a CD-ROM drive. > > Bear in mind, though, that current CD-ROM boot sectors (e.g. ISOLINUX) > rely on Int 13h calls to continue the boot process. This means that, > even though writing an ATA driver will allow GRUB to boot a CD on a > platform which doesn't provide legacy interrupts, the loaded boot > sector won't work properly after being booted. > > A possible solution to this is to write a rudimentary Int 13h handler > which will make use of the ATA driver... Since we're on free software, we can do better. Instead of sticking to an obsolete interface, we can define our own in both sides. E.g. define how a CD layout has to be to be bootable by BIOS-less GRUB. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] [PATCH] Add multiboot 2 capabilities
"Jerone Young" <[EMAIL PROTECTED]> writes: > diff -r b85dfdfcce16 conf/powerpc-ieee1275.rmk > --- a/conf/powerpc-ieee1275.rmk Wed Jul 04 15:53:23 2007 -0500 > +++ b/conf/powerpc-ieee1275.rmk Thu Jul 05 08:04:34 2007 -0500 > @@ -102,7 +102,9 @@ pkgdata_MODULES = halt.mod \ > linux.mod \ > normal.mod \ > reboot.mod \ > - suspend.mod > + suspend.mod \ > +_multiboot.mod \ > +multiboot.mod Badly indented. > # For _linux.mod. > _linux_mod_SOURCES = loader/powerpc/ieee1275/linux.c > @@ -140,5 +142,18 @@ halt_mod_CFLAGS = $(COMMON_CFLAGS) > halt_mod_CFLAGS = $(COMMON_CFLAGS) > halt_mod_LDFLAGS = $(COMMON_LDFLAGS) > > +# For _multiboot.mod > +_multiboot_mod_SOURCES = loader/powerpc/ieee1275/multiboot2.c \ > + loader/multiboot2.c \ > + loader/multiboot_loader.c > +_multiboot_mod_CFLAGS = $(COMMON_CFLAGS) > +_multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) > + > +# For multiboot.mod > +multiboot_mod_SOURCES = loader/multiboot_loader_normal.c > +multiboot_mod_CFLAGS = $(COMMON_CFLAGS) > +multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) > + > + > include $(srcdir)/conf/common.mk > > diff -r b85dfdfcce16 include/grub/i386/pc/loader.h > --- a/include/grub/i386/pc/loader.h Wed Jul 04 15:53:23 2007 -0500 > +++ b/include/grub/i386/pc/loader.h Thu Jul 05 01:17:47 2007 -0500 > @@ -22,11 +22,13 @@ <...> > void EXPORT_FUNC(grub_linux_boot_zimage) (void) __attribute__ ((noreturn)); > void EXPORT_FUNC(grub_linux_boot_bzimage) (void) __attribute__ ((noreturn)); > @@ -34,16 +36,18 @@ void EXPORT_FUNC(grub_linux_boot_bzimage > /* This is an asm part of the chainloader. */ > void EXPORT_FUNC(grub_chainloader_real_boot) (int drive, void *part_addr) > __attribute__ ((noreturn)); > > + Useless change. > /* The asm part of the multiboot loader. */ > void EXPORT_FUNC(grub_multiboot_real_boot) (grub_addr_t entry, > struct grub_multiboot_info *mbi) > + __attribute__ ((noreturn)); > +void EXPORT_FUNC(grub_multiboot2_real_boot) (grub_addr_t entry, > + struct grub_multiboot_info *mbi) > __attribute__ ((noreturn)); Use same codestyle, please. There are some other places where it's not following same codestyle and would be nice if it could be fixed, imho. Kind regards, -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Timed wait/sleep
For i/o delays on x86, Linux uses a sequence of outp(0x80). 0x80 is usually unsed. One to three times should be quite sufficient. Jan ex Roman wrote: > On 06 Jul 2007 17:04:19 -0500, Haudy Kazemi <[EMAIL PROTECTED]> wrote: >> On Jul 6 2007, Alex Roman wrote: >> I'd avoid straight loops...with those you run into processor speed >> issues...runs too fast on new CPUs, runs too slow on old hardware. Of >> course I guess you could calibrate some straight loops to the RTC, >> and then >> use the loops rather than polling the RTC periodically, but I don't >> think >> the extra level of complication would provide any real benefit. > > Yes, I am reluctant to use loops for that reason. > > I could definitely do a simple read RTC in a loop until the time > difference from when I started the loop is what I want it to be... > > I'll try to get that working, but I am open to other suggestions as well! > > > Thanks! > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
