Two SoC ideas

Two SoC ideas

[Wei Shen]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

Hi,
I have two ideas and wonder whether they are welcome as SoC projects.

1) Simple file editing

I think it is useful to add file edit function to Grub. Thus, if a config
file which is required to boot the OS successfully is mistakenly written, we
can still correct it in Grub and need not to reboot from the floppy or cdrom
just for the correcting.
I know it would greately increase the complexity of Grub to support a
writable file system. However, if file writing does not change the block
number of a file, things are much simpler. Since most config files are small
(occupying only one block), I think the solution will work.

2) *addr* option for module command

Add nn option: "*addr* = *value*" to the module command. If the
*addr*option is specified, Grub will load the module to address
*value* instead of the default address.

Regards,

Wei Shen

[-- Attachment #2: Type: text/html, Size: 1182 bytes --]

Re: Two SoC ideas

[colyli]

Chen:

In grub command line, you can edit the configre (even mistaken), so
maybe it will not be worth to add an edit in grub.

An option to set the start address for grub to load multiboot module is
great. This option will make kernel guys (who use multiboot modules) to
initiate the kernel more easy. I remember a branch of grub for L4 kernel
supports this option, maybe it can be a reference if you are interested
in.

Best regards.

Coly


在 2007-03-23五的 23:46 +0800，Wei Shen写道：
> Hi, 
> 
> I have two ideas and wonder whether they are welcome as SoC projects.
>  
> 1) Simple file editing
> I think it is useful to add file edit function to Grub. Thus, if a
> config file which is required to boot the OS successfully is
> mistakenly written, we can still correct it in Grub and need not to
> reboot from the floppy or cdrom just for the correcting. 
> 
> I know it would greately increase the complexity of Grub to support a
> writable file system. However, if file writing does not change the
> block number of a file, things are much simpler. Since most config
> files are small (occupying only one block), I think the solution will
> work. 
>  
> 2) addr option for module command
>  
> Add nn option: "addr = value" to the module command. If the addr
> option is specified, Grub will load the module to address value
> instead of the default address.
>  
> Regards,
>  
> Wei Shen
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Two SoC ideas

[Wei Shen]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

Thanks for your advice.

On 3/24/07, colyli <colyli@263.net> wrote:
>
> Chen:
>
> In grub command line, you can edit the configre (even mistaken), so
> maybe it will not be worth to add an edit in grub.


I do not mean the configure of Grub menu list, but the config files of the
OS, like *boot.ini* of Windows and *inittab* of Linux.

An option to set the start address for grub to load multiboot module is
> great. This option will make kernel guys (who use multiboot modules) to
> initiate the kernel more easy. I remember a branch of grub for L4 kernel
> supports this option, maybe it can be a reference if you are interested
> in.


I know this approach, however, instead of an option, they add a new command
*modaddr*. A limitation is that all modules after the "*modaddr* *value*"
will be loaded in succession to a overriding address below address *value*.

Best regards.
>
> Coly
>
>
> 在 2007-03-23五的 23:46 +0800，Wei Shen写道：
> > Hi,
> >
> > I have two ideas and wonder whether they are welcome as SoC projects.
> >
> > 1) Simple file editing
> > I think it is useful to add file edit function to Grub. Thus, if a
> > config file which is required to boot the OS successfully is
> > mistakenly written, we can still correct it in Grub and need not to
> > reboot from the floppy or cdrom just for the correcting.
> >
> > I know it would greately increase the complexity of Grub to support a
> > writable file system. However, if file writing does not change the
> > block number of a file, things are much simpler. Since most config
> > files are small (occupying only one block), I think the solution will
> > work.
> >
> > 2) addr option for module command
> >
> > Add nn option: "addr = value" to the module command. If the addr
> > option is specified, Grub will load the module to address value
> > instead of the default address.
> >
> > Regards,
> >
> > Wei Shen
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

[-- Attachment #2: Type: text/html, Size: 2954 bytes --]

Re: Two SoC ideas

[coly]

Chen:

For the first idea, it is clear to me. I have no comment on it.
For the second idea, I need more information. Can you explain more for
the limition of "modaddr value" command, and how can the limition to be
broken out by the "addr = value" option ?

Thanks.

Coly


在 2007-03-24六的 01:30 +0800，Wei Shen写道：
> Thanks for your advice.
> 
> On 3/24/07, colyli <colyli@263.net> wrote: 
>         Chen:
>         
>         In grub command line, you can edit the configre (even
>         mistaken), so
>         maybe it will not be worth to add an edit in grub.
>  
> I do not mean the configure of Grub menu list, but the config files of
> the OS, like boot.ini of Windows and inittab of Linux.
> 
>         An option to set the start address for grub to load multiboot
>         module is
>         great. This option will make kernel guys (who use multiboot
>         modules) to 
>         initiate the kernel more easy. I remember a branch of grub for
>         L4 kernel
>         supports this option, maybe it can be a reference if you are
>         interested
>         in.
>  
> I know this approach, however, instead of an option, they add a new
> command modaddr. A limitation is that all modules after the "modaddr
> value" will be loaded in succession to a overriding address below
> address value.
> 
>         Best regards.
>         
>         Coly
>         
>         
>         在 2007-03-23五的 23:46 +0800，Wei Shen写道：
>         > Hi,
>         >
>         > I have two ideas and wonder whether they are welcome as SoC
>         projects. 
>         >
>         > 1) Simple file editing
>         > I think it is useful to add file edit function to Grub.
>         Thus, if a
>         > config file which is required to boot the OS successfully is
>         > mistakenly written, we can still correct it in Grub and need
>         not to 
>         > reboot from the floppy or cdrom just for the correcting.
>         >
>         > I know it would greately increase the complexity of Grub to
>         support a
>         > writable file system. However, if file writing does not
>         change the 
>         > block number of a file, things are much simpler. Since most
>         config
>         > files are small (occupying only one block), I think the
>         solution will
>         > work.
>         >
>         > 2) addr option for module command
>         >
>         > Add nn option: "addr = value" to the module command. If the
>         addr
>         > option is specified, Grub will load the module to address
>         value
>         > instead of the default address.
>         >
>         > Regards, 
>         >
>         > Wei Shen
>         > _______________________________________________
>         > 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

Re: Two SoC ideas

[Hollis Blanchard]

On Fri, 2007-03-23 at 23:46 +0800, Wei Shen wrote:
> 
> 2) addr option for module command   Add nn option: "addr = value" to
> the module command. If the addr option is specified, Grub will load
> the module to address value instead of the default address. 

Why?

-Hollis

LVM as root device

[Juan Pedro Paredes]

grub2+LVM+XEN issues

----8<------------
devel:/boot/grub# cat /boot/grub/device.map
(hd0)   /dev/hda
devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
/boot/grub -t device
/dev/dm-9
devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
/boot/grub -t drive
cannot find a GRUB drive for /dev/dm-9.
-----8<-----------
must be (devel-devel-root)

Into the code i see that
grub_guess_root_device works well and have LVM related code
in grub_util_biosdisk_get_grub_dev i dont see  LVM code

Questions:
LVM must use grub_util_biosdisk_get_grub_dev to determine the grub device?
grub_util_biosdisk_get_grub_dev support LVM devices?
someone can help me to fix this?  Jerome?

Re: LVM as root device

[Yoshinori K. Okuji]

On Monday 26 March 2007 07:24, Juan Pedro Paredes wrote:
> grub2+LVM+XEN issues
>
> ----8<------------
> devel:/boot/grub# cat /boot/grub/device.map
> (hd0)   /dev/hda

Shouldn't this be /dev/dm-9 in your case?

> devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
> /boot/grub -t device
> /dev/dm-9
> devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
> /boot/grub -t drive
> cannot find a GRUB drive for /dev/dm-9.
> -----8<-----------
> must be (devel-devel-root)

Okuji

Re: LVM as root device

[Jerone Young]

This may be a bigger problem. Trying CVS, it apears that LVM as the
root device (where grub files are held ../boot is) does not currently
work. Looking more into it now.

On 3/26/07, Juan Pedro Paredes <juampe@iquis.com> wrote:
>
> grub2+LVM+XEN issues
>
> ----8<------------
> devel:/boot/grub# cat /boot/grub/device.map
> (hd0)   /dev/hda
> devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
> /boot/grub -t device
> /dev/dm-9
> devel:/boot/grub# grub-probe --device-map=/boot/grub/device.map
> /boot/grub -t drive
> cannot find a GRUB drive for /dev/dm-9.
> -----8<-----------
> must be (devel-devel-root)
>
> Into the code i see that
> grub_guess_root_device works well and have LVM related code
> in grub_util_biosdisk_get_grub_dev i dont see  LVM code
>
> Questions:
> LVM must use grub_util_biosdisk_get_grub_dev to determine the grub device?
> grub_util_biosdisk_get_grub_dev support LVM devices?
> someone can help me to fix this?  Jerome?
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Two SoC ideas

[Yoshinori K. Okuji]

On Friday 23 March 2007 16:46, Wei Shen wrote:
> 1) Simple file editing
>
> I think it is useful to add file edit function to Grub. Thus, if a config
> file which is required to boot the OS successfully is mistakenly written,
> we can still correct it in Grub and need not to reboot from the floppy or
> cdrom just for the correcting.
> I know it would greately increase the complexity of Grub to support a
> writable file system. However, if file writing does not change the block
> number of a file, things are much simpler. Since most config files are
> small (occupying only one block), I think the solution will work.

If you don't change the file size, it would work mostly. And this is exactly 
how "savedefault" works in GRUB Legacy.

But I am a bit pessimistic with this approach. For example, ZFS computes a 
checksum for every block, and embeds the information into a parent node. This 
means that, when GRUB modifies any bit of data, GRUB must recompute a 
checksum and write it to somewhere appropriate. Otherwise, a filesystem would 
be corrupted.

Theoretically speaking, nothing prevents GRUB from doing that. But this 
illustrates that GRUB must deal with writing very carefully, and the 
semantics depends on each filesystem. I do not know if a kind of volume 
manager, such as LVM, performs this kind of check, but if it does, we need to 
support it as well.

So this work is not as trivial as at the first glance, although we need it for 
"savedefault" definitely.

> 2) *addr* option for module command
>
> Add nn option: "*addr* = *value*" to the module command. If the
> *addr*option is specified, Grub will load the module to address
> *value* instead of the default address.

We discussed this in bug-grub a long time ago. If you are interested, please 
look at the archive, and search by "modaddr".

In summary, I do not like this, because it is a non-standard extension to 
Multiboot Specification. If you depend on this feature, your users would be 
restricted to using GRUB, and they would not be able to use any other 
Multiboot-compliant boot loaders. This is against the spirit of the Multiboot 
Specification, which addresses portability problems in boot protocols.

So this must be accomplished as a part of Multiboot Specification. Otherwise, 
I do not want to accept it.

Thanks,
Okuji

Re: Two SoC ideas

[coly]

Okuji:

Why the modaddr can not be accepted by multiboot specification ? By
default, grub loads the multiboot modules right after multiboot kernel.
Some microkernel want to keep the multiboot module images in memory, if
a driver crashed it can be reloaded from the image. 
On x86 platform, this scheme will consume much DMA memory. So a command
like modaddr is very useful to save memory in DMA area. I dont know
whether other platforms use Grub, but x86 is the most popular one.

Best regards.

Coly

在 2007-03-24六的 23:57 +0100，Yoshinori K. Okuji写道：
> On Friday 23 March 2007 16:46, Wei Shen wrote:
> > 1) Simple file editing
> >
> > I think it is useful to add file edit function to Grub. Thus, if a config
> > file which is required to boot the OS successfully is mistakenly written,
> > we can still correct it in Grub and need not to reboot from the floppy or
> > cdrom just for the correcting.
> > I know it would greately increase the complexity of Grub to support a
> > writable file system. However, if file writing does not change the block
> > number of a file, things are much simpler. Since most config files are
> > small (occupying only one block), I think the solution will work.
> 
> If you don't change the file size, it would work mostly. And this is exactly 
> how "savedefault" works in GRUB Legacy.
> 
> But I am a bit pessimistic with this approach. For example, ZFS computes a 
> checksum for every block, and embeds the information into a parent node. This 
> means that, when GRUB modifies any bit of data, GRUB must recompute a 
> checksum and write it to somewhere appropriate. Otherwise, a filesystem would 
> be corrupted.
> 
> Theoretically speaking, nothing prevents GRUB from doing that. But this 
> illustrates that GRUB must deal with writing very carefully, and the 
> semantics depends on each filesystem. I do not know if a kind of volume 
> manager, such as LVM, performs this kind of check, but if it does, we need to 
> support it as well.
> 
> So this work is not as trivial as at the first glance, although we need it for 
> "savedefault" definitely.
> 
> > 2) *addr* option for module command
> >
> > Add nn option: "*addr* = *value*" to the module command. If the
> > *addr*option is specified, Grub will load the module to address
> > *value* instead of the default address.
> 
> We discussed this in bug-grub a long time ago. If you are interested, please 
> look at the archive, and search by "modaddr".
> 
> In summary, I do not like this, because it is a non-standard extension to 
> Multiboot Specification. If you depend on this feature, your users would be 
> restricted to using GRUB, and they would not be able to use any other 
> Multiboot-compliant boot loaders. This is against the spirit of the Multiboot 
> Specification, which addresses portability problems in boot protocols.
> 
> So this must be accomplished as a part of Multiboot Specification. Otherwise, 
> I do not want to accept it.
> 
> Thanks,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Two SoC ideas

[Yoshinori K. Okuji]

On Sunday 25 March 2007 07:35, coly wrote:
> Why the modaddr can not be accepted by multiboot specification ?

I didn't say that it is not accepted for Multiboot Specification. I said, it 
is not accpetable to add a GRUB-specific extension to Multiboot. They are 
very different. As I said, first, the feature must be defined in Multiboot 
Specification. Then, we can support it in GRUB.

Okuji

Re: Two SoC ideas

[James Youngman]

On 3/24/07, Yoshinori K. Okuji <okuji@enbug.org> wrote:

> Theoretically speaking, nothing prevents GRUB from doing that. But this
> illustrates that GRUB must deal with writing very carefully, and the
> semantics depends on each filesystem. I do not know if a kind of volume
> manager, such as LVM, performs this kind of check, but if it does, we need to
> support it as well.

Software RAID mirrors may also be a problem.

James.

Re: Two SoC ideas

[Wei Shen]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Hi,

Since it seems that few people like my ideas, I have not apply for them as
SoC projects.

If you think they are helpful. I will still try working on them.

Regards,

Wei


On 3/23/07, Wei Shen <cquark@gmail.com> wrote:
>
> Hi,
> I have two ideas and wonder whether they are welcome as SoC projects.
>
> 1) Simple file editing
>
> I think it is useful to add file edit function to Grub. Thus, if an OS
> config file which is required to boot the OS successfully is mistakenly
> written, we can still correct it in Grub and need not to reboot from the
> floppy or cdrom just for the correcting.
> I know it would greately increase the complexity of Grub to support a
> writable file system. However, if file writing does not change the
> block counts of a file, things are much simpler. Since most config files are
> small (occupying only one block), I think the solution will work.
>
> 2) *addr* option for module command
>
> Add nn option: "*addr* = *value*" to the module command. If the *addr*option is specified, Grub will load the module to address
> *value* instead of the default address.
>
> Regards,
>
> Wei Shen
>

[-- Attachment #2: Type: text/html, Size: 1774 bytes --]

Re: Two SoC ideas

[coly]

oh, Shen:

You hack for your self, not for others. If you enjoy it, just do it.
If you want your job to be used widely, try to find better ideas. Do
not give up anyway :-)

Coly

2007/3/28, Wei Shen <cquark@gmail.com>:
> Hi,
>
> Since it seems that few people like my ideas, I have not apply for them as
> SoC projects.
>
> If you think they are helpful. I will still try working on them.
>
> Regards,
>
> Wei
>
>
> On 3/23/07, Wei Shen <cquark@gmail.com> wrote:
> >
> >
> > Hi,
> > I have two ideas and wonder whether they are welcome as SoC projects.
> >
> > 1) Simple file editing
> >
> > I think it is useful to add file edit function to Grub. Thus, if an OS
> config file which is required to boot the OS successfully is mistakenly
> written, we can still correct it in Grub and need not to reboot from the
> floppy or cdrom just for the correcting.
> > I know it would greately increase the complexity of Grub to support a
> writable file system. However, if file writing does not change the block
> counts of a file, things are much simpler. Since most config files are small
> (occupying only one block), I think the solution will work.
> >
> > 2) addr option for module command
> >
> > Add nn option: "addr = value" to the module command. If the addr option is
> specified, Grub will load the module to address value instead of the default
> address.
> >
> > Regards,
> >
> > Wei Shen
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

Re: Two SoC ideas

[Wei Shen]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

Your are absolutely right. But I am not an expert on Grub.

I think the most important that Google SoC gives a student is not money, but
a opportunity to participate and obtain help.

On 3/28/07, coly <colyli@gmail.com> wrote:

> oh, Shen:
>
> You hack for your self, not for others. If you enjoy it, just do it.
> If you want your job to be used widely, try to find better ideas. Do
> not give up anyway :-)
>
> Coly
>
> 2007/3/28, Wei Shen <cquark@gmail.com>:
> > Hi,
> >
> > Since it seems that few people like my ideas, I have not apply for them
> as
> > SoC projects.
> >
> > If you think they are helpful. I will still try working on them.
> >
> > Regards,
> >
> > Wei
> >
> >
> > On 3/23/07, Wei Shen <cquark@gmail.com> wrote:
> > >
> > >
> > > Hi,
> > > I have two ideas and wonder whether they are welcome as SoC projects.
> > >
> > > 1) Simple file editing
> > >
> > > I think it is useful to add file edit function to Grub. Thus, if an OS
> > config file which is required to boot the OS successfully is mistakenly
> > written, we can still correct it in Grub and need not to reboot from the
> > floppy or cdrom just for the correcting.
> > > I know it would greately increase the complexity of Grub to support a
> > writable file system. However, if file writing does not change the block
> > counts of a file, things are much simpler. Since most config files are
> small
> > (occupying only one block), I think the solution will work.
> > >
> > > 2) addr option for module command
> > >
> > > Add nn option: "addr = value" to the module command. If the addr
> option is
> > specified, Grub will load the module to address value instead of the
> default
> > address.
> > >
> > > Regards,
> > >
> > > Wei Shen
> >
> >
> > _______________________________________________
> > 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
>

[-- Attachment #2: Type: text/html, Size: 3065 bytes --]

Re: Two SoC ideas

[Yoshinori K. Okuji]

On Wednesday 28 March 2007 13:06, Wei Shen wrote:
> Your are absolutely right. But I am not an expert on Grub.

Note that nobody is an expert from the beginning.

> I think the most important that Google SoC gives a student is not money,
> but a opportunity to participate and obtain help.

IMHO, SoC has two significant effects.

One of them is definitely money. Money is not a good motivation in software 
development, but money can allocate your time.

The other is advertisement. Even if people do not go to a museum usually, some 
of them might feel that they want to go, when a special exhibition is 
planned. SoC has the same effect. Even if people do not look at free software 
development usually, some of them might feel that they want to participate, 
when this kind of event is planned.

Besides these, however, I see no difference between mentees in SoC and other 
contributors. After all, our project is Free Software. You are always free to 
take part in our development, whenever you would feel to do so. Help? Yes, we 
do, as much as we can practically, regardless of whether you are paid or not.

I don't know if Jeroen is planning to take some money or not, but I myself did 
not take any cent of money from last year's SoC. So, from my point of view, 
there was no real difference between a mentee and another contributor. So I 
have helped all contributors equally.

Briefly, your contribution is welcome, no matter whatever you do with SoC.

Okuji

Re: Two SoC ideas

[Wei Shen]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

Dear Yoshinori K. Okuji,

You misunderstood me.

A beginer is always afraid of possible coldness, afraid of troubling others,
and fears his opinions are too naive.

He needs courage to propose own ideas. SoC gives an opportunity and more
importantly an excuse, and so he tells himself: I have reasons to
"disturb" my mentor and the community, because he is my mentor and they
decided to accept my project (though, we all know the holding organization
and mentors get no personal benefits).

I believe there will still be  many students to apply for SoC, even if
Google does not offer their maney.

Of course, Google has its own commercial interests. But, it is not of my
care.

Thanks,

Wei

On 3/29/07, Yoshinori K. Okuji <okuji@enbug.org> wrote:
>
> On Wednesday 28 March 2007 13:06, Wei Shen wrote:
> > Your are absolutely right. But I am not an expert on Grub.
>
> Note that nobody is an expert from the beginning.
>
> > I think the most important that Google SoC gives a student is not money,
> > but a opportunity to participate and obtain help.
>
> IMHO, SoC has two significant effects.
>
> One of them is definitely money. Money is not a good motivation in
> software
> development, but money can allocate your time.
>
> The other is advertisement. Even if people do not go to a museum usually,
> some
> of them might feel that they want to go, when a special exhibition is
> planned. SoC has the same effect. Even if people do not look at free
> software
> development usually, some of them might feel that they want to
> participate,
> when this kind of event is planned.
>
> Besides these, however, I see no difference between mentees in SoC and
> other
> contributors. After all, our project is Free Software. You are always free
> to
> take part in our development, whenever you would feel to do so. Help? Yes,
> we
> do, as much as we can practically, regardless of whether you are paid or
> not.
>
> I don't know if Jeroen is planning to take some money or not, but I myself
> did
> not take any cent of money from last year's SoC. So, from my point of
> view,
> there was no real difference between a mentee and another contributor. So
> I
> have helped all contributors equally.
>
> Briefly, your contribution is welcome, no matter whatever you do with SoC.
>
> Okuji
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3114 bytes --]

Re: Two SoC ideas

[Yoshinori K. Okuji]

On Thursday 29 March 2007 05:17, Wei Shen wrote:
> A beginer is always afraid of possible coldness, afraid of troubling
> others, and fears his opinions are too naive.

Not so always. If you are right, why do so many people participate in Free 
Software projects? Certainly, when I joined GRUB, my knowledge about 
bootstrap was quite poor, yet I didn't hesitate to contribute.

I can understand your feeling, but you lose many opportunities of gaining new 
experience, as long as you are scared. Well, it might not be a bad thing, 
after all, it is your freedom how you feel. But I personally feel sad if you 
don't contibute, only because you imagine that we might be cold.

Okuji

Re: Two SoC ideas

[Marco Gerards]

"Wei Shen" <cquark@gmail.com> writes:

Hi,

> A beginer is always afraid of possible coldness, afraid of troubling others,
> and fears his opinions are too naive.

Don't worry about that.  People don't always have the time when
replying to an email on the mailinglist or so.  It's normal and don't
worry about that.

The best thing to learn is by doing something stupid.  Just come with
a stupid idea, ugly code, etc.  People will tell you what's wrong with
it.  Don't be afraid for things like this, you will learn from this.

> He needs courage to propose own ideas. SoC gives an opportunity and more
> importantly an excuse, and so he tells himself: I have reasons to
> "disturb" my mentor and the community, because he is my mentor and they
> decided to accept my project (though, we all know the holding organization
> and mentors get no personal benefits).
>
> I believe there will still be  many students to apply for SoC, even if
> Google does not offer their maney.
>
> Of course, Google has its own commercial interests. But, it is not of my
> care.

In that case there is no single reason not to contribute.  :-)

--
Marco