* Interesting GSoC project ideas for 09
@ 2009-02-25 9:21 "C. Bergström"
2009-02-25 11:59 ` phcoder
0 siblings, 1 reply; 23+ messages in thread
From: "C. Bergström" @ 2009-02-25 9:21 UTC (permalink / raw)
To: grub-devel
Hi everyone.
I'm not a grub developer, but I'm interested to try to spur some ideas
around how grub could benefit from participating in the 09 GSoC. My
initial ideas are selfish and seeing if there's any interest to have the
zfs support ported from sun's fork to grub 2 upstream. I've checked the
licensing on the files and it does say GPL 2+ or something like that.
Anyone have any other ideas? Interested to help mentor? The deadline
is around the corner so if planning hasn't happened yet it should start
soon.
Thanks
./Christopher
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-25 9:21 Interesting GSoC project ideas for 09 "C. Bergström"
@ 2009-02-25 11:59 ` phcoder
2009-02-27 21:08 ` Robert Millan
2009-03-01 14:55 ` liu Aleaxander
0 siblings, 2 replies; 23+ messages in thread
From: phcoder @ 2009-02-25 11:59 UTC (permalink / raw)
To: The development of GRUB 2
Hello. Marco Gerards already agreed that this port is ok. I made some
investigations into their code and have to say that it won't be just a
port. It seems that some features (e.g. directory listing) are missing.
It also uses dirty tricks which limit their code to one opened file in
time. All this has to be addressed. I was planning to do ZFS however now
my studies take more time than I thought they would and so if it's ok
for maintainers to put it on summer of code or if someone wants to do
this port, it's ok with me. Some other ideas:
HID:
-bluetooth keyboard
-mouse support
More graphics drivers
FS:
-btrfs
-Hammer (dragonflybsd)
Network
-TFTP
-TCP/IP
--NFS
--SMB
--AFP
--FTP
--HTTP (last two would allow plain grub2 used to install linux
distribution by just pointing at right internet server)
-TFTP
Firewire
Scripts:
-Finish scripting engine, loops, functions, pipes,...
-Runtime autoconfig which scans all the drives and creates a list of
detected OS. Very useful for demonstrations and recovery
Realmode hooks including map and memdisk
Regards
Vladimir 'phcoder' Serbinenko
C. Bergström wrote:
>
> Hi everyone.
>
> I'm not a grub developer, but I'm interested to try to spur some ideas
> around how grub could benefit from participating in the 09 GSoC. My
> initial ideas are selfish and seeing if there's any interest to have the
> zfs support ported from sun's fork to grub 2 upstream. I've checked the
> licensing on the files and it does say GPL 2+ or something like that.
>
> Anyone have any other ideas? Interested to help mentor? The deadline
> is around the corner so if planning hasn't happened yet it should start
> soon.
>
> Thanks
>
> ./Christopher
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-25 11:59 ` phcoder
@ 2009-02-27 21:08 ` Robert Millan
2009-02-28 11:54 ` phcoder
2009-03-01 14:55 ` liu Aleaxander
1 sibling, 1 reply; 23+ messages in thread
From: Robert Millan @ 2009-02-27 21:08 UTC (permalink / raw)
To: The development of GRUB 2
On Wed, Feb 25, 2009 at 12:59:31PM +0100, phcoder wrote:
> Hello. Marco Gerards already agreed that this port is ok. I made some
> investigations into their code and have to say that it won't be just a
> port. It seems that some features (e.g. directory listing) are missing.
> It also uses dirty tricks which limit their code to one opened file in
> time. All this has to be addressed. I was planning to do ZFS however now
> my studies take more time than I thought they would and so if it's ok
> for maintainers to put it on summer of code or if someone wants to do
> this port, it's ok with me. Some other ideas:
Seems nice. Would you be willing to write a summary for these? Then we
could add it to grub-soc.html.
Btw, if we're going to participate we also need mentors. Who's willing to be
a mentor this year?
--
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 remove your data and not access it at all."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-27 21:08 ` Robert Millan
@ 2009-02-28 11:54 ` phcoder
2009-03-01 4:28 ` Pavel Roskin
2009-03-02 7:52 ` Interesting GSoC project ideas for 09 liu Aleaxander
0 siblings, 2 replies; 23+ messages in thread
From: phcoder @ 2009-02-28 11:54 UTC (permalink / raw)
To: The development of GRUB 2
Robert Millan wrote:
> Seems nice. Would you be willing to write a summary for these? Then we
> could add it to grub-soc.html.
Where is this file?
Here is elaborated list:
HID:
-bluetooth keyboard
Often BIOS lacks bluetooth support completely. This means that if
someone uses bluetooth keyboard he may even need a separate ps/2 or usb
keyboard just to make his choice in grub. Implementing bluetooth stack
is a difficult task
-mouse support
This feature isn't something that is really useful. It's actually just
to make the bootloader nicer. It requires some changes in the grub's
design to be able to receive output from multiple sources in the same
time. This architecture change can be reused later for e.g recieving
input from both keyboard and serial or keyboard+ssh.
More graphics drivers
FS:
-zfs
It's mentionned in original e-mail. ZFS is a filesystem with many
features absent in classical filesystems, like e.g. snapshotting. It's
used by Solaris/OpenSolaris and FreeBSD. A port to fuse in linux exists
but is too slow to consider booting from zfs with linux
-btrfs
A conceptual replacement for ZFS for linux. Contains some features
absent from both ZFS and classical FS. For more details
http://btrfs.wiki.kernel.org/index.php/Main_Page
-Hammer (dragonflybsd)
It's a new feature of DragonFlyBSD. I don't know how it is better then
FFS or ZFS
Network
-TCP/IP
For many netbooting purposes a fairly complete TCP/IP stack is
necessary. Marco Gerards has some very basic code but said that it
shouldn't hold anybody interested in TCP/IP back
http://savannah.nongnu.org/projects/lwip/ or freebsd could be the base
of port. Following protocols need TCP/IP:
-TFTP
TFTP is a UDP-only protocol similar to very basic FTP used to transfer
kernels and configuration in classical netboot environment
-NFS
NFS is usually used to mount remote root filesystem. Its support in grub
can facilitate netbooting
-SMB
SMB is the protocol for which it's the easiest to setup a server.
Windows, MacOS and many linux distribution propose GUI for it. Many
organisations have an SMB server. Its support can make netbooting as
trivial as "put this iso into your shared folder"
-FTP, HTTP and DNS
These are the most used protocol for internet servers. It's also heavily
used to distribute OpenSource software. If grub2 supports at least FTP
or HTTP and DN,. distributions like ubuntu and debian can put a
configuration file on their server. Then user can just type
configfile (http,debian.org)/grub.cfg
Then a menu with mirrors will appear (random default selection is very
useful in this context), after mirrors user can choose a version and/or
variant. Then grub2 will download corresponding kernel and initrd. In
this way installation doesn't need anything else then grub2 and internet
access. No CD burning,...
Wireless stack
Wifi becomes more and more commonplace. If grub2 supports wireless the
previous scenarios can even be done in wireless environment. IMO target
cards should be intel and atheros because they have opensource drivers
Firewire
It's sometimes used for external harddrives, however USB2 is much more
common. However it has an advantage of being symmetric. It means that a
computer can also present itself as a disk. It's useful for cloning and
disaster recovery
Scripts:
-Finish scripting engine, loops, functions, pipes,...
Scripting engine is still incomplete
-Runtime autoconfig.
It scans all the drives and creates a list of detected OSes in grub2.
Very useful for demonstrations and recovery.
Realmode hooks
some tools are able to hook themselves onto bios interrupts to fool
chainloaded bootloader. This includes map and memdisk. It's also
possible to put dummies on interrupts under coreboot it may be enough in
some cases instead of complete SeaBIOS
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-28 11:54 ` phcoder
@ 2009-03-01 4:28 ` Pavel Roskin
2009-03-01 17:15 ` phcoder
2009-03-04 20:59 ` Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) Robert Millan
2009-03-02 7:52 ` Interesting GSoC project ideas for 09 liu Aleaxander
1 sibling, 2 replies; 23+ messages in thread
From: Pavel Roskin @ 2009-03-01 4:28 UTC (permalink / raw)
To: The development of GRUB 2
On Sat, 2009-02-28 at 12:54 +0100, phcoder wrote:
> Robert Millan wrote:
> > Seems nice. Would you be willing to write a summary for these? Then we
> > could add it to grub-soc.html.
> Where is this file?
> Here is elaborated list:
In my opinion, matching all features of GRUB 1 on i386-pc should be the
highest priority. It would allow distributions to switch to GRUB 2,
bringing more users and more developers. As it stands now, GRUB 2 is
seen as something much more experimental and dangerous than GRUB 1.
We won't win many users by the mouse and bluetooth support if distros
don't switch to the new GRUB. And distros are reluctant to make any
changes that would be seen as regressions.
If we cannot match some features, such as network support, we should
offer alternative solutions and document them.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-25 11:59 ` phcoder
2009-02-27 21:08 ` Robert Millan
@ 2009-03-01 14:55 ` liu Aleaxander
2009-03-01 15:30 ` phcoder
1 sibling, 1 reply; 23+ messages in thread
From: liu Aleaxander @ 2009-03-01 14:55 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
can Implementing a chinese supported grub be a grub-soc idea?
thanks.
On Wed, Feb 25, 2009 at 7:59 PM, phcoder <phcoder@gmail.com> wrote:
> Some other ideas:
> HID:
> -bluetooth keyboard
> -mouse support
> More graphics drivers
> FS:
> -btrfs
> -Hammer (dragonflybsd)
> Network
> -TFTP
> -TCP/IP
> --NFS
> --SMB
> --AFP
> --FTP
> --HTTP (last two would allow plain grub2 used to install linux distribution
> by just pointing at right internet server)
> -TFTP
> Firewire
> Scripts:
> -Finish scripting engine, loops, functions, pipes,...
> -Runtime autoconfig which scans all the drives and creates a list of
> detected OS. Very useful for demonstrations and recovery
> Realmode hooks including map and memdisk
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-03-01 14:55 ` liu Aleaxander
@ 2009-03-01 15:30 ` phcoder
0 siblings, 0 replies; 23+ messages in thread
From: phcoder @ 2009-03-01 15:30 UTC (permalink / raw)
To: The development of GRUB 2
liu Aleaxander wrote:
> can Implementing a chinese supported grub be a grub-soc idea?
> thanks.
No. Because it's already done
>
> On Wed, Feb 25, 2009 at 7:59 PM, phcoder <phcoder@gmail.com> wrote:
>
>> Some other ideas:
>> HID:
>> -bluetooth keyboard
>> -mouse support
>> More graphics drivers
>> FS:
>> -btrfs
>> -Hammer (dragonflybsd)
>> Network
>> -TFTP
>> -TCP/IP
>> --NFS
>> --SMB
>> --AFP
>> --FTP
>> --HTTP (last two would allow plain grub2 used to install linux distribution
>> by just pointing at right internet server)
>> -TFTP
>> Firewire
>> Scripts:
>> -Finish scripting engine, loops, functions, pipes,...
>> -Runtime autoconfig which scans all the drives and creates a list of
>> detected OS. Very useful for demonstrations and recovery
>> Realmode hooks including map and memdisk
>>
>> Regards
>> Vladimir 'phcoder' Serbinenko
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-03-01 4:28 ` Pavel Roskin
@ 2009-03-01 17:15 ` phcoder
2009-03-04 21:02 ` Robert Millan
2009-03-04 20:59 ` Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) Robert Millan
1 sibling, 1 reply; 23+ messages in thread
From: phcoder @ 2009-03-01 17:15 UTC (permalink / raw)
To: The development of GRUB 2
I personally see following features still missing from grub2 comparing
to grub1:
-network
It's in the list
-lock
It's more a question of discussing design that actually coding
-simple partition manipulation
I started a design discussion about this subject but nobody seems to be
interested. If I receive no further replies I suppose that my
proposition with "parttool" in "Re: [PATCH] make partition active" is ok
and implement it
-map hook
Vesa is working on low memory loading which is a prerequisite. If my
boot patch gets incorporated with Vesa's code it should be fairly simple
to do it
-setkey
I've seen that someone already started keymap support
Pavel Roskin wrote:
> On Sat, 2009-02-28 at 12:54 +0100, phcoder wrote:
>> Robert Millan wrote:
>>> Seems nice. Would you be willing to write a summary for these? Then we
>>> could add it to grub-soc.html.
>> Where is this file?
>> Here is elaborated list:
>
> In my opinion, matching all features of GRUB 1 on i386-pc should be the
> highest priority. It would allow distributions to switch to GRUB 2,
> bringing more users and more developers. As it stands now, GRUB 2 is
> seen as something much more experimental and dangerous than GRUB 1.
>
> We won't win many users by the mouse and bluetooth support if distros
> don't switch to the new GRUB. And distros are reluctant to make any
> changes that would be seen as regressions.
>
> If we cannot match some features, such as network support, we should
> offer alternative solutions and document them.
>
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-02-28 11:54 ` phcoder
2009-03-01 4:28 ` Pavel Roskin
@ 2009-03-02 7:52 ` liu Aleaxander
1 sibling, 0 replies; 23+ messages in thread
From: liu Aleaxander @ 2009-03-02 7:52 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
On Sat, Feb 28, 2009 at 7:54 PM, phcoder <phcoder@gmail.com> wrote:
> ...
>
...
> Scripts:
> -Finish scripting engine, loops, functions, pipes,...
> Scripting engine is still incomplete
> -Runtime autoconfig.
> It scans all the drives and creates a list of detected OSes in grub2. Very
> useful for demonstrations and recovery.
HI,
are the "-Finish scripting engine, loops, functions, pipes,..." and
"-Runtime autoconfig" two different idea? or just AN idea but two tasks?
Thanks.
[-- Attachment #2: Type: text/html, Size: 967 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-01 4:28 ` Pavel Roskin
2009-03-01 17:15 ` phcoder
@ 2009-03-04 20:59 ` Robert Millan
2009-03-13 11:50 ` Yoshinori K. Okuji
1 sibling, 1 reply; 23+ messages in thread
From: Robert Millan @ 2009-03-04 20:59 UTC (permalink / raw)
To: The development of GRUB 2
On Sat, Feb 28, 2009 at 11:28:05PM -0500, Pavel Roskin wrote:
> On Sat, 2009-02-28 at 12:54 +0100, phcoder wrote:
> > Robert Millan wrote:
> > > Seems nice. Would you be willing to write a summary for these? Then we
> > > could add it to grub-soc.html.
> > Where is this file?
> > Here is elaborated list:
>
> In my opinion, matching all features of GRUB 1 on i386-pc should be the
> highest priority. It would allow distributions to switch to GRUB 2,
> bringing more users and more developers. As it stands now, GRUB 2 is
> seen as something much more experimental and dangerous than GRUB 1.
>
> We won't win many users by the mouse and bluetooth support if distros
> don't switch to the new GRUB. And distros are reluctant to make any
> changes that would be seen as regressions.
(Speaking as distro maintainer now)
We don't need a complete match of all the GRUB Legacy features in order to
migrate. The things I identified as needed for migration in Debian are
listed here:
http://wiki.debian.org/GrubTransition
I think Xen is fixed now though (someone can confirm?). For grub-reboot
/ savedefault almost all the pieces are there already (thanks to bean).
For lock / password we need to agree on whether the proposed approach is
acceptable, or otherwise what needs to be done.
--
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 remove your data and not access it at all."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Interesting GSoC project ideas for 09
2009-03-01 17:15 ` phcoder
@ 2009-03-04 21:02 ` Robert Millan
0 siblings, 0 replies; 23+ messages in thread
From: Robert Millan @ 2009-03-04 21:02 UTC (permalink / raw)
To: The development of GRUB 2
On Sun, Mar 01, 2009 at 06:15:43PM +0100, phcoder wrote:
> I personally see following features still missing from grub2 comparing
> to grub1:
> -network
Notice that in the GRUB Legacy shipped by Debian, network is disabled anyway
(without module support, you can't ship a prebuilt image that supports all
drivers).
> -simple partition manipulation
> I started a design discussion about this subject but nobody seems to be
> interested. If I receive no further replies I suppose that my
> proposition with "parttool" in "Re: [PATCH] make partition active" is ok
> and implement it
This is nice, but not an essential feature when it comes to Debian.
> -map hook
Same here.
> -setkey
> I've seen that someone already started keymap support
Yep, and gettext too. Both are really nice, but I don't think they're
essential for Debian users either.
--
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 remove your data and not access it at all."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-04 20:59 ` Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) Robert Millan
@ 2009-03-13 11:50 ` Yoshinori K. Okuji
2009-03-13 12:23 ` phcoder
0 siblings, 1 reply; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-13 11:50 UTC (permalink / raw)
To: The development of GRUB 2
On Thursday 05 March 2009 05:59:52 Robert Millan wrote:
> We don't need a complete match of all the GRUB Legacy features in order to
> migrate. The things I identified as needed for migration in Debian are
> listed here:
>
> http://wiki.debian.org/GrubTransition
>
> I think Xen is fixed now though (someone can confirm?). For grub-reboot
> / savedefault almost all the pieces are there already (thanks to bean).
>
> For lock / password we need to agree on whether the proposed approach is
> acceptable, or otherwise what needs to be done.
I have the same regression problem as Debian, personally. The password-based
security feature is not quite important for me, but savedefault / fallback
are critical to use GRUB in a remote environment (to upgrade / replace a
kernel safely).
So, I am ready for spending time to review any patch about this. Could you
pinpoint where the "proposed approach" is?
Regards,
Okuji
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-13 11:50 ` Yoshinori K. Okuji
@ 2009-03-13 12:23 ` phcoder
2009-03-14 21:10 ` Yoshinori K. Okuji
0 siblings, 1 reply; 23+ messages in thread
From: phcoder @ 2009-03-13 12:23 UTC (permalink / raw)
To: The development of GRUB 2
Look at load_env/save_env commands and grub-editenv util
Yoshinori K. Okuji wrote:
> On Thursday 05 March 2009 05:59:52 Robert Millan wrote:
>> We don't need a complete match of all the GRUB Legacy features in order to
>> migrate. The things I identified as needed for migration in Debian are
>> listed here:
>>
>> http://wiki.debian.org/GrubTransition
>>
>> I think Xen is fixed now though (someone can confirm?). For grub-reboot
>> / savedefault almost all the pieces are there already (thanks to bean).
>>
>> For lock / password we need to agree on whether the proposed approach is
>> acceptable, or otherwise what needs to be done.
>
> I have the same regression problem as Debian, personally. The password-based
> security feature is not quite important for me, but savedefault / fallback
> are critical to use GRUB in a remote environment (to upgrade / replace a
> kernel safely).
>
> So, I am ready for spending time to review any patch about this. Could you
> pinpoint where the "proposed approach" is?
>
> Regards,
> Okuji
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-13 12:23 ` phcoder
@ 2009-03-14 21:10 ` Yoshinori K. Okuji
2009-03-15 5:52 ` Bean
0 siblings, 1 reply; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-14 21:10 UTC (permalink / raw)
To: The development of GRUB 2
On Friday 13 March 2009 21:23:19 phcoder wrote:
> Look at load_env/save_env commands and grub-editenv util
Thanks. Now I really regret that I didn't find those additions earlier.
I do not like this implementation for the following reasons:
- The saved file is not plain text, unlike GRUB Legacy. This is a bad choice.
Please let me know the reason why it must be binary, if any.
- The command names are ugly. Why didn't anybody follow Pavel's advise
using "env"?
- The utility name is also ugly. I like Pavel's suggestion "grub-env".
If nobody stops me, I will rewrite it in one week, without caring about
backward compatibility.
Regards,
Okuji
>
> Yoshinori K. Okuji wrote:
> > On Thursday 05 March 2009 05:59:52 Robert Millan wrote:
> >> We don't need a complete match of all the GRUB Legacy features in order
> >> to migrate. The things I identified as needed for migration in Debian
> >> are listed here:
> >>
> >> http://wiki.debian.org/GrubTransition
> >>
> >> I think Xen is fixed now though (someone can confirm?). For grub-reboot
> >> / savedefault almost all the pieces are there already (thanks to bean).
> >>
> >> For lock / password we need to agree on whether the proposed approach is
> >> acceptable, or otherwise what needs to be done.
> >
> > I have the same regression problem as Debian, personally. The
> > password-based security feature is not quite important for me, but
> > savedefault / fallback are critical to use GRUB in a remote environment
> > (to upgrade / replace a kernel safely).
> >
> > So, I am ready for spending time to review any patch about this. Could
> > you pinpoint where the "proposed approach" is?
> >
> > Regards,
> > Okuji
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-14 21:10 ` Yoshinori K. Okuji
@ 2009-03-15 5:52 ` Bean
2009-03-22 7:01 ` Yoshinori K. Okuji
0 siblings, 1 reply; 23+ messages in thread
From: Bean @ 2009-03-15 5:52 UTC (permalink / raw)
To: The development of GRUB 2
On Sun, Mar 15, 2009 at 5:10 AM, Yoshinori K. Okuji <okuji@enbug.org> wrote:
> On Friday 13 March 2009 21:23:19 phcoder wrote:
>> Look at load_env/save_env commands and grub-editenv util
>
> Thanks. Now I really regret that I didn't find those additions earlier.
>
> I do not like this implementation for the following reasons:
>
> - The saved file is not plain text, unlike GRUB Legacy. This is a bad choice.
> Please let me know the reason why it must be binary, if any.
Hi,
As the command need to write to disk using blocklist information,
which is not always correct (such as tail packing, sparse block), I
use a magic header for verification. The length field is used to
indicate the length of the block. because the command can't expand
file, otherwise it would need to update fs information, which is too
much for grub.
> - The command names are ugly. Why didn't anybody follow Pavel's advise
> using "env"?
>
> - The utility name is also ugly. I like Pavel's suggestion "grub-env".
>
> If nobody stops me, I will rewrite it in one week, without caring about
> backward compatibility.
I have no objection for the rename, although there should be two env
commands, one to load and one to save.
--
Bean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-15 5:52 ` Bean
@ 2009-03-22 7:01 ` Yoshinori K. Okuji
2009-03-22 10:48 ` phcoder
2009-03-22 12:29 ` Robert Millan
0 siblings, 2 replies; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-22 7:01 UTC (permalink / raw)
To: The development of GRUB 2
On Sunday 15 March 2009 14:52:05 Bean wrote:
> On Sun, Mar 15, 2009 at 5:10 AM, Yoshinori K. Okuji <okuji@enbug.org> wrote:
> > On Friday 13 March 2009 21:23:19 phcoder wrote:
> >> Look at load_env/save_env commands and grub-editenv util
> >
> > Thanks. Now I really regret that I didn't find those additions earlier.
> >
> > I do not like this implementation for the following reasons:
> >
> > - The saved file is not plain text, unlike GRUB Legacy. This is a bad
> > choice. Please let me know the reason why it must be binary, if any.
>
> Hi,
>
> As the command need to write to disk using blocklist information,
> which is not always correct (such as tail packing, sparse block), I
> use a magic header for verification. The length field is used to
> indicate the length of the block. because the command can't expand
> file, otherwise it would need to update fs information, which is too
> much for grub.
I have read your code deeply, and have found the following:
- in reality, you don't deal with tail packing, but just refuse it, because of
this check in the hook function:
if ((offset != 0) || (length != GRUB_DISK_SECTOR_SIZE))
return;
- grub-editenv and save_env always write the magic at the beginning of a file,
thus the magic does not make sense (besides an extremely conservative sanity
check).
I would say that this is a regression from GRUB Legacy, which takes care of
partial sector allocations gracefully.
So, assuming that every filesystem driver calls a read hook correctly, we
should change it for:
- eliminating the magic header (although it could be kept for a safety guard
for accidental writes)
- refusing to write, only if any sparse blocks are in use (as GRUB may not
allocate new sectors physically)
- dealing with partial sectors - possibly due to tail packing - with some
complicated code
I will work towards this direction. I will first fix up the sector handling
and change the format to plain text. Naming changes are quite trivial, so
they can be done later.
Regards,
Okuji
>
> > - The command names are ugly. Why didn't anybody follow Pavel's advise
> > using "env"?
> >
> > - The utility name is also ugly. I like Pavel's suggestion "grub-env".
> >
> > If nobody stops me, I will rewrite it in one week, without caring about
> > backward compatibility.
>
> I have no objection for the rename, although there should be two env
> commands, one to load and one to save.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 7:01 ` Yoshinori K. Okuji
@ 2009-03-22 10:48 ` phcoder
2009-03-22 13:11 ` Yoshinori K. Okuji
2009-03-22 12:29 ` Robert Millan
1 sibling, 1 reply; 23+ messages in thread
From: phcoder @ 2009-03-22 10:48 UTC (permalink / raw)
To: The development of GRUB 2
Hello, I agree that non-sector aligned writes should be handled
correctly. However I disagree with removing of the magic number. I
personally would prefer if this file would have magic number and
checksum. AFAIK currently grub2 doesn't write to FS except in
load_env/save_env so a bug in code calling the hook could easily be
present. And I don't want grub2 to corrupt the filesystem because of any
such mistakes
Yoshinori K. Okuji wrote:
> On Sunday 15 March 2009 14:52:05 Bean wrote:
>> On Sun, Mar 15, 2009 at 5:10 AM, Yoshinori K. Okuji <okuji@enbug.org> wrote:
>>> On Friday 13 March 2009 21:23:19 phcoder wrote:
>>>> Look at load_env/save_env commands and grub-editenv util
>>> Thanks. Now I really regret that I didn't find those additions earlier.
>>>
>>> I do not like this implementation for the following reasons:
>>>
>>> - The saved file is not plain text, unlike GRUB Legacy. This is a bad
>>> choice. Please let me know the reason why it must be binary, if any.
>> Hi,
>>
>> As the command need to write to disk using blocklist information,
>> which is not always correct (such as tail packing, sparse block), I
>> use a magic header for verification. The length field is used to
>> indicate the length of the block. because the command can't expand
>> file, otherwise it would need to update fs information, which is too
>> much for grub.
>
> I have read your code deeply, and have found the following:
>
> - in reality, you don't deal with tail packing, but just refuse it, because of
> this check in the hook function:
>
> if ((offset != 0) || (length != GRUB_DISK_SECTOR_SIZE))
> return;
>
> - grub-editenv and save_env always write the magic at the beginning of a file,
> thus the magic does not make sense (besides an extremely conservative sanity
> check).
>
> I would say that this is a regression from GRUB Legacy, which takes care of
> partial sector allocations gracefully.
>
> So, assuming that every filesystem driver calls a read hook correctly, we
> should change it for:
>
> - eliminating the magic header (although it could be kept for a safety guard
> for accidental writes)
>
> - refusing to write, only if any sparse blocks are in use (as GRUB may not
> allocate new sectors physically)
>
> - dealing with partial sectors - possibly due to tail packing - with some
> complicated code
>
> I will work towards this direction. I will first fix up the sector handling
> and change the format to plain text. Naming changes are quite trivial, so
> they can be done later.
>
> Regards,
> Okuji
>
>>> - The command names are ugly. Why didn't anybody follow Pavel's advise
>>> using "env"?
>>>
>>> - The utility name is also ugly. I like Pavel's suggestion "grub-env".
>>>
>>> If nobody stops me, I will rewrite it in one week, without caring about
>>> backward compatibility.
>> I have no objection for the rename, although there should be two env
>> commands, one to load and one to save.
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 7:01 ` Yoshinori K. Okuji
2009-03-22 10:48 ` phcoder
@ 2009-03-22 12:29 ` Robert Millan
2009-03-22 12:50 ` Yoshinori K. Okuji
1 sibling, 1 reply; 23+ messages in thread
From: Robert Millan @ 2009-03-22 12:29 UTC (permalink / raw)
To: The development of GRUB 2
On Sun, Mar 22, 2009 at 04:01:35PM +0900, Yoshinori K. Okuji wrote:
>
> I will work towards this direction. I will first fix up the sector handling
> and change the format to plain text. Naming changes are quite trivial, so
> they can be done later.
I notice some changes went in for the new implementation. Do you plan to add
the grub-mkconfig magic as well? That will make this feature inmediately
available to end users.
--
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 remove your data and not access it at all."
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 12:29 ` Robert Millan
@ 2009-03-22 12:50 ` Yoshinori K. Okuji
2009-03-28 20:02 ` Yoshinori K. Okuji
0 siblings, 1 reply; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-22 12:50 UTC (permalink / raw)
To: The development of GRUB 2
On Sunday 22 March 2009 21:29:23 Robert Millan wrote:
> On Sun, Mar 22, 2009 at 04:01:35PM +0900, Yoshinori K. Okuji wrote:
> > I will work towards this direction. I will first fix up the sector
> > handling and change the format to plain text. Naming changes are quite
> > trivial, so they can be done later.
>
> I notice some changes went in for the new implementation. Do you plan to
> add the grub-mkconfig magic as well? That will make this feature
> inmediately available to end users.
No, not yet. My commits are some preparation and random bugfixes, as I found
some bugs when reading code. I will also have to think of how to "savedefault
fallback" in GRUB 2.
Regards,
Okuji
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 10:48 ` phcoder
@ 2009-03-22 13:11 ` Yoshinori K. Okuji
2009-03-22 13:23 ` phcoder
0 siblings, 1 reply; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-22 13:11 UTC (permalink / raw)
To: The development of GRUB 2
On Sunday 22 March 2009 19:48:36 phcoder wrote:
> Hello, I agree that non-sector aligned writes should be handled
> correctly. However I disagree with removing of the magic number. I
> personally would prefer if this file would have magic number and
> checksum. AFAIK currently grub2 doesn't write to FS except in
> load_env/save_env so a bug in code calling the hook could easily be
> present. And I don't want grub2 to corrupt the filesystem because of any
> such mistakes
For magic, alright. But I am not certain about the necessity of checksum.
Bean's code re-reads blocks so as to ensure that blocklists are identical to
what a given filesystem driver reads. So the probability of accidental writes
has been reduced very much already. It is hard for me to imagine the benefit
of adding more overhead. With this condition, if a checksum is invalid, the
cause must be either of these:
- that GRUB has a bug in a filesystem driver, so this has read wrong sectors
- that the content of grubenv has already been corrupted (e.g. because the
user modified it mistakenly)
In the latter case, there is no problem in GRUB overwriting the data, so we
don't have to care. In the former, this means that GRUB cannot read the
filesystem correctly anyway, so the user cannot boot any OS reliably. It is
rather surprising that the user has successfully installed GRUB.
Regards,
Okuji
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 13:11 ` Yoshinori K. Okuji
@ 2009-03-22 13:23 ` phcoder
2009-03-22 14:02 ` Yoshinori K. Okuji
0 siblings, 1 reply; 23+ messages in thread
From: phcoder @ 2009-03-22 13:23 UTC (permalink / raw)
To: The development of GRUB 2
Yoshinori K. Okuji wrote:
> On Sunday 22 March 2009 19:48:36 phcoder wrote:
>> Hello, I agree that non-sector aligned writes should be handled
>> correctly. However I disagree with removing of the magic number. I
>> personally would prefer if this file would have magic number and
>> checksum. AFAIK currently grub2 doesn't write to FS except in
>> load_env/save_env so a bug in code calling the hook could easily be
>> present. And I don't want grub2 to corrupt the filesystem because of any
>> such mistakes
>
> For magic, alright. But I am not certain about the necessity of checksum.
>
> Bean's code re-reads blocks so as to ensure that blocklists are identical to
> what a given filesystem driver reads. So the probability of accidental writes
> has been reduced very much already. It is hard for me to imagine the benefit
> of adding more overhead. With this condition, if a checksum is invalid, the
> cause must be either of these:
>
> - that GRUB has a bug in a filesystem driver, so this has read wrong sectors
> - that the content of grubenv has already been corrupted (e.g. because the
> user modified it mistakenly)
>
> In the latter case, there is no problem in GRUB overwriting the data, so we
> don't have to care. In the former, this means that GRUB cannot read the
> filesystem correctly anyway, so the user cannot boot any OS reliably. It is
> rather surprising that the user has successfully installed GRUB.
This assumption doesn't hold true if developping new FS using grub-emu.
Perhaps a configure parameter to disable all writes would be a good idea?
>
> Regards,
> Okuji
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 13:23 ` phcoder
@ 2009-03-22 14:02 ` Yoshinori K. Okuji
0 siblings, 0 replies; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-22 14:02 UTC (permalink / raw)
To: The development of GRUB 2
On Sunday 22 March 2009 22:23:53 phcoder wrote:
> Yoshinori K. Okuji wrote:
> > On Sunday 22 March 2009 19:48:36 phcoder wrote:
> >> Hello, I agree that non-sector aligned writes should be handled
> >> correctly. However I disagree with removing of the magic number. I
> >> personally would prefer if this file would have magic number and
> >> checksum. AFAIK currently grub2 doesn't write to FS except in
> >> load_env/save_env so a bug in code calling the hook could easily be
> >> present. And I don't want grub2 to corrupt the filesystem because of any
> >> such mistakes
> >
> > For magic, alright. But I am not certain about the necessity of checksum.
> >
> > Bean's code re-reads blocks so as to ensure that blocklists are identical
> > to what a given filesystem driver reads. So the probability of accidental
> > writes has been reduced very much already. It is hard for me to imagine
> > the benefit of adding more overhead. With this condition, if a checksum
> > is invalid, the cause must be either of these:
> >
> > - that GRUB has a bug in a filesystem driver, so this has read wrong
> > sectors - that the content of grubenv has already been corrupted (e.g.
> > because the user modified it mistakenly)
> >
> > In the latter case, there is no problem in GRUB overwriting the data, so
> > we don't have to care. In the former, this means that GRUB cannot read
> > the filesystem correctly anyway, so the user cannot boot any OS reliably.
> > It is rather surprising that the user has successfully installed GRUB.
>
> This assumption doesn't hold true if developping new FS using grub-emu.
> Perhaps a configure parameter to disable all writes would be a good idea?
I think you can just avoid invoking save_env.
Regards,
Okuji
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
2009-03-22 12:50 ` Yoshinori K. Okuji
@ 2009-03-28 20:02 ` Yoshinori K. Okuji
0 siblings, 0 replies; 23+ messages in thread
From: Yoshinori K. Okuji @ 2009-03-28 20:02 UTC (permalink / raw)
To: The development of GRUB 2
On Sunday 22 March 2009 21:50:22 Yoshinori K. Okuji wrote:
> On Sunday 22 March 2009 21:29:23 Robert Millan wrote:
> > On Sun, Mar 22, 2009 at 04:01:35PM +0900, Yoshinori K. Okuji wrote:
> > > I will work towards this direction. I will first fix up the sector
> > > handling and change the format to plain text. Naming changes are quite
> > > trivial, so they can be done later.
> >
> > I notice some changes went in for the new implementation. Do you plan to
> > add the grub-mkconfig magic as well? That will make this feature
> > inmediately available to end users.
>
> No, not yet. My commits are some preparation and random bugfixes, as I
> found some bugs when reading code. I will also have to think of how to
> "savedefault fallback" in GRUB 2.
So I have checked in my changes right now. Next, I will fix the namings.
Regards,
Okuji
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-03-28 20:02 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-25 9:21 Interesting GSoC project ideas for 09 "C. Bergström"
2009-02-25 11:59 ` phcoder
2009-02-27 21:08 ` Robert Millan
2009-02-28 11:54 ` phcoder
2009-03-01 4:28 ` Pavel Roskin
2009-03-01 17:15 ` phcoder
2009-03-04 21:02 ` Robert Millan
2009-03-04 20:59 ` Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) Robert Millan
2009-03-13 11:50 ` Yoshinori K. Okuji
2009-03-13 12:23 ` phcoder
2009-03-14 21:10 ` Yoshinori K. Okuji
2009-03-15 5:52 ` Bean
2009-03-22 7:01 ` Yoshinori K. Okuji
2009-03-22 10:48 ` phcoder
2009-03-22 13:11 ` Yoshinori K. Okuji
2009-03-22 13:23 ` phcoder
2009-03-22 14:02 ` Yoshinori K. Okuji
2009-03-22 12:29 ` Robert Millan
2009-03-22 12:50 ` Yoshinori K. Okuji
2009-03-28 20:02 ` Yoshinori K. Okuji
2009-03-02 7:52 ` Interesting GSoC project ideas for 09 liu Aleaxander
2009-03-01 14:55 ` liu Aleaxander
2009-03-01 15:30 ` phcoder
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.