Re: making consmsgbuf_size a tunable?
Hello Matthew, * Matthew Jacob m...@feral.com wrote: Any thoughts about this? Looks good. Maybe we should make it a tunable only? Looking at the code, once the consbuf has been allocated, there is no way you can ever resize it. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpvMZK9ULhdP.pgp Description: PGP signature
Re: GSoC: Making ports work with clang
On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: On Sun, 02 May 2010 10:25:22 +0300, Yuri y...@rawbw.com wrote: Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. [snip] Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. Too true. [snip] You will just keep stumbling upon various problems with various ports I've mentioned that I've been involved with ports+clang since last October. Stumbling upon various problems is what I do. I'm still here, even doing a GSoC project, so it doesn't look like various problems will scare me off. And as I've mentioned above, just because some ports don't compile, it doesn't affect this project too much. Well said, well meant. Kudos. Thanks for your work so far, and thanks for taking up that GSoC project. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence. pgpoRO1eWZrzy.pgp Description: PGP signature
Re: GSoC: Making ports work with clang
Peter Pentchev wrote: On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: On Sun, 02 May 2010 10:25:22 +0300, Yuri y...@rawbw.com wrote: Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. [snip] Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. Too true. I can understand from a commercial perspective why having a permissive licensed production compiler could be good.. I can understand why many people don't like gcc or fsf, but what does the BSD community get? 1) Performance? 2) Robustness? 3) ... ? What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Starting early can give valuable feedback , but without actually having the resources to follow-up it's wasted effort. Is llvm at the point where it can self host BSD? If not why not start there? Maybe identify the most used applications.. I don't waste time on front-end work though so this is of course my humble opinion.. ./C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On 2010-05-03 12:38, C. Bergström wrote: What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Of course it does. It forces you to make your software portable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On 3.5.2010 12:38, C. Bergström wrote: the resources to follow-up it's wasted effort. Is llvm at the point where it can self host BSD? If not why not start there? Maybe identify the most used applications.. http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016648.html -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
Dimitry Andric wrote: On 2010-05-03 12:38, C. Bergström wrote: What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Of course it does. It forces you to make your software portable. and your point is? Are you trying to say that s/building/porting/ between compilers is going to magically make the software (have less bugs, more performance or better robustness) Porting could be a means-to-an-end, but still it's not an end goal.. I'm digging at what's the end goal.. After it's all ported what magically happens? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Mon, May 03, 2010 at 06:19:48PM +0700, C. Bergstr??m wrote: Dimitry Andric wrote: On 2010-05-03 12:38, C. Bergstr??m wrote: What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Of course it does. It forces you to make your software portable. and your point is? Are you trying to say that s/building/porting/ between compilers is going to magically make the software (have less bugs, more performance or better robustness) Porting could be a means-to-an-end, but still it's not an end goal.. I'm digging at what's the end goal.. After it's all ported what magically happens? For me, the project that makes sense is exactly making freebsd ports work with clang, instead of what many have read making applications ported to freebsd and compiled with clang work. Please note the subtle but very important difference. Even more, I do think that making our ports work with exactly clang does not give us any useful bits, except putting the port _infrastructure_ into shape where it can use non-base compilers, as easy as changing two or three variables. Being able to decouple base and port compilers, and give the port system the freedom to use whatever compiler the port masters find suitable is very important. It is important both for ports, to not need to make a rush run to fix after base changes, and it is important for base to not hold on ports much to make a change. Other then that, I mostly share your refusal to drink the Kool-Aid. pgpRBbwAsfij1.pgp Description: PGP signature
Re: GSoC: Making ports work with clang
On Mon, 03 May 2010 13:38:07 +0300, C. Bergström cbergst...@pathscale.com wrote: I can understand from a commercial perspective why having a permissive licensed production compiler could be good.. I can understand why many people don't like gcc or fsf, but what does the BSD community get? 1) Performance? 2) Robustness? 3) ... ? Seeing how often I see this question, maybe I'll write (or force rdivacky@ to do it) an explanation why clang/llvm is good for FreeBSD. Anyway, for now, very short version: 1) Performance - in the long run, yes. gcc 4.2 in base will not be updated anymore. llvm on the other hand is actively developed and includes fancy stuff that new CPUs have. Clang also compiles stuff faster than gcc. 2) Robustness - not yet. It's still too early to rely on stability of clang/llvm, but eventually it will get better. 3) BSD-like license, C99 and eventually C++0x support. I'm too lazy to think about this right now. What's really the goal here? To quote myself: make clang and ports to be friendly with each other. My goals are stated in the initial email and the wiki. I'll update the wiki with some clarification on what are and what are not my goals when I have more time. What problem are you working to solve? The problem is that ports tree is full of assumptions that compiler is gcc. At the moment, there is no way to use alternative compiler without breaking too many things. May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. I prefer to think that compiling software with clang is making world a better place. More seriously - clang is much more strict than gcc. It forces people to write better, standard C/C++ code and not some random walls of incomprehensible text that remotely resemble C or C++, but can't even be compiled by later versions of gcc itself. I've already seen a lot of things being fixed because clang found a bug that gcc missed, or application relied on some weird gcc-specific behaviour and clang refused to compile it. Starting early can give valuable feedback , but without actually having the resources to follow-up it's wasted effort. Well it's my effort that's wasted, I don't see how that's bad for anyone else. And I don't plan to waste anything, I've mentioned that some of the things I'm going to do over summer (and have been doing till now) aren't clang-specific. It will also help compile ports with new versions of gcc (or any other standard C/C++ compiler), and I don't think I need to explain why newer versions of software are usually better. Is llvm at the point where it can self host BSD? You obviously aren't subscribed to freebsd-current@, are you? http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016648.html If not why not start there? It's been started some time ago, by other people. The reason I'm doing this as a GSoC project is because the person currently working on ClangBSD suggested me to do it. Maybe identify the most used applications.. Not sure if you're talking about base system or ports here. I've mentioned that I want to get commonly used ports to work, and I've been doing something like that for some time now. If you're talking about base system, the problem isn't identifying most used applications, it's to fix whatever is still broken. Most of FreeBSD base system works with clang without problems. -- Andrius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On 03/05/2010 12:38, C. Bergström wrote: What's really the goal here? In my opinion it's about staying away from the GPLv3. According to my understanding of the situation, GPLv3 code is not accepted into the project and that means we're stuck with gcc 4.2, which has already reached its EOL. The way I see it we /desperately/ need a new compiler for the base system. Having GPLv3 stuff in Ports is all right, so getting the base system to compile was the most important step. Now that it does I think the change should be made as soon as all the supported architectures work with clang. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Mon, 03 May 2010 14:27:52 +0300, Kostik Belousov kostik...@gmail.com wrote: For me, the project that makes sense is exactly making freebsd ports work with clang, instead of what many have read making applications ported to freebsd and compiled with clang work. Please note the subtle but very important difference. Even more, I do think that making our ports work with exactly clang does not give us any useful bits, except putting the port _infrastructure_ into shape where it can use non-base compilers, as easy as changing two or three variables. Being able to decouple base and port compilers, and give the port system the freedom to use whatever compiler the port masters find suitable is very important. It is important both for ports, to not need to make a rush run to fix after base changes, and it is important for base to not hold on ports much to make a change. Other then that, I mostly share your refusal to drink the Kool-Aid. Finally, someone who understands the benefits of my project and what I'm trying to do! Of course it's my own fault for not explaining my goals clearly enough, but now I know where to point when I try to explain what I'm doing or why it's good for FreeBSD. -- Andrius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
Andrius Morkūnas wrote: On Mon, 03 May 2010 13:38:07 +0300, C. Bergström cbergst...@pathscale.com wrote: I can understand from a commercial perspective why having a permissive licensed production compiler could be good.. I can understand why many people don't like gcc or fsf, but what does the BSD community get? 1) Performance? 2) Robustness? 3) ... ? Seeing how often I see this question, maybe I'll write (or force rdivacky@ to do it) an explanation why clang/llvm is good for FreeBSD. Anyway, for now, very short version: 1) Performance - in the long run, yes. gcc 4.2 in base will not be updated anymore. llvm on the other hand is actively developed and includes fancy stuff that new CPUs have. Clang also compiles stuff faster than gcc. What fancy stuff is in the ports tree which clang will take advantage of? 2) Robustness - not yet. It's still too early to rely on stability of clang/llvm, but eventually it will get better. sarcasmI wish someone would just buy and open source EDG.. It would be a lot faster and less expensive/sarcasm 3) BSD-like license, C99 and eventually C++0x support. I'm too lazy to think about this right now. What's really the goal here? To quote myself: make clang and ports to be friendly with each other. My goals are stated in the initial email and the wiki. I'll update the wiki with some clarification on what are and what are not my goals when I have more time. What problem are you working to solve? The problem is that ports tree is full of assumptions that compiler is gcc. At the moment, there is no way to use alternative compiler without breaking too many things. This is something I can clearly relate to and would see as beneficial. I can't say the gentoo/arch approach is correct, but it may not be a bad idea to steal whatever they have have done correctly. I'd be more than happy to help or work with you if it's feasible to add another compiler to this project. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On 2010-05-03 13:19, C. Bergström wrote: Of course it does. It forces you to make your software portable. and your point is? Are you trying to say that s/building/porting/ between compilers is going to magically make the software (have less bugs, more performance or better robustness) No, it gives you the choice of which compiler to use. Porting could be a means-to-an-end, but still it's not an end goal.. I'm digging at what's the end goal.. After it's all ported what magically happens? You can then switch compilers freely, or at least, without too much effort. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Mon, 03 May 2010 15:34:43 +0300, C. Bergström cbergst...@pathscale.com wrote: What fancy stuff is in the ports tree which clang will take advantage of? I wasn't talking about any specific port. What I meant is that new hardware won't stop coming out just because FreeBSD decided not to update their gcc. New CPUs may have new instructions and other things that are different from their predecessors in one way or another. While llvm will continue to chase the hardware and implement new optimizations, gcc in base will not be aware of those changes, continuing to produce code that runs, but may may be missing potential optimizations on those CPUs. I hope this makes sense. I can't say the gentoo/arch approach is correct, but it may not be a bad idea to steal whatever they have have done correctly. Maybe, but to steal something, I'd have to know what is gentoo/arch approach first. I'd be more than happy to help or work with you if it's feasible to add another compiler to this project. Hopefully, when I finish the project it will be relatively easy to add support for other compilers. -- Andrius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Libpkg, package tools
On Sat, May 1, 2010 at 3:32 PM, David Forsythe dfors...@freebsd.org wrote: Hi all, hello david I'm David Forsythe, and I'll be working on completing libpkg (started during Summer of Code 2009) and putting together some production ready package tools. My mentor will be Tim Kientzle. that's a great news You can email me on or off list is you have any questions, comments, or suggestions. Or if you just want to say hi. okey .. i want to ask you that the library have notifications callbacks in order to know the progress of the package operation example: pkg_add = start, download, download progress, getting dependencies, bla bla bla pkg_delete = analizing package, removing files, execing uninstall operations, deleting, bla bla bla bla bla bla well thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] RUSAGE_THREAD
Kostik,
thank you very much for the review!
Kostik Belousov wrote:
On Mon, Apr 19, 2010 at 12:46:48AM +, Alexander Krizhanovsky wrote:
Hi all!
This patch implements per-thread rusage statistic (like RUSAGE_THREAD in
Linux and RUSAGE_LWP in OpenSolaris).
Unfortunately, we have to acquire a number of locks to read/update
system and user times for current thread rusage information because it's
also used for whole process statistic and needs to be zeroed.
Any comments are very appreciated.
It's tested against 8.0-RELEASE. Appropriate PR is submitted.
--
Alexander Krizhanovsky
NatSys Lab. (http://natsys-lab.com)
tel: +7 (916) 717-3899, +7 (499) 747-6304
e-mail: a...@natsys-lab.com
I think this should be somewhat modified before commit.
First, please separate patch into two pieces. One would introduce
ruxagg_tlock() helper and use it in existing locations instead of
three-liners. Possibly, add KR-ANSI C kern_getrusage definition
change.
Second would actually add RUSAGE_THREAD. There, please follow
the style(9), in particular, do not initialize the local variables
at the declaration, instead, use explicit initialization in the code.
Done. I have also introduced third patch for casting microseconds to
timeval and replaced a few appropriate places in whole kernel code.
patch-rusage-thread-03052010.txt is incremental for
patch-ruxagg_tlock-03052010.txt, which is by turn incremental for
patch-usec2timeval-03052010.txt.
I have made following change for calcru1():
- if ((int64_t)tu 0) {
- /* XXX: this should be an assert /phk */
- printf(calcru: negative runtime of %jd usec for pid %d
(%s)\n,
- (intmax_t)tu, p-p_pid, p-p_comm);
- tu = ruxp-rux_tu;
- }
+ KASSERT((int64_t)tu 0, (calcru: negative runtime of %jd usec
+ for pid %d (%s)\n,
+ (intmax_t)tu, p-p_pid, p-p_comm));
tu can become negative at about 300 thousand years of uptime, so this
condition seems quite unrealistic and indeed should be replaced by an
assertion. However I didn't understand why it isn't done so far and the
comment only was added. Did I miss something?
Should calctru() share the code with calcru1() ? I am esp. concerned
with sanity check like negative runtime etc. Possibly, this code
from calcru1() should be separated into function used from both
calcru1() and calctru().
Man page for getrusage(2) should be updated.
It's added to patch-rusage-thread-03052010.txt.
In the end - shoud I raise a new PR (the original one is kern/145813)?
Thanks for the submission.
--- sys/sys/resource.h.orig 2009-10-25 01:10:29.0 +
+++ sys/sys/resource.h 2010-04-11 23:31:14.0 +
@@ -56,6 +56,7 @@
#define RUSAGE_SELF 0
#defineRUSAGE_CHILDREN -1
+#defineRUSAGE_THREAD 1
struct rusage {
struct timeval ru_utime;/* user time used */
--- sys/kern/kern_resource.c.orig 2009-10-25 01:10:29.0 +
+++ sys/kern/kern_resource.c2010-04-18 23:49:04.0 +
@@ -76,6 +76,7 @@ static void calcru1(struct proc *p, stru
struct timeval *up, struct timeval *sp);
static int donice(struct thread *td, struct proc *chgp, int n);
static struct uidinfo *uilookup(uid_t uid);
+static void ruxagg_tlock(struct proc *p, struct thread *td);
/*
* Resource controls and accounting.
@@ -623,9 +624,7 @@ lim_cb(void *arg)
return;
PROC_SLOCK(p);
FOREACH_THREAD_IN_PROC(p, td) {
- thread_lock(td);
- ruxagg(p-p_rux, td);
- thread_unlock(td);
+ ruxagg_tlock(p, td);
}
PROC_SUNLOCK(p);
if (p-p_rux.rux_runtime p-p_cpulimit * cpu_tickrate()) {
@@ -836,9 +835,7 @@ calcru(struct proc *p, struct timeval *u
FOREACH_THREAD_IN_PROC(p, td) {
if (td-td_incruntime == 0)
continue;
- thread_lock(td);
- ruxagg(p-p_rux, td);
- thread_unlock(td);
+ ruxagg_tlock(p, td);
}
calcru1(p, p-p_rux, up, sp);
}
@@ -918,6 +915,29 @@ calcru1(struct proc *p, struct rusage_ex
sp-tv_usec = su % 100;
}
+static void
+calctru(struct thread *td)
+{
+ u_int64_t tu = cputick2usec(td-td_incruntime);
+ u_int64_t ut = td-td_uticks;
+ u_int64_t it = td-td_iticks;
+ u_int64_t st = td-td_sticks;
+ u_int64_t tt, uu, su;
+
+ tt = ut + st + it;
+ if (!tt) {
+ /* Avoid divide by zero */
+ st = 1;
+ tt = 1;
+ }
+ uu = td-td_ru.ru_utime.tv_usec + (ut * tu) / tt;
+ su = td-td_ru.ru_stime.tv_usec + (st * tu) / tt;
+ td-td_ru.ru_utime.tv_sec += uu / 100;
+ td-td_ru.ru_utime.tv_usec = uu % 100;
+ td-td_ru.ru_stime.tv_sec += su / 100;
+ td-td_ru.ru_stime.tv_usec
Re: [PATCH] RUSAGE_THREAD
On Mon, May 03, 2010 at 08:13:00PM +, Alexander Krizhanovsky wrote:
Kostik,
thank you very much for the review!
Kostik Belousov wrote:
On Mon, Apr 19, 2010 at 12:46:48AM +, Alexander Krizhanovsky wrote:
Hi all!
This patch implements per-thread rusage statistic (like RUSAGE_THREAD in
Linux and RUSAGE_LWP in OpenSolaris).
Unfortunately, we have to acquire a number of locks to read/update
system and user times for current thread rusage information because it's
also used for whole process statistic and needs to be zeroed.
Any comments are very appreciated.
It's tested against 8.0-RELEASE. Appropriate PR is submitted.
--
Alexander Krizhanovsky
NatSys Lab. (http://natsys-lab.com)
tel: +7 (916) 717-3899, +7 (499) 747-6304
e-mail: a...@natsys-lab.com
I think this should be somewhat modified before commit.
First, please separate patch into two pieces. One would introduce
ruxagg_tlock() helper and use it in existing locations instead of
three-liners. Possibly, add KR-ANSI C kern_getrusage definition
change.
Second would actually add RUSAGE_THREAD. There, please follow
the style(9), in particular, do not initialize the local variables
at the declaration, instead, use explicit initialization in the code.
Done. I have also introduced third patch for casting microseconds to
timeval and replaced a few appropriate places in whole kernel code.
patch-rusage-thread-03052010.txt is incremental for
patch-ruxagg_tlock-03052010.txt, which is by turn incremental for
patch-usec2timeval-03052010.txt.
I have made following change for calcru1():
- if ((int64_t)tu 0) {
- /* XXX: this should be an assert /phk */
- printf(calcru: negative runtime of %jd usec for pid %d
(%s)\n,
- (intmax_t)tu, p-p_pid, p-p_comm);
- tu = ruxp-rux_tu;
- }
+ KASSERT((int64_t)tu 0, (calcru: negative runtime of %jd usec
+ for pid %d (%s)\n,
+ (intmax_t)tu, p-p_pid, p-p_comm));
tu can become negative at about 300 thousand years of uptime, so this
condition seems quite unrealistic and indeed should be replaced by an
assertion. However I didn't understand why it isn't done so far and the
comment only was added. Did I miss something?
Should calctru() share the code with calcru1() ? I am esp. concerned
with sanity check like negative runtime etc. Possibly, this code
from calcru1() should be separated into function used from both
calcru1() and calctru().
Man page for getrusage(2) should be updated.
It's added to patch-rusage-thread-03052010.txt.
In the end - shoud I raise a new PR (the original one is kern/145813)?
Thanks for the submission.
It was some time, I already committed ruxagg_tlock() part, that caused
some feedback, and I reworked the rest of the patch myself. See svn-src@
for some discussion, and the latest version that I intend to commit
shortly is below. Your comments are welcome.
Lets discuss third patch after this is landed.
diff --git a/lib/libc/sys/getrusage.2 b/lib/libc/sys/getrusage.2
index bdf5d45..423503f 100644
--- a/lib/libc/sys/getrusage.2
+++ b/lib/libc/sys/getrusage.2
@@ -28,7 +28,7 @@
.\ @(#)getrusage.28.1 (Berkeley) 6/4/93
.\ $FreeBSD$
.\
-.Dd June 4, 1993
+.Dd May 1, 2010
.Dt GETRUSAGE 2
.Os
.Sh NAME
@@ -42,6 +42,7 @@
.In sys/resource.h
.Fd #define RUSAGE_SELF 0
.Fd #define RUSAGE_CHILDREN -1
+.Fd #define RUSAGE_THREAD 1
.Ft int
.Fn getrusage int who struct rusage *rusage
.Sh DESCRIPTION
@@ -49,11 +50,12 @@ The
.Fn getrusage
system call
returns information describing the resources utilized by the current
-process, or all its terminated child processes.
+thread, the current process, or all its terminated child processes.
The
.Fa who
argument is either
-.Dv RUSAGE_SELF
+.Dv RUSAGE_THREAD ,
+.Dv RUSAGE_SELF ,
or
.Dv RUSAGE_CHILDREN .
The buffer to which
@@ -175,6 +177,10 @@ The
.Fn getrusage
system call appeared in
.Bx 4.2 .
+The
+.Dv RUSAGE_THREAD
+facility first appeared in
+.Fx 8.1 .
.Sh BUGS
There is no way to obtain information about a child process
that has not yet terminated.
diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 49a3097..6c50f1f 100644
--- a/sys/kern/kern_proc.c
+++ b/sys/kern/kern_proc.c
@@ -901,7 +901,7 @@ fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp,
int preferthread)
kp-ki_pri.pri_user = td-td_user_pri;
if (preferthread) {
- kp-ki_runtime = cputick2usec(td-td_runtime);
+ kp-ki_runtime = td-td_rux.rux_runtime;
kp-ki_pctcpu = sched_pctcpu(td);
kp-ki_estcpu = td-td_estcpu;
}
diff --git a/sys/kern/kern_resource.c b/sys/kern/kern_resource.c
index a3ed75d..0bc78d0 100644
--- a/sys/kern/kern_resource.c
+++ b/sys/kern/kern_resource.c
@@ -76,7 +76,7 @@ static void calcru1(struct proc *p, struct
Re: making consmsgbuf_size a tunable?
On 05/03/2010 12:21 AM, Ed Schouten wrote: Hello Matthew, * Matthew Jacobm...@feral.com wrote: Any thoughts about this? Looks good. Maybe we should make it a tunable only? Looking at the code, once the consbuf has been allocated, there is no way you can ever resize it. You could, but on closer inspection of the code, this doesn't seem to really kick in until you're multiuser anyway (until somebody executes TIOCONS), so maybe it doesn't really matter. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Generic DMA engine framework
Hi, On 2010-04-30 19:44:45 (+0200), Jakub Klama jc...@semihalf.com wrote: This summer I'll add generic mechanism for using general purpose DMA engines found in embedded system-on-chip devices. This will make possible to schedule transfers from kernel and userspace and will allow to use DMA in other devices using systemwide DMA engine. My earlier experience with kernel development was writing FreeBSD/arm port to TI DaVinci Digital-media system-on-chip - more details here: [1]. Development of this project will be done also on DaVinci - I'll provide implementation of its DMA engine as well as example DMA-enabled device driver - DaVinci's SD/MMC controller (current implementation uses only PIO transfers). You can read more details here: http://wiki.freebsd.org/SOC2010JakubKlama I will appreciate your comments and suggestions about this project. This looks like a very interesting project. I'm quite interested in seeing the idam(4) driver as I'm working on a driver for the hardware crypto engine in the 88F5182 (and later the 88F6xxx I hope) and it'd be much improved by DMA support. Good luck, Kristof ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Generic DMA engine framework
On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski r...@semihalf.com wrote: Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. Yes, I'd be quite interested to see how my attempts compare to your work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I didn't study the Sheevaplug documentation in great detail but I believe the CESA is similar (but not identical) on the two chips. BTW: out of curiousity, what is the platform based on 88F5281 you're using? It's a TS-7800: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 Regards, Kristof ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Generic DMA engine framework
On 2010-05-03, at 21:51, Kristof Provost wrote: Hi, On 2010-04-30 19:44:45 (+0200), Jakub Klama jc...@semihalf.com wrote: This summer I'll add generic mechanism for using general purpose DMA engines found in embedded system-on-chip devices. This will make possible to schedule transfers from kernel and userspace and will allow to use DMA in other devices using systemwide DMA engine. My earlier experience with kernel development was writing FreeBSD/arm port to TI DaVinci Digital-media system-on-chip - more details here: [1]. Development of this project will be done also on DaVinci - I'll provide implementation of its DMA engine as well as example DMA-enabled device driver - DaVinci's SD/MMC controller (current implementation uses only PIO transfers). You can read more details here: http://wiki.freebsd.org/SOC2010JakubKlama I will appreciate your comments and suggestions about this project. This looks like a very interesting project. I'm quite interested in seeing the idam(4) driver as I'm working on a driver for the hardware crypto engine in the 88F5182 (and later the 88F6xxx I hope) and it'd be much improved by DMA support. Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. BTW: out of curiousity, what is the platform based on 88F5281 you're using? Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Generic DMA engine framework
On 2010-05-03, at 22:22, Kristof Provost wrote: On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski r...@semihalf.com wrote: Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. Yes, I'd be quite interested to see how my attempts compare to your work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I didn't study the Sheevaplug documentation in great detail but I believe the CESA is similar (but not identical) on the two chips. I believe the 88F5182 has CESA as well, although as far I can see the main difference is that while the 88F6xxx (and MV-78xxx) CESA has an associated (to some extent can be considered as dedicated) TDMA engine, the one in 88F5182 does not, and can only use the generic purpose engine (IDMA). Our driver assumes TDMA and was only tested with 88F6xxx and 78xxx, so it seems there's some work involved with getting this to work on the 5182. Let me carve the code out for your reference so that you can try to extend it to work wirh Orion. BTW: out of curiousity, what is the platform based on 88F5281 you're using? It's a TS-7800: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 Does the generic DB-88F5XXX kernel config and existing code work with this device, or have you had to modify anything? Rafal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Generic DMA engine framework
On 2010-05-03 22:47:31 (+0200), Rafal Jaworowski r...@semihalf.com wrote: On 2010-05-03, at 22:22, Kristof Provost wrote: On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski r...@semihalf.com wrote: Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. Yes, I'd be quite interested to see how my attempts compare to your work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I didn't study the Sheevaplug documentation in great detail but I believe the CESA is similar (but not identical) on the two chips. I believe the 88F5182 has CESA as well, although as far I can see the main difference is that while the 88F6xxx (and MV-78xxx) CESA has an associated (to some extent can be considered as dedicated) TDMA engine, the one in 88F5182 does not, and can only use the generic purpose engine (IDMA). Our driver assumes TDMA and was only tested with 88F6xxx and 78xxx, so it seems there's some work involved with getting this to work on the 5182. Let me carve the code out for your reference so that you can try to extend it to work wirh Orion. Thanks. BTW: out of curiousity, what is the platform based on 88F5281 you're using? It's a TS-7800: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 Does the generic DB-88F5XXX kernel config and existing code work with this device, or have you had to modify anything? I've disabled PCI but that's about it. Regards, Kristof ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On 2010-May-03 16:33:19 +0300, Andrius Morkūnas hinok...@gmail.com wrote: I wasn't talking about any specific port. What I meant is that new hardware won't stop coming out just because FreeBSD decided not to update their gcc. New CPUs may have new instructions and other things that are different from their predecessors in one way or another. As an example of an increasingly common CPU that gcc 4.2 doen't support, consider the Intel Atom. It supports the 'Core' (ie up to SSSE3) instructions but only does in-order execution (like the Pentium 1). -- Peter Jeremy pgpKNqqUkjeJl.pgp Description: PGP signature
GSoC:Complete Package support in the pkg_install tools and cleanup
Hello, During this summer, I'll work on the pkg_install tools to add complete package support. A complete package is a package which includes all the required dependencies in its tarball. Unlike the PBI package format of PC-BSD, once a complete package is installed, it appears as every package contained in the complete package was installed separately. As a side effect, I'll add libarchive support to the pkg_add tool to make installation as efficient as possible and do some refactoring to allow code re usability. I'll also surely write automated tests which would benefit to the pkg_install tools. My page on the wiki is http://wiki.freebsd.org/SOC2010JulienLaffaye You can email me on or off list is you have any questions, comments or suggestions. Best regards, Julien Laffaye ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
