Interesting GSoC project ideas for 09

Interesting GSoC project ideas for 09

["C. Bergström"]

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

Re: Interesting GSoC project ideas for 09

[phcoder]

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

Re: Interesting GSoC project ideas for 09

[Robert Millan]

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."

Re: Interesting GSoC project ideas for 09

[phcoder]

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

Re: Interesting GSoC project ideas for 09

[Pavel Roskin]

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

Re: Interesting GSoC project ideas for 09

[phcoder]

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

Re: Interesting GSoC project ideas for 09

[Robert Millan]

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."

Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Robert Millan]

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."

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[phcoder]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Bean]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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.

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[phcoder]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[phcoder]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Robert Millan]

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."

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)

[Yoshinori K. Okuji]

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

Re: Interesting GSoC project ideas for 09

[liu Aleaxander]

[-- 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 --]

Re: Interesting GSoC project ideas for 09

[liu Aleaxander]

[-- 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 --]

Re: Interesting GSoC project ideas for 09

[phcoder]

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