Am Sonntag, den 12.04.2009, 09:45 +1000 schrieb Chip Panarchy:
> Which BSD?
>
Debian GNU/kFreeBSD-amd64
--
Felix Zielcke
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Hi
Ah, interesting.
I've been trying to get a feature added to GRUB2 to do with
FreeBSD-amd64. That is to give GRUB2 the feature which allows for
direct 'calling' of the 64-bit FreeBSD kernel. GRUB2 currently
supports only the 32-bit version.
If you have the skill, and the time, can you please g
Am Sonntag, den 12.04.2009, 17:12 +1000 schrieb Chip Panarchy:
> Hi
>
> Ah, interesting.
>
> I've been trying to get a feature added to GRUB2 to do with
> FreeBSD-amd64. That is to give GRUB2 the feature which allows for
> direct 'calling' of the 64-bit FreeBSD kernel. GRUB2 currently
> supports
From: Pavel Roskin
Date: Sat, 11 Apr 2009 23:53:33 -0400
> On Sat, 2009-04-11 at 01:27 -0700, David Miller wrote:
>> Newer versions of gcc emit references to libgcc internal
>> functions __bswapsi2 and __bswapdi2 when building ufs and
>> some other filesystem modules on sparc64.
>>
>> Unfortunat
From: Pavel Roskin
Date: Sun, 12 Apr 2009 02:29:15 -0400
> On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote:
>> The ieee1275 ofdisk driver doesn't use a unique value for
>> disk->id so it's really easy to get disk corruption. I was
>> able to see such corruption by simply booting grub from
From: Pavel Roskin
Date: Sun, 12 Apr 2009 02:39:22 -0400
> On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote:
>> The grub printf code tries to treat 'long' and 'int' the same,
>> that doesn't work on (most) 64-bit platforms.
>
>> + n = (unsigned) (-((long) n));
>
> "unsigned" means "un
From: phcoder
Date: Sat, 11 Apr 2009 21:10:26 +0200
> I do not agree with having separate grub_itoa/grub_ltoa/grub_lltoa in
> kernel where the size is critical. We should have only lltoa and use
> it in all contexts.
I look forward to your patch implementing this improvement :-)
_
Please, don't bother developers with same request in multiple threads.
Not only it doesn't help to promote your suggestion but is also
annoying. I feel it is actually unnice how you push your suggestions
hardly without offering any help in developement
Chip Panarchy wrote:
Hi
Ah, interesting.
David Miller wrote:
From: Pavel Roskin
Date: Sun, 12 Apr 2009 02:29:15 -0400
On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote:
The ieee1275 ofdisk driver doesn't use a unique value for
disk->id so it's really easy to get disk corruption. I was
able to see such corruption by simply booti
Hello, we all know how annoying are these autogenerated files. We could
remove it. The main argument against it is that people will not be able
to compile without installing a lot of developement tools. It changes
nothing for the users wanting to modify the code. So I propose to remove
these fi
David Miller wrote:
From: phcoder
Date: Sat, 11 Apr 2009 21:10:26 +0200
I do not agree with having separate grub_itoa/grub_ltoa/grub_lltoa in
kernel where the size is critical. We should have only lltoa and use
it in all contexts.
I look forward to your patch implementing this improvement :-
> - grub_ltoa (tmp, c, l);
> + grub_lltoa (tmp, c, l);
> }
> else
> {
> n = va_arg (args, int);
> - grub_itoa (tmp, c, n);
> + grub_lltoa (tmp, c, n);
Do you think they d
I have looked in it and isolated the files which changes are needed:
1) switching to x86_64 mode and setting the paging up
2) elf64 parser
3) different boot parameters
I'm quite optimistic and think I should have working freebsd64 soon.
Another good piece of news is that it seems that in freebsd6
What about this one?
phcoder wrote:
- Using an int value for the priority is quetionable. Very often, this
style of priority system leads to chaos, because everyone picks up
arbitrary numbers randomly. I prefer to define enums with a careful
analysis.
I will think about it. But the analysis is
phcoder wrote on Sunday 12 April 2009:
> Hello, we all know how annoying are these autogenerated files. We could
> remove it. The main argument against it is that people will not be able
> to compile without installing a lot of developement tools. It changes
> nothing for the users wanting to modif
Pavel Roskin wrote:
I don't see the code which either handles
GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
We could set params->vid_mode, but the mode setting in the kernel is
done in the 16-bit code that we don't use.
Or we could do the actual asking like linux16 does
Also it looks
Hi,
This patch allows you to load amd64 freebsd kernel directly, here is an example:
set root=(hd0,1,a)
freebsd /boot/kernel/kernel
freebsd_loadenv /boot/device.hints
set FreeBSD.vfs.root.mountfrom=ufs:/dev/ad0s1a
boot
Test successfully on FreeBSD 7.1 amd64.
--
Bean
diff --git a/include/grub/i
Hello, you were faster than me. I will test it today. However I would
suggest to move all asm stuff to bsd.mod and not in the kernel. Look my
patch "move bsd helpers out of kernel"
Bean wrote:
Hi,
This patch allows you to load amd64 freebsd kernel directly, here is an example:
set root=(hd0,1
Also asm helpers are verbatim copy from bsd so the copyright line is
probably incorrect
phcoder wrote:
Hello, you were faster than me. I will test it today. However I would
suggest to move all asm stuff to bsd.mod and not in the kernel. Look my
patch "move bsd helpers out of kernel"
Bean wrote
On Sun, 2009-04-12 at 21:11 +0200, phcoder wrote:
> Pavel Roskin wrote:
> >> I don't see the code which either handles
> >> GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
> >
> > We could set params->vid_mode, but the mode setting in the kernel is
> > done in the 16-bit code that we don't u
On Sun, 2009-04-12 at 11:29 -0700, Colin D Bennett wrote:
> phcoder wrote on Sunday 12 April 2009:
> > Hello, we all know how annoying are these autogenerated files. We could
> > remove it. The main argument against it is that people will not be able
> > to compile without installing a lot of devel
On Sun, 2009-04-12 at 01:01 -0700, David Miller wrote:
> > That's a 3 bit hash. The risk of collisions is very high. I would
> > understand if you had 8 entries for the hash values, but the hash values
> > themselves should be reasonably unique.
>
> In my testing there weren't many collisions.
On Sun, 2009-04-12 at 00:58 -0700, David Miller wrote:
> > Actually, changes to configure.ac affect other users as well. Users of
> > other architectures would have to run those checks.
>
> And what kind of problems would that cause? The symbols would
> not be found, the test wouldn't pass, and
On Sat, 2009-04-11 at 08:29 -0700, Colin D Bennett wrote:
> If we could build with -Werror, then it wouldn't be so hard to find the
> warnings since the build would abort...
It's also possible to redirect stderr to a file so that the build
doesn't stumble on the first warning.
I my opinion, mak
On Sun, 2009-04-12 at 14:46 +0200, phcoder wrote:
> - grub_itoa (tmp, c, n);
> + grub_lltoa (tmp, c, n);
Wrong. For "x" and "u" specifiers, the value is unsigned int, but n is
signed int. If we extend signed into to unsigned long long, we get a
sign extension that
On Sun, 2009-04-12 at 10:19 -0400, Isaac Dupree wrote:
> > - grub_ltoa (tmp, c, l);
> > + grub_lltoa (tmp, c, l);
> > }
> > else
> > {
> > n = va_arg (args, int);
> > - grub_itoa (tmp, c,
On Sun, 2009-04-12 at 17:33 -0400, Pavel Roskin wrote:
> If the type is going to be converted, we need to treat signed and
> unsigned values separately.
This is compile tested only, to show what I mean. The size of
kernel.img is reduced from 31220 to 31124. The code looks long, but I'm
sure an
I already understood what you meant in first mail. Sorry for not paying
attention to this detail. Here is my proposition. IT decreases the size
from 31224 to 31068 bytes. I tested it with following input
grub_printf ("Hello World: %d %ld %lld %x %lx %llx %u %lu %llu\n",
0xff
From: phcoder
Date: Sun, 12 Apr 2009 12:44:10 +0200
> David Miller wrote:
>> From: Pavel Roskin
>> Date: Sun, 12 Apr 2009 02:29:15 -0400
>>
>>> On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote:
>> I think fixing disk cache corruption is more important than
>> arguing over the distribution
From: Pavel Roskin
Date: Sun, 12 Apr 2009 17:01:07 -0400
> It's not just about distribution properties. My impression is that your
> code misuses hashes as indices in a table. Let's make the hash 32-bit.
> That would make it harder to misuse.
They aren't indices in the traditional sense, they
From: Pavel Roskin
Date: Sun, 12 Apr 2009 17:19:42 -0400
> On Sun, 2009-04-12 at 00:58 -0700, David Miller wrote:
>
>> > Actually, changes to configure.ac affect other users as well. Users of
>> > other architectures would have to run those checks.
>>
>> And what kind of problems would that ca
From: Pavel Roskin
Date: Sun, 12 Apr 2009 17:24:49 -0400
> On Sat, 2009-04-11 at 08:29 -0700, Colin D Bennett wrote:
>
>> If we could build with -Werror, then it wouldn't be so hard to find the
>> warnings since the build would abort...
>
> It's also possible to redirect stderr to a file so th
David Miller wrote:
From: phcoder
Date: Sun, 12 Apr 2009 12:44:10 +0200
David Miller wrote:
From: Pavel Roskin
Date: Sun, 12 Apr 2009 02:29:15 -0400
On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote:
I think fixing disk cache corruption is more important than
arguing over the distribu
Bean kindly allowed me to mess with this patch. So here comes an
improved version. I moved helpers out of the kernels. Because of how
FreeBSD expects the initial virtual memory mapping only first GB of
physical memory is accessible so it was required to use of trampoline
technique.
Bean wrote:
+1
Beautiful!
Thanks a heap Bean...
Haven't tried it yet, but will!
Exactly what I've been requested, thanks once again!
Panarchy
On Mon, Apr 13, 2009 at 1:27 AM, phcoder wrote:
> Bean kindly allowed me to mess with this patch. So here comes an improved
> version. I moved helpers out of the
You're right.
Once I have all my operating systems installed, working correctly,
have successfully created my 2 Linux distributions, have some time off
(starting work tomorrow!), then I will learn some C++, and help with
the development of software like GRUB2.
In the meantime, I will have to leec
Hello
Sorry, I forgot to thank PHcoder.
Thank you also PHcoder, with Bean's patch, and your
enchancements/patch-of-patch, I should be able to successfully install
FreeBSD 64-bit onto a Logical Partition
(http://forums.freebsd.org/showthread.php?t=3248), by using the GRUB2
bootloader, instead of t
On Mon, Apr 13, 2009 at 10:58 AM, Chip Panarchy wrote:
> Hello
>
> Sorry, I forgot to thank PHcoder.
>
> Thank you also PHcoder, with Bean's patch, and your
> enchancements/patch-of-patch, I should be able to successfully install
> FreeBSD 64-bit onto a Logical Partition
> (http://forums.freebsd.o
On Sun, 2009-04-12 at 18:07 -0700, David Miller wrote:
> From: Pavel Roskin
> Date: Sun, 12 Apr 2009 17:24:49 -0400
>
> > On Sat, 2009-04-11 at 08:29 -0700, Colin D Bennett wrote:
> >
> >> If we could build with -Werror, then it wouldn't be so hard to find the
> >> warnings since the build woul
On Sun, 2009-04-12 at 18:05 -0700, David Miller wrote:
> > The only problem that it will slow down the configure script.
>
> This is not a serious issue. The configure run is very compact
> and efficient and my changes aren't going to materially change
> this in any way whatsoever.
I know. Alt
On Mon, 2009-04-13 at 00:19 +0200, phcoder wrote:
> I already understood what you meant in first mail. Sorry for not paying
> attention to this detail. Here is my proposition. IT decreases the size
> from 31224 to 31068 bytes. I tested it with following input
>grub_printf ("Hello World: %d %l
Hello
Thanks once again for replying.
I wouldn't mind maintaining the port, though probably only
temporarily, seeing as I have a job starting tomorrow.
However, first I need to get GRUB2 working properly, with the 64-bit
FreeBSD entry.
I have Fedora 64-bit installed onto an ext3 partition. How
I can't make grub2 build with phcoder's bsd64.diff. My guess it is beacuse conf/i386.mk is missing stuff related to
loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)?, but I wouldn't how or where to add it in.
cat kernel_syms.lst def-biosdisk.lst def-chain.lst def-linux16.ls
From: Pavel Roskin
Date: Mon, 13 Apr 2009 01:06:49 -0400
> On Sun, 2009-04-12 at 18:05 -0700, David Miller wrote:
>
>> > By the way, the checks for those functions should be done with the
>> > target compiler, that is after the second occurrence of CC="$TARGET_CC"
>> > in configure.ac.
>>
>> Su
From: David Miller
Date: Sat, 11 Apr 2009 04:46:44 -0700 (PDT)
> From: "Yoshinori K. Okuji"
> Date: Sat, 11 Apr 2009 19:23:23 +0900
>
>> On Saturday 11 April 2009 17:08:31 David Miller wrote:
>>> This patch allows a platform to specify the image file output
>>> format, it also adds the --strip-
From: phcoder
Date: Mon, 13 Apr 2009 03:09:20 +0200
> David Miller wrote:
>> Ummm, that's essentially what my code does, except that the "index"
>> is the address of the cached path entry itself.
> Sorry I totally misread your code. Now it's fine
Thanks for your review, I've thus committed this
make_device_name() uses an arbitrary value for the device name
length, putting an arbitrary limit on such strings.
We can do better by calculating the length of this string precisely.
2009-04-12 David S. Miller
* util/hostdisk.c (make_device_name): Do not make any assumptions
Should be self-explanatory, these tools will be used on sparc64 just
like they are on i386-pc
2009-04-12 David S. Miller
* conf/common.rmk (grub_probe_SOURCES): Add Sun partition module.
(grub_fstest_SOURCES): Likewise.
---
conf/common.rmk |5 +++--
1 files changed, 3 ins
Openfirmware block device drivers do not allow for multiple concurrent
opens of the same device. It simply does not work.
Fortunately grub doesn't actually need to do this, it just happens
to do so. Here is the fix for the case of module dependency handling.
The other case that hits this probl
49 matches
Mail list logo
