Re: easy way to determine if a stream or fd is seekable
On Nov 15, 2011 2:25 PM, "Alexander Best" wrote:
>
> hi there,
>
> one of the things i'm missing is an easy way to determine, whether a
stream or
> fd is seekable. i checked the dd(1) and hd(1) sources and those tools are
> performing so much stuff just to find out if this is the case, and they
still
> are doing a very poor job.
>
> dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the
result:
>
> `dd if=/dev/zero bs=1m count=1 skip=10`:
>
> on freebsd:
> 57,41 real 0,05 user43,21 sys
>
> on openbsd:
> 0,88 real 0,00 user 0,07 sys
>
> on freebsd dd(1) is very easy fixable (1 line diff). the point however is:
>
> there doesn't seem to exist a unified way of checking seekable == TRUE. so
> every userspace application seems to do it differently and most of them
(dd(1)
> and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only
regular
> files are seekable. this means that hd(1) fired at /dev/ada* with a high
skip
> value takes ages! dd(1) is a bit smarter in this case, but still not
correct.
>
> idealy there would be something like stat.st_mode (see stat(2)) where one
> could simply do a S_ISSEEK(m). so far the best and easiest solution i've
seen
> is:
>
> fd = open(argv[1], O_RDONLY);
> if (fd == -1)
> exit(1);
> if (lseek(fd, 0, SEEK_CUR) != -1)
>printf ("%d is seekable.\n", fd);
> else
>printf ("%d is not seekable.\n", fd);
>
> seeing an application iterate through a stream or fd via getchar(),
although
> a simple seek() would work is very frustrating. i think what would be
needed
> is a simple function or macro that userspace applications can make use of.
> maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd,
> solaris or plan9?
>
> cheers.
> alex
>
> references:
> [1]
http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes
> [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485
> [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485
So, according to APUE 2nd Edition, seek should be supported on anything
that's not a pipe, FIFO, or socket. In fact, the "test for seekability"
you've provided above closely resembles the example given in that text.
Need to think about this more before commenting further...
-Brandon
___
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: kldload dtraceall exec format error
On Thu, Sep 1, 2011 at 12:27 PM, Charlie Martin wrote: > > > On 2011-09-01 11:23, Garrett Cooper wrote: >> >> On Thu, Sep 1, 2011 at 9:56 AM, Charlie Martin wrote: >>> >>> Okay, I'll grant this is probably a horrid noob question, but then on the >>> Free kernel I'm a horrid noob so I guess it makes sense. This is for >>> FreeBSD >>> >>> FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 >>> >>> per uname -a. >>> >>> We have a FreeBSD based product on the AMD64 architecture; I'm trying to >>> enable DTrace. The file amd64/conf/GENERIC with which the kernel was >>> compiled has the required lines >>> >>> options KDTRACE_FRAME # Ensure frames are compiled in >>> options KDTRACE_HOOKS # Kernel DTrace hooks >>> options DDB_CTF # for DTrace >>> >>> but when I try kldload dtraceall I get >>> >>> kldload: can't load dtraceall: Exec format error >>> >>> From Google I get that this probably means some mismatch in compiles, >>> but >>> I'm unclear what to look for. Also, another big part of the product, >>> compiled from the same master Makefile, *does* have dtrace enabled >>> successfully. >>> >>> Hints, suggestions, and pointers to documentation gleefully accepted. >> >> What does dmesg say? >> Thanks, >> -Garrett >> > link_elf_obj: symbol lapic_cyclic_clock_func undefined > linker_load_file: Unsupported file type > KLD profile.ko: depends on cyclic - not available or version mismatch > linker_load_file: Unsupported file type > KLD dtraceall.ko: depends on profile - not available or version mismatch > linker_load_file: Unsupported file type > link_elf_obj: symbol lapic_cyclic_clock_func undefined > linker_load_file: Unsupported file type > KLD profile.ko: depends on cyclic - not available or version mismatch > linker_load_file: Unsupported file type > KLD dtraceall.ko: depends on profile - not available or version mismatch > linker_load_file: Unsupported file type > > Aha, dmesg. Thanks. > I'm guessing you've read this: http://wiki.freebsd.org/DTrace Make certain you've configure your kernel correctly, and that you've rebuilt your kernel and modules... -Brandon ___ 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: Where to ask about a 7.2 bug, and debugging sys/queue.h errors
2011/8/25 Kostik Belousov : > On Thu, Aug 25, 2011 at 05:12:09PM -0500, Brandon Gooch wrote: >> On Thu, Aug 25, 2011 at 4:53 PM, Kostik Belousov wrote: >> > On Thu, Aug 25, 2011 at 03:16:09PM -0600, Charlie Martin wrote: >> >> We're having a crash in some internal code running on FreeBSD 7.2 >> >> (specifically 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE and yeah, I know >> >> it's quite a bit behind) in which after 18-30 hours of running load >> >> tests, the code panics with: >> >> >> >> panic: Bad link elm 0xff0044c09600 next->prev != elm >> >> cpuid = 0 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper() at 0x8019119a = db_trace_self_wrapper+0x2a >> >> panic() at 0x80307c72 = panic+0x182 >> >> devfs_populate_loop() at 0x802a43a8 = devfs_populate_loop+0x548 >> >> >> >> >> >> First question: where's the most appropriate place to ask about this >> >> kind of bug on a back version. >> > It is fine to ask there. >> > >> >> >> >> Second: does this remind anyone of any bugs? Googling came up with a >> >> few somewhat similar things but hasn't provided much insight so far. >> > In 99% of the cases, it means that you forgot to dev_ref() some cdev. >> >> So dev_ref increments the reference count for a cdev. Even though the >> work "loop" seems to indicate that we will iterate over a list of >> objects (one of which we may be missing a reference to via a missing >> dev_ref()), I'm not seeing how this can cause a panic from inside >> devfs_populate_loop(). >> >> Can you help me understand this? >> > Missing dev_ref() means that the memory for the cdev (and cdev_priv) is > freed prematurely. If this happens before destroy_dev() is called, > then the list which is iterated over by populate_loop(), is corrupted. > > See e.g. MAKEDEV_REF flag for make_dev(9) and its use in the (old) clone > handlers. > Ahhh, thanks Kostik. Reading make_dev(9) (and more source code) now... -Brandon ___ 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: Where to ask about a 7.2 bug, and debugging sys/queue.h errors
On Thu, Aug 25, 2011 at 4:53 PM, Kostik Belousov wrote: > On Thu, Aug 25, 2011 at 03:16:09PM -0600, Charlie Martin wrote: >> We're having a crash in some internal code running on FreeBSD 7.2 >> (specifically 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE and yeah, I know >> it's quite a bit behind) in which after 18-30 hours of running load >> tests, the code panics with: >> >> panic: Bad link elm 0xff0044c09600 next->prev != elm >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at 0x8019119a = db_trace_self_wrapper+0x2a >> panic() at 0x80307c72 = panic+0x182 >> devfs_populate_loop() at 0x802a43a8 = devfs_populate_loop+0x548 >> >> >> First question: where's the most appropriate place to ask about this >> kind of bug on a back version. > It is fine to ask there. > >> >> Second: does this remind anyone of any bugs? Googling came up with a >> few somewhat similar things but hasn't provided much insight so far. > In 99% of the cases, it means that you forgot to dev_ref() some cdev. So dev_ref increments the reference count for a cdev. Even though the work "loop" seems to indicate that we will iterate over a list of objects (one of which we may be missing a reference to via a missing dev_ref()), I'm not seeing how this can cause a panic from inside devfs_populate_loop(). Can you help me understand this? -Brandon ___ 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] draft patch to make usr.bin/kdump WARNS?= 6 clean
On Mon, May 2, 2011 at 11:10 AM, Garrett Cooper wrote: > I wanted to do something different this weekend, and I picked > usr.bin/kdump as a likely 'victim' for converting from WARNS?= 0 to > WARNS?= 6. I'm curious as to whether or not this is on the right > track, but here's the reasoning I used: > > 1. Conditionally include diskmbr.h or diskpc98.h based on whether or > not an architecture was non-pc98 or pc98 to avoid duplicate > definitions, because the beforementioned headers are mutually > exclusive. > 2. Move the sockfamilyname declaration to kdump_subr.h as it's used in > the generated ioctl.c file. > 3. Fix a signed vs unsigned comparison with a simple cast because the > size_t value will be sufficiently small that it can be converted to a > signed comparison. > 4. Fix a cast assignment type source//dest value alignment issue on > ia64 assigning a struct sockaddr value to either struct sockaddr_in or > struct sockaddr_in6 by using calloc and memcpy. > 5. Fix structure alignment issues on arm by marking some structures as > __packed. > 6. Fix a shadowed declaration for flags by renaming a locally scoped > variable to _flags; add appropriate type to field. > 7. Remove unused argument to ktruser_malloc. > 8. Add missing declarations for ktruser_malloc and ktruser_rtld. > > I've run some basic tests and things seem sane (in particular > ktrace'ing ktrace :)... ktrace'ing 'ssh ::1' and ktrace'ing 'ssh > localhost', but I was wondering if there was anything I was missing or > if someone else who ran arm or ia64 could test this patch out for me. > I've run make universe on amd64, i386, ia64, mips, and pc98, and > things seem sane, but I can't play around with those machines to > determine whether or not they're functional at runtime with the above > changes. > Thanks! > -Garrett > > PS Oh yeah... no commit bit means that I can't commit this either, but > I was curious if my approach was correct before getting to that step > :). Cool, but where's the patch for review? -Brandon ___ 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: Puzzled about VFS sysctl OIDs -- signed vs. unsigned
On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming wrote: > On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch > wrote: >> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill >> wrote: >>> I'm using a little shell script to capture selected sysctl OID >>> values periodically, in an attempt to get a better idea how the >>> resources of a system are being used during a long-running (usually >>> measured in hours), mission-critical workload. >>> >>> In the process of testing this, I've seen some of the VFS sysctl >>> OIDs (in particular) report negative values ... when the description >>> looks to me as if the OID in question is intended to be a monotonically >>> increasing counter. >>> >>> For example: >>> >>>> sysctl -d vfs.getnewbufcalls >>> vfs.getnewbufcalls: Number of calls to getnewbuf >>>> sysctl vfs.getnewbufcalls >>> vfs.getnewbufcalls: -348909432 >>> >>> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >>> appears to be: >>> >>> ... >>> static int getnewbufcalls; >>> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0, >>> "Number of calls to getnewbuf"); >>> ... >>> >>> Many of the other OIDs defined nearby are also SYSCTL_INT (or >>> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >>> variables are defined as static int (or static long) vs. static u_int >>> (or static u_long). >>> >>> Is this both correct and reasonable? If so, how should I interpret such >>> negative values? >>> >>> [GSoC project, anyone?] >>> >>> Thanks! >>> >>> Peace, >>> david >> >> The following initiative may factor heavily into any decision to >> change sysctl declarations at this point: >> >> http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Type-Safety > > The intent of the type-safety is to make sure that the types assumed > for the kernel's sysctl handler match the type of the variable. This > project won't fix issues where a signed type is being used and the > value wraps (at least, I presume that's what happened in this case?) > > Thanks, > matthew Yes, it's wrapping. I wonder, would an audit of the SYCTL_* types be of general use to FreeBSD? I haven't ran into these issues myself, but I can see where this could become more of a problem with the OS in general as larger, heavier loads are placed on general-purpose type systems; where FreeBSD has been used in a product, I assume that the companies engineers, such as those at Isilon, have applied local patches where necessary. Y'know, I think this could be a good GSoC project after all... -Brandon ___ 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: Puzzled about VFS sysctl OIDs -- signed vs. unsigned
On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill wrote: > I'm using a little shell script to capture selected sysctl OID > values periodically, in an attempt to get a better idea how the > resources of a system are being used during a long-running (usually > measured in hours), mission-critical workload. > > In the process of testing this, I've seen some of the VFS sysctl > OIDs (in particular) report negative values ... when the description > looks to me as if the OID in question is intended to be a monotonically > increasing counter. > > For example: > >> sysctl -d vfs.getnewbufcalls > vfs.getnewbufcalls: Number of calls to getnewbuf >> sysctl vfs.getnewbufcalls > vfs.getnewbufcalls: -348909432 > > Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls > appears to be: > > ... > static int getnewbufcalls; > SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0, > "Number of calls to getnewbuf"); > ... > > Many of the other OIDs defined nearby are also SYSCTL_INT (or > SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding > variables are defined as static int (or static long) vs. static u_int > (or static u_long). > > Is this both correct and reasonable? If so, how should I interpret such > negative values? > > [GSoC project, anyone?] > > Thanks! > > Peace, > david The following initiative may factor heavily into any decision to change sysctl declarations at this point: http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Type-Safety I don't pretend to fully understand the reasons or impact of this project, but I have to imagine that at least the scope is similar to a proposed GSoC project (probably bigger). -Brandon ___ 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: DTrace: Sending ^C while running script produces no output
On Sat, Dec 4, 2010 at 3:27 PM, Brandon Gooch
wrote:
> On Sat, Dec 4, 2010 at 2:32 PM, Andriy Gapon wrote:
>> on 03/12/2010 07:20 Brandon Gooch said the following:
>>> I've been tinkering with DTrace a bit, and I've notice something
>>> peculiar on each system I've tried it on.
>>>
>>> Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
>>> produces no output [1].
>>
>> Can you ktrace the dtrace process?
>> I wonder, could it be that SIGINT from ^C is somehow delivered twice?..
>
> I'll give it a shot in just a bit.
I think you are correct, see below.
>
>>> For example, while trying out a one-liner (from
>>> http://www.brendangregg.com/DTrace/dtrace_oneliners.txt):
>>>
>>> bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count();
>>> }'
>>> dtrace: description 'syscall:::entry ' matched 514 probes
>>> ^C
>>
>> BTW, sudo might play a role here... Just a thought.
>
> I could see that for sure. I can't believe I hadn't thought of that
> right off the bat, but then again I tested while logged in as root
> from the console -- I think :/
>
> Human memory is unreliable y'know...
You were absolutely on to it -- sudo appears to be the culprit here. I
ktrace'd both an attempt using sudo and not using sudo (as root).
Snippet of ktrace output when running the aforementioned dtrace
command as root, which works as expected:
8804 initial thread PSIG SIGINT caught handler=0x80065d0d0 mask=0x0 code=0x0
8804 initial thread CALL sigprocmask(SIG_SETMASK,0x7fffe06c,0)
8804 initial thread RET sigprocmask 0
8804 initial thread CALL sigreturn(0x7fffdc90)
8804 initial thread RET sigreturn JUSTRETURN
8804 initial thread CALL fstat(0x1,0x7fffe000)
8804 initial thread STRU struct stat {dev=67174144, ino=120, mode=crw--w
, nlink=1, uid=1001, gid=4, rdev=120, atime=1291504111, stime=1291504111, ctime=
1291504111, birthtime=-1, size=0, blksize=4096, blocks=0, flags=0x0 }
8804 initial thread RET fstat 0
8804 initial thread CALL ioctl(0x1,TIOCGETA,0x7fffe050)
8804 initial thread RET ioctl 0
8804 initial thread CALL write(0x1,0x8029b6000,0x1)
8804 initial thread GIO fd 1 wrote 1 byte
"
Snippet of ktrace output when running the aforementioned dtrace
command with sudo, which produces no output:
4527 initial thread PSIG SIGINT caught handler=0x80065d0d0 mask=0x0 code=0x0
4527 initial thread CALL sigprocmask(SIG_SETMASK,0x7fffe22c,0)
4527 initial thread RET sigprocmask 0
4527 initial thread CALL sigreturn(0x7fffde50)
4527 initial thread RET sigreturn JUSTRETURN
4527 initial thread PSIG SIGINT caught handler=0x80065d0d0 mask=0x0 code=0x0
4527 initial thread CALL sigprocmask(SIG_SETMASK,0x7fffe22c,0)
4527 initial thread RET sigprocmask 0
4527 initial thread CALL sigreturn(0x7fffde50)
4527 initial thread RET sigreturn JUSTRETURN
4527 initial thread PSIG SIGINT caught handler=0x80065d0d0 mask=0x0 code=0x0
4527 initial thread CALL sigprocmask(SIG_SETMASK,0x7fffe22c,0)
4527 initial thread RET sigprocmask 0
4527 initial thread CALL sigreturn(0x7fffde50)
4527 initial thread RET sigreturn JUSTRETURN
4527 initial thread CALL fstat(0x1,0x7fffe1c0)
4527 initial thread STRU struct stat {dev=67174144, ino=128, mode=crw--w
, nlink=1, uid=1001, gid=4, rdev=128, atime=1291523109, stime=1291523110, ctime=
1291523110, birthtime=-1, size=0, blksize=4096, blocks=0, flags=0x0 }
4527 initial thread RET fstat 0
4527 initial thread CALL ioctl(0x1,TIOCGETA,0x7fffe210)
4527 initial thread RET ioctl 0
4527 initial thread CALL write(0x1,0x8029b6000,0x1)
4527 initial thread GIO fd 1 wrote 1 byte
Well, I'm glad to finally get to the bottom of this, and I want to
apologize for the noise, but I think this is still a "gotcha" for new
DTrace users, and I hope it can be noted somewhere (perhaps the DTrace
sections on the FreeBSD wiki).
-Brandon
___
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: DTrace: Sending ^C while running script produces no output
On Sat, Dec 4, 2010 at 2:32 PM, Andriy Gapon wrote:
> on 03/12/2010 07:20 Brandon Gooch said the following:
>> I've been tinkering with DTrace a bit, and I've notice something
>> peculiar on each system I've tried it on.
>>
>> Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
>> produces no output [1].
>
> Can you ktrace the dtrace process?
> I wonder, could it be that SIGINT from ^C is somehow delivered twice?..
I'll give it a shot in just a bit.
>> For example, while trying out a one-liner (from
>> http://www.brendangregg.com/DTrace/dtrace_oneliners.txt):
>>
>> bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count();
>> }'
>> dtrace: description 'syscall:::entry ' matched 514 probes
>> ^C
>
> BTW, sudo might play a role here... Just a thought.
I could see that for sure. I can't believe I hadn't thought of that
right off the bat, but then again I tested while logged in as root
from the console -- I think :/
Human memory is unreliable y'know...
-Brandon
___
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: DTrace: Sending ^C while running script produces no output
On Thu, Dec 2, 2010 at 11:48 PM, Artem Belevich wrote:
> On Thu, Dec 2, 2010 at 9:46 PM, Artem Belevich wrote:
>> On Thu, Dec 2, 2010 at 9:20 PM, Brandon Gooch
>> wrote:
>>> I've been tinkering with DTrace a bit, and I've notice something
>>> peculiar on each system I've tried it on.
>>>
>>> Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
>>> produces no output [1].
>>>
>>> For example, while trying out a one-liner (from
>>> http://www.brendangregg.com/DTrace/dtrace_oneliners.txt):
>>
>> I've got two boxes, both running stable-8/amd64.
>>
>> stable/8 r215749 (+cyclic patch) - reliably produces output, though
>> for some reason does not count anything for 32-bit apps.
>> stable/8 r215546 - seems to have the problem you've described. I did
>> get normal output once out of 10 or so attempts.
>
> Tried on another box, also amd64:
>
> stable/8 r212650 - works fine.
I've rebuilt kernel and world on every DTrace enabled system. I built
from a clean svn checkout. I still see this behavior, although it's
definitely the worst on HEAD:
bran...@x300:/usr/src$ svn info (12-03 22:00)
Path: .
URL: svn://svn.freebsd.org/base/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 216114
Node Kind: directory
Schedule: normal
Last Changed Author: lstewart
Last Changed Rev: 216114
Last Changed Date: 2010-12-02 00:05:44 -0600 (Thu, 02 Dec 2010)
The following NEVER works on this system running HEAD:
bran...@x300:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count(); }'
dtrace: description 'syscall:::entry ' matched 514 probes
^C
bran...@x300:~$ (12-03 21:59)
Of course, sending ANY signal to dtrace via pkill or killall promptly
causes dtrace to spit out:
bran...@x300:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count(); }'
dtrace: description 'syscall:::entry ' matched 514 probes
dbus-daemon 6
syslogd 7
ntpd 8
sendmail 9
hald-addon-storage 10
cut 39
hald 40
mixer44
killall 51
powerd 55
zsh 69
openbox 90
dtrace 109
xterm 172
conky 180
sh 231
sudo457
wpa_supplicant 648
Xorg 1557
firefox-bin1992
bran...@x300:~$ (12-03 22:02)
Very troubling.
Question: Should I be rebuilding my ports (xterm, zsh, ksh, etc...)
after updating to make sure that the proper things are happening when
sending these keyboard interrupts? I'm really grasping here :/
-Brandon
___
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"
DTrace: Sending ^C while running script produces no output
I've been tinkering with DTrace a bit, and I've notice something
peculiar on each system I've tried it on.
Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
produces no output [1].
For example, while trying out a one-liner (from
http://www.brendangregg.com/DTrace/dtrace_oneliners.txt):
bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count(); }'
dtrace: description 'syscall:::entry ' matched 514 probes
^C
bran...@d820:~$ (12-02 23:11)
If I instead, from another terminal, use pkill to quit or terminate
the process, I get output:
bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count(); }';
dtrace: description 'syscall:::entry ' matched 514 probes
akonadi_control 4
akonadiserver 5
syslogd 6
sendmail 8
akonadi_ical_resour 12
akonadi_maildir_res 12
akonadi_nepomuk_con 12
akonadi_vcard_resou 12
kuiserver12
akonadi_maildispatc 14
korgac 14
virtuoso-t 15
dbus-daemon 17
mysqld 18
hald 24
knotify4 27
akonadi_contacts_re 36
nepomukservicestub 70
pkill70
powerd 72
dtrace 101
zsh 111
sudo495
kwin 2812
firefox-bin3175
kdeinit4 11044
Xorg 39588
bran...@d820:~$ (12-02 23:14)
I also want to add that I've tried this with a variety of shells on
both 8.2-PRERELEASE and HEAD systems, i386 and amd64, built with GCC
and nearly GENERIC kernels in order to try to eliminate the cause.
I feel as though this has something to do with file descriptors being
closed too soon when handling the signal or something of that nature.
It's also been suggested that this could be a bug in libdtrace, but I
haven't the knowledge (or skill) to try and pinpoint the cause myself.
Is there anyone here that may be able to provide feedback or debugging
suggestions?
Thanks!
-Brandon
[1] This isn't always the case, only like 99.99% of the time.
Sometimes I do get output, but usually it's just snippets, and
sometimes random characters!
___
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: [CFT+RFC] patch to buildworld with heimdal from ports
On Tue, Nov 16, 2010 at 2:49 AM, Joerg Pulz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Content-ID: > > On Mon, 15 Nov 2010, Brandon Gooch wrote: > >> On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper >> wrote: >>> >>> On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch >>> wrote: >>>> >>>> On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >>>>> >>>>> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> after the security/heimdal port was updated to the current heimdal >>>>>> release and i added one missing function from base it is now possible >>>>>> to >>>>>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>>>>> enabled parts. >>>>> >>>>> Hi Joerg, >>>>> >>>>> I don't think that having the base system depend on a port is the right >>>>> solution to resolving the libgssapi compatibility problems in base. >>>>> >>>>> Did you ever come across the old PR kern/147454 that I submitted in >>>>> June? In it I included a src patch that replaced the base system's >>>>> libgssapi with upstream Heimdal's, which resolved all libgssapi >>>>> compatibility problems. That patch is now stale, but either way I >>>>> haven't been able to draw enough attention to the issue to have it >>>>> fixed. >>>> >>>> I guess we're waiting on someone to review the patch and commit it? >>>> Hopefully someone can get this in soon, before 8.2 is released. >>>> >>>> Is there something wrong with your patch? >>> >>> Not according to another person that commented on the patch (and it >>> sounds like the experience is positive, not negative). Who's the >>> maintainer of the component? >> >> Garrett, where would one look for such an important detail? Source >> file somewhere? >> >> Joerg, how about taking over what's in base? Seems to me like you know >> what's going on, and you're maintaining the port :) >> >> BTW, I'm only beginning to dive into Kerberos on FreeBSD, so I'm not >> bringing to this discussion much wisdom :/ But I would like all of the >> pieces to work! > > Hi Brandon, > > i already started to work on updating base heimdal to a recent version which > is not the easiest task but i made some progreess. > Be patient. > > Kind regards Thanks Joerg! Patience is indeed a virtue, though I suppose I'm not too virtuous! ;) I'm sure you're work is going to make a lot of people happy! -Brandon ___ 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: [CFT+RFC] patch to buildworld with heimdal from ports
On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper wrote: > On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch > wrote: >> On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >>> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>>> Hi, >>>> >>>> after the security/heimdal port was updated to the current heimdal >>>> release and i added one missing function from base it is now possible to >>>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>>> enabled parts. >>> >>> Hi Joerg, >>> >>> I don't think that having the base system depend on a port is the right >>> solution to resolving the libgssapi compatibility problems in base. >>> >>> Did you ever come across the old PR kern/147454 that I submitted in >>> June? In it I included a src patch that replaced the base system's >>> libgssapi with upstream Heimdal's, which resolved all libgssapi >>> compatibility problems. That patch is now stale, but either way I >>> haven't been able to draw enough attention to the issue to have it fixed. >> >> I guess we're waiting on someone to review the patch and commit it? >> Hopefully someone can get this in soon, before 8.2 is released. >> >> Is there something wrong with your patch? > > Not according to another person that commented on the patch (and it > sounds like the experience is positive, not negative). Who's the > maintainer of the component? Garrett, where would one look for such an important detail? Source file somewhere? Joerg, how about taking over what's in base? Seems to me like you know what's going on, and you're maintaining the port :) BTW, I'm only beginning to dive into Kerberos on FreeBSD, so I'm not bringing to this discussion much wisdom :/ But I would like all of the pieces to work! -Brandon ___ 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: [CFT+RFC] patch to buildworld with heimdal from ports
On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: > On 11/15/2010 02:08 PM, Joerg Pulz wrote: >> Hi, >> >> after the security/heimdal port was updated to the current heimdal >> release and i added one missing function from base it is now possible to >> completely buildworld src/ using the port for all Kerberos5/GSSAPI >> enabled parts. > > Hi Joerg, > > I don't think that having the base system depend on a port is the right > solution to resolving the libgssapi compatibility problems in base. > > Did you ever come across the old PR kern/147454 that I submitted in > June? In it I included a src patch that replaced the base system's > libgssapi with upstream Heimdal's, which resolved all libgssapi > compatibility problems. That patch is now stale, but either way I > haven't been able to draw enough attention to the issue to have it fixed. I guess we're waiting on someone to review the patch and commit it? Hopefully someone can get this in soon, before 8.2 is released. Is there something wrong with your patch? -Brandon ___ 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: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote: > Hello fellow freebsd-hackers, > > Long-time hacker, first-time poster. > > I'd like to share a shell script that I wrote for FreeBSD system > administration. > > The attached shell script works similar to sysctl(8), but rather than > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > (and /etc/rc.conf.local) files. > > Syntax shown below (available by running the script without arguments): > > Usage: sysconf [OPTIONS] name[=value] ... > OPTIONS: > -h --help Print this message to stderr and exit. > -d Print list of internal dependencies before exit. > -e Print query results as `var=value' (useful for producing > output to be fed back in). Ignored if -n is specified. > -n Show only variable values, not their names. > > ENVIRONMENT: > SYSCONF_SHOW_DEPS Dump list of dependencies. Must be zero or one > (default: `0') > RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. > > Examples: > > r...@mymachine ~ $ sysconf hostname > hostname: mymachine.localdomain > r...@mymachine ~ $ sysconf hostname=foomaster.deluxe.com > hostname: mymachine.localdomain -> foomaster.deluex.com > r...@mymachine ~ $ sysconf -e hostname > hostname="foomaster.deluxe.com" > r...@mymachine ~ $ sysconf -n hostname > foomaster.deluxe.com > > The script has zero external dependencies. None. Period. It will use > grep(1) if installed, but it is not required. > > Tested extensively on FreeBSD-4.8, FreeBSD-4.11, FreeBSD-8.0, and > FreeBSD-8.1. It seems the list ate the attachment :( Also, take a look at sysconf(3). I think there may be a certain amount of hesitation to welcome a utility with the same name as a POSIX-compliant C library function... ...how about a name like 'sysrc' or 'rcconfig' or something indicating a relationship with the rc.conf file or rc system? Anyway, sounds cool, as I've had a need recently to do some automated configuring of several rc.conf files -- my method was very hackish, and will never see the light of public scrutiny :) -Brandon ___ 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: One-shot-oriented event timers management
On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin wrote: > Brandon Gooch wrote: >> This latest patch causes an interrupt storm with the HPET timer on my >> system. The machine took about 8 minutes to boot and bring me to a >> login prompt. System interactivity (i.e. input from keyboard, output >> on console) was fine, but after checking the output of `systat vmstat >> -1`, I saw the interrupt rate on each HPET entry was over 120k! >> >> Can I provide any useful detail? Of course, test patches are always welcome >> :) > > I was able to reproduce alike storm in some situations. > > Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch Definitely solved it!!! Awesome, BTW, check out my C3 time: # gnu-watch -n1 'sysctl dev.cpu | grep cx_usage' Every 1.0s: sysctl dev.cpu | grep cx_usage Wed Sep 1 17:56:31 2010 dev.cpu.0.cx_usage: 0.00% 0.03% 99.96% last 7159us dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 6343us I've now seen my computer at it's lowest battery drain rate yet (around 11000 mW) while "using" my system. This just keeps getting better and better mav@, hope we see more testers soon :) -Brandon ___ 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: One-shot-oriented event timers management
On Wed, Sep 1, 2010 at 5:44 AM, Alexander Motin wrote: > Alexander Motin wrote: >> Gary Jennejohn wrote: >>> On Mon, 30 Aug 2010 12:11:48 +0200 >>> OK, this is purely anecdotal, but I'll report it anyway. >>> >>> I was running pretty much all day with the patched kernel and things >>> seemed to be working quite well. >>> >>> Then, after about 7 hours, everything just stopped. >>> >>> I had gkrellm running and noticed that it updated only when I moved the >>> mouse. >>> >>> This behavior leads me to suspect that the timer interrupts had stopped >>> working and the mouse interrupts were causing processes to get scheduled. >>> >>> Unfortunately, I wasn't able to get a dump and had to hit reset to >>> recover. >>> >>> As I wrote above, this is only anecdotal, but I've never seen anything >>> like this before applying the patches. >> >> One-shot timers have one weak side: if for some reason timer interrupt >> getting lost -- there will be nobody to reload the timer. Such cases >> probably will require special attention. Same funny situation with >> mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX >> CPU goes to C3 state. > > I have reproduced the problem locally. It happens more often when ticks > are not stopped on idle, like in your original case (or if explicitly > enabled by kern.eventtimer.idletick sysctl). > > I've made some changes to HPET driver, which, I hope, should fix > interrupt losses there. > > Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch > > Patch also includes some optimizations to reduce lock contention. > > Thanks for testing. This latest patch causes an interrupt storm with the HPET timer on my system. The machine took about 8 minutes to boot and bring me to a login prompt. System interactivity (i.e. input from keyboard, output on console) was fine, but after checking the output of `systat vmstat -1`, I saw the interrupt rate on each HPET entry was over 120k! Can I provide any useful detail? Of course, test patches are always welcome :) -Brandon ___ 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: One-shot-oriented event timers management
On Tue, Aug 31, 2010 at 3:48 AM, Alexander Motin wrote: > Gary Jennejohn wrote: >> On Mon, 30 Aug 2010 12:11:48 +0200 >> Gary Jennejohn wrote: >> >>> On Mon, 30 Aug 2010 13:07:38 +0300 >>> Alexander Motin wrote: >>> Gary Jennejohn wrote: > Hmm. I applied your patches and am now running the new kernel. But I > only installed the new kernel and didn't do make buildworld installworld. > > Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 > interrupts per second and most of those are coming from the hpet timers: > > 1122 hpet0:t0 > 1124 hpet0:t1 It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock (stathz) events. HPET timer here works in one-shot mode handling it. > So, what else did you do to reduce interrupts so much? > > Ah, I think I see it now. My desktop has only C1 enabled. Is that it? > Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. >>> Too bad. I'd say that systems which are limited to C1 don't benefit >>> much (or not at all) from your changes. >>> >> >> OK, this is purely anecdotal, but I'll report it anyway. >> >> I was running pretty much all day with the patched kernel and things >> seemed to be working quite well. >> >> Then, after about 7 hours, everything just stopped. >> >> I had gkrellm running and noticed that it updated only when I moved the >> mouse. >> >> This behavior leads me to suspect that the timer interrupts had stopped >> working and the mouse interrupts were causing processes to get scheduled. >> >> Unfortunately, I wasn't able to get a dump and had to hit reset to >> recover. >> >> As I wrote above, this is only anecdotal, but I've never seen anything >> like this before applying the patches. > > One-shot timers have one weak side: if for some reason timer interrupt > getting lost -- there will be nobody to reload the timer. Such cases > probably will require special attention. Same funny situation with > mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX > CPU goes to C3 state. I too had the "freeze" or "pause" when testing with LAPIC, although I've been using HPET for a while now, and things seem normal: # systat -vmstat 1 3 usersLoad 0.28 0.33 0.24 Aug 31 08:48 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 364524 14244 160098817404 1427028 count All 492712 31000 1075523k54724 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow 363 total 74 2153 613 7083 361 1446 5 zfodatkbd0 1 ozfod 115 hpet0:t0 0 1.6%Sys 0.4%Intr 2.3%User 0.0%Nice 95.7%Idle%ozfod56 hpet0:t1 8 ||||||||||| daefr acpi0 9 =>prcfr 187 psm0 12 36 dtbuf totfr ata0 14 Namei Name-cache Dir-cache05 desvn react uhci2+ 16 Callshits %hits % 1953 numvn pdwak ehci1 19 3 3 100 327 frevn pdpgs uhci0 20 intrn ehci0 22 Disks ada0 cd0 pass0 pass1 202356 wirevgapci0 KB/t 0.00 0.00 0.00 0.00 200264 act hdac0 258 tps 0 0 0 0 167392 inact 5 iwn0 259 MB/s 0.00 0.00 0.00 0.004208 cache %busy 0 0 0 0 1422820 free # cat /boot/loader.conf: ... kern.hz="100" hint.apic.0.clock="0" hint.atrtc.0.clock="0" hint.p4tcc.0.disabled="1" hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1 hint.acpi_throttle.0.disabled="1" hw.pci.do_power_nodriver="3" ... # cat /etc/rc.conf: ... powerd_enable="YES" powerd_flags="-a adaptive -b adaptive -n adaptive" performance_cpu_freq="NONE" # Online CPU frequency economy_cpu_freq="NONE" # Offline CPU frequency performance_cx_lowest="C3" # Online CPU idle state economy_cx_lowest="C3" # Offline CPU idle state ... # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C3 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 0.53% 99.46% last 2791us dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 1.13% 98.86% last 1492us Suspend/resume still works well, for what it's worth :
Re: One-shot-oriented event timers management
2010/8/29 Alexander Motin : > Hi. > > I would like to present my new work on timers management code. > > In my previous work I was mostly orienting on reimplementing existing > functionality in better way. The result seemed not bad, but after > looking on perspectives of using event timers in one-shot (aperiodic) > mode I've understood that implemented code complexity made it hardly > possible. So I had to significantly cut it down and rewrite from the new > approach, which is instead primarily oriented on using timers in > one-shot mode. As soon as some systems have only periodic timers I have > left that functionality, though it was slightly limited. > > New management code implements two modes of operation: one-shot and > periodic. Specific mode to be used depends on hardware capabilities and > can be controlled. > > In one-shot mode hardware timers programmed to generate single interrupt > precisely at the time of next wanted event. It is done by comparing > current binuptime with next scheduled times of system events > (hard-/stat-/profclock). This approach has several benefits: event timer > precision is now irrelevant for system timekeeping, hard- and statclocks > are not aliased, while only one timer used for it, and the most > important -- it allows us to define which events and when exactly we > really want to handle, without strict dependence on fixed hz, stathz, > profhz periods. Sure, our callout system is highly depends on hz value, > but now at least we can skip interrupts when we have no callouts to > handle at the time. Later we can go further. > > Periodic mode now also uses alike principals of scheduling events. But > timer running in periodic mode just unable to handle arbitrary events > and as soon as event timers may not be synchronized to system > timecounter and may drift from it, causing jitter effects. So I've used > for time source of scheduling the timer events themselves. As result, > periodic timer runs on fixed frequency multiply to hz rate, while > statclock and profclock generated by dividing it respectively. (If > somebody would tell me that hardclock jitter is not really a big > problem, I would happily rip that artificial timekeeping out of there to > simplify code.) Unluckily this approach makes impossible to use two > events timers to completely separate hard- and statclocks any more, but > as I have said, this mode is required only for limited set of systems > without one-shot capable timers. Looking on my recent experience with > different platforms, it is not a big fraction. > > Management code is still handles both per-CPU and global timers. Per-CPU > timers usage is obvious. Global timer is programmed to handle all CPUs > needs. In periodic mode global timer generates periodic interrupts to > some one CPU, while management code then redistributes them to CPUs that > really need it, using IPI. In one-shot mode timer is always programmed > to handle first scheduled event throughout the system. When that > interrupt arrives, it is also getting redistributed to wanting CPUs with > IPI. > > To demonstrate features that could be obtained from so high flexibility > I have incorporated the idea and some parts of dynamic ticks patches of > Tsuyoshi Ozawa. Now, when some CPU goes down into C2/C3 ACPI sleep > state, that CPU stops scheduling of hard-/stat-/profclock events until > the next registered callout event. If CPU wakes up before that time by > some unrelated interrupt, missed ticks are called artificially (it is > needed now to keep realistic system stats). After system is up to date, > interrupt is handled. Now it is implemented only for ACPI systems with > C2/C3 states support, because ACPI resumes CPU with interrupts disabled, > that allows to keep up missed time before interrupt handler or some > other process (in case of unexpected task switch) may need it. As I can > see, Linux does alike things in the beginning of every interrupt handler. > > I have actively tested this code for a few days on my amd64 Core2Duo > laptop and i386 Core-i5 desktop system. With C2/C3 states enabled > systems experience only about 100-150 interrupts per second, having HZ > set to 1000. These events mostly caused by several event-greedy > processes in our tree. I have traced and hacked several most aggressive > ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . > It allowed me to reduce down to as low as 50 interrupts per system, > including IPIs! Here is the output of `systat -vm 1` from my test > system: http://people.freebsd.org/~mav/systat_w_oneshot.txt . Obviously > that with additional tuning the results can be improved even more. > > My latest patch against 9-CURRENT can be found here: > http://people.freebsd.org/~mav/timers_oneshot4.patch > > Comments, ideas, propositions -- welcome! > > Thanks to all who read this. ;) Totally awesome work m...@! One thing I see: Where is *frame pointing to? It isn't initialized in the function, so... +static int +han
Re: Hello!
On Wed, Apr 28, 2010 at 4:04 PM, Stanislav wrote: > Hello! I am accepted for the google summer of code. I just wanted to > introduce myself to the community. I will be working on "BSNMP enhancement: > A new module". I will be very thankful to anyone who have ideas to share. I > am still newbie and have never coded for project such FreeBSD, but i hope > that with some help i will cope with the project. I will post a link to the > wiki page soon. > Best regards, to all the people who help somehow to the FreeBSD idea. Stanislav, congratulations on your acceptance in the GoC 2010! I, along with many others, am excited to see enhancements in the current state of SNMP on FreeBSD. Your work will undoubtedly be welcomed by many system administrators, and I look forward to sharing ideas and providing support and encouragement wherever possible. Good Luck, and Happy Coding! -Brandon ___ 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: netstat count option
On Wed, Apr 21, 2010 at 4:01 AM, Dmitry Banschikov wrote: > Hello, > > I wrote small patch to the netstat utility. > The patch allows to specify how many times, the display output should be > continue, > in case of option -w. > Usage: > # ./netstat -w2 -c2 > input (Total) output > packets errs bytes packets errs bytes colls > 15 0 2268 13 0 1190 0 > 4 0 240 5 0 278 0 > # > > Option -c [count] is simillar to the same option in iostat utility. > In linux -c means continious output: > -c, --continuous > This will cause netstat to print the selected information every second > continuously. This seems pretty useful, perhaps you should file a PR? http://www.freebsd.org/send-pr.html -Brandon ___ 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: vdso and shared page patch
On Tue, Apr 20, 2010 at 2:57 PM, Giuseppe Cocomazzi wrote: > Hi, > I've written a huge patch which implements vdso support and shared page > subsystem for freebsd. Unfortunately, I've been waiting for a review > for quite a long time and, after some positive responses, silence overcame, > so the code became a bit old, also due to my difficulty in keeping the > source up-to-date. > I understand that now it is very unlikely for the patch to be seriously > considered, however I provide the links to the code and a little explanatory > paper, in case someone is interested: > > patch: http://sbudella.altervista.org/stuff/shared_page_vdso.patch > paper: http://sbudella.altervista.org/stuff/shared_page_vdso.note > tgz: http://sbudella.altervista.org/stuff/shared_page_vdso.tgz > > Feedback would be very appreciated. > Thanks for your attention, > > Giuseppe Cocomazzi > -- This is really cool! Although I must admit -- I don't have the technical skill to read through the patch and comment on the code ;) Wasn't this a Google SoC project at some point? -Brandon ___ 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"
