On Mon, May 27, 2013 at 05:00:13AM +, Orit Moskovich wrote:
Just to be more specific - On x86, during a filter routine all interrupts are
disabled on the cpu currently handling a filter routine or only interrupts on
the IRQ that generated the interrupt?
The CPU enters the handler
on 27/05/2013 09:34 Konstantin Belousov said the following:
Having both filter and ithread for the same interrupt is apparently
possible but weird. I do not see anything which would prevent interrupt
filter from being executed while the ithread is running. But again, this
is very unusual
What is actually the difference between deferring a filter routine's work using
an ithread given to bus_setup_intr, or using the global taskqueue_swi
(implemented using interrupt thread)?
What do you mean that the functionality is locked under INTR_FILTER?
-Original Message-
From:
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK);
+ va = (*lp - mask01);
+ vb = ((~*lp) mask80);
I do not think that this correct C.
Le 27/05/2013 10:37, Václav Zeman a écrit :
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK);
+ va = (*lp - mask01);
+ vb = ((~*lp)
On 2013-05-27 04:37, Václav Zeman wrote:
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str
~LONGPTR_MASK);
+ va = (*lp - mask01);
+ vb = ((~*lp)
On 2013-05-27 10:37, Václav Zeman wrote:
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK);
+ va = (*lp - mask01);
+ vb = ((~*lp)
On 27 May 2013 12:25, Adam Nowacki wrote:
On 2013-05-27 10:37, Václav Zeman wrote:
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK);
+ va
On 27 May 2013 12:20, Lee Thomas wrote:
On 2013-05-27 04:37, Václav Zeman wrote:
On 26 May 2013 21:01, Lee Thomas wrote:
On 2013-05-26 08:00, Václav Zeman wrote:
On 05/25/2013 10:27 PM, Lee Thomas wrote:
+ lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK);
+ va =
on 27/05/2013 10:21 Orit Moskovich said the following:
What is actually the difference between deferring a filter routine's work
using an ithread given to bus_setup_intr, or using the global taskqueue_swi
(implemented using interrupt thread)?
I think you mean taskqueue_fast.
The difference
From what I've read in subr_taskqueue.c taskqueue_swi, taskqueue_swi_giant and
taskqueue_fast are all implemented using swi_add which calls ithread_create().
Is there any performance difference between them. Is one of the above or
ithread given to bus_setup_intr preferable on the other?
[trimmed cc]
on 27/05/2013 15:29 Orit Moskovich said the following:
From what I've read in subr_taskqueue.c taskqueue_swi, taskqueue_swi_giant
and taskqueue_fast are all implemented using swi_add which calls
ithread_create().
Is there any performance difference between them. Is one of the
On 5/26/13 10:03 AM, Dirk Engling wrote:
On 26.05.13 04:51, Super Bisquit wrote:
Please don't turn this into an architecture dependent mess. PCBSD is
i386 AMD64 only.
Read my email thoroughly and notice that I never seriously considered
using pc-sysinstall after looking into it. Don't worry.
On 5/25/13 8:45 PM, Teske, Devin wrote:
On May 25, 2013, at 7:51 PM, Super Bisquit wrote:
Please don't turn this into an architecture dependent mess. PCBSD is i386
AMD64 only.
There's a GSoC project (of which I'm potential mentor) to fix that.
However, you are entirely right… we can't in
On 27 May 2013 03:10, Daniel Eischen deisc...@freebsd.org wrote:
On Mon, 27 May 2013, Teske, Devin wrote:
I don't think there's any reason why we have to write it in C if we can
write
it in sh.
I don't really care one way or the other (C or sh), but
I can say that I can understand(*)
On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms
that it performs best on and use bsdinstall on the others?
Because pc-sysinstall doesn't have a UI - it's only a backend. If we
update bsdinstall to use it, then it won't work on
I have 4 hard drives, each containing a swap partition of size 1023MiB. I get:
warning: total configured swap (1178880 pages) exceeds maximum recommended
amount (1012480 pages).
warning: increase kern.maxswzone or reduce amount of swap.
Is the warning safe to ignore? I assume that only 3955MiB
On 5/27/13 9:56 AM, Bruce Cran wrote:
On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms
that it performs best on and use bsdinstall on the others?
Because pc-sysinstall doesn't have a UI - it's only a backend. If we
update
Index: strnlen.c
===
diff --git a/head/lib/libc/string/strnlen.c b/head/lib/libc/string/strnlen.c
--- a/head/lib/libc/string/strnlen.c (revision 250951)
+++ b/head/lib/libc/string/strnlen.c (working copy)
@@ -1,5 +1,6 @@
On 27/05/2013 19:03, Alfred Perlstein wrote:
Do we always have to seek the lowest common denominator for our user
experience?
Yes.
--
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
On May 27, 2013, at 11:03 AM, Alfred Perlstein wrote:
On 5/27/13 9:56 AM, Bruce Cran wrote:
On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms that
it performs best on and use bsdinstall on the others?
Because pc-sysinstall
9.1-RELEASE-p3
---
#!/bin/sh
sh_f ()
{
global_scope_var=7463457
}
yes | sh_f
echo $global_scope_var
echo '
Now without /usr/bin/yes (maybe it is STDIN issue, instead) ?!?
'
sh_f
echo $global_scope_var
---
Domagoj Smolčić
from SH(1)
Note that unlike some other shells, sh executes each process in a pipe-
line with more than one command in a subshell environment and as a
child
of the sh process.
I'm taking this to mean that redirecting to sh_f has sh_f execute in a
subshell in which global_scope_var
Hello Tim,
Thank you for the review; replies inline. Note that all my performance
discussion is for amd64, with a few tests of x86, and it's all on the
machine described in my initial email (a Lynnfield Xeon), as I don't
have any other FreeBSD platform to test on. Testing and performance
On 5/27/13 11:40 AM, Bruce Cran wrote:
On 27/05/2013 19:03, Alfred Perlstein wrote:
Do we always have to seek the lowest common denominator for our user
experience?
Yes.
Is this a joke?
-Alfred
___
freebsd-hackers@freebsd.org mailing list
I heard there was some discussion at BSDCan about the direction of a future
FreeBSD installer. Considering we currently have bsdinstall, pc-sysinstall,
the best would be removing it at all and adding instruction how to install
by hand.
At least someone that install FreeBSD will know what
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think there should be
a single UI and scripting interface across all platforms. We should try
and get pc-sysinstall running on all of
On 05/27/13 16:23, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think there should
be a single UI and scripting interface across all platforms. We should
try and
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think there should
be a single UI and scripting interface across all platforms. We should
try
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think there should
be a single UI and scripting
On May 26, 2013, at 12:37 PM, Teske, Devin wrote:
On May 26, 2013, at 11:14 AM, Bruce Cran wrote:
On 26/05/2013 18:54, Teske, Devin wrote:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
This proposal is not made public, and you are not the student who
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think
32 matches
Mail list logo