Re: [PATCH 1/2] hurd: add a new type interrupt_t for the interrupt protocol
Justus Winter, le Wed 09 Apr 2014 23:17:27 +0200, a écrit : * hurd/hurd_types.defs (interrupt_t): New type. * hurd/hurd_types.h (interrupt_t): Likewise. * hurd/interrupt.defs (interrupt_operation): Use the new type. Ack. --- hurd/hurd_types.defs | 12 hurd/hurd_types.h| 1 + hurd/interrupt.defs | 6 +- 3 files changed, 18 insertions(+), 1 deletion(-) diff --git a/hurd/hurd_types.defs b/hurd/hurd_types.defs index 6060fa4..129a68c 100644 --- a/hurd/hurd_types.defs +++ b/hurd/hurd_types.defs @@ -168,6 +168,18 @@ destructor: EXEC_STARTUP_DESTRUCTOR #endif ; +type interrupt_t = mach_port_copy_send_t +#ifdef INTERRUPT_INTRAN +intran: INTERRUPT_INTRAN +#endif +#ifdef INTERRUPT_OUTTRAN +outtran: INTERRUPT_OUTTRAN +#endif +#ifdef INTERRUPT_DESTRUCTOR +destructor: INTERRUPT_DESTRUCTOR +#endif +; + type proccoll_t = mach_port_copy_send_t; diff --git a/hurd/hurd_types.h b/hurd/hurd_types.h index d569454..8eac206 100644 --- a/hurd/hurd_types.h +++ b/hurd/hurd_types.h @@ -47,6 +47,7 @@ typedef mach_port_t addr_port_t; typedef mach_port_t startup_t; typedef mach_port_t fs_notify_t; typedef mach_port_t exec_startup_t; +typedef mach_port_t interrupt_t; typedef mach_port_t proccoll_t; #include errno.h /* Defines `error_t'. */ diff --git a/hurd/interrupt.defs b/hurd/interrupt.defs index cc3ad1e..9981aed 100644 --- a/hurd/interrupt.defs +++ b/hurd/interrupt.defs @@ -23,10 +23,14 @@ subsystem interrupt 33000; #include hurd/hurd_types.defs +#ifdef INTERRUPT_IMPORTS +INTERRUPT_IMPORTS +#endif + /* Cause a pending request on this object to immediately return. The exact semantics are dependent on the specific object. */ routine -interrupt_operation (object: mach_port_t; +interrupt_operation (object: interrupt_t; waittime timeout: natural_t; msgseqno seqno: mach_port_seqno_t); -- 1.9.1 -- Samuel s bah, j'aime bien les feux d'artifices, mais j'ai peur de me prendre un boeing sur le coin de la gueule si je vais sur le pont de brooklyn -+- #ens-mim - 11 septembre forever -+-
Re: [PATCH 2/2] libports: fix receiver lookup
Justus Winter, le Wed 09 Apr 2014 23:17:28 +0200, a écrit :
* libports/interrupt-operation.c (ports_S_interrupt_operation): Fix
receiver lookup.
* libports/mig-mutate.h: Add mutators.
* libports/ports.h: Remove superfluous declarations.
Ack.
---
libports/interrupt-operation.c | 4 +---
libports/mig-mutate.h | 7 +++
libports/ports.h | 5 -
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libports/interrupt-operation.c b/libports/interrupt-operation.c
index 19c0edf..943bd4f 100644
--- a/libports/interrupt-operation.c
+++ b/libports/interrupt-operation.c
@@ -24,10 +24,9 @@
/* Cause a pending request on this object to immediately return. The
exact semantics are dependent on the specific object. */
kern_return_t
-ports_S_interrupt_operation (mach_port_t port,
+ports_S_interrupt_operation (struct port_info *pi,
mach_port_seqno_t seqno)
{
- struct port_info *pi = ports_lookup_port (0, port, 0);
if (!pi)
return EOPNOTSUPP;
pthread_mutex_lock (_ports_lock);
@@ -35,6 +34,5 @@ ports_S_interrupt_operation (mach_port_t port,
pi-cancel_threshold = seqno;
pthread_mutex_unlock (_ports_lock);
ports_interrupt_rpcs (pi);
- ports_port_deref (pi);
return 0;
}
diff --git a/libports/mig-mutate.h b/libports/mig-mutate.h
index f692236..4c011b6 100644
--- a/libports/mig-mutate.h
+++ b/libports/mig-mutate.h
@@ -23,3 +23,10 @@
end_using_port_info (port_info_t)
#define NOTIFY_IMPORTS \
import libports/mig-decls.h;
+
+#define INTERRUPT_INTRAN \
+ port_info_t begin_using_port_info_port (mach_port_t)
+#define INTERRUPT_DESTRUCTOR \
+ end_using_port_info (port_info_t)
+#define INTERRUPT_IMPORTS\
+ import libports/mig-decls.h;
diff --git a/libports/ports.h b/libports/ports.h
index 47d4607..7f13124 100644
--- a/libports/ports.h
+++ b/libports/ports.h
@@ -398,11 +398,6 @@ extern kern_return_t
ports_do_mach_notify_port_destroyed (struct port_info *pi, mach_port_t
name);
extern kern_return_t
ports_do_mach_notify_send_once (struct port_info *pi);
-
-/* A default interrupt server */
-int ports_interrupt_server (mach_msg_header_t *, mach_msg_header_t *);
-extern kern_return_t ports_S_interrupt_operation (mach_port_t,
- mach_port_seqno_t);
/* Private data */
extern pthread_mutex_t _ports_lock;
--
1.9.1
--
Samuel
Progress (n.): The process through which the Internet has evolved from
smart people in front of dumb terminals to dumb people in front of smart
terminals.
Re: problem on shut-down
Hi, let me add also: 4) connect through telnet, gracefully close the telnet connection by logging out, shut down: hang Riccardo Riccardo Mottola wrote: Hi, I was able to investigate this more. I have the inconveninece that at every HURD shtudown (even if graceful) I lookse my datetime in the bios... Justus Winter wrote: Sometimes bugs can't be easily reproduced, sadly. One needs to gather information in the best possible way then... Yes, thanks for reporting. Keep at it, we'll get it eventually:) I tried the following: 1) clean boot, shutdown. Fine 2) clean boot, remote ssh, local shutdown. Fine 3) clean boot, remote telnet, local shutdown. hangs so it appears to be something with my xinted/telnetd! Riccardo
Re: problem on shut-down
Quoting Riccardo Mottola (2014-04-09 23:35:16) Hi, I was able to investigate this more. I have the inconveninece that at every HURD shtudown (even if graceful) I lookse my datetime in the bios... Justus Winter wrote: Sometimes bugs can't be easily reproduced, sadly. One needs to gather information in the best possible way then... Yes, thanks for reporting. Keep at it, we'll get it eventually:) I tried the following: 1) clean boot, shutdown. Fine 2) clean boot, remote ssh, local shutdown. Fine 3) clean boot, remote telnet, local shutdown. hangs so it appears to be something with my xinted/telnetd! Could you please specify which packages you are using? Debian has three telnetd packages, and I don't seem to be able to locate the xinetd package at all. Justus
Circular dependency with glibc libpthread libihash
When libpthread tries to link against libihash.so I get the error: /lib/libihash.so: file not recognized: File format not recognized. This happens because libihash was built using the native compiler. So I changed the flag in libihash configure to --host so it will use the cross-compiler. But then I got the error configure:3008: error: C compiler cannot create executables. I read the config.log file and the problem arise from this /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: cannot find crt1.o: No such file or directory /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: cannot find crti.o: No such file or directory /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: cannot find -lc /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: cannot find crtn.o: No such file or directory It tries to compile a program, but cannot find these files, so it fails. But in order to have them we need glibc. We have a circular dependency glibc+libpthread - libihash - glibc, so I guess an intermediate glibc is our only option. Or is there another way?
Re: Circular dependency with glibc libpthread libihash
Manolis Ragkousis, le Fri 11 Apr 2014 00:03:40 +, a écrit : When libpthread tries to link against libihash.so I get the error: /lib/libihash.so: file not recognized: File format not recognized. This happens because libihash was built using the native compiler. So I changed the flag in libihash configure to --host so it will use the cross-compiler. But then I got the error configure:3008: error: C compiler cannot create executables. It tries to compile a program, but cannot find these files, so it fails. But in order to have them we need glibc. We have a circular dependency glibc+libpthread - libihash - glibc, so I guess an intermediate glibc is our only option. Or is there another way? I'd say the build system of the hurd repository should be made to accept not to be able to build programs, and then only build the libraries in that case. That way it won't need crt stuff. Samuel
