* kern/lock.h (simple_lock_data_empty): Define.
(decl_simple_lock_data, simple_unlock): Likewise.
* kern/sched_prim.c (lock): Declare.
[MACH_SLOCKS]: Remove #ifs.
* kern/task.c (task_lock, task_unlock): Remove address operator.
---
kern/lock.h | 6 --
kern/sched_prim.c | 18 +++
* ddb/db_command.h (db_error): Mark with attribute noreturn.
* i386/i386/setjmp.h (_longjmp): Likewise.
---
ddb/db_command.h | 2 +-
i386/i386/setjmp.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ddb/db_command.h b/ddb/db_command.h
index 5f0236a..634dd9d 100644
--- a/
Marin Ramesa, le Sun 15 Dec 2013 22:00:12 +0100, a écrit :
> @@ -228,6 +228,8 @@ void assert_wait(
> thread_tthread;
> #if MACH_SLOCKS
> simple_lock_t lock;
> +#else /* MACH_SLOCKS */
> + decl_simple_lock_data( , *lock);
> #endif /* MACH_SLOCKS */
Marin Ramesa, le Sun 15 Dec 2013 22:38:29 +0100, a écrit :
> On 15.12.2013 20:25:24, Samuel Thibault wrote:
> > Marin Ramesa, le Sun 15 Dec 2013 20:22:02 +0100, a écrit :
> > > On 15.12.2013 20:14:03, Samuel Thibault wrote:
> > > > Marin Ramesa, le Thu 12 Dec 2013 18:27:05 +0100, a écrit :
> > > >
On 15.12.2013 20:25:24, Samuel Thibault wrote:
> Marin Ramesa, le Sun 15 Dec 2013 20:22:02 +0100, a écrit :
> > On 15.12.2013 20:14:03, Samuel Thibault wrote:
> > > Marin Ramesa, le Thu 12 Dec 2013 18:27:05 +0100, a écrit :
> > > > There is a code path when db_error() can return.
> > >
> > > Which
* i386/i386/db_trace.c (db_lookup_i386_kreg) (kregp): Use (long *) instead of
an (int *).
---
i386/i386/db_trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/i386/i386/db_trace.c b/i386/i386/db_trace.c
index 6247d4f..d0c434e 100644
--- a/i386/i386/db_trace.c
+++ b/i386/i
* kern/lock.h (simple_lock_data_empty): Define.
(decl_simple_lock_data, simple_unlock): Likewise.
* kern/sched_prim.c (lock): Declare.
* kern/task.c (task_lock, task_unlock) (task): Remove address operator.
---
kern/lock.h | 6 --
kern/sched_prim.c | 6 ++
kern/task.c | 4 ++--
Marin Ramesa, le Sat 14 Dec 2013 17:58:54 +0100, a écrit :
> + if (strlen(data) != sizeof(struct vm_map_copy))
> + return KERN_INVALID_ARGUMENT;
Err, no, this does not make sense: if data is to be casted into
vm_map_copy, it's not a string, it's some structure with pointers etc
Justus Winter, le Fri 13 Dec 2013 13:03:07 +0100, a écrit :
> * utils/rpctrace.c (escape_sequences): New char array mapping
> characters to their escape sequence.
> (print_data): Escape non-printable characters when printing strings.
Ack on the principle for a fixed patch :)
> ---
> utils/rpctra
Justus Winter, le Sat 14 Dec 2013 13:42:17 +0100, a écrit :
> Quoting Ivan Shmakov (2013-12-13 17:05:19)
> > PS. Doesn’t Gnulib provide such a function already?
>
> Is it ok to use gnulib stuff in the Hurd?
In rpctrace it would probably not be a problem. About the code import
etc., I don't know
Justus Winter, le Fri 13 Dec 2013 15:52:38 +0100, a écrit :
> Currently, it is impossible to properly attribute response messages to
> requests. Even though rpctrace is single-threaded, its tracee may
> not. Or there might be more than one tracee. In any such case it is
> not guaranteed that the
Justus Winter, le Wed 11 Dec 2013 13:04:01 +0100, a écrit :
> This allows one to rpctrace processes doing select(2).
Ack.
> * utils/rpctrace.c (trace_and_forward): Handle MACH_MSG_TYPE_PORT_SEND
> rights.
> ---
> utils/rpctrace.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/u
Justus Winter, le Wed 11 Dec 2013 13:04:00 +0100, a écrit :
> Currently, rpctrace dies if a tracee uses select(2) because it asserts
> that reply_type is a MACH_MSG_TYPE_PORT_SEND_ONCE right. Generalize
> the code surrounding the failing assertion.
Ack.
> * utils/rpctrace.c (trace_and_forward):
Justus Winter, le Wed 11 Dec 2013 13:03:59 +0100, a écrit :
> * utils/rpctrace.c (rewrite_right): Generalize the code so we can use
> rewrite_right to rewrite MACH_MSG_TYPE_PORT_SEND rights for non-rpc ports.
Ack.
> ---
> utils/rpctrace.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletion
Richard Braun, le Mon 09 Dec 2013 14:10:32 +0100, a écrit :
> On Mon, Dec 09, 2013 at 12:59:33PM +0100, Samuel Thibault wrote:
> > No, it's really commenting c != K_DONE which makes the warning away. My
> > current guess is that c gets implicitly casted to int instead of
> > unsigned int.
>
> Just
On 15.12.2013 20:13:22, Samuel Thibault wrote:
> > index 8fe3672..67067cf 100644
> > --- a/kern/task.c
> > +++ b/kern/task.c
> > @@ -769,7 +769,7 @@ kern_return_t task_info(
> > event_info->cow_faults = task->cow_faults;
> > event_info->messages_sent = task->messages_sent;
Justus Winter, le Wed 20 Nov 2013 11:10:08 +0100, a écrit :
> Previously the mtab detector tried to detect whether it talks to
> itself by comparing the control port of the translator it currently
> visits with its own. This was done to prevent deadlocks. However, this
> did not detect non-trivial
Justus Winter, le Wed 20 Nov 2013 11:10:07 +0100, a écrit :
> Previously the mtab content was generated in the open hook. Delay this
> until the data is needed. A follow up patch will take advantage of
> this to both simplify the logic in mtab_populate and make it more
> robust at the same time.
A
Justus Winter, le Wed 20 Nov 2013 11:10:06 +0100, a écrit :
> * trans/mtab.c (main): Use ports_manage_port_operations_multithread.
Aren't mutexes needed to protect the struct mtab content? E.g.
trivfs_S_io_seek probably needs to take a mutex, to protect concurrent
seeks, as is done in hello-mt.c
Marin Ramesa, le Sun 15 Dec 2013 20:22:02 +0100, a écrit :
> On 15.12.2013 20:14:03, Samuel Thibault wrote:
> > Marin Ramesa, le Thu 12 Dec 2013 18:27:05 +0100, a écrit :
> > > There is a code path when db_error() can return.
> >
> > Which one?
>
> When _longjmp()
_longjmp never returns.
Samuel
On 15.12.2013 20:14:03, Samuel Thibault wrote:
> Marin Ramesa, le Thu 12 Dec 2013 18:27:05 +0100, a écrit :
> > There is a code path when db_error() can return.
>
> Which one?
When _longjmp() returns and db_recover and argument to db_error() are
non-zero.
Marin Ramesa, le Thu 12 Dec 2013 18:27:08 +0100, a écrit :
> This quiets the GCC warning about passing from incompatible pointer type.
>
> * i386/i386/db_trace.c (db_i386_reg_value) (db_lookup_i386_kreg) (STACK_IKS):
> Cast to (int *) instead to (long *).
db_lookup_i386_kreg should actually rath
Marin Ramesa, le Thu 12 Dec 2013 18:27:05 +0100, a écrit :
> There is a code path when db_error() can return.
Which one?
Samuel
Marin Ramesa, le Thu 12 Dec 2013 18:27:04 +0100, a écrit :
> --- a/kern/lock.h
> +++ b/kern/lock.h
> @@ -94,7 +94,10 @@ extern voidcheck_simple_locks(void);
> /*
> * Do not allocate storage for locks if not needed.
> */
> -#define decl_simple_lock_data(class,name)
> +struc
Marin Ramesa, le Wed 11 Dec 2013 17:30:42 +0100, a écrit :
> - (void) copyout((char *)&arg_count,
> + (void) copyout((void *)&arg_count,
No need to keep any cast in these cases: &foo is already a pointer,
implicit cast to (void*) will already happen.
Samuel
On Sun, Dec 15, 2013 at 02:43:50PM +0100, Marin Ramesa wrote:
> On 15.12.2013 14:00:22, Richard Braun wrote:
> > What makes you think the content could be something else than a
> > vm_map_copy object ?
>
> Well io_data is a pointer to char, not a pointer to vm_map_copy. And
> there is not one mem
On 15.12.2013 14:00:22, Richard Braun wrote:
> On Sat, Dec 14, 2013 at 01:32:27PM +0100, Marin Ramesa wrote:
> > On 14.12.2013 12:45:32, Richard Braun wrote:
> > > I really don't see a problem in that code, you'll have to
> > > describe it better.
> >
> > So a pointer to io_data is cast to a poi
On Sat, Dec 14, 2013 at 01:32:27PM +0100, Marin Ramesa wrote:
> On 14.12.2013 12:45:32, Richard Braun wrote:
> > I really don't see a problem in that code, you'll have to describe it
> > better.
>
> So a pointer to io_data is cast to a pointer to a vm_map_copy structure
> and then passed to vm_m
---
chips/busses.c | 8
chips/busses.h | 8
ddb/db_aout.c| 34 +-
ddb/db_break.c | 20 ++--
ddb/db_break.h | 12 ++--
ddb/db_command.c | 22 +++---
ddb/db_command.h |
29 matches
Mail list logo
