Does task_info support the TASK_EVENTS_INFO type of information?
Hi, I tried the code below: struct task_events_info taskevents; size_t tkcount = TASK_EVENTS_INFO_COUNT; error_t err; err = task_info (mach_task_self (), TASK_EVENTS_INFO, (task_info_t) taskevents, tkcount); assert_perror (err); and I always get the error: Unexpected error: (os/kern) invalid argument. It seems to me that the Mach doesn't support TASK_EVENTS_INFO. I read Mach 3 Kernel Interfaces and it seems that the original Mach only supports TASK_BASIC_INFO and TASK_THREAD_TIMES_INFO, but The GNU Mach Reference Manual mentions TASK_EVENTS_INFO. I assume that this feature is added in GNU Mach. I use Debian/Hurd, and the version of Mach is GNU Mach 1.3.99. I wonder which version of GNU Mach supports TASK_EVENTS_INFO. Best regards, Zheng Da
Re: Does task_info support the TASK_EVENTS_INFO type of information?
Da Zheng, le Tue 02 Jun 2009 16:24:27 +0800, a écrit :
It seems to me that the Mach doesn't support TASK_EVENTS_INFO.
/usr/src/gnumach-1€ rgrep TASK_EVENTS_INFO .
./include/mach/task_info.h:#define TASK_EVENTS_INFO2 /* various
event counts */
./include/mach/task_info.h:#define TASK_EVENTS_INFO_COUNT \
./doc/mach.info-1:`TASK_EVENTS_INFO'
./doc/mach.info-1: returned is `TASK_EVENTS_INFO_COUNT'.
./doc/mach.info-1: provided it as the TASK_INFO parameter for the
`TASK_EVENTS_INFO'
./doc/mach.texi:@item TASK_EVENTS_INFO
./doc/mach.texi:@code{TASK_EVENTS_INFO_COUNT}.
./doc/mach.texi:@code{TASK_EVENTS_INFO} flavor of @code{task_info}. It has the
/usr/src/gnumach-1€
so yes, it seems not supported by GNU Mach albeit documented.
Samuel
[patch #6844] fix a bug in init: initialize 'flags' in reboot_system
URL: http://savannah.gnu.org/patch/?6844 Summary: fix a bug in init: initialize 'flags' in reboot_system Project: The GNU Hurd Submitted by: zhengda Submitted on: Tue 02 Jun 2009 08:47:27 AM GMT Category: other Hurd Priority: 5 - Normal Status: Works For Me Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None Wiki-like text discussion box: ___ Details: We should initialize 'flags' in reboot_system. The only information we need to get from proc_getprocinfo is the state of the process. 'flags = 0' is very enough to do the job and it can make proc_getprocinfo less likely to fail. The Mach in my system somehow doesn't support the TASK_EVENTS_INFO type of information. Without the initialization of 'flags', it is possible that proc_getprocinfo returns error, which results in the failure to shut down the subhurd. ___ File Attachments: --- Date: Tue 02 Jun 2009 08:47:27 AM GMT Name: init.diff Size: 492B By: zhengda http://savannah.gnu.org/patch/download.php?file_id=18216 ___ Reply to this item at: http://savannah.gnu.org/patch/?6844 ___ Message sent via/by Savannah http://savannah.gnu.org/
Re: Does task_info support the TASK_EVENTS_INFO type of information?
Samuel Thibault wrote:
Da Zheng, le Tue 02 Jun 2009 16:24:27 +0800, a écrit :
It seems to me that the Mach doesn't support TASK_EVENTS_INFO.
/usr/src/gnumach-1€ rgrep TASK_EVENTS_INFO .
./include/mach/task_info.h:#define TASK_EVENTS_INFO2 /* various
event counts */
./include/mach/task_info.h:#define TASK_EVENTS_INFO_COUNT \
./doc/mach.info-1:`TASK_EVENTS_INFO'
./doc/mach.info-1: returned is `TASK_EVENTS_INFO_COUNT'.
./doc/mach.info-1: provided it as the TASK_INFO parameter for the
`TASK_EVENTS_INFO'
./doc/mach.texi:@item TASK_EVENTS_INFO
./doc/mach.texi:@code{TASK_EVENTS_INFO_COUNT}.
./doc/mach.texi:@code{TASK_EVENTS_INFO} flavor of @code{task_info}. It has the
/usr/src/gnumach-1€
so yes, it seems not supported by GNU Mach albeit documented.
Samuel
However, TASK_EVENTS_INFO is used by Hurd in proc_getprocinfo. libps
also tries to use it.
Is it a planned feature or it was supported by GNU Mach but was removed?
If it was removed, we should update the Hurd too.
Anyway, it causes some trouble when subhurd is shutdown.
I just provided a patch to make sure that proc_getprocinfo doesn't try
to get the TASK_EVENTS_INFO type of information when the subhurd is
shutdown.
Best regards,
Zheng Da
[b...@gnu.org: [Savannah-announce] Recover your repositories]
Hello! Email is full-quoted and with my comments inlined. | - Forwarded message from Sylvain Beucler b...@gnu.org - | Date: Tue, 2 Jun 2009 09:16:55 +0200 | Subject: [Savannah-announce] Recover your repositories | | The system is now completely functional. | It's time to decide what to do with your data. | (see first explanations at http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html) | | | Please discuss and send questions at savannah-us...@gnu.org ! | | For import requests: see below, you need to send a support request via | the web interface. | | | | Basically your choices are: | a) you can use the backup from April 29 This is good enough for us, because... | b) you can use our latest (incomplete) backup from May 29 | c) you can import another backup you have | d) you can wait a few days until we possibly recover latest data from the crashes disk (nothing is sure though). More details about this later. | | | Here's how do it for the various VCSs: | | * CVS: | a) The version from 29 April in the 'backup-20090429' subdirectory. | b) The version from 29 May in the 'backup-20090529-incomplete' subdirectory. | c) Upload your backup in your download area (SFTP) for us to import | | Access commands: | cvs -d:pserver:anonym...@cvs.sv.gnu.org:/sources/backup-20090429/your_project co your_module | cvs -d:pserver:anonym...@cvs.sv.gnu.org:/sources/backup-20090529-incomplete/your_project co your_module | rsync rsync://cvs.sv.gnu.org/sources/backup-20090429/your_project/ ... this version (backup-20090429) is sufficiently recent for us, as no checkins to the CVS repository have been done after this date, due to the (still) ongoing CVS to Git migration. (By the way, I'm currently (a) waiting for a clean-up script by Jim Meyering, and (b) tracking down, with the help of its author, either a bug in the conversion program, or a repository corruption in the gnumach module.) Also, I diffed the backup-20090429 rsync tree against my local rsync mirror and found it to be in a correct state. | rsync rsync://cvs.sv.gnu.org/sources/backup-20090529-incomplete/your_project/ | | IN ALL CASES: post a support request, authenticated (i.e. login first) at https://savannah.gnu.org/support/?func=additemgroup=administration with category RECOVERY: CVS/SVN. Requests send by mail or in the wrong category won't be processed. | | If after 2 weeks we didn't receive an answer for your project, we'll reinstall the latest backup we have. | | | * SVN: [Snipped, as not relevant for us.] | * Git: | a) We installed the version from 29 April. | b) You can attempt to recover from the partial 29 May backup: http://git.savannah.gnu.org/r/backup-20090529-incomplete/ | c) You can push a local version if you have one (git push --all; git push --tags) | | You can import the repository directly, without our help. ... exactly! (thanks DVCS!); for the web pages repository I already pushed the missing changes, and for the other repositories the same can be done, and I'll take care of that as soon as I have the conversion finished properly. Neal, you can also simply push your viengoos and viengoos-on-bare-meal branches back into the Viengoos Git repository. | * Mercurial: [Snipped, as not relevant for us.] | * WebCVS: | | We plan to either recover the data from disk, or failing that, manually commit the latest version at www.gnu.org and www.nongnu.org. ... we don't care, as we have all the history in our web pages' Git repository and use the CVS one only as a transport mechanism to get the files to the web server. Regards, Thomas signature.asc Description: Digital signature
Re: [b...@gnu.org: [Savannah-announce] Recover your repositories]
On Tuesday, 2. June 2009 11:30:25 Thomas Schwinge wrote: | * Mercurial: [Snipped, as not relevant for us.] Except the pyhurd code, but I just checked the remote repo and it works. We only need to push to get it up to date again. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
A GNU/Hurd Roadmap dream
I just dreamed of a Roadmap the Hurd might have - a Roadmap which would be the perfect Roadmap for making the Hurd useful for me. I thought I'd share the dream with you. This is the Roadmap I dreamt of: 1) Sound support: Now I can listen to my music (essential). 2) Qemu image with X11 out of the box: Now I can do most of my general development work in the Hurd, including convenient websurfing. 3) Solid hardware support: Now I can use a dual-boot on my main computer. 4) Linux device driver wrapper: Now I don't really need Linux anymore - except for some applications. I can spend most of my computer time using the Hurd. And I can port some applications I need. Then I awoke and I thought and it would be great to add just one more item: 5) Gentoo Portage on the GNU/Hurd: Now the work for maintaining the software bases shrinks massively and more software can be made available at far lower maintenance cost. This is not necessary, though. It also wasn't part of the dream. Best wishes, Arne PS: A native installer wasn't part of the dream, either. I don't need it for using the Hurd. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
Re: A GNU/Hurd Roadmap dream
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
