can we disable AAAA queries in the resolver ?
hi, recently i have been bitten by a problem which might be already known, but still... quite a few apps (sendmail and ssh among them) seem to always try an query if compiled with ipv6 support, and even if the kernel does not support ipv6, tcpdump shows queries going out to the nameserver, and often timing out or otherwise causing my apps significand delays at startup. My understanding is that there are multiple buggy components here: my ISP's nameserver certainly shouldn't behave so badly on requests, and the applications should not bother asking queries when the kernel has no ipv6 support. On the other hand, the resolver code is probably just innocent because if some application issues an request, the resolver has no reason to object. Still, rather than fixing the many broken applications, or the nameserver (on which i have no control) i wonder if it is possible to instruct the resolver, perhaps through some option in resolv.conf, to immediately return some kind of negative replies on selected queries ? cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
Luigi Rizzo wrote: hi, recently i have been bitten by a problem which might be already known, but still... quite a few apps (sendmail and ssh among them) seem to always try an query if compiled with ipv6 support, and even if the kernel does not support ipv6, tcpdump shows queries going out to the nameserver, and often timing out or otherwise causing my apps significand delays at startup. My understanding is that there are multiple buggy components here: my ISP's nameserver certainly shouldn't behave so badly on requests, and the applications should not bother asking queries when the kernel has no ipv6 support. On the other hand, the resolver code is probably just innocent because if some application issues an request, the resolver has no reason to object. Still, rather than fixing the many broken applications, or the nameserver (on which i have no control) i wonder if it is possible to instruct the resolver, perhaps through some option in resolv.conf, to immediately return some kind of negative replies on selected queries ? The code does not seem to have this as an option, but it is rather a compile-time stuff. Refer to the /usr/src/lib/libc/net/getaddrinfo.c. Indeed, it would be useful to have it configurable either in resolv.conf (options) or as an environment variable (RES_OPTIONS). -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
John-Mark Gurney wrote: Ruben de Groot wrote this message on Fri, Aug 01, 2003 at 10:15 +0200: On Fri, Aug 01, 2003 at 04:33:08AM +0200, mh typed: The following comparison is probably bogus, but can anybody explain the huge difference? It's called micro optimization. Linux feels the need to special case /dev/zero to /dev/null, and instead of even reading/writing the data, It just ignores the user request, (or does something like set the pages in the user space to be zero'd. Also, dual procs won't help your performance when you run a single process like this. They will if you interleave the page zero'ing they do on both CPU's... 8^p. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] Re: getfsent(3) and spaces in fstab
Simon Barner wrote: The attached patch will allow blanks and tabs for file systems and path names, as long as the are protected by a '\'. For the old fstab style, blanks and tabs are not allowed as delimiters (as it was in the old implementation). You need to add '\\' to the delimited list, so that it is not skipped. You need to add '\\' to the list of characters that can be escaped, or you've just traded the inability to specify '\t' or ' ' for an inability to speciy '\\'. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
On Fri, Aug 01, 2003 at 11:52:00PM -0700, Luigi Rizzo wrote: My understanding is that there are multiple buggy components here: my ISP's nameserver certainly shouldn't behave so badly on requests, and the applications should not bother asking queries when the kernel has no ipv6 support. Usually the problem is the authorititive name server at the far end. Some don't reply to queries and others return NXDOMAIN when they shouldn't. I did some measurements on hosts listed in our cache's log and of about 24000 hosts about 200 had problems like this. A significant number of these are ad servers, so after complaining to Doubleclick and getting no response, I've told my local name server that it is authorititive for doubleclick.net and given it an empty zone. Since doing this I don't notice the problem any more. (Strictly speaking, you shouldn't cripple the resolver to not look up IPv6 addresses if none are configured 'cos you might want to look up the IPv6 address for some other reason than making a connection. There is a AI_ADDRCONFIG flag for getaddrinfo that tells it to only look up addresses if you have an address in that family configured. For some reason it isn't mentioned in our man page. I'm not sure what the status of our implementation is either...) David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
On Sat, Aug 02, 2003 at 09:59:18AM +0100, David Malone wrote: On Fri, Aug 01, 2003 at 11:52:00PM -0700, Luigi Rizzo wrote: My understanding is that there are multiple buggy components here: my ISP's nameserver certainly shouldn't behave so badly on requests, and the applications should not bother asking queries when the kernel has no ipv6 support. ... (Strictly speaking, you shouldn't cripple the resolver to not look up IPv6 addresses if none are configured 'cos you might want to look up the IPv6 address for some other reason than making a connection. There is a AI_ADDRCONFIG flag for getaddrinfo that i know, but what is happening is that all these applications (including sendmail and our ssh, for what matters) are broken in that they look for an record just for making a connection. And then it is easier to have a sensible default (that can be overridden by those apps who really need it) than one which is correct but depends on too many things [over which one has no control] to behave correctly. tells it to only look up addresses if you have an address in that family configured. For some reason it isn't mentioned in our man page. I'm not sure what the status of our implementation is either...) browsing through the source code there is a bunch of 'options' in resolv.conf that are not mentioned in the manpage.: timeout: T attempts: N debug no-tld-query inet6 rotate no-check-names edns0 a6 dname nibble: suffix nibble2: suffix bitstring: suffix v6revmode: single|both cheers luigi David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
network crash dumps
I'm messing with a utility for performing network crash dumps: http://www.cs.duke.edu/~anderson/freebsd/netdump/ and have currently applied his instructions (with some mods) to FreeBSD 4.7-RELEASE. I have two questions: - To test the functionability, I need to invoke a panic. I've attempted to call 'panic' with a DDB-enabled kernel, but his client code doesn't seem to get triggered. Recent feedback from the author: I seem to remember calling panic from ddb actually does something strange. Try call boot(1) or call boot instead. Does anyone have a grasp on an alternate way of panicing a 4.7-R kernel? - If I can get this to fly, does anyone know in advance if his client code will apply to FBSD 5.x? It wouldn't take me long to find out hte hard way, but I figured I'd ask. Thanks for any advice... -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
i know, but what is happening is that all these applications
(including sendmail and our ssh, for what matters)
are broken in that they look for an record just for making
a connection.
Can you try this patch for sendmail?
--- domain.c.orig Sat Aug 2 09:27:09 2003
+++ domain.cSat Aug 2 09:29:47 2003
@@ -851,12 +851,6 @@
** false -- otherwise.
*/
-# if NETINET6
-# define SM_T_INITIAL T_
-# else /* NETINET6 */
-# define SM_T_INITIAL T_A
-# endif /* NETINET6 */
-
bool
dns_getcanonname(host, hbsize, trymx, statp, pttl)
char *host;
@@ -880,6 +874,7 @@
bool amatch;
bool gotmx = false;
int qtype;
+ int initial;
int loopcnt;
char *xp;
char nbuf[SM_MAX(MAXPACKET, MAXDNAME*2+2)];
@@ -971,11 +966,16 @@
*/
mxmatch = NULL;
- qtype = SM_T_INITIAL;
+ initial = T_A;
+# if NETINET6
+ if (InetMode == AF_INET6)
+ initial = T_;
+# endif /* NETINET6 */
+ qtype = initial;
for (dp = searchlist; *dp != NULL; )
{
- if (qtype == SM_T_INITIAL)
+ if (qtype == initial)
gotmx = false;
if (tTd(8, 5))
sm_dprintf(dns_getcanonname: trying %s.%s (%s)\n,
@@ -1057,7 +1057,7 @@
/* definite no -- try the next domain */
dp++;
- qtype = SM_T_INITIAL;
+ qtype = initial;
continue;
}
else if (tTd(8, 7))
@@ -1234,7 +1234,7 @@
qtype = T_MX;
else
{
- qtype = SM_T_INITIAL;
+ qtype = initial;
dp++;
}
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
messing with CVS_LOCAL_BRANCH_NUM
I'm exploring the 'local repository' tactics as described in: http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html which makes use of the CVS_LOCAL_BRANCH_NUM evironment variable. This is all under 4.7-RELEASE. My general method is: setenv CVS_LOCAL_BRANCH_NUM 1000 setenv MYBRANCH just_testing setenv RELEASE RELENG_4_7 setenv CVSROOT /annex/cvs/FreeBSD cvs rtag -b -r $RELEASE $MYBRANCH src cd /usr cvs checkout -r $MYBRANCH src/UPDATING cvs status src/UPDATING # check to see that this really is my branch vi src/UPDATING When I try to commit, though: cvs ci src cvs commit: Examining src You are committing on the wrong repository! cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Where is this 'wrong repository' concept coming from? My CVSROOT hasn't changed. A google search for that disgnostic message yeilds no hits... Any advice? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
On 2003.08.02 15:35:48 -0400, Brian Reichert wrote:
I'm exploring the 'local repository' tactics as described in:
http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html
[snip]
cvs ci src
cvs commit: Examining src
You are committing on the wrong repository!
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
Where is this 'wrong repository' concept coming from? My CVSROOT
hasn't changed. A google search for that disgnostic message yeilds
no hits...
The problem is the file CVSROOT/nocommits.sh, which is used as a
safeguard in the FreeBSD tree. I replace the file every time I run
cvsup with the following version:
nocommits.sh
#! /bin/sh
# $FreeBSD$
#
# This is just some basic anti-foot-shooting to avoid accidental commits
# to cvsup'ed copies of the repository etc.
OKUSER=simonln
if [ x`/usr/bin/id -un` = x${OKUSER} ]; then
exit 0
fi
echo I should only commit as ${OKUSER}!
exit 1
/nocommits.sh
You could just make a simple script which call 'exit 0' (or perhaps
remove the file; I haven't tried that), but the above version fits
better into my rather odd setup :-).
I have started some work on documenting the CVS_LOCAL_BRANCH_NUM use,
but unfortunatly there are only 24 hours in a day, so I have no idea
when I will get around to finishing it.
--
Simon L. Nielsen
FreeBSD Documentation Team
pgp0.pgp
Description: PGP signature
Assembly interrupts and Developers handbook
First I would like to know where I can buy a copy of the FreeBSD Developer's Handbook. Nice to have a handbook that I can hold in my hand. Secondly, What can I find a list of other interrupts within FreeBSD like the int 80h. Or is this the only interrupt. Like example interrupt for video stuff, disk access etc. .etc thanks in advance, just another happy FreeBSD user 4.8-Release :) Suppressed minds have no Freedom of Choice - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
On Sat, Aug 02, 2003 at 09:49:00PM +0200, Simon L. Nielsen wrote: On 2003.08.02 15:35:48 -0400, Brian Reichert wrote: I'm exploring the 'local repository' tactics as described in: http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html [snip] cvs ci src cvs commit: Examining src You are committing on the wrong repository! cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Where is this 'wrong repository' concept coming from? My CVSROOT hasn't changed. A google search for that disgnostic message yeilds no hits... The problem is the file CVSROOT/nocommits.sh, which is used as a safeguard in the FreeBSD tree. I replace the file every time I run cvsup with the following version: Cool! Thanks for the pointer. Off I go... I have started some work on documenting the CVS_LOCAL_BRANCH_NUM use, but unfortunatly there are only 24 hours in a day, so I have no idea when I will get around to finishing it. Heh. :) Good luck... -- Simon L. Nielsen FreeBSD Documentation Team -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
On Sat, Aug 02, 2003 at 04:04:41PM -0400, Brian Reichert wrote: On Sat, Aug 02, 2003 at 09:49:00PM +0200, Simon L. Nielsen wrote: The problem is the file CVSROOT/nocommits.sh, which is used as a safeguard in the FreeBSD tree. I replace the file every time I run cvsup with the following version: Cool! Thanks for the pointer. Off I go... So - removing the file chokes (it's expressly looked for), but 'exit 0' is sufficent for my little sandbox. Thanks for the help, off to play more... -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network crash dumps
* Brian Reichert [EMAIL PROTECTED] [2003-08-02 11:56 -0400]: I seem to remember calling panic from ddb actually does something strange. Try call boot(1) or call boot instead. Does anyone have a grasp on an alternate way of panicing a 4.7-R kernel? kill -6 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
On Fri, 2003-08-01 at 02:59, Terry Lambert wrote: Personally, I like to look at the Linux register-based passing mechanism in the same light that they look at the FreeBSD use of the MMU hardware to assist VM, at the cost of increased FreeBSD VM system complexity (i.e. they think our VM is too convoluted, and we think their system calls are too convoluted). Maybe, but they also support a lot of MMU-less architectures, so it may have made things simpler for them to not depend on MMU. I wonder if NUMA had any bearing on that as well... -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
Maybe, but they also support a lot of MMU-less architectures, so it may have made things simpler for them to not depend on MMU. I wonder if NUMA had any bearing on that as well... No. The initial design of their VM greatly preceded NUMA and uCLinux. It actually makes the system less portable in that it can require interspersing of machine dependent code in the machine independent parts when the machines page table layout differs from the default. The introduction to the UVM thesis has some good points in this regard. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
On Sat, 2003-08-02 at 16:23, Kip Macy wrote: table layout differs from the default. The introduction to the UVM thesis has some good points in this regard. UVM thesis? (I am subscribed to list.) -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
UVM was the VM system that replaced the old Mach style VM in NetBSD and (I believe) OpenBSD. FreeBSD has already cleaned up a lot of the problems that UVM addresses. However, there are still some things that could be done to make map passing easier, which I believe would make zero-copy support cleaner if not faster. This is the UVM home page: http://ccrc.wustl.edu/pub/chuck/tech/uvm/ -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network crash dumps
On Sat, Aug 02, 2003 at 10:11:32PM +0200, Nicolas Rachinsky wrote: * Brian Reichert [EMAIL PROTECTED] [2003-08-02 11:56 -0400]: I seem to remember calling panic from ddb actually does something strange. Try call boot(1) or call boot instead. Does anyone have a grasp on an alternate way of panicing a 4.7-R kernel? kill -6 1 Hmm, this does bring down my machine, but I didn't see a panic message on the console. Init dying does cause a reboot, but I specifically need a panic.. Thanks, though... -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network crash dumps
* Brian Reichert [EMAIL PROTECTED] [2003-08-02 17:34 -0400]: On Sat, Aug 02, 2003 at 10:11:32PM +0200, Nicolas Rachinsky wrote: * Brian Reichert [EMAIL PROTECTED] [2003-08-02 11:56 -0400]: I seem to remember calling panic from ddb actually does something strange. Try call boot(1) or call boot instead. Does anyone have a grasp on an alternate way of panicing a 4.7-R kernel? kill -6 1 Hmm, this does bring down my machine, but I didn't see a panic message on the console. Init dying does cause a reboot, but I specifically need a panic.. Did you really send a SIGABRT to init? This should cause init to exit after a while (IIRC 30sec), which should cause a Going nowhere without my init panic. Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
It's a toss up. Linux's use of registers for syscall args is not a panacea, because many system calls require more then just the basic call-used registers which means the linux userland code has to save and restore those registers on the stack anyway. And we won't even mention syscalls that require more arguments then you have registers for. Oops! I think the ultimate performance solution is to have some explicitly shared memory between kerneland and userland and store the arguments, error code, and return value there. Being a fairly small package of memory multi-threading would not be an issue as each thread would have its own slot. Of course, FreeBSD has other problems as well.. if you look at our syscall entry and exit code it is simply *horrendous* It goes through an indirect jump and it has to check carry for error returns to set the error code. It is a real mess. What I am doing in DragonFly is reimplementing system calls as messages. It turns out that the overhead is not signifcantly greater (and I haven't even tried optimizing the code yet). With the system call as a message the return code and error are stored in the message itself which means that there are *NO* no special cases and, at least for IA32, the kernel messaging interface has just three fixed arguments which fit easily in the call-used registers. I've been able to get rid of proc-p_retval[], a considerable amount of unnecessary proc/thread pointer passing, and the mechanism is flexible enough to support both synchronous and asynchronous operation as well as both single and multi-threaded operation using the same exact code. Additionally, the mechanism can be extended to support chained system calls (i.e. issue several system calls at once), and transactional sequences. Of course, I haven't actually done all of this yet... I have the messaging infrastructure in place and I am working on asynchronizing I/O and timing system calls (e.g. sleep(), read(), write(), select(), etc..), which is going to take a lot of work, but once that is done the sky is the limit. -Matt :On Fri, 2003-08-01 at 02:59, Terry Lambert wrote: : Personally, I like to look at the Linux register-based passing : mechanism in the same light that they look at the FreeBSD use : of the MMU hardware to assist VM, at the cost of increased : FreeBSD VM system complexity (i.e. they think our VM is too : convoluted, and we think their system calls are too convoluted). : :Maybe, but they also support a lot of MMU-less architectures, so it may :have made things simpler for them to not depend on MMU. I wonder if NUMA :had any bearing on that as well... : :-- :Shawn [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
In article [EMAIL PROTECTED], Brian Reichert [EMAIL PROTECTED] wrote: I'm exploring the 'local repository' tactics as described in: http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html which makes use of the CVS_LOCAL_BRANCH_NUM evironment variable. [...] Any advice? Yes: look for a different approach, or at least backup your local repository frequently. There are known bugs in CVSup which can cause it to throw away your local branch under certain circumstances. I won't have time to fix those issues any time soon. So my advice is, don't use the CVS_LOCAL_BRANCH_NUM feature. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : Additionally, the mechanism can : be extended to support chained system calls (i.e. issue several system : calls at once), and transactional sequences. VMS has done this for a long time. :-) All of their system calls were asynchronous. The synchronous versions are done in userland by calling async version plus wait. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
Matthew Dillon wrote: I think the ultimate performance solution is to have some explicitly shared memory between kerneland and userland and store the arguments, error code, and return value there. Being a fairly small package of memory multi-threading would not be an issue as each thread would have its own slot. You need 8K for this, minimally: 4K that's RO user/RW kernel and 4K that's RW user/RW kernel. You can use it for things like zero system call getpid/getuid/etc.. It's also worth a page doubly mapped, with the second mapping with the PG_G bit set on it (to make it RO visible to user space at the sampe place in all programs) to hold the timecounter information; the current timecounter implementation, with a scad of structures, is both wasteful and unnecessary, given that pointer assigns are atomic, so you can implement with only two, which only take a small part of the page. Doing this, you can use a pointer reference and a structure assign, and a compare-pointer-afterwards to make a zero system call gettimeofday() and other calls (consider the benefits to Apache, SQID, and other programs that have hard logging with timestamp requirements). I've also been toying with the idea of putting environp ** in a COW page, and dealing with changes as a fixup operation in the fault handler (really, environp needs to die, to make way for logical name tables; it persists because POSIX and SuS demand that it persist). So, Matt... how does the modified message based system call interface fare in a before-and-after with lmbench? 8-) 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
On Sat, Aug 02, 2003 at 09:59:18AM +0100 I heard the voice of
David Malone, and lo! it spake thus:
A significant number of these are ad servers, so after complaining
to Doubleclick and getting no response, I've told my local name
server that it is authorititive for doubleclick.net and given it
an empty zone. Since doing this I don't notice the problem any more.
I short-circuited to hosts and ipfw.
# ipfw show 2
2 14 864 reject ip from any to 127.0.0.2
# telnet ad.doubleclick.net 80
Trying 127.0.0.2...
telnet: connect to address 127.0.0.2: Permission denied
telnet: Unable to connect to remote host
('course, DNS is better with multiple machines. You could just burn a
single RFC1918 address for rejecting all the ad-type things)
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
