Em 2010.07.16. 12:17, pluknet escreveu:
Almost the same (#__jid_t#jid_t#).
Did you have to include any header for that? IIRC, I used __jid_t
because it didn't compile with jid_t.
The difference (and probably a trigger of bug elsewhere) might be in
that this lives
on amd64 arch (while yours
On 16 July 2010 01:42, Gabor Kovesdan wrote:
> Em 2010.07.13. 16:05, pluknet escreveu:
>>
>> #ifndef _SYS_SYSPROTO_H_
>> struct setjlimit_args {
>> jid_t jid;
>> int resource;
>> struct rlimit *rlp;
>> };
>> #endif
>> int
>> setjlimit(td, uap)
>> struct thread
Em 2010.07.13. 16:05, pluknet escreveu:
#ifndef _SYS_SYSPROTO_H_
struct setjlimit_args {
jid_t jid;
int resource;
struct rlimit *rlp;
};
#endif
int
setjlimit(td, uap)
struct thread *td;
struct setjlimit_args /* {
jid_t jid;
On 12 July 2010 15:11, Gabor Kovesdan wrote:
> Em 2010.07.12. 9:00, pluknet escreveu:
>>
>> Looking at getjid() impl, I see you're trying to put jid_t into the
>> one register_t
>> which are 64-bit vs 32-bit capable respectively.
>> You need to cast so you put 64-bit into two 32-bit as done for e.
Em 2010.07.12. 9:00, pluknet escreveu:
Looking at getjid() impl, I see you're trying to put jid_t into the
one register_t
which are 64-bit vs 32-bit capable respectively.
You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek().
Thanks for pointing this out, probably this w
On 11 July 2010 18:58, Gabor Kovesdan wrote:
> Em 2010.07.11. 16:54, Dimitry Andric escreveu:
>>
>> On 2010-07-11 16:46, Gabor Kovesdan wrote:
>>
>>>
>>> I have two int64_t variables in kernel code, first is stored internally
>>> and the second one is passed from a syscall argument. When I print t
Em 2010.07.11. 17:33, m...@freebsd.org escreveu:
What does struct killjob_args look like?
It's just what make sysent generated:
+struct killjob_args {
+ char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)];
+ char signal_l_[PADL_(int)]; int signal; char signal_r
On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan wrote:
> Em 2010.07.11. 16:54, Dimitry Andric escreveu:
>>
>> On 2010-07-11 16:46, Gabor Kovesdan wrote:
>>
>>>
>>> I have two int64_t variables in kernel code, first is stored internally
>>> and the second one is passed from a syscall argument. When
On 11.07.2010 18:46, Gabor Kovesdan wrote:
> I have two int64_t variables in kernel code, first is stored internally
> and the second one is passed from a syscall argument. When I print them
> with printf %lld modifier, the internal one behaves correctly but the
> other one I pass from a syscall ha
Em 2010.07.11. 16:54, Dimitry Andric escreveu:
On 2010-07-11 16:46, Gabor Kovesdan wrote:
I have two int64_t variables in kernel code, first is stored internally
and the second one is passed from a syscall argument. When I print them
with printf %lld modifier, the internal one behaves correc
On 2010-07-11 16:46, Gabor Kovesdan wrote:
> I have two int64_t variables in kernel code, first is stored internally
> and the second one is passed from a syscall argument. When I print them
> with printf %lld modifier, the internal one behaves correctly but the
> other one I pass from a syscall
Hi,
I have two int64_t variables in kernel code, first is stored internally
and the second one is passed from a syscall argument. When I print them
with printf %lld modifier, the internal one behaves correctly but the
other one I pass from a syscall has a corrupted value. If I pass 1, it
prin
12 matches
Mail list logo
