GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)
[Taking this to bug-hurd@gnu.org.] Hello! On Wed, Mar 21, 2007 at 08:43:43AM +0100, Leslie P. Polzer wrote: Da wir gerade beim Thema Hurd waren... ist es richtig und ggf. beabsichtigt, da? die Debian GNU/Hurd Rescue-CD keinen Bootloader installiert? Correct, you can't install GRUB from within a GNU/Hurd system, as GRUB's file access methods have not been ported to the Hurd environment. It's probably no longer worthwhile to do that for GRUB legacy, but definitely it is for the upcoming GRUB2. If someone feels like having a look at that... Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
At Tue, 20 Mar 2007 23:16:13 +0100, Richard Braun [EMAIL PROTECTED] wrote: [1 multipart/signed (7bit)] [1.1 text/plain; us-ascii (quoted-printable)] Hello, Here is a proposal for a Google Summer of Code project : rpctrace is one of the most useful debugging tools on the Hurd. It could help a lot in understanding some of the bugs of the system. Unfortunately, it can hardly be used to debug some essential translators because it cannot be used to trace already running tasks. I don't know exactly how this could be done, so I'm asking : is this technically feasible as a GSoC project ? It seems to me that this can be achieved transparently to the monitored task by using the standard Mach interfaces for a task port (you need the task port for debugging anyway). There are extensive interfaces to query and manipulate the port name space of a process, and that should allow you to retrieve all ports, create wrappers for them and insert the wrapper objects into the monitored task. You should also be able to undo the monitoring by reversing the process. Care must be taken to suspend the process while doing this, and also to modify the number of references appropriately. Please see the sections Port Names, Port Rights, Ports and other Tasks in the GNU Mach Reference Manual (gnumach/doc/mach.texi). Note that this will not allow you to debug all essential translators. Depending on your environment, debugging a critical server used by rpctrace itself indirectly would likely be hazardous. Irregardless of that, being able to attach and remove a monitor to a process at runtime is certainly useful. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Google Summer of Code project: libchannel
Hello! On Tue, Mar 20, 2007 at 09:22:12PM +0100, Fredrik Hammar wrote: first up let me introduce myself [...] Welcome, Fredrik! get it running on Xen. That basically works, but still has a number of sharp edges and slippery slopes. But for sure we should document how to get it running at all... Then I proceeded investigating the proposed projects and libchannel is the one that interests me the most. However it might be a bit more than I can chew... Nothing is carved in stone: the published tasks are the basis for the applicants to build their applications on. And nobody will stop you from contributing further once the GSoC is over. ;-) The main problem is my lack of experience with the Hurd's internals and OSes in general. But since my studies right now are quite relaxed, I feel I should be able to catch up by the time GsoC starts. I could easily spend 10h a week studying the Hurd and `bonding' with you guys (as Google puts it), and will spend more time than that as needed if it's available. As a plus studying libstore during this time, which should help me immensely with the design of libchannel, will give me an opportunity to go through and fix some of libstore's documentation. So I want a second opinion; should I go for it and write a proposal for a libchannel implementation or should I consider some other project instead? If you can spend the time on it right now -- applications are open until the end of this weekend, I think -- writing and submitting your application would indeed be a worthwhile thing to do. I can -- of course -- give absolutely no guarantees that we might select yours, but you'll hopefull already learn a lot when writing that application. PS. I'm new to posting on mailing lists, please excuse and correct any misstakes I make. Nothing to find fault within so far. :-) Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)
Thomas Schwinge, le Wed 21 Mar 2007 15:37:16 +0100, a écrit : It's probably no longer worthwhile to do that for GRUB legacy, Maybe as a debian patch at least. Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
maintaining the tool chain
Dear Sirs: I am writing to enquire about maintaining the tool chain of the project GNU Hurd. I am interested in this job. My specialty is computer sicience. I would be grateful if you could give me a chance to this job. Yours faithfully, YuanBo ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Google Summer of Code project: libchannel
Thomas Schwinge [EMAIL PROTECTED] writes: Hello! On Tue, Mar 20, 2007 at 09:22:12PM +0100, Fredrik Hammar wrote: first up let me introduce myself [...] Welcome, Fredrik! Thanks! get it running on Xen. That basically works, but still has a number of sharp edges and slippery slopes. But for sure we should document how to get it running at all... Yeah I gave it a shot in the dark and gave up pretty quickly when it didn't boot mach, I don't even know if I should change the default domain builder to something else, let alone how to get Hurd started after that. But this isn't an issue I want to tackle at the moment, so lets leave it at that. Then I proceeded investigating the proposed projects and libchannel is the one that interests me the most. However it might be a bit more than I can chew... Nothing is carved in stone: the published tasks are the basis for the applicants to build their applications on. And nobody will stop you from contributing further once the GSoC is over. ;-) That's a relief I guess, but I wouldn't want to apply for writing half of libchannel and leave a promise to write the rest later ;-). The main problem is my lack of experience with the Hurd's internals and OSes in general. But since my studies right now are quite relaxed, I feel I should be able to catch up by the time GsoC starts. I could easily spend 10h a week studying the Hurd and `bonding' with you guys (as Google puts it), and will spend more time than that as needed if it's available. As a plus studying libstore during this time, which should help me immensely with the design of libchannel, will give me an opportunity to go through and fix some of libstore's documentation. So I want a second opinion; should I go for it and write a proposal for a libchannel implementation or should I consider some other project instead? If you can spend the time on it right now -- applications are open until the end of this weekend, I think -- writing and submitting your application would indeed be a worthwhile thing to do. I can -- of course -- give absolutely no guarantees that we might select yours, but you'll hopefull already learn a lot when writing that application. Well of course, I wasn't expecting any guarantees of my proposal getting picked. On the contrary, I was hoping I didn't get a guarantees that I wouldn't be picked. ;-) But since that doesn't seem to be the case, I'll guess I give it my best shot at writing a proper proposal. Now I can concentrate on actually writing the proposal and not look around for alternatives, at least not until I get this proposal done. PS. I'm new to posting on mailing lists, please excuse and correct any misstakes I make. Nothing to find fault within so far. :-) Regards, Thomas Lets hope it stays that way. :-) Thanks again, Fredrik ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: a coreutils release is imminent
[Cced to bug-hurd@gnu.org.] Hello! On Tue, Mar 20, 2007 at 10:41:42PM +0100, Jim Meyering wrote: http://meyering.net/cu/coreutils-6.8+.tar.gz http://meyering.net/cu/coreutils-6.8+.tar.gz.sig Please build it and run make -k check on a few unusual systems today or tomorrow and report any problems. That might save someone (yourself, even) some trouble down the road. Here we go. So far, I didn't run the tests marked as ``root-only'' or ``very expensive''. #v+ $ uname -a GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU #v- | ** | ../../../tests/cp/acl: This test requires getfacl and setfacl. | ** | SKIP: acl Correct, not supported so far. | ../../../tests/du/long-from-unreadable: Skipping this test. | It would fail, since your system lacks /proc support. | SKIP: long-from-unreadable Correct, no `/proc/' support by default so far. | ../../../tests/du/8gb: cannot create a file large enough for this test; possibly | ../../../tests/du/8gb: because file offsets are only 32 bits on this file system | SKIP: 8gb Would have to check what's up with that one. (As well as for the others further down the list, the ones where I didn't put specific comments.) | df: Warning: cannot read table of mounted file systems | df: Warning: cannot read table of mounted file systems | ../../../tests/du/slink: skipping this test, since `.' is on an XFS file system | SKIP: slink It's for sure not an xfs file system, but an ext2 one. We don't maintain something like `/proc/mounts' or `/etc/mtab', so running `df' without explicitly specifying a directory to work on won't work: #v+ $ df df: cannot read table of mounted file systems $ echo $? 1 $ fsysopts ./ /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd0s6 $ df ./ df: Warning: cannot read table of mounted file systems Filesystem 1K-blocks Used Available Use% Mounted on - 3831468 2875780764116 80% /devel3 $ echo $? 0 #v- | ../../../tests/ls/stat-dtype: '.' is not on a suitable file system for this test | ../../../tests/ls/stat-dtype: skipping this test | SKIP: stat-dtype | df: Warning: cannot read table of mounted file systems | df: Warning: cannot read table of mounted file systems | PASS: df-P | ../../../tests/misc/pwd-unreadable-parent: vendor getcwd may be inadequate; skipping this test | SKIP: pwd-unreadable-parent | ../../../tests/misc/cat-proc: no /proc/cpuinfo skipping this test | SKIP: cat-proc | df: Warning: cannot read table of mounted file systems | PASS: df | FAIL: nice Known problem. | nohup: ignoring input and redirecting stderr to stdout | PASS: nohup | ../../../tests/misc/tac-continue: FULL_PARTITION_TMPDIR not defined; skipping this test | SKIP: tac-continue | tty-eof: this script requires Perl's Expect package =1.11 | SKIP: tty-eof | ../../../tests/mv/atomic: no strace program, so skipping this test | SKIP: atomic Correct, we don't have `strace', but instead could offer `rpctrace' to ``Trace Mach Remote Procedure Calls'', which roughly is `strace''s equivalent. | ** | ../../../tests/mv/acl: This test requires getfacl and setfacl. | ** | SKIP: acl | ../../../tests/rm/inaccessible: no openat support, so skipping this test | SKIP: inaccessible Correct, not implemented so far. | ../../../tests/tail-2/tail-n0f:/proc/2186/status: missing or 'different': skipping this test | SKIP: tail-n0f | make check-TESTS | make[3]: Entering directory `/devel3/tschwinge/tmp/coreutils/coreutils-6.8+/build/tests' | 0+1 records in | 0+1 records out | ../../src/df: Warning: cannot read table of mounted file systems | ../../tests/help-version: line 198: 6207 Terminated sleep 10m | PASS: help-version Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: a coreutils release is imminent
Thomas Schwinge [EMAIL PROTECTED] wrote: Here we go. So far, I didn't run the tests marked as ``root-only'' or ``very expensive''. Thanks for the detailed feedback! $ uname -a GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU | SKIP: 8gb I suppose you already know about the instructions in README for making the tests produce verbose output... Would have to check what's up with that one. (As well as for the others further down the list, the ones where I didn't put specific comments.) | df: Warning: cannot read table of mounted file systems | df: Warning: cannot read table of mounted file systems | ../../../tests/du/slink: skipping this test, since `.' is on an XFS file system | SKIP: slink It's for sure not an xfs file system, but an ext2 one. We don't maintain something like `/proc/mounts' or `/etc/mtab', so running `df' without explicitly specifying a directory to work on won't work: Good catch. It exposed a suboptimality in that script. Here's a patch that might help. Fix a test script not to claim an ext2 file system is of type xfs. * tests/du/slink: When using df --local and df --type=TYPE, test only the exit code. Don't bother with stdout. Prompted by a report by Thomas Schwinge of an inaccurate diagnostic. diff --git a/tests/du/slink b/tests/du/slink index 2167934..8be1a30 100755 --- a/tests/du/slink +++ b/tests/du/slink @@ -1,7 +1,7 @@ #!/bin/sh # Ensure that the size of a long-named-symlink is 0. -# Copyright (C) 2002, 2003, 2004, 2006 Free Software Foundation, Inc. +# Copyright (C) 2002-2007 Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -34,25 +34,23 @@ cd $tmp || framework_failure=1 # Determine if `.' is on a local (would non-NFS be sufficient?) file system. # On at least some NFS implementations, symlinks never take up space, -df --local . | tail -n +2 tmp + # So if this is a non-local file system, skip the test. -if test -s tmp; then +if df --local . /dev/null 21; then : # Ok. else echo $0: skipping this test, since \`.' is on a non-local file system 12 (exit 77); exit 77 fi -df --type=xfs . | tail -n +2 tmp -if test -s tmp; then +if df --type=xfs . /dev/null 21; then # At least on Irix-6.5.19, when using an xfs file system, # each created symlink (name lengths up to 255) would have a size of `0'. echo $0: skipping this test, since \`.' is on an XFS file system 12 (exit 77); exit 77 fi -df --type=nfsv3 . | tail -n +2 tmp -if test -s tmp; then +if df --type=nfsv3 . /dev/null 21; then # At least on OSF/1 4.0d, when using an nfsv3 file system, # each created symlink can end up having a size of 0. echo $0: skipping this test, since \`.' is on an NFS file system 12 ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Device drivers in Mach?
Hello, when I went to the task page with notes on the coming sound system, I noticed that it's written there that device drivers go into Mach. Why is that? I thought a big point of micro kernels was that a single malfunctioning driver couldn't affect the whole system because it doesn't sit in “admin” space. Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpJ9h2itGIwW.pgp Description: PGP signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: maintaining the tool chain
On Tue, Mar 20, 2007 at 09:05:29PM +0800, �R�L而行 wrote: Dear Sirs: I am writing to enquire about maintaining the tool chain of the project GNU Hurd. I am interested in this job. My specialty is computer sicience. I would be grateful if you could give me a chance to this job. Well... go ahead! Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpQD4SC6LhtG.pgp Description: PGP signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)
On Wed, Mar 21, 2007 at 03:37:16PM +0100, Thomas Schwinge wrote: [Taking this to bug-hurd@gnu.org.] No need to CC me, I happen to be subscribed :) Correct, you can't install GRUB from within a GNU/Hurd system, But the rescue CD is running GNU/Linux...? Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpkLoAQjMHds.pgp Description: PGP signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)
[EMAIL PROTECTED], le Wed 21 Mar 2007 19:46:49 +0100, a écrit : On Wed, Mar 21, 2007 at 03:37:16PM +0100, Thomas Schwinge wrote: [Taking this to bug-hurd@gnu.org.] No need to CC me, I happen to be subscribed :) You then need to explain that to your mailer for properly setting the Mail-Followup-To: header. Correct, you can't install GRUB from within a GNU/Hurd system, But the rescue CD is running GNU/Linux...? Yes. Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Device drivers in Mach?
[EMAIL PROTECTED] wrote: Hello, Hello Leslie when I went to the task page with notes on the coming sound system, I noticed that it's written there that device drivers go into Mach. Why is that? I thought a big point of micro kernels was that a single malfunctioning driver couldn't affect the whole system because it doesn't sit in �admin� space. Your observation is correct. All of Mach's drivers currently reside inside the kernel. AFAIK, Mach's IPC is too slow to support user space drivers. When Mach was created at Carnegie Mellon, they had experimented with user space drivers and observed the above conclusion. I'm sure that the senior members of this project can give you more detailed info on the subject than me. However, processors have gotten *a lot* faster the last ten years since Mach's creation, so i have a few reservations if the current IPC system is completely unusable with user space drivers. Once again, the senior members of this project can shed more light on the subject. Regards, Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)
On Wed, Mar 21, 2007 at 07:57:06PM +0100, Samuel Thibault wrote: You then need to explain that to your mailer for properly setting the Mail-Followup-To: header. Indeed. Correct, you can't install GRUB from within a GNU/Hurd system, But the rescue CD is running GNU/Linux...? Yes. So, why doesn't it install a boot loader? Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpfNtsNoO3mE.pgp Description: PGP signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Device drivers in Mach?
On Wed, Mar 21, 2007 at 09:01:35PM +0200, Constantine Kousoulos wrote: Your observation is correct. All of Mach's drivers currently reside inside the kernel. AFAIK, Mach's IPC is too slow to support user space drivers. Phew. Don't they have that in Minix? I think I remember starting the Realtek network driver in user space. What a delighting experience. However, processors have gotten *a lot* faster the last ten years since Mach's creation, so i have a few reservations if the current IPC system is completely unusable with user space drivers. Once again, the senior members of this project can shed more light on the subject. The only reason for me that would make me start helping with GNU/Hurd would be device drivers (and most of the other stuff) in user space, since Linux crashes too often when faulty hardware or drivers are at play... I'd appreciate more input on this, and why I would want a microkernel architecture that isn't really one (IMHO)... What about L4? Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpilopoVsa13.pgp Description: PGP signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
Hi, On Tue, Mar 20, 2007 at 11:16:13PM +0100, Richard Braun wrote: Here is a proposal for a Google Summer of Code project : rpctrace is one of the most useful debugging tools on the Hurd. It could help a lot in understanding some of the bugs of the system. Unfortunately, it can hardly be used to debug some essential translators because it cannot be used to trace already running tasks. I don't know exactly how this could be done, so I'm asking : is this technically feasible as a GSoC project ? Actually, I already thought of something like this, though I would suggest making it a more generic task: Improving Hurd-specific debugging tools. Implementing the possibility of attaching rpctrace to running processes, is one possible thing that could be done. But there are many others, like adding ability to rpctrace to show the names of the parameters (needs rpctrace and mig changes); adding some tool(s) that allow logging the interactions between several processes, to help understanding complex problems and/or doing system profiling; interactive RPC debugging tools (possibly as GDB extension); and so on. However, I didn't propose this so far, as tschwinge seems to have a perfectly opposite opinion than me on what are suitable tasks and what aren't. -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
Hello! On Wed, Mar 21, 2007 at 08:09:31AM +0100, [EMAIL PROTECTED] wrote: Implementing the possibility of attaching rpctrace to running processes, is one possible thing that could be done. But there are many others, like adding ability to rpctrace to show the names of the parameters (needs rpctrace and mig changes); adding some tool(s) that allow logging the interactions between several processes, to help understanding complex problems and/or doing system profiling; interactive RPC debugging tools (possibly as GDB extension); and so on. However, I didn't propose this so far, as tschwinge seems to have a perfectly opposite opinion than me on what are suitable tasks and what aren't. Huh, what's that? In fact, what I told you was that I wouldn't know how to wrap what you suggested into a concise wording for a GSoC task, so that someone who isn't familiar with all those Hurd details would know what this task was about. I then asked you to come up with such a wording to then install that task, but, so far, you didn't respond to that plea and instead now accuse me to not consider your ideas worthwhile? That doesn't fit. I mean, these are tasks that require a really intimate knowledge of how the components of a Hurd system interact with each other. That's not something where an ``average student'' could make any sense of. That's at least my opinion on this matter. Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
