on 09/07/2010 13:34 Andriy Gapon said the following:
> Having thought and experimented more, I don't see why we need inline assembly
> at
> all and why DPCPU_DEFINE can not simply be defined as follows:
>
> #define DPCPU_DEFINE(t, n)\
> t DPCPU_NAME(n) __section("set_pcpu") \
> __
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
> http://people.freebsd.org/~avg/dpcpu/dpcpu.n
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~
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
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
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 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
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
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
So, long story short... I've basically ported the open posix testsuite
to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
sucker hangs on my dev box at home.
I've written a short testcase that demonstrates this. It prints out:
$ ~/test_sigpause
0
And proceeds to be unresponsi
On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
> So, long story short... I've basically ported the open posix testsuite
> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
> sucker hangs on my dev box at home.
>
> I've written a short testcase that demonstrate
On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
> On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>> So, long story short... I've basically ported the open posix testsuite
>> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
>> sucker hangs on my dev bo
on 12/07/2010 00:15 Jeff Roberson said the following:
>
> On Sun, 11 Jul 2010, Andriy Gapon wrote:
>
>>
>> [oops, sorry, this is not a dup - corrected some omissions/mistakes]
>>
>> on 11/07/2010 14:54 Andriy Gapon said the following:
>>> For completeness, here is a patch that simply drops the in
On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
> >> So, long story short... I've basically ported the open posix testsuite
> >> to FreeBSD, and one of the
2010/7/11 Kostik Belousov :
> On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
>> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
>> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>> >> So, long story short... I've basically ported the open posix testsuite
On Sun, Jul 11, 2010 at 3:35 PM, Garrett Cooper wrote:
> 2010/7/11 Kostik Belousov :
>> On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
>>> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov
>>> wrote:
>>> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>>> >> So,
2010/7/11 Alexander Kabaev :
> On Sun, 11 Jul 2010 15:59:05 -0700
> Garrett Cooper wrote:
>
>> > + if (!_SIG_VALID(how))
>> > + return (-EINVAL);
>
> -EINVAL? Smells too much of Linux, try returning EINVAL instead.
Wow, I'm batting 1,000 today. Please completely ignore my prev
On Sun, 11 Jul 2010 15:59:05 -0700
Garrett Cooper wrote:
> > + if (!_SIG_VALID(how))
> > + return (-EINVAL);
-EINVAL? Smells too much of Linux, try returning EINVAL instead.
--
Alexander Kabaev
signature.asc
Description: PGP signature
On Sun, Jul 11, 2010 at 4:19 PM, Garrett Cooper wrote:
> 2010/7/11 Alexander Kabaev :
>> On Sun, 11 Jul 2010 15:59:05 -0700
>> Garrett Cooper wrote:
>>
>>> > + if (!_SIG_VALID(how))
>>> > + return (-EINVAL);
>>
>> -EINVAL? Smells too much of Linux, try returning EINVAL instead
Hi,
On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote:
> Hello,
> I would like to know the memory usage (total virtual memory) inside a
> process and make decisions accordingly.
> To be more specific, I am using BerkeleyDB backed set or std::set (C++
> STL) depending on my current memory usage
> as
On 12/07/2010, at 12:40, dhruva wrote:
> On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote:
>> Hello,
>> I would like to know the memory usage (total virtual memory) inside a
>> process and make decisions accordingly.
>> To be more specific, I am using BerkeleyDB backed set or std::set (C++
>> STL)
On Fri, Jul 09, 2010 at 07:56:37AM -0700, Garrett Cooper wrote:
> (Let's try this again with the right email address)
> Something simple that I noticed a while back when I was reviewing
> the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the
> conditional feature checks, which
22 matches
Mail list logo
