Re: Phenom II 975 BE shows 0 celsius
on 02/08/2011 00:08 Jung-uk Kim said the following: On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote: on 01/08/2011 22:48 Jung-uk Kim said the following: amdtemp(4) attaches under PCI bus but its sibling on function 2 isn't easy to address, i.e., hostbN. pci_find_bsf() should help with that. I thought about that but it seemed like an overkill because this driver is strictly MD anyway. :-) It's just that pci_cfgregread() has very low level feel to it, nothing else... -- 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: invalid argument in select() when peer socket is in FD_SET
On 2011-Jul-31 16:20:08 +0200, Christoph P.U. Kukulies k...@kukulies.org
wrote:
if (array_of_fds[i]) {
nfds = max(nfds, array_of_fds[i]) + 1;
I suspect you mean: nfds = max(nfds, array_of_fds[i] + 1);
FD_SET(array_of_fds[i], readfds);
}
--
Peter Jeremy
pgpdiN44x0CiJ.pgp
Description: PGP signature
Re: eliminating a syscall on accept()+ioctl() combo
On Mon, Aug 01, 2011 at 08:11:04AM +0200, Vlad Galu wrote: On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: I want to reduce the number of syscalls for my networking application. The app handles incoming connections with the 'accept()' system call. Is there a way to specify to accept() that the newly created file descriptors should be non-blocking (FIONBIO)? This will avoid an ioctl() after the accept(). Thanks! You can make your listening socket non-blocking. Newly created file descriptors will inherit that property. However, that will require you to select()/poll()/kqueue() for that descriptor as well, instead of simply blocking in accept(). This is documented FreeBSD behaviour and common across BSDs, but is not portable. POSIX leaves it unspecified what the non-blocking state of the new socket is and in fact Linux always makes the new socket blocking (unless you request non-blocking using their new accept4() call). Because this portability issue can be very subtle, I suggest not blindly relying on it. -- Jilles Tjoelker ___ 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: eliminating a syscall on accept()+ioctl() combo
On Aug 2, 2011, at 11:16 PM, Jilles Tjoelker wrote: On Mon, Aug 01, 2011 at 08:11:04AM +0200, Vlad Galu wrote: On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: I want to reduce the number of syscalls for my networking application. The app handles incoming connections with the 'accept()' system call. Is there a way to specify to accept() that the newly created file descriptors should be non-blocking (FIONBIO)? This will avoid an ioctl() after the accept(). Thanks! You can make your listening socket non-blocking. Newly created file descriptors will inherit that property. However, that will require you to select()/poll()/kqueue() for that descriptor as well, instead of simply blocking in accept(). This is documented FreeBSD behaviour and common across BSDs, but is not portable. POSIX leaves it unspecified what the non-blocking state of the new socket is and in fact Linux always makes the new socket blocking (unless you request non-blocking using their new accept4() call). Because this portability issue can be very subtle, I suggest not blindly relying on it. Oh, ok. I wasn't aware. Thanks for the heads-up. Good, fast cheap: pick any two. ___ 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: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs
2011/7/31 Kostik Belousov kostik...@gmail.com: Below is the hopefully final patch after Bruce Evans' comments incorporated. If nobody speaks, I will send this to re tomorrow. I notice it's been committed already, and tested latest HEAD. It's working fine, thank you! -- Robert Millan ___ 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
