Files in C.
I know that this is not the place to consult on programming C. But I am so enthusiastic in FreeBSD that I want to learn more on the language C and someday coming to be a small part of which you already are. It wanted that they recommended to me some webpage where to be able to obtain information on files in C. I want to learn well to work with Files. I need to know the best place where to obtain information and I know that you know it. Bye and very very thanks. PD. thousand excuses by my terrible English. they say that more idiot is the one than does not ask. Dicen que más tonto es aquél que no pregunta. -- Concepción, Chile. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
EPERM from write()
I'm down in the bowels of chasing a weird bug that is being presented
by sendmail when doing TLS. For *some* clients it works, but for the
ones that fail, they fail hard.
There are various weird things in my analyses.
The proximate symptom is that the call to write() to put out the
ServerHello message returns -1, errno 1 (EPERM), but I can see from
the tcpdump trace that most (all?) of it got out. Looking backwards
through the ktrace reveals that the fd that is being written to (fd 4)
is the fd that the Ready to start TLS message went out on, and that
(previous) write completed successfully.
Here's the ktrace from that successful write to the one that
blew up, sans numerous calls to gettimeofday and getpid:
35388 sendmail GIO fd 4 wrote 30 bytes
220 2.0.0 Ready to start TLS\r
35388 sendmail RET write 30/0x1e
35388 sendmail CALL fcntl(0x8,0x3,0)
35388 sendmail RET fcntl 2
(get flags on fd 8)
35388 sendmail CALL fcntl(0x8,0x4,0x6)
35388 sendmail RET fcntl 0
(set O_NONBLOCK on fd 8)
35388 sendmail CALL break(0x8191000)
35388 sendmail RET break 0
35388 sendmail CALL break(0x8196000)
35388 sendmail RET break 0
35388 sendmail CALL read(0x8,0x8188000,0xb)
35388 sendmail RET read -1 errno 35 Resource temporarily unavailable
35388 sendmail CALL select(0x9,0xbfbfbe00,0,0xbfbfb850,0xbfbfb648)
35388 sendmail RET select 1
35388 sendmail CALL read(0x8,0x8188000,0xb)
(Here's the ClientHello)
35388 sendmail GIO fd 8 read 11 bytes
0x 807c 0103 0100 6300 10|.|c|
35388 sendmail RET read 11/0xb
35388 sendmail CALL read(0x8,0x818800b,0x73)
(and the rest of the ClientHello, with all the cipher suites)
35388 sendmail GIO fd 8 read 115 bytes
0x 3900 0038 3500 0016 1300 000a 0700
|..9..8..5...|
0x0014 c000 0033 3200 002f 0300 8000 0066 0500
|...3..2../.f|
0x0028 0004 0100 8008 0080 6300 0062 6100 0015
|..c..b..a...|
0x003c 1200 0009 0600 4000 0065 6400 0060 |[EMAIL
PROTECTED]|
0x0050 1400 0011 0800 0006 0400 8000 0003 0200 804d
|...M|
0x0064 57e4 2a11 c967 1804 e745 7cfc a991 93
|W.*..g...E||
35388 sendmail RET read 115/0x73
35388 sendmail CALL break(0x8197000)
35388 sendmail RET break 0
35388 sendmail CALL break(0x8198000)
35388 sendmail RET break 0
(here's the write that fails, but I see all 0xa59 bytes on the wire!)
35388 sendmail CALL write(0x4,0x8174000,0xa59)
35388 sendmail RET write -1 errno 1 Operation not permitted
(And just for fun the syslog that comes out, too.)
35388 sendmail CALL sendto(0x3,0xbfbfa4d0,0x6d,0,0,0)
35388 sendmail GIO fd 3 wrote 109 bytes
20May 2 23:16:25 sm-mta[35388]: STARTTLS=server, error: accept
failed=-1, SSL\
_error=5, timedout=0, errno=1
35388 sendmail RET sendto 109/0x6d
I'm really kind of puzzled at this point. Why would I get -1/EPERM
on an apparently completed write?
The box is 5.4-STABLE, fresh cvsup as of 2 May 05 17:47 GMT. I
forced a rebuild of the SASL stuff (cyrus-sasl-2.1.20_1 and
cyrus-sasl-saslauthd-2.1.20_1) , and then rebuilt sendmail again.
I've got the following in my make.conf re: sendmail building:
SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2
SENDMAIL_CFLAGS+=-D_FFR_SMTP_SSL
SENDMAIL_LDFLAGS+=-L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
The client machine appears to be running 8.13.1.
What I see in the tcpdump disassembly (thanks to Ethereal!) is
(paraphrased)
{client} {mybox} TCP S
{mybox} {client} TCP SA
{client} {mybox} TCP A
{mybox} {client} TCP A seq=1 ack=1 len=89 220 {mybox} ESMTP Sendmail
8.13.3/8.13.3 (+date)
{client} {mybox} TCP A seq=1 ack=90 len=0
{client} {mybox} TCP A seq=1 ack=90 len=24 EHLO {client}\r\n
{mybox} {client} TCP A seq=90 ack=25 len=226 ESMTP options menu, includes
STARTTLS
{client} {mybox} TCP A seq=25 ack=316 len=0
{client} {mybox} TCP A seq=25 ack=316 len=10 STARTTLS\r\n
{mybox} {client} TCP A seq=316 ack=35 len=30 220 Ready to start TLS\r\n
{client} {mybox} TCP A seq=35 ack=346 len=0
{client} {mybox} TCP A seq=35 ack=346 len=126
SSLv2 Record len 124
Handshake: ClientHello, TLS 1.0, gaggle of cipher
suites, no resume session, 16 byte challenge
{mybox} {client} TCP A seq=346 ack=161 len=1448
TLS Record Handshake (22) TLS 1.0 (0x0301) len 74
Handshake: ServerHello (2), random, cipher suite
TLS_DHE_RSA_WITH_AES256_CBC_SHA, no compression
TLS Record Handshake (22) TLS 1.0 len 2184
Handshake: Certificate pile (first segment)
{client} {mybox} TCP A seq=161 ack=1794 len=0
{mybox} {client} TCP FPA seq=1796 ack=161 len=1199
Continuation of certificate pile
TLS Record Handshake (22) TLS 1.0
Re: A question about /sys/kern/link_elf.c
On Monday 02 May 2005 13:35, [EMAIL PROTECTED] wrote: There is a #ifdef SPARSE_MAPPING at line 701,and again a #ifdef SPARSE_MAPPING at line 713.I just can't understand the second one.Does it have any special mean ? thanks . It's just conditional compiling construct...however as you can see in the tag For whatever reason, SPARSE_MAPPING is not even a config option, so this is dead code. It dates back to a tools problem that I had on the alpha where the linker would round up the size of the text segment to the next megabyte boundary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
mergemaster improvement (auto-update for not modified files)
Hello!
The mergemaster with this is test patch (attached)
can auto-update files that was not modified.
It do this by compairing each file with it's CVS
copy. If file was not modified, it can be rewritten.
This dramatically redices amount of files that require
admin's attention.
There is one major problem here:
This can be done in single-user mode only if your
have local CVS repository, because if local CVS is
not exist, anoncvs is used.
Possible solutions:
1. Pre-checkout files in pre-buildworld mode.
2. Setup CVSup collection for subset of required files
(is it possible?), and then keep this small collection
up-to-date locally.
3. Store checksum for every config file installed,
then compare with this checksum on updating.
BTW, tracking checksums can be very useful for
base system too, because checksums can help to do
clean updates (with removal of old files that was not
overwritten).
Index: mergemaster.sh
===
RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.51
diff -u -r1.51 mergemaster.sh
--- mergemaster.sh 7 Mar 2004 10:10:19 - 1.51
+++ mergemaster.sh 3 May 2005 09:21:38 -
@@ -224,6 +224,15 @@
#
TEMPROOT='/var/tmp/temproot'
+TEMPCVS=`mktemp -q -d -t $(basename $0)`
+CVS_SKIP=''
+
+# Only one variable for the list of sites. Should be improved.
+CVS_LOGGED_IN=0
+
+CVSLIST=:pserver:[EMAIL PROTECTED]:/home/ncvs
+ :pserver:[EMAIL PROTECTED]:/home/ncvs
+
# Read /etc/mergemaster.rc first so the one in $HOME can override
#
if [ -r /etc/mergemaster.rc ]; then
@@ -871,7 +880,7 @@
# If the files have the same $Id, delete the one in temproot so the
# user will have less to wade through if files are left to merge by hand.
#
-CVSID1=`grep [$]${CVS_ID_TAG}: ${DESTDIR}${COMPFILE#.} 2/dev/null`
+CVSID1=`grep [$]${CVS_ID_TAG}: ${DESTDIR}${COMPFILE#.} 2/dev/null` ||
CVSID1=''
CVSID2=`grep [$]${CVS_ID_TAG}: ${COMPFILE} 2/dev/null` || CVSID2=none
case ${CVSID2} in
@@ -879,6 +888,60 @@
echo *** Temp ${COMPFILE} and installed have the same CVS Id, deleting
rm ${COMPFILE}
;;
+*)
+ # Checking file for changes against CVS
+ if [ ! -z ${CVSID1} -a -z ${CVS_SKIP} ]
+ then
+ CVSFILE=`echo ${CVSID1} | awk '{print $3}' | sed 's/,v$//'`
+ CVSVERSION=`echo ${CVSID1} | awk '{print $4}'`
+
+ echo *** Checking ${COMPFILE#.} against CVS
+ (cd ${TEMPCVS} cvs -Rq co -r ${CVSVERSION} ${CVSFILE} /dev/null
21) || \
+ for CVSROOT in ${CVSLIST}
+ do
+ if [ ${CVS_LOGGED_IN} -eq 0 ]; then
+ echo *** Enter 'anoncvs' password below
+ cvs -Rqd ${CVSROOT} login CVS_LOGGED_IN=1
+ fi
+ (cd ${TEMPCVS} cvs -Rqd ${CVSROOT} co -r ${CVSVERSION} ${CVSFILE}
/dev/null 21 continue)
+ done
+ case ${AUTO_RUN} in
+ '')
+ if [ $? -ne 0 ]; then
+ echo ${COMPFILE} can't be checked against CVS
+ echo -n Do you wish skip CVS checking for remaining files? y or n
[y]
+ read CVS_SKIP
+
+ echo 1 $CVS_SKIP 1
+
+ case $CVS_SKIP in
+ [Nn])
+ CVS_SKIP=''
+ ;;
+ *)
+ CVS_SKIP='y'
+ echo *** Skip CVS checking for remaining files
+ ;;
+ esac
+ fi
+ ;;
+ *)
+ echo *** Skip CVS checking for remaining files
+ ;;
+ esac
+
+
+ if diff -q ${DIFF_OPTIONS} ${DESTDIR}${COMPFILE#.}
${TEMPCVS}/${CVSFILE} \
+ /dev/null 21; then
+ if mm_install ${COMPFILE}; then
+ echo *** ${COMPFILE} installed successfully
+ else
+ echo *** Problem installing ${COMPFILE}, it will remain to merge
by hand
+ fi
+fi
+ rm -f ${TEMPCVS}/${CVSFILE}
+ fi
+;;
esac
;;
esac
@@ -926,6 +989,9 @@
echo ''
fi
+# How safe it is?
+rm -rf ${TEMPCVS}
+
case ${AUTO_RUN} in
'')
echo -n Do you wish to delete what is left of ${TEMPROOT}? [no]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
On Tue, May 03, 2005 at 01:27:09PM +0400, Denis Peplin wrote: The mergemaster with this is test patch (attached) can auto-update files that was not modified. It do this by compairing each file with it's CVS copy. If file was not modified, it can be rewritten. This dramatically redices amount of files that require admin's attention. There is one major problem here: This can be done in single-user mode only if your have local CVS repository, because if local CVS is not exist, anoncvs is used. Possible solutions: What about mergemaster storing a copy of the original somewhere on disk for usage next time? Then the first run may still be slow, but following runs will be able to use it. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
John Hay wrote: On Tue, May 03, 2005 at 01:27:09PM +0400, Denis Peplin wrote: There is one major problem here: This can be done in single-user mode only if your have local CVS repository, because if local CVS is not exist, anoncvs is used. Possible solutions: What about mergemaster storing a copy of the original somewhere on disk for usage next time? Then the first run may still be slow, but following runs will be able to use it. Every variant based on storing some files somewhere. I'm just don't know wich variant is best (but it seems that improving mergemaster -p is easiest way). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Files in C.
Hi, Pablo Mora wrote: I know that this is not the place to consult on programming C. But I am so enthusiastic in FreeBSD that I want to learn more on the language C and someday coming to be a small part of which you already To get this a bit in line with FreeBSD: FreeBSD comes with the GNU compiler which also has a C frontend. Just get more information from www.gnu.org for their gcc. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE corrupting fs on shutdown -p now?
On Mon, 2 May 2005, c0ldbyte wrote: I have a HDD Post Write Buffer in the BIOS according to the MB manual although the disks aren't connected to the MB controllers they are on RAID 5 set off a PCI-X card. Will give it a go tomorrow ( drag the monitor back to the rack ). Will this have any performance penalties? I could just avoid using shutdown -p but it seems a bit dodgy what its doing. If this machine where miles away without remote console it would have caused major amounts of pain. Why would you use shutdown -p on a remote machine anyway. I could see possibly a shutdown -r but -p come on. I use it regularly -- for remote boxes that are in someone else's facility, I'd much rather I was the one who powered them off and told them when they were ready to unplug than having them do it. Life is a bit better with the advent of soft power via case power buttons, but still... Robert N M Watson I _always_ use it, specialy when the box in question is headless, or via KVM, or im too lazy to get up and switch the power off :-) danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A question about /sys/kern/link_elf.c
thanks for all your responses.I know that it is just conditional compiling construct,but I just can't understand the nested *test* of SPARSE_MAPPING( the 2nd #ifdef ... is nested in the 1st one). Thanks .I think I get it now. On Monday 02 May 2005 13:35, gerarra at tin.it wrote: There is a #ifdef SPARSE_MAPPING at line 701,and again a #ifdef SPARSE_MAPPING at line 713.I just can't understand the second one.Does it have any special mean ? thanks . It's just conditional compiling construct...however as you can see in the tag For whatever reason, SPARSE_MAPPING is not even a config option, so this is dead code. It dates back to a tools problem that I had on the alpha where the linker would round up the size of the text segment to the next megabyte boundary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 May 2005, Denis Peplin wrote: Hello! The mergemaster with this is test patch (attached) can auto-update files that was not modified. It do this by compairing each file with it's CVS copy. If file was not modified, it can be rewritten. This dramatically redices amount of files that require admin's attention. There is one major problem here: This can be done in single-user mode only if your have local CVS repository, because if local CVS is not exist, anoncvs is used. Possible solutions: 1. Pre-checkout files in pre-buildworld mode. 2. Setup CVSup collection for subset of required files (is it possible?), and then keep this small collection up-to-date locally. 3. Store checksum for every config file installed, then compare with this checksum on updating. BTW, tracking checksums can be very useful for base system too, because checksums can help to do clean updates (with removal of old files that was not overwritten). IMHO this isnt something that should be included with mergemaster due to the following things. 1). It should upgrade a file if the files cvs id doesnt match and provide you with a merge option, which it allready does both of those as it is now. 2). Only upgrading files that havent been changed is going to result in a positive false situation where the user actually thinks that his/her system has been fully upgraded and when in fact it hasnt, leaving added lines to files out where they should have been merged in. Preferably also IMHO this patch to mergemaster should be or would be better off renamed to another project and/or an option for people to compile into the system if they wish to have that kind of functionality. E.g: System/Addon for world through the use of a set variable in /etc/make.conf.local or something similiar. But with all due respect, This just seems like another case of a Bike Shed incident. Best regards to humor. --c0ldbyte - -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F iD8DBQFCd223smFQuvffl58RAtAXAJ4+2oKEilJOWvOY2IncqbX3sjTYSwCfXe8b 5UCgbuWk6dsHkJBZb+t8YtA= =070g -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Files in C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 May 2005, Pablo Mora wrote: I know that this is not the place to consult on programming C. But I am so enthusiastic in FreeBSD that I want to learn more on the language C and someday coming to be a small part of which you already are. It wanted that they recommended to me some webpage where to be able to obtain information on files in C. I want to learn well to work with Files. I need to know the best place where to obtain information and I know that you know it. Bye and very very thanks. PD. thousand excuses by my terrible English. they say that more idiot is the one than does not ask. Dicen que más tonto es aquél que no pregunta. Also check out ( http://www.accu.org/ ) they have great documentation and book reviews and a pretty strong orginization as well with mailing lists and as well stuff for disabled people. Plus Plus a mentored developer projects section that you may want to become involved in. http://www.freenode.net/ as well as http://www.dal.net/ is home to a pretty well respectable IRC group of participating channels that may also beable to help you more on this subject. Ofcourse youll prolly find tons of IRC channels on many networks that are roughly about the very same thing but Im not going to go through the trouble of listing them all. Best of luck, --c0ldbyte - -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F iD8DBQFCd3CssmFQuvffl58RAtteAJ4p05jcT4XlaZNb1cn9h3zs+A2QoQCfZc+w v1byU8lBg62QVNZomG86zsA= =fC4e -END PGP SIGNATURE-___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE corrupting fs on shutdown -p now?
So sounds like this does need a bit of looking at. The key thing is both reboot and halt always leave the machine FS in a good state where as shutdown -p doesnt so is there something that -p skips? Or is it simply the fact that it powers down? Steve - Original Message - From: Danny Braniss [EMAIL PROTECTED] I have a HDD Post Write Buffer in the BIOS according to the MB manual although the disks aren't connected to the MB controllers they are on RAID 5 set off a PCI-X card. Will give it a go tomorrow ( drag the monitor back to the rack ). Will this have any performance penalties? I could just avoid using shutdown -p but it seems a bit dodgy what its doing. If this machine where miles away without remote console it would have caused major amounts of pain. Why would you use shutdown -p on a remote machine anyway. I could see possibly a shutdown -r but -p come on. I use it regularly -- for remote boxes that are in someone else's facility, I'd much rather I was the one who powered them off and told them when they were ready to unplug than having them do it. Life is a bit better with the advent of soft power via case power buttons, but still... Robert N M Watson I _always_ use it, specialy when the box in question is headless, or via KVM, or im too lazy to get up and switch the power off :-) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.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]
Re: ipfw causing panic 4.11-RELEASE-p4
On Mon, 2 May 2005, 13:20+0300, Imri Zvik wrote: Hi, I was playing around with ipfw, and when I tried something like: /sbin/ipfw disable firewall /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 applying some rules /sbin/ipfw enable firewall The machine paniced: Mine doesn't: shy# uname -a FreeBSD shy.macomnet.ru 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Apr 21 05:48:09 MSD 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 shy# /sbin/ipfw disable firewall shy# /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 Are you sure? [yn] y Flushed all rules. net.inet.ip.fw.dyn_buckets: 256 - 600 shy# ipfw add 1 allow all from any to any 1 allow ip from any to any shy# /sbin/ipfw enable firewall Could you show your rules? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw causing panic 4.11-RELEASE-p4
On Tue, 3 May 2005, 17:49+0300, Imri Zvik wrote: I forgot to mention I was using ipfw1. When I upgraded to ipfw2 it didn't happen again. [...] Mine doesn't: shy# uname -a FreeBSD shy.macomnet.ru 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Apr 21 05:48:09 MSD 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 shy# /sbin/ipfw disable firewall shy# /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 Are you sure? [yn] y Flushed all rules. net.inet.ip.fw.dyn_buckets: 256 - 600 shy# ipfw add 1 allow all from any to any 1 allow ip from any to any shy# /sbin/ipfw enable firewall Could you show your rules? That's ipfw1. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't get correct address in string form
Hello freebsd-hackers
I have a question related to the simple code below:
#include sys/types.h
#include sys/socket.h
#include sys/sysctl.h
#include netinet/in.h
#include netinet/tcp_var.h
#include err.h
#include netdb.h
#include stdio.h
#include stdlib.h
#include string.h
int main(int argc, char **argv)
{
struct addrinfo hints, *la, *localaddr;
char buf[31];
int gaierr=0;
bzero (buf, sizeof(buf));
//get local address - local address is 192.168.0.250
if ((gaierr = getaddrinfo(argv[1], argv[2], hints, localaddr)) != 0)
errx(1, %s port %s: %s, argv[1], argv[2], gai_strerror(gaierr));
for (la = localaddr; ail; la = la-ai_next)
{
inet_ntop(la-ai_family, la-ai_addr-sa_data, buf, sizeof(struct
sockaddr));
fprintf(stderr, Address: %s\n, buf);
}
return 0;
}
result - something like:
Address: 232.101.192.168
but must be - 192.168.0.250 ???
What i'm doing wrong !?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't get correct address in string form
Hi,
On Tue, 3 May 2005 18:39:10 +0300
Sergey [EMAIL PROTECTED] said:
fenix//get local address - local address is 192.168.0.250
fenixif ((gaierr = getaddrinfo(argv[1], argv[2], hints, localaddr))
!= 0)
fenixerrx(1, %s port %s: %s, argv[1], argv[2],
gai_strerror(gaierr));
You need to initialize hints before calling getaddrinfo(3).
fenix inet_ntop(la-ai_family, la-ai_addr-sa_data, buf, sizeof(struct
sockaddr));
The usage of inet_ntop(3) is wrong.
It should be something like:
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include err.h
#include netdb.h
#include stdio.h
#include stdlib.h
#include string.h
int main(int argc, char **argv)
{
struct addrinfo hints, *la, *localaddr;
char buf[46];
int gaierr=0;
//get local address - local address is 192.168.0.250
bzero(hints, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
if ((gaierr = getaddrinfo(argv[1], argv[2], hints, localaddr)) != 0)
errx(1, %s port %s: %s, argv[1], argv[2], gai_strerror(gaierr));
for (la = localaddr; la; la = la-ai_next)
{
switch (la-ai_family) {
case AF_INET:
inet_ntop(la-ai_family,
((struct sockaddr_in *)la-ai_addr)-sin_addr,
buf, sizeof(buf));
break;
case AF_INET6:
inet_ntop(la-ai_family,
((struct sockaddr_in6 *)la-ai_addr)-sin6_addr,
buf, sizeof(buf));
break;
default:
continue;
}
fprintf(stderr, Address: %s\n, buf);
}
return 0;
}
You can use getnameinfo(3) to simplify usage of inet_ntop(3).
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
John Hay wrote: On Tue, May 03, 2005 at 01:27:09PM +0400, Denis Peplin wrote: The mergemaster with this is test patch (attached) can auto-update files that was not modified. It do this by compairing each file with it's CVS copy. If file was not modified, it can be rewritten. This dramatically redices amount of files that require admin's attention. There is one major problem here: This can be done in single-user mode only if your have local CVS repository, because if local CVS is not exist, anoncvs is used. Possible solutions: What about mergemaster storing a copy of the original somewhere on disk for usage next time? Then the first run may still be slow, but following runs will be able to use it. John Mergemaster could keep checksums of known revisions. it wouldn't take much to have just one file with the last 35 checksums of each file. (maybe with the $FreeBSD$ line removed if it differs..) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
c0ldbyte wrote: IMHO this isnt something that should be included with mergemaster due to the following things. 1). It should upgrade a file if the files cvs id doesnt match and provide you with a merge option, which it allready does both of those as it is now. 2). Only upgrading files that havent been changed is going to result in a positive false situation where the user actually thinks that his/her system has been fully upgraded and when in fact it hasnt, leaving added lines to files out where they should have been merged in. Preferably also IMHO this patch to mergemaster should be or would be better off renamed to another project and/or an option for people to compile into the system if they wish to have that kind of functionality. E.g: System/Addon for world through the use of a set variable in /etc/make.conf.local or something similiar. But with all due respect, This just seems like another case of a Bike Shed incident. not at all. I've wanted this for a long time.. files that I have not touched are at default state and I wnat them to move to teh new default state. Files I have touched, I want to look at by hand. Best regards to humor. --c0ldbyte ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE corrupting fs on shutdown -p now?
On Tue, May 03, 2005 at 01:39:23PM +0100, Steven Hartland wrote: So sounds like this does need a bit of looking at. The key thing is both reboot and halt always leave the machine FS in a good state where as shutdown -p doesnt so is there something that -p skips? Or is it simply the fact that it powers down? If it's indeed dropping power on your disks before they're ready, that would explain the difference. Kris pgphGhxZXHgUv.pgp Description: PGP signature
Re: mergemaster improvement (auto-update for not modified files)
On Tue, May 03, 2005 at 11:15:51AM -0700, Julian Elischer wrote: c0ldbyte wrote: [...] But with all due respect, This just seems like another case of a Bike Shed incident. not at all. I've wanted this for a long time.. files that I have not touched are at default state and I wnat them to move to teh new default state. Files I have touched, I want to look at by hand. so do I. And to go a step further: why do we at all have to run this things in single-user mode ? Not that I am not aware of the technical reasons for it BUT: why don't we run both the installworld and the mergemaster jobs in a manner where they only _preparing_ the installation of the update ? ... maybe creating a jobfile which could be run automatically during reboot to make the update instantaneous happen without a long downtime to do it all manually in single-user mode over a slow serial console ? bye, Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
cleanup and diffs ?
Hello. I was surfing the dragonflybsd wiki site the other day and found out that they are doing a base-cleanup. That is they are compiling the tools that come with the base system with WARNS?=6 ... Humm... This is something that I could do.. Minor cleanup (since I'm no C expert or a OS developer ;) this fits my skillset just fine. Now I have two questions is this something that will be appriciated by someone ? (that is would this clean-up if done properly find its way to the tree ?... nobody likes going through trouble like this when it will have no affect ;). If so.. what is the diff format that is expected (diff -crN ?) and should this be sent via send-pr(1) ? I know that a ,,clean-up'' like this is propably not high on the todo list for FreeBSD but.. for me this would be an easy way to contribute something back since I have no skill to work in the kernel c. -- Thordur I. [EMAIL PROTECTED] FreeBSD - Unix the way *I* like it. A man can do as he will, but not will as he will. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cleanup and diffs ?
On Tue, May 03, 2005 at 10:38:37PM +, Thordur I. Bjornsson wrote: Hello. I was surfing the dragonflybsd wiki site the other day and found out that they are doing a base-cleanup. That is they are compiling the tools that come with the base system with WARNS?=6 ... Humm... This is something that I could do.. Minor cleanup (since I'm no C expert or a OS developer ;) this fits my skillset just fine. Now I have two questions is this something that will be appriciated by someone ? (that is would this clean-up if done properly find its way to the tree ?... nobody likes going through trouble like this when it will have no affect ;). If so.. what is the diff format that is expected (diff -crN ?) and should this be sent via send-pr(1) ? I know that a ,,clean-up'' like this is propably not high on the todo list for FreeBSD but.. for me this would be an easy way to contribute something back since I have no skill to work in the kernel c. You need to understand how to fix the warnings properly..it isn't just a matter of making random changes until gcc stops complaining about it. This can be nontrivial. Also, Dragonfly doesn't have to worry about any other architectures than i386, so it's possible that they haven't really fixed many of these warnings (i.e. they might still be there on a 64-bit platform). Kris pgp03VLHskpAZ.pgp Description: PGP signature
Re: Files in C.
Thanks by responding me. I will revise each direction that have given me and truly I thank it a lot. -- Concepción, Chile. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what goes wrong with barrier free atomic_load/store?
On Wednesday 20 April 2005 04:39 pm, John Giacomoni wrote: can someone give me an example of a situation where one needs to use memory barriers to ensure correctness when doing writes as above? One basic example: struct foo *p = malloc(sizeof(struct foo)); // Step 1 p-bar = 0; // Step 2 atomic(global_p = p); // Step 3 This is a pretty common idiom: Allocate a new data structure, initialize it, then assign the pointer to a shared global value so that the fully-initialized structure becomes visible all at once. Many people miss an important detail: A barrier is needed just before the final pointer assignment. Otherwise, the pointer might reach shared memory (Step 3) before the initialization in Step 2 happens. (This can happen because of compiler reordering or processor write caching.) Variations of this plagued the early attempts to correctly define Java's threading primitives. (It was possible to crash a lot of early JVMs by creating new objects in one thread and accessing them in another; every now and then the accessing thread would see an uninitialized vtable and crash the entire JVM.) Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
In message: [EMAIL PROTECTED] Juergen Unger [EMAIL PROTECTED] writes: : On Tue, May 03, 2005 at 11:15:51AM -0700, Julian Elischer wrote: : c0ldbyte wrote: : [...] : But with all due respect, This just seems like another case of a : Bike Shed incident. : not at all. : I've wanted this for a long time.. : files that I have not touched are at default state and I wnat them to move : to teh new default state. Files I have touched, I want to look at by hand. : : so do I. And to go a step further: why do we at all have to run : this things in single-user mode ? : Not that I am not aware of the technical reasons for it The technical reasons are very simple. If a new system call is created, and programs use that new system call, then if you do an installworld before you boot the kernel, that can result in binaries not working. This has happened with important ones like /bin/sh in the past. In addition, if you aren't running single user, many different races exist in the installation process that can result in bad behavior. There are also potential problems with symbols in there's a large jump between the revisions being updated. Usually you can get away with it, but if you want to be safe, you must do the install in single user. Usually, however, has lead in the past to problems, which is why the project recommendations are conservative. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cleanup and diffs ?
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : it. This can be nontrivial. Also, Dragonfly doesn't have to worry : about any other architectures than i386, so it's possible that they : haven't really fixed many of these warnings (i.e. they might still : be there on a 64-bit platform). Lord knows in the past how many tinderbox breakages we've had in the tree because someone fixed all the warnings at level 6, but in fact broke 64 bit ports... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
