absence notice...

absence notice...

[Vesa Jääskeläinen]

Hi All,

I will be absence from the project related work for a while... So please
feel free to continue or replace the work that I may have got pending.

Some tasks that could be done:

- Video API: save/restore mode. Use "anonymous" data structure that only
device driver itself understands. Having one common block that video
subsystem understands and can choose proper video driver. Idea is to
save mode and then execute something in different mode (Eg. test
videomode) and then restore back to working one if it does not work.

struct
{
	// common part
	char *driver_name/id;

	// driver specific data
	char driver_specific[0];
};

- MM: improve allocation strategy to allocate from start or end of area.
Add more memory areas to MM. Needed at least on x86 with Real Mode
possibility (eg. PCBIOS in use). Need to have difference between lowmem
(< 1MiB) vs. highmem. GRUB normal code/data should go to highmem. BIOS
access data need to go to lowmem. OS kernel code probably should be
loaded at begining on highmem.

Colin: Please feel free to integrate graphical menu change without my
approval. If you feel unsure, please ask in mailing list.

Can't remember anything else for this occasion what important would have
been under the work.

I might read this mailing list occasionally, but don't be suppriced if I
do not notice questions addressed to me.

Thanks,
Vesa Jääskeläinen

Re: absence notice...

[Vladimir 'phcoder' Serbinenko]

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

Hello, Vesa. Take your time and have fun.

2009/5/2 Vesa Jääskeläinen <chaac@nic.fi>

> Hi All,
>
> I will be absence from the project related work for a while... So please
> feel free to continue or replace the work that I may have got pending.
>
> Some tasks that could be done:
>
> - Video API: save/restore mode. Use "anonymous" data structure that only
> device driver itself understands. Having one common block that video
> subsystem understands and can choose proper video driver. Idea is to
> save mode and then execute something in different mode (Eg. test
> videomode) and then restore back to working one if it does not work.
>
> struct
> {
>        // common part
>        char *driver_name/id;
>
>        // driver specific data
>        char driver_specific[0];
> };
>
> - MM: improve allocation strategy to allocate from start or end of area.
> Add more memory areas to MM. Needed at least on x86 with Real Mode
> possibility (eg. PCBIOS in use). Need to have difference between lowmem
> (< 1MiB) vs. highmem. GRUB normal code/data should go to highmem. BIOS
> access data need to go to lowmem. OS kernel code probably should be
> loaded at begining on highmem.
>
I will do this.  I know you already had some work for mm underway that's why
I wasn't doing it. Could you send what you already have even if it's far
from complete?

>
> Colin: Please feel free to integrate graphical menu change without my
> approval. If you feel unsure, please ask in mailing list.
>
> Can't remember anything else for this occasion what important would have
> been under the work.

Framebuffer/vbe split ;)

>
>
> I might read this mailing list occasionally, but don't be suppriced if I
> do not notice questions addressed to me.
>
> Thanks,
> Vesa Jääskeläinen
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

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

Re: absence notice...

[Vesa Jääskeläinen]

Vladimir 'phcoder' Serbinenko wrote:
> I will do this.  I know you already had some work for mm underway that's why
> I wasn't doing it. Could you send what you already have even if it's far
> from complete?

Sorry. Everything got lost on laptop.

Re: absence notice...

[Colin D Bennett]

Vesa Jääskeläinen wrote on Saturday 02 May 2009:
> Hi All,
>
> I will be absence from the project related work for a while... So please
> feel free to continue or replace the work that I may have got pending.
>...
> Colin: Please feel free to integrate graphical menu change without my
> approval. If you feel unsure, please ask in mailing list.

I hope to have a chance to finish up integrating the graphical menu changes 
with the current GRUB codebase soon (I have to resolve some merge conflicts 
first).  Having newborn twins means that “sleep” and “free time” are 
nonexistent for me right now, but hopefully that will change soon!  :-)

Regards,
Colin

Re: absence notice...

[Bean]

Hi Colin,

Thanks for the effort. If you're really busy, you can just send the
remaining patch to the list, I can resolve conflict and merge it in.

On Sun, May 3, 2009 at 12:38 PM, Colin D Bennett <colin@gibibit.com> wrote:
> Vesa Jääskeläinen wrote on Saturday 02 May 2009:
>> Hi All,
>>
>> I will be absence from the project related work for a while... So please
>> feel free to continue or replace the work that I may have got pending.
>>...
>> Colin: Please feel free to integrate graphical menu change without my
>> approval. If you feel unsure, please ask in mailing list.
>
> I hope to have a chance to finish up integrating the graphical menu changes
> with the current GRUB codebase soon (I have to resolve some merge conflicts
> first).  Having newborn twins means that “sleep” and “free time” are
> nonexistent for me right now, but hopefully that will change soon!  :-)
>
> Regards,
> Colin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

Absence notice

[Vladimir 'phcoder' Serbinenko]

Hello. Tomorrow I go on my travel to France (RMLL) and won't be active
till 14 July. I'll stay in contact but will not be able to review
patches. I know that it doesn't change my status a lot right now -
last week was pretty busy too. When I come back I'll catch up with the
progress. If someone needs any of my patches in the trunk feel free to
commit.
Could someone review nested partition patch? It changes sufficiently a
lot to need a peer review and I need for clear network naming support
(I plan to use a syntax like (ftp,192.168.1.1,21,user,pass)/grub.cfg )
@Pavel: thank you very much for being so active and pushing project
forward.Keep up with the good work

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Absence notice

[Pavel Roskin]

On Thu, 2009-07-02 at 23:02 +0200, Vladimir 'phcoder' Serbinenko wrote:
> Hello. Tomorrow I go on my travel to France (RMLL) and won't be active
> till 14 July.

Bon voyage! :-)

>  I'll stay in contact but will not be able to review
> patches. I know that it doesn't change my status a lot right now -
> last week was pretty busy too. When I come back I'll catch up with the
> progress. If someone needs any of my patches in the trunk feel free to
> commit.
> Could someone review nested partition patch?

It doesn't apply in loader/i386/pc/chainloader.c at all.

I think some parts could be split and applied separately.  I don't think
there are any objections against supporting nested partitions.  But I
think it would be better to support letters for BSD partitions if it's
not too hard.

>  It changes sufficiently a
> lot to need a peer review and I need for clear network naming support
> (I plan to use a syntax like (ftp,192.168.1.1,21,user,pass)/grub.cfg )

I think the networking is better split from GRUB as a separate project
under GPLv2.  It would be a huge effort to reimplement networking under
GPLv3.  And I don't see it as a priority.  The priority should be
supplanting GRUB1, yaboot and other bootloaders currently in use.

> @Pavel: thank you very much for being so active and pushing project
> forward.Keep up with the good work

Thanks!

-- 
Regards,
Pavel Roskin

Re: Absence notice

[Vladimir 'phcoder' Serbinenko]

On Fri, Jul 3, 2009 at 12:08 AM, Pavel Roskin<proski@gnu.org> wrote:
> On Thu, 2009-07-02 at 23:02 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Hello. Tomorrow I go on my travel to France (RMLL) and won't be active
>> till 14 July.
>
> Bon voyage! :-)
Thanks
>
>>  I'll stay in contact but will not be able to review
>> patches. I know that it doesn't change my status a lot right now -
>> last week was pretty busy too. When I come back I'll catch up with the
>> progress. If someone needs any of my patches in the trunk feel free to
>> commit.
>> Could someone review nested partition patch?
>
> It doesn't apply in loader/i386/pc/chainloader.c at all.
Ok, I'll rediff.
>
> I think some parts could be split and applied separately.
I'll look but afair it's not possible without breaking something
> I don't think
> there are any objections against supporting nested partitions.
Yes but I thought someone may have comments like "let's shave ths part
from the kernel". The patch doesn't increase the core.img because
increase of kernel size is compensated by pc.mod/bsdlabel.mod split.
It the cases when bsdlabel.mod is used usually no modules like raid or
lvm are used
> But I
> think it would be better to support letters for BSD partitions if it's
> not too hard.
It's done. THe patch treats 'a' and 1 completely alike
>
>>  It changes sufficiently a
>> lot to need a peer review and I need for clear network naming support
>> (I plan to use a syntax like (ftp,192.168.1.1,21,user,pass)/grub.cfg )
>
> I think the networking is better split from GRUB as a separate project
> under GPLv2.  It would be a huge effort to reimplement networking under
> GPLv3.
You wrong on this point because of http://www.sics.se/~adam/lwip/.
It's a complete TCP/IP stack with loads of features suited for preboot
environment and under 3-clause BSD license. I'll use it as a base. We
can import hw drivers from gPXE (most are GPLv3+-compatible) and
FreeBSD then
>  And I don't see it as a priority.  The priority should be
> supplanting GRUB1, yaboot and other bootloaders currently in use.
>
It's my priority. Solaris folks are willing to move to grub2 but are
uncomfortable to lose netboot. (nested partitions and zfs were for
them too) Additionaly I have a laptop without CD-ROM and want to push
distributors to have completely network-based installation. For this a
FTP or HTTP supportin grub would be very nice
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Absence notice

[Pavel Roskin]

On Fri, 2009-07-03 at 01:29 +0200, Vladimir 'phcoder' Serbinenko wrote:

> > It doesn't apply in loader/i386/pc/chainloader.c at all.
> Ok, I'll rediff.

Take your time.

Actually, the chainloader patch refers to "disk->parition" (misspelled
"partition"), so i doubt that it was even compile tested.

> > I think some parts could be split and applied separately.
> I'll look but afair it's not possible without breaking something

We'll see when we have a working patch.

> > I don't think
> > there are any objections against supporting nested partitions.
> Yes but I thought someone may have comments like "let's shave ths part
> from the kernel". The patch doesn't increase the core.img because
> increase of kernel size is compensated by pc.mod/bsdlabel.mod split.
> It the cases when bsdlabel.mod is used usually no modules like raid or
> lvm are used

Such objections may be raised once there is a patch that compiles.
Distributors must consider worst case scenarios.

> > But I
> > think it would be better to support letters for BSD partitions if it's
> > not too hard.
> It's done. THe patch treats 'a' and 1 completely alike

Good!

> >>  It changes sufficiently a
> >> lot to need a peer review and I need for clear network naming support
> >> (I plan to use a syntax like (ftp,192.168.1.1,21,user,pass)/grub.cfg )
> >
> > I think the networking is better split from GRUB as a separate project
> > under GPLv2.  It would be a huge effort to reimplement networking under
> > GPLv3.
> You wrong on this point because of http://www.sics.se/~adam/lwip/.
> It's a complete TCP/IP stack with loads of features suited for preboot
> environment and under 3-clause BSD license. I'll use it as a base. We
> can import hw drivers from gPXE (most are GPLv3+-compatible) and
> FreeBSD then

OK, good to know.

> >  And I don't see it as a priority.  The priority should be
> > supplanting GRUB1, yaboot and other bootloaders currently in use.
> >
> It's my priority. Solaris folks are willing to move to grub2 but are
> uncomfortable to lose netboot. (nested partitions and zfs were for
> them too) Additionaly I have a laptop without CD-ROM and want to push
> distributors to have completely network-based installation. For this a
> FTP or HTTP supportin grub would be very nice

I see.

-- 
Regards,
Pavel Roskin

Re: Absence notice

[Vladimir 'phcoder' Serbinenko]

On Fri, Jul 3, 2009 at 7:22 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Fri, 2009-07-03 at 01:29 +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> > It doesn't apply in loader/i386/pc/chainloader.c at all.
>> Ok, I'll rediff.
>
> Take your time.
>
> Actually, the chainloader patch refers to "disk->parition" (misspelled
> "partition"), so i doubt that it was even compile tested.
My bad. Normally I test my patches and perhaps I just compiled wrong
directory (I build externally and may have forgotten configure). I
don't remember what exactly happened but I clearly did a big mistake
/me feels ashamed
>> > I don't think
>> > there are any objections against supporting nested partitions.
>> Yes but I thought someone may have comments like "let's shave ths part
>> from the kernel". The patch doesn't increase the core.img because
>> increase of kernel size is compensated by pc.mod/bsdlabel.mod split.
>> It the cases when bsdlabel.mod is used usually no modules like raid or
>> lvm are used
>
> Such objections may be raised once there is a patch that compiles.
> Distributors must consider worst case scenarios.
>
If worst-case scenarios don't fit into mbr gap we may consider another
approaches
1) progressive loading (e.g. FS-parsing bootsectors in worst case
bring some kind of stage1.5 back)
2) replace lzma with xz
3) use another embedding areas. E.g. lvm has to divide PV in PE of
equal length. This often results in last block of space being smaller
then PE. This space is reported by pvdisplay as unusable and we may
use it w/o problems. I'm not an lvm expert though so don't rely on my
word

> OK, good to know.
Well it's still a considerable effort but not as hge as implementing
TCP/IP stack from scratch



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Absence notice

[Pavel Roskin]

On Fri, 2009-07-03 at 19:35 +0200, Vladimir 'phcoder' Serbinenko wrote:

> >> > I don't think
> >> > there are any objections against supporting nested partitions.
> >> Yes but I thought someone may have comments like "let's shave ths part
> >> from the kernel". The patch doesn't increase the core.img because
> >> increase of kernel size is compensated by pc.mod/bsdlabel.mod split.
> >> It the cases when bsdlabel.mod is used usually no modules like raid or
> >> lvm are used
> >
> > Such objections may be raised once there is a patch that compiles.
> > Distributors must consider worst case scenarios.
> >
> If worst-case scenarios don't fit into mbr gap we may consider another
> approaches
> 1) progressive loading (e.g. FS-parsing bootsectors in worst case
> bring some kind of stage1.5 back)

I don't think this would be very popular.

> 2) replace lzma with xz

I'm afraid it's the same thing essentially.

> 3) use another embedding areas. E.g. lvm has to divide PV in PE of
> equal length. This often results in last block of space being smaller
> then PE. This space is reported by pvdisplay as unusable and we may
> use it w/o problems. I'm not an lvm expert though so don't rely on my
> word

Or just use a separate partition.

Actually, it's a fair game not to support some especially convoluted
configurations.

-- 
Regards,
Pavel Roskin

Re: Absence notice

[Robert Millan]

On Fri, Jul 03, 2009 at 07:35:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> If worst-case scenarios don't fit into mbr gap we may consider another
> approaches
> 1) progressive loading (e.g. FS-parsing bootsectors in worst case
> bring some kind of stage1.5 back)
> 2) replace lzma with xz
> 3) use another embedding areas. E.g. lvm has to divide PV in PE of
> equal length. This often results in last block of space being smaller
> then PE. This space is reported by pvdisplay as unusable and we may
> use it w/o problems. I'm not an lvm expert though so don't rely on my
> word

Please, strive for simplicity.  We're not compelled to engineer such kind
of complicated solutions (except for changing our compressor) just because
some of our users insist in giving us crappy disk layouts and want us to
support them.

We don't have to support everything at all cost.  Some problems are much
more easily solved by just saying no.

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