Hi All,
I have been thinking on how to improve memory allocator (thou hasn't got
too much time lately to play with it) so it could aid in following
scenarios:
1. Move VBE BIOS thunks or other code from kernel to actual driver
- specially named segment that gets allocated to lowmem in order to cal
Hello, one additional consideration is to let grub2 stay in memory even
after OS loads. This way it would be possibly to expose any
file/partition accessible through grub2 system as a virtual int13h disk.
For this to be a it's very desirable to put all modules that may need to
stay, the kernel
BandiPat schrieb:
Thanks Andreas, I just figured that out as well when testing on
another machine just now. If you still have the file I sent you for
svn2059, would you mind testing it on your machine as well. I'm
tempted to send you the svn2059 or 2065 to compile on your current
machine, to
On Saturday 04 April 2009 08:02:40 Colin D Bennett wrote:
> What if you switch back and forth between normal and rescue mode
> many times in a row? The stack will grow with each call and eventually
> the stack will overflow and Bad Things will happen.
Yes.
> Now you could also return function po
On Saturday 04 April 2009 14:06:18 Bean wrote:
> One of the problem for normal.mod dependency is its side effect. For
> example, currently ls.mod depend on normal.mod just for
> grub_normal_print_device_info. If we want to embed ls.mod in core.img,
> we must embedded normal.mod as well, along with
On Saturday 04 April 2009 18:21:40 phcoder wrote:
> Can someone review this patch?
Looks good to me.
Thanks,
Okuji
> phcoder wrote:
> > mtime part
> > 2009-03-15 Vladimir Serbinenko
> >
> > Support for mtime and further expandability of dir command
> >
> > * include/grub/lib/datetime.
On Saturday 04 April 2009 18:22:39 phcoder wrote:
> Can someone review this patch?
Only some style should be corrected. For example:
+#ifndef GRUB_UTIL
+ if (!parts)
+grub_dl_unref (mymod);
+#endif
Our convention is to put a space between "!" and "parts", so this should be:
+#ifndef GRUB_U
On Sun, Apr 5, 2009 at 10:33 PM, Yoshinori K. Okuji wrote:
> On Saturday 04 April 2009 14:06:18 Bean wrote:
>> One of the problem for normal.mod dependency is its side effect. For
>> example, currently ls.mod depend on normal.mod just for
>> grub_normal_print_device_info. If we want to embed ls.mo
On the IRC Yoshinori K. Okuji agreed that this move can be useful in
cases like lvm+raid and luks. Any further oppositions?
phcoder wrote:
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
Commited
phcoder wrote:
Bean already said on IRC that this patch is fine with him. If I don't
recieve any oppositions in 1 week I consider this patch ok for committment
phcoder wrote:
Applies fine to last SVN
phcoder wrote:
With this patch fat became case-sensitive which is probably wrong.
Cor
On Monday 06 April 2009 00:02:59 Bean wrote:
> On Sun, Apr 5, 2009 at 10:33 PM, Yoshinori K. Okuji wrote:
> > On Saturday 04 April 2009 14:06:18 Bean wrote:
> >> One of the problem for normal.mod dependency is its side effect. For
> >> example, currently ls.mod depend on normal.mod just for
> >> g
Hello,
I have written an article on the wiki right now:
http://grub.enbug.org/OnSplittingModules
This article is based on our discussion on the IRC. I think the disagreement
between Bean and me derived from that I didn't know his ultimate goal, and
actually I investigated the same idea as him
As I already stated on the IRC libgcrypt modules are optimized for speed
and not the performance (e.g. main loop of sha1 is repeated multiple
times with minor modifications to avoid if's). Generally it's ok to
optimize for speed but in context of embedding size is more important.
On the other h
These issues still remain
phcoder wrote:
Hello I was looking into multiboot2 specifications and have some
suggestions:
1) double the size of flags. 8 features per category seems to be few. it
could even be made completely expandable by the following format:
...
2) "All undefined flags *sho
Andreas Born wrote:
BandiPat schrieb:
Thanks Andreas, I just figured that out as well when testing on
another machine just now. If you still have the file I sent you for
svn2059, would you mind testing it on your machine as well. I'm
tempted to send you the svn2059 or 2065 to compile on your
Hello All,
Forgive me for asking a newb question, but could someone please tell
me how to configure grub2 to do either a TFTP or NFS boot? I am
assuming this functionality exists in grub2.
I'm working with a 686 processor and a Realtek 8169 PHY.
Any pointers would be greatly appreciated.
Thank
On Sun, 2009-04-05 at 22:47 -0500, Dallas Clement wrote:
> Hello All,
>
> Forgive me for asking a newb question, but could someone please tell
> me how to configure grub2 to do either a TFTP or NFS boot? I am
> assuming this functionality exists in grub2.
>
> I'm working with a 686 processor and
Okay, Thank you for the speedy reply!
On Sun, Apr 5, 2009 at 10:52 PM, Pavel Roskin wrote:
> On Sun, 2009-04-05 at 22:47 -0500, Dallas Clement wrote:
>> Hello All,
>>
>> Forgive me for asking a newb question, but could someone please tell
>> me how to configure grub2 to do either a TFTP or NFS bo
18 matches
Mail list logo
