partition layouts

partition layouts

[Hollis Blanchard]

I've been thinking about how to install grub2 on an Open Firmware 
system. Here's one possibility:
	/boot -- Linux-native filesystem (e.g. ext3)
		holds kernels, initrd, etc
	/boot/grub -- firmware-native filesystem (on Mac HFS+, on others FAT, 
etc)
		holds grub executable, grub.cfg, modules

The grub ELF file must live on a firmware-native filesystem. When run, 
it can find out what partition it was booted from, so that is a natural 
place to load grub.cfg from as well (and why not modules while we're at 
it?). Thus this is the value of the "prefix" GRUB environment variable.

When booting kernels from another partition though, we're left with 
something like this:
	title Linux
		linux (hd,7)/vmlinux-foo root=/dev/hda12
		initrd (hd,7)/initrd-foo

[To summarize:
(hd,5) -- /boot/grub
(hd,7) -- /boot
(hd,11) -- /
]

Can we have a shortcut to avoid specifying that "(hd,7)/" part 
repeatedly? I think that was the "root" command in GRUB Legacy, which 
was replaced by the "prefix" environment variable? But as I mentioned, 
"prefix" doesn't have the meaning we're looking for here...

The other possibility is to have all of /boot as a firmware-native 
filesystem. I think that's not ideal though, because those filesystems 
(HFS+, FAT) might not support features like symlinks or Unix-style 
permissions, or may not be as well-tested as Linux-native filesystems.

-Hollis

Re: partition layouts

[Vernon Mauery]

Hollis Blanchard wrote:
> I've been thinking about how to install grub2 on an Open Firmware
> system. Here's one possibility:
>     /boot -- Linux-native filesystem (e.g. ext3)
>         holds kernels, initrd, etc
>     /boot/grub -- firmware-native filesystem (on Mac HFS+, on others
> FAT, etc)
>         holds grub executable, grub.cfg, modules
> 
> The grub ELF file must live on a firmware-native filesystem. When run,
> it can find out what partition it was booted from, so that is a natural
> place to load grub.cfg from as well (and why not modules while we're at
> it?). Thus this is the value of the "prefix" GRUB environment variable.

Putting a restraint that says /boot/grub must be a separate partition doesn't sound like a good idea.  It just clutters the partition table with another small partition. 

If all it gains us is that we know where we booted from, we still need to know where /boot is.  I don't see what this gains us -- the root command or prefix variable is still required.  It sounds to me that if you want to have a firmware native partition type, having all of /boot be that type would be preferred.

--Vernon

Re: partition layouts

[Yoshinori K. Okuji]

On Tuesday 05 April 2005 02:38 am, Hollis Blanchard wrote:
> Can we have a shortcut to avoid specifying that "(hd,7)/" part
> repeatedly? I think that was the "root" command in GRUB Legacy, which
> was replaced by the "prefix" environment variable? But as I mentioned,
> "prefix" doesn't have the meaning we're looking for here...

root is not a command but a variable in GRUB 2.

Okuji

Re: partition layouts

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> The grub ELF file must live on a firmware-native filesystem. When run,
> it can find out what partition it was booted from, so that is a
> natural place to load grub.cfg from as well (and why not modules while
> we're at it?). Thus this is the value of the "prefix" GRUB environment
> variable.

Sounds fine to me, assuming things work like we discussed about.

> Can we have a shortcut to avoid specifying that "(hd,7)/" part
> repeatedly? I think that was the "root" command in GRUB Legacy, which
> was replaced by the "prefix" environment variable? But as I mentioned,
> "prefix" doesn't have the meaning we're looking for here...

There is the root variable, but IIRC there were some problems or so.
Anyway, it is how it will work. :)

> The other possibility is to have all of /boot as a firmware-native
> filesystem. I think that's not ideal though, because those filesystems
> (HFS+, FAT) might not support features like symlinks or Unix-style
> permissions, or may not be as well-tested as Linux-native filesystems.

HFS+ supports symlinks, FAT does not (unless you use UMSDOS, which is
not supported).  For every symlink capable filesystem GRUB 2 supports,
symlink support was implemented.

Personally I do not care very much how it will work in practise.  The
main important thing for me is that we can support both of your
proposals.  I think we just have to try both, when possible on many
different machines.

Thanks,
Marco

Re: partition layouts

[Marco Gerards]

Vernon Mauery <vernon-grub@mauery.com> writes:

> Putting a restraint that says /boot/grub must be a separate
> partition doesn't sound like a good idea.  It just clutters the
> partition table with another small partition.

For the apple this was always the case already.  It is something we
can not change.

> If all it gains us is that we know where we booted from, we still
> need to know where /boot is.  I don't see what this gains us -- the
> root command or prefix variable is still required.  It sounds to me
> that if you want to have a firmware native partition type, having
> all of /boot be that type would be preferred.

The discussion is about automatically setting prefix.

--
Marco

Re: partition layouts

[Tomas 'Ebik' Ebenlendr]

> I've been thinking about how to install grub2 on an Open Firmware 
> system. Here's one possibility:
> 	/boot -- Linux-native filesystem (e.g. ext3)
> 		holds kernels, initrd, etc
> 	/boot/grub -- firmware-native filesystem (on Mac HFS+, on others 
> 	FAT, etc)
> 		holds grub executable, grub.cfg, modules
> 
> The grub ELF file must live on a firmware-native filesystem. When run, 
> it can find out what partition it was booted from, so that is a natural 
> place to load grub.cfg from as well (and why not modules while we're at 
> it?). Thus this is the value of the "prefix" GRUB environment variable.
> 
> When booting kernels from another partition though, we're left with 
> something like this:
> 	title Linux
> 		linux (hd,7)/vmlinux-foo root=/dev/hda12
> 		initrd (hd,7)/initrd-foo
> 
> [To summarize:
> (hd,5) -- /boot/grub
> (hd,7) -- /boot
> (hd,11) -- /
> ]
> 

Just simple question. Why /boot is separated partition now? (Well, in
cases that / is readable by grub). We can recommend users not to use
/boot as separate partition to not confuse themselves and
to not partition drive too much.
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 

Re: partition layouts

[Vernon Mauery]

Marco Gerards wrote:
> Vernon Mauery <vernon-grub@mauery.com> writes:

>>If all it gains us is that we know where we booted from, we still
>>need to know where /boot is.  I don't see what this gains us -- the
>>root command or prefix variable is still required.  It sounds to me
>>that if you want to have a firmware native partition type, having
>>all of /boot be that type would be preferred.
> 
> 
> The discussion is about automatically setting prefix.

But if prefix is what root used to be (the location of the kernels, initrds, etc.) then I don't see how having a grub partition helps in setting this.  It will help locate the grub binaries, but not the kernels (as I see it).

--Vernon

Re: partition layouts

[Marco Gerards]

Vernon Mauery <vernon-grub@mauery.com> writes:

>> The discussion is about automatically setting prefix.
>
> But if prefix is what root used to be (the location of the kernels,
> initrds, etc.) then I don't see how having a grub partition helps in
> setting this.  It will help locate the grub binaries, but not the
> kernels (as I see it).

Prefix *is* for locating the GRUB modules and grub.cfg and for nothing
else.

There is no GRUB partition.  The partition we are talking about is a
partition the firmware can access to load GRUB from.  Because this
partition has to be created anyway, it is quite convenient to use it
for the modules as well.

For locating the kernels you need to set root.  If this partition for
the firmware is mounted on /boot, prefix==root.  Which would be nice,
but not a requirement IMO.

--
Marco

Re: partition layouts - symlinks

[Hollis Blanchard]

On Apr 5, 2005, at 2:00 AM, Marco Gerards wrote:

> Hollis Blanchard <hollis@penguinppc.org> writes:
>
>> The other possibility is to have all of /boot as a firmware-native
>> filesystem. I think that's not ideal though, because those filesystems
>> (HFS+, FAT) might not support features like symlinks or Unix-style
>> permissions, or may not be as well-tested as Linux-native filesystems.
>
> HFS+ supports symlinks, FAT does not (unless you use UMSDOS, which is
> not supported).  For every symlink capable filesystem GRUB 2 supports,
> symlink support was implemented.

I think you misunderstand this point. I am not worried about GRUB's 
filesystem support. I am worried about how some Linux distributions 
like to install several kernels (e.g. vmlinux-foo-smp, vmlinux-foo) and 
then create a plain "vmlinux" symlink to the default. That cannot work 
on FAT.

Similarly, reliance on Unix file permissions in /boot will not work 
with FAT. Admittedly this may be less important, as non-root users 
probably have no business in /boot at all, so mount-specified 
permissions may be adequate.

What about fsck on /boot? Aren't these all good reasons to keep /boot 
as a Linux-native filesystem?

-Hollis

Re: partition layouts - separate /boot

[Hollis Blanchard]

On Apr 4, 2005, at 11:55 PM, Vernon Mauery wrote:

> Hollis Blanchard wrote:
>> I've been thinking about how to install grub2 on an Open Firmware
>> system. Here's one possibility:
>>     /boot -- Linux-native filesystem (e.g. ext3)
>>         holds kernels, initrd, etc
>>     /boot/grub -- firmware-native filesystem (on Mac HFS+, on others
>> FAT, etc)
>>         holds grub executable, grub.cfg, modules
>>
>> The grub ELF file must live on a firmware-native filesystem. When run,
>> it can find out what partition it was booted from, so that is a 
>> natural
>> place to load grub.cfg from as well (and why not modules while we're 
>> at
>> it?). Thus this is the value of the "prefix" GRUB environment 
>> variable.
>
> Putting a restraint that says /boot/grub must be a separate partition 
> doesn't sound like a good idea.  It just clutters the partition table 
> with another small partition.
>
> If all it gains us is that we know where we booted from, we still need 
> to know where /boot is.  I don't see what this gains us -- the root 
> command or prefix variable is still required.  It sounds to me that if 
> you want to have a firmware native partition type, having all of /boot 
> be that type would be preferred.

I know there is at least one version of IBM Open Firmware which has a 
4GB limit on disk reads.  Creating a separate partition is the only way 
I know of to keep a filesystem from locating blocks above that 4GB 
limit.

You're correct: if we have /boot and /boot/grub partitions, we still 
need to know where /boot is. That's the heart of my question.

Haven't my arguments about trying to use FAT for /boot convinced you 
that using a firmware-native filesystem may not always be a good idea? 
To summarize, firmware-native filesystems:
- may not be well-tested (HFS)
- may not support expected features like symlinks or file permissions 
(FAT)
- may be less reliable, e.g. no journalling (FAT)
- may not support fsck, and wouldn't you like to fix filesystem 
corruption on /boot?

-Hollis

Re: partition layouts

[Hollis Blanchard]

On Apr 5, 2005, at 2:02 AM, Marco Gerards wrote:

> Vernon Mauery <vernon-grub@mauery.com> writes:
>
>> Putting a restraint that says /boot/grub must be a separate
>> partition doesn't sound like a good idea.  It just clutters the
>> partition table with another small partition.
>
> For the apple this was always the case already.  It is something we
> can not change.

As I have described in the thread "set prefix on PPC", this is not 
correct. We are not constrained by ybin's behavior. We can create 
whatever partitioning layout we see fit, as long as firmware and OS can 
support it.

There is no hard requirement to have a separate /boot/grub, but I think 
the arguments I've raised point us in that direction.

-Hollis

Re: partition layouts

[Hollis Blanchard]

On Apr 5, 2005, at 12:41 AM, Yoshinori K. Okuji wrote:

> On Tuesday 05 April 2005 02:38 am, Hollis Blanchard wrote:
>> Can we have a shortcut to avoid specifying that "(hd,7)/" part
>> repeatedly? I think that was the "root" command in GRUB Legacy, which
>> was replaced by the "prefix" environment variable? But as I mentioned,
>> "prefix" doesn't have the meaning we're looking for here...
>
> root is not a command but a variable in GRUB 2.

Actually, I see now that it is a command: grub_rescue_cmd_root() in 
kern/rescue.c. Is that only a rescue mode thing? That seems to be 
exactly what I need... aside from the very confusing use of "root" 
meaning where GRUB finds the kernel and "root" meaning where Linux 
finds /sbin/init.

I cannot find any grub_env_get("root") callers.

-Hollis

Re: partition layouts

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

>> root is not a command but a variable in GRUB 2.
>
> Actually, I see now that it is a command: grub_rescue_cmd_root() in
> kern/rescue.c. Is that only a rescue mode thing? That seems to be
> exactly what I need... aside from the very confusing use of "root"
> meaning where GRUB finds the kernel and "root" meaning where Linux
> finds /sbin/init.

Personally I do not care about if GRUB is confusing for linux users.
As I see it, GRUB is not only a linux loader.

> I cannot find any grub_env_get("root") callers.

I thought I have changed the command to the variable.  But perhaps
this was only done for prefix (although that would be weird...).  In
that case we need a `root' variable.  It is high on my todo list now,
but don't rely too much on me and my todo list and please write it if
you need it.  It is the right thing to do it this way.

--
Marco

Re: partition layouts - "root"

[Hollis Blanchard]

On Apr 5, 2005, at 11:45 AM, Marco Gerards wrote:

> Hollis Blanchard <hollis@penguinppc.org> writes:
>
>>> root is not a command but a variable in GRUB 2.
>>
>> Actually, I see now that it is a command: grub_rescue_cmd_root() in
>> kern/rescue.c. Is that only a rescue mode thing? That seems to be
>> exactly what I need... aside from the very confusing use of "root"
>> meaning where GRUB finds the kernel and "root" meaning where Linux
>> finds /sbin/init.
>
> Personally I do not care about if GRUB is confusing for linux users.
> As I see it, GRUB is not only a linux loader.

I see that Mach also uses "root" as a kernel argument. I certainly 
agree that GRUB is not only a Linux loader. However I strongly disagree 
that we should intentionally confuse Linux users.

Perhaps using "grubroot", "grubprefix", "grubbase", or similar will be 
acceptable?

>> I cannot find any grub_env_get("root") callers.
>
> I thought I have changed the command to the variable.  But perhaps
> this was only done for prefix (although that would be weird...).  In
> that case we need a `root' variable.  It is high on my todo list now,
> but don't rely too much on me and my todo list and please write it if
> you need it.  It is the right thing to do it this way.

So each menu entry should look something like this?
	title foo
		set root=bar
		multiboot /kernel

-Hollis

Re: partition layouts - "root"

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

>> Personally I do not care about if GRUB is confusing for linux users.
>> As I see it, GRUB is not only a linux loader.
>
> I see that Mach also uses "root" as a kernel argument. I certainly
> agree that GRUB is not only a Linux loader. However I strongly
> disagree that we should intentionally confuse Linux users.

It is not intentionally to confuse people.

> Perhaps using "grubroot", "grubprefix", "grubbase", or similar will be
> acceptable?

For me it is, of course, open or discussion.  However, I just like
`root'.  I do not like the grub prefix.  When removing the prefix
grubroot and grubprefix are not possible.  Perhaps base, but you would
have to convince Okuji.

>>> I cannot find any grub_env_get("root") callers.
>>
>> I thought I have changed the command to the variable.  But perhaps
>> this was only done for prefix (although that would be weird...).  In
>> that case we need a `root' variable.  It is high on my todo list now,
>> but don't rely too much on me and my todo list and please write it if
>> you need it.  It is the right thing to do it this way.
>
> So each menu entry should look something like this?
> 	title foo
> 		set root=bar
> 		multiboot /kernel

That is right.

Thanks,
Marco

Re: partition layouts - "root"

[Hollis Blanchard]

On Apr 6, 2005, at 1:32 AM, Marco Gerards wrote:

> Hollis Blanchard <hollis@penguinppc.org> writes:
>> Perhaps using "grubroot", "grubprefix", "grubbase", or similar will be
>> acceptable?
>
> For me it is, of course, open or discussion.  However, I just like
> `root'.  I do not like the grub prefix.  When removing the prefix
> grubroot and grubprefix are not possible.  Perhaps base, but you would
> have to convince Okuji.

Okuji? Hmm, what about "device"?
	title foo
		set device=bar
		multiboot /kernel root=baz

I would like to avoid this:
	title foo
		set root=bar
		multiboot /kernel root=baz
... because here we are specifying two unrelated "root" variables.

-Hollis

Re: partition layouts - "root"

[Antoine Terrienne]

Selon Hollis Blanchard <hollis@penguinppc.org>:

>
> Okuji? Hmm, what about "device"?
> 	title foo
> 		set device=bar
> 		multiboot /kernel root=baz
>
> I would like to avoid this:
> 	title foo
> 		set root=bar
> 		multiboot /kernel root=baz
> ... because here we are specifying two unrelated "root" variables.
>
> -Hollis
>

The first root variable is a Grub variable but se second is a Linux kernel
argument. I think changing the Grub notation just beacause it can confuse with
the kernel argument is not that good. Linux uses "root" but we cannot garanteed
that a another system (*BSD, L4, Mac OS, AmigaOS, etc...) will not use "device".
So whaterver the name we use for the Grub variables/function we cannot be sure
it will not be used by the system we boot.
I think keeping "root" is a good choice as the user is supposed to know the
arguments of the kernel he wants to boot and how to invoque it.

--
--
  ____
 /    \  / antoine.terrienne@free.fr
|  o o | - http://antoine.terrienne.free.fr
|   o  | \ #153026466
\  V V /
 \_/\_/

Re: partition layouts - "root"

[Hollis Blanchard]

On Apr 6, 2005, at 10:43 AM, Antoine Terrienne wrote:

> Selon Hollis Blanchard <hollis@penguinppc.org>:
>>
>> Okuji? Hmm, what about "device"?
>> 	title foo
>> 		set device=bar
>> 		multiboot /kernel root=baz
>>
>> I would like to avoid this:
>> 	title foo
>> 		set root=bar
>> 		multiboot /kernel root=baz
>> ... because here we are specifying two unrelated "root" variables.
>
> The first root variable is a Grub variable but se second is a Linux 
> kernel
> argument. I think changing the Grub notation just beacause it can 
> confuse with
> the kernel argument is not that good. Linux uses "root" but we cannot 
> garanteed
> that a another system (*BSD, L4, Mac OS, AmigaOS, etc...) will not use 
> "device".

Agreed. However, we know right now that several OSs do this, and that 
by far covers the greatest number of GRUB users.

> So whaterver the name we use for the Grub variables/function we cannot 
> be sure
> it will not be used by the system we boot.
> I think keeping "root" is a good choice as the user is supposed to 
> know the
> arguments of the kernel he wants to boot and how to invoque it.

It's clear to you and I, but seeing "root=foo" "root=bar" is obviously 
not very friendly and in general should be avoided.

-Hollis

Re: partition layouts - "root"

[Yoshinori K. Okuji]

On Thursday 07 April 2005 02:02 am, Hollis Blanchard wrote:
> It's clear to you and I, but seeing "root=foo" "root=bar" is obviously
> not very friendly and in general should be avoided.

I understand your point. But I don't like "device", because it is too generic.

The advantage of "root" is that all GRUB Legacy users understand it.

One radical change would be to introduce the concept of "current working 
device" or "current working directory":

grub> cd (hd0)
grub> pwd
(hd0)

This is consistent with Bash, but users would expect that they can do "cd 
(hd0,0)/boot". Then the behavior of "ls" or TAB is inconsistent.

Okuji

Re: partition layouts - "root"

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Thursday 07 April 2005 02:02 am, Hollis Blanchard wrote:
>> It's clear to you and I, but seeing "root=foo" "root=bar" is obviously
>> not very friendly and in general should be avoided.
>
> I understand your point. But I don't like "device", because it is too generic.

Someone suggested bootdevice on IRC.  I like that one, while is not
that generic.

> The advantage of "root" is that all GRUB Legacy users understand it.

This is really important, I think.

> One radical change would be to introduce the concept of "current working 
> device" or "current working directory":
>
> grub> cd (hd0)
> grub> pwd
> (hd0)
>
> This is consistent with Bash, but users would expect that they can do "cd 
> (hd0,0)/boot". Then the behavior of "ls" or TAB is inconsistent.

This should not be the case.  Not if both tab, ls, linux, etc work
from pwd.  In that case you can cd somewhere and everything you use is
in the current dir.  And there are relative (../foo) and absolute
(/foo) paths.

This is all consistent with bash.  And it should work with all
filesystems I have implemented.  I would like this approach.  You
could even parse `.', `..' and `/' in fs.c so it becomes generic and
you don't have to pass idiotic strings to the filesystems.

Thanks,
Marco

Re: partition layouts - "root"

[Yoshinori K. Okuji]

On Thursday 07 April 2005 04:37 pm, Marco Gerards wrote:
> Someone suggested bootdevice on IRC.  I like that one, while is not
> that generic.

I feel that it is too long to type.

> This should not be the case.  Not if both tab, ls, linux, etc work
> from pwd.  In that case you can cd somewhere and everything you use is
> in the current dir.  And there are relative (../foo) and absolute
> (/foo) paths.

The question is how to "ls" devices. For TAB, you could prefix '(' for 
completion. For "ls", "ls (" looks very strange for me.

Okuji

Re: partition layouts - "root"

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

>> This should not be the case.  Not if both tab, ls, linux, etc work
>> from pwd.  In that case you can cd somewhere and everything you use is
>> in the current dir.  And there are relative (../foo) and absolute
>> (/foo) paths.
>
> The question is how to "ls" devices. For TAB, you could prefix '(' for 
> completion. For "ls", "ls (" looks very strange for me.

We could make a switch for this (`ls --devices', or `ls -d') or a new
command called `lsdev'.  If we do this everything will work like
expected, I think.

--
Marco

Re: partition layouts - "root"

[Yoshinori K. Okuji]

On Friday 08 April 2005 08:39 am, Marco Gerards wrote:
> We could make a switch for this (`ls --devices', or `ls -d') or a new
> command called `lsdev'.  If we do this everything will work like
> expected, I think.

Do you think it would be more convenient than the current behavior of ls? I'm 
not sure. I'd like to know what others think about this.

Okuji

Re: partition layouts - "root"

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Friday 08 April 2005 08:39 am, Marco Gerards wrote:
>> We could make a switch for this (`ls --devices', or `ls -d') or a new
>> command called `lsdev'.  If we do this everything will work like
>> expected, I think.
>
> Do you think it would be more convenient than the current behavior of ls? I'm 
> not sure. I'd like to know what others think about this.

By doing this, everything will work the same using the path set by
`cd'.  That will make things, for my feeling, more convenient.

--
Marco

Re: partition layouts - "root"

[Hollis Blanchard]

On Apr 8, 2005, at 1:39 AM, Marco Gerards wrote:

> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>
>>> This should not be the case.  Not if both tab, ls, linux, etc work
>>> from pwd.  In that case you can cd somewhere and everything you use 
>>> is
>>> in the current dir.  And there are relative (../foo) and absolute
>>> (/foo) paths.
>>
>> The question is how to "ls" devices. For TAB, you could prefix '(' for
>> completion. For "ls", "ls (" looks very strange for me.
>
> We could make a switch for this (`ls --devices', or `ls -d') or a new
> command called `lsdev'.  If we do this everything will work like
> expected, I think.

I think I like this idea a lot. It would also be nice if the various 
file-based commands (like cat and cmp) also looked at the current 
working directory as well.

lsdev (or lsdisk?) also makes a lot of sense to me.

-Hollis

Re: partition layouts - "root"

[Yoshinori K. Okuji]

On Thursday 14 April 2005 05:46 am, Hollis Blanchard wrote:
> I think I like this idea a lot. It would also be nice if the various
> file-based commands (like cat and cmp) also looked at the current
> working directory as well.
>
> lsdev (or lsdisk?) also makes a lot of sense to me.

Ok. Then, let's go to this direction. I think this function would be required:

- char *grub_file_get_absolute_path (const char *path)

If PATH is empty, return current working directory.
If PATH is a relative path, return a path based on current working directory.
If PATH is an absolute path, return a patch based on current working device.
If PATH contains a device name, return PATH.
The return value should be allocated on the heap.
This function also should resolve "." and "..".

Once this is implemented, the rest is trivial. So, who wants to work on 
this? ;)

Okuji

Re: partition layouts - "root"

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> Once this is implemented, the rest is trivial. So, who wants to work on 
> this? ;)

If the copyright problem is solved, I will.  If someone else wants to
do it now, please do!

--
Marco