getifaddrs(3), ifa_data field
I noticed that the getifaddrs(3) library function doesn't behave as described in the manpage. The manpage says: The ifa_data field references address family specific data. For AF_LINK addresses it contains a pointer to the struct if_data (as defined in include file ) which contains various interface attributes and statistics. This is correct and works. For all other address families, it contains a pointer to the struct ifa_data (as defined in include file ) which contains per‐address interface statistics. This is not what I'm seeing. First, I can't find a struct ifa_data definition, and second, the ifa_data field seems to be NULL for all address types other than AF_LINK. I'm thinking there are three possible explanations for this behaviour: - I need to set some non-default option to enable the ifa_data field for non-AF_LINK addresses. - There's a regression; the ifa_data field should contain data for non-AF_LINK addresses but no longer does. - The behaviour is correct, but the manpageis outdated. Please give me a bit more background information on this issue. Cheers Benjamin ___ 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: Some FreeBSD performance Issues
Randall Hyde wrote:
> Hi All,
>
> I recently ported my HLA (High Level Assembler) compiler to FreeBSD and,
> along with it, the HLA Standard Library. I have a performance-related
> question concerning file I/O.
>
> It appears that character-at-a-time file I/O is *exceptionally* slow. Yes, I
> realize that when processing large files I really ought to be doing
> block/buffered I/O to get the best performance, but for certain library
> routines I've written it's been far more convenient to do
> character-at-a-time I/O rather than deal with all the buffering issues. In
> the past, while slower, this character-at-a-time paradigm has provided
> reasonable, though not stellar, performance under Windows and Linux.
> However, with the port to FreeBSD I'm seeing a three-orders-of-magnitude
> performance loss. Here's my little test program:
>
> program t;
> #include( "stdlib.hhf" )
> //#include( "bsd.hhf" )
>
> static
> f :dword;
> buffer :char[64*1024];
>
> begin t;
>
> fileio.open( "socket.h", fileio.r );
> mov( eax, f );
> #if( false )
>
> // Windows: 0.25 seconds
> // BSD: 5.2 seconds
>
> while( !fileio.eof( f )) do
>
> fileio.getc( f );
> //stdout.put( (type char al ));
>
> endwhile;
>
> #elseif( false )
>
> // Windows: 0.0 seconds (below 1ms threshold)
> // BSD: 5.2 seconds
>
> forever
>
> fileio.read( f, buffer, 1 );
> breakif( eax <> 1 );
> //stdout.putc( buffer[0] );
>
> endfor;
>
> #elseif( false )
>
> // BSD: 5.1 seconds
>
> forever
>
> bsd.read( f, buffer, 1 );
> breakif( @c );
> breakif( eax <> 1 );
> //stdout.putc( buffer[0] );
>
> endfor;
>
> #else
>
> // BSD: 0.016 seconds
>
> bsd.read( f, buffer, 64*1024 );
> //stdout.write( buffer, eax );
>
> #endif
>
> fileio.close( f );
>
> end t;
>
> (I selectively set one of the conditionals to true to run a different test;
> yeah, this is HLA assembly code, but I suspect that most people who can read
> C can *mostly* figure out what's going on here).
>
> The "fileio.open" call is basically a bsd.open( "socket.h", bsd.O_RDONLY );
> API call. The socket.h file is about 19K long (it's from the FreeBSD
> include file set). In particular, I would draw your attention to the first
> two tests that do character-at-a-time I/O. The difference in performance
> between Windows and FreeBSD is dramatic (note: Linux numbers are comparable
> to Windows). Just to make sure that the library code wasn't doing something
> incredibly stupid, the third test makes a direct FreeBSD API call to read
> the data a byte at a time -- the results are comparable to the first two
> tests. Finally, I read the whole file at once, just to make sure the problem
> was character-at-a-time I/O (which obviously is the problem). Naturally, at
> one point I'd uncommented all the output statements to verify that I was
> reading the entire file -- no problem there.
>
> Is this really the performance I can expect from FreeBSD when doing
> character I/O this way? Is is there some tuning parameter I can set to
> change internal buffering or something? From this numbers, if I had to
> guess, I'd suspect that FreeBSD was re-reading the entire 4K (or whatever)
> block from the file cache everytime I read a single character. Can anyone
> explain what's going on here? I'm loathe to change my fileio module to add
> buffering as that will create some subtle semantic differences that could
> break existing code (I do have an object-oriented file I/O class that I'm
> going to use to implement buffered I/O, I would prefer to leave the fileio
> module unbuffered, if possible).
>
> And a more general question: if this is the way FreeBSD works, should
> something be done about it?
> Thanks,
> Randy Hyde
Hello Randy,
First, let me out myself as a fan of yours. It was your book that got me
started on ASM and taught me a lot about computers and logic, plus it
provided some entertainment and mental sustenance in pretty boring
times, so thanks!
Now, as for your problem: I think I have to agree with the others in
this thread when they say that the problem likely isn't in FreeBSD. The
following C program, which uses the read(2) call to read socket.h
byte-by-byte, runs quickly (0.05 secs on my 2.1GHz system, measured with
time(1)):
#include
#include
#include
#include
#include
#include
int main(int argc, char** argv) {
int f;
char c;
ssize_t result;
f = open("/usr/include/sys/socket.h", O_RDONLY);
if (f < 0) { perror("open"); exit(1); }
do {
result = read(f, &c, 1);
if (result < 0) { perror("read"); exit(1); }
//printf("%c", c);
} while (result >= 1);
return 0;
}
This should be quite equivalent to your second and third code fragment;
it does one read system call per byte, no buffering involved. This leads
me to bel
Re: rc functions don't allow processes to shutdown
On Friday 31 August 2007 18:51:23 Sean Bruno wrote: > Tobias Roth wrote: > > Sean Bruno wrote: > >> I noticed that if rc.conf has ntpd_enable="NO", an invocation of > >> /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a > >> couple of other processes(like net-snmp) and noted the same > >> behavior. > >> > >> I would have expected that rc would be able to invoke the stop > >> routines if a utility is disabled, but apparently the check for > >> enabled/disabled occurs much too early in the rc handling > >> functions for the stop to fire off. > >> I could investigate further, as I am sure that it's a fairly easy > >> fix to allow the stop functions to be invoked regardless of the > >> enable/disable state. > >> Does it make sense to anyone else that the rc functions should be > >> able to shutdown a process when it has been disabled in rc.conf? > > > > /etc/rc.d/ntpd forcestop > > Indeed one could invoke that. My question is more about what 'stop' > should or should not do. > > Specifically, should it 'stop' when a process has been disabled? Consider this: all init scripts are called with stop on shutdown. If stop always does something, then you'll have many init scripts trying to stop processes that aren't actually running. While this shouldn't hurt the system too much, other than slightly slowing down a shutdown, it doesn't feel like clean design to me. Nor would adding an rc.d-internal-stop. forcestop is a good solution for this issue imo. Cheers Benjamin signature.asc Description: This is a digitally signed message part.
Re: SoC: Distributed Audit Daemon project
On Saturday 26 May 2007 09:49, Alexey Mikhailov wrote: > On Friday 25 May 2007 22:04:34 Benjamin Lutz wrote: > > On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote: > > > [...] > > > 2. As I said before initial subject of this project was > > > "Distributed audit daemon". But after some discussions we had > > > decided that this project can be done in more general maner. We > > > can perform distributed logging for any user-space app. > > > [...] > > > > This sounds very similar to syslogd. Is it feasible to make dlogd a > > drop-in replacement for syslogd, at least from a > > syslog-using-program point of view? > > Our project concentrates on log shipping. We're paying most attention > to securely and reliable log ships. So our project differs from > syslogd in major way. > > But actually it could be possible to be dlogd used by > syslogd\syslog-ng for logs shipping, as I see it. The thing that bugs me most about syslog is not even the transport to remote syslogd instances; that's relatively easy to fix (put some SSL between the daemons, or use encrypted tunnels, etc). It's that when a process logs a syslog event, it can claim to be anything at all. Iirc, it can even give a bogus timestamp. So what I was hoping for here is for auditd to come with a hook that intercepts syslog(3) calls, adds/validates pid, process name and timestamp, and then puts that information somewhere (some local log, a remote log, a lineprinter). It doesn't even have to give the information back to a syslogd daemon; whatever auditd uses for itself would be fine too. What I'm hoping for here is some way to get a guarantee that the information in a log is actually correct. The way it is at the moment, syslog messages are way too trivial to spoof. Anyway, this is just a feature wish :) I'm happy to see you work on auditd, whether or not it contains these syslog bits. Cheers Benjamin pgpawCcXyt3p8.pgp Description: PGP signature
Re: SoC: Distributed Audit Daemon project
On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote: > [...] > 2. As I said before initial subject of this project was "Distributed > audit daemon". But after some discussions we had decided that this > project can be done in more general maner. We can perform distributed > logging for any user-space app. > [...] This sounds very similar to syslogd. Is it feasible to make dlogd a drop-in replacement for syslogd, at least from a syslog-using-program point of view? Cheers Benjamin signature.asc Description: This is a digitally signed message part.
Re: PAPI for FreeBSD
On Friday 18 May 2007 12:38, Harald Servat wrote: > I'm searching some testers for my first version of the port because > I'm only able to test it on my laptop (FreeBSD 6.2 / Pentium M) and > it would be great to test it in other kind of processors (now it's > only supported on Pentium 2/3/4/Celeron AMD K7/8) before releasing it > (and providing my patches to PAPI developers). > Anyone interested on doing this test, please, send me an email and > I'll reply you with some instructions to follow. I've got a Core 2 Duo/Asus P5B Deluxe system here running FreeBSD 6.2 here. If that's useful to you I'm willing to do some tests. Cheers Benjamin pgpAcFUFpux6o.pgp Description: PGP signature
Re: DPS Initial Ideas
On Sunday 13 May 2007 23:00, Thomas Sparrevohn wrote: > The on-disk format seems to be the wrong angle on the issue - The > current structure Works well - but it has a number of drawbacks - > however it no way clear whether that The answer is another > INDEX/storage structure When coming up with ideas what to change INDEX's storage method to, just keep in mind that - There is very little flexibility whatsoever in the way data is stored in the file. Each entry in the INDEX has its 13 or so fields, and that's it. One of the strengths of XML, self-descriptiveness for very dynamic data structures, doesn't matter for INDEX. Basically, imho, using XML for tabular data = bad. - INDEX exists for speed. Accessing the information in it should be as fast as possible. I object to any change that increases the time needed to search for and parse INDEX entries. I've written a little searching tool (it can be found ports-mgmt/psearch). If INDEX were to be converted to XML, just because of that it would be considerably slower. If psearch then were to use standard XML parsing libs, the slowdown would probably be at least an order of magnitude. If there's any change to INDEX's format, it should make access faster, not slower. A format that allows constant-time random access would be nice, for example. - INDEX does not need to be portable. It'll be used on FreeBSD systems only, and by tools written specifically for the ports system. The second point is most important here. This whole thread exists because people consider the existing ports system to be too slow. How is using XML going to help with that at all? Cheers Benjamin pgpGi87Nxjxzf.pgp Description: PGP signature
Re: DPS Initial Ideas
On Sunday 13 May 2007 13:58, Thomas Sparrevohn wrote: > Using XML for INDEX are a very good idea mainly because it allows > "ports" to interface in an easy way to external tools - e.g. java > frontends - web browsers etc, etc. However there are drawbacks - Yet > I feel that the discussion about what tool to use as indexing are > completely misplaced if the only point is that somebody likes SQL > better than a directory tree. I'd have said that using XML for INDEX is a bad idea, because INDEX can then no longer be easily processed with any of the tools in the FreeBSD base system. With the format it uses now, I can easily grep, awk, etc it. If you need an XML version of INDEX, it's easy to have just these tools build one for you though. Not to mention that INDEX is already big enough as it is, imo. I don't see why it should be bloated even more with redundant information. Cheers Benjamin pgpF3kKFk5ixu.pgp Description: PGP signature
man(1) and locale codeset
Hello, While investigating how to get proper quotes in manpages (proper as explained here: http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html) I found that groff outputs correct quote characters (well, for single quotation marks anyway) with -Tutf8. When looking at the man(1) source code, I saw that the code contains support for specifying a -T parameter based on the codeset of the LC_ALL environment variable. See for example in /usr/src/gnu/usr.bin/man/man/man.c: - line 99, definition of ltable. - line 956, appending of -T parameter to parameter list based on locale_opts. However, lines 1645-1646 and 1697-1698 (my src tree is from FreeBSD 6.2, in case the lines differ look for "locale_opts = NULL") disable locale codeset support completely, which cause man to revert to -Tascii. If I comment out those 4 lines, I get UTF-8 manpages with correct single quote characters. What is the reason behind disabling locale support like this? Could this be changed? Cheers Benjamin pgpB3EIA2Y3tt.pgp Description: PGP signature
Re: RFC 919 compliance (broadcasts to 255.255.255.255)
On Saturday 05 August 2006 07:18, you wrote: > On Fri, 4 Aug 2006, Benjamin Lutz wrote: > > Hello, > > > > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter > > 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle > > IP packets with a destination address of 255.255.255.255 properly. > > > > 255.255.255.255 is a "limited broadcast address" (the term is not > > mentioned in the RFC, but seems to be in use everywhere else). An IP > > packet send to that address should be broadcast to the whole IP subnet of > > the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does > > not work, as is evident by this tcpdump output: > > > > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 > > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id > > 33319, seq 0, length 64 > > > > The destination MAC address is that of my gateway, but it should be > > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip > > proto 1" and "ping 255.255.255.255". > > > > I found a discussion from 2003 about this, but it seems to have trailed > > off without coming to a conclusion: > > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > > > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The > > intention seems to be to enable packets to 255.255.255.255. However a > > test with a small program showed that this option seems to have no > > effect, outgoing packets still carried the gateway's MAC address as > > destination. > > > > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as > > broadcasts. > > > > Now, is this behaviour intentional? Is there a way to turn on RFC 919 > > compliance? If not, would someone be willing to add this to the kernel? > > Should I submit a PR? > > Does this feature really necessary? For waht purpose? I discovered it when playing with Wake-on-LAN packets. It is possible to send those with the real subnet's broadcast address, but then you first have to figure that one out. If you have a network device that doesn't have an IP configured yet, it would not know the subnet broadcast address. > I believe this feature is more harmful than useful. Please elaborate. Remember that routers do not pass on packets to 255.255.255.255. The TTL is effectively 1. Cheers Benjamin pgpa6Ook32YFw.pgp Description: PGP signature
RFC 919 compliance (broadcasts to 255.255.255.255)
Hello, I've noticed that FreeBSD does not by default comply to RFC 919, Chapter 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle IP packets with a destination address of 255.255.255.255 properly. 255.255.255.255 is a "limited broadcast address" (the term is not mentioned in the RFC, but seems to be in use everywhere else). An IP packet send to that address should be broadcast to the whole IP subnet of the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does not work, as is evident by this tcpdump output: 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id 33319, seq 0, length 64 The destination MAC address is that of my gateway, but it should be ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip proto 1" and "ping 255.255.255.255". I found a discussion from 2003 about this, but it seems to have trailed off without coming to a conclusion: http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The intention seems to be to enable packets to 255.255.255.255. However a test with a small program showed that this option seems to have no effect, outgoing packets still carried the gateway's MAC address as destination. Btw, Linux and NetBSD both handle packets to 255.255.255.255 as broadcasts. Now, is this behaviour intentional? Is there a way to turn on RFC 919 compliance? If not, would someone be willing to add this to the kernel? Should I submit a PR? Cheers Benjamin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
