(no subject)

[michael]

Title: New Page 1




ÀÎÅͳݿ¡¼­ÀÇ ¼º°øÀÇ °ü°ÇÀº  È«º¸ 
ÀÔ´Ï´Ù!

¡¡
¾Æ¹«¸® ÁÁÀº ȨÆäÀÌÁö¶óµµ ¹æ¹®ÀÚ°¡ ¾ø´Ù¸é ¾Æ¹«¼Ò¿ëÀÌ ¾ø´Ù´Â°ÍÀ» À߾ƽÃÁÒ?
°Ë»ö¿£Áø¿¡ µî·ÏÇÏ·Á¸é ÃÖ¼Ò 10¸¸¿øÀº Áà¾ß ÇÕ´Ï´Ù.
ºñ¿ëÀ» Àý¾àÇϸ鼭 È¿°ú¸¦ ±Ø´ëÈ­ÇÒ ¼ö ÀÖ´Â Àß ºÐ·ùµÈ ¸ÞÀϵ¥ÀÌÅÍ°¡ ¿©±â ÀÖ½À´Ï´Ù.

¡¡

>>Á¦°ø ÀÚ·á<<

1. ºÐ·ùµ¥ÀÌÅÍ(150Mb, 2600¸¸°³, Áߺ¹¾øÀ½)
   

¾÷Á¾º°
¿¬·Éº°
Áö¿ªº°
ISPº°
ÇѸÞÀÏÁ¦°Å




2. Á¤¸®µ¥ÀÌÅÍ(395Mb, 4300¸¸°³, Áߺ¹¾øÀ½)   
¡¡µµ¸ÞÀκ°
¾ËÆĺªº°




3. ÇÁ·Î±×·¥(44Mb)
    

¸ÞÀϹ߼ÛÇÁ·Î±×·¥ 2Á¾
°Ô½ÃÆǵî·ÏÇÁ·Î±×·¥ 3Á¾(°Ô½ÃÆÇ µ¥ÀÌÅÍ(3¸¸) Æ÷ÇÔ)


°¡°ÝÀº 3¸¸¿øÀÔ´Ï´Ù.
¿¬¶ôó : 0505-258-8855, 
[EMAIL PROTECTED]
¿¬¶ôÁÖ½Ã¸é µ¥ÀÌÅ͸¦ ¹Ù·Î ´Ù¿î ¹ÞÀ¸½Ç ¼ö ÀÖ½À´Ï´Ù. (Åùè·Î CD¹ß¼Û°¡´É:¹è¼Û·á¹«·á)

º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.


¼ö½Å°ÅºÎ ¹öÆ°À»
Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù.


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd

(no subject)

[michael]

Title: New Page 1




ÀÎÅͳݿ¡¼­ÀÇ ¼º°øÀÇ °ü°ÇÀº  È«º¸ 
ÀÔ´Ï´Ù!

¡¡
¾Æ¹«¸® ÁÁÀº ȨÆäÀÌÁö¶óµµ ¹æ¹®ÀÚ°¡ ¾ø´Ù¸é ¾Æ¹«¼Ò¿ëÀÌ ¾ø´Ù´Â°ÍÀ» À߾ƽÃÁÒ?
°Ë»ö¿£Áø¿¡ µî·ÏÇÏ·Á¸é ÃÖ¼Ò 10¸¸¿øÀº Áà¾ß ÇÕ´Ï´Ù.
ºñ¿ëÀ» Àý¾àÇϸ鼭 È¿°ú¸¦ ±Ø´ëÈ­ÇÒ ¼ö ÀÖ´Â Àß ºÐ·ùµÈ ¸ÞÀϵ¥ÀÌÅÍ°¡ ¿©±â ÀÖ½À´Ï´Ù.

¡¡

>>Á¦°ø ÀÚ·á<<

1. ºÐ·ùµ¥ÀÌÅÍ(150Mb, 2600¸¸°³, Áߺ¹¾øÀ½)
   

¾÷Á¾º°
¿¬·Éº°
Áö¿ªº°
ISPº°
ÇѸÞÀÏÁ¦°Å




2. Á¤¸®µ¥ÀÌÅÍ(395Mb, 4300¸¸°³, Áߺ¹¾øÀ½)   
¡¡µµ¸ÞÀκ°
¾ËÆĺªº°




3. ÇÁ·Î±×·¥(44Mb)
    

¸ÞÀϹ߼ÛÇÁ·Î±×·¥ 2Á¾
°Ô½ÃÆǵî·ÏÇÁ·Î±×·¥ 3Á¾(°Ô½ÃÆÇ µ¥ÀÌÅÍ(3¸¸) Æ÷ÇÔ)


°¡°ÝÀº 3¸¸¿øÀÔ´Ï´Ù.
¿¬¶ôó : 0505-258-8855, 
[EMAIL PROTECTED]
¿¬¶ôÁÖ½Ã¸é µ¥ÀÌÅ͸¦ ¹Ù·Î ´Ù¿î ¹ÞÀ¸½Ç ¼ö ÀÖ½À´Ï´Ù. (Åùè·Î CD¹ß¼Û°¡´É:¹è¼Û·á¹«·á)

º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.


¼ö½Å°ÅºÎ ¹öÆ°À»
Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù.


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Thu, Aug 12, 2021 at 12:18:20PM +1000, Damien Zammit wrote:
> On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> > It would be interesting to consider dropping the copyright assignment
> > requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> > project, this looks to me like a hindrance more than anything else.
> 
> I imagine it is slightly inconvenient for new contributors, but not a
> hindrance in my opinion.

The fact that this process potentially or apparently took (or rather,
has been taking) months for Sergey (I don't know when it was initiated),
is a pretty good indicator that it is more than a nuisance.

> It ensures that FSF has complete control of the licensing.

I don't mind that, but I also think the Hurd is not a tactical FSF asset
anymore that needs to be kept under tight control. The FSF has enough
copyright in the Hurd that it can enforce it whenever it likes, even if
other people's copyrighted code (as is already the case with the pfinet
stack) is added. Finally, the GPLv2+ code can always be licensed to
GPLv3+ once all the GPLv2only code has been removed, no copyright
assignments are required there, either.

So if the Hurd maintainers would like to drop the requirement (as has
been done with GCC and glibc in recent months), I would support that.


Michael

Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote:
> Michael Banck  writes:
> 
> > I don't mind that, but I also think the Hurd is not a tactical FSF asset
> > anymore that needs to be kept under tight control. The FSF has enough
> > copyright in the Hurd that it can enforce it whenever it likes, even if
> > other people's copyrighted code (as is already the case with the pfinet
> 
> I wouldn’t be so sure about that.
> 
> 1. Without copyright assignment of all code involved, enforcement
>becomes much harder.

I don't think "much harder" can be quantified in a meaningful way,
seeing how parts of the Hurd aren't under the FSF copyright at this
point, anyway.

> 2. The Hurt still provides capabilities other OS’es don’t — while
>maintaining POSIX compatibility. We’ve seen audacity basically
>being taken over by a company in the past months, so the danger of
>losing Hurd to proprietarization rather got bigger than smaller.

Nobody proposes that the FSF relicenses the Hurd to a non-copyleft
license before relinquishing the copyright assignment mandate, so I
don't see how the Hurd continueing to be under a GPLv2+ license will
ever be able to be taken proprietary.

I'm not going to respond further on this thread, this is starting to get
off-topic really quick and if there are further things to be discussed,
gnu-system-discuss or whatever other mailing list is likely the better
place.


Michael

Re: It runs!

[Michael Banck]

On Fri, May 12, 2023 at 09:30:34PM +0300, Sergey Bugaev wrote:
> Hello everyone, I've got some exciting news :)
> 
> /bin/sh runs!!!
> 
> Things start up all the way -- exec, proc, auth, all that. Then
> /hurd/startup exec's /libexec/console-run; I placed a little shell
> script there. The shell (dash) starts up, loads the script, and starts
> executing it! And (this required another tweak to TLS) it manages to
> fork and exec a command!
> 
> The command being "settrans -ac /dev/mach-console /hurd/streamio
> console" -- and that seems to (mostly?) succeed too, streamio starts
> up and settrans does call file-set-trans on the ext2fs. But I haven't
> yet been able to receive any actual output from the shell or
> subsequent commands on the console.
> 
> But -- we now have enough of Unix working to fork and to run /bin/sh!
> How cool is that?!

Woot!


Michael

Re: kvm with hurd-k16.img

[Michael Banck]

On Mon, Nov 03, 2008 at 09:42:01AM +0530, Vikram Vincent wrote:
> 2008/11/2 Shakthi Kannan <[EMAIL PROTECTED]>
> 
> > Hi,
> >
> > --- On Sun, Nov 2, 2008 at 7:37 PM, Shakthi Kannan <[EMAIL PROTECTED]>
> > wrote:
> > |  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512
> > \--
> >
> > It was reported here:
> > http://paste.lisp.org/display/67296
> >
> > Had to use it with -no-kvm-irqchip or -no-kvm-pit.
> >
> > For setting up kvm on debian, this documentation is useful:
> > http://kvm.qumranet.com/kvmwiki/Debian
> >
> >
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498940

Is it trivial to apply the fix which went into 2.6.27 to 2.6.26?  If
that's the case, maybe a bug against linux-2.6 should be reported,
requesting it be fixed for the 2.6.26 lenny kernel.


Michael

Re: kvm with hurd-k16.img

[Michael Banck]

reassign 498940 linux-2.6
retitle 498940 [patch] linux-2.6.26 KVM fails to boot Mach
severity 498940 important
tags 498940 +patch
tags 498940 +fixed-upstream
thanks

On Mon, Nov 03, 2008 at 11:28:53AM +0100, Samuel Thibault wrote:
> Michael Banck, le Mon 03 Nov 2008 11:09:08 +0100, a écrit :
> > Is it trivial to apply the fix which went into 2.6.27 to 2.6.26?
> 
> Yes:
> 
> commit f697554515b06e8d7264f316b25e6da943407142
> Author: Aurelien Jarno <[EMAIL PROTECTED]>
> Date:   Fri May 2 17:02:23 2008 +0200
> 
> KVM: PIT: support mode 3
> 
> The in-kernel PIT emulation ignores pending timers if operating
> under mode 3, which for example Hurd uses.
> 
> This mode should output a square wave, high for (N+1)/2 counts and low
> for (N-1)/2 counts. As we only care about the resulting interrupts, the
> period is N, and mode 3 is the same as mode 2 with regard to
> interrupts.
> 
> Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> 
> diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
> index 735ec9a..60074dc 100644
> --- a/arch/x86/kvm/i8254.c
> +++ b/arch/x86/kvm/i8254.c
> @@ -308,6 +308,7 @@ static void pit_load_count(struct kvm *kvm, int channel, 
> u32
> create_pit_timer(&ps->pit_timer, val, 0);
> break;
> case 2:
> +   case 3:
> create_pit_timer(&ps->pit_timer, val, 1);
> break;
> default:
> 

OK, so reassigning to linux-2.6.  Linux kernel maintainers, please apply
this patch for lenny if another upload is done.


thanks,

Michael

Re: Hurd does not want to build

[Michael Banck]

On Wed, Nov 05, 2008 at 10:33:30PM +0200, Sergiu Ivanov wrote:
>   cd hurd/; make
> 
> which dies with the following error message:
> 
>   ar: creating libshouldbeinlibc.a
>   libshouldbeinlibc.a
>   make[1]: libshouldbeinlibc.a: Command not found
>   make[1]: *** [libshouldbeinlibc.a] Error 127
>   make[1]: Leaving directory `/tmp/hurd/libshouldbeinlibc'
>   make: *** [libshouldbeinlibc] Error 2

Sounds like the ranlib executable is missing, do you have binutils
installed?

"grep RANLIB config.make" probably returns an empty "RANLIB="?


Michael

Re: Fwd: Gentoo GNU/Hurd thread in Gentoo Forums

[Michael Banck]

On Sat, Nov 08, 2008 at 08:23:41AM +0200, Sergiu Ivanov wrote:
> I see... Well, I hope I'll have some time to port emacs to Hurd,
> because, frankly speaking, it's uncomfortable for me to realize that
> *GNU* Emacs does not run on *GNU* Hurd...

Maybe you're doing something wrong then, because GNU Emacs has been
running on GNU Hurd ever since I can remember.

Of course, oweing to the nature of Debian unstable, the emacs22 Debian
package might be uninstallable at times due to missing or outdated
dependencies.  Right now, it seems to be installable without problems,
though.


Michael

Re: Fwd: Gentoo GNU/Hurd thread in Gentoo Forums

[Michael Banck]

On Sun, Nov 09, 2008 at 07:08:30AM +0200, Sergiu Ivanov wrote:
> However, do you mean that I can download the sources of emacs22 and
> they will build successfully on Hurd?

Two weeks ago, that was the case:
http://buildd.debian-ports.org/fetch.php?&pkg=emacs22&ver=22.2%2B2-4&arch=hurd-i386&stamp=1224933865&file=log&as=raw


Michael

Re: status

[Michael Banck]

Arne,

On Sun, Nov 09, 2008 at 11:26:24AM +0100, Arne Babenhauserheide wrote:
> If Viengoos fullfills the hopes I have in it since I read the paper from 
> Neal, 
> then it's likely that the GNU/Hurd will be ported to it. 

You can have your hopes however you want, but it is not very productive
to hype up Viengoos as the next microkernel at this point.  Neal has
made it clear that he considers it a research project and currently not
suitable for the Hurd to use, nor does he currently have the intention
to do the porting and/or necessary work to have Viengoos suitable for a
mainstream operating system.

The Hurd project said it would move to L4, this project has failed and
people are still confused about this several years later.  We should
learn from this and not make any announcements or predictions on how or
when the Hurd will move to a new microkernel until such a project is a
reality.  


Michael

Re: Niche for Hurd - discussion - the power of translators

[Michael Banck]

On Tue, Nov 11, 2008 at 03:58:39AM +0100, [EMAIL PROTECTED] wrote:
> I wonder what it would take to get this into Debian as default...

Uhm, how about starting with a whishlist bug first?


Michael

Re: Niche for the Hurd - summary 2 - niches sorted according to necessary work

[Michael Banck]

On Thu, Nov 13, 2008 at 05:42:49PM +0100, Arne Babenhauserheide wrote:
> I think to make it *the* GNU system we'd need it in a state where I can just 
> start any desktop on it and work with it just like in a GNU/Linux, because 
> else people would just shrug and say "This is GNU then, I think I'll stick 
> with GNU/Linux". 

That's not the definition of *the* GNU system.  *The* GNU system is the
system made/distributed by the GNU project.


Michael

Re: Report in Swedish, English or both?

[Michael Banck]

Hi,

On Wed, Jan 07, 2009 at 10:38:48PM +0100, Carl Fredrik Hammar wrote:
> I'm slightly torn however, partly because I'm more proficient in Swedish.
> And partly because Swedish is in such a poor state when it comes to
> computer science.  Often terminology is borrowed form English even though
> there is viable Swedish words that could replace them.  It would be nice
> to make a contribution in this area.

I think it has to be accepted that while it is possible to write in and
improve your own language, the only viable way when it comes to
contributing to the scientific community is in english.  This may be
less important for this work (but much more so in terms of practical
usefulness to the technical Hurd community, as Olaf pointed out), but
the more you write, the more important it will be that it can be peer
reviewed by non-swedish readers as well.

Thus, I would advise you to write this in english even if your english
is not perfect and it will take longer; it will certainly be fruitful
for the inevitable further publications from you in english, and the
sooner you become familiar with writing scientific publications in
english, the better for your scientific output, I think.


regards,

Michael

Re: Does the cross toolchain really work?

[Michael Banck]

On Thu, Jan 22, 2009 at 10:58:56AM +0800, newper wrote:
> But when I restart the computer it still hang at Hurd sever
> bhootstrap: ext2fs.static[device:hd0s2]exec
> You tell me to enable-kdb when compiling gnumach,but I don't know how
> to use it.

When you --enable-kdb, Mach will drop you into the kernel debugger
instead of rebooting.  However, as you're now having a Hurd issue (exec
hanging) that won't help you here. 


Michael

Re: A GNU/Hurd Roadmap dream

[Michael Banck]

On Tue, Jun 02, 2009 at 10:22:45PM +0200, Arne Babenhauserheide wrote:
> This is the Roadmap I dreamt of: 

Sorry, but this is a wishlist, not a roadmap.


Michael

Re: Hurd build fails on my box

[Michael Banck]

On Sat, Jun 13, 2009 at 09:32:25PM +0300, Sergiu Ivanov wrote:
> I'd like to remark, though, that (on my box) the set of patches I get
> from apt-get and from svn is different... More exactly, the apt-get
> version misses (at least) the ``series'' file and a number of patches
> (like the in6_addr.patch you mentioned). Is this okay or am I doing
> something wrong again?

It's the difference between the last upload of the package, and the
current svn-state of the packaging.

In other words: We should upload the package again some day...


Michael

Re: News 2009-10-31

[Michael Banck]

On Mon, Nov 02, 2009 at 03:58:57PM +0100, Arne Babenhauserheide wrote:
> Am Montag, 2. November 2009 15:29:47 schrieb Thomas Schwinge:
> > > -> http://www.bddebian.com/~hurd-web/news/2009-10-31/

A lot of people will just ignore this monster thread; so if you plan to
actually have people read those, wouldn't it be better to make up a new
thread?  Or move it to another list?


Michael

PS: Is there an RSS feed of the news?

Re: blubber and grubber down

[Michael Banck]

On Tue, Nov 10, 2009 at 05:47:24PM +0100, Thomas Schwinge wrote:
> Hello!
> 
> On Sun, Nov 08, 2009 at 11:45:39AM +0100, I wrote:
> > I think I'll reinstall them later today (preserving /home/, of course).
> 
> Sergiu rightfully so reminded me that I had forgotten to do that.
> blubber is again up running, and grubber will be in some days --
> realistically.  ;-) (I did some changes to my install scripts, and want
> to test and use these improvements for re-installing grubber.)
> <http://www.bddebian.com:/~hurd-web/public_hurd_boxen/zenhost/> now
> documents the installation process, so that someday another person can do
> this, too.
> 
> 
> > Should be pretty easy now that crosshurd is functional again.
> 
> Michael, FYI: This indeed the case.  The only strange thing I noticed is
> this:
> 
> I: Extracting /var/cache/apt/archives/coreutils_7.5-6_hurd-i386.deb...
> I: Extracting /var/cache/apt/archives/dash_0.5.5.1-3_hurd-i386.deb...
> tar: ./bin/sh: Cannot create symlink to `dash': File exists
> tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to `dash.1.gz': 
> File exists
> tar: Exiting with failure status due to previous errors
> I: Extracting /var/cache/apt/archives/debianutils_3.2.1_hurd-i386.deb...
> I: Extracting 
> /var/cache/apt/archives/diffutils_1%3a2.8.1-18_hurd-i386.deb...
> 
> But this didn't have any negative effects (dash finally is running as
> /bin/sh), so I ignored it.

Yeah, it's because both the bash and dash .debs ship the /bin/sh symlink
now; not much we can do about it right now, as both packages are
uptodate with respect to unstable.


Michael

Re: Mercurial vs. git

[Michael Banck]

Hi,

On Wed, Nov 11, 2009 at 03:38:57PM +0100, Arne Babenhauserheide wrote:
> Well, there's Photoshop - and it doesn't yet have a real competitor in free 
> software. Though Gimp is almost as powerful, it is much harder to use for 
> newcomers. Give Photoshop to a newbie, and you'll see him/her working at 
> once. 
> Try that with Gimp, and after a few minutes you'll have a confused user. 

I am getting increasingly annoyed by this - can you explain how this
relates to Hurd development?


Michael

Re: GNU/Hurd in german news

[Michael Banck]

On Thu, Nov 12, 2009 at 12:57:22PM +0100, Arne Babenhauserheide wrote:
> @Samuel: Do you have contact with the fvwm people? If yes: Could you send 
> them 
> a link with the status page? 

I don't think fvwm working is news.


Michael

Re: GNU/Hurd in german news

[Michael Banck]

On Thu, Nov 12, 2009 at 01:20:37PM +0100, Arne Babenhauserheide wrote:
> Am Donnerstag, 12. November 2009 13:02:39 schrieb Michael Banck:
> > On Thu, Nov 12, 2009 at 12:57:22PM +0100, Arne Babenhauserheide wrote:
> > > @Samuel: Do you have contact with the fvwm people? If yes: Could you send
> > > them a link with the status page?
> > 
> > I don't think fvwm working is news.
> 
> Nor interesting to the fvwm people that it runs on GNU/Hurd? 

Why would it be?  AFAIK fvwm has no platform-specific code, so there is
no reason why it should not work.

If it had to be ported, it got ported 10 years ago, so notifying them
now looks totally pointless to me.


Michael

Re: learning curve

[Michael Banck]

This is ridiculous. I am going to unsubscribe from bug-hurd the next
time I see such an off-topic thread again.


Michael

On Thu, Nov 19, 2009 at 08:24:21AM +0100, Arne Babenhauserheide wrote:
> Am Dienstag, 17. November 2009 22:38:39 schrieb olafbuddenha...@gmx.net:
> > The problem with learning bit by bit is that you only look up things if
> > you want to do something new. You never get a complete picture; you
> > never learn how you could do things more efficiently, and/or with better
> > result; and you often pick up really bad practices.
> 
> I tend to disagree here, too. 
> 
> You do pick up back practise if you only check what is absolutely necessary 
> to 
> get the task at hand done (as I often do for shell scripting). 
> 
> If you check deeper issues when you need them, you understand something new 
> and you learn to work more efficiently. 
> 
> Look for example at the Mercurial guide I wrote. At first you only learn to 
> commit and read your log. At that point you already understand that Mercurial 
> tracks your changes - and after using it a bit, you also get a feeling for 
> what commit does. 
> 
> Then you learn how to do nonlinear development, branching and merging at 
> will. 
> Committing is already natural at that point, so you only enhance what you 
> already know by heart. 
> 
> And after that you learn that working together with others is simply 
> nonlinear 
> development by exchanging "commits" between repositories. 
> 
> 
> In really complex areas that becomes even more evident. 
> 
> One example: I'm studying physics, and I learned this summer with the Feynman 
> lectures, which hammer home the point that statistics tell us that the 
> distribution of particles with certain energies is exp(-E/kT) - that's "e" to 
> the potential of minus the energy divided by the temperature (and the 
> Boltzmann constant). He explains that for gases at first (energy distribution 
> in different heights - only from gravity and random movement energy). The 
> distribution says "this many particles with Energy E are there". 
> 
> At that point he never talks about the difference between bose particles and 
> fermi particles. He also doesn't try to give the whole mechanism, but rather 
> gives a central part of the whole picture. 
> 
> Now when I got to learning suprafluids and stuff, it was quite easy to 
> understand what their slightly different distribution does: 
> 
> 1 / (exp(E/kT) - 1)
> 
> That's almost exp( - E/kT), but for low energies it goes to infinity - 
> because 
> the lowest state of a suprafluid can be shared by an arbitrary high number of 
> particles - if you only manage to take away enough energy from them. That's 
> why it can crawl over walls, ignores rotations of the container and such. 
> 
> To really see the implications of that, you already need to know about , 
> Heisenbergs uncertainty relation for the gaussian distribution of energies, 
> quantum mechanics, energy barriers and stuff. But you don't need to 
> understand 
> that to grasp the basic law exp(-E/kt). 
> 
> And really understanding the basic law makes it much easier to understand 
> more 
> complex stuff later on - understanding everything at once is just not 
> feasible 
> for the vast majority of physics students. 
> When you already know exp(-E/kT), many later things are "wow, it's really 
> easy 
> to see how that works - just a small alteration to the basic distribution". 
> 
> (there are more basic principles in physics than this, but that's one which 
> currently fascinates me; it is so easy - once you udnerstand it :) 
> And Feynman really manages to make physics sound as fascinating as it is, 
> while keeping it easy to understand). 
> 
> To organize learning that way makes for a very efficient learning curve. 
> 
> (actually he starts with "all matter is made of atoms (as long as we don't 
> look to deep)" and "we begin with small lies which make it easier to 
> understand the basics - but we tell you which laws are final (to our current 
> knowledge) and which are simplifications we'll have to revise" and goes 
> onward 
> from that). 
> 
> > In either case, you can't seriously argue that it's demanding too much,
> > that everyone learning how to set the text color, should also learn how
> > to set the background color at the same time, and vice versa...
> 
> And the button color, and the text field color (almost no site changes that), 
> ... 
> 
> What's missing there is a way to adapt to user settings. What you describe is 
> binary again: Either set all or nothing. But that means that it doesn't 
> integrate at all or integrates completely - without middle ground. 
> 
> But we already had that part of the discussion... 
> 
> Best wishes, 
> Arne
> 
> PS: I think that this can be relevant to the Hurd, because the learning curve 
> is something which also affects every program, translator usage, etc. - and 
> so 
> it affects how easy it is for people to switch to the Hurd. 

Re: learning curve

[Michael Banck]

On Thu, Nov 19, 2009 at 06:16:07PM +0100, Arne Babenhauserheide wrote:
> I spent some time thinking whether to send this reply to the list or only to 
> Olaf, but I decided to send it to the list, because the learning curve also 
> applies to documentation of the Hurd - the Hurd also offers concepts which 
> are 
> new to many people. 

I said it before, and I'll say it again now: the Hurd does not need
more users, it does not even need a lot more developers, it just need a
few *really smart* developers.

You don't get really smart developers by trashing up your development
list with 200-mail threads about mercurial vs. git vs. cvs or the merits
of light or dark backgrounds in CSS.


I rest my case now.

Michael

Re: Months of the Hurd 2009-12

[Michael Banck]

On Mon, Dec 28, 2009 at 10:25:44AM +0100, Arne Babenhauserheide wrote:
> I prepared the news about this months. If something is missing (or wrong), 
> please tell me! 

There was lots of porting activity as well, mostly by Pino Toscano and
Emilio Pozuelo Monfort.  Maybe asking them for some highlights of newly
fixed or ported packages would be worthwhile.


Michael

Re: cannot boot subhurd

[Michael Banck]

On Sat, Jan 02, 2010 at 10:46:20PM +0800, Da Zheng wrote:
> I tried crosshurd. It doesn't work. Anyone maintains crosshurd?

Yes.

Michael

Re: FOSDEM 2010

[Michael Banck]

On Thu, Dec 31, 2009 at 04:37:12AM +0100, olafbuddenha...@gmx.net wrote:
> Hi,
> 
> On Tue, Dec 22, 2009 at 10:01:41AM +0100, Thomas Schwinge wrote:
> 
> > FOSDEM 2010 is slowly approaching.
> > 
> > A few Hurd types have shown interest in meeting there, so I created
> > <http://www.thomas.schwinge.homeip.net/hurd-web/community/meetings/fosdem_2010.html>
> > for coordination.  Beware that web-editing (and the whole of bddebian
> > HTTP) is still down due to this Perl crash I (or someone else, of
> > course) needs to have a look at.  But you can either use the Git
> > interface, cf.
> > <http://www.gnu.org/software/hurd/contributing/web_pages.html>, for
> > doing any changes, or tell me by email or on IRC (tschwinge on
> > freenode.net).
> 
> As the wiki is kinda-working again now, I think it's right to use
> http://www.bddebian.com/~hurd-web/community/meetings/fosdem_2010/ ?
> 
> Also, I think it would be good to mention that there will be an alt-os
> devroom, where we will surely hang out -- and hopefully could give a
> talk or two as well...

The submission deadline for the alt-os devroom has been extended till
the end of January 4th:

http://groups.google.com/group/rosetta-os/browse_thread/thread/16964e21bef27116

Francois Revol (the chairmain of the devroom) turned up in #hurd today
and requested submissions:

 I'd really like to see a Hurd demo :)

His email address is re...@free.fr.


Michael

Re: Generalizing mobility for the Hurd

[Michael Banck]

On Fri, Jan 29, 2010 at 02:53:04PM +0100, Carl Fredrik Hammar wrote:
> For now it is available from my personal web page provided by my uni:
>   <http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf>
> but I don't know how long that will last since I'm no longer enrolled.
> I guess I'll have to get a web page of my own eventually.

That file is not very big, I think it could be mirrord (at least) at
hurd.gnu.org as well, under the software/hurd/hurd/documentation
section.


Michael

PS: btw, software/hurd/documentation does not look very welcoming, and
it is a 1st class link from the homepage.

Re: news 2010-03: *bug squashing* and *Hurd in GSoC 2010 with GNU*

[Michael Banck]

On Sat, Mar 27, 2010 at 04:16:11PM +0100, Arne Babenhauserheide wrote:
> Am Samstag, 27. März 2010 16:00:37 schrieb olafbuddenha...@gmx.net:
> > Hi,
> > 
> > On Sat, Mar 27, 2010 at 03:03:36PM +0100, Arne Babenhauserheide wrote:
> > > > This month saw bugs dieing as they met hackers like
> > > > [Jérémie, Antrik, Samuel](http://lists.gnu.org/archive/html/bug-
> 
> > I don't take any credit for that...
> > 
> > Also, I never capitalize my nick :-)
> 
> OK, cleaned up - your nick in the second paragraph. Thanks! 

Maybe I mentioned this before (and I won't mention it again), but if the
news are directed to people not already in the community (which I
assume, otherwise people should know about most of it anyway), then I
would suggest not using first names only or nicknames, but spelling out
full names.


Michael

Re: Article - GNU HURD: Altered visions and lost promise

[Michael Banck]

Hi,

On Wed, Jun 30, 2010 at 05:44:37PM +0200, Jure Repinc wrote:
> I've just seen a new article about GNU Hurd:
> http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-
> promise-1030942.html

http://news.ycombinator.com/item?id=1474941 is an interesting (from a
historical/FSF POV) comment on that article.


Michael

Re: Debian GNU/Hurd installation wizard and live cd

[Michael Banck]

Hi,

On Thu, Jul 22, 2010 at 08:43:13AM +0200, Arne Babenhauserheide wrote:
> Hi Justus, 
> 
> On Monday 12 July 2010 15:40:07 Arne Babenhauserheide wrote:
> > Do you have an idea why it breaks here?
> 
> Are you still there? 

Maybe try assigning more RAM to KVM if you assigned much less than
512MB.  Just a wild guess.


Michael

Re: [PATCH 0/8] Bring console-driver-xkb up to date

[Michael Banck]

On Wed, Aug 18, 2010 at 03:03:19AM +0200, Samuel Thibault wrote:
> Hello,
> 
> Diego Nieto Cid, le Wed 04 Aug 2010 04:19:58 -0300, a écrit :
> >The past couple of weeks I've been packaging Marco's input driver
> > for Arch Hurd and I've found that some changes were necesary to make
> > it work again.
> 
> Does anybody know whether / where we have an upstream repository where
> to commit such patches?

They should go into the Hurd codebase, methinks.

The original xkb driver was just a tared up dump of Marco's code tree on
his homepage I believe, so there is no real upstream location AFAIK.


Michael

Re: [tschwinge+n...@gnu.org: Duke Nukem Forever Returns, Will Really Be Released in 2011]

[Michael Banck]

Hi,

On Sat, Sep 04, 2010 at 04:33:22PM +0200, Thomas Schwinge wrote:
> So, there's no escape anymore: we'll have to release next year, 2011.
> Finally.  As far as I know, *everyone* is expecting Duke Nukem Forever
> and the GNU Hurd to appear at the same time, yet to be bundeled (see
> <http://twitter.com/migueldeicaza/status/16015861821>).

Let's contact them for a coordinated release on 4/1/11.


Michael

Re: ED error code

[Michael Banck]

On Tue, Nov 02, 2010 at 11:30:28AM +0100, Manuel Menal wrote:
> On 02/11/2010 11:29, Samuel Thibault wrote:
> > Manuel Menal, le Tue 02 Nov 2010 11:20:27 +0100, a écrit :
> >>> “Macros that begin with E and a digit or E and an uppercase letter may
> >>> be added to the declarations in the  header.”
> 
> >> I'm not a native speaker, but I don't think that means E[A-Z0-9]+ are
> >> reserved for error code macros. Only that error code macros should match
> >> E[A-A0-9]+.
> 
> > I should have quoted the start of the 7.26§ itself:
> 
> > “7.26 Future library directions
> > The following names are grouped under individual headers for
> > convenience. All external names described below are reserved no matter
> > what headers are included by the program.”
> 
> OK, I had missed that part. I'll report bugs against those packages, then.

I think it still makes sense to remove that ED macro if it serves no
purpose


Michael

Re: live cd

[Michael Walker]

Oops, didn't send this to the ML...

On 25 February 2011 21:44, Oz  wrote:
> Debian Gnu/Hurd seems to be complicated to install from what i
> understand because 1 its not a live cd or install cd.  2-you need qemu
> virtulization.  I want to run it natevly as the sole operating system
> on one netbook i have.  i dont know or understand much i am a ubuntu
> gnu/linux user and have been using gnu/linux for a couple of years and
> am truly a noob compared to you guys but want to use a fully free
> system and support the gnu project.  but i need the easiesest route
> possible :)  thats why i was think about the arch hurd live cd.
>

If you're going to use the graphical one, be warned that that's pretty
much just a proof-of-concept. It's a pet project one of the devs is
working on and is pretty slow/unstable. Also, the official
installation CD is pretty unstable, too.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: YotH 2010 -- a Year of the Hurd 2010

[Michael Dorrington]

Thomas Schwinge wrote:
> Hallo!
> 
> Prompted by Karl Berry who is currently preparing a general GNU status
> report, I just contributed the following text -- a Year of the Hurd 2010!
> 
> If you'd like something changed / added / removed, please tell so
> quickly.
> 
> 
> GNU Hurd ()
> 
> Yeah, that's right!  The GNU Hurd, the GNU project's replacement for the
> UNIX kernel, implemented as a collection of servers that run on the Mach
> microkernel.  Contrary to popular belief, this project is not yet dead.
> Of course, it's not the world's most active project either, but a small
> group of volunteers (a handful, mostly) are still plowing their way
> through the terrain of a steadily changing (and improving) Free Software
> world, striving to keep this advanced research prototype system going.
> They are accompanied by another handful of Debian GNU/Hurd, and (new:)
> Arch Hurd packagers.  So, what happened in the last year?

Also the Debian GNU/kFreeBSD port has done a lot to pave the way for
GNU/Hurd. Both by de-Linux-ifying userland and getting an easy to use
and modern installer, the debian-installer, for a non-Linux GNU system
(not to detract from the excellent work of Philip Charles). This
combined with the current high level of usability of GNU/kFreeBSD and
release schedule of Debian Squeeze encouraged participation on work that
directly benefits a GNU/Hurd system.

Debian GNU/kFreeBSD still needs work but by the next release of Debian I
expect that the rough edges will be smoothed and it will move from a
"technology preview" to be as equally finished as Debian GNU/Linux. I
also hope that Debian GNU/Hurd could be released as a "technology
preview" at that time, this would be a huge milestone in GNU/Hurd.

> Grüße,
>  Thomas

Tschüss,
Mike.

Re: XKB's keymaps for the Hurd console

[Michael Banck]

On Tue, Mar 22, 2011 at 05:06:40PM -0500, Oz wrote:
> awsome sounds like i'll be playing some quake 3 mods in the near
> future on the hurd.

I suggest you wait for Duke Nukem Forever.


Michael

XMLFS for GSoC

[Michael Walker]

Hi,

I'd like to apply to work on xmlfs for GSoC this summer. I've been
going through the code over the past few days and working on it a bit,
and have come up with a list of things to implement:

 * Fix all gcc warnings [done]
This was really just so I'd be able to see which functions were
where, this was all very trivial.
 * Support for changes to the backing store [begun]
Not so trivial, as I haven't really done anything with ports
before, which I'm using to monitor changes to the backing store.
However, I'm making good progress with this and I think I'll be done
within the next day or two.
  * Support for editing nodes
  * Support for adding and deleting nodes
  * Support for XSLT transformations
  * Document all functions thoroughly (their purpose, parameters,
return values, and any changes to globals)

As this is my first experience of translator programming, I haven't
decided to attempt the complementary translator, as I don't think I
would be able to do that in the time available. My goal for xmlfs is a
translator that can be used to easily parse and modify XML files via a
shell script, which is document thoroughly enough so that someone with
little or no translator programming experience can understand and use
it as a reference and help for their own work. The only thing I
anticipate any particular difficulty with is the adding/deleting nodes
and XSLT transformations, as I haven't worked with libxml2 before and
so would need to read up on that.

I'm a first year computer science student, and have been using C for a
few years now. I'm pretty familiar with using the Hurd (due to Arch
Hurd), but not so much the programming side of things, and this is the
first time I've done anything with translators or ports. However, I'm
picking it up as I go along (albeit with a lot of googling for
appropriate functions and examples).

Finally, even if this doesn't get picked as a GSoC task (after I send
off my application), I still intend to do this over the summer to
better learn Hurd programming, and so either way there will be an
improved xmlfs this year :)

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: wiki

[Michael Dorrington]

olafbuddenha...@gmx.net wrote:
> Hi,
> 
> On Wed, Mar 23, 2011 at 11:15:21AM +0100, Svante Signell wrote:
> 
>> I don't even know what a .mdwn page is.
> 
> "markdown" is one of the (several) simple text formats for writing
> documents with hyperlinks and basic markup.
> 
>> Why not plain .html?
> 
> HTML was never meant to be writte by hand.

Never?

> Also, the input has to be
> processed anyways, to add headers, links etc. Clearly raw HTML is not
> suitable for writing wiki pages.
> 
> -antrik-
> 
> 

PATCH 1/2 - fix all compiler warnings. (was XMLFS for GSoC)

[Michael Walker]

{ 0, 0, 0, 0, 0, 0 }
 };

 static const char args_doc[] = "XML-DOC";
@@ -52,37 +54,39 @@ static const char doc[] =
   "\vThis translator appears like a directory which tries to match the XML"
   " tree in XML-DOC as closely as possible.";

+error_t parse_opt (int key, char *arg, struct argp_state *state)
+{
+  switch (key)
+  {
+case 'd':
+  debug = fopen (arg, "w");
+  setbuf (debug, NULL);
+  break;
+case ARGP_KEY_ARG:
+  if (state->arg_num == 0)
+xmlfilename = arg;
+  else
+return ARGP_ERR_UNKNOWN;
+  break;
+default:
+  return ARGP_ERR_UNKNOWN;
+}
+
+return 0;
+}
+
 int
 main (int argc, char **argv)
 {
   mach_port_t bootstrap, underlying_node;
   io_statbuf_t underlying_stat;
   file_t xmlfile;
-  char *xmlfilename = NULL;
   error_t err;

+  xmlfilename = NULL;
   debug = NULL;

-  error_t parse_opt (int key, char *arg, struct argp_state *state)
-{
-  switch (key)
-   {
-   case 'd':
- debug = fopen (arg, "w");
- setbuf (debug, NULL);
- break;
-   case ARGP_KEY_ARG:
- if (state->arg_num == 0)
-   xmlfilename = arg;
- else
-   return ARGP_ERR_UNKNOWN;
- break;
-   default:
- return ARGP_ERR_UNKNOWN;
-   }
-  return 0;
-}
-  struct argp argp = { options, parse_opt, args_doc, doc };
+  struct argp argp = { options, parse_opt, args_doc, doc, 0, 0, 0 };

   asprintf ((char **) &argp_program_version, "%s %s",
netfs_server_name, netfs_server_version);

@@ -104,9 +108,9 @@ main (int argc, char **argv)
   if (!xmlfilename)
   /* Try to open the underlying node, which is incidently
 our default XML file. */
-xmlfile = openport (underlying_node, O_READ);
+xmlfile = (file_t) openport (underlying_node, O_READ);
   else
-xmlfile = open (xmlfilename, O_READ);
+xmlfile = (file_t) open (xmlfilename, O_READ);

   xmlfs = malloc (sizeof (struct xmlfs));

@@ -114,7 +118,7 @@ main (int argc, char **argv)

   netfs_root_node->nn_stat = underlying_stat;
   netfs_root_node->nn_stat.st_mode =
-S_IFDIR | (underlying_stat.st_mode & ~S_IFMT & ~S_ITRANS);
+S_IFDIR | (underlying_stat.st_mode & (unsigned int) ~S_IFMT &
(unsigned int) ~S_ITRANS);

   if (err)
 error (1, err, "Cannot create filesystem");
diff --git a/xmlfs.h b/xmlfs.h
index e3c0af6..d47613e 100644
--- a/xmlfs.h
+++ b/xmlfs.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -61,7 +62,12 @@ extern struct xmlfs *xmlfs;

 error_t xmlfs_create (file_t, struct xmlfs *);

+/* Parse an option from the argv array */
+error_t parse_opt (int key, char *arg, struct argp_state *state);
+
+extern char *xmlfilename;
+
 extern FILE *debug;
-#define DEBUG(format, ...) if (debug) fprintf (debug, format, ## __VA_ARGS__)
+#define DEBUG(...) if (debug) fprintf (debug, __VA_ARGS__)

 #endif /* __XMLFS_H__ */


-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

PATCH 2/2 - monitor backing store changes and update. (was XMLFS for GSoC)

[Michael Walker]

fs.c
+++ b/xmlfs.c
@@ -20,6 +20,7 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA.
 */

+#include "monitor.h"
 #include "xmlfs.h"
 #include "version.h"

@@ -75,13 +76,30 @@ error_t parse_opt (int key, char *arg, struct
argp_state *state)
 return 0;
 }

+void
+rebuild_xmlfs (void* param)
+{
+  file_t xmlfile;
+  error_t err;
+
+  (void) param;
+
+  DEBUG ("NOTICE: Reloading XML file\n");
+
+  xmlfile = (file_t) open (xmlfilename, O_READ);
+
+  err = xmlfs_create (xmlfile, xmlfs);
+  if (err)
+error (1, err, "Cannot update filesystem");
+}
+
 int
 main (int argc, char **argv)
 {
-  mach_port_t bootstrap, underlying_node;
+  mach_port_t bootstrap, underlying_node, xmlport;
   io_statbuf_t underlying_stat;
-  file_t xmlfile;
   error_t err;
+  file_t xmlfile;

   xmlfilename = NULL;
   debug = NULL;
@@ -108,10 +126,16 @@ main (int argc, char **argv)
   if (!xmlfilename)
   /* Try to open the underlying node, which is incidently
 our default XML file. */
-xmlfile = (file_t) openport (underlying_node, O_READ);
+{
+  xmlfile = (file_t) openport (underlying_node, O_READ);
+  xmlport = MACH_PORT_NULL;
+}
   else
-xmlfile = (file_t) open (xmlfilename, O_READ);
-
+{
+  xmlfile = (file_t) open (xmlfilename, O_READ);
+  xmlport = file_name_lookup (xmlfilename, 0, 0);
+}
+
   xmlfs = malloc (sizeof (struct xmlfs));

   err = xmlfs_create (xmlfile, xmlfs);
@@ -123,6 +147,16 @@ main (int argc, char **argv)
   if (err)
 error (1, err, "Cannot create filesystem");

+  /* Monitor changes on the underlying XML file */
+  DEBUG ("INFO: Starting file change monitor\n");
+
+  if (xmlport != MACH_PORT_NULL)
+{
+  err = set_file_monitor (xmlport, &rebuild_xmlfs, NULL);
+  if (err)
+error (1, err, "Cannot start file change monitor\n");
+}
+
   DEBUG ("INFO: Entering main loop\n");

   netfs_server_loop ();
diff --git a/xmlfs.h b/xmlfs.h
index d47613e..fa5aeb2 100644
--- a/xmlfs.h
+++ b/xmlfs.h
@@ -62,6 +62,9 @@ extern struct xmlfs *xmlfs;

 error_t xmlfs_create (file_t, struct xmlfs *);

+/* Rebuild the XMLFS data structure */
+void rebuild_xmlfs (void* param);
+
 /* Parse an option from the argv array */
 error_t parse_opt (int key, char *arg, struct argp_state *state);


-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: XMLFS for GSoC

[Michael Walker]

> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory, and the result would
> be a file representing the output of the XSLT processor?

Yes, that's what I was thinking. Though, being able to run it on top
of an XML file should be pretty simple, too.

> BTW, I fear that the scope of your proposal is a bit excessive. The
> summer tends to be over pretty quickly -- unless you are extremely fast,
> I don't think it's likely you will get past making xmlfs and perhaps
> unxmlfs fully functional...

I did originally just plan to do xmlfs, but then I realised that most
of the nontrivial code in the xslt translator and in unxmlfs would be
the same - the directory-tree-to-XML parser, which shouldn't really be
too hard. The only other nontrivial part of the xslt code is the
libnetfs-based translator component, but as that's just presenting the
transformed XML, that could probably just be copied straight from
xmlfs. Thus, I don't think much extra work will really be needed for
either unxmlfs or xslt.

Additionally, I did go from zero Hurd programming knowledge to
implementing a working file change monitor in a couple of days, I do
tend to pick things up pretty quickly.

I think I'll have a go at the directory-tree-to-XML parser tonight and
see how I feel about the proposal after that, and revise it if
necessary.

Thanks for the comments.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: PATCH 1/2 - fix all compiler warnings. (was XMLFS for GSoC)

[Michael Walker]

> That's always a good start!  Where is this repository that your patch is
> against?

http://cvs.savannah.gnu.org/viewvc/xmlfs/?root=hurdextras

> Your editor / mailer broke the lines, so this patch won't even apply.
> Either you instruct your editor / mailer, or let git send-email take care
> of that, or attach the patches instead of publishing them inline.

Heh, oops. I forgot claws-mail strictly enforces line length limits.
I'll keep that in mind

> Hrm.  Not sure whether we'd like all of these.  But you're (to the best
> of my knowledge) to only person working on xmlfs these days, and we have
> no general template, so I'd let you decide.

If any of them turn out to be a problem, or overly complicate the code
(as pretty much everything needs to be explicitly stated with those
flags) I'll consider removing some of them.

> If we really want this, wouldn't it be better to use ``__attribute__
> ((unused))'' with each of the functions' parameters?  In Hurd code, we
> can unconditionally use GNU C / GCC features.

I didn't know of that attribute, and I think I will start using
GCC/GNU stuff more (dropping -pedantic), as GCC is the compiler used
(as antrik pointed out in another email)

> I don't know the surrounding code yet, but should gsize perhaps by a
> size_t instead?

Probably, a lot of the 'problems' could undoubtedly have been fixed in
other ways.

> memcpy with length of one?  Why not replace that with:
>
>    data[size++] = '\n';
>
> (Your cast of data doesn't look right anyway; do you understand and
> agree?)  I should have a look at the whole function -- it still looks a
> bit suspicious: what will come after the '\n' charater; is a '\0'
> expected there?

Yes, that would be a much better solution. I didn't really read the
code thoroughly enough when fixing the warnings, usually going for the
most obvious solution (which may turn out to have caused some issues
later down the line, I suppose). And yes, the case of data looks
completely wrong *facepalm*

> Why move these functions?  Typically, all definitions should be as tight
> in scope as possible.

Warnings about nested functions, though if I'm going to drop -pedantic
and use GCC extensions, that doesn't matter.

> That doesn't look sane.  According to netfs.h these indeed aren't const,
> but why?  They're used only in libnetfs/io-version.c.

I'm not sure. I assumed there was a reason for libnetfs not having
them as consts.

> Both openport and open return an int file descriptor, so why is xmlfile a
> file_t (which is another name for a mach_port_t)?

Looks like xmlfs_create (in fs.c) is using a file_t as a file
descriptor. As that's clearly wrong I'll change that.

>> @@ -114,7 +118,7 @@ main (int argc, char **argv)
>>
>>    netfs_root_node->nn_stat = underlying_stat;
>>    netfs_root_node->nn_stat.st_mode =
>> -    S_IFDIR | (underlying_stat.st_mode & ~S_IFMT & ~S_ITRANS);
>> +    S_IFDIR | (underlying_stat.st_mode & (unsigned int) ~S_IFMT &
>> (unsigned int) ~S_ITRANS);
>
> What's the warning here?

Implicit casting to unsigned int.

Thanks for the comments.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: PATCH 2/2 - monitor backing store changes and update.

[Michael Walker]

>>  all: $(OBJS)
>> -     $(CC) -o $(BINARY) $(OBJS) $(LDFLAGS)
>> +     @$(CC) -o $(BINARY) $(OBJS) $(LDFLAGS)
>>
>>  .c.o:
>> -     $(COMPILE) -c $<
>> +     @$(COMPILE) -c $<
>>
>>  clean:
>> -     rm -f *.o core *.obj *~ $(BINARY)
>> +     @rm -f *.o core *.obj *~ $(BINARY) fs_notify.c
>
> This change is not related to the purpose of the patch... Please put it
> in an extra patch :-)

Ok. I sometimes include multiple small logical changes in one commit,
I'll have to get out of that habit.

>> -
>> +
>
> Avoid such gratuitous changes please...

Oops.

>> new file mode 100644
>> index 000..1a441ca
>> --- /dev/null
>> +++ b/monitor.c
>> @@ -0,0 +1,86 @@
>> +#include "monitor.h"
> [...]
>
> Missing Copyright/License header.

Ok, I wasn't entirely sure what to put as the xmlfs code I started
with had HurdFR stuff, so I decided to leave it until I learned what
the copyright situation for the xmlfs code is.

>> +int
>> +notice_change (mach_msg_header_t *inp, mach_msg_header_t *outp)
>> +{
>
> IIRC most Hurd code has a copy of the function documentation in the .c
> file... Don't know about the existing xmlfs code though?

Hmm, I definitely need to look up commenting/documentation in the GNU
coding style.

>> +  if (handler != NULL)
>> +    (*handler) (params);
>
> I don't think we should ever get into a situation where the notification
> is set up but the handler not? So I guess that should rather be an
> assert()?

Yes, this should be an assert.

>> +/* Only works with one file for now. TODO: work with multiple files */
>> +error_t
>> +set_file_monitor (file_t thefile, void (*thehandler) (void*), void 
>> *theparams)
>
> Err... Why would we need to monitor multiple files in xmlfs?

I originally wrote the monitoring code as a standalone program,
intending to extend it. Forgot to remove some of the irrelevant
code/comments, it seems.

>> +{
>> +  mach_port_t notify;
>> +  error_t err;
>> +  notice_t noticedata;
>> +  cthread_t noticethread;
>> +
>> +  if (thefile == MACH_PORT_NULL)
>> +    error (1, 0, "Null file port given\n");
>
> Again, shouldn't that rather be an assert()?

Yes. I don't really use asserts for some reason, so I'll have to get
into the habit.


>> +  if (err)
>> +    return err;
>
> I think this will also leak bucket and class in the error case?
>

Will fix.

>> +  char filename[1024]; /* Hard filename length limit of 1024, TODO:
>> better solution */
>
> Augh, augh, augh! :-)
>
> I think you should fix this before the patch is commited...

Argh, argh, argh. Note to self: before committing, grep for "TODO"

>
>> +  xmlfile = (file_t) open (xmlfilename, O_READ);
>> +
>> +  err = xmlfs_create (xmlfile, xmlfs);
>
> I believe this will leak a lot of stuff on each file change?

I'll definitely need to have a look at that. Almost certainly
(developing seems so much harder with no valgrind to run after every
change :P)

>> -  mach_port_t bootstrap, underlying_node;
>> +  mach_port_t bootstrap, underlying_node, xmlport;
>
> I'm somewhat confused by the xmlport/xmlfile duality... Perhaps you
> could add a comment explaining it?

Yes, I'll add a comment explaining that. Basically, it's because I
need to pass a port to file_notice_changes.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: XMLFS for GSoC

[Michael Walker]

> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard. The only other nontrivial part of the xslt code is the
> libnetfs-based translator component, but as that's just presenting the
> transformed XML, that could probably just be copied straight from
> xmlfs. Thus, I don't think much extra work will really be needed for
> either unxmlfs or xslt.

Ok, I've had a go at making an xmlfs-directory-structure to XML
converter, and thought in more detail about what needs to be
implemented for each translator and what can be shared, and I've
concluded that I probably can get this done in the time available.

Shared nontrivial code:
  * XML to libnetfs read-only translator: partially done
 Partial compliance to XML spec (problem being the use of, eg
"foo0" rather than "foo[0]")

  * xmlfs tree representation to libxml2 representation: partially done
 Can descend down a directory tree and identify whether everything
encountered is a tag name, attribute, or text node. Dies with an error
if anything else is encountered. All that remains is having it build a
libxml2 representation of the tree.

  * Watch a file/directory for changes and run a function when there
is one: done

Unshared nontrivial code:
  * XML writing
 Not needed for xslt because, as far as I'm aware, XSLT is a
one-way mapping. I may be wrong however, so I'll look into this. All
that needs to be done for this is to update the libxml2 representation
of the XML document. This will be pretty tricky, as I'll have to learn
to use libxml2 properly, but completely doable.

  * Read support in unxmlfs
 unxmlfs takes an xmlfs-compatible directory tree and turns it
into an XML file, thus reading will be done via libtrivfs, with no
write support (I see no need/use for that). I haven't used libtrivfs
before, but hurdextras should provide more than enough examples for me
to learn.

The translators themselves will be implemented out of the following components:

  * xmlfs:
* XML to libnetfs read-only translator
* Watch a file/directory for changes and run a function when there is one
  * Update the presented directory hierarchy
* XML writing

  * unxmlfs:
* Watch a file/directory for changes and run a function when there is one
  * Update the presented XML file
* xmlfs tree representation to libxml2 representation
* Read support in unxmlfs

  * xslt
* Watch a file/directory for changes and run a function when there is one
  * Update the presented directory hierarchy
* xmlfs tree representation to libxml2 representation
* Perform an XSLT transformation
* XML to libnetfs read-only translator

I think that this is perfectly achievable in the time available.

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: XMLFS for GSoC

[Michael Walker]

> Well, if you need the exact same code, this is a pretty good indication
> that it probably shouldn't be in the XSLT translator at all... Working
> on top of a directory tree would only make sense if it would actually
> use the provided structure directly, rather than first serializing it.
>
> Or do you mean just the part that reads the directory structure and
> constructs an internal DOM tree from it?

Yes, that part.

> I don't think the XSLT translator should present a directory tree as
> output. Nothing in XSLT requires the output to be XML.

Aha, I had a feeling I was misunderstanding something somewhere. In
that case, xslt would be even simpler - the code would be pretty much
the same as unxmlfs (turn an xmlfs directory tree into an internal DOM
representation and present it as output via trivfs), but just with a
transformation performed.
In fact, if that's the case maybe even just a "--xslt=FILE" option to
unxmlfs would do the trick. However, XSLT is commonly used to turn one
XML document into another, so perhaps there should be an option to try
and present it as a directory tree, but default to presenting just a
single file.
I need to think about that. In any case, that's not adding much
complexity (probably simplifying things in some areas, in fact).

-- 
Michael Walker (http://www.barrucadu.co.uk)

Arch Hurd Developer;      GNU Webmaster;       FSF member #8385
http://www.archhurd.org   http://www.gnu.org   http://www.fsf.org

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

[Michael Banck]

Hi,

On Tue, Nov 01, 2011 at 11:49:48AM +0100, Svante Signell wrote:
> In package uptimed-0.3.16 the following function is defined:

BTW, I had a look at uptimed before, and the main problem I faced
(IIRC), was making it crash safe.  uptimed is writing the current uptime
into a file, and even on GNU/Linux with ext3 or so I had some issuse
with corrupted uptime files after reboot.

Parsing those files is the main point, so writing them safely is
important.  I don't remember whether the code for that is
platform-dependent though.


Michael

Building from Savannah

[David Michael]

Hi,

I started building a Hurd system from Savannah repos and ran into some
difficulties (e.g. pthread symbols used in Hurd but only defined in
Debian's libc).  Are these repositories supposed to be usable on their
own, or is development mostly happening on the Debian sources?

A few minor compatibilitiy corrections had to be made as well.  I
haven't done any Hurd copyright assignment, so I'm not sure if I
should send patches for review.  (Does anyone know where to find those
forms?)

Let me know if there is interest in supporting Fedora builds from
Savannah repos, and I can send some fixes.

Thanks.

David

[PATCH 0/3] Build fixes for Fedora

[David Michael]

Hi,

These patches are some fixes for my build system that should qualify
as trivial.  I'm new to this build process, so it's entirely possible
that I am at fault for any breakage.  Please tell me if something is
clearly wrong on my side.  For the record, this build was done with a
cross-compiler/sys-root environment (in the spirit of MinGW) that I
packaged on Fedora 18 x86_64 using Savannah git repos.

The first patch handles an undefined symbol.

The second handles a missing header.  This one concerns me because it
appears elsewhere (procfs), but I didn't see where the missing header
would get installed on working builds.  Even the gnumach-dev package
in sid provides a *.defs file as this patch expects, not the header.

The third handles Fedora's disabling of implicit linking.  This might
be necessary sooner or later since it sounds like Debian is also
going to use a comparable configuration[1].

This is mostly enough to get a working build.  At least it boots and
gets to /hurd/exec.  (That's where I stopped with this to look into
tweaking other packages for the cross-compiler.)

David

[1] http://wiki.debian.org/ToolChain/DSOLinking

David Michael (3):
  libdiskfs: Allow SYMLOOP_MAX to be undefined
  utils/vmstat: Use gnumach.defs from gnumach
  Explicitly link against all utilized libraries

 Makeconf|  2 +-
 auth/Makefile   |  2 +-
 boot/Makefile   |  2 +-
 console-client/Makefile |  1 +
 console/Makefile|  2 +-
 daemons/Makefile|  2 ++
 exec/Makefile   |  2 +-
 fatfs/Makefile  |  2 +-
 fstests/Makefile|  1 +
 ftpfs/Makefile  |  2 +-
 hostmux/Makefile|  2 +-
 init/Makefile   |  1 +
 libdiskfs/boot-start.c  |  2 +-
 nfs/Makefile|  2 +-
 nfsd/Makefile   |  2 +-
 pfinet/Makefile |  2 +-
 pflocal/Makefile|  2 +-
 proc/Makefile   |  2 +-
 storeio/Makefile|  2 +-
 sutils/Makefile |  3 +++
 term/Makefile   |  2 +-
 tmpfs/Makefile  |  2 +-
 trans/Makefile  | 17 -
 ufs-utils/Makefile  |  1 +
 usermux/Makefile|  2 +-
 utils/Makefile  | 28 +---
 utils/vmstat.c  |  2 +-
 27 files changed, 69 insertions(+), 23 deletions(-)

--
1.8.1.4

[PATCH 1/3] libdiskfs: Allow SYMLOOP_MAX to be undefined

[David Michael]

POSIX systems are allowed to leave SYMLOOP_MAX undefined, and in such
cases applications are supposed to use sysconf.

* libdiskfs/boot-start.c (diskfs_start_bootstrap): Replace macro with sysconf.
---

According to the standard[1], an undefined SYMLOOP_MAX has a defined
interpretation.  The glibc sysconf implementation[2] should provide a
valid substitute for the macro.

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_01
[2] 
http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/sysconf.c?h=tschwinge/Roger_Whittaker

 libdiskfs/boot-start.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c
index 1e4a1c6..269edfa 100644
--- a/libdiskfs/boot-start.c
+++ b/libdiskfs/boot-start.c
@@ -237,7 +237,7 @@ diskfs_start_bootstrap ()
 }
   else if (retry == FS_RETRY_MAGICAL && pathbuf[0] == '/')
 {
-  assert (init_lookups < SYMLOOP_MAX);
+  assert (init_lookups < sysconf (_SC_SYMLOOP_MAX));

   /* INITNAME is a symlink with an absolute target, so try again.  */
   initname = strdupa (pathbuf);
--
1.8.1.4

[PATCH 2/3] utils/vmstat: Use gnumach.defs from gnumach

[David Michael]

The gnumach installation provides the include file mach/gnumach.defs
instead of mach/gnumach.h.  This runs the defs file through MIG and
builds the result for vmstat.

* utils/vmstat.c: Replace  with "gnumach_U.h".
* utils/Makefile (vmstat): Add rule to depend on gnumach_U.o.
* Makeconf (mach_defs_names): Add gnumach.
---
 Makeconf   | 2 +-
 utils/Makefile | 2 ++
 utils/vmstat.c | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makeconf b/Makeconf
index c72287a..a3c584f 100644
--- a/Makeconf
+++ b/Makeconf
@@ -573,7 +573,7 @@ $(mig-sheader-prefix)%_S.h %Server.c: %.sdefsi
 vpath %.defs $(top_srcdir)/hurd

 # These we want to find in the libc include directory...
-mach_defs_names = bootstrap exc mach mach4 \
+mach_defs_names = bootstrap exc gnumach mach mach4 \
 mach_host mach_port mach_timer_reply memory_object \
 memory_object_default notify
 device_defs_names = dev_forward device device_reply device_request
diff --git a/utils/Makefile b/utils/Makefile
index e3bed0b..e2388f5 100644
--- a/utils/Makefile
+++ b/utils/Makefile
@@ -61,6 +61,8 @@ ps w ids settrans syncfs showtrans fsysopts
storeinfo login vmstat portinfo \

 $(filter-out $(special-targets), $(targets)): %: %.o

+vmstat: gnumachUser.o
+
 rpctrace: ../libports/libports.a ../libihash/libihash.a
 rpctrace-CPPFLAGS = -DDATADIR=\"${datadir}\"

diff --git a/utils/vmstat.c b/utils/vmstat.c
index e394484..90d128f 100644
--- a/utils/vmstat.c
+++ b/utils/vmstat.c
@@ -27,8 +27,8 @@
 #include 
 #include 

+#include "gnumach_U.h"
 #include 
-#include 
 #include 
 #include 
 #include 
--
1.8.1.4

[PATCH 3/3] Explicitly link against all utilized libraries

[David Michael]

Since libc is linked against libmachuser and libhurduser, they are
implicitly linked against everything else on certain systems.  On
systems where implicit linking is disabled, a binary must explicitly
link against each library from which it references symbols.

* auth/Makefile (OTHERLIBS): Explicitly link libmachuser and libhurduser.
* boot/Makefile (OTHERLIBS): Likewise.
* console/Makefile (OTHERLIBS): Likewise.
* console-client/Makefile (console-LDLIBS): Likewise.
* daemons/Makefile (console-run-LDLIBS): Likewise.
* exec/Makefile (OTHERLIBS): Likewise.
* fatfs/Makefile (OTHERLIBS): Likewise.
* ftpfs/Makefile (OTHERLIBS): Likewise.
* hostmux/Makefile (OTHERLIBS): Likewise.
* init/Makefile (OTHERLIBS): Likewise.
* nfsd/Makefile (OTHERLIBS): Likewise.
* pfinet/Makefile (OTHERLIBS): Likewise.
* pflocal/Makefile (OTHERLIBS): Likewise.
* proc/Makefile (OTHERLIBS): Likewise.
* term/Makefile (OTHERLIBS): Likewise.
* tmpfs/Makefile (OTHERLIBS): Likewise.
* trans/Makefile (crash-LDLIBS): Likewise.
(fakeroot-LDLIBS): Likewise.
(firmlink-LDLIBS): Likewise.
(ifsock-LDLIBS): Likewise.
(magic-LDLIBS): Likewise.
(password-LDLIBS): Likewise.
(symlink-LDLIBS): Likewise.
* usermux/Makefile (OTHERLIBS): Likewise.
* utils/Makefile (rpctrace-LDLIBS): Likewise.
(vminfo-LDLIBS): Likewise.
* fstests/Makefile (fstests-LDLIBS): Explicitly link libmachuser.
* nfs/Makefile (OTHERLIBS): Likewise.
* storeio/Makefile (OTHERLIBS): Likewise.
* sutils/Makefile (swapoff-LDLIBS): Likewise.
(swapon-LDLIBS): Likewise.
* trans/Makefile (fifo-LDLIBS): Likewise.
(fwd-LDLIBS): Likewise.
(hello-LDLIBS): Likewise.
(hello-mt-LDLIBS): Likewise.
(new-fifo-LDLIBS): Likewise.
(null-LDLIBS): Likewise.
(proxy-defpager-LDLIBS): Likewise.
(remap-LDLIBS): Likewise.
(streamio-LDLIBS): Likewise.
* ufs-utils/Makefile (mkfs-LDLIBS): Likewise.
* utils/Makefile (dev-probe-LDLIBS): Likewise.
(vmstat-LDLIBS): Likewise.
* daemons/Makefile (mail.local-LDLIBS): Explicitly link libhurduser.
* sutils/Makefile (fsck-LDLIBS): Likewise.
* utils/Makefile (addauth-LDLIBS): Likewise.
(fakeauth-LDLIBS): Likewise.
(fsysopts-LDLIBS): Likewise.
(gcore-LDLIBS): Likewise.
(ids-LDLIBS): Likewise.
(login-LDLIBS): Likewise.
(mount-LDLIBS): Likewise.
(msgport-LDLIBS): Likewise.
(portinfo-LDLIBS): Likewise.
(ps-LDLIBS): Likewise.
(rmauth-LDLIBS): Likewise.
(setauth-LDLIBS): Likewise.
(settrans-LDLIBS): Likewise.
(shd-LDLIBS): Likewise.
(showtrans-LDLIBS): Likewise.
(storeread-LDLIBS): Likewise.
(syncfs-LDLIBS): Likewise.
(unsu-LDLIBS): Likewise.
(w-LDLIBS): Likewise.
---
 auth/Makefile   |  2 +-
 boot/Makefile   |  2 +-
 console-client/Makefile |  1 +
 console/Makefile|  2 +-
 daemons/Makefile|  2 ++
 exec/Makefile   |  2 +-
 fatfs/Makefile  |  2 +-
 fstests/Makefile|  1 +
 ftpfs/Makefile  |  2 +-
 hostmux/Makefile|  2 +-
 init/Makefile   |  1 +
 nfs/Makefile|  2 +-
 nfsd/Makefile   |  2 +-
 pfinet/Makefile |  2 +-
 pflocal/Makefile|  2 +-
 proc/Makefile   |  2 +-
 storeio/Makefile|  2 +-
 sutils/Makefile |  3 +++
 term/Makefile   |  2 +-
 tmpfs/Makefile  |  2 +-
 trans/Makefile  | 17 -
 ufs-utils/Makefile  |  1 +
 usermux/Makefile|  2 +-
 utils/Makefile  | 26 +++---
 24 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/auth/Makefile b/auth/Makefile
index 75910c7..af15b55 100644
--- a/auth/Makefile
+++ b/auth/Makefile
@@ -23,7 +23,7 @@ SRCS = auth.c
 OBJS = auth.o authServer.o auth_replyUser.o
 target = auth
 HURDLIBS = ports ihash shouldbeinlibc
-OTHERLIBS = -lpthread
+OTHERLIBS = -lpthread -lmachuser -lhurduser

 MIGSFLAGS = -imacros $(srcdir)/authmutations.h

diff --git a/boot/Makefile b/boot/Makefile
index 0d883b0..0adf900 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -28,7 +28,7 @@ UX-OBJS = mach-crt0.o uxboot.o sigvec.o syscall.o
ux.o $(COMMON-OBJS)
 target = boot
 io-MIGSFLAGS=-DREPLY_PORTS
 HURDLIBS = store shouldbeinlibc
-OTHERLIBS = -lpthread
+OTHERLIBS = -lpthread -lmachuser -lhurduser

 include ../Makeconf

diff --git a/console-client/Makefile b/console-client/Makefile
index 69a7e37..14d27b8 100644
--- a/console-client/Makefile
+++ b/console-client/Makefile
@@ -40,6 +40,7 @@ HURDLIBS = cons ports netfs fshelp iohelp ihash shouldbeinlibc
 LDLIBS = -ldl -lpthread
 module-dir = $(libdir)/hurd/console
 console-LDFLAGS = -Wl,-E
+console-LDLIBS = -lmachuser -lhurduser

 CPPFLAGS += -I$(CURDIR)/xkb -I$(srcdir)/xkb
 LFLAGS = -i
diff --git a/console/Makefile b/console/Makefile
index c5ab543..ce8882f 100644
--- a/console/Makefile
+++ b/console/Makefile
@@ -27,7 +27,7 @@ SRCS = console.c display.c pager.c input.c
 MIGSTUBS = notifyServer.o tioctlServer.o fs_notifyUser.o

 HURDLIBS = netfs fshelp iohelp pager ports ihash shouldbeinlibc
-OTHERLIBS = -lpthread
+OTHERLIBS = -lpthread -lmachuser -lhurduser
 OBJS = $(sort $(SRCS:.c=.o) $(MIGSTUBS))

 MIGSFLAG

Re: [PATCH 3/3] Explicitly link against all utilized libraries

[David Michael]

Hi,

On Wed, May 1, 2013 at 10:03 PM, Samuel Thibault
 wrote:
> Roland McGrath, le Wed 01 May 2013 19:01:14 -0700, a écrit :
>> So if need be, we should make the installed libc.so linker script do
>> AS_NEEDED ( libmachuser.so.1 libhurduser.so.1 ) or something like that.
>
> We already do this actually.

This is not the case for the Savannah glibc, apparently.  I was
following a Hurd wiki page that said to use the
tschwinge/Roger_Whittaker branch.  The installed libc.so contains only
AS_NEEDED ( /usr/lib/ld.so.1 ).  Perhaps I can adjust this and send a
patch for that branch instead.

Thanks.

David

Re: [PATCH 3/3] Explicitly link against all utilized libraries

[David Michael]

Hi,

I have built the Savannah glibc branch tschwinge/Roger_Whittaker with
an AS_NEEDED patch[1], and this corrects the implicit linking issue as
well.  I would rather that simpler fix be applied to the glibc branch
over using the patch in this thread, but the other two patches in this
set are still necessary for a successful build.

Thanks.

David

[1] 
http://patch-tracker.debian.org/patch/series/view/eglibc/2.13-38/hurd-i386/submitted-add-needed.diff

Re: [PATCH 2/3] utils/vmstat: Use gnumach.defs from gnumach

[David Michael]

Hi,

On Sun, May 5, 2013 at 5:32 PM, Samuel Thibault  wrote:
> Also, if you consider writing more involved patches (i.e. which will
> have some copyright), we will need a copyright assignment from you.

That may happen as I continue working with the system.  The wiki[1]
just links to "contact us" with regard to obtaining the relevant
forms.  If you can direct me to the necessary resources (I suppose for
both Mach and Hurd?), I'll make sure that issue is resolved before
sending future changes.

Thanks.

David

[1] https://www.gnu.org/software/hurd/contributing/copyright_assignment.html

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

[Michael Banck]

Hi,

On Sun, May 05, 2013 at 12:33:27AM +0200, Arne Babenhauserheide wrote:
> A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.
> 
> At the end of the last 2 quarters, Samuel Thibault pushed the [pthread
> patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html)
> from Vincente, Barry, Thomas, Richard and Samuel and others to the
> different upstream packages, 

As QotH is supposed to be read by a wider audience, I really think you 
should expand the last names of people at least for the first mention.


Michael

Re: Imminent Debian GNU/Hurd release

[Michael Banck]

Hi,

On Fri, May 10, 2013 at 09:30:12PM +0100, Miguel Figueiredo wrote:
> It is with huge pleasure that the Hurd project 

The Debian GNU/Hurd port and the GNU Hurd project are not exactly the
same, even though the member overlap is significant.

Just pointing this out here as I am not sure the (GNU) Hurd project has
acked this and I assume this is a Debian GNU/Hurd effort? (Either would
be fine with me).


Michael

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

[Michael Banck]

Hi,

On Fri, May 10, 2013 at 09:58:28PM +0200, Arne Babenhauserheide wrote:
> At the end of the last 2 quarters, Samuel Thibault pushed the [pthread
> patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html)
> from Vicente Hernando Ara, Barry de Frese, Thomas Schwinge, Richard

It's Barry de Freese, two e.


Michael

Re: [PATCH 2/3] utils/vmstat: Use gnumach.defs from gnumach

[David Michael]

Hi,

On Mon, May 13, 2013 at 6:10 PM, Richard Braun  wrote:
> Sorry for reacting late but I don't see the point of that change. Using
> already generated system headers is the intent here. The fact they were
> generated doesn't matter at all, they are the interface reference that
> applications (and even the Hurd itself) must use.

So is  supposed to be generated at some point in the
gnumach install?  That doesn't happen during my build from the
Savannah sources; it only provides .  Am I missing
a step somewhere?

Thanks.

David

[PATCH] config.make: Use more configure settings when building xkb-data

[David Michael]

* config.make.in (datarootdir,YACC): New variable.
* configure.ac (XKB_BASE): Drop extraneous "/share" from path.
---

Hi,

I recently started building Hurd with X11 and ran into some minor troubles.

First, configure detects yacc, but it doesn't get substituted.  This
results in make's default YACC=yacc, so the build would fail on my
system with only GNU bison.

Also, the default XKB_PATH expands to use ${datarootdir}, which wasn't
substituted either.  This would cause the installation to misplace
files.  Correcting this also silences the following warning:

config.status: WARNING:  'config.make.in' seems to ignore the
--datarootdir setting

Comments?

Thanks.

David

 config.make.in | 2 ++
 configure.ac   | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/config.make.in b/config.make.in
index b8002a1..b3eee54 100644
--- a/config.make.in
+++ b/config.make.in
@@ -30,6 +30,7 @@ sysconfdir = @sysconfdir@
 localstatedir = @localstatedir@
 sharedstatedir = @sharedstatedir@
 datadir = @datadir@
+datarootdir = @datarootdir@

 # All of those directories together:
 installationdirlist = $(hurddir) $(libdir) $(bindir) $(sbindir) \
@@ -48,6 +49,7 @@ MIG = @MIG@
 MIGCOM = $(MIG) -cc cat - /dev/null
 AWK = @AWK@
 SED = @SED@
+YACC = @YACC@

 # Compilation flags.  Append these to the definitions already made by
 # the specific Makefile.
diff --git a/configure.ac b/configure.ac
index 31e48ef..73598cf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -246,7 +246,7 @@ PKG_CHECK_MODULES([X11], [x11 xproto],
 AS_IF([test $pkg_failed = no],
   [XKB_BASE="$pkg_cv_XKB_BASE"
AC_MSG_RESULT([$XKB_BASE])],
-  [XKB_BASE="$datadir/share/X11/xkb"
+  [XKB_BASE="$datadir/X11/xkb"
AC_MSG_RESULT([(default) $XKB_BASE])])
 AC_MSG_CHECKING([for X11 prefix])
 _PKG_CONFIG([X11_PREFIX], [variable=prefix], [x11])
-- 
1.8.3.1

[PATCH v2] config.make: Use more configure settings when building xkb-data

[David Michael]

* config.make.in (datarootdir,LEX,YACC): New variable.
* configure.ac (XKB_BASE): Drop extraneous "/share" from path.
* configure.ac: Reset pkg-config status between tests.
---

Hi,

Here's a slight addition:  The pkg-config error state was not being
reset between the variable reads.  This would force a blank X11_PREFIX
if xkeyboard-config is not detected.

Also, since LEX was in the same boat as YACC, that definition is included.

Thanks.

David

 config.make.in | 3 +++
 configure.ac   | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/config.make.in b/config.make.in
index b8002a1..dbcf8a3 100644
--- a/config.make.in
+++ b/config.make.in
@@ -30,6 +30,7 @@ sysconfdir = @sysconfdir@
 localstatedir = @localstatedir@
 sharedstatedir = @sharedstatedir@
 datadir = @datadir@
+datarootdir = @datarootdir@

 # All of those directories together:
 installationdirlist = $(hurddir) $(libdir) $(bindir) $(sbindir) \
@@ -48,6 +49,8 @@ MIG = @MIG@
 MIGCOM = $(MIG) -cc cat - /dev/null
 AWK = @AWK@
 SED = @SED@
+LEX = @LEX@
+YACC = @YACC@

 # Compilation flags.  Append these to the definitions already made by
 # the specific Makefile.
diff --git a/configure.ac b/configure.ac
index 31e48ef..b827536 100644
--- a/configure.ac
+++ b/configure.ac
@@ -246,8 +246,9 @@ PKG_CHECK_MODULES([X11], [x11 xproto],
 AS_IF([test $pkg_failed = no],
   [XKB_BASE="$pkg_cv_XKB_BASE"
AC_MSG_RESULT([$XKB_BASE])],
-  [XKB_BASE="$datadir/share/X11/xkb"
+  [XKB_BASE="$datadir/X11/xkb"
AC_MSG_RESULT([(default) $XKB_BASE])])
+pkg_failed=no
 AC_MSG_CHECKING([for X11 prefix])
 _PKG_CONFIG([X11_PREFIX], [variable=prefix], [x11])
 AS_IF([test $pkg_failed = no],
-- 
1.8.3.1

Re: [PATCH] umount: add a umount utility

[David Michael]

Hi,

On Thu, Aug 15, 2013 at 2:23 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> +#include 

Does umount.c use anything in blkid.h?  It seems to build with that
line removed.

I didn't have libblkid's development files installed when I first
tried building umount, causing an error.  It would be nice to remove
this build dependency if it isn't actually required.

Thanks.

David

Re: [PATCH] mount: handle -t auto

[David Michael]

Hi,

I tried building mount and got a linker error due to missing the -lblkid.

On Mon, Sep 2, 2013 at 4:55 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> +mount-LDLIBS = $(libblkid-LIBS)
> +mount-CPPFLAGS = $(libblkid-CFLAGS)

Those libblkid variables were defined using an underscore in the name
instead of a dash.  The mount program built after s/d-/d_/ on those
two lines in utils/Makefile.

Can this be adjusted?

Thanks.

David

P.S.  Another minor nitpick:  HAVE_BLKID is not being substituted in
config.make.  Neither is HAVE_DAEMON.  However, nothing seems to use
these make variables at the moment, so a correction would only be
cosmetic.

Re: [PATCH 10/16] hurd: add fsys_get_children

[David Michael]

Hi,

On Tue, Jul 30, 2013 at 5:59 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> * hurd/fsys.defs: Add fsys_get_children.
> * hurd/fsys_reply.defs: Add fsys_get_children.

While trying to build the latest changes, this seems to result in a
new compile failure.  The file libdiskfs/boot-start.c includes both
 and "fsys_reply_U.h" which contain conflicting
definitions of fsys_get_children.  It builds by choosing one or the
other.  However, I haven't dug into this to tell what else may be
affected, so I thought I'd better ask for any suggestions on how to
proceed.

Thanks.

David

[RFC] GDB Fixes

[David Michael]

Hi,

Recent changes in mig/Hurd have broken GDB's build process.  I've
appended my changes here and would appreciate any feedback.
(Apologies if this is better sent to a GDB mailing list; I'm hoping
someone here can tell me if I'm doing something stupid with mig
output.)

The first part fixes an awk script after the "auto" keywords were
stripped from mig's output.  The patch adds another block that should
make it compatible with both old and new versions of mig.

The second part defines some process_reply.defs functions to bring it
in line with Hurd's 0845794f.  I assume these will just be unused
functions when building with old Hurd versions, but I haven't tested.

Can anyone comment on this?  (Also, sorry if this steps on any of the
other Hurd/GDB projects going on--I'm just trying to get a working
debugger again.)

Thanks.

David


--- gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
+++ gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
@@ -85,6 +85,13 @@ parse_phase == 5 && /^[ \t]*(auto|static
   print; next;
 }

+parse_phase == 5 && /^[ \t]*const mach_msg_type_t/ {
+  # The type check structure for an argument.
+  arg_check_name[num_checks] = $3;
+  num_checks++;
+  print; next;
+}
+
 parse_phase == 5 && /^[ \t]*mig_external kern_return_t/ {
   # The declaration of the user server function for this rpc.
   user_function_name = $3;
--- gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
+++ gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
@@ -1902,6 +1902,142 @@ S_proc_getmsgport_reply (mach_port_t rep
   return ill_rpc ("S_proc_getmsgport_reply");
 }

+error_t
+S_proc_pid2task (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_pid2task");
+}
+
+error_t
+S_proc_task2pid (mach_port_t reply, error_t err, pid_t pid)
+{
+  return ill_rpc ("S_proc_task2pid");
+}
+
+error_t
+S_proc_task2proc (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_task2proc");
+}
+
+error_t
+S_proc_proc2task (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_proc2task");
+}
+
+error_t
+S_proc_pid2proc (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_pid2proc");
+}
+
+error_t
+S_proc_getprocinfo (mach_port_t reply, error_t err, int flags,
+procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
+data_t threadwaits, mach_msg_type_number_t threadwaitsCnt)
+{
+  return ill_rpc ("S_proc_getprocinfo");
+}
+
+error_t
+S_proc_getprocargs (mach_port_t reply, error_t err,
+data_t procargs, mach_msg_type_number_t procargsCnt)
+{
+  return ill_rpc ("S_proc_getprocargs");
+}
+
+error_t
+S_proc_getprocenv (mach_port_t reply, error_t err,
+   data_t procenv, mach_msg_type_number_t procenvCnt)
+{
+  return ill_rpc ("S_proc_getprocenv");
+}
+
+error_t
+S_proc_getloginid (mach_port_t reply, error_t err, pid_t login_id)
+{
+  return ill_rpc ("S_proc_getloginid");
+}
+
+error_t
+S_proc_getloginpids (mach_port_t reply, error_t err,
+ pidarray_t pids, mach_msg_type_number_t pidsCnt)
+{
+  return ill_rpc ("S_proc_getloginpids");
+}
+
+error_t
+S_proc_getlogin (mach_port_t reply, error_t err, string_t logname)
+{
+  return ill_rpc ("S_proc_getlogin");
+}
+
+error_t
+S_proc_getsid (mach_port_t reply, error_t err, pid_t sid)
+{
+  return ill_rpc ("S_proc_getsid");
+}
+
+error_t
+S_proc_getsessionpgids (mach_port_t reply, error_t err,
+pidarray_t pgidset, mach_msg_type_number_t pgidsetCnt)
+{
+  return ill_rpc ("S_proc_getsessionpgids");
+}
+
+error_t
+S_proc_getsessionpids (mach_port_t reply, error_t err,
+   pidarray_t pidset, mach_msg_type_number_t pidsetCnt)
+{
+  return ill_rpc ("S_proc_getsessionpids");
+}
+
+error_t
+S_proc_getsidport (mach_port_t reply, error_t err, mach_port_t sessport)
+{
+  return ill_rpc ("S_proc_getsidport");
+}
+
+error_t
+S_proc_getpgrp (mach_port_t reply, error_t err, pid_t pgrp)
+{
+  return ill_rpc ("S_proc_getpgrp");
+}
+
+error_t
+S_proc_getpgrppids (mach_port_t reply, error_t err,
+pidarray_t pidset, mach_msg_type_number_t pidsetCnt)
+{
+  return ill_rpc ("S_proc_getpgrppids");
+}
+
+error_t
+S_proc_get_tty (mach_port_t reply, error_t err, mach_port_t tty)
+{
+  return ill_rpc ("S_proc_get_tty");
+}
+
+error_t
+S_proc_getnports (mach_port_t reply, error_t err,
+  mach_msg_type_number_t nports)
+{
+  return ill_rpc ("S_proc_getnports");
+}
+
+error_t
+S_proc_is_important (mach_port_t reply, error_t err, boolean_t essential)
+{
+  return ill_rpc ("S_proc_is_important");
+}
+
+error_t
+S_proc_get_code (mach_port_t reply, error_t err,
+ vm_address_t start_code, vm_address_t end_code)
+{
+  return ill_rpc ("S_proc_get_code");
+}
+

 /* Msg_reply server routines.  We only use msg_sig_post_untraced_reply.  */

Re: [RFC] GDB Hurd Fixes

[David Michael]

Hi,

(Copying gdb-patches this time.)

Here is an updated patch to successfully build GDB after today's
Hurd/mig changes.

The awk script changes handle the "auto" keyword being dropped from
mig output, and that an "#if TypeCheck" line appears before
arg_check_name is defined in some new functions.

The gnu-nat.c changes define functions for the new process_reply.defs entries.

I'd appreciate any feedback or suggestions for getting GDB building on
current Hurd again.

Thanks.

David


--- gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
+++ gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
@@ -85,13 +85,20 @@ parse_phase == 5 && /^[ \t]*(auto|static
   print; next;
 }

+parse_phase == 5 && /^[ \t]*const mach_msg_type_t/ {
+  # The type check structure for an argument.
+  arg_check_name[num_checks] = $3;
+  num_checks++;
+  print; next;
+}
+
 parse_phase == 5 && /^[ \t]*mig_external kern_return_t/ {
   # The declaration of the user server function for this rpc.
   user_function_name = $3;
   print; next;
 }

-parse_phase == 5 && /^#if[ \t]TypeCheck/ {
+parse_phase == 5 && /^#if[ \t]TypeCheck/ && num_checks > 0 {
   # The first args type checking statement; we need to insert our chunk of
   # code that bypasses all the type checks if this is an error return, after
   # which we're done until we get to the next function.  Handily, the size
--- gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
+++ gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
@@ -1902,6 +1902,142 @@ S_proc_getmsgport_reply (mach_port_t rep
   return ill_rpc ("S_proc_getmsgport_reply");
 }

+error_t
+S_proc_pid2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_pid2task_reply");
+}
+
+error_t
+S_proc_task2pid_reply (mach_port_t reply, error_t err, pid_t pid)
+{
+  return ill_rpc ("S_proc_task2pid_reply");
+}
+
+error_t
+S_proc_task2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_task2proc_reply");
+}
+
+error_t
+S_proc_proc2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_proc2task_reply");
+}
+
+error_t
+S_proc_pid2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_pid2proc_reply");
+}
+
+error_t
+S_proc_getprocinfo_reply (mach_port_t reply, error_t err, int flags,
+  procinfo_t procinfo, mach_msg_type_number_t piCnt,
+  data_t threadwaits, mach_msg_type_number_t twCnt)
+{
+  return ill_rpc ("S_proc_getprocinfo_reply");
+}
+
+error_t
+S_proc_getprocargs_reply (mach_port_t reply, error_t err,
+  data_t procargs, mach_msg_type_number_t procargsCnt)
+{
+  return ill_rpc ("S_proc_getprocargs_reply");
+}
+
+error_t
+S_proc_getprocenv_reply (mach_port_t reply, error_t err,
+ data_t procenv, mach_msg_type_number_t procenvCnt)
+{
+  return ill_rpc ("S_proc_getprocenv_reply");
+}
+
+error_t
+S_proc_getloginid_reply (mach_port_t reply, error_t err, pid_t login_id)
+{
+  return ill_rpc ("S_proc_getloginid_reply");
+}
+
+error_t
+S_proc_getloginpids_reply (mach_port_t reply, error_t err,
+   pidarray_t pids, mach_msg_type_number_t pidsCnt)
+{
+  return ill_rpc ("S_proc_getloginpids_reply");
+}
+
+error_t
+S_proc_getlogin_reply (mach_port_t reply, error_t err, string_t logname)
+{
+  return ill_rpc ("S_proc_getlogin_reply");
+}
+
+error_t
+S_proc_getsid_reply (mach_port_t reply, error_t err, pid_t sid)
+{
+  return ill_rpc ("S_proc_getsid_reply");
+}
+
+error_t
+S_proc_getsessionpgids_reply (mach_port_t reply, error_t err,
+  pidarray_t pgidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc ("S_proc_getsessionpgids_reply");
+}
+
+error_t
+S_proc_getsessionpids_reply (mach_port_t reply, error_t err,
+ pidarray_t pidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc ("S_proc_getsessionpids_reply");
+}
+
+error_t
+S_proc_getsidport_reply (mach_port_t reply, error_t err, mach_port_t sessport)
+{
+  return ill_rpc ("S_proc_getsidport_reply");
+}
+
+error_t
+S_proc_getpgrp_reply (mach_port_t reply, error_t err, pid_t pgrp)
+{
+  return ill_rpc ("S_proc_getpgrp_reply");
+}
+
+error_t
+S_proc_getpgrppids_reply (mach_port_t reply, error_t err,
+  pidarray_t pidset, mach_msg_type_number_t pidsetCnt)
+{
+  return ill_rpc ("S_proc_getpgrppids_reply");
+}
+
+error_t
+S_proc_get_tty_reply (mach_port_t reply, error_t err, mach_port_t tty)
+{
+  return ill_rpc ("S_proc_get_tty_reply");
+}
+
+error_t
+S_proc_getnports_reply (mach_port_t reply, error_t err,
+mach_msg_type_number_t nports)
+{
+  return ill_rpc ("S_proc_getnports_reply");
+}
+
+error_t
+S_proc_is_important_reply (mach_port_t reply, error_t err, boolean_t essential)
+{
+  return ill_rpc ("S_proc_is_important_reply");
+}
+
+error_t
+S_proc_get_code_reply (mach_port_t reply, error_t

Re: [RFC] GDB Hurd Fixes

[David Michael]

Hi,

On Fri, Sep 20, 2013 at 4:47 AM, Pedro Alves  wrote:
> On 09/20/2013 01:43 AM, David Michael wrote:
>> (Copying gdb-patches this time.)
> But, we're missing all the context on the gdb-patches@ side.

Sorry about that--here's an explanation of the problems in GDB's build
process with current Hurd:

First, mig has stopped using the "auto" keyword in its output.[1]
Without that keyword, gdb/reply_mig_hack.awk fails to match a
necessary pattern and outputs a bad gdb/process_reply_S.c file.  The
first change I made adds a new pattern to the script in addition to
the old one, so it should work with both old and new mig binaries.

Next, new function definitions were added (then renamed) in
.[2]  In the generated
gdb/process_reply_S.raw, some of the new functions match patterns in
gdb/reply_mig_hack.awk in a different order than expected, producing
bad output again.  The second change I made to the script ensures a
necessary definition is found before writing output.  (It may be
preferable to add a "parse_phase = 6" instead.)

Also because of [2], linking fails due to missing some new functions
in gdb/process_reply_S.c.  I just extended the way other unused
functions from process_reply.defs were handled previously in
gdb/gnu-nat.c.

Thanks.

David

[1] 
http://git.savannah.gnu.org/cgit/hurd/mig.git/commit/?id=b53836447df7230cd5665a7ccabd2a6e1a6607e5
[2] 
http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=e19cc6184fb99394845d56e6e915fea9805e5c28

Re: GNU/Hurd DDE talk at FOSDEM

[Michael Banck]

On January 31, 2014 6:35:44 PM CET, Samuel Thibault  
wrote:
>Emilio Pozuelo Monfort, le Fri 31 Jan 2014 12:31:39 +0100, a écrit :
>> What's the status quo of driver support in the Hurd without DDE (very
>few linux
>> old 2.0 drivers...)
>
>You mean other than network boards?  That's a usual part of my talks,
>yes :)
>
>> I look forward to watching the recorded video :-)
>
>I'm afraid there is usually no video of the microkernel room.
>
>Someone would have to bring a microphone and record it.
>
>Samuel

Hi,

I just got told that all Devrooms are being video taped this year, and there 
might even be streaming available.


Michael

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GSoC] Porting Guix to GNU/Hurd

[David Michael]

Hi,

On Tue, Mar 11, 2014 at 6:26 AM, Manolis Ragkousis  wrote:
> I am reading any available documentation or existing source that can help me
> and I would really appreciate any suggestions ,corrections or questions that
> can help me.

I'm not really a Hurd developer, but I've been cross-compiling
Hurd-from-scratch from git for a little over a year now.  Let me know
if you get stuck or just want to see some relevant code, and we can
share scripts and notes (at least for the earlier stages of your
project).

I'd be interested in using Guix on Hurd, so good luck with your project!

David

Re: [GSoC] Porting Guix to GNU/Hurd

[David Michael]

Hi,

On Wed, Mar 12, 2014 at 7:38 PM, Manolis Ragkousis  wrote:
> For now if you can point me to where I can find any relevant code you have
> available for the building procedure ,especially the part for glibc and
> libpthread, I will be grateful. :-)

I've dumped my build scripts to GitHub[0].  The rules to build
packages are under the make.pkg.d directory.  (It grew from a crazy
Makefile setup.)  The project sources used are current as of right
now.

It should be noted that I haven't had much time to research and report
build problems for the last few months, so some of my hack solutions
may not align with what the developers intended.  (For instance:
 tries to import definitions from a debug file that
doesn't get installed; I just patched it to install those debug files
for now, which may not be a desirable fix.)  Hopefully your project
mentors can help you make corrections if my bad examples lead you
astray.

Good luck.

David

[0] https://github.com/dm0-/gnuxc

Boot-time Virtualization Option

[David Michael]

Hi,

I've uploaded some notes[0] on how to patch qemu to draw to the Linux
framebuffer and stuff the resulting minimal executable into an initrd.
 Placing the initrd and Linux in a Hurd filesystem's /boot allows
adding a GRUB option to start mach in a virtual environment.

For an example usage: I have a Hurd install on a microSD card, and
this option lets me boot directly from the card on a system with
hardware unsupported by mach.  True, this doesn't do anything that
starting qemu from a complete Linux-based distro wouldn't do, but I
think it's a cute quick hack and thought I'd share.

David

[0] https://github.com/dm0-/gnuxc/blob/master/HAL.md

Re: chroot in its own ext2fs?

[Michael Banck]

Hi,

On Fri, May 02, 2014 at 02:22:01AM +0200, Samuel Thibault wrote:
> Does anybody remember precisely why chroots should have their own
> ext2fs?  I can build packages fine from inside a chroot which doesn't
> have its own ext2fs, for instance.

I don't recall why we did that, maybe it was purely for operational
reasons (offline filesystem checking of just the chroot when still had
lots of corruption) and is no longer applicable today.


Michael

[PATCH] Add mach_debug defs rules

[David Michael]

* Makeconf (mach_debug_defs_names,mach_debug_defs): New variables.
* Makeconf: Add rule to generate local $(mach_debug_defs) files.
* procfs/Makefile: Remove vpath for mach_debug defs.
---

Hi,

The hard-coded /usr/include vpath will break building with sysroot
headers.  Can the mach_debug defs files be handled like the others?

Thanks.

David

 Makeconf| 4 
 procfs/Makefile | 3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Makeconf b/Makeconf
index 5cf995d..32eec13 100644
--- a/Makeconf
+++ b/Makeconf
@@ -576,13 +576,17 @@ vpath %.defs $(top_srcdir)/hurd
 mach_defs_names = bootstrap exc mach mach4 \
mach_host mach_port mach_timer_reply memory_object \
memory_object_default notify
+mach_debug_defs_names = mach_debug
 device_defs_names = dev_forward device device_reply device_request
 
 mach_defs = $(addsuffix .defs,$(mach_defs_names))
+mach_debug_defs = $(addsuffix .defs,$(mach_debug_defs_names))
 device_defs = $(addsuffix .defs,$(device_defs_names))
 
 $(mach_defs): %.defs:
echo '#include ' > $@
+$(mach_debug_defs): %.defs:
+   echo '#include ' > $@
 $(device_defs): %.defs:
echo '#include ' > $@
 
diff --git a/procfs/Makefile b/procfs/Makefile
index 6d7ca48..78f20c4 100644
--- a/procfs/Makefile
+++ b/procfs/Makefile
@@ -28,7 +28,4 @@ OBJS = $(SRCS:.c=.o)
 HURDLIBS = netfs fshelp iohelp ps ports ihash shouldbeinlibc
 OTHERLIBS = -lpthread
 
-# Where to find .defs files.
-vpath %.defs /usr/include/mach_debug
-
 include ../Makeconf
-- 
1.9.3

[PATCH] sutils: add random device targets to MAKEDEV

[David Michael]

* sutils/MAKEDEV.sh (random,urandom): New targets.
(std): Add random and urandom to the standard devices list.
---

Hi,

With the random merge, can /dev/(u)random devices now be added to
MAKEDEV?  (I'm not married to the seed file argument, in case there
is a better default location for it.)

Thanks.

David

 sutils/MAKEDEV.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sutils/MAKEDEV.sh b/sutils/MAKEDEV.sh
index 0a8f514..db98353 100644
--- a/sutils/MAKEDEV.sh
+++ b/sutils/MAKEDEV.sh
@@ -100,7 +100,7 @@ mkdev() {
;;
 
   std)
-   mkdev console tty null zero full fd time mem klog shm
+   mkdev console tty null zero random urandom full fd time mem klog shm
;;
   console|com[0-9])
st $I root 600 /hurd/term ${DEVDIR}/$I device $I;;
@@ -117,6 +117,10 @@ mkdev() {
st $I root 666 /hurd/null --full;;
   zero)
st $I root 666 /bin/nullauth -- /hurd/storeio -Tzero;;
+  random)
+   st $I root 644 /hurd/random --secure --seed-file /var/lib/random-seed;;
+  urandom)
+   st $I root 644 /hurd/random --fast --seed-file /var/lib/random-seed;;
   tty)
st $I root 666 /hurd/magic tty;;
   fd)
-- 
1.9.3

Re: [PATCH] sutils: add random device targets to MAKEDEV

[David Michael]

Hi,

On Tue, Jun 17, 2014 at 12:33 PM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting David Michael (2014-06-16 21:08:19)
>> (I'm not married to the seed file argument, in case there is a
>> better default location for it.)
>
> For the record, Debian uses /var/spool/random-seed.

The seed file was stored in various locations on different
systems--/var/spool/ in Debian, /var/lib/ in RHEL, /var/run/ in
random(4), /var/lib/systemd/ in most distros these days--so I just
picked the one closest to my interpretation of the FHS.  (I actually
think /var/lib/misc/ is the most FHS-compliant location in this case
but found no precedence for systems using it after a cursory look.)
I'd be happy to go with the Debian location, too, if upstream Hurd is
to follow those conventions.

>> +  random)
>> +   st $I root 644 /hurd/random --secure --seed-file 
>> /var/lib/random-seed;;
>
> But --secure doesn't seem to work yet, aiui we lack entropy sources.
> The Debian package however contains a patch to make --fast the
> default.  You could drop --secure, as it is the default in the stock
> sources, and will be in the Debian package once this issue is
> addressed.

Okay, thanks.  I saw that /dev/random used the default level on Debian
Hurd, but I didn't notice it was patched away from --secure.

Perhaps it would be best to hold off on applying this if /dev/random
won't have entropy behind it.

Thanks.

David

Re: [PATCH 3/3] i386: use ACPI to power off the machine

[David Michael]

Hi,

On Sat, May 3, 2014 at 4:56 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> However, when I use --enable-device-drivers=qemu it doesn't work:
>
> db> halt
> Looking for RSDP. Scanning EBDA
> Looking for RSDP. Scanning EBDA
> rsdp1=0
>
> Hum.  Maybe someone overwrote our precious EBDA table (whatever that
> is).  It's supposed to be around physical address 0x40e.  See acpi.c
> for the code looking for the RSDP.

It seems to work when acpi.c is patched to use the "Scanning BIOS"
sections if it can't get the EDBA length.  Changing "if (! ebda_len)
return 0;" to just "if (edba_len)" does the trick, making the first
loop conditional instead of calling off the search.

Thanks.

David

[PATCH] acpi: always scan the BIOS region if searching the EBDA fails

[David Michael]

---
This can be applied on top of the ACPI halt patches from Justus to test
powering off QEMU systems.

 i386/i386at/acpi.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/i386/i386at/acpi.c b/i386/i386at/acpi.c
index ec8aeb1..488aa6d 100644
--- a/i386/i386at/acpi.c
+++ b/i386/i386at/acpi.c
@@ -30,13 +30,12 @@ grub_machine_acpi_get_rsdpv1 (void)
   grub_dprintf ("acpi", "Looking for RSDP. Scanning EBDA\n");
   ebda = (grub_uint8_t *) phystokv ((* ((grub_uint16_t *) phystokv (0x40e))) 
<< 4);
   ebda_len = * (grub_uint16_t *) ebda;
-  if (! ebda_len)
-return 0;
-  for (ptr = ebda; ptr < ebda + 0x400; ptr += 16)
-if (grub_memcmp (ptr, GRUB_RSDP_SIGNATURE, GRUB_RSDP_SIGNATURE_SIZE) == 0
-   && grub_byte_checksum (ptr, sizeof (struct grub_acpi_rsdp_v10)) == 0
-   && ((struct grub_acpi_rsdp_v10 *) ptr)->revision == 0)
-  return (struct grub_acpi_rsdp_v10 *) ptr;
+  if (ebda_len)
+for (ptr = ebda; ptr < ebda + 0x400; ptr += 16)
+  if (grub_memcmp (ptr, GRUB_RSDP_SIGNATURE, GRUB_RSDP_SIGNATURE_SIZE) == 0
+ && grub_byte_checksum (ptr, sizeof (struct grub_acpi_rsdp_v10)) == 0
+ && ((struct grub_acpi_rsdp_v10 *) ptr)->revision == 0)
+   return (struct grub_acpi_rsdp_v10 *) ptr;
 
   grub_dprintf ("acpi", "Looking for RSDP. Scanning BIOS\n");
   for (ptr = (grub_uint8_t *) phystokv (0xe); ptr < (grub_uint8_t *) 
phystokv (0x10);
@@ -57,16 +56,14 @@ grub_machine_acpi_get_rsdpv2 (void)
   grub_dprintf ("acpi", "Looking for RSDP. Scanning EBDA\n");
   ebda = (grub_uint8_t *) phystokv ((* ((grub_uint16_t *) phystokv (0x40e))) 
<< 4);
   ebda_len = * (grub_uint16_t *) ebda;
-  if (! ebda_len)
-return 0;
-  for (ptr = ebda; ptr < ebda + 0x400; ptr += 16)
-if (grub_memcmp (ptr, GRUB_RSDP_SIGNATURE, GRUB_RSDP_SIGNATURE_SIZE) == 0
-   && grub_byte_checksum (ptr, sizeof (struct grub_acpi_rsdp_v10)) == 0
-   && ((struct grub_acpi_rsdp_v10 *) ptr)->revision != 0
-   && ((struct grub_acpi_rsdp_v20 *) ptr)->length < 1024
-   && grub_byte_checksum (ptr, ((struct grub_acpi_rsdp_v20 *) ptr)->length)
-   == 0)
-  return (struct grub_acpi_rsdp_v20 *) ptr;
+  if (ebda_len)
+for (ptr = ebda; ptr < ebda + 0x400; ptr += 16)
+  if (grub_memcmp (ptr, GRUB_RSDP_SIGNATURE, GRUB_RSDP_SIGNATURE_SIZE) == 0
+ && grub_byte_checksum (ptr, sizeof (struct grub_acpi_rsdp_v10)) == 0
+ && ((struct grub_acpi_rsdp_v10 *) ptr)->revision != 0
+ && ((struct grub_acpi_rsdp_v20 *) ptr)->length < 1024
+ && grub_byte_checksum (ptr, ((struct grub_acpi_rsdp_v20 *) 
ptr)->length) == 0)
+   return (struct grub_acpi_rsdp_v20 *) ptr;
 
   grub_dprintf ("acpi", "Looking for RSDP. Scanning BIOS\n");
   for (ptr = (grub_uint8_t *) phystokv (0xe); ptr < (grub_uint8_t *) 
phystokv (0x10);
-- 
1.9.3

Re: [PATCH 3/3] i386: use ACPI to power off the machine

[David Michael]

On Tue, Jul 1, 2014 at 5:23 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting David Michael (2014-06-23 00:31:57)
>> Hi,
>>
>> On Sat, May 3, 2014 at 4:56 AM, Justus Winter
>> <4win...@informatik.uni-hamburg.de> wrote:
>> > However, when I use --enable-device-drivers=qemu it doesn't work:
>> >
>> > db> halt
>> > Looking for RSDP. Scanning EBDA
>> > Looking for RSDP. Scanning EBDA
>> > rsdp1=0
>> >
>> > Hum.  Maybe someone overwrote our precious EBDA table (whatever that
>> > is).  It's supposed to be around physical address 0x40e.  See acpi.c
>> > for the code looking for the RSDP.
>>
>> It seems to work when acpi.c is patched to use the "Scanning BIOS"
>> sections if it can't get the EDBA length.  Changing "if (! ebda_len)
>> return 0;" to just "if (edba_len)" does the trick, making the first
>> loop conditional instead of calling off the search.
>
> If you can get it to work, then by all means, please do it :)

I've sent a patch that makes the described change, and I've been using
it with QEMU for a week or two without issues so far.

Thanks for working on this functionality; it's really useful.

David

[PATCH] console-client: Exit on SIGTERM

[David Michael]

* console-client/console.c: Include signal.h.
(signal_handler): New function.
(main): Register signal_handler to trap SIGTERM.
---

Hi,

I've been fiddling with running the console client as a system service
so it can be started and stopped with, e.g., "deco stop console" or
"service console start".

Could it have a signal handler added so the client exits cleanly on the
SIGTERM from these stop commands?  It seems to lock up the display
without this.

Thanks.

David

 console-client/console.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/console-client/console.c b/console-client/console.c
index 2fa0533..4035ebf 100644
--- a/console-client/console.c
+++ b/console-client/console.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,6 +291,14 @@ console_exit (void)
   exit (0);
 }
 
+/* Exit the console client on SIGTERM. */
+static void
+signal_handler (int signum)
+{
+  if (signum == SIGTERM)
+console_exit ();
+}
+
 /* Signal an error to the user.  */
 void console_error (const wchar_t *const err_msg)
 {
@@ -744,6 +753,9 @@ main (int argc, char *argv[])
   if (console_node)
 console_setup_node (console_node);
 
+  if (signal (SIGTERM, signal_handler) == SIG_ERR)
+daemon_error (1, errno, "Could not register a SIGTERM handler");
+
 #if HAVE_DAEMON
   if (daemonize)
 /* Signal parent that all went well.  */
-- 
1.9.3

Re: [PATCH] console-client: Exit on SIGTERM

[David Michael]

On Thu, Jul 17, 2014 at 12:40 PM, Samuel Thibault
 wrote:
> David Michael, le Wed 16 Jul 2014 21:56:36 -0400, a écrit :
>> +/* Exit the console client on SIGTERM. */
>> +static void
>> +signal_handler (int signum)
>> +{
>> +  if (signum == SIGTERM)
>> +console_exit ();
>> +}
>
> We can't just call console_exit() in the middle of the signal handler:
> SIGTERM could very well happen while driver_list_lock is taken,
> driver_fini would then deadlock.  The signal handler should rather make
> the cons_server_loop function return.

Okay, thanks for the information.  I'll try to figure that out and
resend at some point.  Or if anyone else knows how to do it that way
offhand and is up for writing it, I'd be grateful.

David

[PATCH] mig: Drop the Perl runtime dependency

[David Michael]

* mig.in (libexecdir_rel): Compute with realpath instead of perl.
---

Hi,

I tried running mig on a system without Perl ealier with bad results.
Perl seems to be used only for functionality that is also provided by
GNU coreutils (which is already required, e.g. for dirname).  Does it
make sense to drop the Perl command in favor of using realpath here?

Thanks.

David

 mig.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mig.in b/mig.in
index 63e0269..16a9cf2 100644
--- a/mig.in
+++ b/mig.in
@@ -29,7 +29,7 @@ prefix=@prefix@
 exec_prefix=@exec_prefix@
 bindir=@bindir@
 libexecdir=@libexecdir@
-libexecdir_rel=$(perl -MFile::Spec -e 'print 
File::Spec->abs2rel("'"$libexecdir"'","'"$bindir"'")')
+libexecdir_rel=$(realpath --relative-to="$bindir" "$libexecdir")
 bindir_real=$(dirname "$0")
 bindir_real=$(cd "$bindir_real"/ && pwd)
 libexecdir=$bindir_real/$libexecdir_rel
-- 
1.9.3

Re: [PATCH] mig: Drop the Perl runtime dependency

[David Michael]

Hi,

On Tue, Jul 22, 2014 at 9:12 AM, Thomas Schwinge
 wrote:
> Hi!
>
> On Fri, 18 Jul 2014 19:29:07 -0400, David Michael  
> wrote:
>> I tried running mig on a system without Perl ealier with bad results.
>> Perl seems to be used only for functionality that is also provided by
>> GNU coreutils (which is already required, e.g. for dirname).  Does it
>> make sense to drop the Perl command in favor of using realpath here?
>
>> -libexecdir_rel=$(perl -MFile::Spec -e 'print 
>> File::Spec->abs2rel("'"$libexecdir"'","'"$bindir"'")')
>> +libexecdir_rel=$(realpath --relative-to="$bindir" "$libexecdir")
>
> Thanks for the patch, and I'd be happy to apply that, however, on four
> arbitrary (Debian, Ubuntu, Trisquel) systems that I just tried, I either
> see: »realpath: unrecognized option '--relative-to'«, or »bash: realpath:
> command not found«, whereas the Perl variant works on all of these.

Okay, I didn't realize that it had only been two or three years since
a coreutils release first included this functionality.  Sorry for the
noise.

David

Re: [PATCH 8/8] startup: bind the startup server to /servers/startup

[David Michael]

Hi,

On Wed, Sep 3, 2014 at 8:33 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Bind the startup server to /servers/startup instead.  Use this to
> contact the startup server.

I'm trying to test this patch, and glibc appears to need an update as
well.  Does this look okay?

Thanks.

David


diff --git a/sysdeps/mach/hurd/reboot.c b/sysdeps/mach/hurd/reboot.c
index 60d96ea..51c3d73 100644
--- a/sysdeps/mach/hurd/reboot.c
+++ b/sysdeps/mach/hurd/reboot.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -33,8 +34,8 @@ reboot (int howto)
   if (err)
 return __hurd_fail (EPERM);

-  err = __USEPORT (PROC, __proc_getmsgport (port, 1, &init));
-  if (!err)
+  init = __file_name_lookup (_SERVERS_STARTUP, 0, 0);
+  if (init != MACH_PORT_NULL)
 {
   err = __startup_reboot (init, hostpriv, howto);
   __mach_port_deallocate (__mach_task_self (), init);

Re: [PATCH] Update NEWS file

[David Michael]

On Wed, Sep 24, 2014 at 6:37 PM, Samuel Thibault
 wrote:
> Ack.
>
> Justus Winter, le Wed 24 Sep 2014 15:05:06 +0200, a écrit :
>> ---
>>  NEWS | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/NEWS b/NEWS
>> index 72a2e2d..b047aed 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -1,3 +1,25 @@
>> +2013-XX-XX
>> +Version 0.6
>> +
>> +Numerous cleanups and stylistic fixes of the code base.  Several
>> +problems have been identified using static analysis and exercising
>> +tools, and have subsequently been fixed.
>> +
>> +The message dispatching code in the Hurd servers has been improved.
>> +
>> +The embedded gz and bz2 decompressor code has been removed, libz and
>> +libbz2 is used instead.
>> +
>> +The native fakeroot tool has been greatly improved and is now able to
>> +build many packages.  The portinfo and rpctrace tools now offer a
>> +better debugging experience.
>> +
>> +The performance of the integer hashing library has been improved.
>> +
>> +The procfs translator has been merged.
>> +
>> +The random translator has been merged.
>> +
>>  2013-09-27
>>  Version 0.5

Assuming it's not too late already, do you think the patches to split
the startup server from the init process could make it into this
release?

The ability to easily swap out the init program would be a good
selling point for the release, in my opinion.  I've been using the
patches to run GNU dmd as PID 1, and it seems to be working nicely.
The only issue so far is that the changes call
/etc/hurd/runsystem.hurd by default, and that file isn't getting
installed.

Thanks.

David

Re: HELP : Error while building gnumach

[David Michael]

On Mon, Oct 13, 2014 at 1:57 AM, Thomas Schwinge
 wrote:
> Hi!
>
> On Sun, 12 Oct 2014 23:35:41 +0530, vibi sreenivasan  
> wrote:
>> I am trying to build gnumach from git repo as per the instructions in
>> https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html
>
>> [...]
>> checking for i686-unknown-linux-gnu-mig... no
>> checking for mig... no
>> configure: error: The MiG generator is required to build GNU Mach
>>
>>
>> But link says that after configure, we have to install headers & then
>> compile mig.
>>
>> Please let me know what  i am doing wrong.
>
> This is due to:
>
> commit b28e05e203e0739fa5db59c5af378b29eea7a232
> Author: Samuel Thibault 
> Date:   Fri Apr 25 20:39:23 2014 +0200
>
> Make sure mig is available
>
> * configure.ac (MIG): Error out if MiG was not found.
>
> We either have to update the instructions (first configure with »MIG=:«
> (untested), then have to re-configure once MIG has been built), or revert
> that commit.

I've been using this configure command to install headers:

./configure CC='i686-pc-gnu-gcc -nostdlib' MIG=i686-pc-gnu-mig ...

The configure script tries and fails to create executables before
glibc is built, hence the "-nostdlib".  It seems to be hard-coded to
abort if MIG=:, but it doesn't look like it uses its value otherwise
for installing the headers.

Thanks.

David

Re: Problem with reinstallation, bootloader

[Michael Banck]

On Tue, Nov 11, 2014 at 10:37:21AM +0100, Riccardo Mottola wrote:
> How can I get from HURD something similar to DMESG or lspci? Right
> now I don't have any other OSs, thus I can easily list all hardware
> Richard B. asked for! Otherwise I'll burn some kind of LiveCD.

IMO, it's generally a good idea to have a grml live-cd (or bootable
usb-stick) handy: http://grml.org/


Michael

[PATCH gnumach] Correct GCC's -Wformat-security issues

[David Michael]

* linux/pcmcia-cs/clients/axnet_cs.c (axdev_init): Add a format string
literal where printk only has a single variable argument.
* linux/src/drivers/net/3c507.c (el16_probe1): Likewise.
* linux/src/drivers/net/3c509.c (el3_probe): Likewise.
* linux/src/drivers/net/3c515.c (init_module): Likewise.
(tc515_probe): Likewise.
* linux/src/drivers/net/ac3200.c (ac_probe1): Likewise.
* linux/src/drivers/net/apricot.c (apricot_probe): Likewise.
* linux/src/drivers/net/at1700.c (at1700_probe1): Likewise.
* linux/src/drivers/net/de4x5.c (de4x5_hw_init): Likewise.
* linux/src/drivers/net/de600.c (de600_probe): Likewise.
* linux/src/drivers/net/de620.c (de620_probe): Likewise.
* linux/src/drivers/net/depca.c (depca_hw_init): Likewise.
* linux/src/drivers/net/e2100.c (e21_probe1): Likewise.
* linux/src/drivers/net/eepro.c (eepro_probe1): Likewise.
* linux/src/drivers/net/eepro100.c (speedo_found1): Likewise.
* linux/src/drivers/net/eexpress.c (eexp_hw_probe): Likewise.
* linux/src/drivers/net/ewrk3.c (ewrk3_hw_init): Likewise.
* linux/src/drivers/net/fmv18x.c (fmv18x_probe1): Likewise.
* linux/src/drivers/net/hp-plus.c (hpp_probe1): Likewise.
* linux/src/drivers/net/hp.c (hp_probe1): Likewise.
* linux/src/drivers/net/lance.c (lance_probe1): Likewise.
* linux/src/drivers/net/ne.c (ne_probe1): Likewise.
* linux/src/drivers/net/pcnet32.c (pcnet32_probe1): Likewise.
* linux/src/drivers/net/seeq8005.c (seeq8005_probe1): Likewise.
* linux/src/drivers/net/smc-ultra.c (ultra_probe1): Likewise.
* linux/src/drivers/net/smc-ultra32.c (ultra32_probe1): Likewise.
* linux/src/drivers/net/wd.c (wd_probe1): Likewise.
---

Hi,

I tried building on the Fedora 21 beta, and -Werror=format-security is
now in the default CFLAGS.  It gets hung up on a few files in the
included Linux drivers, so this is a quick patch to remedy those
issues.  It's basically just s/printk(version/printk("%s", version/.
Appending -Wno-error=format-security to CFLAGS works, so this isn't
really important, but it would be nice to have.

Thanks.

David

 linux/pcmcia-cs/clients/axnet_cs.c  | 2 +-
 linux/src/drivers/net/3c507.c   | 4 ++--
 linux/src/drivers/net/3c509.c   | 2 +-
 linux/src/drivers/net/3c515.c   | 4 ++--
 linux/src/drivers/net/ac3200.c  | 2 +-
 linux/src/drivers/net/apricot.c | 2 +-
 linux/src/drivers/net/at1700.c  | 2 +-
 linux/src/drivers/net/de4x5.c   | 2 +-
 linux/src/drivers/net/de600.c   | 2 +-
 linux/src/drivers/net/de620.c   | 2 +-
 linux/src/drivers/net/depca.c   | 2 +-
 linux/src/drivers/net/e2100.c   | 2 +-
 linux/src/drivers/net/eepro.c   | 2 +-
 linux/src/drivers/net/eepro100.c| 2 +-
 linux/src/drivers/net/eexpress.c| 2 +-
 linux/src/drivers/net/ewrk3.c   | 2 +-
 linux/src/drivers/net/fmv18x.c  | 2 +-
 linux/src/drivers/net/hp-plus.c | 2 +-
 linux/src/drivers/net/hp.c  | 2 +-
 linux/src/drivers/net/lance.c   | 2 +-
 linux/src/drivers/net/ne.c  | 2 +-
 linux/src/drivers/net/pcnet32.c | 2 +-
 linux/src/drivers/net/seeq8005.c| 2 +-
 linux/src/drivers/net/smc-ultra.c   | 2 +-
 linux/src/drivers/net/smc-ultra32.c | 2 +-
 linux/src/drivers/net/wd.c  | 2 +-
 26 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/linux/pcmcia-cs/clients/axnet_cs.c 
b/linux/pcmcia-cs/clients/axnet_cs.c
index bcd79b0..2e7d9ed 100644
--- a/linux/pcmcia-cs/clients/axnet_cs.c
+++ b/linux/pcmcia-cs/clients/axnet_cs.c
@@ -1814,7 +1814,7 @@ static void set_multicast_list(struct net_device *dev)
 static int axdev_init(struct net_device *dev)
 {
if (ei_debug > 1)
-   printk(version_8390);
+   printk("%s", version_8390);
 
if (dev->priv == NULL) 
{
diff --git a/linux/src/drivers/net/3c507.c b/linux/src/drivers/net/3c507.c
index 63f85a4..58ba2d7 100644
--- a/linux/src/drivers/net/3c507.c
+++ b/linux/src/drivers/net/3c507.c
@@ -354,7 +354,7 @@ int el16_probe1(struct device *dev, int ioaddr)
dev = init_etherdev(0, sizeof(struct net_local));
 
if (net_debug  &&  version_printed++ == 0)
-   printk(version);
+   printk("%s", version);
 
printk("%s: 3c507 at %#x,", dev->name, ioaddr);
 
@@ -410,7 +410,7 @@ int el16_probe1(struct device *dev, int ioaddr)
   dev->if_port ? "ex" : "in", dev->mem_start, dev->mem_end-1);
 
if (net_debug)
-   printk(version);
+   printk("%s", version);
 
/* Initialize the device structure. */
dev->priv = kmalloc(sizeof(struct net_local), GFP_KERNEL);
diff --git a/linux/src/drivers/net/3c509.c b/linux/src/drivers/net/3c509.c
index f884288..727595c 100644
--- a/linux/src/drivers/net/3c509.c
+++ b/linux/src/drivers/net/3c509.c
@@ -314,7 +314,7 @@ int el3_probe(struct device *dev)
el3_root_dev = dev;
 
if (el3_debug > 0)
-   printk(version);
+   printk("%s", version);
 
/* The EL3-specific entries in the device structure. */

Re: Release process & rolling new releases

[David Michael]

On Wed, Nov 19, 2014 at 6:59 PM, Samuel Thibault
 wrote:
> Justus Winter, le Mon 17 Nov 2014 16:30:18 +0100, a écrit :
>> It has now been 2.5 months since I posted that startup patch series,
>> and 2 months since I suggested rolling new releases.
>>
>> I'm annoyed.
>
> I understand this feeling.  I'm still waiting (since several years)
> for some patch series to get reviewed by qemu maintainers, and one
> patch to get at last accepted in linux' input layer.  I'm quite sad I'm
> now in the "blocker" position, mostly due to having still hundreds of
> important mails to process in my mbox, and thus having to delay what
> is not strictly for "tomorrow" or "next week"...  And I prioritized
> uploading your work on libdiskfs threads so people can benefit from it,
> rather than reviewing the startup patch series.
>
> I'm however wondering: I don't see much reviewing being done apart
> from mine.  It would help if some people could spend time on reviewing
> patches.  I'm not saying taking responsibility for the commit step or
> anything, but just proofreading the source code.  That is what takes
> time before committing, and thus what prevents me from giving an ack on
> something for which I already agree on the principle...

I might not be able to do a very thorough review, but for what it's
worth, I've been using the startup patches for a while now without any
problems.  The only issue was that /etc/hurd/runsystem.hurd didn't get
installed.  I tacked the following onto patch #4 in the series to try
it.

David


--- a/daemons/Makefile
+++ b/daemons/Makefile
@@ -32,6 +32,7 @@
 getty-LDLIBS = -lutil

 INSTALL-mail.local-ops = -o root -m 4755
+INSTALL-runsystem.hurd-ops = -m 0755

 include ../Makeconf

@@ -44,3 +45,9 @@
 runttys-LDLIBS = -lutil

 runsystem: runsystem.sh
+
+install: $(sysconfdir)/hurd/runsystem.hurd
+$(sysconfdir)/hurd/runsystem.hurd: runsystem.hurd | $(sysconfdir)/hurd
+$(INSTALL_PROGRAM) $(INSTALL-runsystem.hurd-ops) $< $@
+$(sysconfdir)/hurd: | $(sysconfdir)
+mkdir -p $@

Re: Release process & rolling new releases

[David Michael]

On Sun, Nov 23, 2014 at 4:01 PM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Samuel Thibault (2014-11-23 21:11:05)
>> Hello,
>>
>> David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit :
>> > The only issue was that /etc/hurd/runsystem.hurd didn't get installed.
>> > I tacked the following onto patch #4 in the series to try it.
>>
>> Justus, do we need it?
>
> I guess it cannot hurt to install it.  I have no strong feelings
> either way.  The way I see it is:
>
> There is just one Hurd distribution, Debian GNU/Hurd, and it uses
> sysvinit.  If the guix project gets their Hurd port up and running,
> and I hope they do, then they will be using dmd.
>
> I wrote the init daemon and modified the runsystem script merely to
> get the `proc_set_init_task' patch merged.  I don't expect it to be
> used.

I don't feel very strongly about it either since I'm not using it
myself (I switched to dmd), but I'd lean toward installing it by
default for upstream Hurd to make things easier for anyone else trying
to build their own Hurd system outside the usual distros.  The default
startup scripts could successfully boot a usable system before this
patch set.  But if the expectation is that now a separate init system
will be installed, I'd be okay with that, too.

David

Re: [PATCH hurd 01/28] libshouldbeinlibc: move the reference counting primitives here

[David Michael]

On Mon, Dec 1, 2014 at 10:00 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> * libshouldbeinlibc/refcount.h: Move here, and declare all functions
> `extern inline'.
> * libshouldbeinlibc/refcount.c: And define the functions here.
> * libshouldbeinlibc/Makefile: Add `refcount.{c,h}'.

Should this also remove refcount.h from include/Makefile's
installhdrs?  I'm getting random parallel make failures depending on
if "include" or "libshouldbeinlibc" installs headers first.

David

[PATCH hurd] include: don't install nonexistent refcount.h

[David Michael]

* include/Makefile (installhdrs): Remove refcount.h.
---

Hi,

Can this be fixed please?

Thanks.

David

 include/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/Makefile b/include/Makefile
index 4de165d..b8773fe 100644
--- a/include/Makefile
+++ b/include/Makefile
@@ -22,7 +22,7 @@
 dir := include
 makemode := misc
 
-installhdrs := sys/procfs.h refcount.h
+installhdrs := sys/procfs.h
 
 include ../Makeconf
 
-- 
1.9.3

Re: [PATCH hurd 27/30] hurd: add intranpayload functions to all hurd types

[David Michael]

Hi,

On Thu, Nov 27, 2014 at 8:19 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> +#ifdef HURD_DEFAULT_PAYLOAD_TO_PORT
> +#if HURD_DEFAULT_PAYLOAD_TO_PORT
> +/* Any non-numeric value will fail this test.  If 1 (or any number) is
> +   given, do not inject the default translator function.  */
> +#undef HURD_DEFAULT_PAYLOAD_TO_PORT
> +#endif
> +#else
> +   import ;
> +#define HURD_DEFAULT_PAYLOAD_TO_PORT ports_payload_get_name
> +#endif

My glibc builds are failing, and I think it's because of this
inclusion of  in hurd_types.defs.

Anything that includes  now gets  (via
the freshly output ), which includes other files that
require , but they aren't getting any of its
definitions since _HURD_SIGNAL_H is already defined.

Do you have any suggestions to work around this?

Thanks.

David

Re: [PATCH hurd 3/5] proc: implement `proc_make_task_namespace'

[David Michael]

Hi,

On Thu, Nov 13, 2014 at 7:26 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> @@ -1008,9 +1069,42 @@ S_mach_notify_new_task (mach_port_t notify,
>childp = new_proc (task);
>  }
>
> -  /* XXX do something interesting */
> +  if (MACH_PORT_VALID (parentp->p_task_namespace))
> +{
> +  error_t err;
> +  /* Tasks in a task namespace are not expected to call
> +proc_child, so we do it on their behalf.  */
> +  mach_port_mod_refs (mach_task_self (), task, MACH_PORT_RIGHT_SEND, +1);
> +  err = S_proc_child (parentp, task);
> +  if (! err)
> +   /* Relay the notification.  This consumes TASK and PARENT.  */
> +   return mach_notify_new_task (childp->p_task_namespace, task, parent);
> +}
>
>mach_port_deallocate (mach_task_self (), task);
>mach_port_deallocate (mach_task_self (), parent);

This mach_notify_new_task call in proc/mgt.c seems to be causing a
linker error.  I added task_notifyUser.o to MIGSTUBS to get around it.
Is that correct?

Thanks.

David

Scripts to build a Hurd distro

[David Michael]

Hi,

I've uploaded updates to my Hurd build scripts for Fedora 21, so I
thought I'd send a note about it in case it helps anyone else out there
who is interested in building Hurd outside Debian.  (The project has
actually bloated into a fairly complete distro itself at this point.)
It can be downloaded from https://github.com/dm0-/gnuxc .  Here are some
nifty things it can do:

* It runs GNU dmd as PID 1, with service definitions like mcron, lsh,
  syslog, and the Hurd console client.

* It includes a Linux-libre kernel with a statically linked QEMU so that
  it is still possible to boot Hurd virtually on machines with
  unsupported hardware.  (I use this for a Live CD type of setup and EFI
  booting.)

* It has a Guile/Make file to bootstrap and build all the cross-compiler
  RPMs in parallel with proper dependency tracking.

* It can use your CPU to heat your home or office.

An old dual-core MacBook Air takes about four hours to build the entire
OS and cross-compilers from scratch (including the huge packages like
IceCat), e.g. with "time (make -f setup-sysroot.scm -j8 && gmake -j8)".
It builds faster on systems with more CPU cores due to parallelizing
everything.

This is still mostly a learning experience for myself with a lot of
things I have yet to correct, so it should be considered far from
stable.  Nevertheless, you might find something useful in there.

Happy hacking.

David

Re: Scripts to build a Hurd distro

[David Michael]

Hi,

On Thu, Jan 8, 2015 at 7:59 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Hi David :)
>
> Quoting David Michael (2015-01-04 23:40:03)
>> I've uploaded updates to my Hurd build scripts for Fedora 21, so I
>> thought I'd send a note about it in case it helps anyone else out there
>> who is interested in building Hurd outside Debian.  (The project has
>> actually bloated into a fairly complete distro itself at this point.)
>> It can be downloaded from https://github.com/dm0-/gnuxc .  Here are some
>> nifty things it can do:
>>
>> * It runs GNU dmd as PID 1, with service definitions like mcron, lsh,
>>   syslog, and the Hurd console client.
>>
>> * It has a Guile/Make file to bootstrap and build all the cross-compiler
>>   RPMs in parallel with proper dependency tracking.
>>
>> * It can use your CPU to heat your home or office.
>
> Most impressive!
>
> For someone who isn't a Fedora user, is there an image I can download
> and just boot to play around with?  Also, do you hang out with the
> Guix people?  If not, you should ;).  Also, are you in #hurd?

Sorry, I don't have a clean image ready for distribution at the
moment.  Maybe I could build one and upload it somewhere over the
weekend.

I don't tend to use IRC on any regular basis, and although I follow
Guix development, I'm not really involved.

>> * It includes a Linux-libre kernel with a statically linked QEMU so that
>>   it is still possible to boot Hurd virtually on machines with
>>   unsupported hardware.  (I use this for a Live CD type of setup and EFI
>>   booting.)
>
> Heh, nice hack.  Note though that for the Hurd, booting from a CD
> isn't much different than booting from a hard drive.  grub-mkrescue
> creates bootable cd/hd/usb images, from there on it's just a matter of
> bootstrapping the Hurd the same way it is done for a normal
> installation.  Of course then you have iso9660fs as rootfs, which is
> readonly, which causes problems for the "userland" bootstrap.

Thanks, I'll have to look into grub-mkrescue for booting options.

Linux-libre here is useful beyond just booting, though, like for cases
where I boot a Hurd SD card on a machine that relies on a USB3 network
adapter which only even had a Linux driver for a year or two.  QEMU
can present Hurd with a boring old rtl8139 NIC that it knows how to
use, so networking is still functional.  In this case, Linux-libre is
basically just the world's most inefficient hardware abstraction
layer.

Usable read-only root is also something I'd like to have eventually.
The build system currently puts tmpfs translators on /tmp and some
/var directories with a dumb script a la systemd-tmpfiles, but this
approach is not very complete at this point.

Thanks.

David

Re: Scripts to build a Hurd distro

[David Michael]

On Thu, Jan 8, 2015 at 5:56 PM, David Michael  wrote:
> Sorry, I don't have a clean image ready for distribution at the
> moment.  Maybe I could build one and upload it somewhere over the
> weekend.

I've uploaded a disk image and screenshots here: http://dm0.me/projects/gnuxc/

David

Re: Scripts to build a Hurd distro

[David Michael]

On Tue, Jan 13, 2015 at 5:16 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> * When I tried the QEMU-based mode, I couldn't see the guests GRUB, it
>   looks like qemu was run with -curses saying `XXX graphical mode'.

The included QEMU is patched to draw directly to the Linux
framebuffer, and it falls back to "-display curses" to give a text
console if the graphics device isn't supported.  Graphical displays
should work with i915, radeon, nouveau, and qxl drivers, so you can
add "-vga qxl" if you're testing in QEMU.

The "graphical mode" screen was probably the GRUB menu.  I'll make
GRUB detect the "-display curses" fallback and use a VGA text menu for
the next update.

> * I wonder why your image is that big.  `df' says that 4G are used,
>   that sounds like a lot.  Also, why doesn't `df' show the root
>   filesystem when invoked without parameters?  Funny.  Also, use
>   `zerofree' before compressing and distributing an image.

I think the image size is mostly due to IceCat (and everything else)
being built for development and debugging.  Disk usage and build times
nearly doubled when I added IceCat.  It has two directories in
/usr/lib at almost a gigabyte each.

Aside from a handful of native compiles, everything was installed to a
zero-filled raw image, but I'll try zerofree and maybe replace the
image if it helps compression.

I've also noticed the other issues you mentioned, but they haven't
gotten priority yet.  I'll continue poking at the system and hopefully
get around to them.

Thanks for checking it out.

David

Re: HURD and a Laptop

[Michael Banck]

On Thu, Jan 22, 2015 at 06:34:44PM +0100, Samuel Thibault wrote:
> There are wireless tools on debian-ports.  I don't know the details.

I guess they are about 10 years old by now.

Even back then, they did not work very well, as I recall.


Michael

Re: [PATCH 8/8] startup: bind the startup server to /servers/startup

[David Michael]

On Tue, Jan 27, 2015 at 6:35 PM, Samuel Thibault
 wrote:
> Justus Winter, le Fri 16 Jan 2015 11:15:37 +0100, a écrit :
>> Quoting David Michael (2014-09-18 23:14:17)
>> > On Wed, Sep 3, 2014 at 8:33 AM, Justus Winter
>> > <4win...@informatik.uni-hamburg.de> wrote:
>> > > Bind the startup server to /servers/startup instead.  Use this to
>> > > contact the startup server.
>> >
>> > I'm trying to test this patch, and glibc appears to need an update as
>> > well.  Does this look okay?
>>
>> Please apply this patch to the Debian libc.
>
> I uploaded it to debian-ports the other day.  But as Ludo mentioned, we
> need to push patches upstream too.

I can try creating a proper patch and submitting it upstream over the
weekend, unless someone else is already planning to do so.

Thanks.

David

[PATCH] hurd: Get a startup server port from a file instead of a PID

[David Michael]

To allow easier implementation of different init systems, Hurd no
longer requires PID 1 to speak the startup protocol.  Ports to the
startup server are now obtained from /servers/startup instead.
---

Hi,

This patch has been included in Hurd's glibc branch and Debian's libc
for a while, and we'd like to have it applied upstream.

I haven't submitted copyright assignment papers for glibc, but I don't
believe this change is legally significant.  Let me know if I need to
take care of copyright assignment for this.

Thanks.

David

 ChangeLog  | 6 ++
 sysdeps/mach/hurd/reboot.c | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 50e8153..9b0b580 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-02-01  David Michael  
+
+   * sysdeps/mach/hurd/reboot.c: Include .
+   (reboot): Look up the file _SERVERS_STARTUP instead of PID 1 to get a
+   port to the startup server.
+
 2015-01-31  David S. Miller  
 
* sysdeps/sparc/sparc32/bits/atomic.h
diff --git a/sysdeps/mach/hurd/reboot.c b/sysdeps/mach/hurd/reboot.c
index 654745b..cb59a2b 100644
--- a/sysdeps/mach/hurd/reboot.c
+++ b/sysdeps/mach/hurd/reboot.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -33,8 +34,8 @@ reboot (int howto)
   if (err)
 return __hurd_fail (EPERM);
 
-  err = __USEPORT (PROC, __proc_getmsgport (port, 1, &init));
-  if (!err)
+  init = __file_name_lookup (_SERVERS_STARTUP, 0, 0);
+  if (init != MACH_PORT_NULL)
 {
   err = __startup_reboot (init, hostpriv, howto);
   __mach_port_deallocate (__mach_task_self (), init);
-- 
2.1.0