taskqueue_drain_all
I would like to propose to extend taskqueue API with taskqueue_drain_all.
A potential use case: I have a private taskqueue, several kinds of tasks get
executed via it and then I want to make sure that all of them are completed.
Obviously, I have a way to ensure that no new ones get enqueued.
Is this a good addition?
Or should like consider looping over all of my tasks externally to taskqueue
implementation?
A quick prototype:
--- a/sys/kern/subr_taskqueue.c
+++ b/sys/kern/subr_taskqueue.c
@@ -316,6 +316,7 @@ taskqueue_run_locked(struct taskqueue *queue)
wakeup(task);
}
TAILQ_REMOVE(queue-tq_active, tb, tb_link);
+ wakeup(queue-tq_active);
}
void
@@ -402,6 +403,22 @@ taskqueue_drain(struct taskqueue *queue, struct task *task)
}
void
+taskqueue_drain_all(struct taskqueue *queue)
+{
+ struct task *task;
+
+ TQ_LOCK(queue);
+ while ((task = STAILQ_FIRST(queue-tq_queue)) != NULL) {
+ while (task-ta_pending != 0 || task_is_running(queue, task))
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT, -, 0);
+ }
+ while (TAILQ_FIRST(queue-tq_active) != NULL)
+ TQ_SLEEP(queue, queue-tq_active,
+ queue-tq_mutex, PWAIT, -, 0);
+ TQ_UNLOCK(queue);
+}
+
+void
taskqueue_drain_timeout(struct taskqueue *queue,
struct timeout_task *timeout_task)
{
--
Andriy Gapon
___
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: amdtemp need help with testing
On 2013-10-07 3:24, rozhuk...@gmail.com wrote: I updated amdtemp and now I need your help with testing. Now the driver should support all AMD processors. For a family of 15h and 16h, not all sensors are available - for my system does not find drivers for ati SMBus, and other systems based on the AMD I have not. CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative This is what I get with the 10.0-ALPHA4 driver. sysctl -a | grep amd machine amd64 hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 58.0C This is what I get when I try to compile the new module: freetest# cd /usr/src/sys/modules/amdtemp/ freetest# make Warning: Object directory not changed from original /usr/src/sys/modules/amdtemp cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c:453:9: error: implicit declaration of function 'pci_cfgregread' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if ((pci_cfgregread(pci_get_bus(dev), pci_get_slot(dev), 2, ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/modules/amdtemp FreeBSD freetest.digiware.nl 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1 r256062: Tue Oct 8 11:05:54 CEST 2013 r...@freetest.digiware.nl:/usr/obj/usr/src/sys/FREETEST amd64 --WjW ___ 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
mmap() question
Hello!
I have a program which mmap()s a lot of large files (total size more that RAM
and I have no swap), but it needs only small parts of that files at a time.
My understanding is that when using mmap when I access some memory region OS
reads the relevant portion of that file from disk and caches the result in
memory. If there is no free memory, OS will purge previously read part of
mmap'ed file to free memory for the new chunk.
But this is not the case. I use the following simple program which gets list
of files as command line arguments, mmap()s them all and then selects random
file and random 1K parts of that file and computes a XOR of bytes from that
region.
After some time the program dies:
pid 63251 (a.out), uid 1232, was killed: out of swap space
It seems I incorrectly understand how mmap() works, can you please clarify
what's going wrong?
I expect that program to run indefinitely, purging some regions out of RAM and
reading the relevant parts of files.
Thanks!
#include err.h
#include fcntl.h
#include math.h
#include stdio.h
#include stdlib.h
#include sys/mman.h
#include sys/stat.h
#include sys/types.h
#include unistd.h
struct f_data {
char *beg;
off_t size;
};
int
main(int argc, char* argv[]) {
if (argc 2) {
fprintf(stderr, Usage: %s file ...\n, argv[0]);
exit(0);
}
int i, j, fd;
struct stat st;
struct f_data FILES[500];
int NUM_FILES;
void *p;
NUM_FILES = argc - 1;
for (i=1; i argc; i++) {
printf(%s... , argv[i]);
if ((fd = open(argv[i], O_RDONLY)) 0)
errx(1, open);
if (fstat(fd, st) != 0)
errx(1, fstat);
if ((p = mmap(NULL, st.st_size, PROT_READ, MAP_NOCORE, fd, 0)) ==
MAP_FAILED)
errx(1, mmap);
FILES[i-1].beg = (char*)p;
FILES[i-1].size = st.st_size;
if (msync(p, st.st_size, MS_INVALIDATE) != 0)
errx(1, msync);
printf(Ok.\n);
}
char chk = 0;
while(1) {
int rf = floor((double)random() / 2147483647 * NUM_FILES);
off_t offs = floor((double)random() / 2147483647 * (FILES[rf].size -
1024));
for (j=0; j1024; j++)
chk ^= *(FILES[rf].beg + offs + j);
}
return 0;
}
___
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: amdtemp need help with testing
On 2013-10-09 13:34, Willem Jan Withagen wrote: On 2013-10-07 3:24, rozhuk...@gmail.com wrote: I updated amdtemp and now I need your help with testing. Now the driver should support all AMD processors. For a family of 15h and 16h, not all sensors are available - for my system does not find drivers for ati SMBus, and other systems based on the AMD I have not. CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative This is what I get with the 10.0-ALPHA4 driver. sysctl -a | grep amd machine amd64 hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 58.0C After bruteforce fixing the compile error by deleting the #ifdef around the definition... --WjW freetest# sysctl -a | grep amd machine amd64 Giant,amdtemp hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.rtc.CurTmp: 36.6C dev.amdtemp.0.rtc.CurTmpTjSel: -12.5C dev.amdtemp.0.rtc.TmpSlewDnEn: 1 dev.amdtemp.0.rtc.TmpMaxDiffUp: 3 dev.amdtemp.0.rtc.PerStepTimeDn: 15 dev.amdtemp.0.rtc.PerStepTimeUp: 15 dev.amdtemp.0.rtc.sensor_offset: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor0.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor0.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor0.status: 0 dev.amdtemp.0.tsi.sensor0.cfg3: 0 dev.amdtemp.0.tsi.sensor0.cfg9: 0 dev.amdtemp.0.tsi.sensor0.upd_rate: 8 dev.amdtemp.0.tsi.sensor0.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor0.alert_threshold: 0 dev.amdtemp.0.tsi.sensor0.alert_cfg: 0 dev.amdtemp.0.tsi.sensor0.manufacture_id: 0 dev.amdtemp.0.tsi.sensor0.revision: 1 dev.amdtemp.0.tsi.sensor0.sensor_offset: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor1.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor1.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor1.status: 0 dev.amdtemp.0.tsi.sensor1.cfg3: 0 dev.amdtemp.0.tsi.sensor1.cfg9: 0 dev.amdtemp.0.tsi.sensor1.upd_rate: 8 dev.amdtemp.0.tsi.sensor1.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor1.alert_threshold: 0 dev.amdtemp.0.tsi.sensor1.alert_cfg: 0 dev.amdtemp.0.tsi.sensor1.manufacture_id: 0 dev.amdtemp.0.tsi.sensor1.revision: 1 dev.amdtemp.0.tsi.sensor1.sensor_offset: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor2.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor2.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor2.status: 0 dev.amdtemp.0.tsi.sensor2.cfg3: 0 dev.amdtemp.0.tsi.sensor2.cfg9: 0 dev.amdtemp.0.tsi.sensor2.upd_rate: 8 dev.amdtemp.0.tsi.sensor2.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor2.alert_threshold: 0 dev.amdtemp.0.tsi.sensor2.alert_cfg: 0 dev.amdtemp.0.tsi.sensor2.manufacture_id: 0 dev.amdtemp.0.tsi.sensor2.revision: 1 dev.amdtemp.0.tsi.sensor2.sensor_offset: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor3.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor3.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor3.status: 0 dev.amdtemp.0.tsi.sensor3.cfg3: 0 dev.amdtemp.0.tsi.sensor3.cfg9: 0 dev.amdtemp.0.tsi.sensor3.upd_rate: 8 dev.amdtemp.0.tsi.sensor3.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor3.alert_threshold: 0 dev.amdtemp.0.tsi.sensor3.alert_cfg: 0 dev.amdtemp.0.tsi.sensor3.manufacture_id: 0 dev.amdtemp.0.tsi.sensor3.revision: 1
Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
On Tue, 8 Oct 2013 16:01:25 -0700 Davide Italiano wrote: This could be probably changed -- from what | see even under high memory pressure this wasn't a problem but all in all I agree with you that we shouldn't loop forever but limit the number of pass on the list to a somewhat constant number, to prevent pathological cases. I don't see any need to loop. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked. Well, no. Here you can set the threshold to a more aggressive value so that you reclaim more memory every time. Note that this was not possible in the previous version, so, if you could have a situation where all your cache entries were not touched for 15 or even 30 seconds they would have kept around, and you can destroy up to 10% of them everytime lowmem event is called. Outside of contrived stress tests I think it's very rare for a significant fraction of the cache to have been accessed in the last minute - particularly on large caches where this matters most. ___ 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: mmap() question
On Wed, 9 Oct 2013 15:42:27 +0400 Dmitry Sivachenko wrote: Hello! I have a program which mmap()s a lot of large files (total size more that RAM and I have no swap), but it needs only small parts of that files at a time. My understanding is that when using mmap when I access some memory region OS reads the relevant portion of that file from disk and caches the result in memory. If there is no free memory, OS will purge previously read part of mmap'ed file to free memory for the new chunk. ... It seems I incorrectly understand how mmap() works, can you please clarify what's going wrong? I expect that program to run indefinitely, purging some regions out of RAM and reading the relevant parts of files. I think your problem is that you are accessing the memory so rapidly that the pages can't even get out of the active queue. The VM system isn't optimized for this kind of abnormal access. ___ 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: openjdk7 dtrace support
Hello, I would like to know it there is dtrace support in the openjdk7? Thanks, Patrick Dung On Tuesday, October 8, 2013 1:26 PM, Patrick Dung patrick_...@yahoo.com.hk wrote: Hi all, I would like to know it there is dtrace support in the openjdk7? Thanks, Patrick ___ freebsd-j...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-java To unsubscribe, send any mail to freebsd-java-unsubscr...@freebsd.org ___ 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: taskqueue_drain_all
+1
Very useful :)
-a
On 9 October 2013 01:55, Andriy Gapon a...@freebsd.org wrote:
I would like to propose to extend taskqueue API with taskqueue_drain_all.
A potential use case: I have a private taskqueue, several kinds of tasks
get
executed via it and then I want to make sure that all of them are
completed.
Obviously, I have a way to ensure that no new ones get enqueued.
Is this a good addition?
Or should like consider looping over all of my tasks externally to
taskqueue
implementation?
A quick prototype:
--- a/sys/kern/subr_taskqueue.c
+++ b/sys/kern/subr_taskqueue.c
@@ -316,6 +316,7 @@ taskqueue_run_locked(struct taskqueue *queue)
wakeup(task);
}
TAILQ_REMOVE(queue-tq_active, tb, tb_link);
+ wakeup(queue-tq_active);
}
void
@@ -402,6 +403,22 @@ taskqueue_drain(struct taskqueue *queue, struct task
*task)
}
void
+taskqueue_drain_all(struct taskqueue *queue)
+{
+ struct task *task;
+
+ TQ_LOCK(queue);
+ while ((task = STAILQ_FIRST(queue-tq_queue)) != NULL) {
+ while (task-ta_pending != 0 || task_is_running(queue,
task))
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT,
-, 0);
+ }
+ while (TAILQ_FIRST(queue-tq_active) != NULL)
+ TQ_SLEEP(queue, queue-tq_active,
+ queue-tq_mutex, PWAIT, -, 0);
+ TQ_UNLOCK(queue);
+}
+
+void
taskqueue_drain_timeout(struct taskqueue *queue,
struct timeout_task *timeout_task)
{
--
Andriy Gapon
___
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
___
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(1) depends on RCS - should it?
I guess I'm late to the party (catching up on the whole thread took a while...) On Mon, 7 Oct 2013, Eitan Adler wrote: patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are we okay with a base system utility that behaves differently depending on whether a port is installed? Should the relevant code be removed from patch(1)? See head/usr.bin/patch/inp.c lines 166 to 240 for details. It seems like maybe this question should have been answered before rcs was removed, instead of after? (I don't know whether I would have expected you to be able to find every use of rcs, everywhere, prior to removing it, but this is what public declaration of intent/discussions help with.) -Ben ___ 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(1) depends on RCS - should it?
On Wed, Oct 9, 2013 at 3:26 PM, Benjamin Kaduk ka...@mit.edu wrote: I guess I'm late to the party (catching up on the whole thread took a while...) On Mon, 7 Oct 2013, Eitan Adler wrote: patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are we okay with a base system utility that behaves differently depending on whether a port is installed? Should the relevant code be removed from patch(1)? See head/usr.bin/patch/inp.c lines 166 to 240 for details. It seems like maybe this question should have been answered before rcs was removed, instead of after? (I don't know whether I would have expected you to be able to find every use of rcs, everywhere, prior to removing it, but this is what public declaration of intent/discussions help with.) I was asked by members of core@ to expedite the removal to 10.X - it was not done just because I felt like it. In any case its been reverted now so the discussion is moot. -- Eitan Adler ___ 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(1) depends on RCS - should it?
On Mon, Oct 07, 2013 at 04:17:03PM -0400, Eitan Adler wrote: patch(1) explicitly tries to use RCS (and SCCS) in certain cases. At the SCCS behavior is part of (the SCCS option in ) POSIX 2008. So far I haven't seen any reason for messing with it. Joerg ___ 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
git session at BAFUG tomorrow (San Francisco Bay Area FreeBSD User Group).
I've been doing a few one-on-one sessions at iXsystems explaining the git model to developers and have had much success. Tomorrow at BAFUG (http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/144351492/) I will be doing a quick talk on git and then doing a breakaway session on managing large projects using git. This week Alfred Perlstein will have a GIT talk for FreeBSD users, and offer a 1-2 hour demo in a break awayfor people interested in doing a hands-on GIT experience managing a large project. We will cover migration of your FreeBSD customizations based on one version of FreeBSD to another FreeBSD version. Specifically, Alfred will be doing a hands-on using rebasing, to do this migration. To participate, all that needs to be done is to have run git clone https://github.com/freebsd/freebsd; beforehand (as this takes about 30 minutes). In addition, a computer with wi-fi or some internet connection to github.com http://github.com/ is needed. As a prerequisite, it is expected that you have some understanding of patch(1) and diff(1). There will be no recording allowed and the format will allow only for short discussion and no derailing. Discussion of other SCM tools is only appropriate in the context of understanding what we are doing in git. Advocacy of other SCM tools will not be tolerated. If you can not abide by these rules you will be asked to leave the session. The workshop will mostly focus on git rebase of a large project, however we may cover a few other areas depending on how much progress we make in the 1-2 hours we set aside. Again, if you want to participate, show up on time and make sure you have a git clone of freebsd already made! -Alfred -- Alfred Perlstein ___ 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: openjdk7 dtrace support
On Wed, Oct 09, 2013 at 09:55:51PM +0800, Patrick Dung wrote: Hello, I would like to know it there is dtrace support in the openjdk7? Not yet on FreeBSD, unless there's something I'm missing. Some work needs to be done on the port in order to get it working. hotspot/make/bsd/makefiles/dtrace.make only does anything if it detects that it's running on Darwin; that'd probably be a good place to start for anyone interested in working on this. -Mark ___ 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
