Re: Socket buffer usage
This might not exactly be what you want, but struct kevent has a member called data which, for sockets and pipes, returns the number of available bytes to read (or write) for EVFILT_READ (or EVFILT_READ) events. -- Good, fast and cheap: pick any two. On Saturday, April 7, 2012 at 10:16 PM, Ivan Voras wrote: Hi, I'm tracking down an obscure bug in my userland program and it might have something to do with the way I writeread data through a (Unix domain) socket. I'm setting SO_SNDBUF and SO_RCVBUF, and what I'm looking for is some way to query the amount of TX RX buffered / free data on a socket. Is there something I can use? I'll even accept inspecting kernel structures if explained in detail and can be done on a running system. Alternatively, is there anything else which could cause poll(2) with POLLOUT on a socket to return no events ready on such a socket? (my expectation being that a socket is always ready to be written to if there is buffer space free...). ___ freebsd-hackers@freebsd.org (mailto: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 (mailto: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: PostgreSQL benchmarks (now with Linux numbers)
On Thu, Feb 23, 2012 at 2:41 PM, Damien Fleuriot m...@my.gd wrote: On 2/23/12 2:22 PM, John Baldwin wrote: On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: On 02/22/2012 01:42, Ivan Voras wrote: The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty notable, what prevents us from enabling that by default? It makes all your SYSV SHMs wired. That's fine if you are running a dedicated server using SYSV SHMs where you want that process to use all the RAM in the machine (e.g. a pgqsl server). It's not so great for a general purpose load where you would like an otherwise-idle process using SYSV SHMs to have the SHMs paged out to swap if other processes on the machine need memory and the box is under memory pressure. John, any chance we can get that in layman's terms ? I'm totally no coder, but I'd really like if we could do this at my work place to increase our firewalls' performances. Hi Damien, The above setting prevents the SYSV shared memory from being swapped by the pager. It is useful in a database context, where you want the pages to be available imediately, without having to wait until they are loaded back from disk (in a memory constrained environment). I won't help your firewall at all. -- 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: 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: eliminating a syscall on accept()+ioctl() combo
On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: Hi all, 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! With regards, Bernard Hi Bernard, 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(). HTH Vlad___ 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
FIB separation
Hello, A couple of years ago, Stef Walter proposed a patch[1] that enforced the scope of routing messages. The general consesus was that the best approach would be the OpenBSD way - transporting the FIB number in the message and letting the user applications filter out unwanted messages. Are there any plans to tackle this before 9.0? Thanks, Vlad [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931___ 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: FIB separation
On Jul 16, 2011, at 5:42 PM, Hiroki Sato wrote: Vlad Galu d...@dudu.ro wrote in a718adb2-ec52-462c-a114-85053f1b2...@dudu.ro: du Hello, du du A couple of years ago, Stef Walter proposed a patch[1] that enforced du the scope of routing messages. The general consesus was that the best du approach would be the OpenBSD way - transporting the FIB number in the du message and letting the user applications filter out unwanted du messages. du du Are there any plans to tackle this before 9.0? I am looking into this and investigating other possible extensions in rtsock messages such as addition of a fib member to rt_msghdr. I am not sure it can be done before 9.0, though... -- Hiroki Thanks! Even if this gets postponed for 10.0, living with a backport of the official implementation would be easier than maintaining a homegrown solution. VG ___ 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: Mem leak : malloc/free + pthreads = leakage?
On Sun, Mar 6, 2011 at 6:53 AM, Eric Anderson ander...@ttel.com wrote: On Mar 5, 2011, at 10:44 AM, Deomid Ryabkov wrote: On 03/05/2011 04:02 AM, Eric Anderson wrote: Hi all, I have a moderately threaded userland program (all C) I am working on (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard malloc/free) badly. as opposed to what? OpenBSD? Linux? Windows? why do you think your problem is specific to FreeBSD (as evidenced by your post to a FreeBSD-specific list) or is related to threaded programs? OpenSolaris and Mac OS X. I didn't really assume or state it was specific to FreeBSD, just that this scenario was on FreeBSD. I happen to do most of the development and testing on OS X and FreeBSD, and I've enjoyed the FreeBSD community for a very long time. I am using pcap to capture packets and process them. I have a handful of libs statically linked in (pcap is one, the rest don't seem to matter - I can remove them and still see the leak). Does anyone know of issues regarding malloc/free on multithreaded userland apps? hell yeah. it goes like this: you malloc() then forget to free() - boom, you have a memory leak. you're welcome. Thanks, very insightful. sarcasm aside, those questions still remain: why do you think os/libraries are the problem and not your code? Because I am tracking all malloc and free calls within the application code (aside from libraries) and I can account for all malloc'ed memory and freed memory in both count and by bytes, yet looking at ps output shows a very different story, and if I leave it run long enough, will consume all memory and swap in the system and then be killed off. I wrapped malloc/free in a function, and record all memory alloc'ed and free'd. The only memory I cannot track is memory alloced and freed by libraries I am pulling in (well, can't track easily anyway without hacking through all of their source code). you can't post all of it, ok, and we don't want all of it either. can you isolate a specific example of where valid usage of a library causes a leak? Not really - if I could, I would have fixed it by now. It's a non-trivial issue - which is why I am beginning to suspect something more complicated than a oops I forgot to free kind of error. Plus, I have seen a few people elsewhere on various forums/mailing lists with similar issues claiming that switching to the Hoard allocator fixed the problem (which doesn't seem to be happy with 32bit FreeBSD - tried it). I have also seen various comments about pthreads and memory allocators having apparent leaks at some threading level, but not sure. Thanks, Eric Had there been a memleak in jemalloc, I'm sure more people would have spotted it by now. How many pcap_t structs do you use in your app? libpcap is not threadsafe. FWIW I've been running a pcap/threaded application continuously for the past couple of years and the memory usage has been constant. Also, put a couple of printf()s before and after pcap_dispatch()/pcap_loop() (if you use any of them), to make sure they don't block waiting for your callback to return (on some platforms it doesn't, so you never get to free memory in outer frames). This might not necessarily be your case, but it's worth taking a look at. ___ 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 -- 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: Mem leak : malloc/free + pthreads = leakage?
On Sun, Mar 6, 2011 at 2:06 PM, Vlad Galu d...@dudu.ro wrote: On Sun, Mar 6, 2011 at 6:53 AM, Eric Anderson ander...@ttel.com wrote: On Mar 5, 2011, at 10:44 AM, Deomid Ryabkov wrote: On 03/05/2011 04:02 AM, Eric Anderson wrote: Hi all, I have a moderately threaded userland program (all C) I am working on (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard malloc/free) badly. as opposed to what? OpenBSD? Linux? Windows? why do you think your problem is specific to FreeBSD (as evidenced by your post to a FreeBSD-specific list) or is related to threaded programs? OpenSolaris and Mac OS X. I didn't really assume or state it was specific to FreeBSD, just that this scenario was on FreeBSD. I happen to do most of the development and testing on OS X and FreeBSD, and I've enjoyed the FreeBSD community for a very long time. I am using pcap to capture packets and process them. I have a handful of libs statically linked in (pcap is one, the rest don't seem to matter - I can remove them and still see the leak). Does anyone know of issues regarding malloc/free on multithreaded userland apps? hell yeah. it goes like this: you malloc() then forget to free() - boom, you have a memory leak. you're welcome. Thanks, very insightful. sarcasm aside, those questions still remain: why do you think os/libraries are the problem and not your code? Because I am tracking all malloc and free calls within the application code (aside from libraries) and I can account for all malloc'ed memory and freed memory in both count and by bytes, yet looking at ps output shows a very different story, and if I leave it run long enough, will consume all memory and swap in the system and then be killed off. I wrapped malloc/free in a function, and record all memory alloc'ed and free'd. The only memory I cannot track is memory alloced and freed by libraries I am pulling in (well, can't track easily anyway without hacking through all of their source code). you can't post all of it, ok, and we don't want all of it either. can you isolate a specific example of where valid usage of a library causes a leak? Not really - if I could, I would have fixed it by now. It's a non-trivial issue - which is why I am beginning to suspect something more complicated than a oops I forgot to free kind of error. Plus, I have seen a few people elsewhere on various forums/mailing lists with similar issues claiming that switching to the Hoard allocator fixed the problem (which doesn't seem to be happy with 32bit FreeBSD - tried it). I have also seen various comments about pthreads and memory allocators having apparent leaks at some threading level, but not sure. Thanks, Eric Had there been a memleak in jemalloc, I'm sure more people would have spotted it by now. How many pcap_t structs do you use in your app? libpcap is not threadsafe. FWIW I've been running a pcap/threaded application continuously for the past couple of years and the memory usage has been constant. Also, put a couple of printf()s before and after pcap_dispatch()/pcap_loop() (if you use any of them), to make sure they don't block waiting for your callback to return (on some platforms it doesn't, so you never get to free memory in outer frames). This might not necessarily be your case, but it's worth taking a look at. That should've been pcap_dispatch()/pcap_next(). ___ 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 -- Good, fast cheap. Pick any two. -- 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: [maybe spam] Re: linux PF_PACKET compatibility
On Sat, Feb 12, 2011 at 12:28 PM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: On 02/12/11 19:39, Gary Jennejohn wrote: On Fri, 11 Feb 2011 17:19:17 -0800 Julian Elischerjul...@freebsd.org wrote: On 2/11/11 4:03 PM, Da Rock wrote: Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Ther's a sendarp() routine which uses PF_PACKET to directly access the network driver and bypass the stack. Lazy Linuxers who have no idea or don't care that other operating systems exist. Indeed. Is it possible to leverage another compatible routine? I haven't had a look yet as I just read the message, but can I (after checking return values and arguments) just drop in another arp routine? Or are they simply incompatible across the board? From what I understand they should all be essentially doing the same thing, but I could be wrong on this. Alternatively would I have to basically rewrite the arp.c to be posix compatible (for portability)? Cheers You only need to rewrite the sendarp() routine, using a BPF device descriptor instead of the PF_PACKET socket descriptor. Take a look at libdnet[1] and rbootd[2]'s source. [1] http://libdnet.sf.net/ [2] http://ftp.fr.openbsd.org/pub/OpenBSD/src/usr.sbin/rbootd/ You will need, however, to fill the source with #ifdefs to compensate the fact that Linux has assigned different names and sizes to the members of struct ether_header and arphdr (and has a _BSD_SOURCE knob to accomodate compiling BSD-based software).* * -- 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: linux PF_PACKET compatibility
On Fri, Feb 11, 2011 at 9:22 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ 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 Take a look at bpf(4). I believe you could bypass the TCP/IP stack with netgraph(4), as well, although with possibly more overhead. -- 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: linux PF_PACKET compatibility
On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) -- 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: Compiling kernel with gcc43 [SOLVED]
On Thu, Apr 1, 2010 at 6:27 PM, Oliver Fromme o...@lurza.secnetix.de wrote: Mario Lobo l...@bsd.com.br wrote: [...] It's compiling right now. I'll post my findings and impressions on results and performance right after the next reboot. So, how is it going? Any benchmarks yet? I'm curious if the new gcc version will really make a significant difference. I'm not as worried about performance as I am about compatibilty. Various software suites have started using newer GCCisms in their code. One example I can give from the top of my head is Wt (www.webtoolkit.eu), which compiles with 4.4, but not with 4.2. I shamefully haven't dug any deeper to check which particular syntactical construct offended 4.2. Yes, one might say, after all it's the upstream developers who ought to make sure their software compiles on FreeBSD, but some aditional overhead on the shoulders of our port maintainers should be expected. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ 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 -- 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: Small libstdc++ change required
On Sat, Dec 19, 2009 at 10:40 AM, Roman Divacky rdiva...@freebsd.org wrote: On Sat, Dec 19, 2009 at 09:28:55AM +0200, Vlad Galu wrote: Hi, as per http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36612, could one please apply the following patch? the patch in question seems to be GPLv3, we cant apply it then... Actually, I only followed their suggestion and made the patch myself. Ofc, it most likely looks like their does. It's not theirs, though. Could this work out? ___ 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
Small libstdc++ change required
Hi,
as per http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36612, could one
please apply the following patch?
-- cut here --
--- /usr/include/c++/4.2/ext/pb_ds/exception.hpp2008-04-05
14:15:32.0 +0300
+++ /mnt/store/jails/dudu/usr/include/c++/4.2/ext/pb_ds/exception.hpp
2009-12-19
05:07:55.0 +0200
@@ -71,35 +71,35 @@
struct resize_error : public container_error { };
#if __EXCEPTIONS
- void
+ inline void
__throw_container_error(void)
{ throw container_error(); }
- void
+ inline void
__throw_insert_error(void)
{ throw insert_error(); }
- void
+ inline void
__throw_join_error(void)
{ throw join_error(); }
- void
+ inline void
__throw_resize_error(void)
{ throw resize_error(); }
#else
- void
+ inline void
__throw_container_error(void)
{ std::abort(); }
- void
+ inline void
__throw_insert_error(void)
{ std::abort(); }
- void
+ inline void
__throw_join_error(void)
{ std::abort(); }
- void
+ inline void
__throw_resize_error(void)
{ std::abort(); }
#endif
-- and here --
Thanks,
Vlad
___
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: UNIX domain sockets on nullfs still broken?
On Mon, Nov 30, 2009 at 5:01 PM, xorquew...@googlemail.com wrote:
On 2009-11-30 15:43:01, Ivan Voras wrote:
xorquew...@googlemail.com wrote:
76030 initial thread STRU struct sockaddr { AF_LOCAL,
/tmp/jack-11001/default/jack_0 }
76030 initial thread NAMI /tmp/jack-11001/default/jack_0
76030 initial thread RET connect -1 errno 61 Connection refused
I would expect to see this result from the jail since it's obviously a
Bad Idea, but does it work from the same (host) machine without the jail
in between (i.e. just the nullfs, no jails)?
Hm, yes, you're right. It does work without a jail involved.
What's the sane solution, then, when the only method of communication
is unix domain sockets?
For redirecting a connection to a UNIX socket to a remote host:port,
there's net/unix2tcp. Perhaps you can patch it to go the other way
around as well?
xw
___
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: semaphores between processes
On Thu, Oct 22, 2009 at 11:08 PM, Andrew Gallatin galla...@cs.duke.edu wrote: Hi, We're designing some software which has to lock access to shared memory pages between several processes, and has to run on Linux, Solaris, and FreeBSD. We were planning to have the lock be a pthread_mutex_t residing in the shared memory page. This works well on Linux and Solaris, but FreeBSD (at least 7-stable) does not support PTHREAD_PROCESS_SHARED mutexes. We then moved on to posix semaphores. Using sem_wait/sem_post with the sem_t residing in a shared page seems to work on all 3 platforms. However, the FreeBSD (7-stable) man page for sem_init(3) has this scary text regarding the pshared value: The sem_init() function initializes the unnamed semaphore pointed to by sem to have the value value. A non-zero value for pshared specifies a shared semaphore that can be used by multiple processes, which this implementation is not capable of. Is this text obsolete? Or is my test just getting lucky? Is there recommended way to do this? Thanks, Drew Hi Andrew, This works in Linux is because Linux defines sem_t as a struct type(or union, IIRC), while our sem_t is a pointer type (with more state kept in the pointed struct). SYSV semaphores seems the way to go... ___ 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: sigwait - differences between Linux FreeBSD
On Thu, Oct 8, 2009 at 1:02 PM, Kostik Belousov kostik...@gmail.com wrote: On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote: Hi all, In my efforts to make the xrdp port more robust under FreeBSD, I have discovered that sigwait (kind of an analogue to select(2), but for signals rather than I/O) re-enables ignored signals in its list under Linux, but not FreeBSD. The sesman daemon uses SIGCHLD to clean up after a session has exited. Under Linux this works OK, under FreeSBD it doesn't. I have worked around it in a very hackish manner (define a dummy signal handler and enable it using signal, which means that the sigwait call can then be unblocked by it), but am wondering if anyone else has run across the same problem, and if so, if they fixed it in an elegant manner. Also, does anyone know the correct semantics of sigwait under this situation? ports@ is the wrong list to discuss the issue in the base system. Solaris 10 sigwait(2) manpage says the following: If sigwait() is called on an ignored signal, then the occurrence of the signal will be ignored, unless sigaction() changes the disposition. We have the same behaviour as Solaris, ingored signals are not queued or recorded regardeless of the presence of sigwaiting thread. This is a bit confusing. sigwait(2) says: The signals specified by set should be blocked at the time of the call to sigwait() ___ 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: continuous backup solution for FreeBSD
On Mon, Oct 6, 2008 at 5:33 PM, Evren Yurtesen [EMAIL PROTECTED] wrote: Bob Bishop wrote: Does anybody have free time and skills to give a hand? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Should be possible to do this with a geom(4) class? I am not saying it is impossible. They just need somebody to put them to right track I guess. I personally cant do that. It would be nice if somebody who has knowledge in this area contacts r1soft. At the very least r1soft seems to be willing to communicate on this issue. Continuous backups as well as bare-metal-restore seem to be a key feature for many hosters. FreeBSD is loosing users because of this issue. gmirror+ggate come to mind as a nifty solution ... Thanks, Evren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- ~/.signature: no such file or directory ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
g++ associative containers
Hello list, I didn't have a clue where else to post this so I figured this place was the right one. I also CCed Alex Kabaev, who did the gcc 4 import. I'd like to use a Patricia container in the new libstdc++. The issue is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp has two erroneous #include directive on lines 52 and 53. Are there any plans to cover that part of the new libstdc++, or is there any workaround? Thanks, Vlad -- ~/.signature: no such file or directory ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ associative containers
On 6/16/08, Alexander Kabaev [EMAIL PROTECTED] wrote: On Mon, 16 Jun 2008 16:58:10 +0300 Vlad GALU [EMAIL PROTECTED] wrote: Hello list, I didn't have a clue where else to post this so I figured this place was the right one. I also CCed Alex Kabaev, who did the gcc 4 import. I'd like to use a Patricia container in the new libstdc++. The issue is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp has two erroneous #include directive on lines 52 and 53. Are there any plans to cover that part of the new libstdc++, or is there any workaround? Thanks, Vlad File a PR plaase and assign it to me. Hi Alexander, I submitted the PR, but I've no clue how to assign it to you. Neither send-pr or the web interface (which I ended up using) seemed to allow me to do that. This is probably a PEBKAC :) -- Alexander Kabaev -- ~/.signature: no such file or directory ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The main
I/O
loop calls kevent(), which in turn returns two events with EV_EOF error
set,
always for the same descriptors (they're both socket descriptors). As
the
man page is not pretty clear about it and I don't have my UNP copy at
hand,
I would like to ask the list whether the error events are supposed to be
one-shot or not.
I wonder if it's returning one event for the read socket buffer, and one
event
for the write socket buffer, since there are really two event sources for
each
socket? Not that this is desirable behavior, but it might explain it.
If you
shutdown() only read, do you get back one EOF kevent and one writable
kevent?
I'll try that and see. The only issue being the low frequency this
symptom appears at. I'll get back to the list once I have more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Robert N M Watson
Computer Laboratory
University of Cambridge
--
Mahnahmahnah!
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/14/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The
main I/O
loop calls kevent(), which in turn returns two events with EV_EOF
error set,
always for the same descriptors (they're both socket descriptors).
As the
man page is not pretty clear about it and I don't have my UNP copy
at hand,
I would like to ask the list whether the error events are supposed
to be
one-shot or not.
I wonder if it's returning one event for the read socket buffer, and
one event
for the write socket buffer, since there are really two event sources
for each
socket? Not that this is desirable behavior, but it might explain it.
If you
shutdown() only read, do you get back one EOF kevent and one writable
kevent?
I'll try that and see. The only issue being the low frequency this
symptom appears at. I'll get back to the list once I have more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Ah one more thing. When EOF is caught, a handler which forcibly
removes the event is called, but it keeps poping up again and again.
Robert N M Watson
Computer Laboratory
University of Cambridge
--
Mahnahmahnah!
--
Mahnahmahnah!
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/14/08, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Mar 14), Vlad GALU said:
On 3/14/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house
applications. The main I/O loop calls kevent(), which in turn
returns two events with EV_EOF error set, always for the same
descriptors (they're both socket descriptors). As the man
page is not pretty clear about it and I don't have my UNP
copy at hand, I would like to ask the list whether the error
events are supposed to be one-shot or not.
I wonder if it's returning one event for the read socket
buffer, and one event for the write socket buffer, since there
are really two event sources for each socket? Not that this
is desirable behavior, but it might explain it. If you
shutdown() only read, do you get back one EOF kevent and one
writable kevent?
I'll try that and see. The only issue being the low frequency
this symptom appears at. I'll get back to the list once I have
more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Ah one more thing. When EOF is caught, a handler which forcibly
removes the event is called, but it keeps poping up again and again.
Are you sure the event is being removed? I used to have a hack that
made the kernel return its current eventlist for a kqueue when you
called kevent() with nchanges set to -1 (handy for placing in a program
and using truss to print the result), but it has rotted. I'm attaching
it in case anyone wants to make it work again.
Yep, I'm sure, I've just read the app logs again, we close the
descriptor in the connection destructor..
Since you got EOF status for both the read and write halves of the
socket, why not just close the fd? From my reading of the manpages,
unless you specified EV_ONESHOT when you added the event, events will
fire until you remove them or the condition that triggers them stops.
--
Dan Nelson
[EMAIL PROTECTED]
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 7 Mar 2008, Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. I wonder if it's returning one event for the read socket buffer, and one event for the write socket buffer, since there are really two event sources for each socket? Not that this is desirable behavior, but it might explain it. If you shutdown() only read, do you get back one EOF kevent and one writable kevent? I'll try that and see. The only issue being the low frequency this symptom appears at. I'll get back to the list once I have more info. Robert N M Watson Computer Laboratory University of Cambridge -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A (perhaps silly) kqueue question
I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Ah, yes, sorry. Fresh RELENG_7. Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Ah, yes, sorry. Fresh RELENG_7. Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. Is this reproducable? Can you make this happen at will? I'll try. So far we haven't been able to trigger it at will, unfortunately :( It just pops out once in a while.. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: retrive data from mbuf chain
On 2/7/08, Biks N [EMAIL PROTECTED] wrote: Hi, I am new to FreeBSD kernel programming. Currently I am trying to work on mbuf data manupulation. From my understanding: data (payload) is stored into one or more mufs which are chained together through m_next pointer. Now, I need to retrive all data in mbuf chain ( mbufs linked by m_next). I am working ip_output() in netinet/ip_output.c Does there exist inbuilt function/macro to retrive all the data in mbuf chain? I may be wrong on this one, but according to my understanding, a m_pullup() followed by a mtod() should do the trick. thanks in advance :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
On 1/22/08, Stefan Lambrev [EMAIL PROTECTED] wrote: Greetings, I noticed that hping3 (from ports) is quite slower when running on FreeBSD compared to Linux. Simple ktrace shows lot of gettimeofday() calls, so I'm looking for replacement of this function. I tried clock_gettime() (using CLOCK_REALTIME for clock_id), but this yield worse performance. Of course changing timecounter to TSC make hping almost twice faster, but I'm wandering if I can optimize things more? Also, is it possible to bypass the ACPI timer entirely without disabling the whole ACPI, in order to use TSC as the default timecounter? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large array in KVM
On 12/6/07, Sonja Milicic [EMAIL PROTECTED] wrote: Hi everyone. I'm working on a kernel module that needs to maintain a large structure in memory. As this structure could grow too big to be stored in memory, it would be good to offload parts of it to the disk. What would be the best way to do this? Could using a memory-mapped file help? Take a look at how the md(4) driver allocates swap-backed memory. Perhaps you could do the same for your structure, given that your swap space is big enough to hold it. Thanks in advance, Sonja ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/4/07, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-10-02 15:41, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Sm?rgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. There was an old bug, which caused pts consumers to get stuck in devdrn. This has been fixed, AFAICT, a long time ago. At least, I can't reproduce it any more with the usual tests: * Closing xterm windows. * Closing telnet sessions. * Exiting from screen(1) windows. Weird. 3 people on this thread already saw the symptoms :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Steven Hartland [EMAIL PROTECTED] writes:
Any one got any pointers on this, the machine we running this app on is over
90% idle so I really don't want to have to install a second machine just to
workaround a limit on the number of pty's, surely there's a way to increase
this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
Looks like it hasn't been. A friend who tried to set up an access
server for his company stumbled upon it.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. However, I see that, if I use pts/0-7, for instance, then log off pts/7, the next assigned pts will be pts/8. Is this expected? I tried lowering kern.pts.max to 20. If I open 20 of them and close them afterwards, on the next try I get no more ptys from my screen. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. Wouldn't get deallocated right away, or wouldn't get deallocated at all? Apparently, it is not unusual for pts reclamation to be delayed a bit by a non-zero refcnt. As per my other mail, they wouldn't get deallocated at all. They still show up in /dev/pts/ even after closing, and the next integer index is picked up upon the next terminal creation. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Status of base GDB
I couldn't help noticing that our gdb lags behind other BSDs. Is there a technical reason for this? I'm thinking threading changes/gcc changes (although I can't remember this kind of situation representing a setback in other BSDs' case). Thanks. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 6.2 C++ stl set.clear() very slow
On 5/7/07, valiy [EMAIL PROTECTED] wrote: [...] It might be related to phkmalloc vs jemalloc. You may want to try to link against jemalloc to see if the slowdown still occurs. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 6.2 C++ stl set.clear() very slow
On 5/7/07, valiy [EMAIL PROTECTED] wrote: Vlad GALU wrote: On 5/7/07, valiy [EMAIL PROTECTED] wrote: [...] It might be related to phkmalloc vs jemalloc. You may want to try to link against jemalloc to see if the slowdown still occurs. http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029186.html Fetch the HEAD revision of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/tree.h and overwrite your existing file using it. Afterwards, fetch the HEAD revision of http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/malloc.c. Last step: gcc -fPIC -O -Wall -I/usr/src/lib/libc/include -I/usr/src/sys -shared -o malloc.so malloc.c Or if you want to compile it into a simple object that you can then link directly in your application, gcc -O -Wall -I/usr/src/lib/libc/include -I/usr/src/sys -o malloc.o malloc.c HTH. [EMAIL PROTECTED] ~]# cp /7.0_CURRENT/src/lib/libc/stdlib/malloc.c /tmp/jemalloc.so [EMAIL PROTECTED] ~]# gcc -O -Wall -I/usr/src/lib/libc/include -shared -o /lib/jemalloc.so /tmp/jemalloc.c /tmp/jemalloc.c:1197: warning: type defaults to `int' in declaration of `RB_GENERATE_STATIC' /tmp/jemalloc.c:1197: warning: parameter names (without types) in function declaration /tmp/jemalloc.c:1197: warning: data definition has no type or storage class /tmp/jemalloc.c: In function `chunk_alloc': /tmp/jemalloc.c:1267: warning: implicit declaration of function `chunk_tree_s_RB_MINMAX' /tmp/jemalloc.c:1267: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c:1273: warning: implicit declaration of function `chunk_tree_s_RB_NEXT' /tmp/jemalloc.c:1273: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c:1276: warning: implicit declaration of function `chunk_tree_s_RB_REMOVE' /tmp/jemalloc.c: In function `chunk_dealloc': /tmp/jemalloc.c:1444: warning: implicit declaration of function `chunk_tree_s_RB_FIND' /tmp/jemalloc.c:1444: warning: comparison between pointer and integer /tmp/jemalloc.c:1451: warning: implicit declaration of function `chunk_tree_s_RB_INSERT' /tmp/jemalloc.c: At top level: /tmp/jemalloc.c:1597: warning: type defaults to `int' in declaration of `RB_GENERATE_STATIC' /tmp/jemalloc.c:1597: warning: parameter names (without types) in function declaration /tmp/jemalloc.c:1597: warning: data definition has no type or storage class /tmp/jemalloc.c: In function `arena_chunk_alloc': /tmp/jemalloc.c:1794: warning: implicit declaration of function `arena_chunk_tree_s_RB_INSERT' /tmp/jemalloc.c: In function `arena_chunk_dealloc': /tmp/jemalloc.c:1875: warning: implicit declaration of function `arena_chunk_tree_s_RB_REMOVE' /tmp/jemalloc.c: In function `arena_run_alloc': /tmp/jemalloc.c:2051: warning: implicit declaration of function `arena_chunk_tree_s_RB_MINMAX' /tmp/jemalloc.c:2051: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c:2051: warning: implicit declaration of function `arena_chunk_tree_s_RB_NEXT' /tmp/jemalloc.c:2051: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c: In function `huge_dalloc': /tmp/jemalloc.c:2730: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c: In function `isalloc': /tmp/jemalloc.c:2944: warning: assignment makes pointer from integer without a cast /tmp/jemalloc.c: In function `malloc_init_hard': /tmp/jemalloc.c:3114: warning: 'opts' might be used uninitialized in this function /tmp/jemalloc.c: In function `calloc': /tmp/jemalloc.c:3559: warning: 'num_size' might be used uninitialized in this function /tmp/jemalloc.c: At top level: /tmp/jemalloc.c:1183: warning: 'chunk_comp' defined but not used /tmp/jemalloc.c:1583: warning: 'arena_chunk_comp' defined but not used could you please send me you version of malloc.c ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: user-space locks
On 3/10/07, Kip Macy [EMAIL PROTECTED] wrote: umtx Is it safe/recommended to use spinlocks, like in jemalloc, for very small portions of code? I'm particularly interested in protecting writes to a couple of word sized ints on amd64, so the critical section wouldn't be longer than two assignments. Of course, I could use a lockless queue for my purposes, but I'm asking anyway. On 3/9/07, Peter Holmes [EMAIL PROTECTED] wrote: Does FreeBSD have anything similar to Futexes for Linux. Thanks, Peter Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: socket descriptor returned from socket()
On 2/6/07, Andrew N. Below [EMAIL PROTECTED] wrote: Hello. Could 0 (zero) be a valid socket descriptor? Yes, if your program is a daemon and closes fds 0, 1, 2 which corespond to stdin, stdout and stderr. man 2 socket: RETURN VALUES A -1 is returned if an error occurs, otherwise the return value is a descriptor referencing the socket. I have some troubles with xinetd (2.3.14) - first service in config file with proto=tcp, socket_type=stream and wait=yes fail to start (fcntl returns Bad file descriptor error). -- Andrew N. Below ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kqueue write event position?
On 11/23/06, Ivan Voras [EMAIL PROTECTED] wrote: Vlad Galu wrote: It seems to me you would have to propagate that info along the VOP_WRITE_POST-VFS_KNOTE_LOCKED-VN_KNOTE-knote() chain. Since knote() is generic and is used for all types of notifications, you can probably roll down your own replacement and call it from VN_KNOTE. Of course, there probably is a better way :) Before I get any further with this, can anyone predict what would be the impact of monitoring a large number of files (50,000 or more) with kqueue? For kqueue to work, each file would have to be opened (and take up one file descriptor). My guess is that it won't be remarcably high. However, you can create those files, add them to your notification list and randomly write bytes to them, to see how your system performs. One more suggestion, I think it would be better if, in case you extend the vnode API, you only send the size of the write in the data field of the kevent structure and you store the offset in your program and adding the size to it everytime an event occurs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kqueue write event position?
On 11/23/06, Ivan Voras [EMAIL PROTECTED] wrote: Vlad Galu wrote: My guess is that it won't be remarcably high. However, you can create those files, add them to your notification list and randomly write bytes to them, to see how your system performs. One more suggestion, I think it would be better if, in case you extend the vnode API, you only send the size of the write in the data field of the kevent structure and you store the offset in your program and adding the size to it everytime an event occurs. The writes will not be sequential so I need both offset and length. Eh I guess you can use udata for one of them, then. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kqueue write event position?
On 11/22/06, Ivan Voras [EMAIL PROTECTED] wrote: From the kqueue(2) manual: EVFILT_VNODE Takes a file descriptor as the identifier and the events to watch for in fflags, and returns when one or more of the requested events occurs on the descriptor. The events to monitor are:... I'm interested in NOTE_WRITE, but is there a way to find out where has the write been performed (position and length)? If not, how difficult would it be to expand the API so this information is included? It seems to me you would have to propagate that info along the VOP_WRITE_POST-VFS_KNOTE_LOCKED-VN_KNOTE-knote() chain. Since knote() is generic and is used for all types of notifications, you can probably roll down your own replacement and call it from VN_KNOTE. Of course, there probably is a better way :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD security development
On 3/31/06, Marko Lerota [EMAIL PROTECTED] wrote: Ian G [EMAIL PROTECTED] writes: In terms of cross-border payments, this is always difficult. You might want to look at one of the cross-border specialists like Kagi.com or moneybookers.com or the digital gold currencies. OK, thanks. But it's not only the Colin issue. The FreeBSD project also can't be sponsored from here. Bank orders should be just fine, assuming Colin tells us his IBAN account number and SWIFT code. -- One cannot sell the earth upon which the people walk Tacunka Witco ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD security development
On 3/31/06, Colin Percival [EMAIL PROTECTED] wrote: Vlad GALU wrote: Bank orders should be just fine, assuming Colin tells us his IBAN account number and SWIFT code. I wish I could. Sadly, while Canadian banks are very good at handling payments to/from the US, they aren't very good at handling payments from outside of North America. When I asked about this I got the impression that such payment mechanisms were only available to business customers (i.e., those paying large fees for the privilege). If I were to follow Marko's statement, I also live in a 3rd world country, which is Romania. Over here these services are available to absolutely everybody, no matter whether they have a credit or debit card. I've been using them for quite some time to transfer money in and out, without a single problem, be the transfers local or international. It's true that sometimes the managing fees were not exactly friendly (depends on each bank), but it was overall a lot less expensive than Western Union. I'm not familiar with the North American banking practices at all, but it might not hurt to push them a little ;) Colin Percival -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fastest timecounter ?
Dear hackers, I'm in a dilemma (more like a trilemma, actually). While following the 5.x and 6.x development cycle I observed that the default timecounter varies from one machine from another (for instance on my home desktop which is an AMD Athlon 2400+ it uses ACPI-fast, whereas on my Centrino-powered lappie it likes TSC better). I wrote a piece of software that has to get the current timestamp, one way or the other, a huge number of times per second. Apart from the empyrical tests one can perform to find out the timekeeping scheme with the less performance impact, is there any rule of thumb as to what choice to go for ? Any kind of advice is most welcome, especially reading material. P.S. I know that some of you may say that calling gettimeofday() that often is braindead, and at some point I agree. Unfortunatley, right now I can't do anything better. I need timekeeping to comb the algorithms that deal with my data structures a bit more, after which I can switch to time-related optimizations. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing SSH from a C program
On 2/24/06, Martin Möller [EMAIL PROTECTED] wrote: Hi all, I try to copy some files securely from one machine to another. What is the fastest and easiest way to accomplish this task? Can I access SSH routines in C (is there a library) or is it better just to call scp externally? http://0xbadc0de.be/wiki/doku.php?id=libssh:libssh Or, if you prefer scripting, try this: http://net-ssh.rubyforge.org/. It's also in ports (security/rubygem-net-ssh). Greetings, m. -- Martin Möller freebsd at martinmoeller.net IM: 82221572 (ICQ) - [EMAIL PROTECTED] (Jabber) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Number of kevents registered in kqueue
On 12/17/05, Seán C. Farley [EMAIL PROTECTED] wrote: I may have missed it in the man page, but I am unable to find a way to determine how many kevents are currently registered within a kqueue. If there is no method for a count, how about a way to find if a kqueue is empty or not. Besides tracking what events are still within a kqueue, this would make for an easier way to write an event loop. Currently, calling kevent() on an empty kqueue will still block. kevent() returns the number of events from the changelist, which is at most nevents long. So you know already how many events you've registered and how many of them were yielded. As for blocking on an empty queue, you can get rid of it by passing a pointer to a zeroed struct timespec as the last argument to kevent(). This usually works: -- cut here -- int ev = kevent(kq, NULL, 0, events, maxevents, timeout); for (int i = 0; i ev; i++) ... -- and here -- where kq is the kqueue descriptor, events is a pointer to a struct kevent array, maxevents is the maximum number of watched events and timeout is a struct timespec with all members set to 0. For examples you can check thttpd/lighttpd and/org libevent, they all provide wrappers around kqueue. Also, I recommend that the man page mention that a kqueue may be close(2)'d. The only reference that it can be is that the manual page says the kqueue() call returns a descriptor. Seán -- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cwnd and sstresh monitor
On 12/1/05, Alin-Adrian Anton [EMAIL PROTECTED] wrote: Dear Hackers, I would like to monitor the changes of cwnd and sstresh values during TCP traffic, in order to plot graphs and interpret congestion. So I need (cwnd, timestamp) and (sstresh, timestamp) records to be taken everytime one of the two variables is modified. I'd like to ask you for suggestions, which would be the best aproach (kernel patch, kernel module, etc?), and how would this be done best? (the interception of values, the storage of snapshots, etc)? Does exporting them via sysctl, and graph them using anything (rrdtool) sound reasonable ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BPF patch
On 9/1/05, Vladimir Yu. Stepanov [EMAIL PROTECTED] wrote: [snip] You can always control which traffic to sniff (ingress/egress) using layer 2 filters (ether src/dst host ). -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: preferable way to control kernel module
On 8/10/05, Sergey Uvarov [EMAIL PROTECTED] wrote: Hello hackers, I'm writing a kernel module for my own needs. AFAIK the following methods could be used: 1) allocate not used system call with help of SYSCALL_MODULE macro 1 syscall 2) allocate proprieatry oid via SYSCTL_OID(OID_AUTO) and write an appropriate sysctl handler(s) 1 syscall + some work on the handler, but less flexibility. You can't pass much information as an OID value. 3) add a file in /dev and use ioctl(2) call at least 2 syscalls (open()/ioctl()). The flexibility would be the same as 1), since you would also probably pass info packed in a structure that is the argument for the ioctl(). But you'd have to do slightly more work involving the /dev entry. What is a preferable way to control my module? I would go for 1. But then again, I might be wrong. Better wait to hear more suggestions before choosing a design. Thanks in advance, Sergey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: limit jail disk space
On 7/13/05, Jone Jas [EMAIL PROTECTED] wrote: Alex Lyashkov [EMAIL PROTECTED] 写道： В Срд, 13.07.2005, в 06:42, Jone Jas пишет: Alex Lyashkov 写道： В Втр, 12.07.2005, в 16:03, Vlad GALU пишет: On 7/12/05, Jone Jas wrote: Thanks for your reply. I googled and found this method but I just did not have a try. As for the code-hacking method I mentioned, anyone with any idea is appreciated! See ufs_quota.c, especially chkdqchg(). It is passed a struct ucred* parameter, which contains a struct prison* pointer. So I assume you can make your decision based on that. Of course, the userland quota management tools and the jail utilities need to be made aware of the kernel changes. -- if you compile kernel without QUOTA support it been disabled. I think, more correctly way implement jail disk limit as parallel for disk quota function. IMHO, we can use a sysctl variable to control the functionality. option QUOTA? or jail disklimit? I mean jail disk limit for jail disklimit more easy create tools who controled all limits for jail. Look to LinuxVServer project (www.linux-vserver.org) or FreeVPS. Sure. The tools may control all limits such as cpu time, memory, bandwidth, disk space, etc. I have read the Linux VServer dlimit code. But I am not very sure where to put the hooks for inode/blocks control of jail in FreeBSD. This is why I open this thread. Vlad GALU said I can look to the quota method. I will try. Thanks. It will most probably be tricky, because you can practically have the same uid in both worlds (the host and the jail) with different quota settings mapped to it. So upon granting fs resources you'd have to check which 'world' the request came from. If the quota for that world isn't overdue, you check for that uid's quota inside that world and if that's still OK you grant the resource. You will probably have to add an extra member to the prison structure, to hold the global quota for that jail. -- FreeVPS Developers Team http://www.freevps.com - DO YOU YAHOO!? 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: limit jail disk space
On 7/12/05, Jone Jas [EMAIL PROTECTED] wrote: Thanks for your reply. I googled and found this method but I just did not have a try. As for the code-hacking method I mentioned, anyone with any idea is appreciated! snip See ufs_quota.c, especially chkdqchg(). It is passed a struct ucred* parameter, which contains a struct prison* pointer. So I assume you can make your decision based on that. Of course, the userland quota management tools and the jail utilities need to be made aware of the kernel changes. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question: tracking filesystem changes?
On Wed, 02 Feb 2005 17:00:22 +0300, Deomid Ryabkov [EMAIL PROTECTED] wrote: Milan Obuch wrote: This could be a custom filesystem wrapper for UFS that would report name of the file/directory being changed. Couldn't you use kqueue system to monitor the directory-file? I could, if I hadn't near 10 millions of them. Hm. I meant monitoring the directory itself, as a file, then parsing the directory list to determine what has changed. But with 10M files, probably nothing would work... these are 10M of static documents, the daily change is minmal. the question is: where it is the appropriate place to collect those changes? the right way seems to implement a customs filesystem, but would it possible to obtain a full path at that level? Did you consider using fam (file alteration monitor) from ports? No, won't do the trick either. I cannot afford setting up watchdogs for every file or even every directory. And I'm essentially interested in every one of them (for mirroring purposes). A more general approach is needed. E.g., if an unlink call is issued and an inode is within a particular filesystem (luckily, most of our data already lives on or can be easily moved to a separate filesystem), a notice is sent to some userland daemon: file /www/xxx/yyy.shtml is unlinked. Or opened for writing, or renamed... etc. The file is then scheduled for distribution to mirrors. The idea seems simple and straightforward, yet I don't know if it is achievable. The essential part is obtaining the full pathname of the file (won't bother with hardlinks at first, they aren't used here). Could that be done with the FreeBSD's filesystem (vnode/vfs?) code? (which I'm not familiar with) -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 I once wrote a very small tool that used the kqueue API for tracking descriptor changes. It basically read a list of files, open them in read-only mode, and sent messages to syslog everytime one of the descriptors changed status. In fact, if you read the kqueue documentation (http://people.freebsd.org/~jlemon/papers/kqueue.pdf), you'll pretty much find all you need. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: counting total PIDs since the server been started
On Tue, 14 Dec 2004 09:55:21 +, Chris Elsworth [EMAIL PROTECTED] wrote: On Tue, Dec 14, 2004 at 12:33:45PM +0300, scream wrote: Hello freebsd-hackers, I`m trying to solve this puzzle how to get statistics about total count of fork`ed\exec`ed processes since the server been rebooted and even make some RRD-like graphs.I need it to make some graphs about server perfomance and stability.Could anyone point me to any usefull docs. Hello, OTTOMH without consulting any docs, are these any use: # sysctl -a | grep fork vm.stats.vm.v_forks: 4795379 vm.stats.vm.v_vforks: 1017309 vm.stats.vm.v_rforks: 0 Hehe, I never noticed those. -- Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: counting total PIDs since the server been started
On Tue, 14 Dec 2004 09:23:46 -0600, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Dec 14), Vlad GALU said: On Tue, 14 Dec 2004 09:55:21 +, Chris Elsworth [EMAIL PROTECTED] wrote: On Tue, Dec 14, 2004 at 12:33:45PM +0300, scream wrote: I`m trying to solve this puzzle how to get statistics about total count of fork`ed\exec`ed processes since the server been rebooted and even make some RRD-like graphs.I need it to make some graphs about server perfomance and stability.Could anyone point me to any usefull docs. OTTOMH without consulting any docs, are these any use: # sysctl -a | grep fork vm.stats.vm.v_forks: 4795379 vm.stats.vm.v_vforks: 1017309 vm.stats.vm.v_rforks: 0 Hehe, I never noticed those. Most Unixes provide these stats under the vmstat -s command also. It'd be nice if Linux had something like that. However, I've been able to reproduce the desired effect by issuing cat /proc/stat | grep processes. -- Dan Nelson [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: counting total PIDs since the server been started
On Tue, 14 Dec 2004 12:33:45 +0300, scream [EMAIL PROTECTED] wrote: Hello freebsd-hackers, I`m trying to solve this puzzle how to get statistics about total count of fork`ed\exec`ed processes since the server been rebooted and even make some RRD-like graphs.I need it Maybe add your own read-only sysctl OID and then replace the fork() syscall so it would increment the corresponding variable accordingly at each run ? Read Andrew Reiter's or Pragmatic's tutorials on hacking system calls. After that, take a look at pjd's page, he has some nice stuff that also implements additional sysctls: http://www.daemonnews.org/200010/blueprints.html http://garage.freebsd.pl/ to make some graphs about server perfomance and stability.Could anyone point me to any usefull docs. -- Best regards, Dmitry S. Polyakov mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions ?
Saber ZRELLI [EMAIL PROTECTED] writes: |Hello Dear Seniors , |i was looking for some interesting issue related to FreeBSD networking |, to make it my master thesis , but i couldn't find such a topic , |certainly because i'm not a FreeBSD expert ( but i will be =) ) , |so could any member here , especially contributors , i'm sure you have |very rich ideas and cool stuff to offer ... | |i was thinking about implementing Robust TCP/IP connections .. but |somebody told me that is not very consistent , and i think so also , | |this master thesis will take 1 year ... Some of the things I mostly enjoyed playing with after turning to FreeBSD: kqueue(2)/netgraph(4)/divert(4)/net.inet.tcp.syncache.*/accept_filter(9 ). Perhaps these would give you some slight hints. | |Plz help . | |MANY many thanks. | | | | | |-- |Saber ZRELLI. | |Japana Advanced Institute of Science and Technology |School of Information Sience. |Katayama Lab |mail: [EMAIL PROTECTED], [EMAIL PROTECTED] |url : www.jaist.ac.jp/~zrelli |gpg-id : 0x7119EA78 | |___ |[EMAIL PROTECTED] mailing list |http://lists.freebsd.org/mailman/listinfo/freebsd-hackers |To unsubscribe, send any mail to |[EMAIL PROTECTED] | If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgpXWLQbQKl6w.pgp Description: PGP signature
KLD trouble
Hi there. I've been writing a KLD which contains a control syscall. I then use the macro SYSCALL_MODULE with the desired parameters. Normally, my syscall would automatically get the next free syscall number. But it seems I've done something wrong, because I get negative numbers all the time, which is not correct. Any idea why ? Has this happened to anyone else before ? I read the code several times trying to find the bug, but it was exactly like the one used in the examples in /usr/share/examples/kld/syscall/module. I'm quite lost here ... If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgpYZF4tbRXTA.pgp Description: PGP signature
FreeBSD book recommendation
I'd like to buy a book about FreeBSD kernel internals: data structures, VM layout, reasons for various implementations, sort of a traver through the sourcecode, along with explaining each design decision that has been taken. I'm interested of improving both my personal experience and my fellows'. Do you know any good titles ? Something that can be bought online with price varying betweek $50-200. Thanks in advance for any pointers. If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgprQ7vg3iRWD.pgp Description: PGP signature
Re: SYSV message queues
On Sun, 11 Apr 2004, Lev Walkin wrote:
Vlad GALU wrote:
Hello. I have the following scenario: one process that creates a
message queue and goes through it in a loop, together with another process
that inserts various messages into the queue. What I wish is for the
'listening' process to be able to fully process the queue at a fixed
amount of time. In short, I'd like msgrcv() to iterate throught the queue
and visit every element in a single run. That set of operations being done
periodically.
Do you find this possible ? I'm quite puzzled here. I first tried
inserting a sleep() call in my queue processing loop but then I noticed
that it had a bad effect. It's true that I haven't read the man page very
carefully the first time. I'll blame it on the hurry.
However, while writing this message, an idea occured to me. What
if I write the processing loop as follows:
-- cut here --
int i;
while (1) {
i = 0;
msgctl(queueid, IPC_STAT, queuestat);
while (i = queuestat.msg_qnum) {
msgrcv(queueid, message, sizeof(message), 0, 0);
process_message(message);
i++;
}
sleep(5);
}
-- and here --
Does this look pheasible ? I'm expecting an injection of about
100k messages per second or even more. There'll be quite a lot of
unprocessed ones at the end of each run, I suppose. I'll measure the average time
spent for
one run and decide on the sleep interval.
Did you try to grok what the msgrcv() call is supposed to return?
Specifically, read about -1/EAGAIN and IPC_NOWAIT. Then remove sleep().
It is supposed to block, waiting for more events to be inserted
into the queue.
However, does anyone have a better design ?
Yes. Use sockets.
My program currently uses sockets. I found it easier to write
clean code with SYSV SHM. In fact, I turned to a SYSV message queue
because I wanted to rely on the kernel to manage it, rather than doing it
myself. Of course, this raises some portability problems, but the goal of
the software I'm currently writing is very biased. It will only run on
FreeBSD, so I guess there's no problem with that.
Obsolescent Unix IPC Methods
http://www.catb.org/~esr/writings/taoup/html/ch07s03.html#id2923376
Thanks. That was a nice reading material. I don't entirely agree
with it though. It has some strong points against using shared memory
areas and/or threads. Unfortunately, theory often does not apply in
practice. I think' it's easier for one to program using one of the above
methods. Nowadays most UNIX software makes use of them.
--
Lev Walkin
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
SYSV message queues
Hello. I have the following scenario: one process that creates a
message queue and goes through it in a loop, together with another process
that inserts various messages into the queue. What I wish is for the
'listening' process to be able to fully process the queue at a fixed
amount of time. In short, I'd like msgrcv() to iterate throught the queue
and visit every element in a single run. That set of operations being done
periodically.
Do you find this possible ? I'm quite puzzled here. I first tried
inserting a sleep() call in my queue processing loop but then I noticed
that it had a bad effect. It's true that I haven't read the man page very
carefully the first time. I'll blame it on the hurry.
However, while writing this message, an idea occured to me. What
if I write the processing loop as follows:
-- cut here --
int i;
while (1) {
i = 0;
msgctl(queueid, IPC_STAT, queuestat);
while (i = queuestat.msg_qnum) {
msgrcv(queueid, message, sizeof(message), 0, 0);
process_message(message);
i++;
}
sleep(5);
}
-- and here --
Does this look pheasible ? I'm expecting an injection of about
100k messages per second or even more. There'll be quite a lot of
unprocessed ones at the end of each run, I suppose. I'll measure the average time
spent for
one run and decide on the sleep interval. However, does anyone have a
better design ?
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
passing messages to routing sockets
I understand that in order to add a new route to the routing
table, one must fill a buffer with an ifa_msghdr header, followed by three
socked adddress structures, representing the destination net/ip, the
netmask and the gateway.
While reading route(4) I encountered this:
struct ifa_msghdr {
..
u_int ifmam_addrs;/* like rtm_addrs */
..
}
Now, the description for the rtm_addrs member of the rt_msghdr
says that this should be a bitmask that identifies sockaddrs in the
message sent to the routing socket.
Could anyone provide a quick/small example on how to fill this
member ? I don't really understand what I should write into it.
Thanks in advance for any interest shown to my problem and any
time spent on enlightening a poor soul :)
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Stripping symbol names from /kernel
Is there any way to do that without affecting anything ? I'd like to remove that information. Some people might find it interesting ... If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgp0.pgp Description: PGP signature
Re: help sysctl.h
Nate Grey [EMAIL PROTECTED] writes:
|Hello,
|
|I'm trying to write a little program which retrieve the value 'sysctl
|hw.acpi.thermal.tz0.temperature', I want to write it in C, through
|sys/sysctl.h, but I'm a newbie C coder, so can anyone show me how to
|assign to a var the value stored in that sysctl using sysctl C call?
|I have read 'man 3 sysctl' but I didn't understand very well...
|
|P.S.
|1) Sorry for my English
|2) I'm not a list subscriber so please cc:
|
This is simple. Let's try a read example first:
-- cut here --
#include stdio.h
#include sys/types.h
#include sysctl.h
int main() {
int ret; /* here we will place our result */
int size = sizeof(ret); /* this is the storage size of the variable we
put our result into */
sysctlbyname(net.inet.ip.forwarding, (void *)ret, size, NULL,
NULL);
return ret;
}
-- and here --
As you can see, after the pointers to ret and size, we had two NULL
pointers. This means we didn't want to write anything to the sysctl.
Let's see how to write the sysctl variable:
-- cut here --
#include stdio.h
#include sys/types.h
#include sysctl.h
int main() {
int ret = 1;
int size = sizeof(ret);
sysctlbyname(net.inet.ip.forwarding, NULL, NULL, (void *)ret, size);
return ret;
}
-- and here --
Now execute this proggie as root. After that, issue a 'sysctl
net.inet.ip.forwarding' from the shell. You'll see that the sysctl value
has changed.
Hope this helps. I tried to give the simplest example possible.
|Thanks in advance. Bye
|
|___
|[EMAIL PROTECTED] mailing list
|http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
|To unsubscribe, send any mail to
|[EMAIL PROTECTED]
|
|
|!DSPAM:402b8013604934185311595!
|
|
|
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
pgp0.pgp
Description: PGP signature
kernel land functions
Before grepping through the kernel sources, I thought to ask you guys if you knew any papers regarding kernel space functions, especially memory handling ones. Thanks in advance for any useful links. If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgp0.pgp Description: PGP signature
Re: Dummynet pipes and MRTG
Ganbold [EMAIL PROTECTED] writes: |Hi, | |I need to view the traffic utilization of dummynet pipes in ipfw2. I'm |using FreeBSD 5.2 current. |I'm also using MRTG to draw graphics from ipfw show rule-number |command. Is there any method or program like MRTG to draw bandwidth |utilizations of dummynet pipes? |Can I use MRTG for this purpose? |I hope somebody in this list point me to the right direction. Take a look at RRDTool. There also is a Perl module for drawing RRD graphics, which you could use for fancier stuff. However, some simple shellscripting should do your job. http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ | |thanks in advance, | |Ganbold | |___ |[EMAIL PROTECTED] mailing list |http://lists.freebsd.org/mailman/listinfo/freebsd-hackers |To unsubscribe, send any mail to |[EMAIL PROTECTED] | If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. pgp0.pgp Description: PGP signature
Re: instant message: ymessenger problem
Jose Kulalapnot [EMAIL PROTECTED] writes: |my system is running 5.1 and i installed the latest |ymessenger from the ports. when i run it i get this |message: | |/usr/libexec/ld-elf.so.1: Shared object libintl.so.4 Reinstall gettext and everything that depends on it from scratch. |not found | |how can i fix this? | |__ |__ Want to chat instantly with your online friends? Get the FREE |Yahoo! Messenger http://mail.messenger.yahoo.co.uk |___ |[EMAIL PROTECTED] mailing list |http://lists.freebsd.org/mailman/listinfo/freebsd-hackers |To unsubscribe, send any mail to |[EMAIL PROTECTED] | +---+ |Ana are mere - Abecedar, | | Editura Didactica si Pedagogica, Bucuresti, 1985| +---+ pgp0.pgp Description: PGP signature
Re: instant message: ymessenger problem
Vlad Galu [EMAIL PROTECTED] writes: |Jose Kulalapnot [EMAIL PROTECTED] writes: | ||my system is running 5.1 and i installed the latest ||ymessenger from the ports. when i run it i get this ||message: || ||/usr/libexec/ld-elf.so.1: Shared object libintl.so.4 | | Reinstall gettext and everything that depends on it from scratch. I'm sorry. This wasn't the right answer. I read your message in a hurry, without paying enough atention. The problem is that Y! was linked against gettext 0.11, and your system probably has 0.12. Symlinking libintl.so.4 to libintl.so.5 will probably do the job. | ||not found || ||how can i fix this? || ||__ ||__ Want to chat instantly with your online friends? Get the FREE ||Yahoo! Messenger http://mail.messenger.yahoo.co.uk ||___ ||[EMAIL PROTECTED] mailing list ||http://lists.freebsd.org/mailman/listinfo/freebsd-hackers ||To unsubscribe, send any mail to ||[EMAIL PROTECTED] || | | |+---+ ||Ana are mere - Abecedar, | || Editura Didactica si Pedagogica, Bucuresti, 1985| |+---+ | +---+ |Ana are mere - Abecedar, | | Editura Didactica si Pedagogica, Bucuresti, 1985| +---+ pgp0.pgp Description: PGP signature
Re: instant message: ymessenger problem
Jose Kulalapnot [EMAIL PROTECTED] writes: |tnx Vlad. im now running ymessenger. my id is |buttmanizer. add me if u want. | I would, but your ID sounds scary :) | | | --- Vlad Galu [EMAIL PROTECTED] wrote: Vlad |Galu [EMAIL PROTECTED] writes: | | |Jose Kulalapnot [EMAIL PROTECTED] writes: | | | ||my system is running 5.1 and i installed the | latest | ||ymessenger from the ports. when i run it i get | this | ||message: | || | ||/usr/libexec/ld-elf.so.1: Shared object | libintl.so.4 | | | |Reinstall gettext and everything that depends on | it from scratch. | | I'm sorry. This wasn't the right answer. I read | your message in a | hurry, without paying enough atention. The problem | is that Y! was linked | against gettext 0.11, and your system probably has | 0.12. Symlinking | libintl.so.4 to libintl.so.5 will probably do the | job. | | | | ||not found | || | ||how can i fix this? | || | |__ |__ Want to chat instantly with your online friends? Get the FREE |Yahoo! Messenger http://mail.messenger.yahoo.co.uk |___ |[EMAIL PROTECTED] mailing list |http://lists.freebsd.org/mailman/listinfo/freebsd-hackers |To unsubscribe, send any mail to |[EMAIL PROTECTED] | +---+ |Ana are mere - Abecedar, | | Editura Didactica si Pedagogica, Bucuresti, 1985| +---+ pgp0.pgp Description: PGP signature
Re: HOW TO RETREIVE DATA FROM KERNEL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 30 Aug 2003 21:55:06 -0400 Sandeep Kumar Davu [EMAIL PROTECTED] wrote: Hi, I was wondering how to retreive data from the kernel if I wanna. I want TCP option(if any) to let the application know about that. Can u please tell me if there is any way that I can do it without adding any additional code. If I need to add it sould you please tell me the easiest way to do that. sysctl(3) Sandeep. Sandeep Kumar Davu, M.S. (Computer Science), Kent State University, OH. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] - -- Vlad Galu Network Systems Administrator Romania Data Systems NOC in Bucharest Phone: +40 21 30 10 850 Web:http://www.rdsnet.ro PGP:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x53ABCE97 - Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail. - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD4DBQE/UY9uP5WtpVOrzpcRApt4AJj52TBFrtXkln0QH/E84UQLc9DzAJ9STrRQ h0CPhcTfDtzbHL8a963BeA== =JR7N -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI ID Patch for Intel Ether Express Pro 100 VE (82801BA)
On Thu, 12 Jun 2003 14:14:53 +0300
Tom Alsberg [EMAIL PROTECTED] wrote:
Having got a new machine here a few days ago, an Intel ICH D865 PERL
board based Pentium IV machine, with an on-board Intel EtherExpress
Pro 100 VE, it failed to detect the network adapter.
Seeing that it is an EtherExpress Pro 100, I though the fxp module
should work with it, and found out that the PCI ID (8086:1050) just
isn't recognized as one (new chip or something, apparently).
With the following patch to if_fxp.c:
--- sys/dev/fxp/if_fxp.c.orig Thu Jun 12 14:08:22 2003
+++ sys/dev/fxp/if_fxp.cThu Jun 12 13:29:37 2003
@@ -162,6 +162,7 @@
{ 0x103C, Intel 82801DB (ICH4) Pro/100 Ethernet },
{ 0x103D, Intel 82801DB (ICH4) Pro/100 VE Ethernet },
{ 0x103E, Intel 82801DB (ICH4) Pro/100 VM Ethernet },
+{ 0x1050, Intel 82801BA (D865) Pro/100 VE Ethernet },
{ 0x1059, Intel 82551QM Pro/100 M Mobile Connection },
{ 0x1209, Intel 82559ER Embedded 10/100 Ethernet },
{ 0x1229, Intel 82557/8/9 EtherExpress Pro/100(B)
Ethernet },
it seems to work. I am not sure how reliable it is and whether other
modifications should be made, but it worked fine for now.
Of course, the ID string is also perhaps not the best - perhaps it
needs to be changed.
Anyway, I would like it to be added to the driver, so new machines
with that adapter will work out of the box. Should I submit this
trivial patch to anywhere else, or can it be picked up from this list?
You should check send-pr(1). Thanks for the contribution!
BTW, I had the same story with Linux (that's what they wanted on it, I
was just diagnosing the problem) before, and a similar change to the
Linux eepro100 driver worked as well - had it worked with Linux out of
the box, I wouldn't probably try FreeBSD on it...
Thanks,
-- Tom
--
Tom Alsberg - hacker (being the best description fitting this space)
Web page: http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER: The above message does not even necessarily represent
what my fingers have typed on the keyboard, save anything further.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED]
--
Vlad GALU
Network Administrator VipNET Bucharest
tel: 021/3039940
email: [EMAIL PROTECTED]
web: http://www.vipnet.ro
PGP: http://mirapoint.vipnet.ro/public_key.pgp
pgp0.pgp
Description: PGP signature
Re: Policy Routing / NAT Question
On 11 Jun 2003 08:55:53 -0400 Ryan Wilkins [EMAIL PROTECTED] wrote: Hello.. I'm setting up a TCP protocol testbed for testing various enhanced TCP stacks for use over high bandwidth, high latency links such as Satellite. Due to hardware limitations of the FreeBSD boxes we're using(1U rackmount), there are no expansion slots left for additional network cards. This forces me to have to run some traffic over one gateway and the rest of the traffic over another gateway, all through one ethernet. The problem I have is I need to change the source address of some packets based on destination address. I was able to accomplish this in Linux using Source NAT. I'm not real well versed in FreeBSD hence the reason I'm asking for any assistance here. Does anyone have an idea how to change the source address based on destination address? yes. in the ipnat configuration file you should write something like this: map interface from source to destination - nat address one thing though ... I've noticed the kernel trying to send the packets on the default gateway, no matter what the nat address was. So I used ipfw as well, for policy routing of nat'ed packets. I might have done something wrong as well, I really don't know, but searching the newsgroups archives I found no answer at all, and this seemed to be the only option. Thanks in advance for any help. Ryan Wilkins ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Vlad GALU Network Administrator VipNET Bucharest tel: 021/3039940 email: [EMAIL PROTECTED] web: http://www.vipnet.ro PGP: http://mirapoint.vipnet.ro/public_key.pgp pgp0.pgp Description: PGP signature
Re: Is BSD a Linux operating system?
On Tue, 10 Jun 2003 09:17:05 +0200 (CEST) Soeren Straarup [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Take a look at this: ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree or /usr/share/misc/bsd-family-tree Best regards Søren ** | Soeren Straarup Mobile: +45 20 27 62 44 | | FreeBSD wannabe since 2.2.6-Rhttp://xforce.dk | | Also running OpenBSD and NetBSD aka OZ2DAK aka Xride | ** On Tue, 10 Jun 2003, Danny Braniss wrote: http://www.linuxiso.org/ and now back to our local programming, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+5YX1XTGeGCdlN14RAnj8AJ4n0Hw/O7CR2lamH6HweY7KKUjPDQCffIBL ZtPT7P2PnyNkbQ1EFNmTDwg= =zPIr -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Vlad GALU - aka mira- : Network Administrator VipNET Bucharest tel: 021/3039940 email: [EMAIL PROTECTED] web: http://www.vipnet.ro PGP: http://mirapoint.vipnet.ro/public_key.pgp pgp0.pgp Description: PGP signature
