Re: __restrict__ vs __restrict ?
On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: No, we should be using the __restrict as coded. But I wonder why we can't just use restrict... Because that would really mess up any user program that used 'restrict' as a variable or function name. I think the current approach is the best. Such code isn't portable to C99, which is still a goal of ours. I like RU's suggestion, because it is straight C[99] code and not an abstraction. I'll do a 'make world' test and see if we'd have trouble with RU's form. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __restrict__ vs __restrict ?
On Sat, Jan 17, 2004 at 09:19:28AM -0800, David O'Brien wrote:
On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote:
No, we should be using the __restrict as coded. But I wonder why
we can't just use restrict...
Because that would really mess up any user program that used
'restrict' as a variable or function name. I think the
current approach is the best.
Such code isn't portable to C99, which is still a goal of ours. I like
RU's suggestion, because it is straight C[99] code and not an
abstraction. I'll do a 'make world' test and see if we'd have trouble
with RU's form.
The code I've posted has obvious troubles. It would take care
of the following fragment for -std=c89 and be pure C99 for
-std=c99,
void
foo(char * restrict fa)
{
}
but will break this for -std=c89:
void
restrict(void)
{
}
We have a problem if we want to mix old C89 and new C99 code.
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: [CHECKER] bugs in FreeBSD
In message: [EMAIL PROTECTED] Paul Twohey [EMAIL PROTECTED] writes: : Hi, : : I'm with the Stanford Metacompilation research group. We have a suite of : checkers that find bugs at compile time and we've had quite a bit of : success checking the Linux kernel code for errors. Since our checkers can : emit false alarms we filter the reports before we give them to the kernel : developers. While some false alarms slip past us to the developers, our : limited knowledge of the kernel allows us to recognize most of them. : : We are currently trying to extend our checker to automatically find : functions which allocate resources and to make sure those resources are : properly disposed of. : : Enclosed is a list of potential bugs in FreeBSD where a value is returned : from a function (like malloc) that should be owned by the caller and the : caller does not properly dispose of the value with the appropriate : disposal routine (like free). : : Confirmation of these reports would be appreciated. Wow! That's cool! You've found a number of problems. It will take us a little while to chew through them (although on their face they do seem to be issues). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_input - chksum - why is it done so early in ip_input?
Sten Daniel Sørsdal wrote: Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. Only the IP header checksum is checked. We don't want to forward a packet with a broken header because we can't be sure if it wasn't the destination address that is broken. Be aware that we do not calculate any checksum of the entire IP packet. (This is up to the higher level protocol). It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? On modern networks card (mostly GigE) you have hardware support for that. So there is no expense anymore. I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Can you qualify this more? The checksumming touches only 20 bytes (or a couple more if ip options are present). Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. We are working on it to make it even faster. If you are using 5.2 or -current you get the first step of it by enabling net.inet.ip.fastfowarding. This is a newly written fast path for packet forwarding. (Do not do this on 4.9 because that is the old ip_flow code). -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, 17 Jan 2004, Andre Oppermann wrote: Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. We are working on it to make it even faster. If you are using 5.2 or -current you get the first step of it by enabling net.inet.ip.fastfowarding. This is a newly written fast path for packet forwarding. (Do not do this on 4.9 because that is the old ip_flow code). You can also enable debug.mpsafenet, which disables holding the Giant lock over the forwarding path for supported ethernet drivers. Unfortunately, this option can't be used with KAME IPSEC or IPv6 yet, but can be used with FAST_IPSEC. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM + Vinum
Hi -hackers, following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is how such a setup looks like: http://mailbox.univie.ac.at/~le/geomvinum.ps (this is the actual output from sysctl -b kern.geom.confdot | dot -Tps). And here's the code: http://mailbox.univie.ac.at/~le/geomvinum.tar.gz. You still need vinum(8) to configure the setup; when you're done, unload vinum again and load geom_vinum. Then you can access your volumes in /dev/gvinum/. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
