Re: Debian GNU/Hurd 2013 released!
On 5/21/2013 7:24 PM, Samuel Thibault wrote: This is now published on http://www.debian.org/ports/hurd/hurd-news.en.html http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html Please spread the news :) Samuel \o/ Nice work folks!! Barry
Re: RFC for patch to add task_{set,get}_name RPC
Gentlemen,
I don't want to get into the political or technical merits but here is an
updated patch that works.
I will let you decide what to do with it. :)
Thanks,
Barry
diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs
index 7331334..b26be96 100644
--- a/include/mach/gnumach.defs
+++ b/include/mach/gnumach.defs
@@ -37,3 +37,17 @@ type vm_cache_statistics_data_t = struct[11] of integer_t;
routine vm_cache_statistics(
target_task : vm_task_t;
out vm_cache_stats : vm_cache_statistics_data_t);
+
+/*
+ * Set the name of a task.
+ */
+routine task_set_name(
+ task: task_t;
+ name: task_name_t);
+
+/*
+ * Get the name of a task.
+ */
+routine task_get_name(
+ task: task_t;
+ out name: task_name_t);
diff --git a/include/mach/mach_types.defs b/include/mach/mach_types.defs
index 607d5d9..c913cbb 100644
--- a/include/mach/mach_types.defs
+++ b/include/mach/mach_types.defs
@@ -230,6 +230,8 @@ type emulation_vector_t = ^array[] of
vm_offset_t;
type rpc_signature_info_t = array[*:1024] of int;
+type task_name_t = (MACH_MSG_TYPE_STRING, 8*32);
+
#ifKERNEL_SERVER
simport kern/ipc_kobject.h; /* for null conversion */
simport kern/ipc_tt.h; /* for task/thread conversion */
diff --git a/include/mach/mach_types.h b/include/mach/mach_types.h
index 8768482..5bb3a7b 100644
--- a/include/mach/mach_types.h
+++ b/include/mach/mach_types.h
@@ -43,6 +43,7 @@
#include mach/port.h
#include mach/processor_info.h
#include mach/task_info.h
+#include mach/task_name.h
#include mach/task_special_ports.h
#include mach/thread_info.h
#include mach/thread_special_ports.h
diff --git a/include/mach/task_name.h b/include/mach/task_name.h
new file mode 100644
index 000..d6306e2
--- /dev/null
+++ b/include/mach/task_name.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2013 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
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Author: Barry deFreese.
+ */
+
+#ifndef _TASK_NAME_H_
+#define _TASK_NAME_H_
+
+#define TASK_NAME_SIZE 32
+
+typedef char task_name_t[TASK_NAME_SIZE];
+
+#endif /* _TASK_NAME_H_ */
diff --git a/kern/task.c b/kern/task.c
index 114dd31..438037b 100644
--- a/kern/task.c
+++ b/kern/task.c
@@ -37,6 +37,7 @@
#include mach/vm_param.h
#include mach/task_info.h
#include mach/task_special_ports.h
+#include mach/task_name.h
#include ipc/ipc_space.h
#include ipc/ipc_types.h
#include kern/debug.h
@@ -1212,3 +1213,33 @@ task_ras_control(
#endif
return ret;
}
+
+kern_return_t
+task_set_name (
+ task_t task,
+ task_name_t name)
+{
+
+ if (task == TASK_NULL)
+ return KERN_INVALID_ARGUMENT;
+
+ strncpy(task-name, name, TASK_NAME_SIZE - 1);
+ task-name[TASK_NAME_SIZE - 1] = '\0';
+
+ return KERN_SUCCESS;
+}
+
+kern_return_t
+task_get_name (
+ task_t task,
+ task_name_t name)
+{
+
+ if (task == TASK_NULL)
+ return KERN_INVALID_ARGUMENT;
+
+ strncpy(name, task-name, TASK_NAME_SIZE - 1);
+ name[TASK_NAME_SIZE - 1] = '\0';
+
+ return KERN_SUCCESS;
+}
diff --git a/kern/task.h b/kern/task.h
index 9bfea57..842979a 100644
--- a/kern/task.h
+++ b/kern/task.h
@@ -39,6 +39,7 @@
#include mach/time_value.h
#include mach/mach_param.h
#include mach/task_info.h
+#include mach/task_name.h
#include kern/kern_types.h
#include kern/lock.h
#include kern/queue.h
@@ -111,6 +112,8 @@ struct task {
natural_t cow_faults; /* copy-on-write faults counter */
natural_t messages_sent; /* messages sent counter */
natural_t messages_received; /* messages received counter */
+
+ task_name_t name; /* Task name */
};
#define task_lock(task)simple_lock((task)-lock)
RFC for patch to add task_{set,get}_name RPC
Hi folks,
I am trying to get a test environment going to test this but in the meantime if
any of you care to
review, here is a patch to add task_set_name() and task_get_name() RPCs to
gnumach.
Thanks!
Barry
diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs
index 7331334..b26be96 100644
--- a/include/mach/gnumach.defs
+++ b/include/mach/gnumach.defs
@@ -37,3 +37,17 @@ type vm_cache_statistics_data_t = struct[11] of integer_t;
routine vm_cache_statistics(
target_task : vm_task_t;
out vm_cache_stats : vm_cache_statistics_data_t);
+
+/*
+ * Set the name of a task.
+ */
+routine task_set_name(
+ task: task_t;
+ name: task_name_t);
+
+/*
+ * Get the name of a task.
+ */
+routine task_get_name(
+ task: task_t;
+ out name: task_name_t);
diff --git a/include/mach/mach_types.defs b/include/mach/mach_types.defs
index 607d5d9..c913cbb 100644
--- a/include/mach/mach_types.defs
+++ b/include/mach/mach_types.defs
@@ -230,6 +230,8 @@ type emulation_vector_t = ^array[] of
vm_offset_t;
type rpc_signature_info_t = array[*:1024] of int;
+type task_name_t = (MACH_MSG_TYPE_STRING, 8*32);
+
#ifKERNEL_SERVER
simport kern/ipc_kobject.h; /* for null conversion */
simport kern/ipc_tt.h; /* for task/thread conversion */
diff --git a/include/mach/mach_types.h b/include/mach/mach_types.h
index 8768482..5bb3a7b 100644
--- a/include/mach/mach_types.h
+++ b/include/mach/mach_types.h
@@ -43,6 +43,7 @@
#include mach/port.h
#include mach/processor_info.h
#include mach/task_info.h
+#include mach/task_name.h
#include mach/task_special_ports.h
#include mach/thread_info.h
#include mach/thread_special_ports.h
diff --git a/include/mach/task_name.h b/include/mach/task_name.h
new file mode 100644
index 000..296bd9e
--- /dev/null
+++ b/include/mach/task_name.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 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
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Author: Barry deFreese.
+ */
+
+#ifndef _TASK_NAME_H_
+#define _TASK_NAME_H_
+
+typedef char task_name_t[32];
+
+#endif /* _TASK_NAME_H_ */
diff --git a/kern/task.c b/kern/task.c
index 114dd31..d8690c6 100644
--- a/kern/task.c
+++ b/kern/task.c
@@ -37,6 +37,7 @@
#include mach/vm_param.h
#include mach/task_info.h
#include mach/task_special_ports.h
+#include mach/task_name.h
#include ipc/ipc_space.h
#include ipc/ipc_types.h
#include kern/debug.h
@@ -1212,3 +1213,33 @@ task_ras_control(
#endif
return ret;
}
+
+kern_return_t
+task_set_name (
+ task_t task,
+ task_name_t name)
+{
+
+ if (task == TASK_NULL)
+ return KERN_INVALID_ARGUMENT;
+
+ strncpy(task-name, name, sizeof(task-name) -1);
+ task-name[sizeof(task-name) -1] = '\0';
+
+ return KERN_SUCCESS;
+}
+
+kern_return_t
+task_get_name (
+ task_t task,
+ task_name_t name)
+{
+
+ if (task == TASK_NULL)
+ return KERN_INVALID_ARGUMENT;
+
+ strncpy(name, task-name, sizeof(task-name) - 1);
+ name[sizeof(name) -1] = '\0';
+
+ return KERN_SUCCESS;
+}
diff --git a/kern/task.h b/kern/task.h
index 9bfea57..842979a 100644
--- a/kern/task.h
+++ b/kern/task.h
@@ -39,6 +39,7 @@
#include mach/time_value.h
#include mach/mach_param.h
#include mach/task_info.h
+#include mach/task_name.h
#include kern/kern_types.h
#include kern/lock.h
#include kern/queue.h
@@ -111,6 +112,8 @@ struct task {
natural_t cow_faults; /* copy-on-write faults counter */
natural_t messages_sent; /* messages sent counter */
natural_t messages_received; /* messages received counter */
+
+ task_name_t name; /* Task name */
};
#define task_lock(task)simple_lock((task)-lock)
Re: http://darnassus.sceen.net/~hurd-web/ is the new http://www.bddebian.com:8888/~hurd-web/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry guys, life has really gotten in the way for the last few months and probably for another year or so... :( Barry On 3/6/2013 5:38 PM, Thomas Schwinge wrote: Hi! As Barry's zenhost, the Xen dom0 that is, or rather was, hosting, amongst others, snubber, the machine behind http://www.bddebian.com:/, has now been down for more than half a year already, with no immediate hope of getting it back in service, and Richard, on the other hand, has been more than willing to begin hosting, on his darnassus machine, a new instance of our web pages/wiki conglomerate, we have then been working, again already a month ago..., on setting that up, and now I finally got around to finishing this transition. http://www.gnu.org/software/hurd/ has been updated, and http://www.gnu.org/software/hurd/contributing/web_pages.html in particular again tells a true story about how to work on the pages. In short, http://darnassus.sceen.net/~hurd-web/ is the new http://www.bddebian.com:/~hurd-web/. Grüße, Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE36tEACgkQ5ItltUs5T365wgCfUT76sFnVzGgPR73hHWllFBQ/ I/MAoJb3iavynv4K/Pqtz4oS+knMbrW0 =OMYT -END PGP SIGNATURE-
Re: hurd with libpthread
w000t!! Finally, nice job folks!! (Sorry to have disappeared again... :-() Barry On 11/27/2012 9:54 PM, Samuel Thibault wrote: Hello, At last that work is out! I've pushed the patchqueue from Richard to upstreams, built test debian packages on deb http://people.debian.org/~sthibault/hurd-i386/tmp ./ I hope to have not forgotten anything for the dependencies: the new hurd depends on the new libc0.3, and breaks the old netdde. I can confirm that the upgrade went fine on my machine, but it might be useful to test other cases. We'll have to wait for eglibc 2.13-38 to get uploaded to unstable before being able to upload that to unstable, and eventually push that to buildds, etc. I have to thank a lot everybody who was involved into that big change. Samuel
Re: Hurd build system Makeconf
On 7/25/2012 4:48 AM, Richard Braun wrote: On Tue, Jul 24, 2012 at 11:12:11PM -0400, Barry deFreese wrote: Now the question is, what to do with cancel-cond.c? I'm thinking of just sticking it in libshouldbeinlibc for now? Is there a more appropriate place? Why not in libpthread, near the pthread_cond_wait and pthread_cond_timedwait functions, considering how related they are ? Richard, Mainly because there is no libpthread in hurd sources any more... :) Barry
Hurd build system Makeconf
Hi folks, I applied Thomas Thomas's pthreads stuff to the debian package source and am trying to build. I am trying to use glibc's libpthread. So I get the following error(s): make: *** No rule to make target `libpthread', needed by `libiohelp'. Stop. I am thinking that this line in Makeconf is the issue: # More useful version of HURDLIBS library_deps=$(foreach lib,$(HURDLIBS),$(..)lib$(lib)/lib$(lib).so) I can't see anyway there that it would use libpthread from /usr/lib/... Now of course we don't usually want to use /usr/lib/... because it would pick up the currently installed libs instead of the built ones but we need to make exceptions. Do you think we should have a section like OTHERLIBS or something? Or should pthreads be removed from HURDLIBS and use -lpthread? Thanks! Barry
Re: Hurd build system Makeconf
On 7/24/2012 10:26 PM, Roland McGrath wrote: HURDLIBS is for things that are built in that source tree. If you're using a library that comes from the libc install or someplace like that, then -lfoo is the right way to use it. That is what I thought, thanks Roland. It seems to work. Now the question is, what to do with cancel-cond.c? I'm thinking of just sticking it in libshouldbeinlibc for now? Is there a more appropriate place? Thanks again, Barry
Re: Warnings about error_t in glibc on GNU/Hurd
How about ENOERR?? :) Sorry, couldn't resist. BTW, Thomas has a listing of several of the errors/warnings listed here: http://www.gnu.org/software/hurd/open_issues/glibc.html#index1h1 I'm certainly fine with just adding a value for 0. Thanks for taking the time to reply. Barry On 7/23/2012 3:51 PM, Roland McGrath wrote: Grepping for 'case 0:' shows exactly 8 places where this warning should arise. One of those is the __hurd_fail inline in hurd.h, so that one instance probably generates the warning in many compilations. Most of these are switches with only a few cases where it would be easy to just change them to use 'if' instead of 'switch' without complicating the code. Doing that would just avoid the question. I'm not real sure about giving an E* name to 0, since E* names are for error codes, and 0 isn't one. But OTOH for error_t 0 is certainly one of the expected values, so it makes sense to have an enum constant for it. The question is what name to use, and then whether to actually use that name or just add it to suppress the warning while still using 0 in the code. I tried GCC 4.4, and it doesn't give this warning when you use an integer literal as long as the enum has some name for that integer value. If other GCC versions do warn for 'case 0:' when some item 'foo = 0' is in the enum, someone please tell me. Assuming the warning behavior is consistent with what I've seen, my inclination is not to change the code to use a symbolic name for this. That's mostly because the obvious choices like ESUCCESS or EOK just seem wrong to me since the E* name space ought to be for actual error codes, and I can't think of a good name I'd actually want to be writing in the code. So I'm inclined to pick some name that is not very friendly to use (i.e. long and verbose), perhaps even in the _* space, and add that to the error_t enum just for the purpose of suppressing these warnings and not expect people to use it in the code. Thanks, Roland
Re: Concerning pthreads and such
On 7/19/2012 6:55 PM, Thomas Thomas wrote: From: Thomas Schwinge tho...@codesourcery.com Sent: Thursday, July 19, 2012 12:24 AM Subject: Re: Concerning pthreads and such If you do already know a bit or two about Git and promise to be sufficiently careful, then I'd like to add you to the Savannah Hurd group, so that you can directly push to the Savannah hurd/hurd.git repository. Thanks... but I don't really feel confident about my abilities with git. I tried pushing everything to my bitbucket account: Web interface: https://bitbucket.org/timmytdm/pthreads-hurd Git: https://bitbucket.org/timmytdm/pthreads-hurd.git Am I doing things right? Thomas D Thomas, So far so good. I see you've renamed hurd_condition_wait in most places but did you move the actual definition as well? I am getting undefined references to hurd_cond_wait. Thanks! Barry
Re: Concerning pthreads and such
On 6/20/2012 2:04 PM, Thomas Thomas wrote: Let me try this again: I am sending this to GNU and not debian because: 1) There are several debian people who subscribe to GNU also, 2) The debian development list for Hurd doesn't accept attachments this large, and 3) debian seems to be one of the most used distributions for Hurd. This is a patch to hurd-20120605-2 to have it use pthreads instead of cthreads. It does have some issues. It still needs a libpthread directory in the hurd source tree (I believe that all the directory needs in it is links to the .so and .a files). Libpthread needs to have the function provided by cancel-cond.c in it (so you need to rebuild libpthread, part of glibc: probably all of glibc then). [hurd_condition_wait allows RPCs to be interrupted with hurd_thread_cancel] Also included is a patch to netdde, which also needs to be rebuild if one wants to have working networking. As always, I thank Barry DeFreese and Vicente Ara for doing most of the work. Thomas DiModica PS. What would be, in everyone's opinion, a rigorous test (or tests) that the pthreads code works? Thomas, Have you gotten any feedback on this? Are you still working on it/testing it? Great stuff! Barry
Re: Strange output of gcc -E on GNU/Hurd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/16/2012 3:43 AM, Thomas Schwinge wrote:
Hi!
On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese bdefre...@debian.org
wrote:
In looking at libprelude it generates a lot of files using gawk. The
attached file is
generated from gawk and then is run through gcc -E.
On GNU/Hurd, I get significantly different results than I do from GNU/Linux.
Anyone have a
clue why that might be or where I would look to debug this?
What errors do you get?
Grüße, Thomas
Thomas,
I'm not getting any errors it is just that the output is so radically different
that the package
that processes the output files is having problems.
Attached is foo.h processed by both hurd and linux.
Thanks,
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAEJFcACgkQ5ItltUs5T34pgQCeLut92VjadzC52/NhPwHM/glA
yHoAoPVZ161+tcOqRXGUiVcjutWXv4u1
=ytC2
-END PGP SIGNATURE-
# 1 foo.h
# 1 command-line
# 1 foo.h
# 25 foo.h
# 1 /usr/include/errno.h 1 3 4
# 29 /usr/include/errno.h 3 4
# 1 /usr/include/features.h 1 3 4
# 323 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/bits/predefs.h 1 3 4
# 324 /usr/include/features.h 2 3 4
# 356 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/sys/cdefs.h 1 3 4
# 359 /usr/include/i386-gnu/sys/cdefs.h 3 4
# 1 /usr/include/i386-gnu/bits/wordsize.h 1 3 4
# 360 /usr/include/i386-gnu/sys/cdefs.h 2 3 4
# 357 /usr/include/features.h 2 3 4
# 388 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/gnu/stubs.h 1 3 4
# 1 /usr/include/i386-gnu/bits/wordsize.h 1 3 4
# 5 /usr/include/i386-gnu/gnu/stubs.h 2 3 4
# 1 /usr/include/i386-gnu/gnu/stubs-32.h 1 3 4
# 8 /usr/include/i386-gnu/gnu/stubs.h 2 3 4
# 389 /usr/include/features.h 2 3 4
# 30 /usr/include/errno.h 2 3 4
# 1 /usr/include/i386-gnu/bits/errno.h 1 3 4
# 10 /usr/include/i386-gnu/bits/errno.h 3 4
enum __error_t_codes
{
EPERM = ((0x10 26) | ((1) 0x3fff)),
ENOENT = ((0x10 26) | ((2) 0x3fff)),
ESRCH = ((0x10 26) | ((3) 0x3fff)),
EINTR = ((0x10 26) | ((4) 0x3fff)),
EIO = ((0x10 26) | ((5) 0x3fff)),
ENXIO = ((0x10 26) | ((6) 0x3fff)),
E2BIG = ((0x10 26) | ((7) 0x3fff)),
ENOEXEC = ((0x10 26) | ((8) 0x3fff)),
EBADF = ((0x10 26) | ((9) 0x3fff)),
ECHILD = ((0x10 26) | ((10) 0x3fff)),
EDEADLK = ((0x10 26) | ((11) 0x3fff)),
ENOMEM = ((0x10 26) | ((12) 0x3fff)),
EACCES = ((0x10 26) | ((13) 0x3fff)),
EFAULT = ((0x10 26) | ((14) 0x3fff)),
ENOTBLK = ((0x10 26) | ((15) 0x3fff)),
EBUSY = ((0x10 26) | ((16) 0x3fff)),
EEXIST = ((0x10 26) | ((17) 0x3fff)),
EXDEV = ((0x10 26) | ((18) 0x3fff)),
ENODEV = ((0x10 26) | ((19) 0x3fff)),
ENOTDIR = ((0x10 26) | ((20) 0x3fff)),
EISDIR = ((0x10 26) | ((21) 0x3fff)),
EINVAL = ((0x10 26) | ((22) 0x3fff)),
EMFILE = ((0x10 26) | ((24) 0x3fff)),
ENFILE = ((0x10 26) | ((23) 0x3fff)),
ENOTTY = ((0x10 26) | ((25) 0x3fff)),
ETXTBSY = ((0x10 26) | ((26) 0x3fff)),
EFBIG = ((0x10 26) | ((27) 0x3fff)),
ENOSPC = ((0x10 26) | ((28) 0x3fff)),
ESPIPE = ((0x10 26) | ((29) 0x3fff)),
EROFS = ((0x10 26) | ((30) 0x3fff)),
EMLINK = ((0x10 26) | ((31) 0x3fff)),
EPIPE = ((0x10 26) | ((32) 0x3fff)),
EDOM = ((0x10 26) | ((33) 0x3fff)),
ERANGE = ((0x10 26) | ((34) 0x3fff)),
EAGAIN = ((0x10 26) | ((35) 0x3fff)),
EINPROGRESS = ((0x10 26) | ((36) 0x3fff)),
EALREADY = ((0x10 26) | ((37) 0x3fff)),
ENOTSOCK = ((0x10 26) | ((38) 0x3fff)),
EMSGSIZE = ((0x10 26) | ((40) 0x3fff)),
EPROTOTYPE = ((0x10 26) | ((41) 0x3fff)),
ENOPROTOOPT = ((0x10 26) | ((42) 0x3fff)),
EPROTONOSUPPORT = ((0x10 26) | ((43) 0x3fff)),
ESOCKTNOSUPPORT = ((0x10 26) | ((44) 0x3fff)),
EOPNOTSUPP = ((0x10 26) | ((45) 0x3fff)),
EPFNOSUPPORT = ((0x10 26) | ((46) 0x3fff)),
EAFNOSUPPORT = ((0x10 26) | ((47) 0x3fff)),
EADDRINUSE = ((0x10 26) | ((48) 0x3fff)),
EADDRNOTAVAIL = ((0x10 26) | ((49) 0x3fff)),
ENETDOWN = ((0x10 26) | ((50) 0x3fff)),
ENETUNREACH = ((0x10 26) | ((51) 0x3fff)),
ENETRESET = ((0x10 26) | ((52) 0x3fff)),
ECONNABORTED = ((0x10 26) | ((53) 0x3fff)),
ECONNRESET = ((0x10 26) | ((54) 0x3fff)),
ENOBUFS = ((0x10 26) | ((55) 0x3fff)),
EISCONN = ((0x10 26) | ((56) 0x3fff)),
ENOTCONN = ((0x10 26) | ((57) 0x3fff)),
EDESTADDRREQ = ((0x10 26) | ((39) 0x3fff)),
ESHUTDOWN = ((0x10 26) | ((58) 0x3fff)),
ETOOMANYREFS = ((0x10 26) | ((59) 0x3fff)),
ETIMEDOUT = ((0x10 26) | ((60) 0x3fff)),
ECONNREFUSED = ((0x10 26) | ((61) 0x3fff)),
ELOOP = ((0x10 26) | ((62) 0x3fff)),
ENAMETOOLONG = ((0x10 26) | ((63) 0x3fff)),
EHOSTDOWN = ((0x10 26) | ((64) 0x3fff)),
EHOSTUNREACH = ((0x10 26) | ((65) 0x3fff)),
ENOTEMPTY = ((0x10 26) | ((66) 0x3fff)),
EPROCLIM = ((0x10 26) | ((67) 0x3fff)),
EUSERS = ((0x10 26) | ((68) 0x3fff)),
EDQUOT = ((0x10 26) | ((69) 0x3fff
Strange output of gcc -E on GNU/Hurd
Hi folks, In looking at libprelude it generates a lot of files using gawk. The attached file is generated from gawk and then is run through gcc -E. On GNU/Hurd, I get significantly different results than I do from GNU/Linux. Anyone have a clue why that might be or where I would look to debug this? Thanks! Barry deFreese /* Output of mkerrcodes.awk. DO NOT EDIT. */ /* errnos.h - List of system error values. Copyright (C) 2003, 2004 g10 Code GmbH This file is part of libgpg-error. libgpg-error is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. libgpg-error is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with libgpg-error; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include errno.h #ifdef E2BIG E2BIG PRELUDE_ERROR_E2BIG #endif #ifdef EACCES EACCES PRELUDE_ERROR_EACCES #endif #ifdef EADDRINUSE EADDRINUSE PRELUDE_ERROR_EADDRINUSE #endif #ifdef EADDRNOTAVAIL EADDRNOTAVAIL PRELUDE_ERROR_EADDRNOTAVAIL #endif #ifdef EADV EADVPRELUDE_ERROR_EADV #endif #ifdef EAFNOSUPPORT EAFNOSUPPORTPRELUDE_ERROR_EAFNOSUPPORT #endif #ifdef EAGAIN EAGAIN PRELUDE_ERROR_EAGAIN #endif #ifdef EALREADY EALREADYPRELUDE_ERROR_EALREADY #endif #ifdef EAUTH EAUTH PRELUDE_ERROR_EAUTH #endif #ifdef EBACKGROUND EBACKGROUND PRELUDE_ERROR_EBACKGROUND #endif #ifdef EBADE EBADE PRELUDE_ERROR_EBADE #endif #ifdef EBADF EBADF PRELUDE_ERROR_EBADF #endif #ifdef EBADFD EBADFD PRELUDE_ERROR_EBADFD #endif #ifdef EBADMSG EBADMSG PRELUDE_ERROR_EBADMSG #endif #ifdef EBADR EBADR PRELUDE_ERROR_EBADR #endif #ifdef EBADRPC EBADRPC PRELUDE_ERROR_EBADRPC #endif #ifdef EBADRQC EBADRQC PRELUDE_ERROR_EBADRQC #endif #ifdef EBADSLT EBADSLT PRELUDE_ERROR_EBADSLT #endif #ifdef EBFONT EBFONT PRELUDE_ERROR_EBFONT #endif #ifdef EBUSY EBUSY PRELUDE_ERROR_EBUSY #endif #ifdef ECANCELED ECANCELED PRELUDE_ERROR_ECANCELED #endif #ifdef ECHILD ECHILD PRELUDE_ERROR_ECHILD #endif #ifdef ECHRNG ECHRNG PRELUDE_ERROR_ECHRNG #endif #ifdef ECOMM ECOMM PRELUDE_ERROR_ECOMM #endif #ifdef ECONNABORTED ECONNABORTEDPRELUDE_ERROR_ECONNABORTED #endif #ifdef ECONNREFUSED ECONNREFUSEDPRELUDE_ERROR_ECONNREFUSED #endif #ifdef ECONNRESET ECONNRESET PRELUDE_ERROR_ECONNRESET #endif #ifdef ED ED PRELUDE_ERROR_ED #endif #ifdef EDEADLK EDEADLK PRELUDE_ERROR_EDEADLK #endif #ifdef EDEADLOCK EDEADLOCK PRELUDE_ERROR_EDEADLOCK #endif #ifdef EDESTADDRREQ EDESTADDRREQPRELUDE_ERROR_EDESTADDRREQ #endif #ifdef EDIED EDIED PRELUDE_ERROR_EDIED #endif #ifdef EDOM EDOMPRELUDE_ERROR_EDOM #endif #ifdef EDOTDOT EDOTDOT PRELUDE_ERROR_EDOTDOT #endif #ifdef EDQUOT EDQUOT PRELUDE_ERROR_EDQUOT #endif #ifdef EEXIST EEXIST PRELUDE_ERROR_EEXIST #endif #ifdef EFAULT EFAULT PRELUDE_ERROR_EFAULT #endif #ifdef EFBIG EFBIG PRELUDE_ERROR_EFBIG #endif #ifdef EFTYPE EFTYPE PRELUDE_ERROR_EFTYPE #endif #ifdef EGRATUITOUS EGRATUITOUS PRELUDE_ERROR_EGRATUITOUS #endif #ifdef EGREGIOUS EGREGIOUS PRELUDE_ERROR_EGREGIOUS #endif #ifdef EHOSTDOWN EHOSTDOWN PRELUDE_ERROR_EHOSTDOWN #endif #ifdef EHOSTUNREACH EHOSTUNREACHPRELUDE_ERROR_EHOSTUNREACH #endif #ifdef EIDRM EIDRM PRELUDE_ERROR_EIDRM #endif #ifdef EIEIO EIEIO PRELUDE_ERROR_EIEIO #endif #ifdef EILSEQ EILSEQ PRELUDE_ERROR_EILSEQ #endif #ifdef EINPROGRESS EINPROGRESS PRELUDE_ERROR_EINPROGRESS #endif #ifdef EINTR EINTR PRELUDE_ERROR_EINTR #endif #ifdef EINVAL EINVAL PRELUDE_ERROR_EINVAL #endif #ifdef EIO EIO PRELUDE_ERROR_EIO #endif #ifdef EISCONN EISCONN PRELUDE_ERROR_EISCONN #endif #ifdef EISDIR EISDIR PRELUDE_ERROR_EISDIR #endif #ifdef EISNAM EISNAM PRELUDE_ERROR_EISNAM #endif #ifdef EL2HLT EL2HLT PRELUDE_ERROR_EL2HLT #endif #ifdef EL2NSYNC EL2NSYNCPRELUDE_ERROR_EL2NSYNC #endif #ifdef EL3HLT EL3HLT PRELUDE_ERROR_EL3HLT #endif #ifdef EL3RST EL3RST PRELUDE_ERROR_EL3RST #endif #ifdef ELIBACC ELIBACC PRELUDE_ERROR_ELIBACC #endif #ifdef ELIBBAD ELIBBAD PRELUDE_ERROR_ELIBBAD #endif #ifdef ELIBEXEC ELIBEXECPRELUDE_ERROR_ELIBEXEC #endif #ifdef ELIBMAX ELIBMAX PRELUDE_ERROR_ELIBMAX #endif #ifdef ELIBSCN ELIBSCN PRELUDE_ERROR_ELIBSCN #endif #ifdef ELNRNG ELNRNG PRELUDE_ERROR_ELNRNG #endif #ifdef ELOOP ELOOP PRELUDE_ERROR_ELOOP #endif #ifdef EMEDIUMTYPE EMEDIUMTYPE PRELUDE_ERROR_EMEDIUMTYPE #endif #ifdef EMFILE EMFILE PRELUDE_ERROR_EMFILE #endif #ifdef EMLINK EMLINK PRELUDE_ERROR_EMLINK #endif #ifdef EMSGSIZE EMSGSIZEPRELUDE_ERROR_EMSGSIZE #endif #ifdef EMULTIHOP EMULTIHOP
Re: netdde not detecting cards
On 7/6/2012 12:10 AM, Samuel Thibault wrote: Hello, To people who were having problems of network card detection with netdde, I've found that it was hardcoded that only bus 0 and 2 were probed for. The attached patch should probe for all buses, and probably fix the issue you were having. Check your lspci output, if it looked like 03:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) i.e. first number for the network board is neither 00 nor 02, then it's normal that netdde was not finding your card. You can apply the attached patch to the hurd package, install it, and rebuild netdde, or just wait for the next hurd+netdde upload, or CD image build. Samuel Rockin', I will see if I can try this tonight. Thanks Samuel!! Barry
Re: Account request
On 5/9/2011 1:09 PM, Thomas Schwinge wrote: Hallo Steven! On Mon, 9 May 2011 12:59:27 -0400, seth seth chaotics...@gmail.com wrote: Thanks for creating the account but unable to login, is flubber.bddebian.comdown? His whole network is unreachable at the moment. I've already informed Barry; he's going to have a look. Grüße, Thomas Should be back up now. Please let me know if there is still an issue. Thanks, Barry
Re: blubber and grubber down
On 3/2/2010 8:48 AM, Thomas Schwinge wrote: Hello! On Mon, Mar 01, 2010 at 11:09:35PM +0100, Ludovic Courtès wrote: Thomas Schwinge tho...@schwinge.name writes: But now grubber is re-installed, too. ‘goober’ and ‘clubber’ are down, too. OK, but I can't do anything about these: I can only manage those that are domUs on zenhost, http://www.gnu.org/software/hurd/public_hurd_boxen.html. Barry? Regards, Thomas I'll check on goober. Clubber seems to keep rebooting on startup. Not sure if it is a grub issue or kernel issue. :( Barry
Re: plan to work on user-level device drivers
Da Zheng wrote: Hi, I am thinking about writing user-level device drivers. When I searched Internet, I found the paper An Architecture for Device Drivers Executing as User-Level Tasks written by David B. Golub, Guy G. Sotomayor and Freeman L. Rawson, III. It might be exactly what I want but unfortunately, the paper isn't available for downloading on Internet. I wonder if anyone knows the work and more importantly, where I can download the code. My plan is to write a user-level device driver for testing and ideally, to port ddekit to Mach if it is possible. The first device I choose will be ethernet card, which I think is the one I relatively familiar with. Any suggestion is welcome! Zheng Da Zheng Da, Yay!! Someone is finally tackling this!! I have been looking at DDEKit, XNUs IOKit, and some others. I don't know shite but if I can be of any help, let me know! Barry
Re: grub segfaulting
Samuel Thibault wrote:
Barry deFreese, le Sun 31 May 2009 10:03:32 -0400, a écrit :
Even if I run the unmodified version I get segfaults with the
following error on the console:
end_request: I/O error, dev 02:00, sector 0
Any clue on what could be causing that?
Doesn't gdb give you a backtrace?
Samuel
Yes, sorry, I meant to post this yesterday.
#0 0x0804b520 in grub_memmove (to=0x12ae480, from=0x12b5200, len=4096)
at char_io.c:1298
d0 = 2752
d1 = 19617600
d2 = 19589568
#1 0x0804cdbc in rawread (drive=128, sector=68364, byte_offset=0,
byte_len=4096, buf=0x12ae480 ) at disk_io.c:281
sector_num = 68355
length = 19152896
num_sect = 54
track = 68355
size = 4096
bufaddr = 0x12b5200
slen = 8
sectors_per_vtrack = 63
sector_size_bits = value optimized out
#2 0x0804e2ac in devread (sector=68364, byte_offset=0, byte_len=4096,
buf=0x12ae480 ) at disk_io.c:327
No locals.
#3 0x0804e5b5 in ext2_rdfsb (fsblock=1, buffer=value optimized out)
at fsys_ext2fs.c:331
No locals.
#4 0x0804eb42 in ext2fs_dir (dirname=0x125ac61 boot) at fsys_ext2fs.c:793
current_ino = 2
updir_ino = 2
str_chk = 18817012
linkbuf =
hs\026\001▒\215#\001\...@+\001Ⱥ*\001▒\215#\001g▒\000\000x9\002\000▒\205\037\001\001\000\000\000{r\026\001\000~\000\000\000~\000\000\000@+\001▒*\001▒\234\004\b\005\000\000\000\...@+\001\000~\000\000\005\000\000\0008▒*\001\005\000\000\000\000~\000\000\000~\000\000\200\000\000\000\005\000\000\0008▒*\001\211\235\004\b\005,
'\0' repeats 15 times,
9\016\006\0018y\006\001x▒*\001▒*\004\001\r\000\000\000\...@+\0014▒*\0018▒*\001\017▒\004\b4▒*\001\000\002\000\000\000@$\001\000\000\000\000\000\002\000\000\210▒*\001▒▒\004\b4▒*\001\...@+\001\000...
link_count = 0
rest = 0x125ac65
ch = 47 '/'
loc = 0
map = value optimized out
dp = value optimized out
#5 0x0804dab4 in grub_open (filename=0x125ac60 /boot) at disk_io.c:1649
ptr = 0x Address 0x out of bounds
tmp = 19578600
list_addr = value optimized out
#6 0x0805dfa3 in dump_func (arg=0x125ac59 (hd0,1)/boot, flags=1)
at builtins.c:1245
to = 0x125ac72 /tmp/grub_stage1
fp = value optimized out
c = value optimized out
#7 0x0805e6ec in enter_cmdline (heap=0x125ac54 dump (hd0,1)/boot,
forever=1)
at cmdline.c:173
builtin = (struct builtin *) 0x80691b0
arg = 0x1 Address 0x1 out of bounds
#8 0x08057c4f in cmain () at stage2.c:1119
builtin = value optimized out
state = 195
prev_config_len = 8388608
prev_menu_len = -24968191
cmdline = 0x0
default_file = value optimized out
i = value optimized out
is_opened = value optimized out
#9 0x0804c2f0 in init_bios_info () at common.c:336
max_addr = value optimized out
cont = value optimized out
memtmp = value optimized out
addr = 19246164
drive = 129
#10 0x0804a5c3 in doit.5701 () at asmstub.c:141
env_for_exit = {{__jmpbuf = {-1, 19152904, 16928356, 16928152,
19578864, 134522260}, __mask_was_saved = 0, __saved_mask = 0}}
save_char = -1
serial_device = 0x0
serial_fd = -1
apm_bios_info = {version = 0, cseg = 0, offset = 0, cseg_16 = 0,
dseg_16 = 0, cseg_len = 0, cseg_16_len = 0, dseg_16_len = 0}
grub_scratch_mem = 0x1244000
install_partition = 131072
linux_text_len = 0
ascii_key_map = {0 repeats 129 times}
linux_data_tmp_addr = 0x0
console_current_color = 0
boot_drive = 0
device_map = (char **) 0x80769b8
io_map = {0 repeats 128 times}
version_string = 0.97
config_file = /boot/grub/menu.lst, '\0' repeats 108 times
linux_data_real_addr = 0x0
bios_key_map = {0 repeats 129 times}
disks = (struct geometry *) 0x80751b0
saved_entryno = 0
Thanks,
Barry
grub segfaulting
Hi folks, I was playing with grub to see if I could find out where it is dying. It was working OK but now it is core dumping. Even if I run the unmodified version I get segfaults with the following error on the console: end_request: I/O error, dev 02:00, sector 0 Any clue on what could be causing that? Thanks, Barry
Gnumach Cleanup 13
Hi,
For kicks I did some more cleanup of warnings in gnumach. The majority
of the fixes are for initialization of incompatible pointer.. errors.
Here is a changelog:
2008-07-19 Barry deFreese [EMAIL PROTECTED]
* device/device_emul.h (struct device_emulation_ops): Takes
mach_device_t not void *.
* i386/i386at/autoconf.c: Make forward declarations for comintr()
and lprintr() match prototype.
+ Add brackets around initialization members for bus_ctlr and
bus_device structs.
* i386/i386at/conf.c (struct dev_ops): Pass nomap instead of nulldev
for map parameter.
* i386/i386at/pic_isa.c: Add type for external function
declarations. (Type defaults to int, make void).
Thanks,
Barry deFreese
Index: device/device_emul.h
===
RCS file: /sources/hurd/gnumach/device/Attic/device_emul.h,v
retrieving revision 1.1.2.1
diff -u -p -r1.1.2.1 device_emul.h
--- device/device_emul.h27 Mar 2007 22:47:09 - 1.1.2.1
+++ device/device_emul.h11 Nov 2008 02:05:02 -
@@ -32,9 +32,9 @@
/* Each emulation layer provides these operations. */
struct device_emulation_ops
{
- void (*reference) (void *);
- void (*dealloc) (void *);
- ipc_port_t (*dev_to_port) (void *);
+ void (*reference) (mach_device_t);
+ void (*dealloc) (mach_device_t);
+ ipc_port_t (*dev_to_port) (mach_device_t);
io_return_t (*open) (ipc_port_t, mach_msg_type_name_t,
dev_mode_t, char *, device_t *);
io_return_t (*close) (void *);
@@ -55,9 +55,9 @@ struct device_emulation_ops
io_return_t (*map) (void *, vm_prot_t, vm_offset_t,
vm_size_t, ipc_port_t *, boolean_t);
void (*no_senders) (mach_no_senders_notification_t *);
- io_return_t (*write_trap) (void *, dev_mode_t,
+ io_return_t (*write_trap) (mach_device_t, dev_mode_t,
recnum_t, vm_offset_t, vm_size_t);
- io_return_t (*writev_trap) (void *, dev_mode_t,
+ io_return_t (*writev_trap) (mach_device_t, dev_mode_t,
recnum_t, io_buf_vec_t *, vm_size_t);
};
Index: i386/i386at/autoconf.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/autoconf.c,v
retrieving revision 1.2.2.13
diff -u -p -r1.2.2.13 autoconf.c
--- i386/i386at/autoconf.c 9 Nov 2006 23:33:44 - 1.2.2.13
+++ i386/i386at/autoconf.c 11 Nov 2008 02:05:02 -
@@ -49,12 +49,12 @@
#if NCOM 0
extern struct bus_driver comdriver;
-extern int comintr();
+extern voidcomintr();
#endif /* NCOM */
#if NLPR 0
extern struct bus_driver lprdriver;
-extern int lprintr();
+extern voidlprintr();
#endif /* NLPR */
struct bus_ctlrbus_master_init[] = {
@@ -62,7 +62,7 @@ structbus_ctlrbus_master_init[] = {
/* drivername unit intraddresslen phys_address
adaptor alive flags splpic */
- 0
+ {0}
};
@@ -91,7 +91,7 @@ structbus_device bus_device_init[] = {
#endif /* NLPR 0 */
#endif /* MACH_LPR */
- 0
+ {0}
};
/*
Index: i386/i386at/conf.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/conf.c,v
retrieving revision 1.4.2.15
diff -u -p -r1.4.2.15 conf.c
--- i386/i386at/conf.c 1 Apr 2007 22:10:40 - 1.4.2.15
+++ i386/i386at/conf.c 11 Nov 2008 02:05:02 -
@@ -75,7 +75,7 @@ struct dev_opsdev_name_list[] =
cninit() we stick something appropriate here through the
indirect list */
{ cn, nulldev,nulldev,nulldev,
- nulldev, nulldev,nulldev,nulldev,
+ nulldev, nulldev,nulldev,nomap,
nodev,nulldev,nulldev,0,
nodev },
Index: i386/i386at/pic_isa.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/pic_isa.c,v
retrieving revision 1.1.1.1.4.2
diff -u -p -r1.1.1.1.4.2 pic_isa.c
--- i386/i386at/pic_isa.c 22 Jul 2008 22:28:07 - 1.1.1.1.4.2
+++ i386/i386at/pic_isa.c 11 Nov 2008 02:05:02 -
@@ -30,8 +30,8 @@
/* These interrupts are always present */
-extern intnull(), fpintr(), hardclock(), kdintr();
-extern prtnull();
+extern void intnull(), fpintr(), hardclock(), kdintr();
+extern void prtnull();
void (*ivect[NINTR])() = {
/* 00 */hardclock, /* always */
Re: About merging the Hurd homepage and the Hurd wiki
Thomas Schwinge wrote: Hello! It has been my plan for a long time, but needed to much work effort to be done immediatelly. So I postponed it. Has now perhaps the time come to revisit this topic, in context of just having lost http (port 80) access to the machine hosting the Hurd wiki? Driving both a homepage, http://hurd.gnu.org/, that is very infrequently updated, plus a wiki, (read-only mirror available at http://www.thomas.schwinge.homeip.net/hurd-wiki/), that gets some more care, seems a bit too much. So what about merging them? SNIP Regards, Thomas Thomas, I'm really fine either way. I feel really bad that this has happened as I was told by some colleagues that Verizon was not blocking port 80. In one case I think it makes a great deal of sense. The only thing I liked about having it on my boxen was that it was actually running on Hurd so it showed people that it isn't just vaporware. I suppose that is a moot point though. Thanks, Barry
[task #5487] cthreads - pthreads
Follow-up Comment #3, task #5487 (project hurd): OK I'm attaching my latest patch. I've taken zentons work and taken it all the way. Everything compiles but there are issues. Static linking has issues. If I let the build system do it's thing, ext2fs and ext2fs --help return values however its linked to the binary libpthread. If I link against the ascii pthread in hurd/libpthread it either gives some goofy errors or hangs. For some reason I cannot get gdb to give me debugging symbols or it hangs even inside of gdb and I can't attach to the pid because ps also hangs. I have added pt-cond-implies but it is not completed and neal thinks the code should be inlined anyway. Obviously it needs testing, testing, testing. ___ Reply to this item at: http://savannah.gnu.org/task/?5487 ___ Message sent via/by Savannah http://savannah.gnu.org/
[task #5487] cthreads - pthreads
Additional Item Attachment, task #5487 (project hurd): File name: hurd_pthread_09102008.diff.gz Size:131 KB ___ Reply to this item at: http://savannah.gnu.org/task/?5487 ___ Message sent via/by Savannah http://savannah.gnu.org/
ext2fs crashes lately
Hi folks, With all of the gnumach builds I have been doing on goober lately, I keep seeing ext2fs.static crashes about every third day. Today I got the following: ext2fs.static: /var/tmp/hurd-20071119/build-tree/hurd/libports/port-ref.c:31:ports_port_ref: Assertion 'pi-refcnt || pi-weakrefcnt' failed. Thanks, Barry deFreese
Some questionable warnings
Hi folks, While doing some more cleanup I see that the tt_ospeed and tt_ispeed element in struct tty_status in include/device/tty_status.h are ints while t_ospeed and t_ispeed in the tty struct in device/tty.h they are char. Anyone have a clue why that might be? I grepped the ChangeLogs quickly but didn't seen anything obvious. boot_map() in kern/bootstrap.c doesn't appear to be used anywhere. Remove it or leave it? vm/memory_object_default.user.c: implicit declaration of function mach_msg_send_from_kernel. All I need to do is include kern/ipc_mig.h. However, vm/memory_object_default.cli However, it just includes mach/memory_object_default.defs. Makes sense. That one just includes mach/std_types.defs and mach/mach_types.defs. Can I get away with including a normal header here? I guess that is enough dumb questions for the evening. Thanks! Barry
Useless info - hurd warnings
Hi folks, Just for kicks I built the hurd to see what kinds of warnings it gets. Of the 1434 warnings reported, 1297 of them are in pfinet/* :) Barry BTW, if anyone cares I'm building gnumach and hurd with gcc-4.3 for these warnings just since it seems to be a little more strict.
Gnumach cleanup 12
Hi folks,
Here is another. Mainly incompatible pointer types or use of
uninitialized variables warnings.
Thanks,
Barry deFreese
2008-07-23 Barry deFreese [EMAIL PROTECTED]
* device/chario.c (ttyinput_many): Change chars param to char *.
* device/tty.h (ttyinput_many): Likewise.
* i386/i386/pcb.h: Include mach/exec/exec.h.
* i386/i386at/autoconf.h: Include chips/busses.h.
* i386/i386at/model_dep.c (inittodr): Cast new_time.seconds as u_int *.
* ipc/mach_port.c (mach_port_insert_right): Cast poly as ipc_object_t.
* ipc/mach_debug.c (host_ipc_hash_info): Initialize size to 0 to make
the
compiler believe that there is no bug.
* ipc/mach_debug.c (mach_port_space_info): Likewise for tree_size and
table_size.
* i386/i386at/com.c (commctl): Likewise for b.
* i386/i386/trap.c (user_trap): Likewise for exc.
* i386/i386/user_ldt.c (i386_set_ldt): Likewise for old_copy_object.
* i386/i386at/com.c (comintr): Check line_statiOR not lineiOR.
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: device/chario.c
===
RCS file: /sources/hurd/gnumach/device/Attic/chario.c,v
retrieving revision 1.3.2.3
diff -u -p -r1.3.2.3 chario.c
--- device/chario.c 17 Jul 2008 00:04:00 - 1.3.2.3
+++ device/chario.c 24 Jul 2008 02:18:41 -
@@ -1007,7 +1007,7 @@ void ttyinput(
*/
void ttyinput_many(
struct tty *tp,
- unsigned char *chars,
+ char *chars,
int count)
{
/*
Index: device/tty.h
===
RCS file: /sources/hurd/gnumach/device/Attic/tty.h,v
retrieving revision 1.1.1.1.4.2
diff -u -p -r1.1.1.1.4.2 tty.h
--- device/tty.h 22 Jul 2008 22:28:06 - 1.1.1.1.4.2
+++ device/tty.h 24 Jul 2008 02:18:41 -
@@ -106,7 +106,7 @@ extern void ttyinput(
extern void ttyinput_many(
struct tty * tp,
- unsigned char * chars,
+ char * chars,
int count);
extern boolean_t ttymodem(
Index: i386/i386/pcb.h
===
RCS file: /sources/hurd/gnumach/i386/i386/Attic/pcb.h,v
retrieving revision 1.1.2.2
diff -u -p -r1.1.2.2 pcb.h
--- i386/i386/pcb.h 20 Jul 2008 17:05:36 - 1.1.2.2
+++ i386/i386/pcb.h 24 Jul 2008 02:18:41 -
@@ -27,6 +27,7 @@
#define _I386_PCB_H_
#include sys/types.h
+#include mach/exec/exec.h
extern void pcb_init (thread_t thread);
Index: i386/i386/trap.c
===
RCS file: /sources/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.14
diff -u -p -r1.5.2.14 trap.c
--- i386/i386/trap.c 22 Jul 2008 22:28:06 - 1.5.2.14
+++ i386/i386/trap.c 24 Jul 2008 02:18:41 -
@@ -369,7 +369,7 @@ dump_ss(regs);
int user_trap(regs)
register struct i386_saved_state *regs;
{
- int exc;
+ int exc = 0;
int code;
int subcode;
register int type;
Index: i386/i386/user_ldt.c
===
RCS file: /sources/hurd/gnumach/i386/i386/user_ldt.c,v
retrieving revision 1.2.4.6
diff -u -p -r1.2.4.6 user_ldt.c
--- i386/i386/user_ldt.c 20 Jul 2008 17:05:37 - 1.2.4.6
+++ i386/i386/user_ldt.c 24 Jul 2008 02:18:41 -
@@ -111,7 +111,7 @@ i386_set_ldt(thread, first_selector, des
pcb_t pcb;
vm_size_t ldt_size_needed;
int first_desc = sel_idx(first_selector);
- vm_map_copy_t old_copy_object;
+ vm_map_copy_t old_copy_object = NULL;
if (thread == THREAD_NULL)
return KERN_INVALID_ARGUMENT;
Index: i386/i386at/autoconf.h
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/autoconf.h,v
retrieving revision 1.1.2.1
diff -u -p -r1.1.2.1 autoconf.h
--- i386/i386at/autoconf.h 20 Jul 2008 17:05:37 - 1.1.2.1
+++ i386/i386at/autoconf.h 24 Jul 2008 02:18:41 -
@@ -26,6 +26,7 @@
#define _AUTOCONF_H_
#include mach/std_types.h
+#include chips/busses.h
/*
* probeio:
Index: i386/i386at/com.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.7
diff -u -p -r1.3.2.7 com.c
--- i386/i386at/com.c 22 Jul 2008 22:28:06 - 1.3.2.7
+++ i386/i386at/com.c 24 Jul 2008 02:18:42 -
@@ -529,7 +529,7 @@ int unit;
((tp-t_flags(EVENP|ODDP)) == EVENP ||
(tp-t_flags(EVENP|ODDP)) == ODDP)) {
/* parity error */;
- } else if (lineiOR !comoverrun) {
+ } else if (line_statiOR !comoverrun) {
printf(com%d: overrun\n, unit);
comoverrun = 1;
} else if (line_stat (iFE | iBRKINTR)) {
@@ -751,7 +751,7 @@ commctl(
spl_t s;
int unit;
vm_offset_t dev_addr;
- register int b;
+ register int b = 0;
unit = minor(tp-t_dev);
Index: i386/i386at/model_dep.c
Gnumach cleanup 11
Hi folks,
Here is another patch that cleans up the makes foo from bar without a
cast warnings.
I'm a little curious if using (void *)port cast is correct in the calls
to tty_portdeath()?
I also could use some guidance on these warnings (they all come from
basically the same call):
../kern/startup.c:297: warning: passing argument 1 of 'kvtophys' makes
integer from pointer without a cast
../i386/i386/pcb.c:236: warning: passing argument 1 of 'kvtophys' makes
integer from pointer without a cast
../i386/i386/pcb.c:311: warning: passing argument 1 of 'kvtophys' makes
integer from pointer without a cast
Also, I am still not fixing anything under linux/*
I haven't included a changelog yet since this will probably need
reviewed and/or fixed.
Thanks as always,
Barry
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: i386/i386at/com.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.6
diff -u -p -r1.3.2.6 com.c
--- i386/i386at/com.c 20 Jul 2008 17:05:37 - 1.3.2.6
+++ i386/i386at/com.c 22 Jul 2008 17:12:39 -
@@ -433,7 +433,7 @@ io_return_t comportdeath(dev, port)
dev_t dev;
mach_port_tport;
{
- return (tty_portdeath(com_tty[minor(dev)], port));
+ return (tty_portdeath(com_tty[minor(dev)], (void *)port));
}
io_return_t
Index: i386/i386at/kd.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.15
diff -u -p -r1.5.2.15 kd.c
--- i386/i386at/kd.c20 Jul 2008 17:05:38 - 1.5.2.15
+++ i386/i386at/kd.c22 Jul 2008 17:12:40 -
@@ -590,7 +590,7 @@ kdportdeath(dev, port)
dev_t dev;
mach_port_t port;
{
- return (tty_portdeath(kd_tty, port));
+ return (tty_portdeath(kd_tty, (void *)port));
}
/*ARGSUSED*/
Index: i386/i386at/kd_mouse.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd_mouse.c,v
retrieving revision 1.3.2.9
diff -u -p -r1.3.2.9 kd_mouse.c
--- i386/i386at/kd_mouse.c 20 Jul 2008 17:05:38 - 1.3.2.9
+++ i386/i386at/kd_mouse.c 22 Jul 2008 17:12:40 -
@@ -603,7 +603,7 @@ mouse_handle_byte(ch)
mousebuf[mousebufindex++] = ch;
if (mouse_char_wanted) {
mouse_char_wanted = FALSE;
- wakeup(mousebuf);
+ wakeup((unsigned int)mousebuf);
}
return;
}
Index: i386/i386at/lpr.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/lpr.c,v
retrieving revision 1.1.1.1.4.10
diff -u -p -r1.1.1.1.4.10 lpr.c
--- i386/i386at/lpr.c 20 Jul 2008 17:05:38 - 1.1.1.1.4.10
+++ i386/i386at/lpr.c 22 Jul 2008 17:12:40 -
@@ -202,7 +202,7 @@ lprportdeath(dev, port)
dev_t dev;
mach_port_tport;
{
- return (tty_portdeath(lpr_tty[minor(dev)], port));
+ return (tty_portdeath(lpr_tty[minor(dev)], (void *)port));
}
io_return_t
Index: i386/intel/pmap.c
===
RCS file: /sources/hurd/gnumach/i386/intel/pmap.c,v
retrieving revision 1.4.2.19
diff -u -p -r1.4.2.19 pmap.c
--- i386/intel/pmap.c 18 Nov 2007 17:33:07 - 1.4.2.19
+++ i386/intel/pmap.c 22 Jul 2008 17:12:41 -
@@ -927,7 +927,7 @@ void pmap_destroy(p)
vm_object_unlock(pmap_object);
}
}
- kmem_free(kernel_map, p-dirbase, INTEL_PGBYTES);
+ kmem_free(kernel_map, (vm_offset_t)p-dirbase, INTEL_PGBYTES);
zfree(pmap_zone, (vm_offset_t) p);
}
Index: ipc/ipc_kmsg.c
===
RCS file: /sources/hurd/gnumach/ipc/ipc_kmsg.c,v
retrieving revision 1.2.2.11
diff -u -p -r1.2.2.11 ipc_kmsg.c
--- ipc/ipc_kmsg.c 16 Jul 2008 00:51:03 - 1.2.2.11
+++ ipc/ipc_kmsg.c 22 Jul 2008 17:12:41 -
@@ -531,7 +531,7 @@ ipc_kmsg_get(msg, size, kmsgp)
ikm_init(kmsg, size);
}
- if (copyinmsg((char *) msg, (char *) kmsg-ikm_header, size)) {
+ if (copyinmsg((vm_offset_t) msg, (vm_offset_t) kmsg-ikm_header,
size)) {
ikm_free(kmsg);
return MACH_SEND_INVALID_DATA;
}
@@ -601,7 +601,7 @@ ipc_kmsg_put(msg, kmsg, size)
ikm_check_initialized(kmsg, kmsg-ikm_size);
- if (copyoutmsg((char *) kmsg-ikm_header, (char *) msg, size))
+ if (copyoutmsg((vm_offset_t) kmsg-ikm_header, (vm_offset_t) msg,
size))
mr = MACH_RCV_INVALID_DATA;
else
mr = MACH_MSG_SUCCESS;
Index: ipc/mach_msg.c
Re: Gnumach cleanup 11
How about this one?
Not too sure about the syntax of the changelog.
Thanks!
Barry deFreese
2008-07-23 Barry deFreese [EMAIL PROTECTED]
* i386/i386/locore.h (copyinmsg, copyoutmsg):
Cast parameters as void* rather than vm_offset_t.
* i386/i386at/com.c (comportdeath): Cast port as ipc_port_t in
tty_portdeath call.
* i386/i386at/kd.c (kdportdeath): Likewise.
* i386/i386at/lpr.c (lprportdeath): Likewise.
* i386/i386at/kd_mouse.c (mouse_handle_byte): Cast param to wakeup() as
vm_offset_t.
* i386/intel/pmap.c (pmap_destroy): Cast arg 2 of kmem_free() to
vm_offset_t.
* i386/intel/pmap.h: Cast all arg 1 params to kvtophy() to vm_offset_t.
* ipc/ipc_kmsg.c: Remove casts from params to copyinmsg and
copyoutmsg calls.
* ipc/mach_msg.c: Likewise.
* kern/exceptions.c: Likewise.
* ipc/mach_msg.c: Remove casts from params to copyout calls.
* ipc/bootstrap.c: Likewise.
* kern/ipc_tt.c (mach_ports_register): Cast memory[i] as ipc_port_t in
assignment.
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: i386/i386/locore.h
===
RCS file: /sources/hurd/gnumach/i386/i386/Attic/locore.h,v
retrieving revision 1.1.2.3
diff -u -p -r1.1.2.3 locore.h
--- i386/i386/locore.h 20 Dec 2006 21:57:55 - 1.1.2.3
+++ i386/i386/locore.h 23 Jul 2008 04:35:49 -
@@ -26,11 +26,11 @@
extern int copyin (const void *userbuf, void *kernelbuf, size_t cn);
-extern int copyinmsg (vm_offset_t userbuf, vm_offset_t kernelbuf, size_t cn);
+extern int copyinmsg (const void *userbuf, void *kernelbuf, size_t cn);
extern int copyout (const void *kernelbuf, void *userbuf, size_t cn);
-extern int copyoutmsg (vm_offset_t kernelbuf, vm_offset_t userbuf, size_t cn);
+extern int copyoutmsg (const void *kernelbuf, void *userbuf, size_t cn);
extern int call_continuation (continuation_t continuation);
Index: i386/i386at/com.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.6
diff -u -p -r1.3.2.6 com.c
--- i386/i386at/com.c 20 Jul 2008 17:05:37 - 1.3.2.6
+++ i386/i386at/com.c 23 Jul 2008 04:35:49 -
@@ -433,7 +433,7 @@ io_return_t comportdeath(dev, port)
dev_t dev;
mach_port_t port;
{
- return (tty_portdeath(com_tty[minor(dev)], port));
+ return (tty_portdeath(com_tty[minor(dev)], (ipc_port_t)port));
}
io_return_t
Index: i386/i386at/kd.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.15
diff -u -p -r1.5.2.15 kd.c
--- i386/i386at/kd.c 20 Jul 2008 17:05:38 - 1.5.2.15
+++ i386/i386at/kd.c 23 Jul 2008 04:35:50 -
@@ -590,7 +590,7 @@ kdportdeath(dev, port)
dev_t dev;
mach_port_t port;
{
- return (tty_portdeath(kd_tty, port));
+ return (tty_portdeath(kd_tty, (ipc_port_t)port));
}
/*ARGSUSED*/
Index: i386/i386at/kd_mouse.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd_mouse.c,v
retrieving revision 1.3.2.9
diff -u -p -r1.3.2.9 kd_mouse.c
--- i386/i386at/kd_mouse.c 20 Jul 2008 17:05:38 - 1.3.2.9
+++ i386/i386at/kd_mouse.c 23 Jul 2008 04:35:50 -
@@ -603,7 +603,7 @@ mouse_handle_byte(ch)
mousebuf[mousebufindex++] = ch;
if (mouse_char_wanted) {
mouse_char_wanted = FALSE;
- wakeup(mousebuf);
+ wakeup((vm_offset_t)mousebuf);
}
return;
}
Index: i386/i386at/lpr.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/lpr.c,v
retrieving revision 1.1.1.1.4.10
diff -u -p -r1.1.1.1.4.10 lpr.c
--- i386/i386at/lpr.c 20 Jul 2008 17:05:38 - 1.1.1.1.4.10
+++ i386/i386at/lpr.c 23 Jul 2008 04:35:50 -
@@ -202,7 +202,7 @@ lprportdeath(dev, port)
dev_t dev;
mach_port_t port;
{
- return (tty_portdeath(lpr_tty[minor(dev)], port));
+ return (tty_portdeath(lpr_tty[minor(dev)], (ipc_port_t)port));
}
io_return_t
Index: i386/intel/pmap.c
===
RCS file: /sources/hurd/gnumach/i386/intel/pmap.c,v
retrieving revision 1.4.2.19
diff -u -p -r1.4.2.19 pmap.c
--- i386/intel/pmap.c 18 Nov 2007 17:33:07 - 1.4.2.19
+++ i386/intel/pmap.c 23 Jul 2008 04:35:50 -
@@ -927,7 +927,7 @@ void pmap_destroy(p)
vm_object_unlock(pmap_object);
}
}
- kmem_free(kernel_map, p-dirbase, INTEL_PGBYTES);
+ kmem_free(kernel_map, (vm_offset_t)p-dirbase, INTEL_PGBYTES);
zfree(pmap_zone, (vm_offset_t) p);
}
Index: i386/intel/pmap.h
===
RCS file: /sources/hurd/gnumach/i386/intel/pmap.h,v
Gnumach cleanup 10 second attempt
Here is an updated patch. I hope I got it right this time.
I added __attribute__ ((noreturn)) to i386_exception but I now get this
warning:
../i386/i386/trap.c: In function 'i386_exception':
../i386/i386/trap.c:634: warning: 'noreturn' function does return
But I don't see a return anywhere!??
Thanks,
Barry deFreese
Your favorite idiot.
2008-07-19 Barry deFreese [EMAIL PROTECTED]
* chips/busses.h (struct bus_ctlr): *intr return void instead of int.
* i386/i386/ipl.h (ivect[]): return void instead of int.
* i386/i386at/pic_isa.h (ivect[]): Likewise.
* i386/i386at/kd_mouse.c (mouseintr): Likewise.
* i386/i386at/com.c (comintr): Likewise.
* i386/i386/trap.c (user_trap): Add __attribute__ ((noreturn)).
* i386/i386at/com.c (comstop): Return 0 at end of function.
* i386/i386at/kd.c (kdcnputc, kdstart, kdintr): Return void instead
of int. (kdstop, kdcnprobe): Return 0 at end of function.
* i386/i386at/lpr.c (lprintr, lprstart): Return void instead of int.
(lprstart): Don't return numeric values any longer.
* kern/eventcount.c (evc_wait_clear): Return a value.
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: chips/busses.h
===
RCS file: /sources/hurd/gnumach/chips/Attic/busses.h,v
retrieving revision 1.1.1.1.4.1
diff -u -p -r1.1.1.1.4.1 busses.h
--- chips/busses.h 30 Apr 2007 20:30:10 - 1.1.1.1.4.1
+++ chips/busses.h 21 Jul 2008 14:52:46 -
@@ -73,7 +73,7 @@ struct bus_ctlr {
struct bus_driver *driver; /* myself, as a device */
char *name; /* readability */
int unit; /* index in driver */
- int (*intr)(); /* interrupt handler(s) */
+ void (*intr)(); /* interrupt handler(s) */
vm_offset_t address; /* device virtual address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
@@ -93,7 +93,7 @@ struct bus_device {
struct bus_driver *driver; /* autoconf info */
char *name; /* my name */
int unit;
- int (*intr)();
+ void (*intr)();
vm_offset_t address; /* device address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
Index: i386/i386/ipl.h
===
RCS file: /sources/hurd/gnumach/i386/i386/ipl.h,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 ipl.h
--- i386/i386/ipl.h 13 Oct 2006 14:32:32 - 1.2.2.1
+++ i386/i386/ipl.h 21 Jul 2008 14:52:47 -
@@ -70,7 +70,7 @@ WITH THE USE OR PERFORMANCE OF THIS SOFT
#ifdef KERNEL
#ifndef __ASSEMBLER__
#include machine/machspl.h
-extern int (*ivect[])();
+extern void (*ivect[])();
extern int iunit[];
extern int intpri[];
#endif /* __ASSEMBLER__ */
Index: i386/i386/trap.c
===
RCS file: /sources/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.13
diff -u -p -r1.5.2.13 trap.c
--- i386/i386/trap.c 20 Jul 2008 17:40:18 - 1.5.2.13
+++ i386/i386/trap.c 21 Jul 2008 14:52:47 -
@@ -63,7 +63,7 @@
extern void exception();
extern void thread_exception_return();
-extern void i386_exception();
+extern void i386_exception() __attribute__ ((noreturn));
#if MACH_KDB
boolean_t debug_all_traps_with_kdb = FALSE;
Index: i386/i386at/com.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.6
diff -u -p -r1.3.2.6 com.c
--- i386/i386at/com.c 20 Jul 2008 17:05:37 - 1.3.2.6
+++ i386/i386at/com.c 21 Jul 2008 14:52:47 -
@@ -47,8 +47,8 @@
extern void timeout(), ttrstrt();
-int comprobe(), comintr(), comstart(), commctl();
-void comattach();
+int comprobe(), comstart(), commctl();
+void comattach(), comintr();
static void comparam();
int comstop(), comgetstat(), comsetstat();
@@ -489,7 +489,7 @@ unsigned int count;
return (D_SUCCESS);
}
-int
+void
comintr(unit)
int unit;
{
@@ -816,6 +816,7 @@ int flags;
{
if ((tp-t_state TS_BUSY) (tp-t_state TS_TTSTOP) == 0)
tp-t_state |= TS_FLUSH;
+ return 0;
}
/*
Index: i386/i386at/kd.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.15
diff -u -p -r1.5.2.15 kd.c
--- i386/i386at/kd.c 20 Jul 2008 17:05:38 - 1.5.2.15
+++ i386/i386at/kd.c 21 Jul 2008 14:52:47 -
@@ -118,7 +118,7 @@ boolean_t kdcheckmagic();
int kdcnprobe(struct consdev *cp);
int kdcninit(struct consdev *cp);
int kdcngetc(dev_t dev, int wait);
-int kdcnputc(dev_t dev, int c);
+void kdcnputc(dev_t dev, int c);
int do_modifier (int, Scancode, boolean_t);
/*
@@ -461,7 +461,7 @@ kdopen(dev, flag, ior)
io_req_t ior;
{
struct tty *tp;
- int
Re: Gnumach cleanup 10 second attempt
Samuel Thibault wrote: snip Indeed, but functions implicitely return at the end of it... And in that case, that's why I said to add noreturn to i386_exception and similar. exception() is one of those similars. Samuel Samuel, OK fair enough but exception() does do a few returns, you want me to go ahead and remove those also? Thanks, Barry
Re: Gnumach cleanup 10 second attempt
Samuel Thibault wrote: Barry deFreese, le Mon 21 Jul 2008 11:33:57 -0400, a écrit : Samuel Thibault wrote: snip Indeed, but functions implicitely return at the end of it... And in that case, that's why I said to add noreturn to i386_exception and similar. exception() is one of those similars. OK fair enough but exception() does do a few returns, you want me to go ahead and remove those also? See the comment, they shouldn't be reached, so yes you can, but also add noreturn to the functions that are called just before, etc. ;) Samuel OK I'm getting closer. I added noreturn to exception and exception_raise but I'm still getting the warning that exception_raise is returning. I thought maybe it was assert() but Asser() has __attribute__ ((noreturn)). Any idea on what else I'm missing? Sorry to be such a pain. Thanks, Barry
Gnumach cleanup 10 attempt3
Here they are again.
Thanks,
Barry deFreese
2008-07-19 Barry deFreese [EMAIL PROTECTED]
* chips/busses.h (struct bus_ctlr): *intr return void instead of int.
* i386/i386/ipl.h (ivect[]): return void instead of int.
* i386/i386at/pic_isa.h (ivect[]): Likewise.
* i386/i386at/kd_mouse.c (mouseintr): Likewise.
* i386/i386at/com.c (comintr): Likewise.
* i386/i386at/kd.c (kdcnputc, kdstart, kdintr): Likewise.
* i386/i386/trap.c (exception, thread_exception_return, i386_exception):
Add __attribute__ ((noreturn)).
* i386/i386at/kd.c (kdcnputc, kdstart, kdintr): Return void instead
of int. (kdstop, kdcnprobe): Return 0 at end of function.
* i386/i386at/lpr.c (lprintr, lprstart): Return void instead of int.
(lprstart): Don't return numeric values any longer.
* kern/eventcount.c (evc_wait_clear): Return a value.
* kern/exceptions.c (exception, exception_try_task,
exception_no_server,
exception_raise, exception_raise_continue,
exception_raise_continue_slow,
exception_raise_continue_fast): Add __attribute__ ((noreturn)).
(exception, exceptio_try_task, exception_raise,
exception_raise_continue_slow, exception_raise_continue_fast):
Remove spurious returns.
(exception_no_server): Add panic() on return from thread_halt_self().
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: chips/busses.h
===
RCS file: /sources/hurd/gnumach/chips/Attic/busses.h,v
retrieving revision 1.1.1.1.4.1
diff -u -p -r1.1.1.1.4.1 busses.h
--- chips/busses.h 30 Apr 2007 20:30:10 - 1.1.1.1.4.1
+++ chips/busses.h 22 Jul 2008 01:38:43 -
@@ -73,7 +73,7 @@ struct bus_ctlr {
struct bus_driver *driver; /* myself, as a device */
char *name; /* readability */
int unit; /* index in driver */
- int (*intr)(); /* interrupt handler(s) */
+ void (*intr)(); /* interrupt handler(s) */
vm_offset_t address; /* device virtual address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
@@ -93,7 +93,7 @@ struct bus_device {
struct bus_driver *driver; /* autoconf info */
char *name; /* my name */
int unit;
- int (*intr)();
+ void (*intr)();
vm_offset_t address; /* device address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
Index: i386/i386/ipl.h
===
RCS file: /sources/hurd/gnumach/i386/i386/ipl.h,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 ipl.h
--- i386/i386/ipl.h 13 Oct 2006 14:32:32 - 1.2.2.1
+++ i386/i386/ipl.h 22 Jul 2008 01:38:43 -
@@ -70,7 +70,7 @@ WITH THE USE OR PERFORMANCE OF THIS SOFT
#ifdef KERNEL
#ifndef __ASSEMBLER__
#include machine/machspl.h
-extern int (*ivect[])();
+extern void (*ivect[])();
extern int iunit[];
extern int intpri[];
#endif /* __ASSEMBLER__ */
Index: i386/i386/trap.c
===
RCS file: /sources/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.13
diff -u -p -r1.5.2.13 trap.c
--- i386/i386/trap.c 20 Jul 2008 17:40:18 - 1.5.2.13
+++ i386/i386/trap.c 22 Jul 2008 01:38:43 -
@@ -60,10 +60,10 @@
#include debug.h
-extern void exception();
-extern void thread_exception_return();
+extern void exception() __attribute__ ((noreturn));
+extern void thread_exception_return() __attribute__ ((noreturn));
-extern void i386_exception();
+extern void i386_exception() __attribute__ ((noreturn));
#if MACH_KDB
boolean_t debug_all_traps_with_kdb = FALSE;
Index: i386/i386at/com.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.6
diff -u -p -r1.3.2.6 com.c
--- i386/i386at/com.c 20 Jul 2008 17:05:37 - 1.3.2.6
+++ i386/i386at/com.c 22 Jul 2008 01:38:43 -
@@ -47,8 +47,8 @@
extern void timeout(), ttrstrt();
-int comprobe(), comintr(), comstart(), commctl();
-void comattach();
+int comprobe(), comstart(), commctl();
+void comattach(), comintr();
static void comparam();
int comstop(), comgetstat(), comsetstat();
@@ -489,7 +489,7 @@ unsigned int count;
return (D_SUCCESS);
}
-int
+void
comintr(unit)
int unit;
{
@@ -816,6 +816,7 @@ int flags;
{
if ((tp-t_state TS_BUSY) (tp-t_state TS_TTSTOP) == 0)
tp-t_state |= TS_FLUSH;
+ return 0;
}
/*
Index: i386/i386at/kd.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.15
diff -u -p -r1.5.2.15 kd.c
--- i386/i386at/kd.c 20 Jul 2008 17:05:38 - 1.5.2.15
+++ i386/i386at/kd.c 22 Jul 2008 01:38
Re: Gnumach cleanup 10 attempt3
On Tue, 2008-07-22 at 03:37 +0100, Samuel Thibault wrote:
Barry deFreese, le Mon 21 Jul 2008 22:15:17 -0400, a écrit :
(kdstop): Return 0 at end of function.
Mmm, kdstop should probably just return void, like kdstart. You'll also
need to fix the t_stop and t_start members of struct tty accordingly.
Else, it looks fine.
Samuel
OK, how about now?
Thanks Samuel!
Barry
2008-07-19 Barry deFreese [EMAIL PROTECTED]
* chips/busses.h (struct bus_ctlr): *intr return void instead of int.
* i386/i386/ipl.h (ivect[]): return void instead of int.
* i386/i386at/pic_isa.h (ivect[]): Likewise.
* i386/i386at/kd_mouse.c (mouseintr): Likewise.
* i386/i386at/com.c (comintr): Likewise.
* i386/i386at/kd.c (kdcnputc, kdstart, kdstop, kdintr): Likewise.
* i386/i386/trap.c (exception, thread_exception_return, i386_exception):
Add __attribute__ ((noreturn)).
* i386/i386at/kd.c (kdcnprobe): Return 0 at end of function.
* i386/i386at/lpr.c (lprintr, lprstart): Return void instead of int.
(lprstart): Don't return numeric values any longer.
* kern/eventcount.c (evc_wait_clear): Return a value.
* kern/exceptions.c (exception, exception_try_task,
exception_no_server,
exception_raise, exception_raise_continue,
exception_raise_continue_slow,
exception_raise_continue_fast): Add __attribute__ ((noreturn)).
(exception, exceptio_try_task, exception_raise,
exception_raise_continue_slow, exception_raise_continue_fast):
Remove spurious returns.
(exception_no_server): Add panic() on return from thread_halt_self().
* device/tty.h (struct tty): Make t_start and t_stop return void.
? INSTALL
? Makefile.in
? aclocal.m4
? autom4te.cache
? build-aux
? config.h.in
? configure
? doc/mach.info
? doc/mach.info-1
? doc/mach.info-2
? doc/stamp-vti
? doc/version.texi
Index: chips/busses.h
===
RCS file: /sources/hurd/gnumach/chips/Attic/busses.h,v
retrieving revision 1.1.1.1.4.1
diff -u -p -r1.1.1.1.4.1 busses.h
--- chips/busses.h 30 Apr 2007 20:30:10 - 1.1.1.1.4.1
+++ chips/busses.h 22 Jul 2008 03:30:22 -
@@ -73,7 +73,7 @@ struct bus_ctlr {
struct bus_driver *driver; /* myself, as a device */
char *name; /* readability */
int unit; /* index in driver */
- int (*intr)(); /* interrupt handler(s) */
+ void (*intr)(); /* interrupt handler(s) */
vm_offset_t address; /* device virtual address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
@@ -93,7 +93,7 @@ struct bus_device {
struct bus_driver *driver; /* autoconf info */
char *name; /* my name */
int unit;
- int (*intr)();
+ void (*intr)();
vm_offset_t address; /* device address */
int am; /* address modifier */
vm_offset_t phys_address;/* device phys address */
Index: device/tty.h
===
RCS file: /sources/hurd/gnumach/device/Attic/tty.h,v
retrieving revision 1.1.1.1.4.1
diff -u -p -r1.1.1.1.4.1 tty.h
--- device/tty.h 17 Jul 2008 00:04:01 - 1.1.1.1.4.1
+++ device/tty.h 22 Jul 2008 03:30:22 -
@@ -52,10 +52,10 @@ struct tty {
struct cirbuf t_outq; /* output buffer */
char * t_addr; /* device pointer */
int t_dev; /* device number */
- int (*t_start)(struct tty *);
+ void (*t_start)(struct tty *);
/* routine to start output */
#define t_oproc t_start
- int (*t_stop)(struct tty *, int);
+ void (*t_stop)(struct tty *, int);
/* routine to stop output */
int (*t_mctl)(struct tty *, int, int);
/* (optional) routine to control
Index: i386/i386/ipl.h
===
RCS file: /sources/hurd/gnumach/i386/i386/ipl.h,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 ipl.h
--- i386/i386/ipl.h 13 Oct 2006 14:32:32 - 1.2.2.1
+++ i386/i386/ipl.h 22 Jul 2008 03:30:23 -
@@ -70,7 +70,7 @@ WITH THE USE OR PERFORMANCE OF THIS SOFT
#ifdef KERNEL
#ifndef __ASSEMBLER__
#include machine/machspl.h
-extern int (*ivect[])();
+extern void (*ivect[])();
extern int iunit[];
extern int intpri[];
#endif /* __ASSEMBLER__ */
Index: i386/i386/trap.c
===
RCS file: /sources/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.13
diff -u -p -r1.5.2.13 trap.c
--- i386/i386/trap.c 20 Jul 2008 17:40:18 - 1.5.2.13
+++ i386/i386/trap.c 22 Jul 2008 03:30:23 -
@@ -60,10 +60,10 @@
#include debug.h
-extern void exception();
-extern void thread_exception_return();
+extern void exception() __attribute__ ((noreturn));
+extern void thread_exception_return() __attribute__ ((noreturn));
-extern void i386_exception();
+extern void i386_exception() __attribute__ ((noreturn));
#if MACH_KDB
boolean_t debug_all_traps_with_kdb = FALSE;
Index
device_reference and device_deallocate
Hi folks, I ran in to a strange one while working on some more gnumach cleanup. device_reference was renamed to mach_device_reference quite a while back and device_deallocate was renamed to mach_device_deallocate. However, ds_routines.c still define device_reference and device_deallocate and kern/ipc_mig.c still calls them. As far as I can tell kern/ipc_mig.c is the only code that still references. Do you think I'm safe to remove those functions from ds_routines.c and update kern/ipc_mig.c to use mach_device_*? (Which are now prototyped in device/dev_hdr.h bye the way). Thanks! Barry deFreese
New clean-up patch for gnumach
Hi folks, I've been lazy and useless for months now so I thought I'd do some more gnumach clean-up. Here is a patch to fix several implicit declaration of function warnings. Let me know what you think. Thanks, Barry gnumach_cleanup7.diff.gz Description: GNU Zip compressed data
Another clean-up (printf format warnings)
Here is another clean up patch. This one is for all of the format foo expects type bar.. warnings. I'm not sure if this is the preferred method of fixing (by casting the vars) or if the format should be changed? Thanks, Barry gnumach_cleanup8.diff.gz Description: GNU Zip compressed data
Re: Another clean-up (printf format warnings)
Barry deFreese wrote: Here is another clean up patch. This one is for all of the format foo expects type bar.. warnings. I'm not sure if this is the preferred method of fixing (by casting the vars) or if the format should be changed? Thanks, Barry Here is an improved patch that fixes the format strings rather than casting the variables. Thanks, Barry deFreese gnumach_cleanup8v2.diff.gz Description: GNU Zip compressed data
Re: New machine for shitbox / wiki system
Samuel Thibault wrote: Thomas Schwinge, le Tue 08 Jul 2008 09:41:20 +0200, a écrit : Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Yes. That's also what I'd suggest. There'd as well be the plus of other people being able to reboot/recover hung systems, if Barry is on vacations, etc. Samuel, perhaps you can help to set-up such a system? Sure, the hard part is just a matter of having a working Debian system on it, install the packages from http://youpibouh.thefreecat.org/hurd-xen and a xen-hypervisor-something-nonpae package, update-grub, reboot with that, and give me ssh access. Samuel Samuel, By working Debian system do you mean Debian GNU/Linux or a Debian Hurd system? Thanks, Barry deFreese
New machine for shitbox
Hi folks, OK, I have finally put a new machine in for shitbox. It's still not super high-end (700Mhz PIII with 384Mb) but it should at least be more stable and come back up when rebooting. I also did a dist-upgrade. I hope that wasn't a bad thing. I'm still a little concerned about the HD but I'm not sure how much trouble it would be to get it up on a new one. I'm up for suggestions, etc. I also have a nicer machine P4 (2.4Ghz or so I think) that I was thinking about replacing flubber with but I am wondering if that makes the most sense? Since flubber is now the wiki code and such, should it be taken out of the more public role? I'm thinking maybe using the gnubber hardware for flubber and set up a new gnubber might make more sense. Thoughts? Thanks! Barry deFreese
On vacation
Folks, I am going to be on vacation from June 17th to about the 27th so if any of the public boxes or the wiki dies I, unfortunately, will not be able to bring them back up until I return. I apologize ahead of time for any inconvenience this may cause and the fact that I have not gotten the replacement hardware installed yet. I swear I will work on new hardware for at least the wiki box and flubber when I return from vacation. Thanks, Barry deFreese
Re: Wiki
Arne Babenhauserheide wrote: Yes, and it's quite alive already: http://www.bddebian.com/~wiki/ And it has the importen (imo) strength, that it is being hosted on a hurd machine. There's not much better for getting people to realize that Hurd is good than using it for the Websites. Besides: Which distro runs on bddebian? Best wishes, Arne Debian, what else is there for Hurd? ;-) Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #17646] glibc: ``-z relro''
Samuel Thibault wrote: Follow-up Comment #2, bug #17646 (project hurd): Which testcase makes the dynamic loader crash? I tried compiling 2.5 with z_relro, I am currently using it, and it seems to work fine. People can try a debian package from my repo at http://dept-info.labri.fr/~thibault/debian-hurd main unstable ___ Samuel, I think I had that experience also but it killed gnumach somewhere later down the line iirc. Of course I could be wrong. Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd Pthreads
Thomas Schwinge wrote: Hello! On Sat, Nov 25, 2006 at 07:51:44PM -0500, Barry deFreese wrote: OK, I have a HUGE cthreads-pthreads patch going that is going fairly well. Did you ever publish this somewhere? Did you base it on the patches that are available at http://savannah.gnu.org/task/?5487? Regards, Thomas Thomas, No because I never got much of a response and because Leonardo and I ran into the problem with one of the Hurdish functions (I'm having a brainfart atm and can't remember which one). And also no, I didn't base it on the patch on savannah, I started from scratch. I probably still have it around if you have any interest. Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Carl Fredrik Hammar to work on libchannel
Thomas Schwinge wrote: Hello! bug-hurd, please welcome Carl Fredrik Hammar, who will be working on http://savannah.gnu.org/task/?1619, ``designing and writing libchannel, a library for streams'', as a Google Summer of Code 2007 project. Richard Braun will officially be his mentor, but of course we all will support them. Giving Fredrik a warm welcome shouldn't be too difficult given that he had already previously introduced himself and his proposal on this very mailing list. Some rules. They may be rather obvious, but let's nevertheless write them down here. Mentoring shall take place on the public [EMAIL PROTECTED] mailing list (save organizational or personal issues, of course), so that everyone can contribute to the process and also that everyone else can learn alongside. The student shall post reports of his efforts to the mailing list. While reserving that right, we won't come up with a fixed interval right now, but the student should at least post his status when requested by the mentor. (If there are discussions going on, these are of course already a statement about the project's status.) Well then, let the fun begin! Good luck, Fredrik! Regards, Thomas and Richard W00t, welcome Fredrik, and good luck!!! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: A translator for `/dev/shm'
Roland McGrath wrote: Fixing tmpfs shouldn't be so bad. Is anyone trying? In the absence of tmpfs, what's wrong with a plain directory on the root filesystem? As far as I know Ben (bing) has tried without much success unfortunately. Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Alternative to './configure' ?
Ashish Gokhale wrote: Hello, It looks like 'configure' script has been removed from gnumach-1-branch. Is there any alternative to this script? is it a temporary state of the repository? my local copy of sources is broken i am not able to build the kernel. Thank you, Ashish Gokhale Ashish, The gnumach brach has been automakified. You need to run autoreconf or whatever to generate configure. Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: build error : osit.version.h less than required ???
Ashish Gokhale wrote: Hi, Once again I attempt to build the mach kernel using gnumach_1_branch, but I get following error. --- configure: error: version in oskit/version.h less than required 19991121 --- How do I resolve this? Thank you, AG Ashish, Are you sure you are pulling the gnumach-1-branch? You have to do something like the following: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/hurd co -r gnumach-1-branch gnumach Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Device drivers in Mach?
[EMAIL PROTECTED] wrote: On Wed, Mar 21, 2007 at 10:00:29PM +0100, Richard Braun wrote: Mach is old [...] [...] Hurd on L4 project is stalled [...] Sooo... what's the plan? Stay with Mach and feed that old stuff? Leslie I suppose that depends on who you ask. Some of the bigwigs are looking at a totally new system based on Coyotos. Some of us are trying to do what we can with Mach, while Richard is writing a mach-compatible replacement that I don't believe he intends to actually utilize for Hurd but I may be wrong there. I personally liked the idea of L4 but apparently there were technical concerns that were way over my head. (Though from what I understand, some of the new derivatives of L4 might be more compatible). Welcome to Free Software. You are welcome to do whatever you wish, which means everyone does what they want and no one steers the ship! :-) Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Google Summer of Code 2007
Thomas Schwinge wrote: Hello! On Mon, Mar 05, 2007 at 01:14:30AM +0100, I wrote: Like they did last year, Google is again hosting a Summer of Code program in 2007. See http://code.google.com/soc/. The GNU project is again going to apply for being a mentoring organization and has asked the various GNU subproject to already begin collecting ideas about projects being worth attending there. See http://gnu.org/software/soc-projects/guidelines.html Suitable tasks would again be made up from the ones already registered at http://savannah.gnu.org/task/?group=hurd and from the ones you are going to send in now. I began to make some thoughts about that; please comment. http://savannah.gnu.org/task/?1619 -- designing and writing libchannel, a library for streams This should be fine to put up as a project. http://savannah.gnu.org/task/?5469 -- Rewrite pfinet The libchannel project should be done before, or at least in parallel, I'd say. http://savannah.gnu.org/task/?5470 -- Implement pfinet6 The ``rewrite pfinet'' project should be done before (and libchannel transitively), or at least in parallel, I'd say. http://savannah.gnu.org/task/?5485 -- Design and implement a sound system Both libchannel and the device driver update should be done before, or at least in parallel, I'd say. http://savannah.gnu.org/task/?5486 -- Andrew File System (AFS) This should be fine to put up as a project. http://savannah.gnu.org/task/?5487 -- cthreads - pthreads How much is actually left to be done? Consider that the GSoC is about writing code, not about debugging. http://savannah.gnu.org/task/?5488 -- Update the device driver glue code in GNU Mach Shall we publish that one as a project? http://savannah.gnu.org/task/?5489 -- GNU Mach's IPC / VM system This is most probably too complex for a GSoC project. http://savannah.gnu.org/task/?5497 -- nfs and nfsd Manuel Menal was working on that during the 2006 GSoC, but didn't get it to an end. His code is still available in the `mmenal-soc2006-nfs-branch' branch. Someone would have to check how much work there is left to be done, to decide if we can put it up as a project again. http://savannah.gnu.org/task/?5499 -- Logical Volume Manager (LVM) This should be fine to put up as a project. http://savannah.gnu.org/task/?5503 -- extended attributes How much is actually left to be done? Consider that a patch to add support for reading and writing of extended attributes is already available in http://savannah.gnu.org/patch/?5126. http://savannah.gnu.org/task/?6231 -- Implement support for futexes Is this a suitable project? http://savannah.gnu.org/task/?6584 -- Improve Xen support Is this a suitable project? http://savannah.gnu.org/task/?6612 -- Overriding the system's default servers Is this a suitable project? Further suggestions are of course still welcome! Regards, Thomas Are we talking Debian specific stuff or no? There still the Debian installer afair. Also, how about implementing PPP? I think there was something about being able to boot from a stow'd filesystem? Thanks! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Bug#413787: libc0.3: TLS patch
Samuel Thibault wrote: Hi, Thomas Schwinge, le Wed 07 Mar 2007 10:32:00 +0100, a écrit : On Wed, Mar 07, 2007 at 03:06:22AM +0100, Samuel Thibault wrote: Thanks to Barry's long glibc builds, here is at last a patch that builds a tls/__thread -enabled and working glibc. Great! BTW, by working, I mean that simple programs do work, event with __thread variables. Can you comment on the issues mentioned at http://savannah.gnu.org/bugs/?17644#comment2? Mmm, which issues? About the glibc-Mach interface, I don't really have any opinion ; I would just remind that glibc-linux interface uses a generic set_thread_area() syscall and a newtls parameter to the clone syscall, but the passed structure is very arch-specific anyway. About --without-__thread, it seems to work already (it got debugged on Linux in the meanwhile). The attached patch may be applied as soon as now, but do _not_ drop --without-tls and --without-__thread yet, because hurd's libpthread.so doesn't initialize TLS yet, and hence that would break all multithreaded applications. I'm now working on the Hurd part, I'll mail the bug when it is uploaded. Here is what Roland once wrote: http://lists.gnu.org/archive/html/hurd-devel/2003-02/msg1.html. Ah, thanks for digging out this, that'll be helpful. Samuel Folks, How do we go about getting this stuff upstream? I can file bugs and whatever but I know there are concerns from some (i.e. Ulrich) about some of the patches we have, such as the __libc_once fix. Thanks for all the work! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
glibc 2.5 with TLS make check errors
Hey folks, I'm checking make check output now. My log is here: http://www2.bddebian.com:8000/hurd/glibc/glibc25_tls/make_check1.log I trimmed out just a list of the errors here: http://www2.bddebian.com:8000/hurd/glibc/glibc25_tls/make_check1_errors.log I'll see if my dumb arse can debug some of them. Thanks! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Glibc-2.5 with TLS cont'd
Hey folks,
Thanks to Samuel I got past my errno problems but now I am getting this
error:
/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function
`__pause_nocancel':
../sysdeps/posix/pause.c:55: undefined reference to `sigsuspend_not_cancel'
collect2: ld returned 1 exit status
make[1]: *** [/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc.so] Error 1
make[1]: Leaving directory `/devel3/bdefreese/glibc-2.5/glibc-2.5'
make: *** [all] Error 2
This is the offending section from pause.c:
#ifndef NO_CANCELLATION
# include not-cancel.h
int
__pause_nocancel (void)
{
sigset_t set;
__sigemptyset (set);
__sigprocmask (SIG_BLOCK, NULL, set);
return sigsuspend_not_cancel (set);
}
#endif
As far as I can tell this stuff is coming from nptl. Do we want to head
down that road or should I be trying to work around this? I assume that
nptl would be A LOT more work?
Thanks,
Barry deFreese
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Building glibc 2.5 on Hurd: tls
Thomas Schwinge wrote: Hello! Support for tls for Hurd systems is still not fixed properly. Details are at http://savannah.gnu.org/bugs/?17644. To get a functional glibc-2_5-branch, this either needs to be fixed or the tls-requiring bits of glibc-2_5-branch have to be bend over to not require it. Regards, Thomas Hi folks, Just an FYI, I have built glibc-2.5 with all of Thomas's patches. Currently I am getting the following error: /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `mach_open_devstream': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:137: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `dealloc_ref': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:117: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `write_some': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:47: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `devstream_read': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:94: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__hurd_fail': ../hurd/hurd.h:76: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os:/devel3/bdefreese/glibc-2.5/glibc-2.5/hurd/hurdselect.c:202: more undefined references to `__libc_errno' follow /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__pause_nocancel': ../sysdeps/posix/pause.c:55: undefined reference to `sigsuspend_not_cancel' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__hurd_fail': ../hurd/hurd.h:76: undefined reference to `__libc_errno' ../hurd/hurd.h:76: undefined reference to `__libc_errno' ../hurd/hurd.h:76: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `execvp': /devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:66: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:77: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os:/devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:115: more undefined references to `__libc_errno' follow collect2: ld returned 1 exit status make[1]: *** [/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc.so] Error 1 make[1]: Leaving directory `/devel3/bdefreese/glibc-2.5/glibc-2.5' make: *** [all] Error 2 Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Drop Olivetti XP7/XP9?
Samuel Thibault wrote: Hi, Found yet another hideous hack in i386/intel/pmap.c for the old olivetti XP7/XP9. Any objection to my dropping it? Samue Not from me.. :-) Thanks Samuel! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH] Support for alignment in the zone allocator
Richard Braun wrote:
Here is a patch that does it all. Any comments ?
2006-12-30 Richard Braun [EMAIL PROTECTED]
Added alignment support in the zone allocator.
* kern/zalloc.c (ALIGN_SIZE_UP): New macro.
(zinit): New `align' parameter.
(zget_space): Likewise.
(zone_bootstrap): Updated call to zinit() with alignment of 0.
(zalloc): Updated call to zget_space() with the zone alignment.
* kern/zalloc.h (zone): New member `align'.
(zinit): Declaration updated as required.
* device/dev_lookup.c (dev_lookup_init): Updated call to zinit() with
alignment of 0.
* device/dev_pager.c (dev_pager_hash_init): Likewise.
(device_pager_init): Likewise.
* device/ds_routines.c (ds_init): Likewise.
(ds_trap_init): Likewise.
* device/net_io.c (net_io_init): Likewise.
* i386/i386/fpu.c (fpu_module_init): Likewise.
* i386/i386/pcb.c (pcb_module_init): Likewise.
* i386/intel/pmap.c (pmap_init): Likewise.
* ipc/ipc_init.c (ipc_bootstrap): Likewise.
* ipc/ipc_marequest.c (ipc_marequest_init): Likewise.
* kern/act.c (global_act_init): Likewise.
* kern/kalloc.c (kalloc_init): Likewise.
* kern/processor.c (pset_sys_init): Likewise.
* kern/task.c (task_init): Likewise.
* kern/thread.c (thread_init): Likewise.
* vm/vm_external.c (vm_external_module_initialize): Likewise.
* vm/vm_fault.c (vm_fault_init): Likewise.
* vm/vm_map.c (vm_map_init): Likewise.
* vm/vm_object.c (vm_object_bootstrap): Likewise.
* vm/vm_resident.c (vm_page_module_init): Likewise.
Index: device/dev_lookup.c
===
RCS file: /sources/hurd/gnumach/device/Attic/dev_lookup.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 dev_lookup.c
--- device/dev_lookup.c 25 Feb 1997 21:28:14 - 1.1.1.1
+++ device/dev_lookup.c 30 Dec 2006 10:42:23 -
@@ -401,7 +401,7 @@ dev_lookup_init()
simple_lock_init(dev_port_lock);
- dev_hdr_zone = zinit(sizeof(struct mach_device),
+ dev_hdr_zone = zinit(sizeof(struct mach_device), 0,
sizeof(struct mach_device) * NDEVICES,
PAGE_SIZE,
FALSE,
Index: device/dev_pager.c
===
RCS file: /sources/hurd/gnumach/device/dev_pager.c,v
retrieving revision 1.3.2.5
diff -u -p -r1.3.2.5 dev_pager.c
--- device/dev_pager.c 10 Nov 2006 01:22:57 - 1.3.2.5
+++ device/dev_pager.c 30 Dec 2006 10:42:24 -
@@ -174,6 +174,7 @@ void dev_pager_hash_init(void)
size = sizeof(struct dev_pager_entry);
dev_pager_hash_zone = zinit(
size,
+ 0,
size * 1000,
PAGE_SIZE,
FALSE,
@@ -727,6 +728,7 @@ void device_pager_init(void)
*/
size = sizeof(struct dev_pager);
dev_pager_zone = zinit(size,
+ 0,
(vm_size_t) size * 1000,
PAGE_SIZE,
FALSE,
Index: device/ds_routines.c
===
RCS file: /sources/hurd/gnumach/device/Attic/ds_routines.c,v
retrieving revision 1.6.2.7
diff -u -p -r1.6.2.7 ds_routines.c
--- device/ds_routines.c11 Nov 2006 00:54:05 - 1.6.2.7
+++ device/ds_routines.c30 Dec 2006 10:42:24 -
@@ -1471,7 +1471,7 @@ void ds_init()
*/
device_io_map-wait_for_space = TRUE;
- io_inband_zone = zinit(sizeof(io_buf_ptr_inband_t),
+ io_inband_zone = zinit(sizeof(io_buf_ptr_inband_t), 0,
1000 * sizeof(io_buf_ptr_inband_t),
10 * sizeof(io_buf_ptr_inband_t),
FALSE,
@@ -1519,7 +1519,7 @@ zone_t io_trap_zone;
void
ds_trap_init(void)
{
- io_trap_zone = zinit(IOTRAP_REQSIZE,
+ io_trap_zone = zinit(IOTRAP_REQSIZE, 0,
256 * IOTRAP_REQSIZE,
16 * IOTRAP_REQSIZE,
FALSE,
Index: device/net_io.c
===
RCS file: /sources/hurd/gnumach/device/net_io.c,v
retrieving revision 1.2.2.11
diff -u -p -r1.2.2.11 net_io.c
--- device/net_io.c 13 Nov 2006 21:30:36 - 1.2.2.11
+++ device/net_io.c 30 Dec 2006 10:42:25 -
@@ -1494,6 +1494,7 @@ net_io_init()
size = sizeof(struct net_rcv_port);
net_rcv_zone = zinit(size,
+0,
size * 1000,
PAGE_SIZE,
FALSE,
@@ -1501,6 +1502,7 @@ net_io_init()
size = sizeof(struct
Re: gdbserver for GNU/Hurd
Daniel Jacobowitz wrote: On Sat, Dec 23, 2006 at 04:31:55PM +0100, Mark Kettenis wrote: Has anyone ever worked on porting the GDB distribution's gdbserver to GNU/Hurd? I'm pretty sure the answer to that question is no. As far as I know. In case you don't know: this would allow for debugging programs on GNU/Hurd systems using a cross debugger running on another system (e.g. a non GNU/Hurd one). This is of advantage if you're cross compiling and then don't have to copy the source files to the target system for using gdb locally on there. But it'd be difficult to have access to all the advanced features a native GNU/Hurd GDB offers. It shouldn't be hard to add anything necessary to the remote protocol and if anyone was interested in working on it I'd be glad to offer advice. I'm looking at this just for fun. Should we add our own hurd-i386-foo files or gnu-i386-foo, or try to shoehorn our stuff into using something like linux-i386-low? Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Samuel Thibault wrote:
Barry deFreese, le Thu 21 Dec 2006 09:54:05 -0500, a écrit :
OK, that makes sense, sorry. It just takes a while to get through my
thick skull sometimes. So about my question about adding a struct for
the fxsr stuff. I don't really want to add a union of 4 structs right,
I need two unions of two structs? So I'd have something like this:
union i387_save_struct {
struct i386_fp_save;
struct i386_fpxsr_save;
}
and
union i387_regs_struct {
struct i386_fp_regs;
struct i386_fpxsr_regs;
}
Make sense?
Makes sense, but won't work. Remember that the size of a union is the
size of its biggest member. When you'll put both unions one after the
other in the i386_fpsave_state structure, i386_fp_regs will _not_
be just after i386_fp_save, just because sizeof(i386_fpxsr_save)
sizeof(i386_fp_save). The union has hence to be before the split into
structures.
Also, about structure, look at the Intel docs: only the XMM register
saving area doesn't have holes.
Samuel
OK, one more time. And if this is correct, I have two questions. 1)
What do I do with the xmm space, ignore it? 2) Where is the best place
to check for fxsr? Should it be done in fpu.c after we determine
fpu_type = FP_387?
Thanks as always and thanks especially to Samuel and Olaf for their time
and patience!
Barry
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Samuel Thibault wrote:
Barry deFreese, le Thu 21 Dec 2006 00:17:34 -0500, a écrit :
I apologize for keep going on about this but I still don't quite
understand why a seperate struct is needed for i386_fp_regs.
I told you: this permits to easily do what is written in fpu.c:
/*
* Ensure that reserved parts of the environment are 0.
*/
memset(user_fp_state, 0, sizeof(struct i386_fp_save));
user_fp_state-fp_control = ifps-fp_save_state.fp_control;
user_fp_state-fp_status = ifps-fp_save_state.fp_status;
user_fp_state-fp_tag = ifps-fp_save_state.fp_tag;
user_fp_state-fp_eip = ifps-fp_save_state.fp_eip;
user_fp_state-fp_cs = ifps-fp_save_state.fp_cs;
user_fp_state-fp_opcode = ifps-fp_save_state.fp_opcode;
user_fp_state-fp_dp = ifps-fp_save_state.fp_dp;
user_fp_state-fp_ds = ifps-fp_save_state.fp_ds;
*user_fp_regs = ifps-fp_regs;
With separate structs, the last line can be written that way, allowing
the compiler to optimize the copy. For getting the same result without
separate structs, we'd have to call an ugly explicit memcpy().
Samuel
Samuel,
OK, that makes sense, sorry. It just takes a while to get through my
thick skull sometimes. So about my question about adding a struct for
the fxsr stuff. I don't really want to add a union of 4 structs right,
I need two unions of two structs? So I'd have something like this:
union i387_save_struct {
struct i386_fp_save;
struct i386_fpxsr_save;
}
and
union i387_regs_struct {
struct i386_fp_regs;
struct i386_fpxsr_regs;
}
Make sense?
Thanks,
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach FP Struct (Beating a dead horse)
Heya gang,
I apologize for keep going on about this but I still don't quite
understand why a seperate struct is needed for i386_fp_regs. Here is
what gnumachs looks like:
struct i386_fp_save {
unsigned short fp_control; /* control */
unsigned short fp_unused_1;
unsigned short fp_status; /* status */
unsigned short fp_unused_2;
unsigned short fp_tag; /* register tags */
unsigned short fp_unused_3;
unsigned intfp_eip; /* eip at failed instruction */
unsigned short fp_cs; /* cs at failed instruction */
unsigned short fp_opcode; /* opcode of failed instruction */
unsigned intfp_dp; /* data address */
unsigned short fp_ds; /* data segment */
unsigned short fp_unused_4;
};
struct i386_fp_regs {
unsigned short fp_reg_word[5][8];
/* space for 8 80-bit FP
registers */
};
And here is how Linux does it:
struct i387_fsave_struct {
longcwd;
longswd;
longtwd;
longfip;
longfcs;
longfoo;
longfos;
longst_space[20]; /* 8*10 bytes for each FP-reg = 80 bytes */
longstatus; /* software status information */
};
Is there some reason that I am not understand that i386_fp_regs has to
be a seperate struct and not an element of i386_fp_save?
Thanks and sorry to keep griping on this,
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18502] Suboptimal cache configuration for IA-32 processors
Samuel Thibault wrote: Barry deFreese, le Thu 14 Dec 2006 21:57:49 -0500, a écrit : Samuel Thibault wrote: Barry deFreese, le Thu 14 Dec 2006 02:03:10 +, a écrit : That is just from running times on a little C program that counts to 10, so it's obviously not scientific. Try compiling something, gnumach for instance ;) Not much of a diff there either: gnumach build: No cache: 12:50 Cache: 12:25 What processor is this? Samuel Pentium II 733Mhz 384Mb Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18502] Suboptimal cache configuration for IA-32 processors
Samuel Thibault wrote: Barry deFreese, le Thu 14 Dec 2006 02:03:10 +, a écrit : That is just from running times on a little C program that counts to 10, so it's obviously not scientific. Try compiling something, gnumach for instance ;) Samuel Not much of a diff there either: gnumach build: No cache: 12:50 Cache: 12:25 Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18502] Suboptimal cache configuration for IA-32 processors
Follow-up Comment #2, bug #18502 (project hurd): OK, I built gnumach with the following in model_dep.c: set_cr0((get_cr0() | CR0_PG | CR0_WP) ~(CR0_CD | CR0_NW)); And I got worse performance: 0m0.040s 0m0.130s 0m0.000s 0m0.000s Booted back to normal gnumach: 0m0.010s 0m0.020s 0m0.000s 0m0.000s That is just from running times on a little C program that counts to 10, so it's obviously not scientific. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18502 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Help develop of GNU/Hurd project
christian nastasi wrote: I'm a GNU/Linux user with knowledge of several GNU tools and quite good of Linux Kernel. I would love to start using GNU/Hurd and I hope to give contribute, but I am new at it and now unfortunately I don't have a machine to install it. It has been hard for me to find a GNU/Hurd shell account, can somebody help me? I hope I could start as soon as possible. Thank you for your time, regards. -- Christian Nastasi GNU's Better Christian, I have 3 or 4 public boxes available. You can check out the hostnames/etc here: http://hurd.gnufans.org/bin/view/Hurd/PublicHurdBoxen You can find me or one of the Hurd usuals that can set you up and account on one of them on #hurd on freenode. Of course by using them, you might be subjected to my constant dumb questions! ;-) Barry deFreese (aka bddebian on IRC) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[patch #5622] Gnumach Clean-up patch 6 (ddb)
URL: http://savannah.gnu.org/patch/?5622 Summary: Gnumach Clean-up patch 6 (ddb) Project: The GNU Hurd Submitted by: bddebian Submitted on: Thursday 12/07/2006 at 19:38 Category: GNU Mach Priority: 3 - Low Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None Wiki-like text discussion box: ___ Details: Hi folks. Just wanted to put this somewhere so it didn't get lost. Thanks, Barry. ___ File Attachments: --- Date: Thursday 12/07/2006 at 19:38 Name: gnumach_cleanup_6.diff Size: 29kB By: bddebian http://savannah.gnu.org/patch/download.php?file_id=11473 ___ Reply to this item at: http://savannah.gnu.org/patch/?5622 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[patch #5618] Test code for i386_{set,get}_gdt
URL:
http://savannah.gnu.org/patch/?5618
Summary: Test code for i386_{set,get}_gdt
Project: The GNU Hurd
Submitted by: bddebian
Submitted on: Wednesday 12/06/2006 at 22:00
Category: GNU Mach
Priority: 3 - Low
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
Wiki-like text discussion box:
___
Details:
Here are some tests that I started but Samuel made actually work for testing
the i386_{set,get}_gdt stuff I ported from Oskit/Mach.
Thanks.
Barry
___
File Attachments:
---
Date: Wednesday 12/06/2006 at 22:00 Name: gdt_tests.tar.gz Size: 957B By:
bddebian
http://savannah.gnu.org/patch/download.php?file_id=11464
___
Reply to this item at:
http://savannah.gnu.org/patch/?5618
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
Roland McGrath wrote: does not make sense Damn, I figured it didn't. Do we really need locking here or can we do without until we can implement nptl? Thanks! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: gcc-4.1 with fastmath
Roland McGrath wrote: gnumach doesn't support newer fpu state for mmx/xmm et al. would need new thread state flavor for fpx or whatever we call it. cf linux asm/user.h user_i387_struct vs user_fxsr_struct former is what mach can handle. need to handle latter in ctx sw + user thread state flavor, then enable cpu support bits (cr4 bit i think). Roland thanks. Can one of the Savannah project members please create a task for this? I tried to but apparently only members can create new tasks, etc? Also, does anyone happen to know why i386_fp_save and i386_fp_regs are split out? In Linux's user.h they are in 1 struct: user_i387_struct. Thanks as always! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
gcc-4.1 with fastmath
Heya gang,
I was able to build gcc-4.1 with a crtfastmath.o by changing config.gcc
to the following:
i[34567]86-*-gnu*)
tmake_file=${tmake_file} i386/t-crtfm
;;
But when running the attached test code compiled with --fast-math, I get
the following:
Starting program: /devel/bdefreese/fastmath_test/test1
Program received signal SIGILL, Illegal instruction.
set_fast_math () at ../../src/gcc/config/i386/crtfastmath.c:71
71unsigned int mxcsr = __builtin_ia32_stmxcsr ();
(gdb) bt full
#0 set_fast_math () at ../../src/gcc/config/i386/crtfastmath.c:71
mxcsr = 16998664
eax = 1667
ebx = value optimized out
ecx = value optimized out
edx = 58980863
#1 0x08048855 in __do_global_ctors_aux ()
No symbol table info available.
#2 0x080483dd in _init ()
No symbol table info available.
#3 0x0804868f in __libc_csu_init ()
No symbol table info available.
#4 0x01068edb in __libc_start_main () from /lib/libc.so.0.3
No symbol table info available.
#5 0x08048491 in _start () at ../sysdeps/i386/elf/start.S:119
No locals.
Thanks,
Barry deFreese (aka bddebian)
#include syslog.h
#include stdio.h
#include stdlib.h
#define ITERATIONS 1024
typedef struct {
char sign;
long frac;
int exp;
} sdouble;
/* Warning : double's size is hardcoded here, very bad habit. This program
is initially designed to only run on Itanium. */
sdouble cut_double (double d) {
sdouble ret;
long *db;
db = (long *)d;
ret.sign = (*db 63) 0x0001;
ret.exp = ((*db 52) 0x07FF) - 1023;
ret.frac = (*db ) 0x000F;
return ret;
}
int main (int argc, char **argv) {
sdouble sa;
double a;
int i;
a = 1;
i = 1;
openlog (double_test, LOG_CONS, LOG_USER);
syslog (LOG_USER | LOG_NOTICE, starting);
while (i = ITERATIONS) {
syslog (LOG_USER | LOG_NOTICE, iteration #%d, i);
a /= 2;
sa = cut_double (a);
printf (iteration %d : a=(%d, %lx, %d) : , i, sa.sign,
sa.frac, sa.exp);
printf (\n);
i++;
}
exit (0);
}
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
Thomas Schwinge wrote:
Follow-up Comment #2, bug #18217 (project hurd):
Roland: ``Uli abused the macros. To support the use he wants, __libc_once
should be revamped in all its implementations to return a value or have a
variant that does (value says whether fn just ran).''
Is there any reason this wouldn't work?
Current code:
/* Use mutexes as once control variables. */
struct __libc_once
{
__libc_lock_t lock;
int done;
};
#define __libc_once_define(CLASS,NAME) \
CLASS struct __libc_once NAME = { MUTEX_INITIALIZER, 0 }
/* Call handler iff the first call. */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
do
{\
__libc_lock_lock
(ONCE_CONTROL.lock); \
if
(!ONCE_CONTROL.done) \
(INIT_FUNCTION)
(); \
ONCE_CONTROL.done =
1;\
__libc_lock_unlock
(ONCE_CONTROL.lock); \
} while (0)
Change to:
*Remove struct
#define __libc_once_define(CLASS,NAME) \
CLASS int NAME = MUTEX_INITIALIZER
/* Call handler iff the first call. */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
do {
__libc_lock_lock(ONCE_CONTROL);
if ((ONCE_CONTROL) == MUTEX_INITIALIZER)
(INIT_FUNCTION)();
ONCE_CONTROL = 1;
__libc_lock_unlock(ONCE_CONTROL);
} while (0)
Or am I waaay off as usual?
Thanks!
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18015] GNU Mach: `make dist' and friends
Thomas Schwinge wrote: Follow-up Comment #5, bug #18015 (project hurd): ERROR: files left in build directory after distclean: ./config.status.orig ./Makefile.orig If you add ``DISTCLEANFILES = Makefile.orig config.status.orig'' to `Makefile.am', does it work then? Thomas, Sure does: gnumach-1.3.99 archives ready for distribution: gnumach-1.3.99.tar.gz rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc goober:/devel2/bdefreese/gnumach-1-12032006/gnumach/build# Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Building glibc from CVS
Heya gang, I am trying to build glibc from CVS and am getting the following error: In file included from ../include/link.h:47, from ../include/dlfcn.h:3, from ../sysdeps/generic/ldsodefs.h:32, from ../sysdeps/mach/hurd/i386/init-first.c:32: ../sysdeps/generic/rtld-lowlevel.h:1:2: error: #error Lowlevel primitives for ld.so not implemented In file included from ../include/dlfcn.h:3, from ../sysdeps/generic/ldsodefs.h:32, from ../sysdeps/mach/hurd/i386/init-first.c:32: ../include/link.h:224: error: expected specifier-qualifier-list before '__rtld_mrlock_define' In file included from ../sysdeps/generic/ldsodefs.h:41, from ../sysdeps/mach/hurd/i386/init-first.c:32: ../sysdeps/generic/rtld-lowlevel.h:1:2: error: #error Lowlevel primitives for ld.so not implemented Should we have an rtld-lowlevel.h (I don't see one on any other archs), or should we be implementing a sysdep dependent ldsodefs.h instead of using generic/? Thanks! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18015] GNU Mach: `make dist' and friends
Follow-up Comment #2, bug #18015 (project hurd): Thomas, Building out of the tree doesn't seem to work for me. build/../configure works OK but make dist seems to just keep running aclocal, autoconf, and automake recursively. Thanks, Barry ___ Reply to this item at: http://savannah.gnu.org/bugs/?18015 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18015] GNU Mach: `make dist' and friends
Follow-up Comment #3, bug #18015 (project hurd): As usual I screwed up. It appears I was having a timestamp problem. make dist works fine and a build on the resulting tarball is fine. I also tried running 'make distcheck' which seemed to be working fine but my machine hung again. I may try it again and report back. Thanks, Barry ___ Reply to this item at: http://savannah.gnu.org/bugs/?18015 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18015] GNU Mach: `make dist' and friends
Follow-up Comment #4, bug #18015 (project hurd): OK 'make distcheck' did not finish successfully: rm -f Makefile ERROR: files left in build directory after distclean: ./config.status.orig ./Makefile.orig make[1]: *** [distcleancheck] Error 1 make[1]: Leaving directory `/devel2/bdefreese/gnumach-1-11302006/gnumach/build/gnumach-1.3.99/_build' make: *** [distcheck] Error 2 rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18015 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: ``make dist'' and friends
snip That seems to be correct. I hope that doing so doesn't break anything. (Thinking about the rules in `Makerules.am' that deal with those files.) But you should have noticed if it had... I decided to add the `.srv' and `.cli' files to `EXTRA_DIST' instead. OK gang, I've gotten pretty far but now I'm a little confused. I had to include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c includes. But now it is attempting to build FlashPoint.c and failing. [...] But afaict, in a normal (i.e. not from make dist's tarball), FlashPoint.c is not build. Correct. Also, I meant to mention. I suppose one way around this may be to add FlashPoint.c to EXTRA_DIST instead of inside of a dist_liblinux_a_SOURCES target? Correct. This and similar other files should also be added to `EXTRA_DIST' instead of some `*_SOURCES'. I am attaching a diff of what I have done so far. Barry, thanks for the patch, it was of great help! I integrated it into a local tree here at home, changed and added some bits, began testing it to eventually commit it into the cvs repository, but before I was able to finish the testing, I hit another Automake bug, I believe, which I then reported to bug-automake@gnu.org. So we now have to wait until that is resolved. Regards, Thomas Thomas, Great thanks. It's funny, I originally had all the .cli and .srv files in EXTRA_DIST.. Doh. So, should I pretty much stop working on this at this point? Thanks again! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Moving `migcom' out of `[exec_prefix]/libexec/'
(stdout);
}
WriteUserHeader(uheader, StatementList);
myfclose(uheader, UserHeaderFileName);
if (ServerHeaderFileName)
{
if (BeVerbose)
{
printf (done.\nWriting %s ..., ServerHeaderFileName);
fflush (stdout);
}
WriteServerHeader(sheader, StatementList);
myfclose(sheader, ServerHeaderFileName);
}
if (IsKernelServer)
{
if (BeVerbose)
{
printf(done.\nWriting %s ... , InternalHeaderFileName);
fflush(stdout);
}
WriteInternalHeader(iheader, StatementList);
myfclose(iheader, InternalHeaderFileName);
}
if (UserFilePrefix)
{
if (BeVerbose)
{
printf(done.\nWriting individual user files ... );
fflush(stdout);
}
WriteUserIndividual(StatementList);
}
else
{
if (BeVerbose)
{
printf(done.\nWriting %s ... , UserFileName);
fflush(stdout);
}
WriteUser(user, StatementList);
myfclose(user, UserFileName);
}
if (BeVerbose)
{
printf(done.\nWriting %s ... , ServerFileName);
fflush(stdout);
}
WriteServer(server, StatementList);
myfclose(server, ServerFileName);
if (RoutineListFileName != strNULL)
{
FILE *listfile = myfopen (RoutineListFileName, w);
WriteRoutineList (listfile, StatementList);
myfclose (listfile, RoutineListFileName);
}
if (BeVerbose)
printf(done.\n);
return 0;
}
static FILE *
myfopen(const char *name, const char *mode)
{
const char *realname;
FILE *file;
extern int errno;
if (name == strNULL)
realname = /dev/null;
else
realname = name;
file = fopen(realname, mode);
if (file == NULL)
fatal(fopen(%s): %s, realname, unix_error_string(errno));
return file;
}
static void
myfclose(FILE *file, const char *name)
{
if (ferror(file) || fclose(file))
fatal(fclose(): , name, unix_error_string(errno));
}
Constantine,
I'm speaking out of my ass as usual but I assume he suggested Ben
because we would prefer using argp and Ben is the argp master. But what
you have looks reasonable.
Thanks,
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
[task #5723] Investigate flick
Follow-up Comment #1, task #5723 (project hurd): I have done some research and talked to a few people (including Jeff Bailey) and as far as I can find out Flick is slower and even less maintained than MiG so I'm not sure what this would buy us? Thanks. Barry ___ Reply to this item at: http://savannah.gnu.org/task/?5723 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #15329] exec doesn't like zip'ed binaries
Follow-up Comment #2, bug #15329 (project hurd): Did Andrew's patch not get committed? If so, can this bug be closed? If not, can it be committed? Thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?15329 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: ``make dist'' and friends
Thomas Schwinge wrote: Hello! On Tue, Nov 28, 2006 at 12:13:20AM -0500, Barry deFreese wrote: Barry deFreese wrote: [...] I have added a few dist_libkernel_a_SOURCE to include all the header files, .sym, .srv, and .cli files. That seems to be correct. I hope that doing so doesn't break anything. (Thinking about the rules in `Makerules.am' that deal with those files.) But you should have noticed if it had... Now I am stuck on one that I cannot figure out: i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by `../ipc/ipc_entry.c'. Stop. Probably some of its dependency files are still missing to be added to some `*_SOURCE' variable, have a look at the first set of rules in `Makerules.am'. A small update. Apparently i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't getting built but I get no error... But it's definitely needed, as I understand this at the moment. (I can't access a built tree at the moment.) Regards, Thomas OK gang, I've gotten pretty far but now I'm a little confused. I had to include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c includes. But now it is attempting to build FlashPoint.c and failing. gcc -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -D__ASSEMBLY__ -traditional -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -I../i386/linux/dev/include -I./linux/dev/include -I../linux/dev/include -I./linux/src/include -I../linux/src/include -g -O2 -c -o linux/src/arch/i386/lib/liblinux_a-semaphore.o `test -f 'linux/src/arch/i386/lib/semaphore.S' || echo '../'`linux/src/arch/i386/lib/semaphore.S if gcc -DHAVE_CONFIG_H -I. -I.. -I. -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -I../i386/linux/dev/include -I./linux/dev/include -I../linux/dev/include -I./linux/src/include -I../linux/src/include -O2 -Wall -fno-strict-aliasing -g -O2 -MT linux/src/drivers/scsi/liblinux_a-FlashPoint.o -MD -MP -MF linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo -c -o linux/src/drivers/scsi/liblinux_a-FlashPoint.o `test -f 'linux/src/drivers/scsi/FlashPoint.c' || echo '../'`linux/src/drivers/scsi/FlashPoint.c; \ then mv -f linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Po; else rm -f linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo; exit 1; fi ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_ProbeHostAdapter': ../linux/src/drivers/scsi/FlashPoint.c:2432: warning: implicit declaration of function 'inb' ../linux/src/drivers/scsi/FlashPoint.c:2467: warning: implicit declaration of function 'outb' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_ReleaseHostAdapter': ../linux/src/drivers/scsi/FlashPoint.c:4106: warning: implicit declaration of function 'outl' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FPT_RNVRamData': ../linux/src/drivers/scsi/FlashPoint.c:4146: warning: implicit declaration of function 'inl' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_HandleInterrupt': ../linux/src/drivers/scsi/FlashPoint.c:4713: warning: implicit declaration of function 'inw' ../linux/src/drivers/scsi/FlashPoint.c:4730: warning: implicit declaration of function 'outw' ../linux/src/drivers/scsi/FlashPoint.c: At top level: ../linux/src/drivers/scsi/FlashPoint.c:12056: error: expected ')' before '*' token ../linux/src/drivers/scsi/FlashPoint.c:12063: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'FlashPoint__HardwareResetHostAdapter' ../linux/src/drivers/scsi/FlashPoint.c:12069: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12076: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12083: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12090: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'FlashPoint__InterruptPending' ../linux/src/drivers/scsi/FlashPoint.c:12097: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12117: error: expected ')' before 'CardHandle' make[2]: *** [linux/src/drivers/scsi/liblinux_a-FlashPoint.o] Error 1 rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc make[2]: Leaving directory `/tmp/gnumach-1.3.99/build' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnumach-1.3.99/build' make: *** [all] Error 2 But afaict, in a normal (i.e. not from make dist's tarball), FlashPoint.c is not build. I am attaching a diff of what I have done so far. Thanks! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: ``make dist'' and friends
Barry deFreese wrote: Thomas Schwinge wrote: Hello! On Tue, Nov 28, 2006 at 12:13:20AM -0500, Barry deFreese wrote: Barry deFreese wrote: [...] I have added a few dist_libkernel_a_SOURCE to include all the header files, .sym, .srv, and .cli files. That seems to be correct. I hope that doing so doesn't break anything. (Thinking about the rules in `Makerules.am' that deal with those files.) But you should have noticed if it had... Now I am stuck on one that I cannot figure out: i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by `../ipc/ipc_entry.c'. Stop. Probably some of its dependency files are still missing to be added to some `*_SOURCE' variable, have a look at the first set of rules in `Makerules.am'. A small update. Apparently i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't getting built but I get no error... But it's definitely needed, as I understand this at the moment. (I can't access a built tree at the moment.) Regards, Thomas OK gang, I've gotten pretty far but now I'm a little confused. I had to include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c includes. But now it is attempting to build FlashPoint.c and failing. gcc -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -D__ASSEMBLY__ -traditional -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -I../i386/linux/dev/include -I./linux/dev/include -I../linux/dev/include -I./linux/src/include -I../linux/src/include -g -O2 -c -o linux/src/arch/i386/lib/liblinux_a-semaphore.o `test -f 'linux/src/arch/i386/lib/semaphore.S' || echo '../'`linux/src/arch/i386/lib/semaphore.S if gcc -DHAVE_CONFIG_H -I. -I.. -I. -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -I../i386/linux/dev/include -I./linux/dev/include -I../linux/dev/include -I./linux/src/include -I../linux/src/include -O2 -Wall -fno-strict-aliasing -g -O2 -MT linux/src/drivers/scsi/liblinux_a-FlashPoint.o -MD -MP -MF linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo -c -o linux/src/drivers/scsi/liblinux_a-FlashPoint.o `test -f 'linux/src/drivers/scsi/FlashPoint.c' || echo '../'`linux/src/drivers/scsi/FlashPoint.c; \ then mv -f linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Po; else rm -f linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo; exit 1; fi ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_ProbeHostAdapter': ../linux/src/drivers/scsi/FlashPoint.c:2432: warning: implicit declaration of function 'inb' ../linux/src/drivers/scsi/FlashPoint.c:2467: warning: implicit declaration of function 'outb' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_ReleaseHostAdapter': ../linux/src/drivers/scsi/FlashPoint.c:4106: warning: implicit declaration of function 'outl' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FPT_RNVRamData': ../linux/src/drivers/scsi/FlashPoint.c:4146: warning: implicit declaration of function 'inl' ../linux/src/drivers/scsi/FlashPoint.c: In function 'FlashPoint_HandleInterrupt': ../linux/src/drivers/scsi/FlashPoint.c:4713: warning: implicit declaration of function 'inw' ../linux/src/drivers/scsi/FlashPoint.c:4730: warning: implicit declaration of function 'outw' ../linux/src/drivers/scsi/FlashPoint.c: At top level: ../linux/src/drivers/scsi/FlashPoint.c:12056: error: expected ')' before '*' token ../linux/src/drivers/scsi/FlashPoint.c:12063: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'FlashPoint__HardwareResetHostAdapter' ../linux/src/drivers/scsi/FlashPoint.c:12069: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12076: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12083: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12090: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'FlashPoint__InterruptPending' ../linux/src/drivers/scsi/FlashPoint.c:12097: error: expected ')' before 'CardHandle' ../linux/src/drivers/scsi/FlashPoint.c:12117: error: expected ')' before 'CardHandle' make[2]: *** [linux/src/drivers/scsi/liblinux_a-FlashPoint.o] Error 1 rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc make[2]: Leaving directory `/tmp/gnumach-1.3.99/build' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnumach-1.3.99/build' make: *** [all] Error 2 But afaict, in a normal (i.e. not from make dist's tarball), FlashPoint.c is not build. I am attaching a diff of what I have done so far. Thanks! Barry deFreese (aka bddebian) Doh, forgot the .diff file. Also, I meant to mention. I suppose one way around this may be to add FlashPoint.c to EXTRA_DIST instead of inside of a dist_liblinux_a_SOURCES target
Re: ``make dist'' and friends
Thomas Schwinge wrote: Hello! This is mainly for Barry, but there is no reason that I should send it privately, so... 19:49 bddebian WTF generates the .defs.c files? Have a look at the magic in `Makerules.am' and how it is being used in `Makefrag.am'. This is not optimal, but I didn't invent a better way so far. It's also marked as `TODO' in there. 19:56 bddebian OK, I get make dist to run, then configure seems to run clean finally on the extracted tarball. But now when running make, I get: 19:56 bddebian ld# make 19:56 bddebian make all-recursive 19:56 bddebian make[1]: Entering directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:56 bddebian make[2]: Entering directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:56 bddebian grep: ../CVS/Root: No such file or directory 19:56 bddebian make[2]: *** No rule to make target `vm/memory_object_user.user.defs.c', needed by `../ipc/ipc_entry.c'. Stop. 19:57 bddebian make[2]: Leaving directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:57 bddebian make[1]: *** [all-recursive] Error 1 19:57 bddebian make[1]: Leaving directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:57 bddebian make: *** [all] Error 2 I checked in a change to oppress the (harmless) error message from grep. No action required from your side. For the actual error message from above, I think I'd need to have a look at the changes you did so far. 22:19 bddebian Why is everything nodist_foo.. in Makefrag.am? Those are the files that are generated during the build (e.g. mig's output files) and we thusly don't want to include in a release tarball. Regards, Thomas Thomas, Aye, I have fixed all of those. Not sure if I've done it the best way but I have added a few dist_libkernel_a_SOURCE to include all the header files, .sym, .srv, and .cli files. Now I am stuck on one that I cannot figure out: i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by `../ipc/ipc_entry.c'. Stop. Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: ``make dist'' and friends
Barry deFreese wrote: Thomas Schwinge wrote: Hello! This is mainly for Barry, but there is no reason that I should send it privately, so... 19:49 bddebian WTF generates the .defs.c files? Have a look at the magic in `Makerules.am' and how it is being used in `Makefrag.am'. This is not optimal, but I didn't invent a better way so far. It's also marked as `TODO' in there. 19:56 bddebian OK, I get make dist to run, then configure seems to run clean finally on the extracted tarball. But now when running make, I get: 19:56 bddebian ld# make 19:56 bddebian make all-recursive 19:56 bddebian make[1]: Entering directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:56 bddebian make[2]: Entering directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:56 bddebian grep: ../CVS/Root: No such file or directory 19:56 bddebian make[2]: *** No rule to make target `vm/memory_object_user.user.defs.c', needed by `../ipc/ipc_entry.c'. Stop. 19:57 bddebian make[2]: Leaving directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:57 bddebian make[1]: *** [all-recursive] Error 1 19:57 bddebian make[1]: Leaving directory `/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 19:57 bddebian make: *** [all] Error 2 I checked in a change to oppress the (harmless) error message from grep. No action required from your side. For the actual error message from above, I think I'd need to have a look at the changes you did so far. 22:19 bddebian Why is everything nodist_foo.. in Makefrag.am? Those are the files that are generated during the build (e.g. mig's output files) and we thusly don't want to include in a release tarball. Regards, Thomas Thomas, Aye, I have fixed all of those. Not sure if I've done it the best way but I have added a few dist_libkernel_a_SOURCE to include all the header files, .sym, .srv, and .cli files. Now I am stuck on one that I cannot figure out: i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by `../ipc/ipc_entry.c'. Stop. Thanks, Barry deFreese (aka bddebian) A small update. Apparently i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't getting built but I get no error... Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [task #5490] syslog
Constantine Kousoulos wrote: Hello again, From http://savannah.gnu.org/task/?5490: Find and implement a suitable way to make the Hurd servers use `syslog'. Can someone explain what this task demands to be done? Debian's syslogd seems to be working with the current GNU/Hurd snapshot. To test it, i added a few syslog entries in /hurd/utils/ps.c and it worked ok. I understand that syslogd cannot act as klogd does in linux. Maybe we need to modify GNU Mach or glibc's syslog.h to get something klogi. But why can't syslogd work as it is for the hurd servers? Thanks, Constantine Constantine, AFAIUI, the task IS to make Hurd code write entries to syslog. Good luck :-) Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Hurd Pthreads
Heya gang, OK, I have a HUGE cthreads-pthreads patch going that is going fairly well. However, we still have an issue with hurd_condition_wait. Can that be stopped-gapped into libpthreads, or should some real glibc work be done first? In other words, am I wasting my time as always? Thanks! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #17120] GNU Mach debian dir
Follow-up Comment #3, bug #17120 (project hurd): Isn't it standard practice not to include debian dirs in upstream tarballs? What's the issue with just removing this? Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17120 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #17346] GNU mach can't handle 4GB memory
Follow-up Comment #2, bug #17346 (project hurd): This better? vm_size_t memsize = boot_info.mem_upper; if ((memsize = 0x40)) memsize = (0x40-1); phys_last_addr = 0x10 + (memsize * 0x400); ___ Reply to this item at: http://savannah.gnu.org/bugs/?17346 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach cleanup Round 6
Hi folks, it's your favorite PITA again.. :-)
* ddb/db_aout.c Include: db_output.h
* ddb/db_break.c Include: db_cond.h, db_output.h, and db_expr.h
* db_delete_cmd(): specify int for variable n
* ddb/db_command.c Include: db_macro.h, db_expr.h, and db_examine.h
* ddb/db_command.h Add forward declarations for:
* db_exec_cmd_nest()
* ddb/db_cond.c Include: db_cond.h, db_expr.h, and db_output.h
* db_cond_cmd(): specify int for variable c
* ddb/db_cond.h New file
* ddb/db_examine.c Include: machine/db_interface.h,
ddb/db_examine.h, ddb/db_expr.h
* Remove forward declarations for: db_strcpy() and db_examine()
* db_xcdump() specify int for variables i,n
* ddb/db_examine.h New file
* ddb/db_expr.c Include: db_expr.h, db_output.h, db_sym.h, db_variables.h
* ddb/db_input.c Include: db_command.h
* ddb/db_input.h New file
* ddb/db_lex.c Include: db_command.h, db_examine.h, db_input.h,
db_output.h
* db_skip_to_eol() specify int for variables skip, t, n
* db_lex() specify int for variable c
* ddb/db_lex.h Remove forward declaration for db_lex().
* ddb/db_macro.c Include: db_examine.h, db_expr.h, db_output.h
* db_def_macro_cmd() specify int for variables c, n
* ddb/db_macro.h New file
* ddb/db_output.c Include: db_command.h
* ddb/db_output.h Add forward declaration for db_printf()
* ddb/db_print.c Include machine/db_interface.h, ddb/db_command.h,
ddb/db_output.h
* db_show_regs() specify int for variable i
* ddb/db_run.c Include: db_command.h, db_examine.h, db_output.h,
db_watch.h
* ddb/db_run.h Include kern/task.h, machine/db_machdep.h
* Add forward declarations:
* db_single_step()
* db_single_step_cmd()
* db_in_single_step()
* ddb/db_sym.c Include: db_command.h, db_output.h
* db_sym_parse_and_lookup() specify int for variable n
* ddb/db_sym.h Add forward declaration for db_line_at_pc()
* ddb/db_task_thread.c Include: db_command.h, db_expr.h, db_lex.h,
db_output.h
* db_lookup_task() specify int for variables task_id, npset
* db_lookup_task_thread() specify int for variable thread_id
* db_lookup_thread() specify int for variables thread_id, ntask, npset
* db_lookup_task_id() specify int for variables task_id, npset
* db_lookup_thread_id() specify int for variable thread_id
* ddb/db_trap.c Include: db_examine.h, db_output.h
* ddb/db_trap.h New file
* ddb/db_variables.c Include: db_command.h, db_examine.h, db_expr.h,
db_output.h
* db_get_suffix() specify int for variable value
* db_cmp_variable_name() specify int for variable level
* ddb/db_variables.h Add forward declaration for db_get_variable()
* ddb/db_watch.c db_command.h, db_expr.h, db_output.h, db_run.h
* ddb/db_write_cmd.c Include: db_expr.h, db_output.h
* i386/i386/db_interface.c Include: kern/printf.h, ddb/db_access.h,
ddb/db_command.h, ddb/db_output.h, ddb/db_run.h, ddb/db_trap.h
* kdbprinttrap() Add void return type to function declaration
* db_user_to_kernel_address() specify int for variable *kaddr
* db_task_name() specify int for variable n
* i386/i386/db_interface.h New file
* i386/i386/db_trace.c Add int return type to function declaration
for db_i386_reg_value()
* i386/i386/trap.c Include: ddb/db_watch.h, ddb/db_run.h
* ipc/ipc_kmsg.c Include: ddb/db_output.h if MACH_KDB is defined
* kern/lock.c Include: ddb/db_output.h
Thanks!
Barry deFreese (aka bddebian)
Index: ddb/db_aout.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_aout.c,v
retrieving revision 1.2.2.2
diff -u -p -r1.2.2.2 db_aout.c
--- ddb/db_aout.c 8 Nov 2006 01:45:43 - 1.2.2.2
+++ ddb/db_aout.c 15 Nov 2006 17:15:51 -
@@ -37,6 +37,7 @@
#include string.h
#include mach/std_types.h
#include machine/db_machdep.h/* data types */
+#include ddb/db_output.h
#include ddb/db_sym.h
#ifndefDB_NO_AOUT
Index: ddb/db_break.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_break.c,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 db_break.c
--- ddb/db_break.c 15 Oct 2006 14:59:03 - 1.2.2.1
+++ ddb/db_break.c 15 Nov 2006 17:15:51 -
@@ -43,6 +43,9 @@
#include ddb/db_variables.h
#include ddb/db_command.h
#include ddb/db_task_thread.h
+#include ddb/db_output.h
+#include ddb/db_cond.h
+#include ddb/db_expr.h
#defineNBREAKPOINTS100
#define NTHREAD_LIST (NBREAKPOINTS*3)
@@ -594,7 +597,7 @@ db_list_breakpoints()
void
db_delete_cmd()
{
- register n;
+ register int n;
thread_t thread;
vm_offset_t task_thd;
boolean_t user_global = FALSE;
@@ -677,7 +680,7 @@ db_breakpoint_cmd(addr, have_addr, count
db_expr_t count;
char * modif;
{
- register n;
+ register int n;
thread_t thread;
boolean_t
Re: Maintaining the tool chain
Thomas Schwinge wrote: Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', http://savannah.gnu.org/people/?group=hurd: #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mostly GCC, binutils and glibc) up-to-date in an environment where the tool chain is being advanced for the Linux kernel, as an example, and subsequently the Hurd-specific parts would need to be adopted to these advancements. Please contact us mailing to bug-hurd@gnu.org if you are interested in helping here. #v- Thanks to Michael Banck for the suggestion to add such a inquiry. Regards, Thomas Thomas, You know I'm game if there is anything my limited skillset can bring to the table. Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach cleanup Round 6
Thomas Bushnell BSG wrote: On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote: Hi folks, it's your favorite PITA again.. :-) Index: i386/i386/trap.c === RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v retrieving revision 1.5.2.6 diff -u -p -r1.5.2.6 trap.c --- i386/i386/trap.c11 Nov 2006 00:54:05 - 1.5.2.6 +++ i386/i386/trap.c15 Nov 2006 17:15:58 - @@ -60,6 +60,8 @@ extern void thread_exception_return(); extern void i386_exception(); #if MACH_KDB +#include ddb/db_watch.h +#include ddb/db_run.h boolean_t debug_all_traps_with_kdb = FALSE; extern struct db_watchpoint *db_watchpoint_list; extern boolean_t db_watchpoints_inserted; The #includes should go at the front, with the rest of the includes. Preserve the normal order: #include ... #include ... other decls ... functions except when there is a good reason to deviate, which there does not seem to be in this case. Thomas Thomas, Thanks for the reply. Are you saying I should wrap those includes around an #ifdef MACH_KDB up where the other includes are? If so, that makes sense to me. Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach cleanup Round 4
- Original Message - From: Roland McGrath [EMAIL PROTECTED] To: Samuel Thibault [EMAIL PROTECTED] Cc: Barry deFreese [EMAIL PROTECTED]; bug-hurd@gnu.org Sent: Monday, November 13, 2006 7:02 PM Subject: Re: Gnumach cleanup Round 4 Roland McGrath, le Mon 13 Nov 2006 13:44:30 -0800, a écrit : I don't disagree. Have a suggestion for a better place to declare it? Some machine-independent header included by the relevant code. kern/model_dep.h then? If you invent a header, don't give it a silly name like that. I meant some existing header if there is an appropriate one. Gents, In other *nixes it appears to be declared in sys/ddi.h. Does that make more sense? Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Building glibc with TLS
OK, for kicks I tried to build glibc with --with-tls and --without-__thread using my gnumach with the gdt stuff I did a couple weeks ago and Jeroens patch from here: http://www.dekkers.cx/hurd/glibc-tls.patch Here is what I got: CPP='gcc-4.0 -E -x c-header' /devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/elf/ld.so.1 --library-path /devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/math:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/elf:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/dlfcn:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/nss:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/nis:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/rt:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/resolv:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/crypt:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/mach:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/hurd:/X11R6/lib /devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/xbootparam_prot.T make[3]: *** [/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/xbootparam_prot.stmp] Segmentation fault make[3]: Leaving directory `/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/sunrpc' make[2]: *** [sunrpc/others] Error 2 make[2]: Leaving directory `/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/glibc-2.3.6' make[1]: *** [all] Error 2 make[1]: Leaving directory `/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc' I'll see if I can play with this but it's probably over my head. Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach cleanup - 'return type defaults to int'
- Original Message - From: Barry deFreese [EMAIL PROTECTED] To: bug-hurd@gnu.org Sent: Monday, November 13, 2006 5:39 AM Subject: Gnumach cleanup - 'return type defaults to int' As per Samuels request, here is a patch to clean up all warnings for non-typed functions. snip Hi again folks. Something weird is happening to me with cvs diff. So if someone reviews/commits this, please note that mouseintr() in i386/i386at/kd_mouse.c should be int, NOT void. Sorry and thanks! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach cleanup 5 - Control reaches end of non-void function
Heya gents,
Just a quick one to clean the remaining warnings in the title.
I realize that this reverts a couple of the things I sent on my last
patch but several of the lpr functions really return nothing so should
have been void in the first place.
Thanks as always,
Barry deFreese (aka bddebian)
Index: i386/i386/trap.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.6
diff -u -p -r1.5.2.6 trap.c
--- i386/i386/trap.c 11 Nov 2006 00:54:05 - 1.5.2.6
+++ i386/i386/trap.c 14 Nov 2006 03:43:31 -
@@ -570,6 +570,7 @@ printf(user trap %d error %d sub %08x\n
i386_exception(exc, code, subcode);
/*NOTREACHED*/
+ return -1;
}
/*
@@ -1116,6 +1117,8 @@ check_io_fault(regs)
/* port not mapped */
return FALSE;
}
+ /* NOTREACHED ? */
+ return FALSE;
}
#if MACH_PCSAMPLE 0
Index: i386/i386at/com.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.4
diff -u -p -r1.3.2.4 com.c
--- i386/i386at/com.c 13 Nov 2006 21:30:36 - 1.3.2.4
+++ i386/i386at/com.c 14 Nov 2006 03:43:31 -
@@ -45,10 +45,10 @@
extern void timeout(), ttrstrt();
-int comprobe(), comintr(), comstart(), commctl();
-void comattach();
+int comprobe(), comstart(), commctl();
+void comattach(), comstop(), comintr();
static void comparam();
-int comstop(), comgetstat(), comsetstat();
+io_return_t comgetstat(), comsetstat();
static vm_offset_t com_std[NCOM] = { 0 };
struct bus_device *cominfo[NCOM];
@@ -487,7 +487,7 @@ unsigned int count;
return (D_SUCCESS);
}
-int
+void
comintr(unit)
int unit;
{
@@ -807,7 +807,7 @@ commctl(
return commodem[unit];
}
-int
+void
comstop(tp, flags)
register struct tty *tp;
int flags;
Index: i386/i386at/kd.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.11
diff -u -p -r1.5.2.11 kd.c
--- i386/i386at/kd.c 13 Nov 2006 21:30:36 - 1.5.2.11
+++ i386/i386at/kd.c 14 Nov 2006 03:43:32 -
@@ -489,7 +489,7 @@ kdopen(dev, flag, ior)
struct tty *tp;
int kdstart();
spl_t o_pri;
- int kdstop();
+ void kdstop();
tp = kd_tty;
o_pri = spltty();
@@ -1170,7 +1170,7 @@ struct tty *tp;
}
/*ARGSUSED*/
-int
+void
kdstop(tp, flags)
register struct tty *tp;
int flags;
Index: i386/i386at/lpr.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/lpr.c,v
retrieving revision 1.1.1.1.4.9
diff -u -p -r1.1.1.1.4.9 lpr.c
--- i386/i386at/lpr.c 13 Nov 2006 21:30:36 - 1.1.1.1.4.9
+++ i386/i386at/lpr.c 14 Nov 2006 03:43:32 -
@@ -64,10 +64,11 @@ extern void ttrstrt();
* Driver information for auto-configuration stuff.
*/
-int lprprobe(), lprintr(), lprstart(), lprstop();
+int lprprobe(), lprintr(), lprstart();
+void lprstop();
void lprattach(struct bus_device *);
#ifdef MACH_KERNEL
-int lprstop(), lprgetstat(), lprsetstat();
+int lprgetstat(), lprsetstat();
#endif /* MACH_KERNEL */
struct bus_device *lprinfo[NLPR]; /* ??? */
@@ -369,7 +370,7 @@ struct tty *tp;
}
#ifdef MACH_KERNEL
-int
+void
lprstop(tp, flags)
register struct tty *tp;
int flags;
@@ -378,7 +379,7 @@ int flags;
tp-t_state |= TS_FLUSH;
}
#else /* MACH_KERNEL */
-int lprstop(tp, flag)
+void lprstop(tp, flag)
struct tty *tp;
{
int s = spltty();
Index: kern/eventcount.c
===
RCS file: /cvsroot/hurd/gnumach/kern/eventcount.c,v
retrieving revision 1.1.1.1.4.6
diff -u -p -r1.1.1.1.4.6 eventcount.c
--- kern/eventcount.c 13 Nov 2006 21:30:37 - 1.1.1.1.4.6
+++ kern/eventcount.c 14 Nov 2006 03:43:33 -
@@ -232,6 +232,7 @@ kern_return_t evc_wait_clear(natural_t e
simple_unlock(ev-lock);
splx(s);
ret = KERN_NO_SPACE; /* XX */
+ return ret;
}
/*
Index: util/putchar.c
===
RCS file: /cvsroot/hurd/gnumach/util/Attic/putchar.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 putchar.c
--- util/putchar.c 25 Feb 1997 21:28:35 - 1.1.1.1
+++ util/putchar.c 14 Nov 2006 03:43:35 -
@@ -21,7 +21,7 @@
* Author: Bryan Ford, University of Utah CSL
*/
-int putchar(int c)
+void putchar(int c)
{
cnputc(c);
}
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach cleanup Round 4
Heya gang. OK, I was working on a much bigger patch but got hung up on some of the chario / tty stuff. So I am sending what I have for now. * i386/i386/locore.h New file * i386/i386/pcb.h New file * i386/i386/spl.h Add function declarations * i386/i386at/kd_event.h New file * i386/i386at/kd_mouse.h New file * i386/i386at/model_dep.h New file * i386/i386at/kd.c Include new kd_event.h and kd_mouse.h. * i386/i386at/kd.h Remove prototypes for splx() and spltty(). * i386/i386at/lpr.c Remove prototypes for splx() and spltty(). * ipc/mach_msg.c Include new locore.h and pcb.h * kern/debug.c Include new i386at/model_dep.h * kern/mach_clock.h New file * kern/mach_clock.c New includes: * i386at/model_dep.h * kern/mach_clock.h * kern/queue.h * kern/timer.h * kern/mach_factor.h New file * kern/sched_prim.c New includes: * i386at/model_dep.h * kern/mach_factor.h * kern/thread.c Include new i386/pcb.h Thanks! Barry deFreese (aka bddebian) Index: i386/i386/locore.h === RCS file: i386/i386/locore.h diff -N i386/i386/locore.h --- /dev/null 1 Jan 1970 00:00:00 - +++ i386/i386/locore.h 12 Nov 2006 20:21:57 - @@ -0,0 +1,39 @@ +/* + * Header file for printf type functions. + * Copyright (C) 2006 Free Software Foundation. + * + * 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 + * the Free Software Foundation; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef _MACHINE_LOCORE_H_ +#define _MACHINE_LOCORE_H_ + +#include sys/types.h +#include stdarg.h + +#include kern/sched_prim.h + +extern int copyin (const void *userbuf, void *driverbuf, size_t cn); + +extern int copyinmsg (vm_offset_t userbuf, vm_offset_t driverbuf, size_t cn); + +extern int copyout (const void *userbuf, void *driverbuf, size_t cn); + +extern int copyoutmsg (vm_offset_t userbuf, vm_offset_t driverbuf, size_t cn); + +extern int call_continuation (continuation_t continuation); + +#endif /* _MACHINE__LOCORE_H_ */ + Index: i386/i386/pcb.h === RCS file: i386/i386/pcb.h diff -N i386/i386/pcb.h --- /dev/null 1 Jan 1970 00:00:00 - +++ i386/i386/pcb.h 12 Nov 2006 20:21:57 - @@ -0,0 +1,61 @@ +/* + * + * Copyright (C) 2006 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 + * the Free Software Foundation; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Author: Barry deFreese. + */ +/* + * + * + */ + +#ifndef _I386_PCB_H_ +#define _I386_PCB_H_ + +#include sys/types.h + +extern void pcb_init (thread_t thread); + +extern void pcb_terminate (thread_t thread); + +extern void pcb_collect (thread_t thread); + +extern kern_return_t thread_setstatus ( + thread_tthread, + int flavor, + thread_state_t tstate, + unsigned intcount); + +extern kern_return_t thread_getstatus ( + thread_tthread, + int flavor, + thread_state_t tstate, + unsigned int*count); + +extern void thread_set_syscall_return ( + thread_tthread, + kern_return_t retval); + +extern vm_offset_t user_stack_low (vm_size_t stack_size); + +extern vm_offset_t set_user_regs ( + vm_offset_t stack_base, + vm_offset_t stack_size, + struct exec_info *exec_info, + vm_size_t arg_size); + +#endif /* _I386_PCB_H_ */ Index: i386/i386/spl.h === RCS file: /cvsroot/hurd/gnumach/i386/i386/spl.h,v retrieving revision 1.2 diff -u -p -r1.2 spl.h --- i386/i386/spl.h 26 Apr 1999 05:26:12 - 1.2 +++ i386/i386/spl.h 12 Nov 2006 20:21:57 - @@ -48,6 +48,28 @@ extern spl_t (spldcm)(void); extern spl_t (spl6)(void); +extern int spl0 (void); + +extern int splsched (void); + +extern int splx (int n); + +extern int
Re: Gnumach cleanup Round 4
- Original Message - From: Samuel Thibault [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: bug-hurd@gnu.org Sent: Sunday, November 12, 2006 6:47 PM Subject: Re: Gnumach cleanup Round 4 Hi, Barry deFreese, le Sun 12 Nov 2006 21:19:06 -0500, a écrit : OK, I was working on a much bigger patch but got hung up on some of the chario / tty stuff. So I am sending what I have for now. Ah, I misread it, so that patch was not so big, I commited most of it (the obvious part). * i386/i386at/model_dep.h New file * kern/debug.c Include new i386at/model_dep.h * kern/mach_clock.c New includes: * i386at/model_dep.h This poses problem. We can't ask the kernel part to include some i386-specific part. For such things we have the machine/ symlink, but it points to i386/i386/, not i386/i386at/ . Any thoughts on this? Samuel Samuel, Thanks, I thought about that too. Unfortunately I'm not quite skilled enough yet to get the differences between what's in i386/ vs i386at/ . Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach cleanup Round 4
- Original Message - From: Roland McGrath [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: bug-hurd@gnu.org Sent: Sunday, November 12, 2006 7:50 PM Subject: Re: Gnumach cleanup Round 4 Decls for copyin et al do not belong in a machine header. Roland, I don't disagree. Have a suggestion for a better place to declare it? Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach cleanup - 'return type defaults to int'
As per Samuels request, here is a patch to clean up all warnings for non-typed functions. * device/cons.c * cninit() Add void return type to function definition * cngetc() return type int * cnmaygetc() Likewise * cnputc() return type void * device/net_io.c * net_del_q_info() return type void * net_free_dead_infp() Likewise * net_free_dead_entp() Likewise * device/chario.c * tty_cts() Likewise * i386/i386at/com.c * comintr() return type int * comparm() return type void * comtimer() Likewise * fix_modem_state() Likewise * commodem_intr() Likewise * commctl() return type int * comstop() return type int * i386/i386at/rtc.c * rtcinit() Likewise * rtcput() Likewise * yeartoday() return type int * readtodc() return type int * i386/i386at/iopl.c * ioplopen() return type int * ioplclose() return type int * i386/i386at/kd.c * kd_io_map_open() return type void * kd_io_map_close() Likewise * feep() Likewise * pause() Likewise * kd_debug_put() Likewise * cnpollc() Likewise * kdopen() return type int * kdclose() return type void * kdread() return type int * kdwrite() Likewise * kdportdeath() Likewise * kdsetbell() Likewise * kdgetkbent() Likewise * kdintr() return type void * kd_handle_ack() return type void * kd_resend() Likewise * do_modifier() return type int * kdstate2idx() Likewise * kdstart() Likewise * kdstop() return type void * kdinit() Likewise * kd_belloff() Likewise * kd_bellon() Likewise * kd_putc() Likewise * kd_setpos() Likewise * kd_scrollup() Likewise * kd_scrolldn() Likewise * kd_parseesc() Likewise * kd_parserest() Likewise * kd_tab() Likewise * kd_cls() Likewise * kd_home() Likewise * kd_up() Likewise * kd_down() Likewise * kd_right() Likewise * kd_left() Likewise * kd_cr() Likewise * kd_cltobcur() Likewise * kd_cltopcur() Likewise * kd_cltoecur() Likewise * kd_clfrbcur() Likewise * kd_delln() Likewise * kd_insln() Likewise * kd_delch() Likewise * kd_erase() Likewise * kd_eraseln() Likewise * kd_insch() Likewise * kd_isupper() return type boolean_t * kd_islower() Likewise * kd_senddata() return type void * kd_sendcmd() Likewise * kd_cmdreg_read() return type unsigned char * kd_cmdreg_write() return type void * kd_mouse_drain() Likewise * set_kd_state() Likewise * kd_setleds1() Likewise * kd_setleds2() Likewise * cnsetleds() Likewise * kdreboot() Likewise * kd_kbd_magic() return type int * i386/i386at/kd_event.c * kbdinit() return type void * kbdopen() return type int * kbdclose() return type void * kbdioctl() return type int * kbdselect() Likewise * kbdread() Likewise * kdb_in_out() return type void * X_kdb_enter() Likewise * X_kdb_exit() Likewise * X_kdb_enter_init() Likewise * X_kdb_exit_init() Likewise * i386/i386at/kd_mouse.c * init_mouse_hw() return type void * mouseopen() return type int * serial_mouse_open() return type void * kd_mouse_open() Likewise * mouseclose() Likewise * serial_mouse_close() Likewise * kd_mouse_close() Likewise * mouseioctl() return type int * mouseselect() Likewise * mouseread() Likewise * mouseread() return type void * mouse_handle_byte() Likewise * mouse_packet_mouse_system_mouse() Likewise * mouse_packet_microsoft_mouse() Likewise * ibm_ps2_mouse_open() Likewise * ibm_ps2_mouse_close() Likewise * mouse_packet_ibm_ps2_mouse() Likewise * mouse_moved() Likewise * mouse_button() Likewise * i386/i386at/model_dep.c * i386at_init() return type void * timemmap() return type int * startrtclock() return type void * i386/i386at/lpr.c * lprprobe() return type int * lpropen() Likewise * lprclose() return type void * lprread() return type int * lprwrite() Likewise * lprportdeath() Likewise * lprstop() Likewise * lprpr() return type int * lprpr_addr() return type void * i386/i386/fpu.c * fpnoextflt() return type void * fpextovrflt() Likewise * fpexterrflt() Likewise * fp_save() Likewise * fp_load() Likewise * fpintr() Likewise * i386/i386/loose_ends.c * delay() return type void * i386/i386/phys.c * pmap_zero_page() return type void * pmap_copy_page() Likewise * copy_to_phys() Likewise * copy_from_phys() Likewise * i386/i386/pic.c * picinit() return type void * form_pic_mask() Likewise * intnull() Likewise * prtnull() Likewise * i386/i386/pit.c * clkstart() return type void * i386/intel/pmap.c * pmap_pageable() return type void Thanks, Barry deFreese (aka bddebian
Gnumach: locore.S copyin vs. copyinmsg
Hello again folks, Looking at more cleanup stuff I run across implicit declarations for copyin, copyinmsg, copyout, and copyoutmsg. From my extremely limited knowledge of assembler, copyin and copyinmsg look to be exactly the same. Is there any reason not to drop all instances of copyinmsg in favor of copyin, since copyin seems to be a standard? Here are parts of the code: from locore.S: ENTRY(copyin) Entry(copyinmsg) pushl %esi pushl %edi/* save registers */ snip from asm.h: #define ENTRY(x).globl EXT(x); .p2align TEXT_ALIGN; LEXT(x) #define Entry(x).globl EXT(x); .p2align TEXT_ALIGN; LEXT(x) Thanks!! Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach: locore.S copyin vs. copyinmsg
- Original Message - From: Thomas Bushnell BSG [EMAIL PROTECTED] To: Samuel Thibault [EMAIL PROTECTED] Cc: Barry deFreese [EMAIL PROTECTED]; bug-hurd@gnu.org Sent: Friday, November 10, 2006 1:04 PM Subject: Re: Gnumach: locore.S copyin vs. copyinmsg Yeah, I already added declarations for copyinmsg and copyoutmsg in locore.h. Thanks for the replies! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
