Hello!
A happy new year to everyone!
Running a GNU/Hurd system on Xen is getting nearer. Very nice!
Tue, Jan 02, 2007 at 01:11:05AM +0000, Samuel Thibault wrote:
A crude first ugly patch.
I wondered how you got the thing to boot, wondered if you had also ported
GRUB to Xen along the way, but then I saw the patch for
`kern/bootstrap.c'. :-)
It at least boots my Hurd in read-only mode fine! And by faking write mode, I
could run make in /src/hurd/ :)
As expected, pure userland programs like for (i=0;i<1000000;) run as fast as
natively. the other hand, dd < /dev/zero /dev/null bs=1 runs 6 times
slower, but that's three times better than qemu with kqemu
As I also have an experimental Xen machine running here, I'll be sure to
give this a try as well.
Do you have your development tree publically available? If not, you
could also work on a tree in the Savannah GNU Mach repository, if you
want.
Remaining items (I'll work on them shortly)
- enable block write
- net device (should be easy now that rings work)
- asynchronous events support
- clock support
Very nice!
Regards,
Thomas
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org
PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)
8r7wFlQbZ2Mr/6gsTuNr85k=
=gzvh
PGP SIGNATURE

Thomas Schwinge, le Tue 02 Jan 2007 12:10:49 +0100, a :
Tue, Jan 02, 2007 at 01:11:05AM +0000, Samuel Thibault wrote:
A crude first ugly patch.

I wondered how you got the thing to boot, wondered if you had also ported
GRUB to Xen along the way, but then I saw the patch for
`kern/bootstrap.c'. :-)

;)

Yes, the problem is that Xen is a bit Linux-oriented, and as such the
parameter is called "ramdisk", can ship only one file, and doesn't have
a command line separate from the kernel's

Do you have your development tree publically available?

I only often update the patch at

http://dept-info.labri.fr/~thibault/tmp/patch-gnumach-xen

If not, you could also work on a tree in the Savannah GNU Mach
repository, if you want.

Well, why not, since it does work a bit now.

BTW, why is the CVS holding generated files like configure & co? Since
we all have variouns versios of autoconf/automake, the cvs diff output
is cluttered with useless hooks.

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Tue, Jan 02, 2007 at 10:21:14PM +0100, Samuel Thibault wrote:
BTW, why is the CVS holding generated files like configure & co? Since
we all have variouns versios of autoconf/automake, the cvs diff output
is cluttered with useless hooks.

Correct. I followed that practice of the previous committers to the
trees. It has both advantages and disadvantages. You listed a
disadvantage. An advantage is that we can easily tell people: ``Get the
`gnumach-1-branch' from cvs and compile that one.'' without having to
worry if they have suitable versions of the Auto* tools installed. I
don't know if that is really a strong argument, though.

I don't have a general objection against changing that practice.

What are others's opinions?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

Q3AdkKg0/R/YTi9vc2HN+qA=
=Ca7G
PGP SIGNATURE

[Cced to <grub-devel (AT) gnu (DOT) org>.]

Hello!

This is about porting GRUB to Xen to allow booting a GNU/Hurd system as a
Xen domU.

GNU/Hurd systems use GNU Mach as a microkernel and have a GRUB
configuration like the following one, which is currently not translatable
to a Xen configuration:

#v+
title Debian GNU/Hurd
kernel (hd0,5)/boot/gnumach.gz \
root=device:hd0s6
module (hd0,5)/hurd/ext2fs.static \
${kernel-command-line} \
${host-port} \
${device-port} \
${exec-task} \
-T typed ${root} $(task-create) $(task-resume)
module (hd0,5)/lib/ld.so.1 \
/hurd/exec \
$(exec-task=task-create)
#v-

Tue, Jan 02, 2007 at 10:21:14PM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Tue 02 Jan 2007 12:10:49 +0100, a ?crit :
Tue, Jan 02, 2007 at 01:11:05AM +0000, Samuel Thibault wrote:
A crude first ugly patch.

I wondered how you got the thing to boot, wondered if you had also ported
GRUB to Xen along the way, but then I saw the patch for
`kern/bootstrap.c'. :-)

[Samuel there hard-coded the above quoted ``module []'' lines.]

;)

Yes, the problem is that Xen is a bit Linux-oriented, and as such the
parameter is called "ramdisk", can ship only one file, and doesn't have
a command line separate from the kernel's

Is there a consensus that GRUB (or rather GRUB2) should be ported to
allow them to run in a Xen environment?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

a0T45M0trBD6uf0+loUGDNA=
=aA96
PGP SIGNATURE

Hello!

Tue, Jan 02, 2007 at 10:21:14PM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Tue 02 Jan 2007 12:10:49 +0100, a ?crit :
Do you have your development tree publically available?

I only often update the patch at

http://dept-info.labri.fr/~thibault/tmp/patch-gnumach-xen

If not, you could also work on a tree in the Savannah GNU Mach
repository, if you want.

Well, why not, since it does work a bit now.

So, feel free to create a branch, perhaps called
`gnumach-1-branch-Xen-branch' or similar. As the goal is to finally
merge that branch back into the `gnumach-1-branch', please try not to do
unrelated changes that would complicate that process.

How shall we keep it with the ChangeLog? Do you intend to write entries
for each patch you check in into the new branch?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

q9gDR3M0xaxk5euhVFYLidw=
=0Jkb
PGP SIGNATURE

Hi,

Wed, Jan 03, 2007 at 12:55:21PM +0100, Thomas Schwinge wrote:

Tue, Jan 02, 2007 at 10:21:14PM +0100, Samuel Thibault wrote:

BTW, why is the CVS holding generated files like configure & co?
Since we all have variouns versios of autoconf/automake, the cvs
diff output is cluttered with useless hooks.

Correct. I followed that practice of the previous committers to the
trees. It has both advantages and disadvantages. You listed a
disadvantage. An advantage is that we can easily tell people: ``Get
the `gnumach-1-branch' from cvs and compile that one.'' without having
to worry if they have suitable versions of the Auto* tools installed.
I don't know if that is really a strong argument, though.

Indeed, that's the only argument I know of in favor of generated files
in CVS: The proponents of this approach claim that it eases building
from CVS. But it's a very weak point IMH It's perfectly reasonable to
expect people building from CVS to have the proper build tools
available. In fact, my experience is that generated files in CVS rather
make it *harder* to build stuff, because of incompatibilities between
different versions of the build tools.

What are others's opinions?

I strongly dislike generated files in CVS.
-antrik-

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Mon, Jan 08, 2007 at 07:16:05PM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Wed 03 Jan 2007 13:18:18 +0100, a ?crit :
So, feel free to create a branch, perhaps called
`gnumach-1-branch-Xen-branch' or similar.

Before that, just a little check: Xen provides some public headers
for making easier to implement doms, the CPYING file is as follows:

XEN NTICE

This copyright applies to all files within this subdirectory.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SFTWARE IS PRVIDED "AS IS", WITHUT WARRANTY F ANY KIND, EXPRESS R
IMPLIED, INCLUDING BUT NT LIMITED T THE WARRANTIES F MERCHANTABILITY,
FITNESS FR A PARTICULAR PURPSE AND NNINFRINGEMENT. IN N EVENT SHALL THE
AUTHRS R CPYRIGHT HLDERS BE LIABLE FR ANY CLAIM, DAMAGES R THER
LIABILITY, WHETHER IN AN ACTIN F CNTRACT, TRT R THERWISE, ARISING
FRM, UT F R IN CNNECTIN WITH THE SFTWARE R THE USE R THER
DEALINGS IN THE SFTWARE.

Is this K to include in GNU Mach ?

This is called the ``X11 License'' (see
<#3>) and is compatible with
the GPL, see <#X11License>.
Someone may want to double-check, I only had a quick look.

How shall we keep it with the ChangeLog? Do you intend to write entries
for each patch you check in into the new branch?

I don't think I'll write ChangeLog entries for now, since a bunch of
changes will probably disappear (panic()s here and there, TD, ).
Then I'll probably only write one ChangeLog entry, so it will be easy to
merge it.

Is this okay with the other Hurd maintainers?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

CoVgYY1QFLiThmmXlwkavYw=
=o5CU
PGP SIGNATURE

Hello!

Wed, Jan 03, 2007 at 12:55:21PM +0100, I wrote:
Tue, Jan 02, 2007 at 10:21:14PM +0100, Samuel Thibault wrote:
BTW, why is the CVS holding generated files like configure & co? Since
we all have variouns versios of autoconf/automake, the cvs diff output
is cluttered with useless hooks.

Correct. I followed that practice of the previous committers to the
trees. It has both advantages and disadvantages. You listed a
disadvantage. An advantage is that we can easily tell people: ``Get the
`gnumach-1-branch' from cvs and compile that one.'' without having to
worry if they have suitable versions of the Auto* tools installed. I
don't know if that is really a strong argument, though.

(If this situation shour really occur somewhen, it'd also be enough to
run a ``make dist'' and provide the person with the resulting tarball.)

I don't have a general objection against changing that practice.

What are others's opinions?

's opinions were also to remove all (?) generated files from the
revision control system.

Are there any Hurd maintainers to disagree?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

YcJF3TvE+w0QLixNBoZcwa0=
=625k
PGP SIGNATURE

Hi,

Thomas Schwinge, le Tue 09 Jan 2007 00:21:07 +0100, a :
's opinions were also to remove all (?) generated files from the
revision control system.

Yes, doc/ too is a pain to clean before diffing.

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Roland McGrath, le Mon 08 Jan 2007 15:33:50 -0800, a :
That said, building them up as you write the code is by far the best
way to do them.
True. I'll try keeping them up to date then.
Samuel
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Tue, Jan 09, 2007 at 12:28:20AM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Tue 09 Jan 2007 00:21:07 +0100, a ?crit :
's opinions were also to remove all (?) generated files from the
revision control system.

Yes, doc/ too is a pain to clean before diffing.

I identified the following files for removal, as they are properly
restored after running ``autoreconf -i'' and ``make'' (for the `doc/'
files). Anything to add there?

#v+
CPYING
INSTALL
Makefile.in
aclocal.m4
config.h.in
build-aux/compile
build-aux/config.guess
build-aux/config.sub
build-aux/depcomp
build-aux/install-sh
build-aux/mdate-sh
build-aux/missing
build-aux/texinfo.tex
doc/mach.info
doc/mach.info-1
doc/mach.info-2
doc/stamp-vti
doc/version.texi
#v-

Also, I'll have to invent something new for my recently added ``Web pages
of the GNU Mach Reference Manual'' magic in `doc/Makefrag.am'. But
that's really no show stopper for removing the generated files. ;-)

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

kgRJ6gZuA9hPNlx4xITyTiI=
=wP6D
PGP SIGNATURE

Thomas Schwinge, le Thu 11 Jan 2007 00:54:55 +0100, a :
I identified the following files for removal, as they are properly
restored after running ``autoreconf -i'' and ``make'' (for the `doc/'
files). Anything to add there?

configure ?

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Thu, 11 Jan 2007 00:54:55 +0100
Thomas Schwinge <tschwinge (AT) gnu (DOT) orgwrote:

Hello!

Tue, Jan 09, 2007 at 12:28:20AM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Tue 09 Jan 2007 00:21:07 +0100, a ?crit :
's opinions were also to remove all (?) generated files from the
revision control system.

Yes, doc/ too is a pain to clean before diffing.

I identified the following files for removal, as they are properly
restored after running ``autoreconf -i'' and ``make'' (for the `doc/'
files). Anything to add there?

version.c.in

#v+
CPYING
INSTALL
Makefile.in
aclocal.m4
config.h.in
build-aux/compile
build-aux/config.guess
build-aux/config.sub
build-aux/depcomp
build-aux/install-sh
build-aux/mdate-sh
build-aux/missing
build-aux/texinfo.tex
doc/mach.info
doc/mach.info-1
doc/mach.info-2
doc/stamp-vti
doc/version.texi
#v-

Also, I'll have to invent something new for my recently added ``Web pages
of the GNU Mach Reference Manual'' magic in `doc/Makefrag.am'. But
that's really no show stopper for removing the generated files. ;-)

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org