From owner-freebsd-hackers Sun Aug 11 0:37: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87D1337B400 for ; Sun, 11 Aug 2002 00:37:08 -0700 (PDT) Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234F243E70 for ; Sun, 11 Aug 2002 00:37:08 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17dnHe-0003hg-00 for freebsd-hackers@freebsd.org; Sun, 11 Aug 2002 10:37:06 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@freebsd.org Subject: /usr/local & cc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 10:37:06 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG is it me going senile, or some setup screwup on my part, but i see that cpp does not have /usr/local/include in its path nor /usr/local/lib in gcc/ld. i checked solaris/bsdi/linux and they all search /usr/local/[include,lib] thanks, danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 1:17:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B76BF37B400 for ; Sun, 11 Aug 2002 01:17:50 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20F7E43E3B for ; Sun, 11 Aug 2002 01:17:34 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.5/8.12.3) with ESMTP id g7B8H59R002287; Sun, 11 Aug 2002 02:17:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Aug 2002 02:16:45 -0600 (MDT) Message-Id: <20020811.021645.131703847.imp@bsdimp.com> To: danny@cs.huji.ac.il Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /usr/local & cc From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Danny Braniss writes: : is it me going senile, or some setup screwup on my part, but i see : that cpp does not have /usr/local/include in its path nor : /usr/local/lib in gcc/ld. i checked solaris/bsdi/linux and they all : search /usr/local/[include,lib] Are you sure about solaris and bsdi? This is a linux-ism. Last time this came up, that was the conclusion on the thread. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 2:30:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6AF937B400 for ; Sun, 11 Aug 2002 02:30:08 -0700 (PDT) Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E344E43E4A for ; Sun, 11 Aug 2002 02:30:07 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17dp30-0000If-00; Sun, 11 Aug 2002 12:30:06 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /usr/local & cc In-reply-to: Your message of Sun, 11 Aug 2002 02:16:45 -0600 (MDT) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 12:30:06 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In message: > Danny Braniss writes: > : is it me going senile, or some setup screwup on my part, but i see > : that cpp does not have /usr/local/include in its path nor > : /usr/local/lib in gcc/ld. i checked solaris/bsdi/linux and they all > : search /usr/local/[include,lib] > > Are you sure about solaris and bsdi? This is a linux-ism. Last time > this came up, that was the conclusion on the thread. > > Warner well, as far as i can check they are using /usr/local, im including some output: BSDI BSD/OS 4.1: facundo> cc -v c.c Using builtin specs. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) /usr/libexec/egcs-1.1.2/i386-unknown-bsdielf4.1/egcs-2.91.66/cpp -lang-c -v -un def -D__GNUC__=2 -D__GNUC_MINOR__=91 -Dunix -D__i386__ -Di386 -D__bsdi__ -Dbsdi -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__bsdi__ -D__bsdi__ -D__ELF__ -D__u nix -D__i386 -D__bsdi -Asystem(unix) -Asystem(bsd) -Acpu(i386) -Amachine(i386) - Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ c.c /var/tm p/cca0vzGa.i GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (i386 ELF BSD/OS) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/include /usr/include End of search list. /usr/libexec/egcs-1.1.2/i386-unknown-bsdielf4.1/egcs-2.91.66/cc1 /var/tmp/cca0v zGa.i -quiet -dumpbase c.c -version -o /var/tmp/cclXeQqj.s GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (i386-unknown-bsdielf4. 1) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). as -V -Qy -o /var/tmp/ccgiQKJi.o /var/tmp/cclXeQqj.s GNU assembler version 2.9.1 (bsdielf), using BFD version 2.9.1 ld -m elf_i386 -dynamic-linker /shlib/ld-bsdi.so /usr/lib/crt1.o /usr/lib/crti. o /usr/lib/crtbegin.o -L/usr/libexec/egcs-1.1.2/i386-unknown-bsdielf4.1/egcs-2. 9 1.66 /var/tmp/ccgiQKJi.o -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o ------------------------------------------------------------------------------- - BSDI BSD/OS 4.0.1: shuldig> cc -v c.c gcc version 2.7.2.1 /usr/libexec/gcc2/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dunix -D__i386__ -Di386 -D__bsdi__ -Dbsdi -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__bsdi__ -D__bsdi__ -D__ELF__ -D__unix -D__i386 -D__bsdi -Asystem(unix) -Asystem(bsd) -Acpu(i386) -Amachine(i386) c.c /tmp/cc012835.i GNU CPP version 2.7.2.1 (i386 ELF BSD/OS) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/include /usr/include /usr/include End of search list. /usr/libexec/gcc2/cc1 /tmp/cc012835.i -quiet -dumpbase c.c -version -o /tmp/cc012835.s GNU C version 2.7.2.1 (i386 ELF BSD/OS) compiled by GNU C version 2.7.2.1. as -V -Qy -o /tmp/cc0128351.o /tmp/cc012835.s GNU assembler version 2.8.1 (bsd/os), using BFD version 2.8.1 ld -m elf_i386 -dynamic-linker /shlib/ld-bsdi.so /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib /tmp/cc0128351.o -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o and cpp -v Reading specs from /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/specs gcc version 2.95 19990728 (release) /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/cpp -lang-c -v -Dunix -D__i386__ -Di386 -D__bsdi__ -Dbsdi -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__bsdi__ -D__bsdi__ -D__ELF__ -D__unix -D__i386 -D__bsdi -Asystem(unix) -Asystem(bsd) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ - GNU CPP version 2.95 19990728 (release) (i386 ELF BSD/OS) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/../../../../i386-pc-bsdi4.0/includ e /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/../../../../include/g++-3 End of omitted list. ------------------------------------------------------------------------------- SunOS sol4 5.8 Generic sun4u sparc SUNW,UltraAX-MP: Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/cpp -lang-c -v -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) - GNU CPP version 2.95.2 19991024 (release) (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solar is2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../include/g++-3 End of omitted list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 9: 2:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F31D37B400 for ; Sun, 11 Aug 2002 09:02:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E7243E72 for ; Sun, 11 Aug 2002 09:02:14 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7BG28r06683; Sun, 11 Aug 2002 09:02:08 -0700 (PDT) Message-ID: <3D568A6B.4000100@isi.edu> Date: Sun, 11 Aug 2002 09:01:47 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White Cc: hackers@freebsd.org Subject: Re: SMP P4 Xeons out there? References: <20020810160643.I38678-100000@carver.gumbysoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000001040201090903070404" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms000001040201090903070404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Doug White wrote: > Hey folks, > > Anyone other there with multiprocessor P4 Xeon systems with Hyperthreading > enabled that are seeing 4 CPUs show up on boot? Not yet, but we're expecting some Dell Precision 530s later this week - I'll let you know. Lars -- Lars Eggert USC Information Sciences Institute --------------ms000001040201090903070404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMTE2MDE0N1owIwYJKoZIhvcNAQkEMRYEFJussJ4BTNYR uSCGXz4ZPy2nVTGNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBCPB5pG+VIHJWo1BoxKKj3cNOxx9Xn8tc8lyhE/gbRZqXo HIpJ/n2xbqXKuW5gMvbY8DYx0p7QGpiFCTx58mKaVvD4Ho7/g7KQF9IqnJElW5vdMXXWQtWQ ujDoPNIdzstZFrenEIsoip7qXKRoT3+T89waWdt2rPj+a+1IIk88JAAAAAAAAA== --------------ms000001040201090903070404-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 10:36:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC26837B400; Sun, 11 Aug 2002 10:36:13 -0700 (PDT) Received: from mail.cruzio.com (dsl3-63-249-66-210.cruzio.com [63.249.66.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79CE843E3B; Sun, 11 Aug 2002 10:36:13 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.11.3/8.11.3) id g7BHrbn00809; Sun, 11 Aug 2002 10:53:37 -0700 (PDT) (envelope-from brucem) Date: Sun, 11 Aug 2002 10:53:37 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200208111753.g7BHrbn00809@mail.cruzio.com> To: freebsd-hackers@freebsd.org Subject: PCM Native Audio Driver for NatSemi Geode GX1 Cc: cg@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have written a FreeBSD "new PCM" audio driver for the Native Audio PCI function internal to the National Semiconductor Geode GX1/Cx5530 CPU and chipset, and integrated equivalents. This driver uses the Cx5530 southbridge's internal PCI audio hardware directly. It does not use the Soundblaster emulator that at one time was in the Cyrix "hypervisor". I'm under the impression that this driver should work on any NatSemi GX1 CPU, but don't know that for sure. Also included in this kit are 4 small "new PCM" audio test programs. These test programs should work with any FreeBSD "new PCM" audio driver. The kit can be obtained at: http://alumni.cse.ucsc.edu/~brucem/gx_audio This driver is heavily commented and hopefully is useful to anyone studying the FreeBSD PCM audio system, or any similar PCI drivers using interfaces built on FreeBSD kernel objects. All features exercised by the test programs are working. Testing has been done under FreeBSD 4.6 Stable. Suspend/Resume support is present but not yet tested. Please let me know if you find bugs or have any advice at all about anything pertaining to this... - bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 11:15:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6707F37B400 for ; Sun, 11 Aug 2002 11:15:29 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BC5443E42 for ; Sun, 11 Aug 2002 11:15:28 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.5/8.12.3) with ESMTP id g7BIFJ9R004555; Sun, 11 Aug 2002 12:15:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Aug 2002 12:14:51 -0600 (MDT) Message-Id: <20020811.121451.10751663.imp@bsdimp.com> To: danny@cs.huji.ac.il Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /usr/local & cc From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Interesting... The /usr/local behavior is new then on Solaris (or was configured in), because I know that it didn't used to be that way. I'm pretty sure that the solaris native compilers don't do that. The bsdi compiler also used to not have /usr/local included automatically. The fact that it is included BEFORE /usr/include seems wrong to me and that it would break things if somebody ever installed a file with the same name system header in /usr/local.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 12: 8:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 825DE37B400 for ; Sun, 11 Aug 2002 12:08:45 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0176343E6E for ; Sun, 11 Aug 2002 12:08:45 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.5/8.12.5) id g7BJ8EeR005333; Sun, 11 Aug 2002 14:08:14 -0500 (CDT) (envelope-from dan) Date: Sun, 11 Aug 2002 14:08:14 -0500 From: Dan Nelson To: Danny Braniss Cc: "M. Warner Losh" , freebsd-hackers@FreeBSD.ORG Subject: Re: /usr/local & cc Message-ID: <20020811190814.GG7599@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Aug 11), Danny Braniss said: > > In message: > > Danny Braniss writes: > > : is it me going senile, or some setup screwup on my part, but i see > > : that cpp does not have /usr/local/include in its path nor > > : /usr/local/lib in gcc/ld. i checked solaris/bsdi/linux and they all > > : search /usr/local/[include,lib] > > > > Are you sure about solaris and bsdi? This is a linux-ism. Last time > > this came up, that was the conclusion on the thread. > > > > Warner > > well, as far as i can check they are using /usr/local, > im including some output: > > BSDI BSD/OS 4.0.1: > Reading specs from /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/specs > gcc version 2.95 19990728 (release) > #include <...> search starts here: > /usr/local/include > /usr/local/lib/gcc-lib/i386-pc-bsdi4.0/2.95/../../../../i386-pc-bsdi4.0/include > > ------------------------------------------------------------------------------- > SunOS sol4 5.8 Generic sun4u sparc SUNW,UltraAX-MP: > Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs > gcc version 2.95.2 19991024 (release) > #include <...> search starts here: > /usr/local/include > /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solaris2.6/include These two you compiled yourself, so you can't use them them in your examples. If you were to try with the native Solaris cc, it would not include /usr/local. Same for the bundled cc on Tru64. It's probably a bug that BSD/OS didn't remove /usr/include when they imported gcc into the base system. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 12:47:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1706D37B400 for ; Sun, 11 Aug 2002 12:47:57 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id D9BCD43E72 for ; Sun, 11 Aug 2002 12:47:56 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 28149 invoked by uid 1031); 8 Aug 2002 15:48:14 -0000 Date: Thu, 8 Aug 2002 15:48:14 +0000 From: Bruce M Simpson To: freebsd-hackers@freebsd.org Subject: Building ports into packages, outside of /usr/ports Message-ID: <20020808154814.GD18301@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Has anybody thought about hacking the above to support building packages outside of the ports tree, and without installing them? Strikes me as something that could be neatly solved with judicious use of chroot(1). This is something which was raised at the FreeBSD UK Users Group meeting last night, so it's bugging me. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 13:22:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ED2337B400 for ; Sun, 11 Aug 2002 13:22:35 -0700 (PDT) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BDFE43E65 for ; Sun, 11 Aug 2002 13:22:34 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.6/8.11.6) id g7BKMEF97258; Sun, 11 Aug 2002 21:22:14 +0100 (BST) (envelope-from rb) Message-Id: <4.3.2.7.2.20020811210636.02068bf0@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Aug 2002 21:22:14 +0100 To: "M. Warner Losh" From: Bob Bishop Subject: wi hostap mode WEP oddity Cc: hackers@freebsd.org In-Reply-To: <20020724.183650.38682224.imp@bsdimp.com> References: <4.3.2.7.2.20020724222414.01f9f8f0@gid.co.uk> <4.3.2.7.2.20020723230525.02056a48@gid.co.uk> <20020724.142626.132443392.imp@bsdimp.com> <4.3.2.7.2.20020724222414.01f9f8f0@gid.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I'm using a 3Com AirConnect (3CRWE777A) in hostap mode on a -STABLEish kernel, and I've observed an oddity which might explain some other reports. I'm setting 'wepmode on', but ifconfig subsequently reports 'wepmode MIXED' although wicontrol reports it as 'On'. I can't connect with a non-WEP client, so I believe the card really is in WEP-only mode and ifconfig is reporting it wrongly. All seems to work except that client connexions drop after an indeterminate period (perhaps related to signal quality) and won't reconnect unless I ifconfig down then up the hostap interface. I'm going to see whether upgrading to the latest firmware effects any improvement. [Test client is a 3CRSHPW on Win2k running latest firmware.] -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 13:55:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02E0237B412 for ; Sun, 11 Aug 2002 13:55:34 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EAD343E5E for ; Sun, 11 Aug 2002 13:55:34 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6FBA672FC6; Sun, 11 Aug 2002 13:52:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6E8F272FC5; Sun, 11 Aug 2002 13:52:37 -0700 (PDT) Date: Sun, 11 Aug 2002 13:52:37 -0700 (PDT) From: Doug White To: Sean Hamilton Cc: hackers@freebsd.org Subject: Re: arplookup: host is not on local network In-Reply-To: <000f01c240c8$e7247c00$f019e8d8@slugabed.org> Message-ID: <20020811134721.A41711-100000@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 10 Aug 2002, Sean Hamilton wrote: > Greetings, > > I have a FreeBSD box being colocated. Every few seconds, I get the following > message: > > /kernel: arplookup 216.187.x.x failed: host is not on local network > > As I understand, this 216.187.x.x machine is acting as a "proxy arp". I > think it's supposed to be completely transparent, but evidently my box is > noticing. Got to love broken linux boxes. Linux has this fun habit of announcing ARPs for all interfaces on all other interfaces. It drives BSD boxes batty since its abnormal, but it is allowed behavior. That or someone has a seriously broken netmask. You should check that your network configuration is correct first, then use tcpdump to locate the offender and report them to your provider. They can ask the owner of said machine politely to install the patches or set /proc flags to disable that behavior. You can, of course, comment out the printfs, or hide it behind log_arp_wrong_iface which is controlled by the sysctl net.link.ether.inet.log_arp_wrong_iface. The file you want to modify in that case is src/sys/netinet/if_ether.c. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 14: 5:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C09137B400 for ; Sun, 11 Aug 2002 14:05:28 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AE3E43E65 for ; Sun, 11 Aug 2002 14:05:27 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.5/8.12.3) with ESMTP id g7BL5P9R005211; Sun, 11 Aug 2002 15:05:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Aug 2002 13:52:26 -0600 (MDT) Message-Id: <20020811.135226.44234970.imp@bsdimp.com> To: rb@gid.co.uk Cc: hackers@freebsd.org Subject: Re: wi hostap mode WEP oddity From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20020811210636.02068bf0@gid.co.uk> References: <4.3.2.7.2.20020724222414.01f9f8f0@gid.co.uk> <20020724.183650.38682224.imp@bsdimp.com> <4.3.2.7.2.20020811210636.02068bf0@gid.co.uk> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <4.3.2.7.2.20020811210636.02068bf0@gid.co.uk> Bob Bishop writes: : I'm using a 3Com AirConnect (3CRWE777A) in hostap mode on a -STABLEish : kernel, and I've observed an oddity which might explain some other reports. : I'm setting 'wepmode on', but ifconfig subsequently reports 'wepmode MIXED' : although wicontrol reports it as 'On'. I can't connect with a non-WEP : client, so I believe the card really is in WEP-only mode and ifconfig is : reporting it wrongly. You maybe be correct about that. I've not played with wep much, but have noticed when I was playing with ad-hoc demo mode that I could get a lucent card to connect w/o wep, but maybe I'm confused and it is a simple bug in wi that it reports mixed. : All seems to work except that client connexions drop after an indeterminate : period (perhaps related to signal quality) and won't reconnect unless I : ifconfig down then up the hostap interface. I'm going to see whether : upgrading to the latest firmware effects any improvement. [Test client is a : 3CRSHPW on Win2k running latest firmware.] That's very odd. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 15:59:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDA2B37B401 for ; Sun, 11 Aug 2002 15:59:20 -0700 (PDT) Received: from priv-edtnes15-hme0.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69FB243E3B for ; Sun, 11 Aug 2002 15:59:19 -0700 (PDT) (envelope-from sh@planetquake.com) Received: from dbs ([216.232.25.240]) by priv-edtnes15-hme0.telusplanet.net (InterMail vM.5.01.04.01 201-253-122-122-101-20011014) with SMTP id <20020811225918.MJDF3365.priv-edtnes15-hme0.telusplanet.net@dbs> for ; Sun, 11 Aug 2002 16:59:18 -0600 Message-ID: <001f01c2418a$bc174890$f019e8d8@slugabed.org> From: "Sean Hamilton" To: References: <20020811134721.A41711-100000@carver.gumbysoft.com> Subject: Re: arplookup: host is not on local network Date: Sun, 11 Aug 2002 15:59:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From: "Doug White" > You should check that your network configuration is correct first, then > use tcpdump to locate the offender and report them to your provider. They > can ask the owner of said machine politely to install the patches or set > /proc flags to disable that behavior. You can, of course, comment out the Which /proc flags? Indeed it is a linux box, the firewall, which I have access to. My coworker, the administrator of this box, has simply turned a blind eye to this, on the grounds that it's not actually causing problems, just noise... but if it's a simple tweak, I'm sure he could be bribed with caffeine or somesuch. > printfs, or hide it behind log_arp_wrong_iface which is controlled by the > sysctl net.link.ether.inet.log_arp_wrong_iface. The file you want to > modify in that case is src/sys/netinet/if_ether.c. Thanks, looks like that sysctl is what I've been looking for. Though you seem to indicate I would have to modify the kernel to achieve this, it seems to be that way already -- perhaps a recent thing? Regardless, I find it somewhat surprising my googling didn't point me in this direction. sh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 16:33:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F110C37B400; Sun, 11 Aug 2002 16:33:37 -0700 (PDT) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1280643E81; Sun, 11 Aug 2002 16:33:36 -0700 (PDT) (envelope-from joe@genius.tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id C72B247D; Mon, 12 Aug 2002 00:33:28 +0100 (BST) Date: Mon, 12 Aug 2002 00:33:28 +0100 From: Josef Karthauser To: Takanori Watanabe Cc: hackers@freebsd.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb usbdevs Message-ID: <20020811233328.GA33280@genius.tao.org.uk> References: <200207251415.g6PEFoB3069395@freefall.freebsd.org> <200207251423.XAA12554@axe-inc.co.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <200207251423.XAA12554@axe-inc.co.jp> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2002 at 11:23:55PM +0900, Takanori Watanabe wrote: > > Log: > > MFNetBSD: FTDI USB-serial converter chips description. >=20 > I ported a FTDI USB serial converter driver from NetBSD. > http://people.freebsd.org/uftdi.tar.gz I've committed this. Thanks :). Joe --=20 "As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality." - Albert Einstein, 1921 --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iEYEARECAAYFAj1W9EgACgkQXVIcjOaxUBYX4wCfad2Oa+tIJhsMsuy0cERADIaG 7nIAnjp2oAbAzvmV8PyOsH3aCnDNanxm =ozBL -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 11 17:55:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2A537B400 for ; Sun, 11 Aug 2002 17:55:17 -0700 (PDT) Received: from localhost.com (ppp-62-11-40-254.dialup.tiscali.it [62.11.40.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 3108A43E65 for ; Sun, 11 Aug 2002 17:55:16 -0700 (PDT) (envelope-from eee.uio@libero.it) From: "pretty" To: freebsd-hackers@FreeBSD.org Date: Mon, 12 Aug 2002 02.53.57 +0200 Subject: secret X-Mailer: MailXSender 1.06 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20020812005516.3108A43E65@mx1.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG http=3A=2F=2Fragazzepericolose=2Eda=2Eru veramente=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E http=3A=2F=2Fragazzepericolose=2Eda=2Eru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 1:32:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86C1637B400 for ; Mon, 12 Aug 2002 01:32:40 -0700 (PDT) Received: from hotmail.com (oe97.pav0.hotmail.com [64.4.33.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 233D743E42 for ; Mon, 12 Aug 2002 01:32:40 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 01:32:40 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: Date: Mon, 12 Aug 2002 16:32:27 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0000_01C2421D.D87200F0" Message-ID: X-OriginalArrivalTime: 12 Aug 2002 08:32:40.0039 (UTC) FILETIME=[D1EC3770:01C241DA] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C2421D.D87200F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Everybody, I am a jackaroo to FreeBSD kernel. I have a question about how the kern= el add all devices. =20 For example, in NetBSD, I can find the code in /sys/kern/init_main.c: /* Attach pseudo-devices. */ for (pdev =3D pdevinit; pdev->pdev_attach !=3D NULL; pdev++) (*pdev->pdev_attach)(pdev->pdev_count); I know the NetBSD kernel add devices(such as storage device and network d= evice) by them. But in FreeBSD, I can not locate the place. which part code should I read? Thank you. =20 Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://e= xplorer.msn.com ------=_NextPart_001_0000_01C2421D.D87200F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Everybody,

  I am a jackaroo to FreeBSD kernel. I have a question about how the kerne= l add all devices.

  For example= , in NetBSD, I can find the code in /sys/kern/init_main.c:<= /SPAN>

 /* Attach pseudo-devices. */<= /FONT>

for (pdev =3D pdevinit; pdev->pdev_attach !=3D NULL; pdev++)

              <= /SPAN>(*pdev->pdev_attach)(pdev->pdev_count);<= /P>

I know the NetBSD kernel add dev= ices(such as storage device and network device) by them.

<= FONT face=3D"Times New Roman" size=3D3>But in FreeBSD, I can not locate t= he place.

which pa= rt code should I read?

Thank you.

 

  Ouyang Kai


Get more fr= om the Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0000_01C2421D.D87200F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 1:35:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EFA137B400 for ; Mon, 12 Aug 2002 01:35:32 -0700 (PDT) Received: from hotmail.com (oe60.pav0.hotmail.com [64.4.33.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 642E743E42 for ; Mon, 12 Aug 2002 01:35:32 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 01:35:32 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: Subject: Hi, how the kernel add the devices Date: Mon, 12 Aug 2002 16:35:23 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C2421E.413F6140" Message-ID: X-OriginalArrivalTime: 12 Aug 2002 08:35:32.0231 (UTC) FILETIME=[388EA170:01C241DB] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0001_01C2421E.413F6140 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Everybody, I am a jackaroo to FreeBSD kernel. I have a question about how the kern= el add all devices. =20 For example, in NetBSD, I can find the code in /sys/kern/init_main.c: /* Attach pseudo-devices. */ for (pdev =3D pdevinit; pdev->pdev_attach !=3D NULL; pdev++) (*pdev->pdev_attach)(pdev->pdev_count); I know the NetBSD kernel add devices(such as storage device and network d= evice) by them. But in FreeBSD, I can not locate the place. which part code should I read? Thank you. =20 Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://e= xplorer.msn.com ------=_NextPart_001_0001_01C2421E.413F6140 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Everybody,<= BR>  I am a jackaroo to FreeBSD kernel. I have a question about how = the kernel add all devices. 
  For example, in NetBSD, I ca= n find the code in /sys/kern/init_main.c:
 /* Attach pseudo-devic= es. */
for (pdev =3D pdevinit; pdev->pdev_attach !=3D NULL; pdev++)=
           &nb= sp;  (*pdev->pdev_attach)(pdev->pdev_count);
I know the Net= BSD kernel add devices(such as storage device and network device) by them= .
But in FreeBSD, I can not locate the place.
which part code shoul= d I read?
Thank you.
 
Best Regards
  Ouyang Kai
 
 

Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0001_01C2421E.413F6140-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 2:16:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6905237B400 for ; Mon, 12 Aug 2002 02:16:11 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1983543E3B for ; Mon, 12 Aug 2002 02:16:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0007.cvx21-bradley.dialup.earthlink.net ([209.179.192.7] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eBJ3-0004lf-00; Mon, 12 Aug 2002 02:16:09 -0700 Message-ID: <3D577C37.FF7992D3@mindspring.com> Date: Mon, 12 Aug 2002 02:13:27 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ouyang kai Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hi, how the kernel add the devices References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ouyang kai wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable See /usr/src/sys/kernel.h. It is done using linker sets and SYSINIT. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 2:50: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C4137B400 for ; Mon, 12 Aug 2002 02:49:58 -0700 (PDT) Received: from hotmail.com (oe72.pav0.hotmail.com [64.4.33.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FC0C43E4A for ; Mon, 12 Aug 2002 02:49:57 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 02:49:57 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: "Lambert Terry" , Subject: Re: Hi, how the kernel add the devices Date: Mon, 12 Aug 2002 17:49:46 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0002_01C24228.A5C40FD0" Message-ID: X-OriginalArrivalTime: 12 Aug 2002 09:49:57.0544 (UTC) FILETIME=[9E175280:01C241E5] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0002_01C24228.A5C40FD0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0003_01C24228.A5C680D0" ------=_NextPart_002_0003_01C24228.A5C680D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Terry, >See /usr/src/sys/kernel.h. It is done using linker sets and >SYSINIT. Hmm=A1=AD. Thank you! I find the mi_startup() function in /sys/kern/init_main.c, there are some= code as follow: for (sipp =3D sysinit; sipp < sysinit_end; sipp++) { if ((*sipp)->subsystem =3D=3D SI_SUB_DUMMY) continue; /* skip dummy task(s)*/ if ((*sipp)->subsystem =3D=3D SI_SUB_DONE) continue; /* Call function */ (*((*sipp)->func))((*sipp)->udata); /* Check off the one we're just done */ (*sipp)->subsystem =3D SI_SUB_DONE; /* Check if we've installed more sysinit items via KLD */ if (newsysinit !=3D NULL) { if (sysinit !=3D SET_BEGIN(sysinit_set)) free(sysinit, M_TEMP); sysinit =3D newsysinit; sysinit_end =3D newsysinit_end; newsysinit =3D NULL; newsysinit_end =3D NULL; goto restart; } } Now, I am puzzled about the function pointer(func), which is how to work.= =20 For example, I have a NIC =A1=AEfxp0=A1=AF, so the function pointer shoul= d point to the fxp_attach? If that is right, I want to know how the kernel call the mi_startup()? Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://ex= plorer.msn.com ------=_NextPart_002_0003_01C24228.A5C680D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Terry,
 >See /usr/src/sys/kernel.h.  It is done using link= er sets and
>SYSINIT.
Hmm=A1=AD. Thank you!
I find the mi_sta= rtup() function in /sys/kern/init_main.c, there are some code as follow:<= BR>for (sipp =3D sysinit; sipp < sysinit_end; sipp++) {
  = ;if ((*sipp)->subsystem =3D=3D SI_SUB_DUMMY)
   cont= inue; /* skip dummy task(s)*/
  if ((*sipp)->subsyst= em =3D=3D SI_SUB_DONE)
   continue;
  /* C= all function */
  (*((*sipp)->func))((*sipp)->udata);<= BR>  /* Check off the one we're just done */
  (*s= ipp)->subsystem =3D SI_SUB_DONE;
  /* Check if we've inst= alled more sysinit items via KLD */
  if (newsysinit !=3D NU= LL) {
   if (sysinit !=3D SET_BEGIN(sysinit_set))
&n= bsp;   free(sysinit, M_TEMP);
   sysinit= =3D newsysinit;
   sysinit_end =3D newsysinit_end;
=    newsysinit =3D NULL;
   newsysinit_en= d =3D NULL;
   goto restart;
  }
 = }
Now, I am puzzled about the function pointer(func), which is how to = work.
For example, I have a NIC =A1=AEfxp0=A1=AF, so the function poi= nter should point to the fxp_attach?
If that is right, I want to know = how the kernel call the mi_startup()?
 
Best R= egards
 Ouyang Kai
 
 
Get more from the Web. FREE MSN Exp= lorer download : http://explorer.msn.= com

------=_NextPart_002_0003_01C24228.A5C680D0-- ------=_NextPart_001_0002_01C24228.A5C40FD0 Content-Type: text/plain; name="kernel_init_problem.txt" Content-Disposition: attachment; filename="kernel_init_problem.txt" Content-Transfer-Encoding: quoted-printable Dear Terry >See /usr/src/sys/kernel.h. It is done using linker sets and >SYSINIT. Hmm=A1=AD. Thank you! I find the mi_startup() function in /sys/kern/init_main.c, there are some= code as follow: for (sipp =3D sysinit; sipp < sysinit_end; sipp++) { if ((*sipp)->subsystem =3D=3D SI_SUB_DUMMY) continue; /* skip dummy task(s)*/ if ((*sipp)->subsystem =3D=3D SI_SUB_DONE) continue; /* Call function */ (*((*sipp)->func))((*sipp)->udata); /* Check off the one we're just done */ (*sipp)->subsystem =3D SI_SUB_DONE; /* Check if we've installed more sysinit items via KLD */ if (newsysinit !=3D NULL) { if (sysinit !=3D SET_BEGIN(sysinit_set)) free(sysinit, M_TEMP); sysinit =3D newsysinit; sysinit_end =3D newsysinit_end; newsysinit =3D NULL; newsysinit_end =3D NULL; goto restart; } } Now, I am puzzled about the function pointer(func), which is how to work.= =20 For example, I have a NIC =A1=AEfxp0=A1=AF, so the function pointer shoul= d point to the fxp_attach? Best Regards Ouyang Kai If that is right, I want to know how the kernel call the mi_startup()? ------=_NextPart_001_0002_01C24228.A5C40FD0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 3:19:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9875C37B400; Mon, 12 Aug 2002 03:15:26 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFECF43E3B; Mon, 12 Aug 2002 03:15:17 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA76768; Mon, 12 Aug 2002 13:14:39 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7CAEX8Y076679; Mon, 12 Aug 2002 13:14:34 +0300 (EEST) Received: from vega.vega.com (h210.234.dialup.iptcom.net [212.9.234.210]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7CAE3oQ057457; Mon, 12 Aug 2002 13:14:06 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7CAE1F2039450; Mon, 12 Aug 2002 13:14:01 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D578A99.F0821712@FreeBSD.org> Date: Mon, 12 Aug 2002 13:14:49 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: hackers@FreeBSD.org, audit@FreeBSD.org, Alexander Litvin , Andriy Gapon Subject: Thread-safe resolver [patches for review] Content-Type: multipart/mixed; boundary="------------051496A982500B2DDF1E4FCD" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------051496A982500B2DDF1E4FCD Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Folks, Attched please find two patches based on bin/29581 PR to make FreeBSD resolver thread-safe. They represent two approaches to reach this goal - the first is to introduce reentrant versions of the standard gethostbyXXX(3) APIs, similar to ones existing in other unices, and the second one is to make gethostbyXXX(3) returning data placed into per-thread storage when linked with libc_r. I like the latter approach more, since it doesn't introduce new non-standard APIs. I would like to hear any comments and suggestions on the proposed patches, as well as to opinions about which path to chose. Thanks! -Maxim --------------051496A982500B2DDF1E4FCD Content-Type: text/plain; charset=koi8-r; name="resolv_r-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="resolv_r-1.diff" Index: src/include/netdb.h =================================================================== RCS file: /home/ncvs/src/include/netdb.h,v retrieving revision 1.24 diff -d -u -r1.24 netdb.h --- src/include/netdb.h 26 Jun 2002 08:18:42 -0000 1.24 +++ src/include/netdb.h 10 Aug 2002 10:03:43 -0000 @@ -82,7 +82,10 @@ #define _PATH_PROTOCOLS "/etc/protocols" #define _PATH_SERVICES "/etc/services" -extern int h_errno; +__BEGIN_DECLS +int * __h_errno_accessor(void); +__END_DECLS +#define h_errno (* __h_errno_accessor()) /* * Structures returned by network data base library. All addresses are @@ -240,6 +243,15 @@ char *gai_strerror(int); void setnetgrent(const char *); void setservent(int); + +int gethostbyaddr_r(const char *, int, int, struct hostent *, + char *, int, int *); +int gethostbyname_r(const char *, struct hostent *, + char *, int, int *); +int gethostbyname2_r(const char *, int, struct hostent *, + char *, int, int *); +struct hostent *gethostent_r(struct hostent *, char *, int); + /* * PRIVATE functions specific to the FreeBSD implementation Index: src/include/resolv.h =================================================================== RCS file: /home/ncvs/src/include/resolv.h,v retrieving revision 1.21 diff -d -u -r1.21 resolv.h --- src/include/resolv.h 23 Mar 2002 17:24:53 -0000 1.21 +++ src/include/resolv.h 10 Aug 2002 10:03:43 -0000 @@ -90,11 +90,16 @@ #define MAXDFLSRCH 3 /* # default domain levels to try */ #define MAXDNSRCH 6 /* max # domains in search path */ #define LOCALDOMAINPARTS 2 /* min levels in name that is "local" */ +#define MAXALIASES 35 /* max # of aliases to return */ +#define MAXADDRS 35 /* max # of addresses to return */ #define RES_TIMEOUT 5 /* min. seconds between retries */ #define MAXRESOLVSORT 10 /* number of net to sort on */ #define RES_MAXNDOTS 15 /* should reflect bit field size */ +#define CAST_ALIGN(ptr, type) \ + (char*)(type)ptr < (char*)ptr ? ((type)ptr) + 1 : (type)ptr + struct __res_state { int retrans; /* retransmition time interval */ int retry; /* number of times to retransmit */ @@ -198,10 +203,6 @@ char * humanname; /* Its fun name, like "mail exchanger" */ }; -extern struct __res_state _res; -/* for INET6 */ -extern struct __res_state_ext _res_ext; - extern const struct res_sym __p_class_syms[]; extern const struct res_sym __p_type_syms[]; @@ -224,6 +225,7 @@ #define fp_query __fp_query #define fp_nquery __fp_nquery #define hostalias __hostalias +#define hostalias_r __hostalias_r #define putlong __putlong #define putshort __putshort #define p_class __p_class @@ -273,6 +275,7 @@ void fp_query(const u_char *, FILE *); void fp_nquery(const u_char *, int, FILE *); const char * hostalias(const char *); +const char * hostalias_r(const char *, char *, int); void putlong(u_int32_t, u_char *); void putshort(u_int16_t, u_char *); const char * p_class(int); @@ -315,5 +318,30 @@ void res_freeupdrec(ns_updrec *); #endif __END_DECLS + +struct __res_data { + int h_errno_res; + int s; /* socket used for communications */ + int connected : 1; /* is the socket connected */ + int vc : 1; /* is the socket a virtual circuit? */ + int af; /* address family of socket */ + res_send_qhook Qhook; + res_send_rhook Rhook; + FILE* hostf; + int stayopen; + struct __res_state *res; + struct __res_state_ext *res_ext; +}; + +__BEGIN_DECLS +u_int16_t _getshort(const u_char *); +u_int32_t _getlong(const u_char *); +struct __res_data * __res_data_accessor(void); +struct __res_state * __res_accessor(void); +__END_DECLS +#define _res_data (* __res_data_accessor()) +#define _res (* __res_accessor()) +/* for INET6 */ +#define _res_ext (* (__res_data_accessor()->res_ext)) #endif /* !_RESOLV_H_ */ Index: src/lib/libc/net/getaddrinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getaddrinfo.c,v retrieving revision 1.28 diff -d -u -r1.28 getaddrinfo.c --- src/lib/libc/net/getaddrinfo.c 2 Aug 2002 11:58:48 -0000 1.28 +++ src/lib/libc/net/getaddrinfo.c 10 Aug 2002 10:03:49 -0000 @@ -1673,7 +1673,6 @@ /* resolver logic */ extern const char *__hostalias(const char *); -extern int h_errno; /* * Formulate a normal query, send, and await answer. Index: src/lib/libc/net/gethostbydns.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbydns.c,v retrieving revision 1.36 diff -d -u -r1.36 gethostbydns.c --- src/lib/libc/net/gethostbydns.c 26 Jun 2002 14:18:36 -0000 1.36 +++ src/lib/libc/net/gethostbydns.c 10 Aug 2002 10:03:49 -0000 @@ -68,6 +68,7 @@ #include #include +#include #include #include #include @@ -82,18 +83,11 @@ #define SPRINTF(x) ((size_t)sprintf x) -#define MAXALIASES 35 -#define MAXADDRS 35 - static const char AskedForGot[] = "gethostby*.gethostanswer: asked for \"%s\", got \"%s\""; -static char *h_addr_ptrs[MAXADDRS + 1]; - -static struct hostent host; -static char *host_aliases[MAXALIASES]; -static char hostbuf[8*1024]; -static u_char host_addr[16]; /* IPv4 or IPv6 */ +static char hostbuf_s[8*1024]; +static u_char host_addr_s[16]; /* IPv4 or IPv6 */ #ifdef RESOLVSORT static void addrsort(char **, int); @@ -119,7 +113,6 @@ char ac; } align; -extern int h_errno; int _dns_ttl_; #ifdef DEBUG @@ -157,11 +150,14 @@ } while (0) static struct hostent * -gethostanswer(answer, anslen, qname, qtype) +gethostanswer(answer, anslen, qname, qtype, host, hostbuf, hostbuflen) const querybuf *answer; int anslen; const char *qname; int qtype; + struct hostent *host; + char *hostbuf; + int hostbuflen; { const HEADER *hp; const u_char *cp; @@ -176,7 +172,7 @@ int (*name_ok)(const char *); tname = qname; - host.h_name = NULL; + host->h_name = NULL; eom = answer->buf + anslen; switch (qtype) { case T_A: @@ -197,7 +193,7 @@ ancount = ntohs(hp->ancount); qdcount = ntohs(hp->qdcount); bp = hostbuf; - ep = hostbuf + sizeof hostbuf; + ep = hostbuf + hostbuflen; cp = answer->buf; BOUNDED_INCR(HFIXEDSZ); if (qdcount != 1) { @@ -220,17 +216,15 @@ h_errno = NO_RECOVERY; return (NULL); } - host.h_name = bp; + host->h_name = bp; bp += n; /* The qname can be abbreviated, but h_name is now absolute. */ - qname = host.h_name; + qname = host->h_name; } - ap = host_aliases; + ap = host->h_aliases; *ap = NULL; - host.h_aliases = host_aliases; - hap = h_addr_ptrs; + hap = host->h_addr_list; *hap = NULL; - host.h_addr_list = h_addr_ptrs; haveanswer = 0; had_error = 0; _dns_ttl_ = -1; @@ -259,7 +253,7 @@ continue; /* XXX - had_error++ ? */ } if ((qtype == T_A || qtype == T_AAAA) && type == T_CNAME) { - if (ap >= &host_aliases[MAXALIASES-1]) + if (ap >= &host->h_aliases[MAXALIASES-1]) continue; n = dn_expand(answer->buf, eom, cp, tbuf, sizeof tbuf); if ((n < 0) || !(*name_ok)(tbuf)) { @@ -286,7 +280,7 @@ continue; } strcpy(bp, tbuf); - host.h_name = bp; + host->h_name = bp; bp += n; continue; } @@ -341,8 +335,8 @@ return (NULL); } if (!haveanswer) - host.h_name = bp; - else if (ap < &host_aliases[MAXALIASES-1]) + host->h_name = bp; + else if (ap < &host->h_aliases[MAXALIASES-1]) *ap++ = bp; else n = -1; @@ -356,7 +350,7 @@ } break; #else - host.h_name = bp; + host->h_name = bp; if (_res.options & RES_USE_INET6) { n = strlen(bp) + 1; /* for the \0 */ if (n >= MAXHOSTNAMELEN) { @@ -364,27 +358,27 @@ break; } bp += n; - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); } h_errno = NETDB_SUCCESS; - return (&host); + return (host); #endif case T_A: case T_AAAA: - if (strcasecmp(host.h_name, bp) != 0) { + if (strcasecmp(host->h_name, bp) != 0) { syslog(LOG_NOTICE|LOG_AUTH, - AskedForGot, host.h_name, bp); + AskedForGot, host->h_name, bp); cp += n; continue; /* XXX - had_error++ ? */ } - if (n != host.h_length) { + if (n != host->h_length) { cp += n; continue; } if (!haveanswer) { int nn; - host.h_name = bp; + host->h_name = bp; nn = strlen(bp) + 1; /* for the \0 */ bp += nn; } @@ -396,7 +390,7 @@ had_error++; continue; } - if (hap >= &h_addr_ptrs[MAXADDRS-1]) { + if (hap >= &host->h_addr_list[MAXADDRS-1]) { if (!toobig++) dprintf("Too many addresses (%d)\n", MAXADDRS); @@ -430,62 +424,82 @@ * address in that case, not some random one */ if (_res.nsort && haveanswer > 1 && qtype == T_A) - addrsort(h_addr_ptrs, haveanswer); + addrsort(host->h_addr_list, haveanswer); # endif /*RESOLVSORT*/ - if (!host.h_name) { + if (!host->h_name) { n = strlen(qname) + 1; /* for the \0 */ if (n > ep - bp || n >= MAXHOSTNAMELEN) goto no_recovery; strcpy(bp, qname); - host.h_name = bp; + host->h_name = bp; bp += n; } if (_res.options & RES_USE_INET6) - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); h_errno = NETDB_SUCCESS; - return (&host); + return (host); } no_recovery: h_errno = NO_RECOVERY; return (NULL); } -struct hostent * -__dns_getanswer(answer, anslen, qname, qtype) - const char *answer; - int anslen; - const char *qname; - int qtype; -{ - switch(qtype) { - case T_AAAA: - host.h_addrtype = AF_INET6; - host.h_length = IN6ADDRSZ; - break; - case T_A: - default: - host.h_addrtype = AF_INET; - host.h_length = INADDRSZ; - break; - } - - return(gethostanswer((const querybuf *)answer, anslen, qname, qtype)); -} - int _dns_gethostbyname(void *rval, void *cb_data, va_list ap) { const char *name; int af; + struct hostent *host; + char *hostbuf; + int hostbuflen; + u_char *host_addr; querybuf buf; const char *cp; char *bp, *ep; int n, size, type, len; + char abuf[MAXDNAME]; name = va_arg(ap, const char *); af = va_arg(ap, int); + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char *); + hostbuflen = va_arg(ap, int); *(struct hostent **)rval = NULL; + if(hostbuflen != 0 && hostbuf != NULL) { + host->h_aliases = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_aliases + sizeof(char *[MAXALIASES]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host->h_addr_list = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_addr_list + sizeof(char *[MAXADDRS + 1]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host_addr = hostbuf; + bp = (char *)host_addr + sizeof(u_char[16]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < MAXDNAME+1) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + } else { + hostbuf = hostbuf_s; + hostbuflen = sizeof hostbuf_s; + host_addr = host_addr_s; + } + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { h_errno = NETDB_INTERNAL; return NS_UNAVAIL; @@ -506,15 +520,15 @@ return NS_UNAVAIL; } - host.h_addrtype = af; - host.h_length = size; + host->h_addrtype = af; + host->h_length = size; /* * if there aren't any dots, it could be a user-level alias. * this is also done in res_query() since we are not the only * function that looks up host names. */ - if (!strchr(name, '.') && (cp = __hostalias(name))) + if (!strchr(name, '.') && (cp = __hostalias_r(name, abuf, sizeof abuf))) name = cp; /* @@ -538,17 +552,15 @@ strncpy(hostbuf, name, MAXDNAME); hostbuf[MAXDNAME] = '\0'; bp = hostbuf + MAXDNAME; - ep = hostbuf + sizeof hostbuf; - host.h_name = hostbuf; - host.h_aliases = host_aliases; - host_aliases[0] = NULL; - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; + ep = hostbuf + hostbuflen; + host->h_name = hostbuf; + host->h_aliases[0] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; if (_res.options & RES_USE_INET6) - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); h_errno = NETDB_SUCCESS; - *(struct hostent **)rval = &host; + *(struct hostent **)rval = host; return NS_SUCCESS; } if (!isdigit((unsigned char)*cp) && *cp != '.') @@ -572,15 +584,13 @@ strncpy(hostbuf, name, MAXDNAME); hostbuf[MAXDNAME] = '\0'; bp = hostbuf + MAXDNAME; - len = sizeof hostbuf - MAXDNAME; - host.h_name = hostbuf; - host.h_aliases = host_aliases; - host_aliases[0] = NULL; - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; + len = hostbuflen - MAXDNAME; + host->h_name = hostbuf; + host->h_aliases[0] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; h_errno = NETDB_SUCCESS; - *(struct hostent **)rval = &host; + *(struct hostent **)rval = host; return NS_SUCCESS; } if (!isxdigit((unsigned char)*cp) && *cp != ':' && *cp != '.') @@ -591,7 +601,8 @@ dprintf("res_search failed (%d)\n", n); return NS_UNAVAIL; } - *(struct hostent **)rval = gethostanswer(&buf, n, name, type); + *(struct hostent **)rval = gethostanswer(&buf, n, name, type, + host, hostbuf, hostbuflen); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; } @@ -600,6 +611,10 @@ { const char *addr; /* XXX should have been def'd as u_char! */ int len, af; + struct hostent *host; + char *hostbuf; + int hostbuflen; + char *bp; const u_char *uaddr; static const u_char mapped[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0xff,0xff }; static const u_char tunnelled[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 }; @@ -607,6 +622,7 @@ querybuf buf; struct hostent *hp; char qbuf[MAXDNAME+1], *qp; + u_char *host_addr; #ifdef SUNSECURITY struct hostent *rhp; char **haddr; @@ -618,9 +634,45 @@ uaddr = (const u_char *)addr; len = va_arg(ap, int); af = va_arg(ap, int); - + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char*); + hostbuflen = va_arg(ap, int); *(struct hostent **)rval = NULL; + if(hostbuflen != 0 && hostbuf != NULL) { + host->h_aliases = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_aliases + sizeof(char *[MAXALIASES]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host->h_addr_list = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_addr_list + sizeof(char *[MAXADDRS + 1]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host_addr = hostbuf; + bp = (char *)host_addr + sizeof(u_char[16]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < MAXDNAME+1) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + } else { + hostbuf = hostbuf_s; + hostbuflen = sizeof hostbuf_s; + host_addr = host_addr_s; + } + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { h_errno = NETDB_INTERNAL; return NS_UNAVAIL; @@ -680,7 +732,7 @@ dprintf("static buffer is too small (%d)\n", n); return NS_UNAVAIL; } - if (!(hp = gethostanswer(&buf, n, qbuf, T_PTR))) + if (!(hp = gethostanswer(&buf, n, qbuf, T_PTR, host, hostbuf, hostbuflen))) return NS_NOTFOUND; /* h_errno was set by gethostanswer() */ #ifdef SUNSECURITY if (af == AF_INET) { @@ -717,8 +769,8 @@ hp->h_addrtype = af; hp->h_length = len; bcopy(addr, host_addr, len); - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; if (af == AF_INET && (_res.options & RES_USE_INET6)) { _map_v4v6_address((char*)host_addr, (char*)host_addr); hp->h_addrtype = AF_INET6; Index: src/lib/libc/net/gethostbyht.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbyht.c,v retrieving revision 1.16 diff -d -u -r1.16 gethostbyht.c --- src/lib/libc/net/gethostbyht.c 22 Mar 2002 21:52:29 -0000 1.16 +++ src/lib/libc/net/gethostbyht.c 10 Aug 2002 10:03:52 -0000 @@ -62,6 +62,7 @@ #include #include #include +#include #include #include #include @@ -70,49 +71,53 @@ #include /* XXX */ #include /* XXX */ -#define MAXALIASES 35 - -static struct hostent host; -static char *host_aliases[MAXALIASES]; -static char hostbuf[BUFSIZ+1]; -static FILE *hostf = NULL; -static u_int32_t host_addr[4]; /* IPv4 or IPv6 */ static char *h_addr_ptrs[2]; -static int stayopen = 0; +static char *host_aliases[MAXALIASES]; +static struct hostent host_s = { NULL, host_aliases, 0, 0, h_addr_ptrs }; + +static char hostbuf_s[BUFSIZ+1]; +static u_int32_t host_addr_s[4]; /* IPv4 or IPv6 */ void _sethosthtent(f) int f; { - if (!hostf) - hostf = fopen(_PATH_HOSTS, "r" ); + if (!_res_data.hostf) + _res_data.hostf = fopen(_PATH_HOSTS, "r" ); else - rewind(hostf); - stayopen = f; + rewind(_res_data.hostf); + _res_data.stayopen = f; } void _endhosthtent() { - if (hostf && !stayopen) { - (void) fclose(hostf); - hostf = NULL; + if (_res_data.hostf && !_res_data.stayopen) { + (void) fclose(_res_data.hostf); + _res_data.hostf = NULL; } } struct hostent * gethostent() { + + return (gethostent_r(&host_s, hostbuf_s, sizeof hostbuf_s)); +} + +struct hostent * +gethostent_r(struct hostent *host, char *hostbuf, int hostbuflen) +{ char *p; char *cp, **q; int af, len; - if (!hostf && !(hostf = fopen(_PATH_HOSTS, "r" ))) { + if (!_res_data.hostf && !(_res_data.hostf = fopen(_PATH_HOSTS, "r" ))) { h_errno = NETDB_INTERNAL; return (NULL); } again: - if (!(p = fgets(hostbuf, sizeof hostbuf, hostf))) { + if (!(p = fgets(hostbuf, hostbuflen, _res_data.hostf))) { h_errno = HOST_NOT_FOUND; return (NULL); } @@ -124,12 +129,12 @@ if (!(cp = strpbrk(p, " \t"))) goto again; *cp++ = '\0'; - if (inet_pton(AF_INET6, p, host_addr) > 0) { + if (inet_pton(AF_INET6, p, host->h_addr_list[0]) > 0) { af = AF_INET6; len = IN6ADDRSZ; - } else if (inet_pton(AF_INET, p, host_addr) > 0) { + } else if (inet_pton(AF_INET, p, host->h_addr_list[0]) > 0) { if (_res.options & RES_USE_INET6) { - _map_v4v6_address((char*)host_addr, (char*)host_addr); + _map_v4v6_address(host->h_addr_list[0], host->h_addr_list[0]); af = AF_INET6; len = IN6ADDRSZ; } else { @@ -139,15 +144,12 @@ } else { goto again; } - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; - host.h_length = len; - host.h_addrtype = af; + host->h_length = len; + host->h_addrtype = af; while (*cp == ' ' || *cp == '\t') cp++; - host.h_name = cp; - q = host.h_aliases = host_aliases; + host->h_name = cp; + q = host->h_aliases; if ((cp = strpbrk(cp, " \t")) != NULL) *cp++ = '\0'; while (cp && *cp) { @@ -155,14 +157,14 @@ cp++; continue; } - if (q < &host_aliases[MAXALIASES - 1]) + if (q < &host->h_aliases[MAXALIASES - 1]) *q++ = cp; if ((cp = strpbrk(cp, " \t")) != NULL) *cp++ = '\0'; } *q = NULL; h_errno = NETDB_SUCCESS; - return (&host); + return (host); } int @@ -170,14 +172,58 @@ { const char *name; int af; + struct hostent *host; + char *hostbuf, *bp; + int hostbuflen; + u_int32_t *host_addr; struct hostent *p; char **cp; name = va_arg(ap, const char *); af = va_arg(ap, int); + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char*); + hostbuflen = va_arg(ap, int); + if(hostbuflen != 0 && hostbuf != NULL) { + host->h_aliases = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_aliases + sizeof(char *[MAXALIASES]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host->h_addr_list = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_addr_list + sizeof(char *[2]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host_addr = CAST_ALIGN(hostbuf, u_int32_t *); + bp = (char *)host_addr + sizeof(u_int32_t[4]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < BUFSIZ+1) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + } else { + hostbuf = hostbuf_s; + hostbuflen = sizeof hostbuf_s; + host_addr = host_addr_s; + } + + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; + sethostent(0); - while ((p = gethostent()) != NULL) { + while ((p = gethostent_r(host, hostbuf, hostbuflen)) != NULL) { if (p->h_addrtype != af) continue; if (strcasecmp(p->h_name, name) == 0) @@ -198,14 +244,58 @@ { const char *addr; int len, af; + struct hostent *host; + char *hostbuf, *bp; + int hostbuflen; + u_int32_t *host_addr; struct hostent *p; addr = va_arg(ap, const char *); len = va_arg(ap, int); af = va_arg(ap, int); + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char*); + hostbuflen = va_arg(ap, int); + + if(hostbuflen != 0 && hostbuf != NULL) { + host->h_aliases = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_aliases + sizeof(char *[MAXALIASES]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host->h_addr_list = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_addr_list + sizeof(char *[2]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + host_addr = CAST_ALIGN(hostbuf, u_int32_t *); + bp = (char *)host_addr + sizeof(u_int32_t[4]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < BUFSIZ+1) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NS_UNAVAIL); + } + } else { + hostbuf = hostbuf_s; + hostbuflen = sizeof hostbuf_s; + host_addr = host_addr_s; + } + + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; sethostent(0); - while ((p = gethostent()) != NULL) + while ((p = gethostent_r(host, hostbuf, hostbuflen)) != NULL) if (p->h_addrtype == af && !bcmp(p->h_addr, addr, len)) break; endhostent(); Index: src/lib/libc/net/gethostbynis.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbynis.c,v retrieving revision 1.15 diff -d -u -r1.15 gethostbynis.c --- src/lib/libc/net/gethostbynis.c 22 Mar 2002 21:52:29 -0000 1.15 +++ src/lib/libc/net/gethostbynis.c 10 Aug 2002 10:03:52 -0000 @@ -44,29 +44,63 @@ #include #include #endif - -#define MAXALIASES 35 -#define MAXADDRS 35 - -extern int h_errno; +#include #ifdef YP +static char hostbuf_s[8*1024]; +static u_char host_addr_s[16]; + +static char *h_addr_ptrs[2]; static char *host_aliases[MAXALIASES]; -static char hostaddr[MAXADDRS]; -static char *host_addrs[2]; +static struct hostent host_s = { NULL, host_aliases, 0, 0, h_addr_ptrs }; static struct hostent * -_gethostbynis(name, map, af) +_gethostbynis(name, map, af, host, hostbuf, hostbuflen) const char *name; char *map; int af; + struct hostent *host; + char *hostbuf; + int hostbuflen; { - char *cp, **q; + char *bp, *cp, **q; char *result; int resultlen,size; - static struct hostent h; static char *domain = (char *)NULL; - static char ypbuf[YPMAXRECORD + 2]; + + if(hostbuflen != 0 && hostbuf != NULL) { + host->h_aliases = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_aliases + sizeof(char *[MAXALIASES]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NULL); + } + host->h_addr_list = CAST_ALIGN(hostbuf, char **); + bp = (char *)host->h_addr_list + sizeof(char *[2]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NULL); + } + host->h_addr_list[0] = hostbuf; + bp = (char *)host->h_addr_list[0] + sizeof(u_char[16]); + hostbuflen -= (bp - hostbuf); + hostbuf = bp; + if(hostbuflen < 0) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NULL); + } + } else { + hostbuf = hostbuf_s; + hostbuflen = sizeof hostbuf_s; + host->h_addr_list[0] = host_addr_s; + } switch(af) { case AF_INET: @@ -90,27 +124,29 @@ h_errno = HOST_NOT_FOUND; return ((struct hostent *)NULL); } - - /* avoid potential memory leak */ - bcopy((char *)result, (char *)&ypbuf, resultlen); - ypbuf[resultlen] = '\0'; + if (resultlen > hostbuflen) { + h_errno = NO_RECOVERY; + errno = ERANGE; + return (NULL); + } + result[resultlen] = '\0'; + bcopy((char *)result, hostbuf, resultlen); free(result); - result = (char *)&ypbuf; + result = hostbuf; if ((cp = index(result, '\n'))) *cp = '\0'; cp = strpbrk(result, " \t"); *cp++ = '\0'; - h.h_addr_list = host_addrs; - h.h_addr = hostaddr; - *((u_long *)h.h_addr) = inet_addr(result); - h.h_length = size; - h.h_addrtype = AF_INET; + *((u_long *)host->h_addr_list[0]) = inet_addr(result); + host->h_addr_list[1] = NULL; + host->h_length = size; + host->h_addrtype = AF_INET; while (*cp == ' ' || *cp == '\t') cp++; - h.h_name = cp; - q = h.h_aliases = host_aliases; + host->h_name = cp; + q = host->h_aliases; cp = strpbrk(cp, " \t"); if (cp != NULL) *cp++ = '\0'; @@ -119,14 +155,14 @@ cp++; continue; } - if (q < &host_aliases[MAXALIASES - 1]) + if (q < &host->h_aliases[MAXALIASES - 1]) *q++ = cp; cp = strpbrk(cp, " \t"); if (cp != NULL) *cp++ = '\0'; } *q = NULL; - return (&h); + return (host); } #endif /* YP */ @@ -135,7 +171,7 @@ _gethostbynisname(const char *name, int af) { #ifdef YP - return _gethostbynis(name, "hosts.byname", af); + return _gethostbynis(name, "hosts.byname", af, &host_s, NULL, 0); #else return NULL; #endif @@ -146,7 +182,7 @@ { #ifdef YP return _gethostbynis(inet_ntoa(*(struct in_addr *)addr), - "hosts.byaddr", af); + "hosts.byaddr", af, &host_s, NULL, 0); #else return NULL; #endif @@ -159,11 +195,18 @@ #ifdef YP const char *name; int af; + struct hostent *host; + char *hostbuf; + int hostbuflen; name = va_arg(ap, const char *); af = va_arg(ap, int); + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char *); + hostbuflen = va_arg(ap, int); - *(struct hostent **)rval = _gethostbynis(name, "hosts.byname", af); + *(struct hostent **)rval = _gethostbynis(name, "hosts.byname", af, + host, hostbuf, hostbuflen); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; #else return NS_UNAVAIL; @@ -177,12 +220,19 @@ const char *addr; int len; int af; + struct hostent *host; + char *hostbuf; + int hostbuflen; addr = va_arg(ap, const char *); len = va_arg(ap, int); af = va_arg(ap, int); - - *(struct hostent **)rval =_gethostbynis(inet_ntoa(*(struct in_addr *)addr),"hosts.byaddr", af); + host = va_arg(ap, struct hostent *); + hostbuf = va_arg(ap, char *); + hostbuflen = va_arg(ap, int); + + *(struct hostent **)rval =_gethostbynis(inet_ntoa(*(struct in_addr *)addr), + "hosts.byaddr", af, host, hostbuf, hostbuflen); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; #else return NS_UNAVAIL; Index: src/lib/libc/net/gethostnamadr.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostnamadr.c,v retrieving revision 1.20 diff -d -u -r1.20 gethostnamadr.c --- src/lib/libc/net/gethostnamadr.c 22 Mar 2002 21:52:29 -0000 1.20 +++ src/lib/libc/net/gethostnamadr.c 10 Aug 2002 10:03:52 -0000 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -46,6 +47,10 @@ extern int _dns_gethostbyaddr(void *, void *, va_list); extern int _nis_gethostbyaddr(void *, void *, va_list); +static char *h_addr_ptrs[MAXADDRS + 1]; +static char *host_aliases[MAXALIASES]; +static struct hostent host_s = { NULL, host_aliases, 0, 0, h_addr_ptrs }; + /* Host lookup order if nsswitch.conf is broken or nonexistant */ static const ns_src default_src[] = { { NSSRC_FILES, NS_SUCCESS }, @@ -53,25 +58,38 @@ { 0 } }; -struct hostent * -gethostbyname(const char *name) +int +gethostbyname_r(const char *name, struct hostent *resp, + char *buffer, int buflen, int *h_errnop) { - struct hostent *hp; + int rval; if ((_res.options & RES_INIT) == 0 && res_init() == -1) { - h_errno = NETDB_INTERNAL; - return (NULL); + *h_errnop = NO_RECOVERY; + return (NETDB_INTERNAL); } if (_res.options & RES_USE_INET6) { /* XXX */ - hp = gethostbyname2(name, AF_INET6); /* XXX */ - if (hp) /* XXX */ - return (hp); /* XXX */ + rval = gethostbyname2_r(name, AF_INET6, resp, + buffer, buflen, h_errnop); /* XXX */ + if (rval == 0) /* XXX */ + return (0); /* XXX */ } /* XXX */ - return (gethostbyname2(name, AF_INET)); + return (gethostbyname2_r(name, AF_INET, resp, + buffer, buflen, h_errnop)); } struct hostent * -gethostbyname2(const char *name, int type) +gethostbyname(const char *name) +{ + int rval; + + rval = gethostbyname_r(name, &host_s, NULL, 0, &h_errno); + return (rval == 0 ? &host_s : NULL); +} + +int +gethostbyname2_r(const char *name, int type, struct hostent *resp, + char *buffer, int buflen, int *h_errnop) { struct hostent *hp = 0; int rval; @@ -82,18 +100,29 @@ NS_NIS_CB(_nis_gethostbyname, NULL) /* force -DHESIOD */ { 0 } }; - + rval = nsdispatch((void *)&hp, dtab, NSDB_HOSTS, "gethostbyname", - default_src, name, type); + default_src, name, type, resp, buffer, buflen); + *h_errnop = h_errno; if (rval != NS_SUCCESS) - return NULL; + return ((errno == 0) ? -1 : errno); /* Be paranoid */ else - return hp; + return (0); } struct hostent * -gethostbyaddr(const char *addr, int len, int type) +gethostbyname2(const char *name, int type) +{ + int rval; + + rval = gethostbyname2_r(name, type, &host_s, NULL, 0, &h_errno); + return (rval == 0 ? &host_s : NULL); +} + +int +gethostbyaddr_r(const char *addr, int len, int type, struct hostent *resp, + char *buffer, int buflen, int *h_errnop) { struct hostent *hp = 0; int rval; @@ -106,37 +135,28 @@ }; rval = nsdispatch((void *)&hp, dtab, NSDB_HOSTS, "gethostbyaddr", - default_src, addr, len, type); + default_src, addr, len, type, resp, buffer, buflen); + *h_errnop = h_errno; if (rval != NS_SUCCESS) - return NULL; + return ((errno == 0) ? -1 : errno); /* Be paranoid */ else - return hp; + return (0); } -struct hostent_data; - -/* - * Temporary function (not thread safe) - */ -int gethostbyaddr_r(const char *addr, int len, int type, - struct hostent *result, struct hostent_data *buffer) +struct hostent * +gethostbyaddr(const char *addr, int len, int type) { - struct hostent *hp; - int ret; - if ((hp = gethostbyaddr(addr, len, type)) == NULL) { - ret = -1; - } else { - memcpy(result, hp, sizeof(struct hostent)); - ret = 0; - } - return(ret); + int rval; + + rval = gethostbyaddr_r(addr, len, type, NULL, NULL, 0, &h_errno); + return (rval == 0 ? &host_s : NULL); } void -sethostent(stayopen) - int stayopen; +sethostent(int stayopen) { + _sethosthtent(stayopen); _sethostdnsent(stayopen); } @@ -144,6 +164,7 @@ void endhostent() { + _endhosthtent(); _endhostdnsent(); } Index: src/lib/libc/net/getnetbydns.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbydns.c,v retrieving revision 1.21 diff -d -u -r1.21 getnetbydns.c --- src/lib/libc/net/getnetbydns.c 26 Jun 2002 14:18:36 -0000 1.21 +++ src/lib/libc/net/getnetbydns.c 10 Aug 2002 10:03:52 -0000 @@ -82,11 +82,8 @@ #include "res_config.h" -extern int h_errno; - #define BYADDR 0 #define BYNAME 1 -#define MAXALIASES 35 #if PACKETSZ > 1024 #define MAXPACKET PACKETSZ Index: src/lib/libc/net/getnetbyht.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbyht.c,v retrieving revision 1.10 diff -d -u -r1.10 getnetbyht.c --- src/lib/libc/net/getnetbyht.c 22 Mar 2002 21:52:29 -0000 1.10 +++ src/lib/libc/net/getnetbyht.c 10 Aug 2002 10:03:52 -0000 @@ -58,8 +58,7 @@ #include #include #include - -#define MAXALIASES 35 +#include static FILE *netf; static char line[BUFSIZ+1]; Index: src/lib/libc/net/getnetbynis.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbynis.c,v retrieving revision 1.15 diff -d -u -r1.15 getnetbynis.c --- src/lib/libc/net/getnetbynis.c 22 Mar 2002 21:52:29 -0000 1.15 +++ src/lib/libc/net/getnetbynis.c 10 Aug 2002 10:03:52 -0000 @@ -44,9 +44,7 @@ #include #include #endif - -#define MAXALIASES 35 -#define MAXADDRS 35 +#include #ifdef YP static char *host_aliases[MAXALIASES]; Index: src/lib/libc/net/herror.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/herror.c,v retrieving revision 1.11 diff -d -u -r1.11 herror.c --- src/lib/libc/net/herror.c 22 Mar 2002 21:52:29 -0000 1.11 +++ src/lib/libc/net/herror.c 10 Aug 2002 10:03:52 -0000 @@ -71,8 +71,6 @@ }; int h_nerr = { sizeof h_errlist / sizeof h_errlist[0] }; -int h_errno; - /* * herror -- * print the error indicated by the h_errno value. @@ -110,3 +108,19 @@ return (h_errlist[err]); return ("Unknown resolver error"); } + +#undef h_errno +int h_errno; + +/* + * Declare a weak reference in case the application is not linked + * with libpthread. + */ +__weak_reference(__h_errno_accessor_unthreaded, __h_errno_accessor); + +int * +__h_errno_accessor_unthreaded() +{ + return &h_errno; +} + Index: src/lib/libc/net/res_init.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_init.c,v retrieving revision 1.29 diff -d -u -r1.29 res_init.c --- src/lib/libc/net/res_init.c 22 Mar 2002 21:52:30 -0000 1.29 +++ src/lib/libc/net/res_init.c 10 Aug 2002 10:03:55 -0000 @@ -104,17 +104,6 @@ # define isascii(c) (!(c & 0200)) #endif -/* - * Resolver state default settings. - */ - -struct __res_state _res -# if defined(__BIND_RES_TEXT) - = { RES_TIMEOUT, } /* Motorola, et al. */ -# endif - ; - -struct __res_state_ext _res_ext; /* * Set up default settings. If the configuration file exist, the values @@ -154,6 +143,9 @@ #ifndef RFC1535 int dots; #endif + + if(&_res_data==NULL) + return -1; /* * These three fields used to be statically initialized. This made @@ -582,3 +574,43 @@ */ #undef res_init __weak_reference(__res_init, res_init); + +/* + * Resolver state default settings. + */ + +#undef _res +#undef _res_ext +#undef _res_data + +struct __res_state _res +# if defined(__BIND_RES_TEXT) + = { RES_TIMEOUT, } /* Motorola, et al. */ +# endif + ; + +struct __res_state_ext _res_ext; + +struct __res_data _res_data = { 0, -1, 0, 0, 0, NULL, NULL, NULL, 0, &_res, + &_res_ext }; + +/* + * Declare a weak reference in case the application is not linked + * with libpthread. + */ +__weak_reference(__res_data_accessor_unthreaded, __res_data_accessor); +__weak_reference(__res_accessor_unthreaded, __res_accessor); + +struct __res_data * +__res_data_accessor_unthreaded() +{ + + return &_res_data; +} + +struct __res_state * +__res_accessor_unthreaded() +{ + + return _res_data.res; +} Index: src/lib/libc/net/res_query.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_query.c,v retrieving revision 1.23 diff -d -u -r1.23 res_query.c --- src/lib/libc/net/res_query.c 7 Jul 2002 11:28:28 -0000 1.23 +++ src/lib/libc/net/res_query.c 10 Aug 2002 10:03:55 -0000 @@ -87,6 +87,7 @@ #include #include #include +#include #include "res_config.h" @@ -374,11 +375,20 @@ hostalias(name) const char *name; { + static char abuf[MAXDNAME]; + return (hostalias_r(name, abuf, sizeof abuf)); +} + +const char * +hostalias_r(name, abuf, len) + const char *name; + char *abuf; + int len; +{ char *cp1, *cp2; FILE *fp; char *file; char buf[BUFSIZ]; - static char abuf[MAXDNAME]; if (_res.options & RES_NOALIASES) return (NULL); @@ -402,8 +412,8 @@ break; for (cp2 = cp1 + 1; *cp2 && !isspace((unsigned char)*cp2); ++cp2) ; - abuf[sizeof(abuf) - 1] = *cp2 = '\0'; - strncpy(abuf, cp1, sizeof(abuf) - 1); + abuf[len - 1] = *cp2 = '\0'; + strncpy(abuf, cp1, len - 1); fclose(fp); return (abuf); } Index: src/lib/libc/net/res_send.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_send.c,v retrieving revision 1.45 diff -d -u -r1.45 res_send.c --- src/lib/libc/net/res_send.c 1 Apr 2002 16:09:45 -0000 1.45 +++ src/lib/libc/net/res_send.c 10 Aug 2002 10:03:56 -0000 @@ -102,13 +102,6 @@ #include "res_config.h" -static int s = -1; /* socket used for communications */ -static int connected = 0; /* is the socket connected */ -static int vc = 0; /* is the socket a virtual circuit? */ -static int af = 0; /* address family of socket */ -static res_send_qhook Qhook = NULL; -static res_send_rhook Rhook = NULL; - #define CAN_RECONNECT 1 @@ -170,7 +163,7 @@ res_send_qhook hook; { - Qhook = hook; + _res_data.Qhook = hook; } void @@ -178,7 +171,7 @@ res_send_rhook hook; { - Rhook = hook; + _res_data.Rhook = hook; } static struct sockaddr * get_nsaddr(size_t); @@ -406,13 +399,13 @@ goto next_ns; } - if (Qhook) { + if (_res_data.Qhook) { int done = 0, loops = 0; do { res_sendhookact act; - act = (*Qhook)((struct sockaddr_in **)&nsap, + act = (*_res_data.Qhook)((struct sockaddr_in **)&nsap, &buf, &buflen, ans, anssiz, &resplen); switch (act) { @@ -457,14 +450,14 @@ */ try = _res.retry; truncated = 0; - if (s < 0 || !vc || hp->opcode == ns_o_update || - af != nsap->sa_family) { - if (s >= 0) + if (_res_data.s < 0 || !_res_data.vc || hp->opcode == ns_o_update || + _res_data.af != nsap->sa_family) { + if (_res_data.s >= 0) res_close(); - af = nsap->sa_family; - s = _socket(af, SOCK_STREAM, 0); - if (s < 0) { + _res_data.af = nsap->sa_family; + _res_data.s = _socket(_res_data.af, SOCK_STREAM, 0); + if (_res_data.s < 0) { terrno = errno; Perror(stderr, "socket(vc)", errno); badns |= (1 << ns); @@ -472,7 +465,7 @@ goto next_ns; } errno = 0; - if (_connect(s, nsap, salen) < 0) { + if (_connect(_res_data.s, nsap, salen) < 0) { terrno = errno; Aerror(stderr, "connect/vc", errno, nsap); @@ -480,7 +473,7 @@ res_close(); goto next_ns; } - vc = 1; + _res_data.vc = 1; } /* * Send length & message @@ -490,7 +483,7 @@ iov[0].iov_len = INT16SZ; iov[1].iov_base = (caddr_t)buf; iov[1].iov_len = buflen; - if (_writev(s, iov, 2) != (INT16SZ + buflen)) { + if (_writev(_res_data.s, iov, 2) != (INT16SZ + buflen)) { terrno = errno; Perror(stderr, "write failed", errno); badns |= (1 << ns); @@ -503,7 +496,7 @@ read_len: cp = ans; len = INT16SZ; - while ((n = _read(s, (char *)cp, (int)len)) > 0) { + while ((n = _read(_res_data.s, (char *)cp, (int)len)) > 0) { cp += n; if ((len -= n) <= 0) break; @@ -551,7 +544,7 @@ } cp = ans; while (len != 0 && - (n = _read(s, (char *)cp, (int)len)) > 0) { + (n = _read(_res_data.s, (char *)cp, (int)len)) > 0) { cp += n; len -= n; } @@ -574,7 +567,7 @@ n = (len > sizeof(junk) ? sizeof(junk) : len); - if ((n = _read(s, junk, n)) > 0) + if ((n = _read(_res_data.s, junk, n)) > 0) len -= n; else break; @@ -604,12 +597,13 @@ struct sockaddr_storage from; int fromlen; - if (s < 0 || vc || af != nsap->sa_family) { - if (vc) + if (_res_data.s < 0 || _res_data.vc || + _res_data.af != nsap->sa_family) { + if (_res_data.vc) res_close(); - af = nsap->sa_family; - s = _socket(af, SOCK_DGRAM, 0); - if (s < 0) { + _res_data.af = nsap->sa_family; + _res_data.s = _socket(_res_data.af, SOCK_DGRAM, 0); + if (_res_data.s < 0) { #ifndef CAN_RECONNECT bad_dg_sock: #endif @@ -619,7 +613,7 @@ res_close(); goto next_ns; } - connected = 0; + _res_data.connected = 0; } #ifndef CANNOT_CONNECT_DGRAM /* @@ -650,8 +644,8 @@ * Connect only if we are sure we won't * receive a response from another server. */ - if (!connected) { - if (_connect(s, nsap, salen) < 0) { + if (!_res_data.connected) { + if (_connect(_res_data.s, nsap, salen) < 0) { Aerror(stderr, "connect(dg)", errno, nsap); @@ -659,9 +653,9 @@ res_close(); goto next_ns; } - connected = 1; + _res_data.connected = 1; } - if (send(s, (char*)buf, buflen, 0) != buflen) { + if (send(_res_data.s, (char*)buf, buflen, 0) != buflen) { Perror(stderr, "send", errno); badns |= (1 << ns); res_close(); @@ -672,7 +666,7 @@ * Disconnect if we want to listen * for responses from more than one server. */ - if (connected) { + if (_res_data.connected) { #ifdef CAN_RECONNECT /* XXX: any errornous address */ struct sockaddr_in no_addr; @@ -680,24 +674,24 @@ no_addr.sin_family = AF_INET; no_addr.sin_addr.s_addr = INADDR_ANY; no_addr.sin_port = 0; - (void) _connect(s, + (void) _connect(_res_data.s, (struct sockaddr *) &no_addr, sizeof no_addr); #else - int s1 = _socket(af, SOCK_DGRAM,0); + int s1 = _socket(_res_data.af, SOCK_DGRAM,0); if (s1 < 0) goto bad_dg_sock; - (void)_dup2(s1, s); + (void)_dup2(s1, _res_data.s); (void)_close(s1); Dprint(_res.options & RES_DEBUG, (stdout, ";; new DG socket\n")) #endif /* CAN_RECONNECT */ - connected = 0; + _res_data.connected = 0; errno = 0; } #endif /* !CANNOT_CONNECT_DGRAM */ - if (_sendto(s, (char*)buf, buflen, 0, + if (_sendto(_res_data.s, (char*)buf, buflen, 0, nsap, salen) != buflen) { Aerror(stderr, "sendto", errno, nsap); badns |= (1 << ns); @@ -722,13 +716,13 @@ (void) gettimeofday(&ctv, NULL); timeradd(&timeout, &ctv, &timeout); wait: - if (s < 0) { + if (_res_data.s < 0) { Perror(stderr, "s out-of-bounds", EMFILE); res_close(); goto next_ns; } - EV_SET(&kv, s, EVFILT_READ, EV_ADD | EV_ONESHOT, 0,0,0); + EV_SET(&kv, _res_data.s, EVFILT_READ, EV_ADD | EV_ONESHOT, 0,0,0); n = _kevent(kq, &kv, 1, &kv, 1, &ts); if (n < 0) { @@ -757,7 +751,7 @@ } errno = 0; fromlen = sizeof(from); - resplen = _recvfrom(s, (char*)ans, anssiz, 0, + resplen = _recvfrom(_res_data.s, (char*)ans, anssiz, 0, (struct sockaddr *)&from, &fromlen); if (resplen <= 0) { Perror(stderr, "recvfrom", errno); @@ -862,13 +856,13 @@ !(_res.options & RES_STAYOPEN)) { res_close(); } - if (Rhook) { + if (_res_data.Rhook) { int done = 0, loops = 0; do { res_sendhookact act; - act = (*Rhook)((struct sockaddr_in *)nsap, + act = (*_res_data.Rhook)((struct sockaddr_in *)nsap, buf, buflen, ans, anssiz, &resplen); switch (act) { @@ -920,12 +914,12 @@ void res_close() { - if (s >= 0) { - (void)_close(s); - s = -1; - connected = 0; - vc = 0; - af = 0; + if (_res_data.s >= 0) { + (void)_close(_res_data.s); + _res_data.s = -1; + _res_data.connected = 0; + _res_data.vc = 0; + _res_data.af = 0; } } Index: src/lib/libc_r/sys/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc_r/sys/Makefile.inc,v retrieving revision 1.10 diff -d -u -r1.10 Makefile.inc --- src/lib/libc_r/sys/Makefile.inc 28 Aug 1999 00:03:13 -0000 1.10 +++ src/lib/libc_r/sys/Makefile.inc 10 Aug 2002 10:03:56 -0000 @@ -2,5 +2,5 @@ .PATH: ${.CURDIR}/sys ${.CURDIR}/arch/${MACHINE_ARCH} -SRCS+= uthread_error.c _atomic_lock.S +SRCS+= uthread_error.c uthread_resolv.c _atomic_lock.S Index: src/lib/libc_r/sys/uthread_resolv.c =================================================================== RCS file: src/lib/libc_r/sys/uthread_resolv.c diff -N src/lib/libc_r/sys/uthread_resolv.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/lib/libc_r/sys/uthread_resolv.c 10 Aug 2002 10:03:56 -0000 @@ -0,0 +1,151 @@ +/*- + * Copyright (c) 2001 Alexandr Litvin + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include "pthread_private.h" + +#undef h_errno +#undef _res +#undef _res_ext +#undef _res_data + +extern int h_errno; +extern struct __res_data _res_data; + +static pthread_once_t once = PTHREAD_ONCE_INIT; +static pthread_key_t key; + + +static void +__res_data_destroy(void *p) +{ + struct __res_data *_res_datap = (struct __res_data *)p; + + if(_res_datap->res) + free(_res_datap->res); + if(_res_datap->res_ext) + free(_res_datap->res_ext); + if(_res_datap->s >= 0) + close(_res_datap->s); + if(_res_datap->hostf) + fclose(_res_datap->hostf); + free(_res_datap); +} + +static void +__res_data_init() +{ + + pthread_key_create(&key, __res_data_destroy); +} + +struct __res_data * +__res_data_accessor() +{ + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + _res_datap = &_res_data; + } else { + pthread_once(&once, __res_data_init); + _res_datap = (struct __res_data *)pthread_getspecific(key); + if(_res_datap==NULL) { + _res_datap = malloc(sizeof(struct __res_data)); + if(_res_datap==NULL) + return (NULL); + bzero(_res_datap, sizeof(struct __res_data)); + _res_datap->res = malloc(sizeof(struct __res_state)); + if(_res_datap->res == NULL) { + free(_res_datap); + return (NULL); + } + bzero(_res_datap->res, sizeof(struct __res_state)); + _res_datap->res_ext = + malloc(sizeof(struct __res_state_ext)); + if(_res_datap->res_ext == NULL) { + free(_res_datap->res); + free(_res_datap); + return (NULL); + } + bzero(_res_datap->res_ext, + sizeof(struct __res_state_ext)); + _res_datap->s = -1; + pthread_setspecific(key, _res_datap); + } + } + return (_res_datap); +} + +static struct __res_state dummy_res; +static int dummy_h_errno; + +struct __res_state * +__res_accessor() +{ + struct __res_state *resp; + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + resp = _res_data.res; + } else { + _res_datap = __res_data_accessor(); + if(_res_datap) { + resp = _res_datap->res; + } else { + dummy_res.options = RES_DEFAULT; + resp = &dummy_res; + } + } + return (resp); +} + +int * +__h_errno_accessor() +{ + int *h_errnop; + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + h_errnop = &h_errno; + } else { + _res_datap = __res_data_accessor(); + if(_res_datap) { + h_errnop = &_res_datap->h_errno_res; + } else { + dummy_h_errno = NETDB_INTERNAL; + h_errnop = &dummy_h_errno; + } + } + return (h_errnop); +} --------------051496A982500B2DDF1E4FCD Content-Type: text/plain; charset=koi8-r; name="resolv_r-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="resolv_r-2.diff" Index: src/include/netdb.h =================================================================== RCS file: /home/ncvs/src/include/netdb.h,v retrieving revision 1.24 diff -d -u -r1.24 netdb.h --- src/include/netdb.h 26 Jun 2002 08:18:42 -0000 1.24 +++ src/include/netdb.h 12 Aug 2002 09:48:11 -0000 @@ -82,7 +82,10 @@ #define _PATH_PROTOCOLS "/etc/protocols" #define _PATH_SERVICES "/etc/services" -extern int h_errno; +__BEGIN_DECLS +int * __h_errno_accessor(void); +__END_DECLS +#define h_errno (* __h_errno_accessor()) /* * Structures returned by network data base library. All addresses are Index: src/include/resolv.h =================================================================== RCS file: /home/ncvs/src/include/resolv.h,v retrieving revision 1.21 diff -d -u -r1.21 resolv.h --- src/include/resolv.h 23 Mar 2002 17:24:53 -0000 1.21 +++ src/include/resolv.h 12 Aug 2002 09:48:11 -0000 @@ -62,6 +62,7 @@ #include #include #include +#include /* * Revision information. This is the release date in YYYYMMDD format. @@ -90,6 +91,8 @@ #define MAXDFLSRCH 3 /* # default domain levels to try */ #define MAXDNSRCH 6 /* max # domains in search path */ #define LOCALDOMAINPARTS 2 /* min levels in name that is "local" */ +#define MAXALIASES 35 /* max # of aliases to return */ +#define MAXADDRS 35 /* max # of addresses to return */ #define RES_TIMEOUT 5 /* min. seconds between retries */ #define MAXRESOLVSORT 10 /* number of net to sort on */ @@ -198,10 +201,6 @@ char * humanname; /* Its fun name, like "mail exchanger" */ }; -extern struct __res_state _res; -/* for INET6 */ -extern struct __res_state_ext _res_ext; - extern const struct res_sym __p_class_syms[]; extern const struct res_sym __p_type_syms[]; @@ -224,6 +223,7 @@ #define fp_query __fp_query #define fp_nquery __fp_nquery #define hostalias __hostalias +#define hostalias_r __hostalias_r #define putlong __putlong #define putshort __putshort #define p_class __p_class @@ -273,6 +273,7 @@ void fp_query(const u_char *, FILE *); void fp_nquery(const u_char *, int, FILE *); const char * hostalias(const char *); +const char * hostalias_r(const char *, char *, int); void putlong(u_int32_t, u_char *); void putshort(u_int16_t, u_char *); const char * p_class(int); @@ -315,5 +316,35 @@ void res_freeupdrec(ns_updrec *); #endif __END_DECLS + +struct __res_data { + int h_errno_res; + int s; /* socket used for communications */ + int connected : 1; /* is the socket connected */ + int vc : 1; /* is the socket a virtual circuit? */ + int af; /* address family of socket */ + res_send_qhook Qhook; + res_send_rhook Rhook; + FILE* hostf; + int stayopen; + struct hostent host; + char *hostbuf; + int hostbuflen; + u_char *host_addr; + int host_addrlen; + struct __res_state *res; + struct __res_state_ext *res_ext; +}; + +__BEGIN_DECLS +u_int16_t _getshort(const u_char *); +u_int32_t _getlong(const u_char *); +struct __res_data * __res_data_accessor(void); +struct __res_state * __res_accessor(void); +__END_DECLS +#define _res_data (* __res_data_accessor()) +#define _res (* __res_accessor()) +/* for INET6 */ +#define _res_ext (* (__res_data_accessor()->res_ext)) #endif /* !_RESOLV_H_ */ Index: src/lib/libc/net/getaddrinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getaddrinfo.c,v retrieving revision 1.28 diff -d -u -r1.28 getaddrinfo.c --- src/lib/libc/net/getaddrinfo.c 2 Aug 2002 11:58:48 -0000 1.28 +++ src/lib/libc/net/getaddrinfo.c 12 Aug 2002 09:48:17 -0000 @@ -1673,7 +1673,6 @@ /* resolver logic */ extern const char *__hostalias(const char *); -extern int h_errno; /* * Formulate a normal query, send, and await answer. Index: src/lib/libc/net/gethostbydns.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbydns.c,v retrieving revision 1.36 diff -d -u -r1.36 gethostbydns.c --- src/lib/libc/net/gethostbydns.c 26 Jun 2002 14:18:36 -0000 1.36 +++ src/lib/libc/net/gethostbydns.c 12 Aug 2002 09:48:17 -0000 @@ -68,6 +68,7 @@ #include #include +#include #include #include #include @@ -82,19 +83,9 @@ #define SPRINTF(x) ((size_t)sprintf x) -#define MAXALIASES 35 -#define MAXADDRS 35 - static const char AskedForGot[] = "gethostby*.gethostanswer: asked for \"%s\", got \"%s\""; -static char *h_addr_ptrs[MAXADDRS + 1]; - -static struct hostent host; -static char *host_aliases[MAXALIASES]; -static char hostbuf[8*1024]; -static u_char host_addr[16]; /* IPv4 or IPv6 */ - #ifdef RESOLVSORT static void addrsort(char **, int); #endif @@ -119,7 +110,6 @@ char ac; } align; -extern int h_errno; int _dns_ttl_; #ifdef DEBUG @@ -157,11 +147,14 @@ } while (0) static struct hostent * -gethostanswer(answer, anslen, qname, qtype) +gethostanswer(answer, anslen, qname, qtype, host, hostbuf, hostbuflen) const querybuf *answer; int anslen; const char *qname; int qtype; + struct hostent *host; + char *hostbuf; + int hostbuflen; { const HEADER *hp; const u_char *cp; @@ -176,7 +169,7 @@ int (*name_ok)(const char *); tname = qname; - host.h_name = NULL; + host->h_name = NULL; eom = answer->buf + anslen; switch (qtype) { case T_A: @@ -197,7 +190,7 @@ ancount = ntohs(hp->ancount); qdcount = ntohs(hp->qdcount); bp = hostbuf; - ep = hostbuf + sizeof hostbuf; + ep = hostbuf + hostbuflen; cp = answer->buf; BOUNDED_INCR(HFIXEDSZ); if (qdcount != 1) { @@ -220,17 +213,15 @@ h_errno = NO_RECOVERY; return (NULL); } - host.h_name = bp; + host->h_name = bp; bp += n; /* The qname can be abbreviated, but h_name is now absolute. */ - qname = host.h_name; + qname = host->h_name; } - ap = host_aliases; + ap = host->h_aliases; *ap = NULL; - host.h_aliases = host_aliases; - hap = h_addr_ptrs; + hap = host->h_addr_list; *hap = NULL; - host.h_addr_list = h_addr_ptrs; haveanswer = 0; had_error = 0; _dns_ttl_ = -1; @@ -259,7 +250,7 @@ continue; /* XXX - had_error++ ? */ } if ((qtype == T_A || qtype == T_AAAA) && type == T_CNAME) { - if (ap >= &host_aliases[MAXALIASES-1]) + if (ap >= &host->h_aliases[MAXALIASES-1]) continue; n = dn_expand(answer->buf, eom, cp, tbuf, sizeof tbuf); if ((n < 0) || !(*name_ok)(tbuf)) { @@ -286,7 +277,7 @@ continue; } strcpy(bp, tbuf); - host.h_name = bp; + host->h_name = bp; bp += n; continue; } @@ -341,8 +332,8 @@ return (NULL); } if (!haveanswer) - host.h_name = bp; - else if (ap < &host_aliases[MAXALIASES-1]) + host->h_name = bp; + else if (ap < &host->h_aliases[MAXALIASES-1]) *ap++ = bp; else n = -1; @@ -356,7 +347,7 @@ } break; #else - host.h_name = bp; + host->h_name = bp; if (_res.options & RES_USE_INET6) { n = strlen(bp) + 1; /* for the \0 */ if (n >= MAXHOSTNAMELEN) { @@ -364,27 +355,27 @@ break; } bp += n; - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); } h_errno = NETDB_SUCCESS; - return (&host); + return (host); #endif case T_A: case T_AAAA: - if (strcasecmp(host.h_name, bp) != 0) { + if (strcasecmp(host->h_name, bp) != 0) { syslog(LOG_NOTICE|LOG_AUTH, - AskedForGot, host.h_name, bp); + AskedForGot, host->h_name, bp); cp += n; continue; /* XXX - had_error++ ? */ } - if (n != host.h_length) { + if (n != host->h_length) { cp += n; continue; } if (!haveanswer) { int nn; - host.h_name = bp; + host->h_name = bp; nn = strlen(bp) + 1; /* for the \0 */ bp += nn; } @@ -396,7 +387,7 @@ had_error++; continue; } - if (hap >= &h_addr_ptrs[MAXADDRS-1]) { + if (hap >= &host->h_addr_list[MAXADDRS-1]) { if (!toobig++) dprintf("Too many addresses (%d)\n", MAXADDRS); @@ -430,57 +421,40 @@ * address in that case, not some random one */ if (_res.nsort && haveanswer > 1 && qtype == T_A) - addrsort(h_addr_ptrs, haveanswer); + addrsort(host->h_addr_list, haveanswer); # endif /*RESOLVSORT*/ - if (!host.h_name) { + if (!host->h_name) { n = strlen(qname) + 1; /* for the \0 */ if (n > ep - bp || n >= MAXHOSTNAMELEN) goto no_recovery; strcpy(bp, qname); - host.h_name = bp; + host->h_name = bp; bp += n; } if (_res.options & RES_USE_INET6) - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); h_errno = NETDB_SUCCESS; - return (&host); + return (host); } no_recovery: h_errno = NO_RECOVERY; return (NULL); } -struct hostent * -__dns_getanswer(answer, anslen, qname, qtype) - const char *answer; - int anslen; - const char *qname; - int qtype; -{ - switch(qtype) { - case T_AAAA: - host.h_addrtype = AF_INET6; - host.h_length = IN6ADDRSZ; - break; - case T_A: - default: - host.h_addrtype = AF_INET; - host.h_length = INADDRSZ; - break; - } - - return(gethostanswer((const querybuf *)answer, anslen, qname, qtype)); -} - int _dns_gethostbyname(void *rval, void *cb_data, va_list ap) { const char *name; int af; + struct hostent *host; + char *hostbuf; + int hostbuflen; + u_char *host_addr; querybuf buf; const char *cp; char *bp, *ep; int n, size, type, len; + char abuf[MAXDNAME]; name = va_arg(ap, const char *); af = va_arg(ap, int); @@ -491,6 +465,11 @@ return NS_UNAVAIL; } + host = &_res_data.host; + hostbuf = _res_data.hostbuf; + hostbuflen = _res_data.hostbuflen; + host_addr = _res_data.host_addr; + switch (af) { case AF_INET: size = INADDRSZ; @@ -506,15 +485,15 @@ return NS_UNAVAIL; } - host.h_addrtype = af; - host.h_length = size; + host->h_addrtype = af; + host->h_length = size; /* * if there aren't any dots, it could be a user-level alias. * this is also done in res_query() since we are not the only * function that looks up host names. */ - if (!strchr(name, '.') && (cp = __hostalias(name))) + if (!strchr(name, '.') && (cp = __hostalias_r(name, abuf, sizeof abuf))) name = cp; /* @@ -538,17 +517,15 @@ strncpy(hostbuf, name, MAXDNAME); hostbuf[MAXDNAME] = '\0'; bp = hostbuf + MAXDNAME; - ep = hostbuf + sizeof hostbuf; - host.h_name = hostbuf; - host.h_aliases = host_aliases; - host_aliases[0] = NULL; - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; + ep = hostbuf + hostbuflen; + host->h_name = hostbuf; + host->h_aliases[0] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; if (_res.options & RES_USE_INET6) - _map_v4v6_hostent(&host, &bp, &ep); + _map_v4v6_hostent(host, &bp, &ep); h_errno = NETDB_SUCCESS; - *(struct hostent **)rval = &host; + *(struct hostent **)rval = host; return NS_SUCCESS; } if (!isdigit((unsigned char)*cp) && *cp != '.') @@ -572,15 +549,13 @@ strncpy(hostbuf, name, MAXDNAME); hostbuf[MAXDNAME] = '\0'; bp = hostbuf + MAXDNAME; - len = sizeof hostbuf - MAXDNAME; - host.h_name = hostbuf; - host.h_aliases = host_aliases; - host_aliases[0] = NULL; - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; + len = hostbuflen - MAXDNAME; + host->h_name = hostbuf; + host->h_aliases[0] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; h_errno = NETDB_SUCCESS; - *(struct hostent **)rval = &host; + *(struct hostent **)rval = host; return NS_SUCCESS; } if (!isxdigit((unsigned char)*cp) && *cp != ':' && *cp != '.') @@ -591,7 +566,8 @@ dprintf("res_search failed (%d)\n", n); return NS_UNAVAIL; } - *(struct hostent **)rval = gethostanswer(&buf, n, name, type); + *(struct hostent **)rval = gethostanswer(&buf, n, name, type, + host, hostbuf, hostbuflen); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; } @@ -600,6 +576,9 @@ { const char *addr; /* XXX should have been def'd as u_char! */ int len, af; + struct hostent *host; + char *hostbuf; + int hostbuflen; const u_char *uaddr; static const u_char mapped[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0xff,0xff }; static const u_char tunnelled[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 }; @@ -607,6 +586,7 @@ querybuf buf; struct hostent *hp; char qbuf[MAXDNAME+1], *qp; + u_char *host_addr; #ifdef SUNSECURITY struct hostent *rhp; char **haddr; @@ -618,13 +598,19 @@ uaddr = (const u_char *)addr; len = va_arg(ap, int); af = va_arg(ap, int); - + *(struct hostent **)rval = NULL; if ((_res.options & RES_INIT) == 0 && res_init() == -1) { h_errno = NETDB_INTERNAL; return NS_UNAVAIL; } + + host = &_res_data.host; + hostbuf = _res_data.hostbuf; + hostbuflen = _res_data.hostbuflen; + host_addr = _res_data.host_addr; + if (af == AF_INET6 && len == IN6ADDRSZ && (!bcmp(uaddr, mapped, sizeof mapped) || !bcmp(uaddr, tunnelled, sizeof tunnelled))) { @@ -680,7 +666,8 @@ dprintf("static buffer is too small (%d)\n", n); return NS_UNAVAIL; } - if (!(hp = gethostanswer(&buf, n, qbuf, T_PTR))) + if (!(hp = gethostanswer(&buf, n, qbuf, T_PTR, host, hostbuf, + hostbuflen))) return NS_NOTFOUND; /* h_errno was set by gethostanswer() */ #ifdef SUNSECURITY if (af == AF_INET) { @@ -717,8 +704,8 @@ hp->h_addrtype = af; hp->h_length = len; bcopy(addr, host_addr, len); - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; + host->h_addr_list[0] = (char *)host_addr; + host->h_addr_list[1] = NULL; if (af == AF_INET && (_res.options & RES_USE_INET6)) { _map_v4v6_address((char*)host_addr, (char*)host_addr); hp->h_addrtype = AF_INET6; Index: src/lib/libc/net/gethostbyht.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbyht.c,v retrieving revision 1.16 diff -d -u -r1.16 gethostbyht.c --- src/lib/libc/net/gethostbyht.c 22 Mar 2002 21:52:29 -0000 1.16 +++ src/lib/libc/net/gethostbyht.c 12 Aug 2002 09:48:20 -0000 @@ -62,6 +62,7 @@ #include #include #include +#include #include #include #include @@ -70,33 +71,35 @@ #include /* XXX */ #include /* XXX */ -#define MAXALIASES 35 - -static struct hostent host; -static char *host_aliases[MAXALIASES]; -static char hostbuf[BUFSIZ+1]; -static FILE *hostf = NULL; -static u_int32_t host_addr[4]; /* IPv4 or IPv6 */ -static char *h_addr_ptrs[2]; -static int stayopen = 0; - void _sethosthtent(f) int f; { - if (!hostf) - hostf = fopen(_PATH_HOSTS, "r" ); + + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return; + } + + if (!_res_data.hostf) + _res_data.hostf = fopen(_PATH_HOSTS, "r" ); else - rewind(hostf); - stayopen = f; + rewind(_res_data.hostf); + _res_data.stayopen = f; } void _endhosthtent() { - if (hostf && !stayopen) { - (void) fclose(hostf); - hostf = NULL; + + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return; + } + + if (_res_data.hostf && !_res_data.stayopen) { + (void) fclose(_res_data.hostf); + _res_data.hostf = NULL; } } @@ -106,13 +109,27 @@ char *p; char *cp, **q; int af, len; + struct hostent *host; + char *hostbuf; + int hostbuflen; - if (!hostf && !(hostf = fopen(_PATH_HOSTS, "r" ))) { + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return NULL; + } + + host = &_res_data.host; + hostbuf = _res_data.hostbuf; + hostbuflen = _res_data.hostbuflen; + host->h_addr_list[0] = _res_data.host_addr; + host->h_addr_list[1] = NULL; + + if (!_res_data.hostf && !(_res_data.hostf = fopen(_PATH_HOSTS, "r" ))) { h_errno = NETDB_INTERNAL; return (NULL); } again: - if (!(p = fgets(hostbuf, sizeof hostbuf, hostf))) { + if (!(p = fgets(hostbuf, hostbuflen, _res_data.hostf))) { h_errno = HOST_NOT_FOUND; return (NULL); } @@ -124,12 +141,12 @@ if (!(cp = strpbrk(p, " \t"))) goto again; *cp++ = '\0'; - if (inet_pton(AF_INET6, p, host_addr) > 0) { + if (inet_pton(AF_INET6, p, host->h_addr_list[0]) > 0) { af = AF_INET6; len = IN6ADDRSZ; - } else if (inet_pton(AF_INET, p, host_addr) > 0) { + } else if (inet_pton(AF_INET, p, host->h_addr_list[0]) > 0) { if (_res.options & RES_USE_INET6) { - _map_v4v6_address((char*)host_addr, (char*)host_addr); + _map_v4v6_address(host->h_addr_list[0], host->h_addr_list[0]); af = AF_INET6; len = IN6ADDRSZ; } else { @@ -139,15 +156,12 @@ } else { goto again; } - h_addr_ptrs[0] = (char *)host_addr; - h_addr_ptrs[1] = NULL; - host.h_addr_list = h_addr_ptrs; - host.h_length = len; - host.h_addrtype = af; + host->h_length = len; + host->h_addrtype = af; while (*cp == ' ' || *cp == '\t') cp++; - host.h_name = cp; - q = host.h_aliases = host_aliases; + host->h_name = cp; + q = host->h_aliases; if ((cp = strpbrk(cp, " \t")) != NULL) *cp++ = '\0'; while (cp && *cp) { @@ -155,14 +169,14 @@ cp++; continue; } - if (q < &host_aliases[MAXALIASES - 1]) + if (q < &host->h_aliases[MAXALIASES - 1]) *q++ = cp; if ((cp = strpbrk(cp, " \t")) != NULL) *cp++ = '\0'; } *q = NULL; h_errno = NETDB_SUCCESS; - return (&host); + return (host); } int @@ -175,7 +189,7 @@ name = va_arg(ap, const char *); af = va_arg(ap, int); - + sethostent(0); while ((p = gethostent()) != NULL) { if (p->h_addrtype != af) Index: src/lib/libc/net/gethostbynis.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostbynis.c,v retrieving revision 1.15 diff -d -u -r1.15 gethostbynis.c --- src/lib/libc/net/gethostbynis.c 22 Mar 2002 21:52:29 -0000 1.15 +++ src/lib/libc/net/gethostbynis.c 12 Aug 2002 09:48:20 -0000 @@ -44,16 +44,9 @@ #include #include #endif - -#define MAXALIASES 35 -#define MAXADDRS 35 - -extern int h_errno; +#include #ifdef YP -static char *host_aliases[MAXALIASES]; -static char hostaddr[MAXADDRS]; -static char *host_addrs[2]; static struct hostent * _gethostbynis(name, map, af) @@ -64,9 +57,20 @@ char *cp, **q; char *result; int resultlen,size; - static struct hostent h; static char *domain = (char *)NULL; - static char ypbuf[YPMAXRECORD + 2]; + struct hostent *host; + char *hostbuf; + int hostbuflen; + + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return NULL; + } + + host = &_res_data.host; + hostbuf = _res_data.hostbuf; + hostbuflen = _res_data.hostbuflen; + host->h_addr_list[0] = _res_data.host_addr; switch(af) { case AF_INET: @@ -90,27 +94,29 @@ h_errno = HOST_NOT_FOUND; return ((struct hostent *)NULL); } - - /* avoid potential memory leak */ - bcopy((char *)result, (char *)&ypbuf, resultlen); - ypbuf[resultlen] = '\0'; + if (resultlen > hostbuflen) { + h_errno = NETDB_INTERNAL; + errno = ERANGE; + return (NULL); + } + result[resultlen] = '\0'; + bcopy((char *)result, hostbuf, resultlen); free(result); - result = (char *)&ypbuf; + result = hostbuf; if ((cp = index(result, '\n'))) *cp = '\0'; cp = strpbrk(result, " \t"); *cp++ = '\0'; - h.h_addr_list = host_addrs; - h.h_addr = hostaddr; - *((u_long *)h.h_addr) = inet_addr(result); - h.h_length = size; - h.h_addrtype = AF_INET; + *((u_long *)host->h_addr_list[0]) = inet_addr(result); + host->h_addr_list[1] = NULL; + host->h_length = size; + host->h_addrtype = AF_INET; while (*cp == ' ' || *cp == '\t') cp++; - h.h_name = cp; - q = h.h_aliases = host_aliases; + host->h_name = cp; + q = host->h_aliases; cp = strpbrk(cp, " \t"); if (cp != NULL) *cp++ = '\0'; @@ -119,14 +125,14 @@ cp++; continue; } - if (q < &host_aliases[MAXALIASES - 1]) + if (q < &host->h_aliases[MAXALIASES - 1]) *q++ = cp; cp = strpbrk(cp, " \t"); if (cp != NULL) *cp++ = '\0'; } *q = NULL; - return (&h); + return (host); } #endif /* YP */ @@ -163,6 +169,11 @@ name = va_arg(ap, const char *); af = va_arg(ap, int); + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return NS_UNAVAIL; + } + *(struct hostent **)rval = _gethostbynis(name, "hosts.byname", af); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; #else @@ -181,8 +192,14 @@ addr = va_arg(ap, const char *); len = va_arg(ap, int); af = va_arg(ap, int); - - *(struct hostent **)rval =_gethostbynis(inet_ntoa(*(struct in_addr *)addr),"hosts.byaddr", af); + + if ((_res.options & RES_INIT) == 0 && res_init() == -1) { + h_errno = NETDB_INTERNAL; + return NS_UNAVAIL; + } + + *(struct hostent **)rval = _gethostbynis( + inet_ntoa(*(struct in_addr *)addr), "hosts.byaddr", af); return (*(struct hostent **)rval != NULL) ? NS_SUCCESS : NS_NOTFOUND; #else return NS_UNAVAIL; Index: src/lib/libc/net/gethostnamadr.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/gethostnamadr.c,v retrieving revision 1.20 diff -d -u -r1.20 gethostnamadr.c --- src/lib/libc/net/gethostnamadr.c 22 Mar 2002 21:52:29 -0000 1.20 +++ src/lib/libc/net/gethostnamadr.c 12 Aug 2002 09:48:20 -0000 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -82,7 +83,7 @@ NS_NIS_CB(_nis_gethostbyname, NULL) /* force -DHESIOD */ { 0 } }; - + rval = nsdispatch((void *)&hp, dtab, NSDB_HOSTS, "gethostbyname", default_src, name, type); @@ -114,29 +115,10 @@ return hp; } -struct hostent_data; - -/* - * Temporary function (not thread safe) - */ -int gethostbyaddr_r(const char *addr, int len, int type, - struct hostent *result, struct hostent_data *buffer) -{ - struct hostent *hp; - int ret; - if ((hp = gethostbyaddr(addr, len, type)) == NULL) { - ret = -1; - } else { - memcpy(result, hp, sizeof(struct hostent)); - ret = 0; - } - return(ret); -} - void -sethostent(stayopen) - int stayopen; +sethostent(int stayopen) { + _sethosthtent(stayopen); _sethostdnsent(stayopen); } @@ -144,6 +126,7 @@ void endhostent() { + _endhosthtent(); _endhostdnsent(); } Index: src/lib/libc/net/getnetbydns.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbydns.c,v retrieving revision 1.21 diff -d -u -r1.21 getnetbydns.c --- src/lib/libc/net/getnetbydns.c 26 Jun 2002 14:18:36 -0000 1.21 +++ src/lib/libc/net/getnetbydns.c 12 Aug 2002 09:48:20 -0000 @@ -82,11 +82,8 @@ #include "res_config.h" -extern int h_errno; - #define BYADDR 0 #define BYNAME 1 -#define MAXALIASES 35 #if PACKETSZ > 1024 #define MAXPACKET PACKETSZ Index: src/lib/libc/net/getnetbyht.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbyht.c,v retrieving revision 1.10 diff -d -u -r1.10 getnetbyht.c --- src/lib/libc/net/getnetbyht.c 22 Mar 2002 21:52:29 -0000 1.10 +++ src/lib/libc/net/getnetbyht.c 12 Aug 2002 09:48:20 -0000 @@ -58,8 +58,7 @@ #include #include #include - -#define MAXALIASES 35 +#include static FILE *netf; static char line[BUFSIZ+1]; Index: src/lib/libc/net/getnetbynis.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getnetbynis.c,v retrieving revision 1.15 diff -d -u -r1.15 getnetbynis.c --- src/lib/libc/net/getnetbynis.c 22 Mar 2002 21:52:29 -0000 1.15 +++ src/lib/libc/net/getnetbynis.c 12 Aug 2002 09:48:20 -0000 @@ -44,9 +44,7 @@ #include #include #endif - -#define MAXALIASES 35 -#define MAXADDRS 35 +#include #ifdef YP static char *host_aliases[MAXALIASES]; Index: src/lib/libc/net/herror.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/herror.c,v retrieving revision 1.11 diff -d -u -r1.11 herror.c --- src/lib/libc/net/herror.c 22 Mar 2002 21:52:29 -0000 1.11 +++ src/lib/libc/net/herror.c 12 Aug 2002 09:48:20 -0000 @@ -71,8 +71,6 @@ }; int h_nerr = { sizeof h_errlist / sizeof h_errlist[0] }; -int h_errno; - /* * herror -- * print the error indicated by the h_errno value. @@ -104,9 +102,26 @@ hstrerror(err) int err; { + if (err < 0) return ("Resolver internal error"); else if (err < h_nerr) return (h_errlist[err]); return ("Unknown resolver error"); +} + +#undef h_errno +int h_errno; + +/* + * Declare a weak reference in case the application is not linked + * with libpthread. + */ +__weak_reference(__h_errno_accessor_unthreaded, __h_errno_accessor); + +int * +__h_errno_accessor_unthreaded() +{ + + return &h_errno; } Index: src/lib/libc/net/res_init.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_init.c,v retrieving revision 1.29 diff -d -u -r1.29 res_init.c --- src/lib/libc/net/res_init.c 22 Mar 2002 21:52:30 -0000 1.29 +++ src/lib/libc/net/res_init.c 12 Aug 2002 09:48:22 -0000 @@ -83,12 +83,12 @@ #include #include #include -#include #include #include #include #include #include +#include #include "res_config.h" @@ -104,17 +104,6 @@ # define isascii(c) (!(c & 0200)) #endif -/* - * Resolver state default settings. - */ - -struct __res_state _res -# if defined(__BIND_RES_TEXT) - = { RES_TIMEOUT, } /* Motorola, et al. */ -# endif - ; - -struct __res_state_ext _res_ext; /* * Set up default settings. If the configuration file exist, the values @@ -154,6 +143,10 @@ #ifndef RFC1535 int dots; #endif + + /* Ensure that _res_data is inited in the threaded case */ + if(&_res_data == NULL) + return -1; /* * These three fields used to be statically initialized. This made @@ -582,3 +575,49 @@ */ #undef res_init __weak_reference(__res_init, res_init); + +/* + * Resolver state default settings. + */ + +#undef _res +#undef _res_ext +#undef _res_data + +struct __res_state _res +# if defined(__BIND_RES_TEXT) + = { RES_TIMEOUT, } /* Motorola, et al. */ +# endif + ; + +struct __res_state_ext _res_ext; + +static char *host_aliases[MAXALIASES]; +static char *h_addr_ptrs[MAXADDRS + 1]; +static char hostbuf[8*1024]; +static u_char host_addr[16]; + +struct __res_data _res_data = { 0, -1, 0, 0, 0, NULL, NULL, NULL, 0, + { NULL, host_aliases, 0, 0, h_addr_ptrs }, hostbuf, sizeof hostbuf, + host_addr, sizeof host_addr, &_res, &_res_ext }; + +/* + * Declare a weak reference in case the application is not linked + * with libpthread. + */ +__weak_reference(__res_data_accessor_unthreaded, __res_data_accessor); +__weak_reference(__res_accessor_unthreaded, __res_accessor); + +struct __res_data * +__res_data_accessor_unthreaded() +{ + + return &_res_data; +} + +struct __res_state * +__res_accessor_unthreaded() +{ + + return _res_data.res; +} Index: src/lib/libc/net/res_query.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_query.c,v retrieving revision 1.23 diff -d -u -r1.23 res_query.c --- src/lib/libc/net/res_query.c 7 Jul 2002 11:28:28 -0000 1.23 +++ src/lib/libc/net/res_query.c 12 Aug 2002 09:48:22 -0000 @@ -87,6 +87,7 @@ #include #include #include +#include #include "res_config.h" @@ -374,11 +375,21 @@ hostalias(name) const char *name; { + static char abuf[MAXDNAME]; + + return (hostalias_r(name, abuf, sizeof abuf)); +} + +const char * +hostalias_r(name, abuf, len) + const char *name; + char *abuf; + int len; +{ char *cp1, *cp2; FILE *fp; char *file; char buf[BUFSIZ]; - static char abuf[MAXDNAME]; if (_res.options & RES_NOALIASES) return (NULL); @@ -402,8 +413,8 @@ break; for (cp2 = cp1 + 1; *cp2 && !isspace((unsigned char)*cp2); ++cp2) ; - abuf[sizeof(abuf) - 1] = *cp2 = '\0'; - strncpy(abuf, cp1, sizeof(abuf) - 1); + abuf[len - 1] = *cp2 = '\0'; + strncpy(abuf, cp1, len - 1); fclose(fp); return (abuf); } Index: src/lib/libc/net/res_send.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/res_send.c,v retrieving revision 1.45 diff -d -u -r1.45 res_send.c --- src/lib/libc/net/res_send.c 1 Apr 2002 16:09:45 -0000 1.45 +++ src/lib/libc/net/res_send.c 12 Aug 2002 09:48:23 -0000 @@ -102,13 +102,6 @@ #include "res_config.h" -static int s = -1; /* socket used for communications */ -static int connected = 0; /* is the socket connected */ -static int vc = 0; /* is the socket a virtual circuit? */ -static int af = 0; /* address family of socket */ -static res_send_qhook Qhook = NULL; -static res_send_rhook Rhook = NULL; - #define CAN_RECONNECT 1 @@ -170,7 +163,7 @@ res_send_qhook hook; { - Qhook = hook; + _res_data.Qhook = hook; } void @@ -178,7 +171,7 @@ res_send_rhook hook; { - Rhook = hook; + _res_data.Rhook = hook; } static struct sockaddr * get_nsaddr(size_t); @@ -406,13 +399,13 @@ goto next_ns; } - if (Qhook) { + if (_res_data.Qhook) { int done = 0, loops = 0; do { res_sendhookact act; - act = (*Qhook)((struct sockaddr_in **)&nsap, + act = (*_res_data.Qhook)((struct sockaddr_in **)&nsap, &buf, &buflen, ans, anssiz, &resplen); switch (act) { @@ -457,14 +450,16 @@ */ try = _res.retry; truncated = 0; - if (s < 0 || !vc || hp->opcode == ns_o_update || - af != nsap->sa_family) { - if (s >= 0) + if (_res_data.s < 0 || !_res_data.vc || + hp->opcode == ns_o_update || + _res_data.af != nsap->sa_family) { + if (_res_data.s >= 0) res_close(); - af = nsap->sa_family; - s = _socket(af, SOCK_STREAM, 0); - if (s < 0) { + _res_data.af = nsap->sa_family; + _res_data.s = _socket(_res_data.af, SOCK_STREAM, + 0); + if (_res_data.s < 0) { terrno = errno; Perror(stderr, "socket(vc)", errno); badns |= (1 << ns); @@ -472,7 +467,7 @@ goto next_ns; } errno = 0; - if (_connect(s, nsap, salen) < 0) { + if (_connect(_res_data.s, nsap, salen) < 0) { terrno = errno; Aerror(stderr, "connect/vc", errno, nsap); @@ -480,7 +475,7 @@ res_close(); goto next_ns; } - vc = 1; + _res_data.vc = 1; } /* * Send length & message @@ -490,7 +485,7 @@ iov[0].iov_len = INT16SZ; iov[1].iov_base = (caddr_t)buf; iov[1].iov_len = buflen; - if (_writev(s, iov, 2) != (INT16SZ + buflen)) { + if (_writev(_res_data.s, iov, 2) != (INT16SZ + buflen)) { terrno = errno; Perror(stderr, "write failed", errno); badns |= (1 << ns); @@ -503,7 +498,7 @@ read_len: cp = ans; len = INT16SZ; - while ((n = _read(s, (char *)cp, (int)len)) > 0) { + while ((n = _read(_res_data.s, (char *)cp, (int)len)) > 0) { cp += n; if ((len -= n) <= 0) break; @@ -551,7 +546,7 @@ } cp = ans; while (len != 0 && - (n = _read(s, (char *)cp, (int)len)) > 0) { + (n = _read(_res_data.s, (char *)cp, (int)len)) > 0) { cp += n; len -= n; } @@ -574,7 +569,7 @@ n = (len > sizeof(junk) ? sizeof(junk) : len); - if ((n = _read(s, junk, n)) > 0) + if ((n = _read(_res_data.s, junk, n)) > 0) len -= n; else break; @@ -604,12 +599,14 @@ struct sockaddr_storage from; int fromlen; - if (s < 0 || vc || af != nsap->sa_family) { - if (vc) + if (_res_data.s < 0 || _res_data.vc || + _res_data.af != nsap->sa_family) { + if (_res_data.vc) res_close(); - af = nsap->sa_family; - s = _socket(af, SOCK_DGRAM, 0); - if (s < 0) { + _res_data.af = nsap->sa_family; + _res_data.s = _socket(_res_data.af, SOCK_DGRAM, + 0); + if (_res_data.s < 0) { #ifndef CAN_RECONNECT bad_dg_sock: #endif @@ -619,7 +616,7 @@ res_close(); goto next_ns; } - connected = 0; + _res_data.connected = 0; } #ifndef CANNOT_CONNECT_DGRAM /* @@ -650,8 +647,9 @@ * Connect only if we are sure we won't * receive a response from another server. */ - if (!connected) { - if (_connect(s, nsap, salen) < 0) { + if (!_res_data.connected) { + if (_connect(_res_data.s, nsap, salen) < + 0) { Aerror(stderr, "connect(dg)", errno, nsap); @@ -659,9 +657,10 @@ res_close(); goto next_ns; } - connected = 1; + _res_data.connected = 1; } - if (send(s, (char*)buf, buflen, 0) != buflen) { + if (send(_res_data.s, (char*)buf, buflen, 0) != + buflen) { Perror(stderr, "send", errno); badns |= (1 << ns); res_close(); @@ -672,7 +671,7 @@ * Disconnect if we want to listen * for responses from more than one server. */ - if (connected) { + if (_res_data.connected) { #ifdef CAN_RECONNECT /* XXX: any errornous address */ struct sockaddr_in no_addr; @@ -680,24 +679,25 @@ no_addr.sin_family = AF_INET; no_addr.sin_addr.s_addr = INADDR_ANY; no_addr.sin_port = 0; - (void) _connect(s, + (void) _connect(_res_data.s, (struct sockaddr *) &no_addr, sizeof no_addr); #else - int s1 = _socket(af, SOCK_DGRAM,0); + int s1 = _socket(_res_data.af, + SOCK_DGRAM,0); if (s1 < 0) goto bad_dg_sock; - (void)_dup2(s1, s); + (void)_dup2(s1, _res_data.s); (void)_close(s1); Dprint(_res.options & RES_DEBUG, (stdout, ";; new DG socket\n")) #endif /* CAN_RECONNECT */ - connected = 0; + _res_data.connected = 0; errno = 0; } #endif /* !CANNOT_CONNECT_DGRAM */ - if (_sendto(s, (char*)buf, buflen, 0, + if (_sendto(_res_data.s, (char*)buf, buflen, 0, nsap, salen) != buflen) { Aerror(stderr, "sendto", errno, nsap); badns |= (1 << ns); @@ -722,13 +722,14 @@ (void) gettimeofday(&ctv, NULL); timeradd(&timeout, &ctv, &timeout); wait: - if (s < 0) { + if (_res_data.s < 0) { Perror(stderr, "s out-of-bounds", EMFILE); res_close(); goto next_ns; } - EV_SET(&kv, s, EVFILT_READ, EV_ADD | EV_ONESHOT, 0,0,0); + EV_SET(&kv, _res_data.s, EVFILT_READ, + EV_ADD | EV_ONESHOT, 0,0,0); n = _kevent(kq, &kv, 1, &kv, 1, &ts); if (n < 0) { @@ -757,7 +758,7 @@ } errno = 0; fromlen = sizeof(from); - resplen = _recvfrom(s, (char*)ans, anssiz, 0, + resplen = _recvfrom(_res_data.s, (char*)ans, anssiz, 0, (struct sockaddr *)&from, &fromlen); if (resplen <= 0) { Perror(stderr, "recvfrom", errno); @@ -862,15 +863,15 @@ !(_res.options & RES_STAYOPEN)) { res_close(); } - if (Rhook) { + if (_res_data.Rhook) { int done = 0, loops = 0; do { res_sendhookact act; - act = (*Rhook)((struct sockaddr_in *)nsap, - buf, buflen, - ans, anssiz, &resplen); + act = (*_res_data.Rhook)( + (struct sockaddr_in *)nsap, buf, buflen, + ans, anssiz, &resplen); switch (act) { case res_goahead: case res_done: @@ -920,12 +921,12 @@ void res_close() { - if (s >= 0) { - (void)_close(s); - s = -1; - connected = 0; - vc = 0; - af = 0; + if (_res_data.s >= 0) { + (void)_close(_res_data.s); + _res_data.s = -1; + _res_data.connected = 0; + _res_data.vc = 0; + _res_data.af = 0; } } Index: src/lib/libc_r/sys/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc_r/sys/Makefile.inc,v retrieving revision 1.10 diff -d -u -r1.10 Makefile.inc --- src/lib/libc_r/sys/Makefile.inc 28 Aug 1999 00:03:13 -0000 1.10 +++ src/lib/libc_r/sys/Makefile.inc 12 Aug 2002 09:48:23 -0000 @@ -2,5 +2,5 @@ .PATH: ${.CURDIR}/sys ${.CURDIR}/arch/${MACHINE_ARCH} -SRCS+= uthread_error.c _atomic_lock.S +SRCS+= uthread_error.c uthread_resolv.c _atomic_lock.S Index: src/lib/libc_r/sys/uthread_resolv.c =================================================================== RCS file: src/lib/libc_r/sys/uthread_resolv.c diff -N src/lib/libc_r/sys/uthread_resolv.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/lib/libc_r/sys/uthread_resolv.c 12 Aug 2002 09:48:23 -0000 @@ -0,0 +1,186 @@ +/*- + * Copyright (c) 2001 Alexandr Litvin + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "pthread_private.h" + +#undef h_errno +#undef _res +#undef _res_ext +#undef _res_data + +extern int h_errno; +extern struct __res_data _res_data; + +static pthread_once_t once = PTHREAD_ONCE_INIT; +static pthread_key_t key; + + +static void +__res_data_destroy(void *p) +{ + struct __res_data *_res_datap = (struct __res_data *)p; + + if(_res_datap->res) + free(_res_datap->res); + if(_res_datap->res_ext) + free(_res_datap->res_ext); + if (_res_datap->host.h_aliases) + free(_res_datap->host.h_aliases); + if (_res_datap->host.h_addr_list) + free(_res_datap->host.h_addr_list); + if (_res_datap->hostbuf) + free(_res_datap->hostbuf); + if (_res_datap->host_addr) + free(_res_datap->host_addr); + if(_res_datap->s >= 0) + close(_res_datap->s); + if(_res_datap->hostf) + fclose(_res_datap->hostf); + free(_res_datap); +} + +static void +__res_data_init() +{ + + pthread_key_create(&key, __res_data_destroy); +} + +struct __res_data * +__res_data_accessor() +{ + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + _res_datap = &_res_data; + } else { + pthread_once(&once, __res_data_init); + _res_datap = (struct __res_data *)pthread_getspecific(key); + if(_res_datap==NULL) { + _res_datap = malloc(sizeof(struct __res_data)); + if(_res_datap==NULL) + return (NULL); + bzero(_res_datap, sizeof(struct __res_data)); + _res_datap->res = malloc(sizeof(struct __res_state)); + if(_res_datap->res == NULL) + goto e1; + bzero(_res_datap->res, sizeof(struct __res_state)); + _res_datap->res_ext = + malloc(sizeof(struct __res_state_ext)); + if(_res_datap->res_ext == NULL) + goto e2; + bzero(_res_datap->res_ext, + sizeof(struct __res_state_ext)); + _res_datap->s = -1; + _res_datap->host.h_name = NULL; + _res_datap->host.h_aliases = + malloc(sizeof(char *[MAXALIASES])); + if (_res_datap->host.h_aliases == NULL) + goto e3; + _res_datap->host.h_addrtype = 0; + _res_datap->host.h_length = 0; + _res_datap->host.h_addr_list = + malloc(sizeof(char *[MAXADDRS + 1])); + if (_res_datap->host.h_addr_list == NULL) + goto e4; + _res_datap->hostbuflen = sizeof(*_res_datap->hostbuf) * + 8 * 1024; + _res_datap->hostbuf = malloc(_res_datap->hostbuflen); + if (_res_datap->hostbuf == NULL) + goto e5; + _res_datap->host_addrlen = + sizeof(*_res_datap->host_addr) * 16; + _res_datap->host_addr = + malloc(_res_datap->host_addrlen); + if (_res_datap->host_addr == NULL) + goto e6; + pthread_setspecific(key, _res_datap); + } + } + return (_res_datap); + +e6: free(_res_datap->hostbuf); +e5: free(_res_datap->host.h_addr_list); +e4: free(_res_datap->host.h_aliases); +e3: free(_res_datap->res_ext); +e2: free(_res_datap->res); +e1: free(_res_datap); + return (NULL); +} + +static struct __res_state dummy_res; +static int dummy_h_errno; + +struct __res_state * +__res_accessor() +{ + struct __res_state *resp; + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + resp = _res_data.res; + } else { + _res_datap = __res_data_accessor(); + if(_res_datap) { + resp = _res_datap->res; + } else { + dummy_res.options = RES_DEFAULT; + resp = &dummy_res; + } + } + return (resp); +} + +int * +__h_errno_accessor() +{ + int *h_errnop; + struct __res_data *_res_datap; + + if (_thread_run == _thread_initial) { + h_errnop = &h_errno; + } else { + _res_datap = __res_data_accessor(); + if(_res_datap) { + h_errnop = &_res_datap->h_errno_res; + } else { + dummy_h_errno = NETDB_INTERNAL; + h_errnop = &dummy_h_errno; + } + } + return (h_errnop); +} --------------051496A982500B2DDF1E4FCD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 3:39:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB7B237B400 for ; Mon, 12 Aug 2002 03:39:08 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1A643E6A for ; Mon, 12 Aug 2002 03:39:07 -0700 (PDT) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17eCbL-00077B-00 (Debian); Mon, 12 Aug 2002 11:39:07 +0100 Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17dHyn-00054O-00 (Debian); Fri, 09 Aug 2002 23:11:33 +0100 Date: Fri, 9 Aug 2002 23:11:33 +0100 From: Tony Finch To: freebsd-hackers@freebsd.org Cc: dot@dotat.at Subject: using mtree as tripwire Message-ID: <20020809231133.D1697@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've been playing around with using mtree as a lightweight replacement for tripwire, and it seems to work quite nicely. There are a few bits and pieces: (1) a patch to make the -X exclude-file facility slightly more flexible and easy-to-manage; (2) a script for creating the mtree spec file containing all of the checksums; and (3) an /etc/periodic/security script to do the mtree checksum comparison with reality. I've parametrized (3) with a command for obtaining the spec file, for people who keep it on a remote machine etc. so obviously (2) should have a corresponding option. I suppose it could get it from periodic.conf but that's a bit ugly since it isn't a periodic script. Does anyone have any better ideas? I'd also like to optionally run (2) as part of the installworld process, and maybe include it as part of the standard distribution. I'm currently keeping the file in /var/db/; I'm not sure whether or not that's better than /etc/mtree/ -- it's over 7MB on my machine which is probably an important consideration. The patch to mtree and some of the scripts can be found at http://people.FreeBSD.org/~fanf/FreeBSD/ Tony. -- f.a.n.finch http://dotat.at/ SOUTH FITZROY: WESTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST. RAIN OR DRIZZLE AT TIMES. GOOD OCCASIONALLY MODERATE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 3:42: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E51C37B400 for ; Mon, 12 Aug 2002 03:41:58 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 189AD43E5E for ; Mon, 12 Aug 2002 03:41:58 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0085.cvx21-bradley.dialup.earthlink.net ([209.179.192.85] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eCe4-0006ik-00; Mon, 12 Aug 2002 03:41:57 -0700 Message-ID: <3D579024.5ABE33B7@mindspring.com> Date: Mon, 12 Aug 2002 03:38:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ouyang kai Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hi, how the kernel add the devices References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ouyang kai wrote: > > Part 1.1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable > > Name: kernel_init_problem.txt > kernel_init_problem.txt Type: Plain Text (text/plain) > Encoding: quoted-printable If you are talking about the fxp driver, then you need to look in /usr/src/sys/dev/fxp/if_fxp.c, around line 240: DRIVER_MODULE(if_fxp, pci, fxp_driver, fxp_devclass, 0, 0); DRIVER_MODULE(if_fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); DRIVER_MODULE(miibus, fxp, miibus_driver, miibus_devclass, 0, 0); The definition of DRIVER_MODULE is variant, based on whether the code is a loadable module, or is compiled into the kernel. The original intent of the SYSINIT code was to erase the distinction between code statically linked into the kernel, and code loaded later, as a loadable module. Specifically, the DRIVER_MODULE() macro uses the DECLARE_MODULE(); see /usr/src/sys/sys/bus.h, in which it specifies SI_SUB_DRIVERS as the init_main.c code sort order, and the sub-order within that as SI_ORDER_MIDDLE. The DECLARE_MODULE() macro encapsulates a SYSINIT() entry; see /usr/src/sys/sys/module.h. The result is that the init_main.c code calls the entry point on startup to probe the device (see /usr/src/sys/dev/fxp/if_fxp.c). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 3:53:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F221637B400; Mon, 12 Aug 2002 03:53:25 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E4943E72; Mon, 12 Aug 2002 03:53:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0085.cvx21-bradley.dialup.earthlink.net ([209.179.192.85] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eCp9-0005Q5-00; Mon, 12 Aug 2002 03:53:24 -0700 Message-ID: <3D5792CD.497C80F0@mindspring.com> Date: Mon, 12 Aug 2002 03:49:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: hackers@FreeBSD.org, audit@FreeBSD.org, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > Attched please find two patches based on bin/29581 PR to make FreeBSD > resolver thread-safe. They represent two approaches to reach this goal > - the first is to introduce reentrant versions of the standard > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > the second one is to make gethostbyXXX(3) returning data placed into > per-thread storage when linked with libc_r. I like the latter approach > more, since it doesn't introduce new non-standard APIs. > > I would like to hear any comments and suggestions on the proposed > patches, as well as to opinions about which path to chose. 1) Allocate the per thread storage as a single blob, and set the pointers into it, instead of using seperate allocations. This will have the side effect of letting you free it, all at once, and will tend to make it faster on each first use per thread, anyway. You can do this by making a meta structure containing the list of structures to be allocated, and then setting the pointers to the addresses of the structure subelements. 2) Note somewhere in the man page that this makes it so you can not pass the results off to another thread by reference, unless you copy them once there (i.e. you are not allowed persistant references accross threads). It seems to me the most likely use would be to permit a seperate thread (or threads) to be used to resolve concurrently, and/or with other operations. The upshot of this is that holding a reference would mean that you could not initiate another lookup on the lookup worker thread(s) until the reference was freed. You may also want to consider the use of a .init and .fini section for the code, to permit the creation of an initial lookup context chunk; this is kind of a tradeoff, but it will mean that a server will not have to do the recheck each time. The .fini section would aloow auto-cleanup. This may be a necessity for a long running program that uses a shared object to perform the thread creation and lookup (you could leak memory, otherwise). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 5:18:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88AD737B400 for ; Mon, 12 Aug 2002 05:18:42 -0700 (PDT) Received: from hotmail.com (oe40.pav0.hotmail.com [64.4.32.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24F2E43E65 for ; Mon, 12 Aug 2002 05:18:42 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 05:18:42 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: "Lambert Terry" , Subject: How the kernel add the devices when the kernel start Date: Mon, 12 Aug 2002 20:18:34 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C2423D.6F19DF40" Message-ID: X-OriginalArrivalTime: 12 Aug 2002 12:18:42.0118 (UTC) FILETIME=[658D3E60:01C241FA] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0004_01C2423D.6F19DF40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Terry, (*((*sipp)->func))((*sipp)->udata); =20 I saw the corresponding code based on your hints. I have some questions.= =20 When the kernel process this code to check the SI_SUB_DRIVERS, it would = find =20 the registed 'fxp' device(fxp_probe), right? If the 'fxp' device is exist, the kernel will try to attach it(fxp_atta= ch), right? Another, If we do not compile the 'vr' device into the kernel and we d= o load the corresponding 'ko', so the kernel will not check the device, that is to say, the 'vr' device = does not registe to kernel, right? But, I have some problem : 1. When the kernel process the specified device, the 'func' means what? =20 For example: the member 'if_ioctl' of the structure 'ifnet', when the = kernel process the 'fxp' device, I know it should call the function 'fxp_ioctl'. But I do not the 'func' mea= ns what when it check SI_SUB_DRIVERS. 2. In NetBSD, I can find main() function in init_main.c, but in FreeBSD, = I could not find it, I am puzzled about the place of the FreeBSD main process. =20 Thank you so much! Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://e= xplorer.msn.com ------=_NextPart_001_0004_01C2423D.6F19DF40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Terry,
 
(*((*sipp)->func))((*sipp)->udata);
&= nbsp;
 I saw the corresponding code based on your hints. I have s= ome questions. 
 When the kernel process this c= ode to check the SI_SUB_DRIVERS, it would find
the registed 'fxp' dev= ice(fxp_probe), right?
  If the 'fxp' device is exist, the kernel= will try to attach it(fxp_attach), right?
   Another, If we= do not compile the 'vr' device into the kernel and we do load the corres= ponding 'ko',
so the kernel will not check the device, that is to say,= the 'vr' device does not registe to kernel, right?
  But, I have= some problem :
1. When the kernel process the specified device, the '= func' means what?
   For example: the member 'if_ioctl' of = the structure 'ifnet', when the kernel process the 'fxp' device, I
kno= w it should call the function 'fxp_ioctl'. But I do not the 'func' means = what when it check SI_SUB_DRIVERS.
2. In NetBSD, I can find main() fun= ction in init_main.c, but in FreeBSD, I could not find it, I am puzzled a= bout
the place of the FreeBSD main process.
  Thank y= ou so much!
Best Regards
  Ouyang Kai
 
<= /BODY>
Get more from the Web. FREE MSN Explore= r download : http://explorer.msn.com<= /a>

------=_NextPart_001_0004_01C2423D.6F19DF40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 5:23:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2E1937B400; Mon, 12 Aug 2002 05:23:54 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC4243E86; Mon, 12 Aug 2002 05:23:53 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g7CCNmo9021178; Mon, 12 Aug 2002 08:23:48 -0400 (EDT) Date: Mon, 12 Aug 2002 08:23:48 -0400 (EDT) From: Daniel Eischen To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] In-Reply-To: <3D578A99.F0821712@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 12 Aug 2002, Maxim Sobolev wrote: > Folks, > > Attched please find two patches based on bin/29581 PR to make FreeBSD > resolver thread-safe. They represent two approaches to reach this goal > - the first is to introduce reentrant versions of the standard > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > the second one is to make gethostbyXXX(3) returning data placed into > per-thread storage when linked with libc_r. I like the latter approach > more, since it doesn't introduce new non-standard APIs. > > I would like to hear any comments and suggestions on the proposed > patches, as well as to opinions about which path to chose. Why do you need uthread_resolv.c? You should be able to thread calls by checking __isthreaded. Just keep everything in libc. If there are missing stubs for some pthread_* routines (I think everything you need is in -current's libc), then add them. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 5:28: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F9B937B400; Mon, 12 Aug 2002 05:27:55 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id E533743E8A; Mon, 12 Aug 2002 05:27:50 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id PAA20856; Mon, 12 Aug 2002 15:27:27 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7CCRO8Y020796; Mon, 12 Aug 2002 15:27:24 +0300 (EEST) Received: from vega.vega.com (h210.234.dialup.iptcom.net [212.9.234.210]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7CCRIoQ021025; Mon, 12 Aug 2002 15:27:21 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7CCRHF2039805; Mon, 12 Aug 2002 15:27:17 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D57A9D4.DAA043EF@FreeBSD.org> Date: Mon, 12 Aug 2002 15:28:04 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Terry Lambert Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Maxim Sobolev wrote: > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > resolver thread-safe. They represent two approaches to reach this goal > > - the first is to introduce reentrant versions of the standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > 1) Allocate the per thread storage as a single blob, and > set the pointers into it, instead of using seperate > allocations. This will have the side effect of letting > you free it, all at once, and will tend to make it > faster on each first use per thread, anyway. You can > do this by making a meta structure containing the list > of structures to be allocated, and then setting the > pointers to the addresses of the structure subelements. Ok, I'll do it. > 2) Note somewhere in the man page that this makes it so > you can not pass the results off to another thread by > reference, unless you copy them once there (i.e. you > are not allowed persistant references accross threads). > It seems to me the most likely use would be to permit > a seperate thread (or threads) to be used to resolve > concurrently, and/or with other operations. The upshot > of this is that holding a reference would mean that you > could not initiate another lookup on the lookup worker > thread(s) until the reference was freed. Yuip, I'll do it as well. > You may also want to consider the use of a .init and .fini > section for the code, to permit the creation of an initial > lookup context chunk; this is kind of a tradeoff, but it will > mean that a server will not have to do the recheck each time. > The .fini section would aloow auto-cleanup. This may be a > necessity for a long running program that uses a shared object > to perform the thread creation and lookup (you could leak > memory, otherwise). Could you please elaborate how exactly memory could be leaked in this case, if the program does correctly shut down all its threads? I also would like to hear from you whether or not you think that we need all those gethostbyXXX_r(3) functions. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 5:33:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F283E37B400; Mon, 12 Aug 2002 05:33:50 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52BD243E3B; Mon, 12 Aug 2002 05:33:46 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id PAA29342; Mon, 12 Aug 2002 15:33:26 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7CCXM8Y029267; Mon, 12 Aug 2002 15:33:23 +0300 (EEST) Received: from vega.vega.com (h210.234.dialup.iptcom.net [212.9.234.210]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7CCXIoQ023526; Mon, 12 Aug 2002 15:33:19 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7CCXIF2039813; Mon, 12 Aug 2002 15:33:18 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D57AB3D.17737AD7@FreeBSD.org> Date: Mon, 12 Aug 2002 15:34:05 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Daniel Eischen Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > On Mon, 12 Aug 2002, Maxim Sobolev wrote: > > Folks, > > > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > resolver thread-safe. They represent two approaches to reach this goal > > - the first is to introduce reentrant versions of the standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > Why do you need uthread_resolv.c? You should be able to thread > calls by checking __isthreaded. Just keep everything in libc. > If there are missing stubs for some pthread_* routines (I think > everything you need is in -current's libc), then add them. Why do we have uthread_error.c then? Also it will add penalty to every access to _res_data structure even in non-threaded case. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 6:10:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78B1737B406; Mon, 12 Aug 2002 06:10:22 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAC7E43E4A; Mon, 12 Aug 2002 06:10:21 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g7CDAKhh027052; Mon, 12 Aug 2002 09:10:20 -0400 (EDT) Date: Mon, 12 Aug 2002 09:10:20 -0400 (EDT) From: Daniel Eischen To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] In-Reply-To: <3D57AB3D.17737AD7@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 12 Aug 2002, Maxim Sobolev wrote: > Daniel Eischen wrote: > > > > On Mon, 12 Aug 2002, Maxim Sobolev wrote: > > > Folks, > > > > > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > > resolver thread-safe. They represent two approaches to reach this goal > > > - the first is to introduce reentrant versions of the standard > > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > > the second one is to make gethostbyXXX(3) returning data placed into > > > per-thread storage when linked with libc_r. I like the latter approach > > > more, since it doesn't introduce new non-standard APIs. > > > > > > I would like to hear any comments and suggestions on the proposed > > > patches, as well as to opinions about which path to chose. > > > > Why do you need uthread_resolv.c? You should be able to thread > > calls by checking __isthreaded. Just keep everything in libc. > > If there are missing stubs for some pthread_* routines (I think > > everything you need is in -current's libc), then add them. > > Why do we have uthread_error.c then? Also it will add penalty to every > access to _res_data structure even in non-threaded case. Take a look at everything else in libc. What about malloc? It does the same thing and checks __isthreaded. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 6:16:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5440737B400 for ; Mon, 12 Aug 2002 06:16:27 -0700 (PDT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E010E43E42 for ; Mon, 12 Aug 2002 06:16:25 -0700 (PDT) (envelope-from marck@rinet.ru) Received: from localhost (marck@localhost) by woozle.rinet.ru (8.11.6/8.11.6) with ESMTP id g7CDGKj67986; Mon, 12 Aug 2002 17:16:20 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 12 Aug 2002 17:16:20 +0400 (MSD) From: Dmitry Morozovsky To: Bruce M Simpson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Building ports into packages, outside of /usr/ports In-Reply-To: <20020808154814.GD18301@spc.org> Message-ID: <20020812171508.V56159-100000@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 8 Aug 2002, Bruce M Simpson wrote: BMS> Has anybody thought about hacking the above to support building packages BMS> outside of the ports tree, and without installing them? Strikes me as BMS> something that could be neatly solved with judicious use of chroot(1). BMS> BMS> This is something which was raised at the FreeBSD UK Users Group meeting BMS> last night, so it's bugging me. Hmm, did you look at /usr/ports/Tools/portbuild and /usr/ports/Tools/scripts/release ? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 7:58:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE82937B400 for ; Mon, 12 Aug 2002 07:58:30 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB7A43E6A for ; Mon, 12 Aug 2002 07:58:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eGeB-0001F1-00; Mon, 12 Aug 2002 07:58:19 -0700 Message-ID: <3D57CCD5.B8B36F86@mindspring.com> Date: Mon, 12 Aug 2002 07:57:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ouyang kai Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How the kernel add the devices when the kernel start References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ouyang kai wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable | When the kernel process this code to check the SI_SUB_DRIVERS, | it would find the registed 'fxp' device(fxp_probe), right? Not exactly. Let's expand the macros manually: -------------------------------------------------------------------------- DRIVER_MODULE(if_fxp, pci, fxp_driver, fxp_devclass, 0, 0); -> static driver_t *if_fxp_pci_driver_list[] = { &fxp_driver }; static struct driver_module_data if_fxp_pci_driver_mod = { 0, 0, "pci", if_fxp_pci_driver_list, (sizeof if_fxp_pci_driver_list) / (sizeof if_fxp_pci_driver_list[0]), &fxp_devclass }; static moduledata_t if_fxp_pci_mod = { "pci/if_fxp", driver_module_handler, &if_fxp_pci_driver_mod }; DECLARE_MODULE(if_fxp_pci, if_fxp_pci_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE) -> SYSINIT(if_fxp_pcimodule, SI_SUB_DRIVERS, SI_ORDER_MIDDLE, module_register_init, &if_fxp_pci_mod) -> struct sysinit if_fxp_pcimodule_sys_init { SI_SUB_DRIVERS, SI_ORDER_MIDDLE, module_register_init, &if_fxp_pci_mod }; -> in init_main.c: module_register_init( &if_fxp_pci_mod); /-------------------------------------------------------------------------- So the answer is that it calls the function "module_register_init" with the address of the moduledata_t structure whose contents are: -------------------------------------------------------------------------- static moduledata_t if_fxp_pci_mod = { "pci/if_fxp", driver_module_handler, &{ 0, 0, "pci", if_fxp_pci_driver_list, 1, &fxp_devclass } }; /-------------------------------------------------------------------------- | If the 'fxp' device is exist, the kernel will try to attach | it(fxp_attach), right? This *eventually* calls the probe, and, if it finds a device, the attach, so yes, many function calls deep. | Another, If we do not compile the 'vr' device into the kernel | and we do not load the corresponding 'ko', so the kernel will | not check the device, that is to say, the 'vr' device does not | registe to kernel, right? Yes. Unless the .ko (kernel module) version gets loaded, a driver must be statically linked into the kernel, or it will not be called to try and probe for devices that it matches. | 1. When the kernel process the specified device, the 'func' | means what? For example: the member 'if_ioctl' of the | structure 'ifnet', when the kernel process the 'fxp' device, | I know it should call the function 'fxp_ioctl'. But I do not | the 'func' means what when it check SI_SUB_DRIVERS. In this case, the macros make it mean the function named module_register_init(). | 2. In NetBSD, I can find main() function in init_main.c, but | in FreeBSD, I could not find it, I am puzzled about the place | of the FreeBSD main process. This is not well documented, and it has changed recently, as people have gained an understanding for the boot process, and screwed around with the code there, so any documentation is out of date pretty quickly. That's the problem with documenting things: there is so little documentation that as soon as something is documented, people understand it and jump on it and change it because they now understand it. Unfortunately people can't seem to leave working code alone, expecially if it's the only code they understand (understanding broken code would be too much like work, I guess...). The short answer is: mi_startup(). The longer answer is: bootstrap code (boot0, boot1+boot2) -- this is the entry point from the BIOS btext() (in locore.s; called locorestart() on Alpha) -- this is the entry point from the bootstrap identify_cpu() create_pagetables() begin() (in relocated address space) mi_startup() -- this is the entrypoint to the machine independent startup code that will be the same no matter what type of machine you run FreeBSD on. Which one is really "main()" depends on your philosophy, and who has been rearranging the deck chairs in locore.s this week. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 8: 9:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0359D37B400; Mon, 12 Aug 2002 08:09:26 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B7843E65; Mon, 12 Aug 2002 08:09:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eGou-0000Cs-00; Mon, 12 Aug 2002 08:09:24 -0700 Message-ID: <3D57CF6D.2982CE8@mindspring.com> Date: Mon, 12 Aug 2002 08:08:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > You may also want to consider the use of a .init and .fini > > section for the code, to permit the creation of an initial > > lookup context chunk; this is kind of a tradeoff, but it will > > mean that a server will not have to do the recheck each time. > > The .fini section would aloow auto-cleanup. This may be a > > necessity for a long running program that uses a shared object > > to perform the thread creation and lookup (you could leak > > memory, otherwise). > > Could you please elaborate how exactly memory could be leaked in this > case, if the program does correctly shut down all its threads? Create PIC object foo.so. Link PIC object foo.so against libc.so. Call dlopen to load module foo.so into program "bob". Call function in foo.so from program "bob". Function in foo.so creates two threads, one for IPv4 lookup, another for IPv6 lookup to cause lookups to proceed concurrently. Lookup completes. Unload module foo.so. -> leak memory in libc.so image The assumption (which is potentially wrong) is that the program will correctly shut down all its threads, when in fact it was a module not under the programs control that created and used the threads. The leak depends on: 1) A pool of worker threads being created and left around or the purpose of simultaneous resolution 2) The parent shutting down the module without explicitly dealing with the threads (basically, code which would need to live in ".fini" of the foo.so, and could not be automatically triggered on unload of foo.so any other way). I think that parallel IPv6/IPv4 resolution presented as a single serial interface is a high probability implementation with the support for threaded access to the resolver, particularly with the Mozilla code acting the way it does. > I also would like to hear from you whether or not you think that we > need all those gethostbyXXX_r(3) functions. No. I don't think any of the _r functions are needed, so long as the results are not cached by pointer instead of a copy, before passing them from one thread to another. It's a risk on the clobber case of a call with a cached reference outstanding but not processed by another thread which is not an issue with the _r functions, which require that you pass the storage down. Of course, if you pass down per thread storage, you could have the same problem if you didn't copy rather than reference the results before passing to another thread by address. Given that, per thread allocations ("thread local storage") makes more sense than allocate/free fights between threads based on who's responsible for owning the memory after an inter-thread call. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 12:22:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2774B37B400; Mon, 12 Aug 2002 12:22:51 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C4CC43E3B; Mon, 12 Aug 2002 12:22:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 4B81B2A7D6; Mon, 12 Aug 2002 12:22:50 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] In-Reply-To: <3D57A9D4.DAA043EF@FreeBSD.org> Date: Mon, 12 Aug 2002 12:22:50 -0700 From: Peter Wemm Message-Id: <20020812192250.4B81B2A7D6@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > I also would like to hear from you whether or not you think that we > need all those gethostbyXXX_r(3) functions. Yes. Because autoconf looks for them and will assume non-reentrancy if they are not present. Also, for source compatability with linux and solaris and just about everything else that implements this stuff. The expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is safe. If you can make the non_r versions safe then that is a bonus I guess. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 13: 1:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8642A37B405; Mon, 12 Aug 2002 13:01:08 -0700 (PDT) Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B43D343E42; Mon, 12 Aug 2002 13:01:05 -0700 (PDT) (envelope-from hottymaria@gosympatico.ca) Received: from [209.226.175.136] by tomts9-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020812200119.KDYI12452.tomts9-srv.bellnexxia.net@[209.226.175.136]>; Mon, 12 Aug 2002 16:01:19 -0400 From: To: Subject: Hey, whats up? Date: Mon, 12 Aug 2002 16:01:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020812200119.KDYI12452.tomts9-srv.bellnexxia.net@[209.226.175.136]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

My buddies and I were average people, just like you...Then we had our great idea...
find young hot girls and proposition them to fool around on video tape.
Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!
BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, click here You will be glad you did.











If you never want to hear from me again, please click here and I will remove you from all future mailings.

----- Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 13: 7: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7994737B400 for ; Mon, 12 Aug 2002 13:07:01 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B23343E7B for ; Mon, 12 Aug 2002 13:06:58 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8776E72FC5; Mon, 12 Aug 2002 13:03:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 840EA72D9E; Mon, 12 Aug 2002 13:03:50 -0700 (PDT) Date: Mon, 12 Aug 2002 13:03:50 -0700 (PDT) From: Doug White To: Sean Hamilton Cc: hackers@freebsd.org Subject: Re: arplookup: host is not on local network In-Reply-To: <001f01c2418a$bc174890$f019e8d8@slugabed.org> Message-ID: <20020812130248.W45923-100000@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 11 Aug 2002, Sean Hamilton wrote: > From: "Doug White" > > You should check that your network configuration is correct first, then > > use tcpdump to locate the offender and report them to your provider. They > > can ask the owner of said machine politely to install the patches or set > > /proc flags to disable that behavior. You can, of course, comment out the > > Which /proc flags? Indeed it is a linux box, the firewall, which I have > access to. My coworker, the administrator of this box, has simply turned a > blind eye to this, on the grounds that it's not actually causing problems, > just noise... but if it's a simple tweak, I'm sure he could be bribed with > caffeine or somesuch. I don't recall, its under /proc/sys/net most likely ... you can google for it. > > printfs, or hide it behind log_arp_wrong_iface which is controlled by the > > sysctl net.link.ether.inet.log_arp_wrong_iface. The file you want to > > modify in that case is src/sys/netinet/if_ether.c. > > Thanks, looks like that sysctl is what I've been looking for. Though you > seem to indicate I would have to modify the kernel to achieve this, it seems > to be that way already -- perhaps a recent thing? Regardless, I find it > somewhat surprising my googling didn't point me in this direction. log_arp_wrong_iface was in 4.5 I think, but you do need to do a minor hack to put an if(){} block around the offending printf. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 13: 8:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E98037B400 for ; Mon, 12 Aug 2002 13:08:18 -0700 (PDT) Received: from mgw1-out.MEIway.com (mgw1.meiway.com [212.73.210.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DC8E43E6A for ; Mon, 12 Aug 2002 13:08:17 -0700 (PDT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) by mgw1-out.MEIway.com (Postfix Relay Hub) with ESMTP id 1295AEF908 for ; Mon, 12 Aug 2002 21:38:03 +0200 (CEST) Received: from localhost (localhost.meiway.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 3A30F5D00A for ; Mon, 12 Aug 2002 21:49:36 +0200 (CEST) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 9E5065D008 for ; Mon, 12 Aug 2002 21:49:35 +0200 (CEST) Received: from LenConrad.Go2France.com [193.252.44.38] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id A1A8141B0250; Mon, 12 Aug 2002 21:51:04 +0200 Message-Id: <5.1.0.14.2.20020812213717.02e92928@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Aug 2002 21:39:54 +0200 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Re: Routing table: removing an invalid entry Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, I can't find anything in the archives, and two submissions to -questions got nothing. how to remove a route when the destination is totally fubar? today's syslog has 500 megs of: Aug 12 12:35:27 mx3 arplookup 255.255.255.0 failed: host is not on local network Aug 12 12:35:27 mx3 arpresolve: can't allocate llinfo for 255.255.255.0rt thanks Len ================ >man route? of course, I have been there, I have been to the handbook, I've been to google/bsd, and my own -question -net -isp archives, and can't find the answer. What does you "man route" say about trashing trashy entries? # route delete "64\&0x7f000001" route: bad address: 64\&0x7f000001 # route delete '64\&0x7f000001' route: bad address: 64\&0x7f000001 # route delete `64\&0x7f000001` 64&0x7f000001: Command not found. route: writing to routing socket: Invalid argument delete net : Invalid argument Len To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 13:11: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DE137B400 for ; Mon, 12 Aug 2002 13:11:07 -0700 (PDT) Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95B9343E65 for ; Mon, 12 Aug 2002 13:11:06 -0700 (PDT) (envelope-from hottymaria@gosympatico.ca) Received: from [209.226.175.136] by tomts10-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020812201052.YNQQ15981.tomts10-srv.bellnexxia.net@[209.226.175.136]>; Mon, 12 Aug 2002 16:10:52 -0400 From: To: Subject: Hey, whats up? Date: Mon, 12 Aug 2002 16:11:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020812201052.YNQQ15981.tomts10-srv.bellnexxia.net@[209.226.175.136]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

My buddies and I were average people, just like you...Then we had our great idea...
find young hot girls and proposition them to fool around on video tape.
Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!
BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, click here You will be glad you did.











If you never want to hear from me again, please click here and I will remove you from all future mailings.

----- Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 13:51:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE8FA37B400 for ; Mon, 12 Aug 2002 13:51:22 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 515C943E75 for ; Mon, 12 Aug 2002 13:51:22 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 21740AE147; Mon, 12 Aug 2002 13:51:22 -0700 (PDT) Date: Mon, 12 Aug 2002 13:51:22 -0700 From: Alfred Perlstein To: "Andrew R. Reiter" Cc: hackers@FreeBSD.ORG Subject: Re: sysv_ipc regression suite Message-ID: <20020812205121.GD65814@elvis.mu.org> References: <20020805145544.GX76284@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Andrew R. Reiter [020805 09:15] wrote: > On Mon, 5 Aug 2002, Alfred Perlstein wrote: > > :Can anyone point out or provide me with a suite to regression test > :sysv_ipc, specifically semaphores, message queues and shared memory? > : > :I'm working on SMP locking those subsystems and it would be a major > :time saver if someone could point me to something that already > :exists (or code one up for me). > : > > Not sure if you did this or not, sorry if so, but can you add your doing > the sysv ipc locking work on the SMP todo page? :D Where and how can i do this? -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 15:18: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 451B637B400; Mon, 12 Aug 2002 15:18:03 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id F023043E6E; Mon, 12 Aug 2002 15:18:02 -0700 (PDT) (envelope-from mbsd@pacbell.net) Received: from atlas ([64.160.45.209]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H0R00JSX4M2LN@mta5.snfc21.pbi.net>; Mon, 12 Aug 2002 15:18:02 -0700 (PDT) Date: Mon, 12 Aug 2002 15:18:02 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= Subject: Re: Thread-safe resolver [patches for review] In-reply-to: <20020812192250.4B81B2A7D6@canning.wemm.org> X-X-Sender: mikko@atlas.home To: Peter Wemm Cc: Maxim Sobolev , hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Message-id: <20020812150652.Q38018-100000@atlas.home> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 12 Aug 2002, Peter Wemm wrote: > Maxim Sobolev wrote: > > I also would like to hear from you whether or not you think that we > > need all those gethostbyXXX_r(3) functions. > > Yes. Because autoconf looks for them and will assume non-reentrancy if > they are not present. Also, for source compatability with linux and > solaris and just about everything else that implements this stuff. The > expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is > safe. If you can make the non_r versions safe then that is a bonus I guess. You are aware that Solaris's version of gethostbyname_r() has a different interface than Linux's (glibc 2.whatever) variant, and that both differ from AIX's gethostbyname_r()... right? Also, some systems (HP-UX 11 and Irix [not sure, though]) have a reentrant gethostbyname(), possibly alongside a _r version marked "obsolete". So, even though I agree that having _r versions might be useful, neither autoconf (which has to be smarter than just looking for a "_r" version), nor source compatibility should be considered the main reasons, IMHO. $.02, /Mikko Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 16:59:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03E2437B401 for ; Mon, 12 Aug 2002 16:59:26 -0700 (PDT) Received: from web20908.mail.yahoo.com (web20908.mail.yahoo.com [216.136.226.230]) by mx1.FreeBSD.org (Postfix) with SMTP id 3954243E6E for ; Mon, 12 Aug 2002 16:59:25 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020812235925.98910.qmail@web20908.mail.yahoo.com> Received: from [210.83.128.34] by web20908.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 16:59:25 PDT Date: Mon, 12 Aug 2002 16:59:25 -0700 (PDT) From: David Xu Subject: Re: Thread-safe resolver [patches for review] To: Terry Lambert , Maxim Sobolev Cc: "hackers@FreeBSD.ORG " , "audit@FreeBSD.ORG" , Alexander Litvin , Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > No. I don't think any of the _r functions are needed, so long > as the results are not cached by pointer instead of a copy, > before passing them from one thread to another. It's a risk on > the clobber case of a call with a cached reference outstanding > but not processed by another thread which is not an issue with > the _r functions, which require that you pass the storage down. > > Of course, if you pass down per thread storage, you could have > the same problem if you didn't copy rather than reference the > results before passing to another thread by address. > > Given that, per thread allocations ("thread local storage") > makes more sense than allocate/free fights between threads > based on who's responsible for owning the memory after an > inter-thread call. 8-). > > -- Terry localtime() etc. are candidate to make them use per thread storage. David Xu __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 17: 3:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32FEF37B400; Mon, 12 Aug 2002 17:03:53 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA71643E42; Mon, 12 Aug 2002 17:03:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0130.cvx21-bradley.dialup.earthlink.net ([209.179.192.130] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ePA1-0002cc-00; Mon, 12 Aug 2002 17:03:45 -0700 Message-ID: <3D584CAB.1BD6D8E8@mindspring.com> Date: Mon, 12 Aug 2002 17:02:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Xu Cc: Maxim Sobolev , "hackers@FreeBSD.ORG" , "audit@FreeBSD.ORG" , Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <20020812235925.98910.qmail@web20908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Xu wrote: > localtime() etc. are candidate to make them use per thread > storage. Any call that returns a pointer to a statically allocated data area is a candidate, by definition, I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 17: 5:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E033937B400; Mon, 12 Aug 2002 17:05:13 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A6343E75; Mon, 12 Aug 2002 17:05:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0130.cvx21-bradley.dialup.earthlink.net ([209.179.192.130] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ePBA-0004E1-00; Mon, 12 Aug 2002 17:04:57 -0700 Message-ID: <3D584CF2.D5306D8B@mindspring.com> Date: Mon, 12 Aug 2002 17:04:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Maxim Sobolev , hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <20020812192250.4B81B2A7D6@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > Maxim Sobolev wrote: > > I also would like to hear from you whether or not you think that we > > need all those gethostbyXXX_r(3) functions. > > Yes. Because autoconf looks for them and will assume non-reentrancy if > they are not present. Also, for source compatability with linux and > solaris and just about everything else that implements this stuff. The > expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is > safe. If you can make the non_r versions safe then that is a bonus I guess. Autoconf is evil pure and simple, from the 8th dimension. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 17:51:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5A9E37B400 for ; Mon, 12 Aug 2002 17:51:37 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4172743E77 for ; Mon, 12 Aug 2002 17:51:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0130.cvx21-bradley.dialup.earthlink.net ([209.179.192.130] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ePuE-0004vf-00 for hackers@freebsd.org; Mon, 12 Aug 2002 17:51:30 -0700 Message-ID: <3D5857D8.8CB8D051@mindspring.com> Date: Mon, 12 Aug 2002 17:50:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: How the kernel add the devices when the kernel start Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sent with permission; the original to which this was a response was supposed to go to -hackers. (Captured for the next person with the same questions). ouyang kai wrote: > > Part 1.1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable > > Name: kernel_init_problem3.txt > kernel_init_problem3.txt Type: Plain Text (text/plain) > Encoding: quoted-printable | If I have two 'fxp' devices in my box, then, the system should have | the same vars, Why don't they conflict ? How do they register? PCI devices are enumerated by the PCI bus enumerator. The enumerator goes through the IDs of all the cards that exist, and calls the driver probe routine if it matches the Vendor and product ID reported on the PCI bus. The enumerator lives in /usr/src/sys/pci/pci.c. Each matching instance has a device instance structure allocated, which is unique to the device. PCI also guarantees that two identical devices get slot-based memory ranges and other resources assigned, so they are not conflicting (cards are all in different slots, by definition). Thus the per device instance structure keeps them seperate, and the bus ensures there are no conflicts. For PCI cards that map memory to well known locations, there can be conflicts (this is especially true of vide cards). Most do not map at a fixed location, but instead map wherever the POST initialization of the BIOS tells them is available. So: 1) Machine powers on 2) Machine POSTs (Power On Self Tests) 3) BIOS POST code assigns card specific resources 4) Kernel enumerates PCI devices 5) Driver matches vendor/device ID 6) Per device instance structure is allocated 7) Per device instance structure is filled out from values set up by BIOS POST 8) Card is attached and interrupt handler is registered with address of per device instance structure 9) Interrupts come in 10) Interrupt sharing code uses PCI command to ask which card(s) cause the interrupt 11) Device driver entry point is called for card that cause the interrupt with address of per device context structure 12) Per device context structure address is converted from void pointer to device specific structure pointer static void fxp_intr(void *xsc) { struct fxp_softc *sc = xsc; 13) And interrupt processing proceeds to completion | PS: I can get the device name from the link-level sockaddr(struct | sockaddr_dl's member sdl_data:"fxp0" and "fxp1"), right? Yes, but there's really no reason to want it. It's only for displaying to the user. | >This *eventually* calls the probe, and, if it finds a device, | >the attach, so yes, many function calls deep. | I think I did not ask the question clearly. | Now, I know in the mi_startup(), the kernel complete the function of |'module_register_init'. | But, When and How the kernel 'eventually' calls the probe and attach? The bus enumerator enumerates the PCI devices. The SYSINIT() code (via DRIVER_MODULE) only registers the device hierarchy data structure. The actual top level driver in the hierarchy does the work; on i386, this is the "nexus" driver. See: /usr/src/sys/i386/i386/nexus.c. This is done in configure(): /* nexus0 is the top of the i386 device tree */ device_add_child(root_bus, "nexus", 0); /* initialize new bus architecture */ root_bus_configure(); located in: /usr/src/sys/i386/i386/autoconf.c. The declaration for this call is: SYSINIT(configure2, SI_SUB_CONFIGURE, SI_ORDER_THIRD, configure, NULL); If you look in /usr/src/sys/sys/kernel.h, you see: [...] SI_SUB_CREATE_INIT = 0x2500000, /* create the init process */ SI_SUB_DRIVERS = 0x3100000, /* Let Drivers initialize */ SI_SUB_CONFIGURE = 0x3800000, /* Configure devices */ SI_SUB_VFS = 0x4000000, /* virtual file system*/ [...] ...in other words, all the drivers get registered into the device hierarchy under the root ("nexus") in the SI_SUB_DRIVERS phase, and then they are initialized in the SI_SUB_CONFIGURE phase. Note that when you load a device driver as a module, the device hierarchy is already present. Therefore the device registers into an existing hierarchy. The probe is called (in the PCI case) only on "unclaimed" devices. For ISA and other devices, there is bus-specific behaviour. In the ISA case, it can actively probe (most ISA devices require active probing), so it can destabilize your system (by poking things that aren't ISA cards, and which do not like it when they are poked); non-legacy drivers "just work". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 12 21:43:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF7437B400 for ; Mon, 12 Aug 2002 21:43:38 -0700 (PDT) Received: from squall.waterspout.com (squall.waterspout.com [208.13.56.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 269B343E65 for ; Mon, 12 Aug 2002 21:43:38 -0700 (PDT) (envelope-from will@csociety.org) Received: by squall.waterspout.com (Postfix, from userid 1050) id 36F289B3A; Mon, 12 Aug 2002 23:43:29 -0500 (EST) Date: Mon, 12 Aug 2002 23:43:29 -0500 From: Will Andrews To: Bruce M Simpson Cc: freebsd-hackers@freebsd.org Subject: Re: Building ports into packages, outside of /usr/ports Message-ID: <20020813044328.GY78857@squall.waterspout.com> References: <20020808154814.GD18301@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020808154814.GD18301@spc.org> User-Agent: Mutt/1.3.26i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Aug 08, 2002 at 03:48:14PM +0000, Bruce M Simpson wrote: > Has anybody thought about hacking the above to support building packages > outside of the ports tree, and without installing them? Strikes me as > something that could be neatly solved with judicious use of chroot(1). > > This is something which was raised at the FreeBSD UK Users Group meeting > last night, so it's bugging me. Sure. It's something FreeBSD has been doing for almost four years now. See ports/Tools/portbuild. :-] It's designed for mass package building though, not just one. Its primary purposes are for testing, occasional package regeneration, and release package generation. Regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 0:41:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34DF837B400 for ; Tue, 13 Aug 2002 00:41:21 -0700 (PDT) Received: from hotmail.com (oe83.pav0.hotmail.com [64.4.33.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAAC143E70 for ; Tue, 13 Aug 2002 00:41:20 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Aug 2002 00:41:20 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: Subject: About nge NIC problem Date: Tue, 13 Aug 2002 15:41:07 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0000_01C242DF.D719FCE0" Message-ID: X-OriginalArrivalTime: 13 Aug 2002 07:41:20.0765 (UTC) FILETIME=[D0F20AD0:01C2429C] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C242DF.D719FCE0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0001_01C242DF.D71C46D0" ------=_NextPart_002_0001_01C242DF.D71C46D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, I have trouble in using nge NIC(LinkSys EG1032) to support Novell and App= le in FreeBSD 4.5. The apple software is netatalk 1.5.3.1. And the novell netware software i= s MARS_NWE. The TCP/IP and the Samba work well on the nge. Do you have any experiance on netatalk and MARS_NWE of the nge NIC? Please help. Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://exp= lorer.msn.com ------=_NextPart_002_0001_01C242DF.D71C46D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
I have = trouble in using nge NIC(LinkSys EG1032) to support Novell and Apple
i= n FreeBSD 4.5.
The apple software is netatalk 1.5.3.1. And the novell = netware software is
MARS_NWE.
The TCP/IP and the Samba work well on= the nge.
Do you have any experiance on netatalk and MARS_NWE of the n= ge NIC?
Please help.
 
Best Regards
Ouya= ng Kai

Get more from the Web. FRE= E MSN Explorer download : http://expl= orer.msn.com

------=_NextPart_002_0001_01C242DF.D71C46D0-- ------=_NextPart_001_0000_01C242DF.D719FCE0 Content-Type: text/plain; name="nge_problem.txt" Content-Disposition: attachment; filename="nge_problem.txt" Hi, I have trouble in using nge NIC(LinkSys EG1032) to support Novell and Apple in FreeBSD 4.5. The apple software is netatalk 1.5.3.1. And the novell netware software is MARS_NWE. The TCP/IP and the Samba work well on the nge. Do you have any experiance on netatalk and MARS_NWE of the nge NIC? Please help. Best Regards Ouyang Kai ------=_NextPart_001_0000_01C242DF.D719FCE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 1:14:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7917437B400; Tue, 13 Aug 2002 01:14:17 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76EC243E65; Tue, 13 Aug 2002 01:14:13 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id LAA47364; Tue, 13 Aug 2002 11:13:51 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7D8Dl8c047320; Tue, 13 Aug 2002 11:13:48 +0300 (EEST) Received: from vega.vega.com (h81.234.dialup.iptcom.net [212.9.234.81]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7D8DgoQ023263; Tue, 13 Aug 2002 11:13:44 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7D8DfF2042236; Tue, 13 Aug 2002 11:13:41 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D58BFE8.9281433@FreeBSD.org> Date: Tue, 13 Aug 2002 11:14:32 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Terry Lambert Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> <3D57CF6D.2982CE8@mindspring.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Maxim Sobolev wrote: > > > You may also want to consider the use of a .init and .fini > > > section for the code, to permit the creation of an initial > > > lookup context chunk; this is kind of a tradeoff, but it will > > > mean that a server will not have to do the recheck each time. > > > The .fini section would aloow auto-cleanup. This may be a > > > necessity for a long running program that uses a shared object > > > to perform the thread creation and lookup (you could leak > > > memory, otherwise). > > > > Could you please elaborate how exactly memory could be leaked in this > > case, if the program does correctly shut down all its threads? > > Create PIC object foo.so. > Link PIC object foo.so against libc.so. > Call dlopen to load module foo.so into program "bob". > Call function in foo.so from program "bob". > Function in foo.so creates two threads, one for IPv4 lookup, > another for IPv6 lookup to cause lookups to proceed > concurrently. > Lookup completes. > Unload module foo.so. > -> leak memory in libc.so image This scenario doesn't look as a legitimate way to do things for me. Let's inspect what will happen when you are unloading a PIC module, which has one or more threads running. There are two possibilities: either thread scheduler (libc_r) was linked with the program itself and therefore loaded with it, or it was linked with PIC module and loaded along with that module. In the first case, after you have dlclose'd the PIC module, dynamic linker will unmap module's code from memory, but the thread scheduler will remain running and on the next attempt to pass control to the thread in your PIC module will probably get SIGBUS due to the fact that code is no longer mapped. In the second case, you'll unload module along with thread scheduler, but thread-scheduling signals setup will remain in place, so that shortly you will get the same SIGBUS, when the kernel will be trying to delivery signal to no longer mapper region. In either case, you will get the problem much more serious than memory leak. > The assumption (which is potentially wrong) is that the program > will correctly shut down all its threads, when in fact it was a > module not under the programs control that created and used the > threads. I do not quite agree. In such case, the module should probably have destructor function, either placed into the fini section, or to be explicitly called by the program before dlclose(). > The leak depends on: > > 1) A pool of worker threads being created and left around > or the purpose of simultaneous resolution > > 2) The parent shutting down the module without explicitly > dealing with the threads (basically, code which would > need to live in ".fini" of the foo.so, and could not be > automatically triggered on unload of foo.so any other way). > > I think that parallel IPv6/IPv4 resolution presented as a single > serial interface is a high probability implementation with the > support for threaded access to the resolver, particularly with > the Mozilla code acting the way it does. > > > I also would like to hear from you whether or not you think that we > > need all those gethostbyXXX_r(3) functions. > > No. I don't think any of the _r functions are needed, so long > as the results are not cached by pointer instead of a copy, > before passing them from one thread to another. It's a risk on > the clobber case of a call with a cached reference outstanding > but not processed by another thread which is not an issue with > the _r functions, which require that you pass the storage down. > > Of course, if you pass down per thread storage, you could have > the same problem if you didn't copy rather than reference the > results before passing to another thread by address. > > Given that, per thread allocations ("thread local storage") > makes more sense than allocate/free fights between threads > based on who's responsible for owning the memory after an > inter-thread call. 8-). Thank you for the explanation! -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 1:31:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E0A037B400; Tue, 13 Aug 2002 01:31:40 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB97643E42; Tue, 13 Aug 2002 01:31:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0012.cvx21-bradley.dialup.earthlink.net ([209.179.192.12] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eX5R-0006a4-00; Tue, 13 Aug 2002 01:31:33 -0700 Message-ID: <3D58C359.A5F7B1AA@mindspring.com> Date: Tue, 13 Aug 2002 01:29:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> <3D57CF6D.2982CE8@mindspring.com> <3D58BFE8.9281433@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > This scenario doesn't look as a legitimate way to do things for me. > Let's inspect what will happen when you are unloading a PIC module, > which has one or more threads running. There are two possibilities: > either thread scheduler (libc_r) was linked with the program itself > and therefore loaded with it, or it was linked with PIC module and > loaded along with that module. In the first case, after you have > dlclose'd the PIC module, dynamic linker will unmap module's code from > memory, but the thread scheduler will remain running and on the next > attempt to pass control to the thread in your PIC module will probably > get SIGBUS due to the fact that code is no longer mapped. In the > second case, you'll unload module along with thread scheduler, but > thread-scheduling signals setup will remain in place, so that shortly > you will get the same SIGBUS, when the kernel will be trying to > delivery signal to no longer mapper region. Unless you have a single exported API from the .so that takes a single request, and does simultaneous lookups. The result will be two inactive threads hanging on a condition variable which will never come true, because the function which makes it true in order to trigger the parallel lookup has been unloaded. Basically, a sleep is a sleep, and it doesn't matter if the code that caused it is there any more or not, if you never get a wakeup. To use an analogy, it doesn't matter if the SIGHUP handler will cause a core dump, if you never get a SIGHUP, does it? > In either case, you will get the problem much more serious than memory > leak. Assuming, incorrectly, that you are talking to the threads directly, rather than to a proxy function. The calling program need not be threaded or support threads. > > The assumption (which is potentially wrong) is that the program > > will correctly shut down all its threads, when in fact it was a > > module not under the programs control that created and used the > > threads. > > I do not quite agree. In such case, the module should probably have > destructor function, either placed into the fini section, or to be > explicitly called by the program before dlclose(). Uh, that's exactly the argument I was making: use a .fini section to clean up the per thread memory allocations. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 3:14:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6969037B400; Tue, 13 Aug 2002 03:14:47 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1053443E3B; Tue, 13 Aug 2002 03:14:43 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA76900; Tue, 13 Aug 2002 13:14:23 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7DAEJ8c076830; Tue, 13 Aug 2002 13:14:20 +0300 (EEST) Received: from vega.vega.com (h124.234.dialup.iptcom.net [212.9.234.124]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7DADvoQ081252; Tue, 13 Aug 2002 13:14:16 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7DADuF2042460; Tue, 13 Aug 2002 13:13:56 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D58DC16.5AB834BF@FreeBSD.org> Date: Tue, 13 Aug 2002 13:14:46 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Daniel Eischen Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > On Mon, 12 Aug 2002, Maxim Sobolev wrote: > > Folks, > > > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > resolver thread-safe. They represent two approaches to reach this goal > > - the first is to introduce reentrant versions of the standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > Why do you need uthread_resolv.c? You should be able to thread > calls by checking __isthreaded. Just keep everything in libc. > If there are missing stubs for some pthread_* routines (I think > everything you need is in -current's libc), then add them. I did that, but I can't fugure out correct way to get _thread_run and _thread_initial symbols into libc from libc_r. Any ideas? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 4:14:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2868037B400; Tue, 13 Aug 2002 04:14:19 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DDE743E6A; Tue, 13 Aug 2002 04:14:18 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g7DBEHHB039753; Tue, 13 Aug 2002 13:14:17 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g7DBEGYW749434; Tue, 13 Aug 2002 13:14:16 +0200 (MES) Date: Tue, 13 Aug 2002 13:15:56 +0200 (CEST) From: Martin Blapp To: , Subject: Wrong paths for named-xfer (STABLE/CURRENT) Message-ID: <20020813130926.O4313-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, We noted that named-xfer does not work in STABLE and CURRENT. Named does look for it in /usr/local/libexec than in /usr/libexec. But named-xfer gets installed into /usr/libexec. I guess the paths are just plain wrong here in the Makefile. I made a patch: --- contrib/bind/bin/named/Makefile.orig Tue Aug 13 13:05:29 2002 +++ contrib/bind/bin/named/Makefile Tue Aug 13 13:05:32 2002 @@ -33,9 +33,9 @@ EXE= YACC = yacc -d SYSLIBS = -ll -lutil -DESTBIN = /usr/local/bin -DESTSBIN = /usr/local/sbin -DESTEXEC = /usr/local/libexec +DESTBIN = /usr/bin +DESTSBIN = /usr/sbin +DESTEXEC = /usr/libexec DESTMAN = /usr/share/man DESTHELP= /usr/share/misc DESTETC= /etc We don't install named into /usr/local, do we ? Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 4:58: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1966837B400; Tue, 13 Aug 2002 04:57:59 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711CA43E6E; Tue, 13 Aug 2002 04:57:57 -0700 (PDT) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (p5087B6AA.dip.t-dialin.net [80.135.182.170]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g7DBvl0Z005502 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 13 Aug 2002 13:57:50 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g7DBvYFJ066576 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 13 Aug 2002 13:57:34 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g7DBvXaP066575; Tue, 13 Aug 2002 13:57:33 +0200 (CEST)?g (envelope-from ticso) Date: Tue, 13 Aug 2002 13:57:33 +0200 From: Bernd Walter To: Martin Blapp Cc: dougb@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Wrong paths for named-xfer (STABLE/CURRENT) Message-ID: <20020813115732.GP55760@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <20020813130926.O4313-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020813130926.O4313-100000@levais.imp.ch> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 13, 2002 at 01:15:56PM +0200, Martin Blapp wrote: > > Hi, > > We noted that named-xfer does not work in STABLE and CURRENT. > Named does look for it in /usr/local/libexec than in /usr/libexec. > > But named-xfer gets installed into /usr/libexec. > > I guess the paths are just plain wrong here in the Makefile. > > I made a patch: > > --- contrib/bind/bin/named/Makefile.orig Tue Aug 13 13:05:29 2002 > +++ contrib/bind/bin/named/Makefile Tue Aug 13 13:05:32 2002 > @@ -33,9 +33,9 @@ > EXE= > YACC = yacc -d > SYSLIBS = -ll -lutil > -DESTBIN = /usr/local/bin > -DESTSBIN = /usr/local/sbin > -DESTEXEC = /usr/local/libexec > +DESTBIN = /usr/bin > +DESTSBIN = /usr/sbin > +DESTEXEC = /usr/libexec > DESTMAN = /usr/share/man > DESTHELP= /usr/share/misc > DESTETC= /etc > > We don't install named into /usr/local, do we ? We don't use Makesfile inside src/contrib. See src/usr/sbin/named/Makefile.inc where the values are correct. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 5:41:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C41937B400; Tue, 13 Aug 2002 05:41:10 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2329243E3B; Tue, 13 Aug 2002 05:41:09 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g7DCf5HB065674; Tue, 13 Aug 2002 14:41:05 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g7DCf5YW750793; Tue, 13 Aug 2002 14:41:05 +0200 (MES) Date: Tue, 13 Aug 2002 14:42:44 +0200 (CEST) From: Martin Blapp To: Cc: , Subject: Re: Wrong paths for named-xfer (STABLE/CURRENT) In-Reply-To: <20020813115732.GP55760@cicely5.cicely.de> Message-ID: <20020813144059.P4313-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > > We don't install named into /usr/local, do we ? > > We don't use Makesfile inside src/contrib. Thanks very much ! > See src/usr/sbin/named/Makefile.inc where the values are correct. Ahh know I see what happened. I went one time into src/contrib last week and typed make at the wrong place. Then pathnamed.h was accidently generated. From a normal build, this file was used and - bang ... :/ Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 7:34: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A04D037B400 for ; Tue, 13 Aug 2002 07:34:02 -0700 (PDT) Received: from ns3.safety.net (ns3.safety.net [216.40.201.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C11143E42 for ; Tue, 13 Aug 2002 07:34:02 -0700 (PDT) (envelope-from les@ns3.safety.net) Received: (from les@localhost) by ns3.safety.net (8.10.2/8.10.2) id g7DEY1205125 for hackers@freebsd.org; Tue, 13 Aug 2002 07:34:01 -0700 From: Les Biffle Message-Id: <200208131434.g7DEY1205125@ns3.safety.net> Subject: IP routing question To: hackers@freebsd.org Date: Tue, 13 Aug 2002 07:34:01 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL94 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I want to do the following: 1. Create "n" IPSEC VPN tunnels 2. Create "n" VLAN pseudo interfaces 3. Route IP Packets based on their arrival iface/tunnel out through a corresponding tunnel/iface. For example, I want to route all packets received through VPN tunnel "2" out through VLAN "2," and all packets received on VLAN "2" out through VPN "2," without regard to source or destination IP Addresses. I don't want to examine the IP Addresses of any of the routed packets, but only want to make the routing decision based on arrival interface. Does anyone have any ideas or suggestions? Please? -Les -- Les Biffle (480) 585-4099 les@safety.net http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 7:48:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71FB937B400 for ; Tue, 13 Aug 2002 07:48:11 -0700 (PDT) Received: from cpw.math.columbia.edu (cpw.math.columbia.edu [128.59.192.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B2043E72 for ; Tue, 13 Aug 2002 07:48:10 -0700 (PDT) (envelope-from atici@math.columbia.edu) Received: from cpw.math.columbia.edu (atici@localhost [127.0.0.1]) by cpw.math.columbia.edu (8.12.2/8.12.2) with ESMTP id g7DEm9fq013560 for ; Tue, 13 Aug 2002 10:48:09 -0400 Received: from localhost (atici@localhost) by cpw.math.columbia.edu (8.12.2/8.12.2/Submit) with ESMTP id g7DEm9pW013557 for ; Tue, 13 Aug 2002 10:48:09 -0400 Date: Tue, 13 Aug 2002 10:48:09 -0400 (EDT) From: Alp ATICI To: freebsd-hackers@FreeBSD.ORG Subject: Port for Sun Grdiware 5.3 In-Reply-To: <20020803160915.B55525-100000@sasami.jurai.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there any port of Sun Gridware 5.3 for FreeBSD? I found the source code is open and there're binaries for several arch/OS's there but couldn't see any FreeBSD port. http://gridengine.sunsource.net Let me know if you have any information about that. Thanks, Alp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 8:15:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9005937B400 for ; Tue, 13 Aug 2002 08:15:28 -0700 (PDT) Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0894143E6A for ; Tue, 13 Aug 2002 08:15:28 -0700 (PDT) (envelope-from andrew@ugh.net.au) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 267B8A80A; Wed, 14 Aug 2002 01:15:26 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 23DCF5425 for ; Wed, 14 Aug 2002 01:15:26 +1000 (EST) Date: Wed, 14 Aug 2002 01:15:26 +1000 (EST) From: Andrew To: hackers@freebsd.org Subject: Re: IP routing question (fwd) Message-ID: <20020814011205.D58835-100000@starbug.ugh.net.au> X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I tried to send this directly however it seems your provider is blocking something like 203.0.0.0/8...or I'm just unlucky... Andrew ---------- Forwarded message ---------- Date: Wed, 14 Aug 2002 00:46:27 +1000 (EST) From: Andrew To: Les Biffle Subject: Re: IP routing question On Tue, 13 Aug 2002, Les Biffle wrote: > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. You might get away with ipfw rulles using via and next-hop. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 9:13:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C935B37B401 for ; Tue, 13 Aug 2002 09:13:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C09F43E7B for ; Tue, 13 Aug 2002 09:13:18 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nyogpitv0wfnytff@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7DGD0r15585; Tue, 13 Aug 2002 09:13:00 -0700 (PDT) Message-ID: <3D59300C.8090906@isi.edu> Date: Tue, 13 Aug 2002 09:13:00 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Les Biffle Cc: hackers@freebsd.org Subject: Re: IP routing question References: <200208131434.g7DEY1205125@ns3.safety.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080207020408080208010909" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms080207020408080208010909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Les Biffle wrote: > 1. Create "n" IPSEC VPN tunnels > 2. Create "n" VLAN pseudo interfaces > 3. Route IP Packets based on their arrival iface/tunnel out through > a corresponding tunnel/iface. > > For example, I want to route all packets received through VPN tunnel "2" > out through VLAN "2," and all packets received on VLAN "2" out through > VPN "2," without regard to source or destination IP Addresses. > > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. > > Does anyone have any ideas or suggestions? Please? IPsec tunnel mode won't work, since SAs aren't represented as Interfaces. I'm not aware of any routing daemon that can use inbound interfaces as a parameter in its forwarding decision, otherwise using IPIP tunnels together with IPsec transport mode (draft-touch-ipsec-vpn-04.txt) might have worked with whatever daemon does that. You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, but then you say you don't want to look at IP addresses... So no, I don't see how it can be done under your constraints. Lars -- Lars Eggert USC Information Sciences Institute --------------ms080207020408080208010909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMzE2MTMwMFowIwYJKoZIhvcNAQkEMRYEFC6m8vUi8D7h ly7vEId/qeP1GcObMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBK+5lze1PmyQB0xOQ8YklaHyyTwE+MCHd0nxt45D5ytWnM aVdUUUqosiCDEkVhMw/nhtq09a4DH+rb5/6d8sLR9Wa3IKrSqTkbnrvEnQDmc15jUYBoUGQX iPZDWy5icLa4k3SGHPuwPBFszgl007qT1WDbAvNHd8LNKloEmHf7mQAAAAAAAA== --------------ms080207020408080208010909-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 9:41:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2377F37B400; Tue, 13 Aug 2002 09:41:52 -0700 (PDT) Received: from viola.sinor.ru (viola.sinor.ru [217.70.106.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BFE043E42; Tue, 13 Aug 2002 09:41:51 -0700 (PDT) (envelope-from semenu@FreeBSD.org) Received: from tlg5-ppp68.sibnet.ru (tlg5-ppp68.sibnet.ru [217.70.116.68]) by viola.sinor.ru (8.12.3/8.12.3) with ESMTP id g7DGfkrZ014671; Tue, 13 Aug 2002 23:41:47 +0700 Date: Tue, 13 Aug 2002 23:41:14 +0700 (NOVST) From: "Semen A. Ustimenko" X-X-Sender: semenu@main.the.net To: freebsd-hackers@FreeBSD.org Cc: freebsd-scsi@FreeBSD.org Subject: SCSI device emulation using SCSI host controller Message-ID: <20020813232629.L568-100000@main.the.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I beg you all pardon for a question not related directly to FreeBSD, but if the answer is ``yes'', then I believe FreeBSD will be in deal. The question is: "Can I emulate a SCSI device (tape, if that matters) using usual SCSI host controller and specific software, or I will definitely need specific hardware?" Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 11:13:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E964E37B400 for ; Tue, 13 Aug 2002 11:13:46 -0700 (PDT) Received: from ns3.safety.net (ns3.safety.net [216.40.201.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 929D443E65 for ; Tue, 13 Aug 2002 11:13:46 -0700 (PDT) (envelope-from les@ns3.safety.net) Received: (from les@localhost) by ns3.safety.net (8.10.2/8.10.2) id g7DIDiH14643; Tue, 13 Aug 2002 11:13:44 -0700 From: Les Biffle Message-Id: <200208131813.g7DIDiH14643@ns3.safety.net> Subject: Re: IP routing question In-Reply-To: <3D59300C.8090906@isi.edu> To: Lars Eggert Date: Tue, 13 Aug 2002 11:13:44 -0700 (MST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL94 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG (snip) > You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, > but then you say you don't want to look at IP addresses... I'm happy to look at outside addresses, just not the ones on the inside. I would also consider matching up endpoint (VPN gateway or "outside") address and SPI to know which SA a packet is arriving on, for the inbound-through-tunnel direction, and then use the vlan interface name to help select the departing tunnel, if possible. > So no, I don't see how it can be done under your constraints. Well, not perhaps without some nethacks in the kernel. I've certainly done that before, but would prefer something more vanilla. Thanks, -Les -- Les Biffle (480) 585-4099 les@safety.net http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 11:21:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC60437B400 for ; Tue, 13 Aug 2002 11:21:06 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 6411343E70 for ; Tue, 13 Aug 2002 11:21:02 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 35644 invoked by uid 1000); 13 Aug 2002 18:21:03 -0000 Date: Tue, 13 Aug 2002 11:21:02 -0700 (PDT) From: Nate Lawson To: "Semen A. Ustimenko" Cc: freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: SCSI device emulation using SCSI host controller In-Reply-To: <20020813232629.L568-100000@main.the.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Yes. sys/cam/scsi/scsi_target* /usr/share/examples/scsi_target On Tue, 13 Aug 2002, Semen A. Ustimenko wrote: > Hi! > > I beg you all pardon for a question not related directly to FreeBSD, but > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > The question is: "Can I emulate a SCSI device (tape, if that matters) > using usual SCSI host controller and specific software, or I will > definitely need specific hardware?" > > Thanks! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 12:29:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E07E337B400; Tue, 13 Aug 2002 12:29:37 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0103E43E6E; Tue, 13 Aug 2002 12:29:37 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g7DJTaKD051648; Tue, 13 Aug 2002 13:29:36 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g7DJTZ2O051647; Tue, 13 Aug 2002 13:29:36 -0600 (MDT) (envelope-from ken) Date: Tue, 13 Aug 2002 13:29:35 -0600 From: "Kenneth D. Merry" To: "Semen A. Ustimenko" Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI device emulation using SCSI host controller Message-ID: <20020813132935.A51629@panzer.kdm.org> References: <20020813232629.L568-100000@main.the.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020813232629.L568-100000@main.the.net>; from semenu@FreeBSD.ORG on Tue, Aug 13, 2002 at 11:41:14PM +0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > Hi! > > I beg you all pardon for a question not related directly to FreeBSD, but > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > The question is: "Can I emulate a SCSI device (tape, if that matters) > using usual SCSI host controller and specific software, or I will > definitely need specific hardware?" You'll need either the right Adaptec or QLogic controller, but yes, it can be done with FreeBSD. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 12:31:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0515137B400 for ; Tue, 13 Aug 2002 12:31:39 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id B505C43E4A for ; Tue, 13 Aug 2002 12:31:37 -0700 (PDT) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g7DJVQWr042325 for ; Tue, 13 Aug 2002 15:31:26 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host hiten@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g7DJVNXf042316 for freebsd-hackers@FreeBSD.org; Tue, 13 Aug 2002 15:31:23 -0400 (EDT) (envelope-from hiten) Date: Tue, 13 Aug 2002 15:31:23 -0400 From: Hiten Pandya To: freebsd-hackers@FreeBSD.org Subject: SysV IPC related question Message-ID: <20020813153123.A41757@angelica.unixdaemons.com> Reply-To: hiten@uk.FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all. I was wondering why we have a struct mymsg in , when many utilities defined their own version of it. I am curious about this because our stock version of struct mymsg: struct mymsg { long mtype; /* message type */ char mtext[1]; /* message body */ }; Why do we have a value of [1] in the mtext array? Are we meant to define a struct mymsg at all!? Thanks. Regards. -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@xMach.org PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 13: 0:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E2C837B400 for ; Tue, 13 Aug 2002 13:00:25 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0958243E70 for ; Tue, 13 Aug 2002 13:00:25 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813200024.LRFI13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 13 Aug 2002 20:00:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA17963; Tue, 13 Aug 2002 12:51:32 -0700 (PDT) Date: Tue, 13 Aug 2002 12:51:31 -0700 (PDT) From: Julian Elischer To: Les Biffle Cc: hackers@freebsd.org Subject: Re: IP routing question In-Reply-To: <200208131434.g7DEY1205125@ns3.safety.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 13 Aug 2002, Les Biffle wrote: > Hi, > > I want to do the following: > > 1. Create "n" IPSEC VPN tunnels > 2. Create "n" VLAN pseudo interfaces > 3. Route IP Packets based on their arrival iface/tunnel out through > a corresponding tunnel/iface. > > For example, I want to route all packets received through VPN tunnel "2" > out through VLAN "2," and all packets received on VLAN "2" out through > VPN "2," without regard to source or destination IP Addresses. incoming packets should be selectabl in ipfw by using the clause "in recv gif0" or "in recv vlan0" then you should be able to redirec thtem using the 'fwd' command assuming gif0 has a remote end (of the tunnel) at 1.1.1.1 and a packet arrived on vlan0, and the machine you want to forward to on vlan0 is 2.2.2.2 the following ipfw commands should work (not tested).. fwd 1.1.1.1 ip from any to any in recv vlan0 the reverse packets should be redirected by: fwd 2.2.2.2 ip from any to any in recv gif0 As I say, this has not been tested.. let uis know what happens so that others can do this if it works.... > > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. > > Does anyone have any ideas or suggestions? Please? > > -Les > > -- > Les Biffle > (480) 585-4099 les@safety.net http://www.les.safety.net/ > Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 13:16:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C3A737B400 for ; Tue, 13 Aug 2002 13:16:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1AF343E65 for ; Tue, 13 Aug 2002 13:16:42 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (0rjqu8kzzeh1evru@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7DKGcr01931; Tue, 13 Aug 2002 13:16:38 -0700 (PDT) Message-ID: <3D596925.60906@isi.edu> Date: Tue, 13 Aug 2002 13:16:37 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Julian Elischer Cc: Les Biffle , hackers@freebsd.org Subject: Re: IP routing question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005090706050209010907" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms090005090706050209010907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > On Tue, 13 Aug 2002, Les Biffle wrote: >>I want to do the following: >> >>1. Create "n" IPSEC VPN tunnels >>2. Create "n" VLAN pseudo interfaces >>3. Route IP Packets based on their arrival iface/tunnel out through >> a corresponding tunnel/iface. >> >>For example, I want to route all packets received through VPN tunnel "2" >>out through VLAN "2," and all packets received on VLAN "2" out through >>VPN "2," without regard to source or destination IP Addresses. > > incoming packets should be selectabl in ipfw by using the > clause > "in recv gif0" Minor point: IPsec tunnel mode tunnels aren't gif tunnels - he'd need to use IPIP tunnels + IPsec transport mode in that case (see draft-touch-ipsec-vpn04.txt), which I recommend anyway, of course :-) I hadn't thought of using the ipfw "in" selector, good idea! Lars -- Lars Eggert USC Information Sciences Institute --------------ms090005090706050209010907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMzIwMTYzN1owIwYJKoZIhvcNAQkEMRYEFMzFxqpayYNv EPgrjd1qxsHjF4iaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYClY+O97iq9v75G/5pOCo2pdXN41sw2J/emPmGuejru9q7W cuB7PxMqJ+sfuNOcw2Y+oNjqNZWBOxdDAd4+pWuHiD8soJwx7fsD27I5Virl0gO0/ILQ1cvA F+LdQG36OWYEPRePaToZY/cwWDdf6lqfyqFmUqkZA1qlyievHqYIHgAAAAAAAA== --------------ms090005090706050209010907-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 15:25:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 416CB37B400 for ; Tue, 13 Aug 2002 15:25:23 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7398A43E42 for ; Tue, 13 Aug 2002 15:25:19 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6279472FC5; Tue, 13 Aug 2002 15:21:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5EC9A72D9E; Tue, 13 Aug 2002 15:21:59 -0700 (PDT) Date: Tue, 13 Aug 2002 15:21:59 -0700 (PDT) From: Doug White To: Len Conrad Cc: freebsd-hackers@freebsd.org Subject: Re: Routing table: removing an invalid entry In-Reply-To: <5.1.0.14.2.20020812213717.02e92928@mail.Go2France.com> Message-ID: <20020813152116.J50258-100000@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 12 Aug 2002, Len Conrad wrote: > Sorry, I can't find anything in the archives, and two submissions to > -questions got nothing. > > how to remove a route when the destination is totally fubar? [...] > # route delete "64\&0x7f000001" > route: bad address: 64\&0x7f000001 You mean the ones with bogus netmasks? Give the netmask in the 'route delete' arguments. route delete 64 netmask 0x7f000001 That might work :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:20:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 608DB37B400 for ; Tue, 13 Aug 2002 16:20:50 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D94543E6A for ; Tue, 13 Aug 2002 16:20:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0032.cvx40-bradley.dialup.earthlink.net ([216.244.42.32] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ekxw-0003wS-00; Tue, 13 Aug 2002 16:20:44 -0700 Message-ID: <3D599416.5CDE92D9@mindspring.com> Date: Tue, 13 Aug 2002 16:19:50 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Les Biffle Cc: Lars Eggert , hackers@freebsd.org Subject: Re: IP routing question References: <200208131813.g7DIDiH14643@ns3.safety.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Les Biffle wrote: > > You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, > > but then you say you don't want to look at IP addresses... > > I'm happy to look at outside addresses, just not the ones on the inside. > I would also consider matching up endpoint (VPN gateway or "outside") > address and SPI to know which SA a packet is arriving on, for the > inbound-through-tunnel direction, and then use the vlan interface name > to help select the departing tunnel, if possible. > > > So no, I don't see how it can be done under your constraints. > > Well, not perhaps without some nethacks in the kernel. I've certainly > done that before, but would prefer something more vanilla. One short answer is to not set a default route, per se. I know this is ugly, but it fixes the IPSec tunnel problem. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:24: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EF837B400 for ; Tue, 13 Aug 2002 16:24:06 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477A743E6E for ; Tue, 13 Aug 2002 16:24:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0032.cvx40-bradley.dialup.earthlink.net ([216.244.42.32] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17el12-0000Yd-00; Tue, 13 Aug 2002 16:23:57 -0700 Message-ID: <3D5994D7.E047294C@mindspring.com> Date: Tue, 13 Aug 2002 16:23:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hiten@uk.FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: SysV IPC related question References: <20020813153123.A41757@angelica.unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > I was wondering why we have a struct mymsg in , when many > utilities defined their own version of it. I am curious about this > because our stock version of struct mymsg: > > struct mymsg { > long mtype; /* message type */ > char mtext[1]; /* message body */ > }; > > Why do we have a value of [1] in the mtext array? Are we meant to > define a struct mymsg at all!? This is the message contents. It is an overlay structure. The [1] is the same thing that, in the current ANSI C standard, you would define in terms of [0]. The point is that you have a structure that sonsists of a long followed by an indeterminate number of bytes. You cast the combination to a pointer to a structure of this type, and you can reference the long as mymsgp->mtype, and the contents as mymsgp->mtype. Please leave it alone. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:30:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B06CA37B405 for ; Tue, 13 Aug 2002 16:30:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F4843E3B for ; Tue, 13 Aug 2002 16:30:04 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (30fg54hp7ri2op2e@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7DNU2r12458; Tue, 13 Aug 2002 16:30:02 -0700 (PDT) Message-ID: <3D599679.5090507@isi.edu> Date: Tue, 13 Aug 2002 16:30:01 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Terry Lambert Cc: Les Biffle , hackers@freebsd.org Subject: Re: IP routing question References: <200208131813.g7DIDiH14643@ns3.safety.net> <3D599416.5CDE92D9@mindspring.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000903020107080709070207" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms000903020107080709070207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Les Biffle wrote: > >>>You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, >>>but then you say you don't want to look at IP addresses... >> >>I'm happy to look at outside addresses, just not the ones on the inside. >>I would also consider matching up endpoint (VPN gateway or "outside") >>address and SPI to know which SA a packet is arriving on, for the >>inbound-through-tunnel direction, and then use the vlan interface name >>to help select the departing tunnel, if possible. >> >> >>>So no, I don't see how it can be done under your constraints. >> >>Well, not perhaps without some nethacks in the kernel. I've certainly >>done that before, but would prefer something more vanilla. > > > > One short answer is to not set a default route, per se. > > I know this is ugly, but it fixes the IPSec tunnel problem. I don't think we have the same definition of "the IPSec tunnel problem." Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates encapsulation and firewalling techniques that are (better) handled outside IPsec", see draft-touch-ipsec-vpn. Having or not having a default route won't matter, since you'll have more specific routes that match before the default route would be picked. Lars -- Lars Eggert USC Information Sciences Institute --------------ms000903020107080709070207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMzIzMzAwMVowIwYJKoZIhvcNAQkEMRYEFGs1KgUV236+ CnoWfW9COFXixgepMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAe/XnoEt973JagXljOIEKGoCwOmRTzokxn2SGMPGtuiGh4 C/suvQPzISGMBHGW0ZzYtkJV8zA/0u684M8JiO2mfNJAdFdNfYKnY8HyhXj9Bmem13JzOJZA yU1wccBjjcG8idaakcokI03pwQLoD9/Y2zmvbKaq7A7njolmRTvUpQAAAAAAAA== --------------ms000903020107080709070207-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:35: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0BD237B400 for ; Tue, 13 Aug 2002 16:34:59 -0700 (PDT) Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by mx1.FreeBSD.org (Postfix) with SMTP id 52EDB43E42 for ; Tue, 13 Aug 2002 16:34:59 -0700 (PDT) (envelope-from hitmaster2k@yahoo.com) Message-ID: <20020813233459.25838.qmail@web21102.mail.yahoo.com> Received: from [62.254.0.5] by web21102.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 16:34:59 PDT Date: Tue, 13 Aug 2002 16:34:59 -0700 (PDT) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: Re: SysV IPC related question To: Terry Lambert Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <3D5994D7.E047294C@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- Terry Lambert wrote: > Hiten Pandya wrote: > > I was wondering why we have a struct mymsg in , when many > > utilities defined their own version of it. I am curious about this > > because our stock version of struct mymsg: > > > > struct mymsg { > > long mtype; /* message type */ > > char mtext[1]; /* message body */ > > }; > > > > Why do we have a value of [1] in the mtext array? Are we meant to > > define a struct mymsg at all!? > > This is the message contents. It is an overlay structure. The > [1] is the same thing that, in the current ANSI C standard, you > would define in terms of [0]. > > The point is that you have a structure that sonsists of a long > followed by an indeterminate number of bytes. You cast the > combination to a pointer to a structure of this type, and you > can reference the long as mymsgp->mtype, and the contents as > mymsgp->mtype. > > Please leave it alone. 8-). OK. One more question; so, is there any particular reason why our cousin NetBSD doesnt use this "overlay" structure? Also, the NetBSD SysV Msg regression tool defines its own struct mymsg; and doesnt have one standard in the header file. Also, if possible, could you outline some situations where this would be used? Help will be very appreicated. Thanks. -- Hiten __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:44:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C441837B400 for ; Tue, 13 Aug 2002 16:44:28 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5640343E70 for ; Tue, 13 Aug 2002 16:44:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0032.cvx40-bradley.dialup.earthlink.net ([216.244.42.32] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17elKc-0005NI-00; Tue, 13 Aug 2002 16:44:10 -0700 Message-ID: <3D599992.7C954D42@mindspring.com> Date: Tue, 13 Aug 2002 16:43:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert Cc: Les Biffle , hackers@freebsd.org Subject: Re: IP routing question References: <200208131813.g7DIDiH14643@ns3.safety.net> <3D599416.5CDE92D9@mindspring.com> <3D599679.5090507@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lars Eggert wrote: > I don't think we have the same definition of "the IPSec tunnel problem." > Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates > encapsulation and firewalling techniques that are (better) handled > outside IPsec", see draft-touch-ipsec-vpn. > > Having or not having a default route won't matter, since you'll have > more specific routes that match before the default route would be picked. As you say, SA's are not interfaces. Try pinging over the link from hosts on either side of the tunnel, e.g.: 10.0.1.15/8<--->10.0.1.1/8 10.0.2.1/8<---->10.0.2.11/8 public IP #1<----------->public IP #2 Ping #1 <----------------------------> works Ping #2 <------------------------------------------->broken Get rid of the default route, and ping #2 starts working. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 16:58: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D168537B400 for ; Tue, 13 Aug 2002 16:57:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99CB643E4A for ; Tue, 13 Aug 2002 16:57:56 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (wvtv4lrlv51fmx7l@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7DNvrr29818; Tue, 13 Aug 2002 16:57:53 -0700 (PDT) Message-ID: <3D599D00.8070807@isi.edu> Date: Tue, 13 Aug 2002 16:57:52 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Terry Lambert Cc: Les Biffle , hackers@freebsd.org Subject: Re: IP routing question References: <200208131813.g7DIDiH14643@ns3.safety.net> <3D599416.5CDE92D9@mindspring.com> <3D599679.5090507@isi.edu> <3D599992.7C954D42@mindspring.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010207080004000208010905" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms010207080004000208010905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Lars Eggert wrote: > >>I don't think we have the same definition of "the IPSec tunnel problem." >>Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates >>encapsulation and firewalling techniques that are (better) handled >>outside IPsec", see draft-touch-ipsec-vpn. >> >>Having or not having a default route won't matter, since you'll have >>more specific routes that match before the default route would be picked. > > > As you say, SA's are not interfaces. Try pinging over the link > from hosts on either side of the tunnel, e.g.: > > 10.0.1.15/8<--->10.0.1.1/8 10.0.2.1/8<---->10.0.2.11/8 > public IP #1<----------->public IP #2 > > Ping #1 <----------------------------> works > Ping #2 <------------------------------------------->broken > > Get rid of the default route, and ping #2 starts working. That looks like a routing issue on the tunnel endpoint that's independent from IPsec - what's in the routing table? Lars -- Lars Eggert USC Information Sciences Institute --------------ms010207080004000208010905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMzIzNTc1MlowIwYJKoZIhvcNAQkEMRYEFDgYQQxpYaU3 MB498BV/rmkl3HL8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAVuLszY8AX83MWCPMtmDaeEFApG1r8qb4/2TX59vqzWEx6 M5nxrWwPiDQIWkJmgmDQmErVP2YS2yn+4/2b4gkkhpWqlSOBn3O+COx6xdyFzeK2Egf6hRLO bKyrY4HLfeZSOPMEqzwn9b18NqviwwX7qlLYPqWm+mMXDI0ut87fhAAAAAAAAA== --------------ms010207080004000208010905-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 17: 0:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F18F37B400 for ; Tue, 13 Aug 2002 17:00:51 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB71443E3B for ; Tue, 13 Aug 2002 17:00:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0032.cvx40-bradley.dialup.earthlink.net ([216.244.42.32] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17elag-0005uY-00; Tue, 13 Aug 2002 17:00:46 -0700 Message-ID: <3D599D77.C1657E75@mindspring.com> Date: Tue, 13 Aug 2002 16:59:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hiten@uk.FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: SysV IPC related question References: <20020813233459.25838.qmail@web21102.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > OK. One more question; so, is there any particular reason why our cousin > NetBSD doesnt use this "overlay" structure? Also, the NetBSD SysV Msg > regression tool defines its own struct mymsg; and doesnt have one standard > in the header file. I don't know why NetBSD doesn't have this. Perhaps they are unconcerned with the portability of code using SYSV message queues, when it comes to internal structure packing. I would think directly casting it to a long in the kernel would be a bad thing on Alpha, with certain source code in user space. I expect that they define it for the regression test so that they can actually do regression on these cases. > Also, if possible, could you outline some situations where this would be > used? Help will be very appreicated. It's because if you don't ask for a specific meswsage type (e.g. it is important for you to get messages in the order they were sent), then you can't control which message will be returned in your message buffer passed to msgrcv(2). Example: ---------- struct mymsg { long mtype; char mtest[1]; }; #define MTYPE_A 75 struct msg_a { long mtype; int id; char name[ 8]; }; #define MTYPE_B 76 struct msg_b { long mtype; char msg[ 16]; struct stat data; }; typedef union { struct mymsg mymsg; struct msg_a a; struct mdg_b b; } msg_t; msg_t msg; /* p3 = 0 :== receive any message */ if ( msgrcv(msqid, &msg, sizeof(msg), 0, 0) == -1) { perror("msgsnd"); exit( 3); } switch( msg.mymsg.mtype) { case MTYPE_A: printf( "name=%s, id = %d\n", msg.a.name, msg.a.id); break; case MTYPE_B: printf( "Result '%s', size= %d\n", msg.b.msg, msg.b.data.st_size); break; default: printf "Unrecognized message type: %d\n", msg.mymsg.mtype); break; } ---------- -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 17: 9:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C35B937B400 for ; Tue, 13 Aug 2002 17:09:29 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68CEB43E42 for ; Tue, 13 Aug 2002 17:09:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0032.cvx40-bradley.dialup.earthlink.net ([216.244.42.32] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17elj1-00025Z-00; Tue, 13 Aug 2002 17:09:24 -0700 Message-ID: <3D599F7D.D64008AC@mindspring.com> Date: Tue, 13 Aug 2002 17:08:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert Cc: Les Biffle , hackers@freebsd.org Subject: Re: IP routing question References: <200208131813.g7DIDiH14643@ns3.safety.net> <3D599416.5CDE92D9@mindspring.com> <3D599679.5090507@isi.edu> <3D599992.7C954D42@mindspring.com> <3D599D00.8070807@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lars Eggert wrote: > Terry Lambert wrote: > > As you say, SA's are not interfaces. Try pinging over the link > > from hosts on either side of the tunnel, e.g.: > > > > 10.0.1.15/8<--->10.0.1.1/8 10.0.2.1/8<---->10.0.2.11/8 > > public IP #1<----------->public IP #2 > > > > Ping #1 <--------------------------> works > > Ping #2 <----------------------------------------->broken > > > > Get rid of the default route, and ping #2 starts working. > > That looks like a routing issue on the tunnel endpoint that's > independent from IPsec - what's in the routing table? Now? Not a default route, that's for sure... 8-) 8-) ;^). I traced the problem down to the cloning of routes, and given the opacity of the code, and the fact I had a workaround avaiable, didn't bother chasing it further. The response packets got *back* to 10.0.1.1, but 10.0.1.1 did not forward them on the local net to 10.0.1.15, but pushed them out the default interface instead. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 17:30:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E680B37B400 for ; Tue, 13 Aug 2002 17:30:12 -0700 (PDT) Received: from web11404.mail.yahoo.com (web11404.mail.yahoo.com [216.136.131.234]) by mx1.FreeBSD.org (Postfix) with SMTP id 794F143E65 for ; Tue, 13 Aug 2002 17:30:12 -0700 (PDT) (envelope-from raysonlogin@yahoo.com) Message-ID: <20020814003011.77699.qmail@web11404.mail.yahoo.com> Received: from [199.246.40.54] by web11404.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 17:30:11 PDT Date: Tue, 13 Aug 2002 17:30:11 -0700 (PDT) From: Rayson Ho Subject: Re: Port for Sun Grdiware 5.3 To: Alp ATICI , freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- Alp ATICI wrote: > Is there any port of Sun Gridware 5.3 for FreeBSD? I know that "Ron Chen" and several other people worked on the port. They have it working but not sure about whether the source was checked in or not. You can search for "freebsd" in the archive: http://gridengine.sunsource.net/servlets/SearchList > I found the source code is open and there're binaries for several > arch/OS's there but couldn't see any FreeBSD port. Also, I've heard they were looking for people to be the maintainer, anyone?? > > http://gridengine.sunsource.net > > Let me know if you have any information about that. > Thanks, > > Alp > Rayson __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 17:45:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B797237B400; Tue, 13 Aug 2002 17:45:45 -0700 (PDT) Received: from cpw.math.columbia.edu (cpw.math.columbia.edu [128.59.192.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147E443E42; Tue, 13 Aug 2002 17:45:45 -0700 (PDT) (envelope-from atici@math.columbia.edu) Received: from intel4.math.columbia.edu (root@intel4.math.columbia.edu [128.59.192.29]) by cpw.math.columbia.edu (8.12.5/8.12.5) with ESMTP id g7E0jhL1003040; Tue, 13 Aug 2002 20:45:43 -0400 Received: from localhost (atici@localhost) by intel4.math.columbia.edu (8.11.3/8.11.3) with ESMTP id g7E0jle26817; Tue, 13 Aug 2002 20:45:47 -0400 X-Authentication-Warning: intel4.math.columbia.edu: atici owned process doing -bs Date: Tue, 13 Aug 2002 20:45:47 -0400 (EDT) From: Alp ATICI To: Rayson Ho Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Port for Sun Gridware 5.3 In-Reply-To: <20020814003011.77699.qmail@web11404.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I made a search at the site you mentioned before but got nothing relevant. Does anyone have the link to the port? Do you know how it performs in general? Efficient? not? Thanks, Alp On Tue, 13 Aug 2002, Rayson Ho wrote: > I know that "Ron Chen" and several other people worked on the port. > They have it working but not sure about whether the source was checked > in or not. > > You can search for "freebsd" in the archive: > http://gridengine.sunsource.net/servlets/SearchList > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 18:13: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D749237B422; Tue, 13 Aug 2002 18:13:04 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BE743E4A; Tue, 13 Aug 2002 18:13:03 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([138.89.161.212]) by pop015.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20020814011301.TCKE2139.pop015.verizon.net@bellatlantic.net>; Tue, 13 Aug 2002 20:13:01 -0500 Message-ID: <3D59AE9B.3C27FA8C@bellatlantic.net> Date: Tue, 13 Aug 2002 21:12:59 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: "Semen A. Ustimenko" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI device emulation using SCSI host controller References: <20020813232629.L568-100000@main.the.net> <20020813132935.A51629@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > Hi! > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > using usual SCSI host controller and specific software, or I will > > definitely need specific hardware?" > > You'll need either the right Adaptec or QLogic controller, but yes, it can > be done with FreeBSD. Or Symbios (now LSI Logic). -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 19:30:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF8C37B401; Tue, 13 Aug 2002 19:30:42 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C62243E3B; Tue, 13 Aug 2002 19:30:41 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g7E2UcKD053708; Tue, 13 Aug 2002 20:30:38 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g7E2Uc5j053707; Tue, 13 Aug 2002 20:30:38 -0600 (MDT) (envelope-from ken) Date: Tue, 13 Aug 2002 20:30:38 -0600 From: "Kenneth D. Merry" To: Sergey Babkin Cc: "Semen A. Ustimenko" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI device emulation using SCSI host controller Message-ID: <20020813203037.A53640@panzer.kdm.org> References: <20020813232629.L568-100000@main.the.net> <20020813132935.A51629@panzer.kdm.org> <3D59AE9B.3C27FA8C@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D59AE9B.3C27FA8C@bellatlantic.net>; from babkin@bellatlantic.net on Tue, Aug 13, 2002 at 09:12:59PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 13, 2002 at 21:12:59 -0400, Sergey Babkin wrote: > "Kenneth D. Merry" wrote: > > > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > > Hi! > > > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > > using usual SCSI host controller and specific software, or I will > > > definitely need specific hardware?" > > > > You'll need either the right Adaptec or QLogic controller, but yes, it can > > be done with FreeBSD. > > Or Symbios (now LSI Logic). Has anyone done any target mode code for their boards? I know they're probably capable of it, but AFAIK, the sym(4) driver doesn't support target mode and I didn't see anything in the mpt(4) commit that indicated that it supports target mode either. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 19:39:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7E9E37B400 for ; Tue, 13 Aug 2002 19:39:57 -0700 (PDT) Received: from priv-edtnes27.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1834143E75 for ; Tue, 13 Aug 2002 19:39:57 -0700 (PDT) (envelope-from sh@planetquake.com) Received: from dbs ([216.232.25.240]) by priv-edtnes27.telusplanet.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020814023956.DJUK589.priv-edtnes27.telusplanet.net@dbs> for ; Tue, 13 Aug 2002 20:39:56 -0600 Message-ID: <000501c2433b$e6527410$f019e8d8@slugabed.org> From: "Sean Hamilton" To: Subject: IP monitoring Date: Tue, 13 Aug 2002 19:40:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings, I'm interested in developing a fairly proprietary IP monitoring solution (I want to look for specific trends in specific packets.) Will there be considerable gains from writing some sort of kernel module, vs. a userspace solution? I've never hacked the kernel or written any sort of kernel module before, but I'm eager to do so. What is the most low level API for this sort of thing, to avoid API overhead, if I should do it in user space? thanks, sh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 19:45:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC6D137B400 for ; Tue, 13 Aug 2002 19:45:37 -0700 (PDT) Received: from priv-edtnes27.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id C024943E6A for ; Tue, 13 Aug 2002 19:45:36 -0700 (PDT) (envelope-from sh@planetquake.com) Received: from dbs ([216.232.25.240]) by priv-edtnes27.telusplanet.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020814024536.DLFP589.priv-edtnes27.telusplanet.net@dbs> for ; Tue, 13 Aug 2002 20:45:36 -0600 Message-ID: <000a01c2433c$b0e96620$f019e8d8@slugabed.org> From: "Sean Hamilton" To: References: <000501c2433b$e6527410$f019e8d8@slugabed.org> Subject: Re: IP monitoring Date: Tue, 13 Aug 2002 19:45:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Also, forgot to mention, I will need to look inside TCP streams, and know which user owns them, and which packets pertain to which TCP stream, which is why I was thinking a module would be more suitable. If I did this in user space, I'd have to reconstruct the streams myself (but as I understand, that isn't amazingly difficult.) sh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 20:20:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1D8937B400 for ; Tue, 13 Aug 2002 20:20:19 -0700 (PDT) Received: from web11404.mail.yahoo.com (web11404.mail.yahoo.com [216.136.131.234]) by mx1.FreeBSD.org (Postfix) with SMTP id 667DE43E77 for ; Tue, 13 Aug 2002 20:20:19 -0700 (PDT) (envelope-from raysonlogin@yahoo.com) Message-ID: <20020814031338.97069.qmail@web11404.mail.yahoo.com> Received: from [199.246.40.54] by web11404.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 20:13:38 PDT Date: Tue, 13 Aug 2002 20:13:38 -0700 (PDT) From: Rayson Ho Subject: Re: Port for Sun Gridware 5.3 To: Alp ATICI Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Ron Chen" posted the patch: http://gridengine.sunsource.net/servlets/ReadMsg?msgId=4171&listName=dev But the best place to ask is the SGE mailing list. Rayson --- Alp ATICI wrote: > I made a search at the site you mentioned before but got > nothing relevant. > > Does anyone have the link to the port? > Do you know how it performs in general? Efficient? not? > > Thanks, > Alp > > On Tue, 13 Aug 2002, Rayson Ho wrote: > > I know that "Ron Chen" and several other people worked on the port. > > They have it working but not sure about whether the source was > checked > > in or not. > > > > You can search for "freebsd" in the archive: > > http://gridengine.sunsource.net/servlets/SearchList > > > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 20:24: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DC5B37B400 for ; Tue, 13 Aug 2002 20:24:06 -0700 (PDT) Received: from april.chuckr.org (april.chuckr.org [66.92.147.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED2F43E3B for ; Tue, 13 Aug 2002 20:24:05 -0700 (PDT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.12.5/8.12.5) with ESMTP id g7E3NYhH083200; Tue, 13 Aug 2002 23:23:35 -0400 (EDT) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost) by april.chuckr.org (8.12.5/8.12.5/Submit) with ESMTP id g7E3NXRu083197; Tue, 13 Aug 2002 23:23:34 -0400 (EDT) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Tue, 13 Aug 2002 23:23:32 -0400 (EDT) From: Chuck Robey To: Sean Hamilton Cc: Subject: Re: IP monitoring In-Reply-To: <000a01c2433c$b0e96620$f019e8d8@slugabed.org> Message-ID: <20020813231956.J497-100000@april.chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 13 Aug 2002, Sean Hamilton wrote: > Also, forgot to mention, I will need to look inside TCP streams, and know > which user owns them, and which packets pertain to which TCP stream, which > is why I was thinking a module would be more suitable. If I did this in user > space, I'd have to reconstruct the streams myself (but as I understand, that > isn't amazingly difficult.) If you do it in user space it's a lot easier to debug. It can be done, of course, in both places, but general IO is easy in userspace too (for user interaction, if you need it). You can also make such a thing portable in user space, which is hard to do in the kernel. The downside is, there's copies of the data to consider (more work to be done means less time to do it in), so you might have too much traffic under some conditions, depending on what you're doing. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 13 22: 0:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E063737B400 for ; Tue, 13 Aug 2002 22:00:36 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9416F43E6E for ; Tue, 13 Aug 2002 22:00:36 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 36644 invoked by uid 1000); 14 Aug 2002 05:00:38 -0000 Date: Tue, 13 Aug 2002 22:00:38 -0700 (PDT) From: Nate Lawson To: Sean Hamilton Cc: hackers@freebsd.org Subject: Re: IP monitoring In-Reply-To: <000a01c2433c$b0e96620$f019e8d8@slugabed.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 13 Aug 2002, Sean Hamilton wrote: > Also, forgot to mention, I will need to look inside TCP streams, and know > which user owns them, and which packets pertain to which TCP stream, which > is why I was thinking a module would be more suitable. If I did this in user > space, I'd have to reconstruct the streams myself (but as I understand, that > isn't amazingly difficult.) > > sh pcap(3) does fast usermode packet capture via BPF ports/net/libnids does TCP stream reassembly Running things in the kernel does not automatically make them fast unless your CPU usage is maxed by boundary crossings. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 0:30:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D3A637B400 for ; Wed, 14 Aug 2002 00:30:04 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2EEC43E4A for ; Wed, 14 Aug 2002 00:30:03 -0700 (PDT) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g7E7TuWr016702; Wed, 14 Aug 2002 03:29:56 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host hiten@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g7E7TtYI016701; Wed, 14 Aug 2002 03:29:55 -0400 (EDT) (envelope-from hiten) Date: Wed, 14 Aug 2002 03:29:55 -0400 From: Hiten Pandya To: freebsd-hackers@FreeBSD.org Cc: hiten@uk.FreeBSD.org Subject: Fixing issues with the MSDOSFS code. [w/ PATCH(es)] Message-ID: <20020814032955.A16015@angelica.unixdaemons.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello all. OK. I am going to get straight to the point. I was going through the PR database yesterday, and I saw that there are three PRs submitted on one same MSDOSFS issue. As we know, that there is no MSDOSFS maintainer; I have taken the courage to gather the patches, which, have know to work, and are still applicable to date. Below is my research: :-) I am submitting this, in the hopes, that a committer will pick them up, commit them, and put the PRs it affects into 'feedback' state. Thanking in advance. Regards. P.S. Findings attached with this mail. -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@xMach.org PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="msdos_critical.patch" The following patch fixes a number of issues within the FreeBSD MSDOS File System code. Delta one: ---------- Author: Semen Ustimenko The problem as submitted by the author (kern/24393) is: There are sometimes a FAT filesystems not handled correctly by msdosfs driver, but handled by mtools and other OSes. The problem is that msdosfs assume . entry in directory have cluster number set to real directory cluster number. But sometimes cluster number for . entry is set to 0, and msdosfs behaves wrong with such filesystems. Index: msdosfs_denode.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v retrieving revision 1.62 diff -u -r1.62 msdosfs_denode.c --- msdosfs_denode.c 2002/08/04 10:29:26 1.62 +++ msdosfs_denode.c 2002/08/14 00:09:19 @@ -356,6 +356,17 @@ */ u_long size; + /* + * XXX Sometimes, these arrives that . entry have cluster + * number 0, when it shouldn't. Use real cluster number + * instead of what is written in directory entry. + */ + if ((diroffset == 0) && (ldep->de_StartCluster != dirclust)) { + printf("deget(): . entry at clust %ld != %ld\n", + dirclust, ldep->de_StartCluster); + ldep->de_StartCluster = dirclust; + } + nvp->v_type = VDIR; if (ldep->de_StartCluster != MSDOSFSROOT) { error = pcbmap(ldep, 0xffff, 0, &size, 0); Delta two: ---------- Author: Jiangyi Liu Check against: NetBSD MSDOS-FS (they have similar fix) Problem: This delta fixes a bunch of problems, from fsck_msdosfs related problems, to >2GB hard drives; and last but not least, letting an msdosfs extended partition (massive ones) live peacefully. The following PRs are closable by applying this patch: - i386/28536 - misc/30168 - kern/32256 (hopefully) - kern/29121 (hopefully) Index: msdosfs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vfsops.c,v retrieving revision 1.91 diff -u -r1.91 msdosfs_vfsops.c --- msdosfs_vfsops.c 2002/08/13 10:05:46 1.91 +++ msdosfs_vfsops.c 2002/08/14 00:31:16 @@ -543,8 +543,14 @@ } /* - * Check and validate (or perhaps invalidate?) the fsinfo structure? XXX + * Check and validate (or perhaps invalidate?) the fsinfo structure? */ + if (pmp->pm_fsinfo && pmp->pm_nxtfree > pmp->pm_maxcluster) { + printf("Next free cluster in FSInfo (%u) exceeds maxcluster (%u)\n", + pmp->pm_nxtfree, pmp->pm_maxcluster); + error = EINVAL; + goto error_exit; + } /* * Allocate memory for the bitmap of allocated clusters, and then --IS0zKkzwUGydFO0o-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 0:33:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6111A37B400 for ; Wed, 14 Aug 2002 00:33:53 -0700 (PDT) Received: from web21109.mail.yahoo.com (web21109.mail.yahoo.com [216.136.227.111]) by mx1.FreeBSD.org (Postfix) with SMTP id 16E9043E6A for ; Wed, 14 Aug 2002 00:33:53 -0700 (PDT) (envelope-from hitmaster2k@yahoo.com) Message-ID: <20020814073352.47515.qmail@web21109.mail.yahoo.com> Received: from [62.254.0.5] by web21109.mail.yahoo.com via HTTP; Wed, 14 Aug 2002 00:33:52 PDT Date: Wed, 14 Aug 2002 00:33:52 -0700 (PDT) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: Re: SysV IPC related question To: Terry Lambert Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <3D599D77.C1657E75@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- Terry Lambert wrote: > I don't know why NetBSD doesn't have this. Perhaps they are > unconcerned with the portability of code using SYSV message > queues, when it comes to internal structure packing. > > I would think directly casting it to a long in the kernel would > be a bad thing on Alpha, with certain source code in user space. > > I expect that they define it for the regression test so that > they can actually do regression on these cases. I was going on about: basesrc/regress/sys/kern/sysvmsg > > Also, if possible, could you outline some situations where this would be > > used? Help will be very appreicated. > > It's because if you don't ask for a specific meswsage type (e.g. > it is important for you to get messages in the order they were > sent), then you can't control which message will be returned in > your message buffer passed to msgrcv(2). > [ ... ] Thank you for the information. Very appreciated, as always. 8-) -- Hiten __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 0:53:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F38537B400; Wed, 14 Aug 2002 00:53:03 -0700 (PDT) Received: from excite.com (213-96-43-109.uc.nombres.ttd.es [213.96.43.109]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A69143E42; Wed, 14 Aug 2002 00:52:55 -0700 (PDT) (envelope-from Center_for_Age2722y86@excite.com) Received: from 131.45.238.224 ([131.45.238.224]) by smtp4.cyberecschange.com with SMTP; Tue, 13 Aug 0102 22:51:46 +0900 Reply-To: "Office" Message-ID: <001c65d02c2e$8355c7b1$6cc86ac0@lxsonu> From: "Office" To: , , , , , , Subject: Three types of HGH products Date: Wed, 14 Aug 0102 17:49:23 -1000 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A8_20B74C6D.B8018A10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_000_00A8_20B74C6D.B8018A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 S25vdyB0aGUgZGlmZmVyZW50IEhHSCBwcm9kdWN0cw0KDQo8aHRtbD4NCg0K PGhlYWQ+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQoNCjxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTWljcm9zb2Z0IEZyb250 UGFnZSA0LjAiPg0KDQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9IkZy b250UGFnZS5FZGl0b3IuRG9jdW1lbnQiPg0KDQo8dGl0bGU+VGhlcmUgYXJl IHRocmVlIGRpZmZlcmVudCB0eXBlcyBvZiBIR0ggcHJvZHVjdHM8L3RpdGxl Pg0KDQo8L2hlYWQ+DQoNCjxib2R5IGJhY2tncm91bmQ9ImNsb3Vkcy5qcGci Pg0KDQo8cD48Zm9udCBzaXplPSI0Ij48Zm9udCBjb2xvcj0iIzgwMDAwMCI+ PGI+VGhlcmUgYXJlIHRocmVlIGRpZmZlcmVudCB0eXBlcyBvZg0KDQpIR0gg cHJvZHVjdHMuPC9iPjwvZm9udD48YnI+DQoNClRoZSBjb25mdXNpb24gaXMg dGhhdCBhbGwgdGhyZWUgYXJlPGJyPg0KDQphZHZlcnRpc2VkIGFzIGlmIHRo ZXkgd2VyZSB0aGUgc2FtZS48L2ZvbnQ+PGJyPg0KDQombmJzcDs8YnI+DQoN CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 dT5UaGUgdGhyZWUgdHlwZXMgYXJlOjwvdT48YnI+DQoNCiZuYnNwOzxicj4N Cg0KPGI+MSk8L2I+IC0tLSA8Zm9udCBjb2xvcj0iIzAwMDBGRiI+PGI+SG9t ZW9wYXRoaWMgSEdIPC9iPjwvZm9udD48YnI+DQoNCjxiPjIpPC9iPiAtLS0g PGZvbnQgY29sb3I9IiMwMDAwRkYiPjxiPlByZS1jdXJzb3IgSEdIPC9iPjwv Zm9udD48YnI+DQoNCjxiPjMpPC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAw RkYiPjxiPlJlYWwgb3Igc3ludGhldGljIEhHSDwvYj48L2ZvbnQ+DQoNCihk ZWxpdmVyZWQgYnkgaW5qZWN0aW9uPGJyPg0KDQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3IsIGJ5IGFuIG9yYWwgc3By YXkgbWV0aG9kKS48YnI+DQoNCiZuYnNwOzxicj4NCg0KRG8geW91IGtub3cg ZGlmZmVyZW5jZXM/PGJyPg0KDQombmJzcDs8YnI+DQoNCkNhbGwgdXMgYW5k IHdlJ2xsIGV4cGxhaW4gdGhlbSB0byB5b3UuPGJyPg0KDQombmJzcDs8YnI+ DQoNCk91ciB0b2xsIGZyZWUgbnVtYmVyIGlzIDxmb250IGNvbG9yPSIjMDAw MDgwIj48Yj4xLTg4OC02MjEtNzMwMDwvYj48L2ZvbnQ+PGJyPg0KDQpBbiBI R0ggc3RhZmYgbWVtYmVyIGlzIGF2YWlsYWJsZTxicj4NCg0KOSB0byA1IFBh Y2lmaWMgVGltZS48YnI+DQoNCklmIGFmdGVyIGhvdXJzLCBwbGVhc2UgbGVh dmUgeW91IG5hbWU8YnI+DQoNCmFuZCBkYXkgYW5kIGV2ZW5pbmcgcGhvbmUg bnVtYmVycy48YnI+DQoNCldlIHdpbGwgY2FsbCB5b3UgYmFjayBpbiBhIG5v IHByZXNzdXJlLDxicj4NCg0KZWR1Y2F0aW9uYWwgbWFubmVyLjxicj4NCg0K SWYgeW91IGFyZSBvdmVyc2VhcyBjYWxsIHlvdXIgbG9uZyBkaXN0YW5jZTxi cj4NCg0Kb3BlcmF0b3IgYW5kIGFzayB0byBiZSBjb25uZWN0ZWQgdG8gb3Vy PGJyPg0KDQpwaG9uZSBudW1iZXIuJm5ic3A7IFdlIHdpbGwgY2FsbCB5b3Ug YmFjayBzbzxicj4NCg0Kd2UgY2FuIHBheSBmb3IgdGhlIGxvbmcgZGlzdGFu Y2UgY2hhcmdlcy48YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9 IiNGRjAwMDAiPkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIEhHSCByZWFkIG9u Li4uLi4uLi4uLi4uPC9mb250Pjxicj4NCg0KJm5ic3A7PGJyPg0KDQpIQVZF IFlPVSBIRUFSRCBPRjxicj4NCg0KSFVNQU4gR1JPV1RIIEhPUk1PTkUgKEhH SCk/Pz88YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJlbGVhc2VkIGJ5IHlvdXIgb3duIHBpdHVpdGFyeSBnbGFuZCwg SEdIIHN0YXJ0cw0KDQpkZWNsaW5pbmc8YnI+DQoNCmluIHlvdXIgMjBzLCBl dmVuIG1vcmUgaW4geW91ciAzMHMgYW5kIDQwcywgZXZlbnR1YWxseSByZXN1 bHRpbmc8YnI+DQoNCmluIHRoZSBzaHJpbmthZ2Ugb2YgbWFqb3Igb3JnYW5z IC0tIHBsdXMsIGFsbDxicj4NCg0Kb3RoZXIgc3ltcHRvbXMgcmVsYXRlZCB0 byBvbGQgYWdlLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoN CklOIFRIT1VTQU5EUyBPRiBDTElOSUNBTCBTVFVESUVTLDxicj4NCg0KSEdI IEhBUyBCRUVOIFNIT1dOIFRPIEFDQ09NUExJU0ggVEhFIEZPTExPV0lORzo8 YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZWR1Y2UgQm9keSBGYXQgYW5kIEJ1 aWxkIExlYW4gTXVzY2xlPGJyPg0KDQombmJzcDsmbmJzcDsgV0lUSE9VVCBF WEVSQ0lTRSE8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBFbmhhbmNlIFNleHVh bCBQZXJmb3JtYW5jZTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIFJlbW92ZSBX cmlua2xlcyBhbmQgQ2VsbHVsaXRlPGJyPg0KDQombmJzcDs8YnI+DQoNCiog TG93ZXIgQmxvb2QgUHJlc3N1cmUgYW5kIEltcHJvdmUgQ2hvbGVzdGVyb2wg UHJvZmlsZTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIEltcHJvdmUgU2xlZXAs IFZpc2lvbiBhbmQgTWVtb3J5PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVz dG9yZSBIYWlyIENvbG9yIGFuZCBHcm93dGg8YnI+DQoNCiZuYnNwOzxicj4N Cg0KKiBTdHJlbmd0aGVuIHRoZSBJbW11bmUgU3lzdGVtPGJyPg0KDQombmJz cDs8YnI+DQoNCiogSW5jcmVhc2UgRW5lcmd5IGFuZCBDYXJkaWFjIE91dHB1 dDxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIFR1cm4gYmFjayB5b3VyIGJvZHkn cyBCaW9sb2dpY2FsIFRpbWUgQ2xvY2sgMTAgLSAyMCB5ZWFyczxicj4NCg0K Jm5ic3A7PGJyPg0KDQoqIExpdmUgTG9uZ2VyIEFORCBTdHJvbmdlcjxicj4N Cg0KJm5ic3A7PGJyPg0KDQpBbGwgbmF0dXJhbCBhbmQgb3JnYW5pYyBwbGFu dCBiYXNlZDxicj4NCg0KJm5ic3A7PGJyPg0KDQo8Zm9udCBjb2xvcj0iIzAw MDBGRiI+PGI+RkVFTCAxMCBZRUFSUyBZT1VOR0VSIFdJVEggT1JBTCBTUFJB WSBIR0guPGJyPg0KDQpHVUFSQU5URUVEPC9iPjwvZm9udD48YnI+DQoNCiZu YnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIGFyZSB0aGUgbWFu dWZhY3R1cmVyIGFuZCB3ZSBzZWxsIGRpcmVjdGx5IHRvIERvY3RvcnMsPGJy Pg0KDQpDaGlyb3ByYWN0b3JzLCBhbmQgY29uc3VtZXJzIHdvcmxkIHdpZGUg dGhlIGhpZ2hlc3QgZ3JhZGU8YnI+DQoNCiZuYnNwO0hHSCBPcmFsIFNwcmF5 IGF2YWlsYWJsZS4mbmJzcDs8YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdpdGggaW50ZXJuZXQgbWFya2V0aW5nLCB3 ZSBhcmUgYWJsZSB0byBzYXZlDQoNCmFkdmVydGlzaW5nPGJyPg0KDQpjb3N0 IGFuZCBwYXNzIHRob3NlIHNhdmluZ3MgYWxvbmcgdG8geW91Ljxicj4NCg0K QnV0IHlvdSBtdXN0IGFjdCBub3cuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+ DQoNClRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBjYWxsJm5ic3A7IHVz IG5vdy48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRPTEwgRlJFRSA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgt NjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQpXZSBt dXN0IHNwZWFrIHRvIHlvdSBpbiBwZXJzb24gdG8gcXVhbGlmeSB5b3VyIHVz YWdlLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWxsIG9mIHlvdXIgcXVlc3Rpb25zIHdpbGwgYmUgYWRkcmVzc2Vk IGFuZCBhbnN3ZXJlZCBpbg0KDQphIGZyaWVuZGx5LDxicj4NCg0Kbm8gcHJl c3N1cmUgbWFubmVyLiZuYnNwOyBPdXIgbWFpbiBwdXJwb3NlIGlzIHRvIHBy b3ZpZGUgeW91IHdpdGg8YnI+DQoNCiZuYnNwO2luZm9ybWF0aW9uIHNvIHlv dSBjYW4gbWFrZSBhbiBlZHVjYXRlZCBkZWNpc2lvbi48YnI+DQoNCiZuYnNw Ozxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBtb3JlIGlu Zm9ybWF0aW9uIGNhbGw8YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02 MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNw O0lmIHlvdSBhcmUgb24gbGluZSB3cml0ZSBkb3duIG91cjxicj4NCg0KcGhv bmUgbnVtYmVyIGFuZCBjYWxsIHVzIHdoZW4geW91IGNhbi48YnI+DQoNCiZu YnNwOzxicj4NCg0KU29vbiwgeW91IGFuZCB5b3VyIGxvdmVkIG9uZXMgd2ls bCBiZSB2ZXJ5IGdsYWQgeW91IGRpZC48YnI+DQoNCiZuYnNwOzxicj4NCg0K UmVhZCB3aGF0IHBlb3BsZSBhcmUgc2F5aW5nOjxicj4NCg0KJm5ic3A7PGJy Pg0KDQomcXVvdDtUaGUgZWZmZWN0cyBvZiA2IG1vbnRocyBvZiBHSCBvbjxi cj4NCg0KbGVhbiBib2R5IG1hc3MgYW5kIGZhdCB3ZXJlIGVxdWl2YWxlbnQ8 YnI+DQoNCmluIG1hZ25pdHVkZSB0byB0aGUgY2hhbmdlcyBpbmN1cnJlZDxi cj4NCg0KZHVyaW5nIDEwLTIwIHllYXJzIG9mIGFnaW5nLiZxdW90Ozxicj4N Cg0KRHIuIERhbmllbCBSdWRtYW4sIE1ELDxicj4NCg0KTmV3IEVuZ2xhbmQg Sm91cm5hbCBvZiBNZWRpY2luZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJnF1 b3Q7V2l0aGluIGZvdXIgbW9udGhzLCBteSBib2R5IGZhdCBkZWNyZWFzZWQ8 YnI+DQoNCiZuYnNwO2Zvcm0gMzAlIGRvd24gdG8gMjElISBJIG5vdGljZWQg bXkgc2tpbjxicj4NCg0KJm5ic3A7aXMgbW9yZSBzdXBwbGUgYW5kIG15IG92 ZXJhbGwgbWVudGFsPGJyPg0KDQombmJzcDtvdXRsb29rIGltcHJvdmVkIHNp Z25pZmljYW50bHkuJnF1b3Q7PGJyPg0KDQombmJzcDtELlcuLCBOZXcgSmVy c2V5PGJyPg0KDQombmJzcDs8YnI+DQoNCiZxdW90O1dlIGhhdmUgYmVlbiBv biB0aGUgc3ByYXkgZm9yIGp1c3QgMyB3ZWVrczxicj4NCg0Kbm93LCBhbmQg YmVzaWRlcyB0aGUgdHJlbWVuZG91cyBlbmVyZ3kgd2U8YnI+DQoNCmJvdGgg ZmVlbCwgbXkgaHVzYmFuZHMgYWxsZXJnaWVzIGFuZCBzcGVsbHM8YnI+DQoN Cm9mIGRlcHJlc3Npb24gaGF2ZSBsaWZ0ZWQuIEkgYW0gaGVhbGluZzxicj4N Cg0KZXh0cmVtZWx5IGZhc3QgYWZ0ZXIgYW4gYWNjaWRlbnQgYW5kIGhhdmU8 YnI+DQoNCmxvc3QgNyBsYnMuIHdpdGhvdXQgdHJ5aW5nISZxdW90Ozxicj4N Cg0KQy5CLiwgRmxhZ3N0YWZmLiBBWjxicj4NCg0KJm5ic3A7PGJyPg0KDQpU aGFua3MgZm9yIHJlYWRpbmcgb3VyIGxldHRlciw8YnI+DQoNClRoZSBIR0gg U3RhZmY8YnI+DQoNClVTQSBEaXZpc2lvbjxicj4NCg0KJm5ic3A7PGJyPg0K DQpQUzombmJzcDsgVGhlIEhHSCBTdGFmZiBndWFyYW50ZWVzIHRoZTxicj4N Cg0KaGlnaGVzdCBxdWFsaXR5IGFuZCBsb3dlc3QgcHJpY2UuPGJyPg0KDQom bmJzcDs8YnI+DQoNCiZuYnNwO1dlIG1hbnVmYWN0dXJlIGFuZCBzaGlwIGRp cmVjdGx5IHRvIHlvdXIgZG9vci48YnI+DQoNCiZuYnNwOzxicj4NCg0KQ2Fs bCB1cyBub3cgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03 MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0KPT09PT09PSZu YnNwOyZuYnNwOyBFbmQgb2YgbWVzc2FnZSA9PT09PT09PSZuYnNwOzxicj4N Cg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBz dGF0ZW1lbnQgaXMgcHJvdmlkZWQgdG8gYmU8YnI+DQoNCmluIGNvbXBsaWFu Y2Ugd2l0aCBjb21tZXJjaWFsIGVtYWlsIGxhd3MuPGJyPg0KDQombmJzcDs8 YnI+DQoNCiZuYnNwOyZuYnNwOyBJZiB5b3UgZG8gbm90IHdpc2ggdG8gcmVj ZWl2ZSBmdXJ0aGVyPGJyPg0KDQptYWlsaW5ncywgcGxlYXNlIGNsaWNrIHJl cGx5IHRvOiBwbHNyZW1oZ2gzNEBidGFtYWlsLm5ldC5jbiAgYW5kIHR5cGUg cmVtb3ZlIGluIHRoZSBzdWJqZWN0IGJveC48YnI+DQoNClRoZW4gY2xpY2sg c2VuZC48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoaXMg bWVzc2FnZSBpcyBpbiBmdWxsIGNvbXBsaWFuY2Ugd2l0aDxicj4NCg0KVS5T LiBGZWRlcmFsIHJlcXVpcmVtZW50cyBmb3IgY29tbWVyY2lhbDxicj4NCg0K ZW1haWwgdW5kZXIgYmlsbCBTLjE2MTggVGl0bGUgbGxsLCBTZWN0aW9uIDMw MSw8YnI+DQoNClBhcmFncmFwaCAoYSkoMikoQykgcGFzc2VkIGJ5IHRoZSAx MDV0aCBVLlMuPGJyPg0KDQpDb25ncmVzcyBhbmQgaXMgbm90IGNvbnNpZGVy ZWQgU1BBTTxicj4NCg0Kc2luY2UgaXQgaW5jbHVkZXMgYSByZW1vdmUgbWVj aGFuaXNtLio8YnI+DQoNClRoaXMgbWVzc2FnZSBpcyBub3QgaW50ZW5kZWQg Zm9yIHJlc2lkZW50cyBpbiB0aGU8YnI+DQoNCnN0YXRlcyBvZiBDQSwgTkMs IE5WLCBSSSwgVE4sIFZBICZhbXA7IFdBLjxicj4NCg0KU2NyZWVuaW5nIG9m IGFkZHJlc3NlcyBoYXMgYmVlbiBkb25lIHRvIHRoZSBiZXN0PGJyPg0KDQpv ZiBvdXIgdGVjaG5pY2FsIGFiaWxpdHkuPGJyPg0KDQombmJzcDs8YnI+DQoN CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYWxsIHVzDQoNCm5vdyA8 Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgtNjIxLTczMDA8L2ZvbnQ+ PC9iPiBmb3IgeW91cjxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGZyZWUNCg0KSEdIIGNvbnN1bHRhdGlvbi48L3A+DQoNCjxwPjxicj4N Cg0KVGhhbmsgeW91PC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KDQot LQ0KDQoyODkyT1NCSTgtMTAwRGhURTExNTJGa2NRMC0zMTJUSWVWODc2M0Rs Mzc= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 10: 3: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A9437B400; Wed, 14 Aug 2002 10:02:46 -0700 (PDT) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4811743E65; Wed, 14 Aug 2002 10:02:46 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 521; Wed, 14 Aug 2002 10:02:44 -0700 Message-ID: <3D5A8D68.AE7B43A5@expertcity.com> Date: Wed, 14 Aug 2002 10:03:36 -0700 From: Steve Francis X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: pmtu-d broken Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I find this hard to believe, but it seem PMTU-D is broken up to and including 4.6.1-RELEASE-p10 (the latest I've tried. Also tried 4.4) The behaviour of FreeBSD is such that when it sends a too large packet, and receives a fragmentation required-DF bit set ICMP, it does not honor it for the packet that caused the ICMP. It does correctly put the new MTU in its cloned route table, and does correctly send future packets in segment of size < the mtu, but it keeps retransmitting the packet that caused the ICMP in the original, too big size, so it never makes it, and just keeps generating more ICMPs. tcpdump examples: First, note that there is no specific entry for 10.4.0.80 dell350-12# netstat -anlr | grep 10.4 10.4.1.55 63.251.224.129 UGHW 1 990 1500 fxp0 10.4.1.58 63.251.224.129 UGHW 7 478339 1420 fxp0 10.4.1.233 63.251.224.129 UGHW3 0 2735 1420 fxp0 dell350-12# From 10.4.0.80, which is on the other side of a VPN tunnel with MTU of 1420 bytes, I do wget: Note that despite the ICMP messages telling it fragmentation is required, the freeBSD box keeps sending 1500 byte packets with DF set. dell350-12# tcpdump -vvi fxp0 host wonko.corp or host 10.16.5.8 tcpdump: listening on fxp0 09:40:25.938609 10.4.0.80.2793 > dell350-12.snv.http: S [tcp sum ok] 3671603378: 3671603378(0) win 16384 ( DF) (ttl 61, id 35804, len 60) 09:40:25.938665 dell350-12.snv.http > 10.4.0.80.2793: S [tcp sum ok] 3749220980: 3749220980(0) ack 3671603379 win 17376 (DF) (ttl 64, id 43056, len 60) 09:40:25.960106 10.4.0.80.2793 > dell350-12.snv.http: . [tcp sum ok] 1:1(0) ack 1 win 17376 (DF) (ttl 61, id 35806, len 52) 09:40:25.961626 10.4.0.80.2793 > dell350-12.snv.http: P 1:147(146) ack 1 win 173 76 (DF) (ttl 61, id 35823, len 198) 09:40:25.961647 dell350-12.snv.http > 10.4.0.80.2793: . [tcp sum ok] 1:1(0) ack 147 win 17230 (DF) (ttl 64, id 43078, l en 52) 09:40:25.962318 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 43079, len 1500 ) 09:40:25.962337 dell350-12.snv.http > 10.4.0.80.2793: . 1449:2897(1448) ack 147 win 17376 (DF) (ttl 64, id 43080, len 1 500) 09:40:25.962352 dell350-12.snv.http > 10.4.0.80.2793: . 2897:4345(1448) ack 147 win 17376 (DF) (ttl 64, id 43081, len 1 500) 09:40:25.963573 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43079, len 1500) (ttl 254, id 16874, len 56) 09:40:25.963696 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43080, len 1500) (ttl 254, id 16875, len 56) 09:40:25.963826 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43081, len 1500) (ttl 254, id 16876, len 56) 09:40:26.953112 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 43456, len 1500 ) 09:40:26.954116 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43456, len 1500) (ttl 254, id 17435, len 56) 09:40:28.953114 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 44025, len 1500 ) 09:40:28.954114 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 44025, len 1500) (ttl 254, id 18997, len 56) 09:40:32.953061 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 45089, len 1500 ) 09:40:32.954454 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 45089, len 1500) (ttl 254, id 22545, len 56) ^C However, we do see that it correcltly updated the mtu: dell350-12# netstat -anlr | grep 10.4 10.4.0.80 63.251.224.129 UGHW 1 2736 1420 fxp0 10.4.1.55 63.251.224.129 UGHW 1 990 1500 fxp0 10.4.1.58 63.251.224.129 UGHW 7 478423 1420 fxp0 dell350-12# And a repeated wget works fine: dell350-12# tcpdump -vvi fxp0 host wonko.corp or host 10.16.5.8 tcpdump: listening on fxp0 09:40:59.134496 10.4.0.80.1979 > dell350-12.snv.http: S [tcp sum ok] 926911706:9 26911706(0) win 16384 (DF ) (ttl 61, id 38108, len 60) 09:40:59.134532 dell350-12.snv.http > 10.4.0.80.1979: S [tcp sum ok] 422570166:4 22570166(0) ack 926911707 win 16416 (DF) (ttl 64, id 53036, len 60) 09:40:59.156451 10.4.0.80.1979 > dell350-12.snv.http: . [tcp sum ok] 1:1(0) ack 1 win 17376 (DF) (ttl 61, id 38170, len 52) 09:40:59.156820 10.4.0.80.1979 > dell350-12.snv.http: P 1:147(146) ack 1 win 173 76 (DF) (ttl 61, id 38171, len 198) 09:40:59.156842 dell350-12.snv.http > 10.4.0.80.1979: . [tcp sum ok] 1:1(0) ack 147 win 16270 (DF) (ttl 64, id 53037, l en 52) 09:40:59.157780 dell350-12.snv.http > 10.4.0.80.1979: . 1:1369(1368) ack 147 win 16416 (DF) (ttl 64, id 53038, len 1420 ) 09:40:59.157799 dell350-12.snv.http > 10.4.0.80.1979: . 1369:2737(1368) ack 147 win 16416 (DF) (ttl 64, id 53039, len 1 420) 09:40:59.157816 dell350-12.snv.http > 10.4.0.80.1979: . 2737:4105(1368) ack 147 win 16416 (DF) (ttl 64, id 53040, len 1 420) sending nothing larger than 1420 bytes. So freeBSD is behaving in a broken way that violates the RFC, unless I'm much mistaken. Unfortunately, I am not a coder, so cant go poking at source to verify or fix this. (Well, it would take me a very long time.) Anyone care to confirm (and ideally, fix)? I can replicate this at will, so can easily gather more data if people want. TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 12:39:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0671937B400; Wed, 14 Aug 2002 12:38:47 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97CE43E6E; Wed, 14 Aug 2002 12:38:45 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g7EJcWOo096464; Wed, 14 Aug 2002 15:38:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Aug 2002 15:38:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: hackers@FreeBSD.org, developers@FreeBSD.org Subject: FreeBSD Development Status Report: May, 2002 - June, 2002 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG May - June 2002 Status Report Introduction May and June were remarkably busy months for the FreeBSD Project-- FreeBSD developers met in Monterey, CA in June for FreeBSD Developer Summit III to discuss strategy for the FreeBSD 5.0 release later this year, for the USENIX Annual Technical conference and for the FreeBSD BoF. Substantial technical progress was made on FreeBSD 5.0, and FreeBSD 4.6-RELEASE was cut on the RELENG_4 branch in June. The remainder of the summer will continue to be busy. Final components and features for 5.0-RELEASE will go into the tree, and the development direction will change from new features to stability, performance, and production-readiness. With additional 5.0 development previews late in the summer, we hope to broaden the tester base for the -CURRENT branch, and start to get early adopters digging out any potential problems in their test environments. I encourage both FreeBSD Developers and FreeBSD Users to give 5.0-DP2 a spin (on a machine without critical data!) and let us know how it goes. The more testing that happens before the release, the less fixing we have to do afterwards! Robert Watson * Bluetooth stack for FreeBSD (Netgraph implementation) * BSDCon 2003 * Fast IPSEC Status * FreeBSD C99 & POSIX Conformance Project * FreeBSD GNOME Project * FreeBSD Java Project * FreeBSD Release Engineering * FreeBSD Security Officer Team * FreeBSD/ia64 * FreeBSD/KGI Status Report * GEOM - generalized block storage manipulation * Hardware Crypto Support Status * Improving FreeBSD Startup Scripts * IP Routing Table Replacement * ipfw2 * jp.FreeBSD.org daily SNAPSHOTs project * jpman project * KAME Project * KSE (Kernel schedulable Entity) thread support * Libh Status Report * Lightweight Interrupt Scheduling * locking up pcb's in the networking stack * mb_alloc updates * NATD rewrite * NEWCARD * OLDCARD * OpenOffice.org for FreeBSD * Single UNIX Specification conformant SCCS suite * SMPng Status Report * TCP Hostcache * TCP Metrics Measurement * TIRPC port for BSD sockets * TrustedBSD MAC * UFS2 - Extended attribute and large size support for UFS * Userland Regression Tests * Zero Copy Sockets status report Bluetooth stack for FreeBSD (Netgraph implementation) Contact: Maksim Yevmenkin Not much to report. Another engineering snapshot is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020709.tar.gz. If anyone has Bluetooth hardware and spare time please join in and help me with testing. This snapshot includes basic support for USB devices and manual pages. The HCI layer now has support for multiple control hooks. All HCI transport drivers (H4, BT3C and UBT) has been changed to provide consistent interface to the rest of the world. Some userspace utilities have been changed as well. Still no support for RFCOMM (Serial port emulation over Bluetooth link) and SDP (Service Discovery Protocol). Several design flaws have been discovered and it might take some time to resolve these issues. ---------------------------------------------------------------------- BSDCon 2003 URL: http://www.usenix.org/events/bsdcon03/cfp/ Contact: Gregory Shapiro The BSDCon 2003 Program Committee invites you to contribute original and innovative papers on topics related to BSD-derived systems and the Open Source world. Topics of interest include but are not limited to: * Embedded BSD application development and deployment * Real world experiences using BSD systems * Using BSD in a mixed OS environment * Comparison with non-BSD operating systems; technical, practical, licensing (GPL vs. BSD) * Tracking open source development on non-BSD systems * BSD on the desktop * I/O subsystem and device driver development * SMP and kernel threads * Kernel enhancements * Internet and networking services * Security * Performance analysis and tuning * System administration * Future of BSD Submissions in the form of extended abstracts are due by April 1, 2003. Be sure to review the extended abstract expectations before submitting. Selection will be based on the quality of the written submission and whether the work is of interest to the community. We look forward to receiving your submissions! ---------------------------------------------------------------------- Fast IPSEC Status Contact: Sam Leffler The main goal of this project is to modify the IPSEC protocols to use the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). A secondary goal is to do general performance tuning of the IPSEC protocols. Basic functionality is operational for IPv4 protocols. IPv6 support is coded but not yet tested. Hardware assisted cryptographic operations are working with good performance improvements. Operation with software-based cryptographic calculations appears to be at least as good as the existing implementation. Numerous opportunities for performance improvements have been identified. This work is currently being done in the -stable tree. A port to the -current tree is about to start. ---------------------------------------------------------------------- FreeBSD C99 & POSIX Conformance Project URL: http://www.FreeBSD.org/projects/c99/ Contact: Mike Barcroft Contact: FreeBSD-Standards Mailing List Since the last status report, the following utilities have been brought up to conformance (at least to some degree) with POSIX.1-2001, they include: asa(1), cd(1), compress(1), ctags(1), ls(1), newgrp(1), nice(1), od(1), pathchk(1), renice(1), tabs(1), tr(1), uniq(1), wc(1), and who(1). In addition, development is taking place on bringing the BSD SCCS suite up to date with newer standards. On the API front, printf(9) has been given support for the `j' and 'n' flags, waitpid(2) now supports the WCONTINUED option, and an implementation of fstatvfs() and statvfs() has been committed. An implementation of utmpx is in progress, which has an aim to address some of the major problems with the current utmp. Several headers have been brought up to conformance with POSIX.1-2001, they include: , , , and . ---------------------------------------------------------------------- FreeBSD GNOME Project URL: http://www.freebsd.org/gnome/ Contact: Joe Marcus Contact: Maxim Sobolev Things are going well with the FreeBSD GNOME Project. We have just finished porting the GNOME 2.0 Final development platform and desktop to FreeBSD! We hope to be able to make GNOME 2.0 the default for 5.0-DP2 and 4.7-RELEASE. In the meantime, we're working to port more GNOME 2.0 applications. In order to allow GNOME 1.4.1 applications to work with GNOME 2.0, we are revamping the GNOME porting infrastructure. GNOME 1.4.1 based ports are being converted to use the new GNOMENG porting structure. The specifics of this new system will be written up in the GNOME porting guide found on the FreeBSD GNOME project homepage. ---------------------------------------------------------------------- FreeBSD Java Project URL: http://www.freebsd.org/java/ Contact: Greg Lewis The BSD Java Porting Team has been making slow but steady progress on a number of fronts in the last few months. Unfortunately most of this has occurred behind the scenes, meaning this is a good opportunity to bring the community up to date. * Bill Huey has gotten the Java HotSpot Virtual Machine up and running on FreeBSD! While dubbing the code of alpha quality, Bill has been working hard and is able to run major examples such as the Java 2D demo. This code has hit the repository and will soon be available. * The port of the 1.4 J2SDK has commenced. The first commits have gone into the tree, although a first patchset is a way off yet. * Progress continues with the TCK compliance testing. The current status has the JDK down to 19 compiler failures and 183 runtime failures. As we edge closer to compliance its hoped that example code will be released to allow the community to pull together through the final few bugs. * A new patchset for JDK 1.3.1 is imminent. This patchset will include HotSpot for the first time. ---------------------------------------------------------------------- FreeBSD Release Engineering URL: http://www.FreeBSD.org/releng Contact: Over the past few months the FreeBSD Release Engineering Team oversaw a release process that culminated in the release of FreeBSD 4.6 for the i386 and Alpha architectures on June 15. The RE team is currently working concurrently on FreeBSD 4.6.1 and 5.0 DP2. 4.6.1 is a minor point release with an updated SSH and BIND, fixes for some of the reported ata(4) problems, and assorted security enhancements that will be detailed in the release notes. The release engineering activities for 4.6.1 are taking place on the RELENG_4_6 branch in CVS, while the work on 5.0 DP2 is taking place in Perforce so as not to disturb ongoing -CURRENT development. We are still committed to FreeBSD 5.0 on or around November 15, 2002. For more information about upcoming release schedules, please see our website above. The RE team would like to thank Sentex Communications for providing the release builders with access to a fast i386 build machine. Compaq also donated a couple of fast Alpha build machines to the project. ---------------------------------------------------------------------- FreeBSD Security Officer Team URL: http://www.freebsd.org/security Contact: Jacques Vidrine After an outstanding job serving the project as Security Officer for over a year, Kris stepped down in January in order to focus more of his time pursuing his PhD. I offered to attempt to fill the vacant role. This is the first report by the SO Team. Notable events since the beginning of 2002 follow. 28 FreeBSD Security Advisories have been issued, 16 of which were regarding the base system. Of those sixteen, 8 affected only FreeBSD. FreeBSD Security Notices were introduced, and four have been issued so far. The Security Notices cover issues that are not regarded as critical enough to warrant a Security Advisory. So far only Ports Collection issues (i.e. vulnerabilities in optional 3rd party packages) have been reported in Security Notices. The first four Security Notices covered 53 individual issues. Issues reported to the SO team are now being tracked using a RequestTracker ticket database. The SO team has undergone membership changes, as well as some changes in internal organization. The membership and organization has also been made publicly visible on the FreeBSD Security Officer web page. ---------------------------------------------------------------------- FreeBSD/ia64 URL: http://people.freebsd.org/~peter/ia64/ Contact: Peter Wemm IA64 has been progressing slowly. We have access to a prototype 4-way Itaninum2 system from Intel and have managed to get it up and running to the point of being able to access disk and network with SMP enabled. We have a big problem with ACPI2.0 and PCI routing table entries behind pci-pci bridges with no short-term solution in sight. Various WIP items have been committed to CVS, namely more complete support for executing 32bit i386 binaries as well as Marcel Moolenaar's prototype EFI GPT tools. ---------------------------------------------------------------------- FreeBSD/KGI Status Report URL: http://www.FreeBSD.org/~nsouch/ggiport.html Contact: Nicholas Souchu Progression is slow, but the effort is maintained. Most of fb over KGI has been written in parallel with a KGI display driver based on fb. DDC/DDC2 is being discussed for Plug & Play monitor support. KGI aims at providing a generic OS independant interface which would take advantage of FreeBSD I2C (iic(4)) infrastructure. ---------------------------------------------------------------------- GEOM - generalized block storage manipulation URL: http://www.freebsd.org/~phk/Geom/ Contact: Poul-Henning Kamp The GEOM code has gotten so far that it beats our current code in some areas while stil lacking in others. The goal is for GEOM to be the default in 5.0-RELEASE. Currently work on a cryptographic module which should be able to protect a diskpartition from practically any sort of attack is progressing. ---------------------------------------------------------------------- Hardware Crypto Support Status Contact: Sam Leffler The goal of this project is to import the OpenBSD kernel-level crypto subsystem. This facility provides kernel- and user-level access to hardware crypto devices for the calculation of cryptographic hashes, ciphers, and public key operations. The main clients of this facility are the kernel RNG (/dev/random), network protocols (e.g. IPSEC), and OpenSSL (through the /dev/crypto device). The software has been available as a patch against the -stable tree for about six months. The core crypto support is tested, including device drivers for the Hifn 7951, and Broadcom 5805, 5820, and 5821 parts. Recent work has concentrated on fixing device driver bugs, fixing support for Hifn 7811 parts, adding support for public key operations, and adding flow-control between the crypto layer and device drivers. Future work includes porting this facility to the -current tree. ---------------------------------------------------------------------- Improving FreeBSD Startup Scripts URL: http://groups.yahoo.com/group/FreeBSD-rc/links/ Contact: Doug Barton Contact: Mike Makonnen Contact: Gordon Tetlow We are making excellent progress. There is a fully functioning implementation imported to -current now. We need as many people as possible to rc_ng equal to YES in /etc/rc.conf. The next step is to set the default to YES, which we plan to do before DP 2. ---------------------------------------------------------------------- IP Routing Table Replacement Contact: Andre Oppermann Contact: Claudio Jeker The current Patricia Trie routing table in BSD UNIX is not very efficient and wastes an enormous amount of space for every node (more than 256 bytes) (A full Internet view of 110k routes takes 33 MByte of KVM). Another problem are pointers from and to everywhere in the routing table. This makes replacing the table very hard and also significantly highers the table maintainance burden (for example for some kinds of updates the entire PCB has be searched lineary). Also this is a heavy burden for SMP locking. The rewrite focuses on untangeling the pointer mess, making the routing table replaceable and providing a more IP optimized table (5 MByte for 110k routes). Other new options include policy routing and some structual alignments in the network stack for clarity, cleaness and flexibilty. The rewritten IP routing table will be ready for committing in October. ---------------------------------------------------------------------- ipfw2 URL: http://www.iet.unipi.it/~luigi/ Contact: Luigi Rizzo In summer 2002 the native FreeBSD firewall has been completely rewritten in a form that uses BPF-like instructions to perform packet matching in a more effective way. The external user interface is completely backward compatible, though you can make use of some newer match patterns (e.g. to handle sparse sets of IP addresses) which can dramatically simplify the writing of ruleset (and speed up their processing). The new firewall, called ipfw2, is much faster and easier to extend than the old one. It has been already included in FreeBSD-CURRENT, and patches for FreeBSD-STABLE are available from the author. ---------------------------------------------------------------------- jp.FreeBSD.org daily SNAPSHOTs project URL: http://snapshots.jp.FreeBSD.org/ URL: http://www.jp.FreeBSD.org/snapshots/ URL: http://snapshots.jp.FreeBSd.org:8021 URL: ftp://daemon.jp.FreeBSD.org/pub/FreeBSD/releases/i386/ Contact: Makoto Matsushita I spent busy days in last two months, many new topics are emerged from the project. We now support FreeBSD/alpha 5-current distribution by cross-compiling on the x86 PC. Anonymous ftp area is now exported to the yet another web server. Our release branch snapshots are relocated to daemon.jp.FreeBSD.org because of our CPU/network bandwidth problem. I'm seriously considering to solve the lack of CPU and network resources for the project's future evolution. Maybe the bandwidth problem can be resolved (several bandwidth offering are received!), but there is no answer about CPU problem (I have a plan to upgrade our PCs from P3-500Mhz to P4 or something better than previous). If you have interested to donate PCs to the project, please email me for more detail. ---------------------------------------------------------------------- jpman project URL: http://www.jp.FreeBSD.org/man-jp/ Contact: Kazuo Horikawa For 4.6-RELEASE, we announced the package ja-man-doc-4.6.tgz which is in sync with 4.6-RELEASE base system manual pages except for perl5 pages (jpman project do not maintain them). Continuing section 3 updating has 88% finished. ---------------------------------------------------------------------- KAME Project URL: http://www.kame.net/ URL: http://www.interop.jp/eng/exhibition/ipv6_showcase.html URL: http://www.interop.jp/jp/exhibition/ipv6_showcase.html URL: http://www.sfc.wide.ad.jp/~say/n+i/ Contact: SUZUKI Shinsuke I'm afraid KAME Project does not work actively with regard to FreeBSD in these two month, since we are too busy with the demonstration of our IPv6 implementation at Networld+Interop 2002 Tokyo. (Thanks to a great effort, the demonstration was quite successful) We are aware of netinet6-related bug reports regarding socket handling, fine-grain locking, ip6fw etc. Regret to say, we could not answer them right now due to the above situation, however we'll discus these issues internally and determine what to do. ---------------------------------------------------------------------- KSE (Kernel schedulable Entity) thread support URL: http://www.freebsd.ord/~julian/ Contact: Julian Elischer Contact: Dan Eischen The project took a major step at the beginning of July when Milestone-III was committed. Milestone-III allows a simple test program (available at /usr/src/tools/KSE/ksetest/) to run multiple threads, using kernel support. It does not yet allow the ability to allow these threads to run on different CPUs simultaneously. Milestone IV will be to allow this, however Milestone-III should allow Dan to start (with any interested parties) to start prototyping the userland part of the system. Milestone-III is only currently usable on x86, and does not include some of the requirements for full thread-control, suspension etc. that will be required later. Before M-IV is started some small tweeking is likely in the central sources on M-III as we discover issues as we try to get the userland jumpstarted. These will have no effect on non-KSE processes, (i.e. all of them :-) and should not be an issue for other developers. A tex/fig->html guru is needed to help maintain the KSE web page (not mentionned above as it is broken). ---------------------------------------------------------------------- Libh Status Report URL: http://www.freebsd.org/projects/libh.html URL: http://usw4.freebsd.org/~libh/ URL: http://usw4.freebsd.org/~libh/screenshots Contact: Antoine Beaupre Contact: Alexander Langer Contact: Nathan Ahlstrom Max has been busy cleaning up the user interface dark side, and has come up with a plan to improve the build system (using an automated Makefile dependency generator); the UI design and the TCL glue magic (using Swig). A develepment page has been created on usw4, publishing a lot of information about the current project status, a Changelog, screenshots, documentation, etc. A new listbox widget has been implemented, making diskeditor look nicer and more useable. The package system backend is being inspected and redesigned to conform to a standard that is itself being re-thought. Indeed, the old sysinstall2.txt text has been SGML-ized and enhanced and now provides a good (altough rough) overview of libh package system. This allowed the document to be enhanced with diagrams of how different procedures work. We are therefore getting closer to a real pkgAPI specification document. The package management tools have been sligthly enhanced and should be a bit more useable, and we started commiting regression test suites in the tree, mostly to test and maintain pkg API conformance. So work continues on libh. I plan to take a look at the rhtvision port to see if it would be better to use it for the tvision backend. I'll keep on working on the package system to make it really trustworthy, while Max is continuing his great work on the UI subsystem. I hope to make a new libh alpha release soon. Note that from now on, libh progress will be published on the development page. ---------------------------------------------------------------------- Lightweight Interrupt Scheduling URL: http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/interrupt/sys/... Contact: Bosko Milekic The lightweight interrupt scheduling code makes scheduling an interrupt on i386 without having to grab the sched_lock possible, and also avoids a full-blown context switch. Currently, the code in the p4 branch works, although needs a little bit of cleanup and, most importantly, requires a merge to post-KSE III. Now that stuff seems to have stabilized a bit, I'm waiting to get a little time (and nerve) to do the merge. Also, looking forward for some KSE interface that will allow for "KSE borrowing," which would make this cleaner with regards to KSE and lightweight interrupts. This is a 5.0 feature. ---------------------------------------------------------------------- locking up pcb's in the networking stack URL: http://www.freebsd.org/smp Contact: Jeffrey Hsu Jennifer Yang's patch was committed June 10 for the BSD Summit. After a few bugs which were reported initially and fixed that same week, networking in -current has been stable, including the parts that were not locked up, like IPv6. Work is on-going to lock up the rest of the stack. ---------------------------------------------------------------------- mb_alloc updates URL: http://people.freebsd.org/~bmilekic/code/mb_alloc/ Contact: Bosko Milekic mb_alloc is getting some updates and a couple of optimisations. A new allocator interface routine should already be committed by the time this report is "published:" m_getcl() allocates an mbuf and a cluster in one shot. This is the result of months (literally) of requests from Alfred and, recently, Luigi - who, coincidentally, is the author of the same [upcoming] routine in -STABLE. Other than that, mb_alloc is being shown how to perform multi-mbuf or cluster allocations without dropping the cache lock in between (m_getcl() and m_getm() will use this). Finally, work is being done to optimise ext_buf ref. count allocations and to provide support for jumbo (> 9K) clusters. ---------------------------------------------------------------------- NATD rewrite Contact: Claudio Jeker Contact: Andre Oppermann The current natd is pretty powerful in translating different kinds of traffic but not very powerful in configuration. This project rewrites natd and parts of libalias to give it a configuration set as powerful and expressive as the ones in ipf (ipnat) and pf. In addition it'll use kqueue and will support aliasing to multiple IP addresses. The rewritten natd will be ready for committing in early September. ---------------------------------------------------------------------- NEWCARD Contact: Warner Losh A devd daemon, to replace pccardd and usbd, has been designed. A few minor bugs have been fixed in NEWCARD. NEWCARD is now the default in -current. There is an experimental pci/cardbus bus code merge available as a branch which will be merged into current as soon as it is stable. Status: The ed driver, for non-ne2000 clones, is broken and won't probe. The ata driver won't attach. The sio driver hangs on the first character. The wi driver is known to work well. Cardbus cards are generally known to work well, except for some de based cards, which unfortuntely includes the popular Xircom cards. Many systems fail to work because acpi fails to route interrupts correctly for non-root pci bridges. ---------------------------------------------------------------------- OLDCARD Contact: Warner Losh A major power bug was fixed in oldcard. This caused many problems for people using PCI interrupts having their machines hang on boot. This fix has made it into 4.6.1. Cardbus power is now used on all cardbus bridges that support it. This means that we now support 3.3V cards on all cardbus bridges. Before, we only supported them on some of the bridges because every bridge uses different 3.3V power control when programmed through the ExCA registers. Now that we're going through the CardBus bridge's power control register, 3.3V cards work. In fact, for CardBus bridges, the so called X.XV and Y.YV cards will work in those bridges that support them. However, X.XV and Y.YV haven't been defined yet, and no bridges support them (but the bridge interface define it). Obviously this latter part is untested. CL-PD6722 support has been augmented slightly. Now it is possible to instruct the driver which type of 3.3V card detection strategy to use. There are three choices: none, do it like the CL-PD6710 does it and do it like the CL-PD6722 does it. Preliminary support for the CL-PD6729 on a PCI card using PCI interrupts has been committed. However, it fails for at least one of the cards like this the author has. Client drivers can now ask for the manufacturer and model number of the card without parsing the CIS directly. Except for fixing bugs and updating pccard.conf entries, no additional work is planned on the OLDCARD system. ---------------------------------------------------------------------- OpenOffice.org for FreeBSD URL: http://projects.imp.ch/openoffice Contact: Martin Blapp The port of openoffice 1.0 has been finished. Most showstopper issues with rtld, libc and our toolchain have been fixed. There is one remaining deadlock in the web-browser code of OO.org. If anybody like to help us with fixing this bug (may be another libc_r bug as it looks like) just mail me ! Unfortunalty gcc2 support got broken again with the import of gcc2.95.4 in STABLE. Exceptions support seems to be broken again, we get internal compiler errors with c++ exceptions code. You'll have to use gcc31 again. Since our package cluster is outdated and can not build OO.org packages anytime soon, I did my own little package cluster and can now offer packages for 4.6R for 16 different languages. They can be found on the project homepage. Porting of OpenOffice1.0.1 is on it's way. A beta port and a package have been made available on the project homepage. ---------------------------------------------------------------------- Single UNIX Specification conformant SCCS suite Contact: Juli Mallett The final version of SCCS distributed by CSRG has been integrated into the projects CVS repository, and worked on extensively to the point where essential functionality works on FreeBSD (and other operating systems). Some standards-related functionality has been implemented ---------------------------------------------------------------------- SMPng Status Report URL: http://www.FreeBSD.org/smp/ Contact: John Baldwin Contact: The SMPng project has continued to make steady progress in the past two months. Jeff Roberson completed the switch over to UMA for the general kernel malloc() and free() pushing down Giant appropriately so that callers of malloc() and free() are no longer required to hold Giant. Alan Cox continues to clean up the locking in the VM system pushing down Giant in several of the VM related system calls. Jeffrey Hsu committed locking for TCP/IP protocol control blocks in the network stack. John Baldwin committed the changes to the p_canfoo() API to use thread credentials for subject threads and added appropriate locking for the targer process credentials. Support for adaptive mutexes on SMP systems as well as the new IA32 PAUSE instruction were also committed in May. The kernel tracing facility KTRACE also received an overhaul such that the majority of its work was pushed out into a worker thread allowing trace points to no longer require Giant. Andrew Reiter has also been pushing down Giant in several system calls. Bosko continues to work on light-weight interrupt threads for i386. Most of the bugs in the turnstile code have been found and fixed; however, the turnstile and preemption patches have temporarily been put on hold so that more emphasis can be placed on fixing bugs and making -current more stable in preparation for 5.0 release in November. Alan Cox and Andrew Reiter are continuing the work mentioned above. Jeff Roberson is also working on fixing the current vnode locking in VFS. Peter Wemm has also started to tackle TLB issues on SMP in the i386 pmap again as well. ---------------------------------------------------------------------- TCP Hostcache Contact: Andre Oppermann The current cache for the TCP metrics is embedded directly into the routing table route objects. This is highly inefficient as every route has an empty 56 Byte large metrics structure in it. TCP is the only consumer (except the MTU and Expiry field) of the structure. A full view of the Internet routes (110k routes) has more than 6 Mbyte of unused overhead due to it. The hit rate today is at only approx. 10% in webserver applications. The TCP hostcache will move this entire metrics structure from the routing table to the TCP stack. Every entry is a host entry so a simple hash table is sufficient to keep the entries. Its implementation is much like the TCP Syncache. The hostcache is going through testing on our servers and will be ready for committing in September. The results of the TCP metrics measurement will be used to tune the cache. ---------------------------------------------------------------------- TCP Metrics Measurement URL: http://www-t.zhwin.ch/pa02_2/diplomarbeiten2002.pdf Contact: Andre Oppermann Contact: Olivier Mueller These students will analyse the tcpdumps of five major Swiss newspaper websites which give a representative overview of the user structure in Switzerland. The nice thing about Switzerland is that is has a very good mix of Modem/ISDN, leased line, Cable, ADSL and 3G/GSM/GPRS users. Every Internet access technology is represented. The goal is to analyse the behaviour of all TCP sessions to the monitored sites. Parameters to be analysed include TCP session RTT, RTT variance, in/outbound BDP, MSS changes, flow control behaviour, packet loss, packet loss, packet retransmit and timing of HTTP traffic to find optimal TCP parameter caching method. If you have any other metrics you think is useful please contact me so I can put that into the job description for the Students. The study will be made in September and October. ---------------------------------------------------------------------- TIRPC port for BSD sockets URL: http://www.attic.ch/tirpc URL: http://www.attic.ch/tirpc Contact: Martin Blapp A lot of remaining PR's and Bugs have been closed. All relevant rpc concerning patches have been comitted. Thank goes to Alfred and Ian Dowese. Jean-Luc Richier has made a patch available which adds IPv6 support to all remaining rpc servers. See ftp://ftp.imag.fr/pub/ipv6/NFS/NFS_IPV6_FreeBSD5.0.gz and ftp://ftp.imag.fr/pub/ipv6/NFS/0README_NFS_IPV6_FreeBSD5.0 We will check his code and add it to CURRENT ASAP. A first commit part from TIRPC99 has been done. I'm working now on porting the remaining parts so when FreeBSD 5.0 gets released, it will be TIRPC99 based. This will happen together with the NetBSD project, as they use the same codebase as we do. ---------------------------------------------------------------------- TrustedBSD MAC URL: http://www.TrustedBSD.org/ Contact: Robert Watson Contact: TrustedBSD Discussion Mailing List The TrustedBSD Project has been busy in May and June, developing new features, presenting on the technology at the FreeBSD Developer Summit, and improving the readiness of the MAC branch for integration into the main FreeBSD tree. The migration to dynamic labeling in the TrustedBSD MAC framework is complete, with all policies now making use of dynamic labels in the kernel. This permits policies to associate arbitrary additional security data with a variety of kernel objects at run-time. Implement mac_test, a sanity checking module. Pass labels as well as objects to each policy entry point to reduce knowledge of label storage in the policies. Implement mac_partition, a simple jail-like policy. Adapt the MAC framework for process locking. Improve support for sockets: provide a peerlabel maintained for stream sockets (unix domain, tcp), entry points for accept, bind, connect, listen. Improve support for IPv4 and IPv6 by labeling IP fragment reassembly queues, and providing entry points to instrument fragment matching, update, reassembly, etc. Locally disable KAME if_loop mbuf contiguity hack because it drops labels on mbufs: we need to make sure the label is propagated. Label pipes and provide access control for them. Improve vnode labeling: now handle labeling for devfs, pseudofs, procfs. Fix interactions between MAC and ACLs relating to the new VAPPEND flag. SELinux policy tools now ported to SEBSD. SEBSD now labels subjects and file system objects. Provide ugidfw, a tool for managing rules for the mac_bsdextended policy. Massive diff reduction. KSEIII merged. Main tree integration will begin shortly. Updated prototype code may be retrieved from the TrustedBSD CVS trees on cvsup10.FreeBSD.org. ---------------------------------------------------------------------- UFS2 - Extended attribute and large size support for UFS Contact: Poul-Henning Kamp Contact: Kirk Mckusick UFS2 is an extension to the well-known UFS filesystem which using a new inode format adds support for "64bit everywhere" and later for extended attribute support, in addition to the current UFS features: soft-updates and snapshots. The basic UFS2 code has been committed and work on the extended attribute interface and vnode operations will continue. ---------------------------------------------------------------------- Userland Regression Tests Contact: Juli Mallett Regression tests for many bugs fixed in text manipulation utilities have been added, as well as tests for various non-standard versions of functionality that FreeBSD users should expect. A library of m4 macros for creating the tests themselves has been added. ---------------------------------------------------------------------- Zero Copy Sockets status report URL: http://people.FreeBSD.org/~ken/zero_copy/ Contact: Ken Merry The zero copy sockets code was committed to FreeBSD-current on June 25th, 2002. I'm not planning on doing any more patches, although I will leave the web page up as it contains useful information. Many thanks to the folks who have tested and reviewed the code over the years. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 14:20:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B8337B400 for ; Wed, 14 Aug 2002 14:20:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E4F43E6E for ; Wed, 14 Aug 2002 14:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020814212007.OTWE13899.sccrmhc02.attbi.com@InterJet.elischer.org> for ; Wed, 14 Aug 2002 21:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA23182 for ; Wed, 14 Aug 2002 14:08:36 -0700 (PDT) Date: Wed, 14 Aug 2002 14:08:35 -0700 (PDT) From: Julian Elischer To: hackers@freebsd.org Subject: BSD and HP Pavilion computers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Has anyone managed to get dual-boot working on an HP Pavilion? (Or even a non dual boot?) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 14:40: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F226737B400 for ; Wed, 14 Aug 2002 14:39:41 -0700 (PDT) Received: from mydomain.com (182.Red-80-59-229.pooles.rima-tde.net [80.59.229.182]) by mx1.FreeBSD.org (Postfix) with SMTP id 3AED943E4A for ; Wed, 14 Aug 2002 14:39:30 -0700 (PDT) (envelope-from reg@regaltelecom.com) From: "World Connection" To: "Hackers" Subject: Important Message Date: Wed, 14 Aug 2002 23:39:22 +0200 MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High Reply-To: "World Connection" X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_5619913543" Message-Id: <20020814213930.3AED943E4A@mx1.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------_NextPart_5619913543 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE =93Connecting your Business to the World Wide Web=94 How many customers are YOU LOSING? The figure would AMAZE YOU! HOW are you LOSING them? They cannot find your web site! A Simple Equation NOT Being FOUND =3D Losing new Customers! We can change that! For ONLY $119.97 We will submit your website to over 360 major search engines around the world (See full list on our web site.) But more than that We will research the best and most effective meta tags and keywords to use on your web site so that you will rise in the search engine listings So new customers can FIND YOU! Don't lose any more customers! Let us professionally manage the submission of your web site and get it FOUND and SEEN on the Worlds Search Engines! CLICK ON this link CLICK HERE! to discover the POWER of =93Connecting your Business to the World Wide Web=94 ------_NextPart_5619913543 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE World Web Connect:::::::::::The Best Web Solutions!!!

      =93Connecting your Business to the World Wide Web=94

 

How many customers are

YOU LOSING?

The figure would AMAZE YOU!

 

HOW are you LOSING them?

They cannot find your web site!

A Simple Equation

NOT Being FOUND =3D Losing new Customers!

 

 We can change that!

 

For ONLY $119.97

 

We will submit your website to over 360 major search engines around the world

(See full list on our web site.)

 

But more than that

We will research the best and most effective meta tags and keywords to use

on your web site so that you will rise in the search engine listings

So new customers can FIND YOU!

 

Don't lose any more customers!

 

Let us professionally manage the submission of your web site

and get it FOUND and SEEN on the Worlds Search Engines!

CLICK ON this link

CLICK HERE!

to discover the POWER of

 =93Connecting your Business to the World Wide Web=94

 

 

 

 

 

   
------_NextPart_5619913543-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 14:50:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6068837B400 for ; Wed, 14 Aug 2002 14:50:29 -0700 (PDT) Received: from smtp.lynuxworks.com (smtp.Lynuxworks.COM [207.21.185.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2D8543E3B for ; Wed, 14 Aug 2002 14:50:28 -0700 (PDT) (envelope-from pbuckingham@Lnxw.COM) Received: from lnxw.com (farscape.isdcorp.com [216.100.252.8]) by smtp.lynuxworks.com (8.11.2/8.9.3) with ESMTP id g7ELoQ728812; Wed, 14 Aug 2002 14:50:26 -0700 Message-ID: <3D5ACFA2.8070304@lnxw.com> Date: Wed, 14 Aug 2002 14:46:10 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Has anyone managed to get dual-boot working on an HP Pavilion? > > (Or even a non dual boot?) yep. i actually have triple boot: windows, linux & freebsd. i used partition magic initally with one hard disk, with two it was much simpler. what problems are you having? peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 15:20:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBF4337B400 for ; Wed, 14 Aug 2002 15:20:12 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3978F43E42 for ; Wed, 14 Aug 2002 15:20:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020814222007.TBSC11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Wed, 14 Aug 2002 22:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA23410; Wed, 14 Aug 2002 15:02:04 -0700 (PDT) Date: Wed, 14 Aug 2002 15:02:04 -0700 (PDT) From: Julian Elischer To: Peter Buckingham Cc: hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers In-Reply-To: <3D5ACFA2.8070304@lnxw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG P.s. I'm going to try partition magic next (I found a copy at work) On Wed, 14 Aug 2002, Peter Buckingham wrote: > Julian Elischer wrote: > > Has anyone managed to get dual-boot working on an HP Pavilion? > > > > (Or even a non dual boot?) > > yep. i actually have triple boot: windows, linux & freebsd. > > i used partition magic initally with one hard disk, with two it was much simpler. > > what problems are you having? > > peter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 15:20:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA80F37B405 for ; Wed, 14 Aug 2002 15:20:14 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5613843E42 for ; Wed, 14 Aug 2002 15:20:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020814222013.TBUJ11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Wed, 14 Aug 2002 22:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA23408; Wed, 14 Aug 2002 15:01:13 -0700 (PDT) Date: Wed, 14 Aug 2002 15:01:12 -0700 (PDT) From: Julian Elischer To: Peter Buckingham Cc: hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers In-Reply-To: <3D5ACFA2.8070304@lnxw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG did you get CDs? I was going to try reinstall the Windows in a virtual partition for VMware but as they give you a the software distribution in a "recovery partition" on the disk instead of on CDs that becomes hard(er). Also whan IO put on the BSD boot manager it booted directly to 'recovery mode' instead of to BSD. It then wanted to recreate the original (BIG) ntfs partition instead of living with the BSD partiton and smaller ntfs partition I replaced it with.. I'm still experimenting with it though.. It's a Pavilion 512-N also any idea what type the ethernet card is.. BSD 4.4 didn't see it that's for sure.. On Wed, 14 Aug 2002, Peter Buckingham wrote: > Julian Elischer wrote: > > Has anyone managed to get dual-boot working on an HP Pavilion? > > > > (Or even a non dual boot?) > > yep. i actually have triple boot: windows, linux & freebsd. > > i used partition magic initally with one hard disk, with two it was much simpler. > > what problems are you having? > > peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 15:37:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A415137B400 for ; Wed, 14 Aug 2002 15:37:35 -0700 (PDT) Received: from bodb.mc.mpls.visi.com (bodb.mc.mpls.visi.com [208.42.156.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3072443E6A for ; Wed, 14 Aug 2002 15:37:35 -0700 (PDT) (envelope-from hawkeyd@visi.com) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by bodb.mc.mpls.visi.com (Postfix) with ESMTP id 7E2945A3F; Wed, 14 Aug 2002 17:31:44 -0500 (CDT) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g7EMVe223414; Wed, 14 Aug 2002 17:31:40 -0500 (CDT) (envelope-from hawkeyd) Date: Wed, 14 Aug 2002 17:31:40 -0500 (CDT) Message-Id: <200208142231.g7EMVe223414@sheol.localdomain> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: hawkeyd@visi.com Organization: if (!FIFO) if (!LIFO) break; References: In-Reply-To: From: hawkeyd@visi.com (D J Hawkey Jr) Subject: Re: BSD and HP Pavilion computers X-Original-Newsgroups: sol.lists.freebsd.hackers To: julian@elischer.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article , julian@elischer.org writes: > > Has anyone managed to get dual-boot working on an HP Pavilion? > > (Or even a non dual boot?) Yup. I have a Pavilion 7840. I used FreeBSD's FIPS (I think that's what it's called) to cut the Windoze(tm) partition in half, and installed FreeBSD in the new space. FreeBSD's boot manager works fine. > Julian You have a problem, or just looking ahead? Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 15:55:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98CF837B400 for ; Wed, 14 Aug 2002 15:55:08 -0700 (PDT) Received: from smtp.lynuxworks.com (smtp.Lynuxworks.COM [207.21.185.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BE0B43E72 for ; Wed, 14 Aug 2002 15:55:08 -0700 (PDT) (envelope-from pbuckingham@Lnxw.COM) Received: from lnxw.com (farscape.isdcorp.com [216.100.252.8]) by smtp.lynuxworks.com (8.11.2/8.9.3) with ESMTP id g7EMt7731288; Wed, 14 Aug 2002 15:55:07 -0700 Message-ID: <3D5ADECB.6060505@lnxw.com> Date: Wed, 14 Aug 2002 15:50:51 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Julian, Julian Elischer wrote: > did you get CDs? it had the recovery cds. > I was going to try reinstall the Windows in a virtual partition > for VMware but as they give you a the software distribution > in a "recovery partition" on the disk instead of on CDs > that becomes hard(er). i remember have some difficulties because the recovery cds try to take the whole partition. with partition magic i think that i hid the end partition and everything was okay. > Also whan IO put on the BSD boot manager it booted directly to 'recovery > mode' instead of to BSD. It then wanted to > recreate the original (BIG) ntfs partition instead of > living with the BSD partiton and smaller ntfs partition I replaced > it with.. I'm still experimenting with it though.. not sure about this, it was a while ago since i did it. > also any idea what type the ethernet card is.. BSD 4.4 didn't see it > that's for sure.. mine was a wierd version of realtek, i haven't managed to get it working yet. it detects it but then has problems so it doesn't quite load. i am currently having problems with it detecting my modem. i have an actiontec pci modem which has it's id listed in the pci_ids, pciconf -lv lists it, but it is not detected as an sio on boot :-( this modem is detected and runs fine under linux and windows on the exact same pc. i am trying to upgrade to current to see whether this helps... i can give you more details when i get home. peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 17:14:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69D7237B400; Wed, 14 Aug 2002 17:14:04 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CA643E70; Wed, 14 Aug 2002 17:14:03 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([138.89.159.38]) by pop018.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20020815001402.XBIF8228.pop018.verizon.net@bellatlantic.net>; Wed, 14 Aug 2002 19:14:02 -0500 Message-ID: <3D5AF247.6545758C@bellatlantic.net> Date: Wed, 14 Aug 2002 20:13:59 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: "Semen A. Ustimenko" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI device emulation using SCSI host controller References: <20020813232629.L568-100000@main.the.net> <20020813132935.A51629@panzer.kdm.org> <3D59AE9B.3C27FA8C@bellatlantic.net> <20020813203037.A53640@panzer.kdm.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > > On Tue, Aug 13, 2002 at 21:12:59 -0400, Sergey Babkin wrote: > > "Kenneth D. Merry" wrote: > > > > > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > > > Hi! > > > > > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > > > using usual SCSI host controller and specific software, or I will > > > > definitely need specific hardware?" > > > > > > You'll need either the right Adaptec or QLogic controller, but yes, it can > > > be done with FreeBSD. > > > > Or Symbios (now LSI Logic). > > Has anyone done any target mode code for their boards? Not any I know of. If anyone is willing to do that, I can provide examples of the target-mode microcode for Symbios. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 18: 0:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8987937B400 for ; Wed, 14 Aug 2002 18:00:31 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id F02B843E6A for ; Wed, 14 Aug 2002 18:00:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815010015.YIIA13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 01:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA23976; Wed, 14 Aug 2002 17:50:01 -0700 (PDT) Date: Wed, 14 Aug 2002 17:49:59 -0700 (PDT) From: Julian Elischer To: D J Hawkey Jr Cc: freebsd-hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers In-Reply-To: <200208142231.g7EMVe223414@sheol.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Any idea how to set up XFree86 V3.3.6 for the i810 VGA controller? On Wed, 14 Aug 2002, D J Hawkey Jr wrote: > In article , > julian@elischer.org writes: > > > > Has anyone managed to get dual-boot working on an HP Pavilion? > > > > (Or even a non dual boot?) > > Yup. I have a Pavilion 7840. I used FreeBSD's FIPS (I think that's what > it's called) to cut the Windoze(tm) partition in half, and installed > FreeBSD in the new space. FreeBSD's boot manager works fine. > > > Julian > > You have a problem, or just looking ahead? > Dave > > -- > > Windows: "Where do you want to go today?" > Linux: "Where do you want to go tomorrow?" > FreeBSD: "Are you guys coming, or what?" > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 20:53:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B17E937B407 for ; Wed, 14 Aug 2002 20:53:07 -0700 (PDT) Received: from hotmail.com (oe42.pav0.hotmail.com [64.4.32.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78A843E84 for ; Wed, 14 Aug 2002 20:52:21 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Aug 2002 20:52:07 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: Subject: Hi, the kernel how control timeout and interrupt method? Date: Thu, 15 Aug 2002 11:51:58 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0000_01C24452.2929FDA0" Message-ID: X-OriginalArrivalTime: 15 Aug 2002 03:52:07.0802 (UTC) FILETIME=[205DEDA0:01C2440F] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C24452.2929FDA0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0001_01C24452.2929FDA0" ------=_NextPart_002_0001_01C24452.2929FDA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi guys, I have two questions, please help. 1. in one book, there are both pfslowtimo(void *arg) and pffasttimo(void = *arg) in =20 uipc_domain.c, which will be called by timeout, one is called every 500ms= , the other is called every 200ms. I want to know how FreeBSD control the t= imeout? I want to the kernel how to know it is time to call pfslowtimo or pffastt= imo? 2. I have a data-line, which connet the COM2 with a special backplane(my = box's IDE disk attach by the backplane). I can scan the COM2's state to find whether the= IDE disk exist or not. I use the polling method to scan in user space. =20 I access '/dev/io' device and get the COM state from the interface addre= ss.I think this method is unefficient. I think when the COM status change, it should spring an interrupt, the k= erenl will ignore the interrupt default, right? I can write an interrupt program, or embed = my process in the kernel. But I have no idea how to start. how can I start my task? =20 Thank you! Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://exp= lorer.msn.com ------=_NextPart_002_0001_01C24452.2929FDA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi guys,
&n= bsp;I have two questions, please help.
1. in one book, there are both = pfslowtimo(void *arg) and pffasttimo(void *arg) in
uipc_domain.c, whi= ch will be called by timeout, one is called every 500ms,
the other is = called every 200ms. I want to know how FreeBSD control the timeout?
I = want to the kernel how to know it is time to call pfslowtimo or pffasttim= o?
2. I have a data-line, which connet the COM2 with a special= backplane(my box's IDE disk
attach by the backplane). I can scan the = COM2's state to find whether the IDE disk exist
or not. I use the poll= ing method to scan in user space.
 I access '/dev/io' device and= get the COM state from the interface address.I think this
method is u= nefficient.
 I think when the COM status change, it should spring= an interrupt, the kerenl will ignore
the interrupt default, right? I = can write an interrupt program, or embed my process in the
kernel. But= I have no idea how to start. how can I start my task?
 
 = ;Thank you!
Best Regards
Ouyang Kai
 
&n= bsp;

Get more from the Web. FREE = MSN Explorer download : http://explor= er.msn.com

------=_NextPart_002_0001_01C24452.2929FDA0-- ------=_NextPart_001_0000_01C24452.2929FDA0 Content-Type: text/plain; name="interrupt.txt" Content-Disposition: attachment; filename="interrupt.txt" Content-Transfer-Encoding: quoted-printable Hi guys, I have two questions, please help. 1. in one book, there are both pfslowtimo(void *arg) and pffasttimo(void = *arg) in =20 uipc_domain.c, which will be called by timeout, one is called every 500ms= , the other is called every 200ms. I want to know how FreeBSD control the t= imeout? I want to the kernel how to know it is time to call pfslowtimo or pffastt= imo? 2. I have a data-line, which connet the COM2 with a special backplane(my = box's IDE disk attach by the backplane). I can scan the COM2's state to find whether the= IDE disk exist or not. I use the polling method to scan in user space. =20 I access '/dev/io' device and get the COM state from the interface addre= ss.I think this method is unefficient. I think when the COM status change, it should spring an interrupt, the k= erenl will ignore the interrupt default, right? I can write an interrupt program, or embed = my process in the kernel. But I have no idea how to start. how can I start my task? =20 Thank you! Best Regards Ouyang Kai ------=_NextPart_001_0000_01C24452.2929FDA0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 21:19:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C2B337B400 for ; Wed, 14 Aug 2002 21:19:11 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A47B343E6A for ; Wed, 14 Aug 2002 21:19:10 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 38901 invoked by uid 1000); 15 Aug 2002 04:19:12 -0000 Date: Wed, 14 Aug 2002 21:19:12 -0700 (PDT) From: Nate Lawson To: Julian Elischer Cc: D J Hawkey Jr , freebsd-hackers@freebsd.org Subject: Re: BSD and HP Pavilion computers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It was first supported in 3.3.6 when you load agp.ko. http://www.xfree86.org/3.3.6/i810.html However, I think the recommended config is 4.2.0 for today's agp.ko: http://www.xfree86.org/4.2.0/i810.html I had trouble getting 3.3.6 working with any combination of intel/old linux agp.ko on Linux but have had no problems with FreeBSD, 4.2.0, and the integrated agp kernel module. -Nate On Wed, 14 Aug 2002, Julian Elischer wrote: > Any idea how to set up XFree86 V3.3.6 for the i810 VGA controller? > > > On Wed, 14 Aug 2002, D J Hawkey Jr wrote: > > > In article , > > julian@elischer.org writes: > > > > > > Has anyone managed to get dual-boot working on an HP Pavilion? > > > > > > (Or even a non dual boot?) > > > > Yup. I have a Pavilion 7840. I used FreeBSD's FIPS (I think that's what > > it's called) to cut the Windoze(tm) partition in half, and installed > > FreeBSD in the new space. FreeBSD's boot manager works fine. > > > > > Julian > > > > You have a problem, or just looking ahead? > > Dave > > > > -- > > > > Windows: "Where do you want to go today?" > > Linux: "Where do you want to go tomorrow?" > > FreeBSD: "Are you guys coming, or what?" > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 14 23:51:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAAB337B400 for ; Wed, 14 Aug 2002 23:51:19 -0700 (PDT) Received: from hotmail.com (oe51.pav0.hotmail.com [64.4.32.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2FB43E3B for ; Wed, 14 Aug 2002 23:51:19 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Aug 2002 23:51:19 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: Subject: About 'sysctl' routine problem? Date: Thu, 15 Aug 2002 14:51:09 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C2446B.31044CB0" Message-ID: X-OriginalArrivalTime: 15 Aug 2002 06:51:19.0283 (UTC) FILETIME=[28BFBC30:01C24428] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0002_01C2446B.31044CB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi guys, In the "TCP/IP Illustrated, Volume2: The Implementation" book, there give 'ioctl' and 'sysctl' in the kernel routine. ioctl -> sooioctl->(interface)ifioctl..... sysctl-> net_sysctl -> pr_sysctl -> ip_sysctl.... Now, I can find the corresponding code about 'ioctl' routine. But, I could not find any code about 'sysctl', why? how the FreeBSD realize the corresponding functions? Thank you! =20 Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://exp= lorer.msn.com ------=_NextPart_001_0002_01C2446B.31044CB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi guys,
&n= bsp; In the "TCP/IP Illustrated, Volume2: The Implementation" book,
th= ere give 'ioctl' and 'sysctl' in the kernel routine.
  ioctl ->= ; sooioctl->(interface)ifioctl.....
  sysctl-> net_sysctl -= > pr_sysctl -> ip_sysctl....
  Now, I can find the correspo= nding code about 'ioctl' routine.
But, I could not find any code about= 'sysctl', why?
how the FreeBSD realize the corresponding functions?
   Thank you!
 
Best Regards
Ouyang Kai=
 

Get more from t= he Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0002_01C2446B.31044CB0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 0:19:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C198837B400 for ; Thu, 15 Aug 2002 00:19:29 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DEFB43E70 for ; Thu, 15 Aug 2002 00:19:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0107.cvx40-bradley.dialup.earthlink.net ([216.244.42.107] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fEug-0000lD-00; Thu, 15 Aug 2002 00:19:23 -0700 Message-ID: <3D5B52EA.2594A98@mindspring.com> Date: Thu, 15 Aug 2002 00:06:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ouyang kai Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: About 'sysctl' routine problem? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ouyang kai wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable | Hi guys, | In the "TCP/IP Illustrated, Volume2: The Implementation" book, | there give 'ioctl' and 'sysctl' in the kernel routine. | ioctl -> sooioctl->(interface)ifioctl..... | sysctl-> net_sysctl -> pr_sysctl -> ip_sysctl.... | Now, I can find the corresponding code about 'ioctl' routine. | But, I could not find any code about 'sysctl', why? | how the FreeBSD realize the corresponding functions? | Thank you! The book is not applicable to the sysctl implementation. Pick a sysctl by the terminal name, search for the name in the source code, and then expand the macros. Once again, we are talking about linker sets. This is a little more complex, though, since you have to take the "boot environment" into account, as well (the boot environment is the basis for a preinitialized sysctl space contents, seperate from the code you see in the kernel itself for the declarations of specific sysctl OIDs that are added to the ones exported before the kernel is even really started. Research: TUNABLE_INT_DECL TUNABLE_INT_FETCH SYSCTL_DECL SYSCTL_NODE SYSCTL_INT SYSCTL_STRUCT SYSCTL_PROC Start with: cd /usr/src/sys/netinet grep SYSCTL * And looking at: /usr/src/sys/sys/sysctl.h See also: SI_SUB_TUNABLES = 0x0700000, /* establish tunable values */ in /usr/src/sys/sys/kernel.h. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 0:35:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4221F37B400 for ; Thu, 15 Aug 2002 00:35:20 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A0643E72 for ; Thu, 15 Aug 2002 00:35:19 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g7F7Y1D07339 for ; Thu, 15 Aug 2002 00:34:01 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Thu, 15 Aug 2002 00:34:00 -0700 (PDT) From: Patrick Thomas To: Subject: possible to expand a file for vn-device FS usage ? Message-ID: <20020815002812.S58763-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a 500meg file that I dd'd and have mounted as a vn-device filesystem. I would like to increase this to 1gig, however it is very time consuming to do a dump of the FS to a file, dd a new larger one, then do a restore (I have many special files in the FS, thus the need for dump). Is there a procedure wherein I can just unmount the file, expand it, then remount it ? I realize some trickery is needed as the newfs originally done on the file will then be wrong, etc. - possibly disklabel as well - but I am willing to run a new disklabel and/or newfs command on the file in addition to expanding it. Any suggestions on how to expand that file without doing the dump/restore steps ? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 0:48: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D0937B400 for ; Thu, 15 Aug 2002 00:48:02 -0700 (PDT) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9395A43EB2 for ; Thu, 15 Aug 2002 00:47:56 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.4/8.12.3) with ESMTP id g7F7lUgD002122; Thu, 15 Aug 2002 17:17:31 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: possible to expand a file for vn-device FS usage ? From: "Daniel O'Connor" To: Patrick Thomas Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020815002812.S58763-100000@utility.clubscholarship.com> References: <20020815002812.S58763-100000@utility.clubscholarship.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Aug 2002 17:17:30 +0930 Message-Id: <1029397652.36834.88.camel@chowder.gsoft.com.au> Mime-Version: 1.0 X-Spam-Score: -3.5 () IN_REP_TO,SUBJ_ENDS_IN_Q_MARK X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2002-08-15 at 17:04, Patrick Thomas wrote: > Any suggestions on how to expand that file without doing the dump/restore > steps ? man 8 growfs perchance? :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 0:58:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66E3B37B400 for ; Thu, 15 Aug 2002 00:58:31 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C37143E6E for ; Thu, 15 Aug 2002 00:58:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0107.cvx40-bradley.dialup.earthlink.net ([216.244.42.107] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fFWR-00004S-00; Thu, 15 Aug 2002 00:58:23 -0700 Message-ID: <3D5B5BB7.BC424E72@mindspring.com> Date: Thu, 15 Aug 2002 00:43:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel O'Connor Cc: Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: possible to expand a file for vn-device FS usage ? References: <20020815002812.S58763-100000@utility.clubscholarship.com> <1029397652.36834.88.camel@chowder.gsoft.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > On Thu, 2002-08-15 at 17:04, Patrick Thomas wrote: > > Any suggestions on how to expand that file without doing the dump/restore > > steps ? > > man 8 growfs perchance? :) You can unmount it, grow the underlying file with: dd if-/dev/zero bs=XXX,count=XXX >> filename and *THEN* use growfs(8) on it. Doing this will leave the allocation layout in the same state that it is at present, so the bottom half of the FS will end up fragmented, even though there is free space at the top (FS growing does not equally redistribute the FS content into the newly enlarged space). The best approach is the same as it would be for a device: dump and restore the FS from the old image to the new. In the vn device case, you could just create a new empty FS of the necessary size, and dump from the old piped to a restore of the new. If you can live with the internal fragmentation, use growfs(8); if you can't, use dump/restore. IMO, you will have less potential for future problems if you use dump/restore. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 2:25:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22A3B37B400 for ; Thu, 15 Aug 2002 02:25:23 -0700 (PDT) Received: from hotmail.com (oe17.pav0.hotmail.com [64.4.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99D2743E70 for ; Thu, 15 Aug 2002 02:25:22 -0700 (PDT) (envelope-from oykai@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Aug 2002 02:25:22 -0700 X-Originating-IP: [210.12.61.105] From: "ouyang kai" To: "Lambert Terry" , Subject: Re: About 'sysctl' routine problem? Date: Thu, 15 Aug 2002 17:25:12 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 6.10.0016.1624 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0000_01C24480.B630A860" Message-ID: X-OriginalArrivalTime: 15 Aug 2002 09:25:22.0551 (UTC) FILETIME=[AE2A8070:01C2443D] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C24480.B630A860 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0001_01C24480.B630A860" ------=_NextPart_002_0001_01C24480.B630A860 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Terry, Thank you! >Once again, we are talking about linker sets. This is a little >more complex, though, since you have to take the "boot environment" >into account, as well (the boot environment is the basis for a >preinitialized sysctl space contents, seperate from the code you >see in the kernel itself for the declarations of specific sysctl >OIDs that are added to the ones exported before the kernel is even >really started. in kern_mib.c: SYSCTL_NODE(, CTL_NET, net, CTLFLAG_RW, 0, "Network, (see socket.h)"); --> struct sysctl_oid_list sysctl_net_children; static struct sysctl_oid sysctl__net =3D { =20 &sysctl_children, { 0 }, =20 CTL_NET, CTLTYPE_NODE|CTLFLAG_RW, (void*)&sysctl_net_children, =20 0, "net", 0, "N", 0 }; =20 DATA_SET(sysctl_set, sysctl__net); It seem like the SYSINIT macro. > TUNABLE_INT_DECL > TUNABLE_INT_FETCH > SYSCTL_DECL > SYSCTL_NODE > SYSCTL_INT > SYSCTL_STRUCT > SYSCTL_PROC Whether do they register also in mi_startup() like other devices, when t= he 'sipp' is looped to 'SI_SUB_TUNABLES'? You said some specific sysctl OIDs can be added before the kernel is eve= n really started, I want to know when they will be added? Could you give me an example? =20 I try to trace some routine from the 'ifconfig' program source code. The following code is copied from 'ifconfig' program: mib[0] =3D CTL_NET; mib[1] =3D PF_ROUTE; mib[2] =3D 0; mib[3] =3D 0; /* address family */ mib[4] =3D NET_RT_IFLIST; mib[5] =3D 0; /* if particular family specified, only ask about it */ if (afp) mib[3] =3D afp->af_af; if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) errx(1, "iflist-sysctl-estimate"); From the SYSCTL_NODE(_net, PF_ROUTE, routetable, CTLFLAG_RD, sysctl_rtsoc= k, ""); we can know the RF_ROUTE is the 'net's children', and its' handler is sys= ctl_rtsock. So, the kernel will call sysctl_rtsock, right? in sysctl_rtsock function: case NET_RT_IFLIST: error =3D sysctl_iflist(af, &w); So, this time, the kernel will call sysctl_iflist finally, right? But I have some wonder how the 'sysctl' command transfer from user space = to kernel space? I find the line in sysproto.h: int __sysctl __P((struct proc *, struct sysctl_args *)); I think whether the 'sysctl' is changed to '__sysctl' in kernel space? If that is right, the __sysctl is how conect with sysctl_rtsock? Thank you very much!:-) Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://exp= lorer.msn.com ------=_NextPart_002_0001_01C24480.B630A860 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Terry,  Thank you!
>Once again, we are talking about linker= sets.  This is a little
>more complex, though, since you have= to take the "boot environment"
>into account, as well (the boot en= vironment is the basis for a
>preinitialized sysctl space contents,= seperate from the code you
>see in the kernel itself for the decla= rations of specific sysctl
>OIDs that are added to the ones exporte= d before the kernel is even
>really started.
 in ke= rn_mib.c:
SYSCTL_NODE(, CTL_NET,   net,    CT= LFLAG_RW, 0,
 "Network, (see socket.h)");
-->
struct sys= ctl_oid_list sysctl_net_children;
static struct sysctl_oid sysctl__net= =3D {  
 &sysctl_children, { 0 },  &nbs= p;
 CTL_NET, CTLTYPE_NODE|CTLFLAG_RW, (void*)&sysctl_net_chi= ldren,
 0, "net", 0, "N", 0 }; 
DATA_SET(sysctl_set, sys= ctl__net);
It seem like the SYSINIT macro.
> TUNABL= E_INT_DECL
> TUNABLE_INT_FETCH
> SYSCTL_DECL
>= ; SYSCTL_NODE
> SYSCTL_INT
> SYSCTL_STRUCT
= > SYSCTL_PROC
 Whether do they register also in mi_startu= p() like other devices, when the
'sipp' is looped to 'SI_SUB_TUNABLES'= ?
 You said some specific sysctl OIDs can be added before the ker= nel is even really started,
I want to know when they will be added? Co= uld you give me an example?
 
I try to trace some routine fro= m the 'ifconfig' program source code.
The following code is copied fro= m 'ifconfig' program:
 mib[0] =3D CTL_NET;
 mib[1] =3D PF= _ROUTE;
 mib[2] =3D 0;
 mib[3] =3D 0; /* address fam= ily */
 mib[4] =3D NET_RT_IFLIST;
 mib[5] =3D 0;
 /* if particular family specified, only ask about it */
 = ;if (afp)
  mib[3] =3D afp->af_af;
 if (s= ysctl(mib, 6, NULL, &needed, NULL, 0) < 0)
  errx(1, = "iflist-sysctl-estimate");
From the SYSCTL_NODE(_net, PF_ROUTE= , routetable, CTLFLAG_RD, sysctl_rtsock, "");
we can know the RF_ROUTE= is the 'net's children', and its' handler is sysctl_rtsock.
So, the k= ernel will call sysctl_rtsock, right?
in sysctl_rtsock function:
&n= bsp;case NET_RT_IFLIST:
  error =3D sysctl_iflist(af, &w= );
So, this time, the kernel will call sysctl_iflist finally, right?But I have some wonder how the 'sysctl' command transfer from user spac= e to kernel space?
I find the line in sysproto.h:
int __sysctl= __P((struct proc *, struct sysctl_args *));
I think whether the 'sysc= tl' is changed to '__sysctl' in kernel space?
If that is right, the __= sysctl is how conect with sysctl_rtsock?
   Thank yo= u very much!:-)
Best Regards
Ouyang Kai
=
Get more from the Web. FREE MSN Explorer download : = http://explorer.msn.com

------=_NextPart_002_0001_01C24480.B630A860-- ------=_NextPart_001_0000_01C24480.B630A860 Content-Type: text/plain; name="sysctl2.txt" Content-Disposition: attachment; filename="sysctl2.txt" Content-Transfer-Encoding: quoted-printable Dear Terry, Thank you! >Once again, we are talking about linker sets. This is a little >more complex, though, since you have to take the "boot environment" >into account, as well (the boot environment is the basis for a >preinitialized sysctl space contents, seperate from the code you >see in the kernel itself for the declarations of specific sysctl >OIDs that are added to the ones exported before the kernel is even >really started. in kern_mib.c: SYSCTL_NODE(, CTL_NET, net, CTLFLAG_RW, 0, "Network, (see socket.h)"); --> struct sysctl_oid_list sysctl_net_children; static struct sysctl_oid sysctl__net =3D { =20 &sysctl_children, { 0 }, =20 CTL_NET, CTLTYPE_NODE|CTLFLAG_RW, (void*)&sysctl_net_children, =20 0, "net", 0, "N", 0 }; =09 DATA_SET(sysctl_set, sysctl__net); It seem like the SYSINIT macro. > TUNABLE_INT_DECL > TUNABLE_INT_FETCH > SYSCTL_DECL > SYSCTL_NODE > SYSCTL_INT > SYSCTL_STRUCT > SYSCTL_PROC Whether do they register also in mi_startup() like other devices, when t= he 'sipp' is looped to 'SI_SUB_TUNABLES'? You said some specific sysctl OIDs can be added before the kernel is eve= n really started, I want to know when they will be added? Could you give me an example? =20 I try to trace some routine from the 'ifconfig' program source code. The following code is copied from 'ifconfig' program: mib[0] =3D CTL_NET; mib[1] =3D PF_ROUTE; mib[2] =3D 0; mib[3] =3D 0; /* address family */ mib[4] =3D NET_RT_IFLIST; mib[5] =3D 0; /* if particular family specified, only ask about it */ if (afp) mib[3] =3D afp->af_af; if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) errx(1, "iflist-sysctl-estimate"); From the SYSCTL_NODE(_net, PF_ROUTE, routetable, CTLFLAG_RD, sysctl_rtsoc= k, ""); we can know the RF_ROUTE is the 'net's children', and its' handler is sys= ctl_rtsock. So, the kernel will call sysctl_rtsock, right? in sysctl_rtsock function: case NET_RT_IFLIST: error =3D sysctl_iflist(af, &w); So, this time, the kernel will call sysctl_iflist finally, right? But I have some wonder how the 'sysctl' command transfer from user space = to kernel space? I find the line in sysproto.h: int __sysctl __P((struct proc *, struct sysctl_args *)); I think whether the 'sysctl' is changed to '__sysctl' in kernel space? If that is right, the __sysctl is how conect with sysctl_rtsock? Thank you very much!:-) Best Regards Ouyang Kai ------=_NextPart_001_0000_01C24480.B630A860-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 6:54:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1CB637B400; Thu, 15 Aug 2002 06:53:46 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BC8943E6A; Thu, 15 Aug 2002 06:53:46 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0101.cvx40-bradley.dialup.earthlink.net ([216.244.42.101] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fL4E-0004iB-00; Thu, 15 Aug 2002 06:53:39 -0700 Message-ID: <3D5BACD5.405A71DF@mindspring.com> Date: Thu, 15 Aug 2002 06:29:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org, jlemon@freebsd.org Subject: PATCHES: Support for kqueue for System V message queues Content-Type: multipart/mixed; boundary="------------AB3423182009884E14B98646" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------AB3423182009884E14B98646 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I got really tired of this support not eng there, so I have added it, with these patches (attached -- for weenies, I have included a unidiff, at the end, but you should really use the context diff when you port the code to -current... ;-)). The "data" part returns the number of messages pending on the message queue being filtered on (sorry, but returning the message type is leftas an exercise for the student, since the note value is muxed inwth the hint, and there's not a third parameter to KNOTE(), knote(), or f_event()). I have included an example receiver, and an example sender. The most interesting test is to send a couple of messages, and then start the receiver, and send another one. Note that I do not trigger an event for messages already in the queue, as this would have required substantial changes to the number of members in the f_ops vector, and refactoring of much of the code in kern_event.c to take the new entry vectors into account. Basically, it acts like signals (EV_CLEAR is set automatically on f_attach(), but can be explicitly reset with a second call). -- Terry --------------AB3423182009884E14B98646 Content-Type: text/plain; charset=us-ascii; name="kqueue.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kqueue.diff" Index: kern/kern_event.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_event.c,v retrieving revision 1.2.2.8 diff -c -r1.2.2.8 kern_event.c *** kern/kern_event.c 14 Dec 2001 19:24:42 -0000 1.2.2.8 --- kern/kern_event.c 15 Aug 2002 11:33:50 -0000 *************** *** 122,127 **** --- 122,128 ---- extern struct filterops aio_filtops; extern struct filterops sig_filtops; + extern struct filterops sysvmsg_filtops; /* * Table for for all system-defined filters. *************** *** 134,139 **** --- 135,141 ---- &proc_filtops, /* EVFILT_PROC */ &sig_filtops, /* EVFILT_SIGNAL */ &timer_filtops, /* EVFILT_TIMER */ + &sysvmsg_filtops, /* EVFILT_SYSVMSG */ }; static int Index: kern/sysv_msg.c =================================================================== RCS file: /usr/cvs/src/sys/kern/sysv_msg.c,v retrieving revision 1.23.2.3 diff -c -r1.23.2.3 sysv_msg.c *** kern/sysv_msg.c 1 Nov 2000 17:58:06 -0000 1.23.2.3 --- kern/sysv_msg.c 15 Aug 2002 13:37:16 -0000 *************** *** 40,45 **** --- 40,46 ---- #undef MSG_DEBUG_OK static void msg_freehdr __P((struct msg *msghdr)); + static struct msqid_ds *msqid_to_msqptr __P((int umsqid)); /* XXX casting to (sy_call_t *) is bogus, as usual. */ static sy_call_t *msgcalls[] = { *************** *** 112,118 **** /* 0..(MSGSEG-1) -> index of next segment */ }; ! #define MSG_LOCKED 01000 /* Is this msqid_ds locked? */ static int nfree_msgmaps; /* # of free map entries */ static short free_msgmaps; /* head of linked list of free map entries */ --- 113,124 ---- /* 0..(MSGSEG-1) -> index of next segment */ }; ! struct i_msqid_ds { ! struct msqid_ds e; /* externally visable */ ! struct klist q_klist; /* filters on this message queue */ ! }; ! ! #define MSG_LOCKED 01000 /* Is this i_msqid_ds locked? */ static int nfree_msgmaps; /* # of free map entries */ static short free_msgmaps; /* head of linked list of free map entries */ *************** *** 120,126 **** static char *msgpool; /* MSGMAX byte long msg buffer pool */ static struct msgmap *msgmaps; /* MSGSEG msgmap structures */ static struct msg *msghdrs; /* MSGTQL msg headers */ ! static struct msqid_ds *msqids; /* MSGMNI msqid_ds struct's */ static void msginit(dummy) --- 126,132 ---- static char *msgpool; /* MSGMAX byte long msg buffer pool */ static struct msgmap *msgmaps; /* MSGSEG msgmap structures */ static struct msg *msghdrs; /* MSGTQL msg headers */ ! static struct i_msqid_ds *i_msqids; /* MSGMNI i_msqid_ds struct's */ static void msginit(dummy) *************** *** 137,145 **** msghdrs = malloc(sizeof(struct msg) * msginfo.msgtql, M_MSG, M_WAITOK); if (msghdrs == NULL) panic("msghdrs is NULL"); ! msqids = malloc(sizeof(struct msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); ! if (msqids == NULL) ! panic("msqids is NULL"); /* * msginfo.msgssz should be a power of two for efficiency reasons. --- 143,151 ---- msghdrs = malloc(sizeof(struct msg) * msginfo.msgtql, M_MSG, M_WAITOK); if (msghdrs == NULL) panic("msghdrs is NULL"); ! i_msqids = malloc(sizeof(struct i_msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); ! if (i_msqids == NULL) ! panic("i_msqids is NULL"); /* * msginfo.msgssz should be a power of two for efficiency reasons. *************** *** 183,195 **** } free_msghdrs = &msghdrs[0]; ! if (msqids == NULL) ! panic("msqids is NULL"); for (i = 0; i < msginfo.msgmni; i++) { ! msqids[i].msg_qbytes = 0; /* implies entry is available */ ! msqids[i].msg_perm.seq = 0; /* reset to a known value */ ! msqids[i].msg_perm.mode = 0; } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) --- 189,201 ---- } free_msghdrs = &msghdrs[0]; ! if (i_msqids == NULL) ! panic("i_msqids is NULL"); for (i = 0; i < msginfo.msgmni; i++) { ! i_msqids[i].e.msg_qbytes = 0; /* implies entry is available */ ! i_msqids[i].e.msg_perm.seq = 0; /* reset to a known value */ ! i_msqids[i].e.msg_perm.mode = 0; } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) *************** *** 243,248 **** --- 249,288 ---- free_msghdrs = msghdr; } + static struct msqid_ds * + msqid_to_msqptr(umsqid) + int umsqid; + { + int msqid; + struct msqid_ds *msqptr = 0; + + msqid = IPCID_TO_IX(umsqid); + + if (msqid < 0 || msqid >= msginfo.msgmni) { + #ifdef MSG_DEBUG_OK + printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, + msginfo.msgmni); + #endif + } else { + + msqptr = (struct msqid_ds *)&i_msqids[msqid]; + + if (msqptr->msg_qbytes == 0) { + #ifdef MSG_DEBUG_OK + printf("no such msqid\n"); + #endif + msqptr = NULL; + } else if (msqptr->msg_perm.seq != IPCID_TO_SEQ(umsqid)) { + #ifdef MSG_DEBUG_OK + printf("wrong sequence number\n"); + msqptr = NULL; + #endif + } + } + + return(msqptr); + } + #ifndef _SYS_SYSPROTO_H_ struct msgctl_args { int msqid; *************** *** 256,262 **** struct proc *p; register struct msgctl_args *uap; { - int msqid = uap->msqid; int cmd = uap->cmd; struct msqid_ds *user_msqptr = uap->buf; int rval, eval; --- 296,301 ---- *************** *** 270,299 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif return(EINVAL); - } - - msqptr = &msqids[msqid]; - - if (msqptr->msg_qbytes == 0) { - #ifdef MSG_DEBUG_OK - printf("no such msqid\n"); - #endif - return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { - #ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); - #endif - return(EINVAL); - } eval = 0; rval = 0; --- 309,316 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); eval = 0; rval = 0; *************** *** 305,310 **** --- 322,332 ---- struct msg *msghdr; if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_M))) return(eval); + + /* notify intent before actually removing message queue */ + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_IPC_RMID | uap->msqid); + /* Free the message headers */ msghdr = msqptr->msg_first; while (msghdr != NULL) { *************** *** 411,417 **** if (key != IPC_PRIVATE) { for (msqid = 0; msqid < msginfo.msgmni; msqid++) { ! msqptr = &msqids[msqid]; if (msqptr->msg_qbytes != 0 && msqptr->msg_perm.key == key) break; --- 433,439 ---- if (key != IPC_PRIVATE) { for (msqid = 0; msqid < msginfo.msgmni; msqid++) { ! msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes != 0 && msqptr->msg_perm.key == key) break; *************** *** 448,454 **** * they are copying the message in/out. We can't * re-use the entry until they release it. */ ! msqptr = &msqids[msqid]; if (msqptr->msg_qbytes == 0 && (msqptr->msg_perm.mode & MSG_LOCKED) == 0) break; --- 470,476 ---- * they are copying the message in/out. We can't * re-use the entry until they release it. */ ! msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes == 0 && (msqptr->msg_perm.mode & MSG_LOCKED) == 0) break; *************** *** 480,485 **** --- 502,508 ---- msqptr->msg_stime = 0; msqptr->msg_rtime = 0; msqptr->msg_ctime = time_second; + bzero(&((struct i_msqid_ds *)msqptr)->q_klist, sizeof(struct klist)); } else { #ifdef MSG_DEBUG_OK printf("didn't find it and wasn't asked to create it\n"); *************** *** 507,513 **** struct proc *p; register struct msgsnd_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; int msgflg = uap->msgflg; --- 530,535 ---- *************** *** 515,520 **** --- 537,543 ---- register struct msqid_ds *msqptr; register struct msg *msghdr; short next; + int s; #ifdef MSG_DEBUG_OK printf("call to msgsnd(%d, 0x%x, %d, %d)\n", msqid, user_msgp, msgsz, *************** *** 524,552 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif return(EINVAL); - } - - msqptr = &msqids[msqid]; - if (msqptr->msg_qbytes == 0) { - #ifdef MSG_DEBUG_OK - printf("no such message queue id\n"); - #endif - return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { - #ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); - #endif - return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_W))) { #ifdef MSG_DEBUG_OK --- 547,554 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_W))) { #ifdef MSG_DEBUG_OK *************** *** 812,817 **** --- 814,824 ---- msqptr->msg_lspid = p->p_pid; msqptr->msg_stime = time_second; + s = splhigh(); + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_SYSVMSG | uap->msqid); + splx(s); + wakeup((caddr_t)msqptr); p->p_retval[0] = 0; return(0); *************** *** 832,838 **** struct proc *p; register struct msgrcv_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; long msgtyp = uap->msgtyp; --- 839,844 ---- *************** *** 851,879 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif ! return(EINVAL); ! } ! ! msqptr = &msqids[msqid]; ! if (msqptr->msg_qbytes == 0) { ! #ifdef MSG_DEBUG_OK ! printf("no such message queue id\n"); ! #endif return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { - #ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); - #endif - return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_R))) { #ifdef MSG_DEBUG_OK --- 857,864 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_R))) { #ifdef MSG_DEBUG_OK *************** *** 1099,1101 **** --- 1084,1176 ---- p->p_retval[0] = msgsz; return(0); } + + static int + filt_sysvmsgattach(struct knote *kn) + { + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return (ESRCH); + + kn->kn_flags |= EV_CLEAR; /* automatically set */ + + /* XXX locking? this might compete with another process. */ + SLIST_INSERT_HEAD(&i_msqptr->q_klist, kn, kn_selnext); + + return (0); + } + + /* + * The knote may be attached to a message queue which is deleted out + * from under us by another process, leaving nothing for the knote to + * be attached to. So when the ,essage queue is deleted, the knote + * is marked as DETACHED and also flagged as ONESHOT so it will be + * deleted when read out. However, as part of the knote deletion, + * this routine is called, so a check is needed to avoid actually + * performing a detach, because the original message queue does not + * exist any more. Note that reusing the queue ID will bzero the list + * head, orphaning the events which were linked to it, so this does + * not have to be tracked (thought it seems a bit messy, this is what + * kqueue already does for exiting processes, FWIW). + */ + static void + filt_sysvmsgdetach(struct knote *kn) + { + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if (kn->kn_status & KN_DETACHED) + return; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return; + + /* XXX locking? this might compete with another process. */ + SLIST_REMOVE(&i_msqptr->q_klist, kn, knote, kn_selnext); + } + + /* + * Handle events on a given message queue object; called once for + * each object. + */ + static int + filt_sysvmsg(struct knote *kn, long hint) + { + u_int event; + int msqid; + register struct msqid_ds *msqptr; + + /* + * mask data out of "hint". + */ + event = (u_int)(hint & NOTE_SVMCMASK); + msqid = (int)(hint & NOTE_SVMDMASK); + + if ((msqptr = msqid_to_msqptr(msqid)) == NULL) + return(0); + + /* + * if the user is interested in this event, record it. + */ + if (kn->kn_sfflags & event) + kn->kn_fflags |= event; + + switch( event) { + case NOTE_IPC_RMID: /* message queue is being removed */ + /* flag the event as finished */ + kn->kn_status |= KN_DETACHED; + kn->kn_flags |= (EV_EOF | EV_ONESHOT); + break; + + case NOTE_SYSVMSG: /* a message was enqueued */ + kn->kn_data = msqptr->msg_qnum; /* # of messages now in queue */ + break; + } + + return (kn->kn_fflags != 0); + } + + struct filterops sysvmsg_filtops = + { 0, filt_sysvmsgattach, filt_sysvmsgdetach, filt_sysvmsg }; Index: sys/event.h =================================================================== RCS file: /usr/cvs/src/sys/sys/event.h,v retrieving revision 1.5.2.5 diff -c -r1.5.2.5 event.h *** sys/event.h 14 Dec 2001 19:21:22 -0000 1.5.2.5 --- sys/event.h 15 Aug 2002 12:59:53 -0000 *************** *** 36,43 **** #define EVFILT_PROC (-5) /* attached to struct proc */ #define EVFILT_SIGNAL (-6) /* attached to struct proc */ #define EVFILT_TIMER (-7) /* timers */ ! #define EVFILT_SYSCOUNT 7 #define EV_SET(kevp, a, b, c, d, e, f) do { \ (kevp)->ident = (a); \ --- 36,44 ---- #define EVFILT_PROC (-5) /* attached to struct proc */ #define EVFILT_SIGNAL (-6) /* attached to struct proc */ #define EVFILT_TIMER (-7) /* timers */ + #define EVFILT_SYSVMSG (-8) /* System V messages */ ! #define EVFILT_SYSCOUNT 8 #define EV_SET(kevp, a, b, c, d, e, f) do { \ (kevp)->ident = (a); \ *************** *** 103,108 **** --- 104,117 ---- #define NOTE_TRACK 0x00000001 /* follow across forks */ #define NOTE_TRACKERR 0x00000002 /* could not track child */ #define NOTE_CHILD 0x00000004 /* am a child process */ + + /* + * data/hint flags for EVFILT_SYSVMSG, shared with userspace + */ + #define NOTE_IPC_RMID 0x80000000 /* message queue deleted */ + #define NOTE_SYSVMSG 0x40000000 /* message enqueued */ + #define NOTE_SVMCMASK 0xf0000000 /* mask for hint bits */ + #define NOTE_SVMDMASK 0x000fffff /* mask for msqid */ /* * This is currently visible to userland to work around broken --------------AB3423182009884E14B98646 Content-Type: text/plain; charset=us-ascii; name="rcv.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rcv.c" #include #include #include #include #include #include #include #define KEYPATH "/root/RCALL/msg/foo" struct foo { long mtype; char mtext[ 80]; }; main() { key_t key; int msqid; struct foo foo; int i; struct kevent ev; struct timespec nullts = { 0, 0 }; int kq; int n; key = ftok( KEYPATH, 'b'); msqid = msgget( key, 0666 | IPC_CREAT); if( msqid == -1) { perror("msgget"); exit( 2); } printf( "Message queue %d\n", msqid); kq = kqueue(); EV_SET( &ev, msqid, EVFILT_SYSVMSG, EV_ADD | EV_ENABLE, NOTE_SYSVMSG, 0, 0); kevent( kq, &ev, 1, NULL, 0, &nullts); for(;;) { n = kevent(kq, NULL, 0, &ev, 1, NULL); if (n > 0) { printf( "%d messages pending on queue %d ", ev.data, ev.ident); } /* for each pending message, retrieve it */ for(i=0; i < ev.data; i++) { /* p3 = 0 :== receive any message */ if (msgrcv(msqid, &foo, sizeof(foo), 0, 0) == -1) { perror("msgsnd"); exit( 3); } printf( "snd says: '%s'\n", foo.mtext); } } /* NOTREACHED */ /* destroy queue */ msgctl(msqid, IPC_RMID, NULL); exit( 0); } --------------AB3423182009884E14B98646 Content-Type: text/plain; charset=us-ascii; name="snd.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="snd.c" #include #include #include #include #include #define KEYPATH "/root/RCALL/msg/foo" struct foo { long mtype; char mtext[ 80]; }; main() { key_t key; int msqid; struct foo foo; key = ftok( KEYPATH, 'b'); msqid = msgget( key, 0666 | IPC_CREAT); if( msqid == -1) { perror("msgget"); exit( 2); } foo.mtype = 75; strcpy( foo.mtext, "Hello, world!"); if ( msgsnd(msqid, &foo, sizeof(foo), 0) == -1) { perror("msgsnd"); exit( 3); } exit( 0); } --------------AB3423182009884E14B98646 Content-Type: text/plain; charset=us-ascii; name="kqueue.udiff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kqueue.udiff" Index: kern/kern_event.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_event.c,v retrieving revision 1.2.2.8 diff -u -r1.2.2.8 kern_event.c --- kern/kern_event.c 14 Dec 2001 19:24:42 -0000 1.2.2.8 +++ kern/kern_event.c 15 Aug 2002 11:33:50 -0000 @@ -122,6 +122,7 @@ extern struct filterops aio_filtops; extern struct filterops sig_filtops; +extern struct filterops sysvmsg_filtops; /* * Table for for all system-defined filters. @@ -134,6 +135,7 @@ &proc_filtops, /* EVFILT_PROC */ &sig_filtops, /* EVFILT_SIGNAL */ &timer_filtops, /* EVFILT_TIMER */ + &sysvmsg_filtops, /* EVFILT_SYSVMSG */ }; static int Index: kern/sysv_msg.c =================================================================== RCS file: /usr/cvs/src/sys/kern/sysv_msg.c,v retrieving revision 1.23.2.3 diff -u -r1.23.2.3 sysv_msg.c --- kern/sysv_msg.c 1 Nov 2000 17:58:06 -0000 1.23.2.3 +++ kern/sysv_msg.c 15 Aug 2002 13:37:16 -0000 @@ -40,6 +40,7 @@ #undef MSG_DEBUG_OK static void msg_freehdr __P((struct msg *msghdr)); +static struct msqid_ds *msqid_to_msqptr __P((int umsqid)); /* XXX casting to (sy_call_t *) is bogus, as usual. */ static sy_call_t *msgcalls[] = { @@ -112,7 +113,12 @@ /* 0..(MSGSEG-1) -> index of next segment */ }; -#define MSG_LOCKED 01000 /* Is this msqid_ds locked? */ +struct i_msqid_ds { + struct msqid_ds e; /* externally visable */ + struct klist q_klist; /* filters on this message queue */ +}; + +#define MSG_LOCKED 01000 /* Is this i_msqid_ds locked? */ static int nfree_msgmaps; /* # of free map entries */ static short free_msgmaps; /* head of linked list of free map entries */ @@ -120,7 +126,7 @@ static char *msgpool; /* MSGMAX byte long msg buffer pool */ static struct msgmap *msgmaps; /* MSGSEG msgmap structures */ static struct msg *msghdrs; /* MSGTQL msg headers */ -static struct msqid_ds *msqids; /* MSGMNI msqid_ds struct's */ +static struct i_msqid_ds *i_msqids; /* MSGMNI i_msqid_ds struct's */ static void msginit(dummy) @@ -137,9 +143,9 @@ msghdrs = malloc(sizeof(struct msg) * msginfo.msgtql, M_MSG, M_WAITOK); if (msghdrs == NULL) panic("msghdrs is NULL"); - msqids = malloc(sizeof(struct msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); - if (msqids == NULL) - panic("msqids is NULL"); + i_msqids = malloc(sizeof(struct i_msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); + if (i_msqids == NULL) + panic("i_msqids is NULL"); /* * msginfo.msgssz should be a power of two for efficiency reasons. @@ -183,13 +189,13 @@ } free_msghdrs = &msghdrs[0]; - if (msqids == NULL) - panic("msqids is NULL"); + if (i_msqids == NULL) + panic("i_msqids is NULL"); for (i = 0; i < msginfo.msgmni; i++) { - msqids[i].msg_qbytes = 0; /* implies entry is available */ - msqids[i].msg_perm.seq = 0; /* reset to a known value */ - msqids[i].msg_perm.mode = 0; + i_msqids[i].e.msg_qbytes = 0; /* implies entry is available */ + i_msqids[i].e.msg_perm.seq = 0; /* reset to a known value */ + i_msqids[i].e.msg_perm.mode = 0; } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) @@ -243,6 +249,40 @@ free_msghdrs = msghdr; } +static struct msqid_ds * +msqid_to_msqptr(umsqid) + int umsqid; +{ + int msqid; + struct msqid_ds *msqptr = 0; + + msqid = IPCID_TO_IX(umsqid); + + if (msqid < 0 || msqid >= msginfo.msgmni) { +#ifdef MSG_DEBUG_OK + printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, + msginfo.msgmni); +#endif + } else { + + msqptr = (struct msqid_ds *)&i_msqids[msqid]; + + if (msqptr->msg_qbytes == 0) { +#ifdef MSG_DEBUG_OK + printf("no such msqid\n"); +#endif + msqptr = NULL; + } else if (msqptr->msg_perm.seq != IPCID_TO_SEQ(umsqid)) { +#ifdef MSG_DEBUG_OK + printf("wrong sequence number\n"); + msqptr = NULL; +#endif + } + } + + return(msqptr); +} + #ifndef _SYS_SYSPROTO_H_ struct msgctl_args { int msqid; @@ -256,7 +296,6 @@ struct proc *p; register struct msgctl_args *uap; { - int msqid = uap->msqid; int cmd = uap->cmd; struct msqid_ds *user_msqptr = uap->buf; int rval, eval; @@ -270,30 +309,8 @@ if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); - msqid = IPCID_TO_IX(msqid); - - if (msqid < 0 || msqid >= msginfo.msgmni) { -#ifdef MSG_DEBUG_OK - printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, - msginfo.msgmni); -#endif + if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); - } - - msqptr = &msqids[msqid]; - - if (msqptr->msg_qbytes == 0) { -#ifdef MSG_DEBUG_OK - printf("no such msqid\n"); -#endif - return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { -#ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); -#endif - return(EINVAL); - } eval = 0; rval = 0; @@ -305,6 +322,11 @@ struct msg *msghdr; if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_M))) return(eval); + + /* notify intent before actually removing message queue */ + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_IPC_RMID | uap->msqid); + /* Free the message headers */ msghdr = msqptr->msg_first; while (msghdr != NULL) { @@ -411,7 +433,7 @@ if (key != IPC_PRIVATE) { for (msqid = 0; msqid < msginfo.msgmni; msqid++) { - msqptr = &msqids[msqid]; + msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes != 0 && msqptr->msg_perm.key == key) break; @@ -448,7 +470,7 @@ * they are copying the message in/out. We can't * re-use the entry until they release it. */ - msqptr = &msqids[msqid]; + msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes == 0 && (msqptr->msg_perm.mode & MSG_LOCKED) == 0) break; @@ -480,6 +502,7 @@ msqptr->msg_stime = 0; msqptr->msg_rtime = 0; msqptr->msg_ctime = time_second; + bzero(&((struct i_msqid_ds *)msqptr)->q_klist, sizeof(struct klist)); } else { #ifdef MSG_DEBUG_OK printf("didn't find it and wasn't asked to create it\n"); @@ -507,7 +530,6 @@ struct proc *p; register struct msgsnd_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; int msgflg = uap->msgflg; @@ -515,6 +537,7 @@ register struct msqid_ds *msqptr; register struct msg *msghdr; short next; + int s; #ifdef MSG_DEBUG_OK printf("call to msgsnd(%d, 0x%x, %d, %d)\n", msqid, user_msgp, msgsz, @@ -524,29 +547,8 @@ if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); - msqid = IPCID_TO_IX(msqid); - - if (msqid < 0 || msqid >= msginfo.msgmni) { -#ifdef MSG_DEBUG_OK - printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, - msginfo.msgmni); -#endif + if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); - } - - msqptr = &msqids[msqid]; - if (msqptr->msg_qbytes == 0) { -#ifdef MSG_DEBUG_OK - printf("no such message queue id\n"); -#endif - return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { -#ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); -#endif - return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_W))) { #ifdef MSG_DEBUG_OK @@ -812,6 +814,11 @@ msqptr->msg_lspid = p->p_pid; msqptr->msg_stime = time_second; + s = splhigh(); + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_SYSVMSG | uap->msqid); + splx(s); + wakeup((caddr_t)msqptr); p->p_retval[0] = 0; return(0); @@ -832,7 +839,6 @@ struct proc *p; register struct msgrcv_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; long msgtyp = uap->msgtyp; @@ -851,29 +857,8 @@ if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); - msqid = IPCID_TO_IX(msqid); - - if (msqid < 0 || msqid >= msginfo.msgmni) { -#ifdef MSG_DEBUG_OK - printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, - msginfo.msgmni); -#endif - return(EINVAL); - } - - msqptr = &msqids[msqid]; - if (msqptr->msg_qbytes == 0) { -#ifdef MSG_DEBUG_OK - printf("no such message queue id\n"); -#endif + if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { -#ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); -#endif - return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_R))) { #ifdef MSG_DEBUG_OK @@ -1099,3 +1084,93 @@ p->p_retval[0] = msgsz; return(0); } + +static int +filt_sysvmsgattach(struct knote *kn) +{ + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return (ESRCH); + + kn->kn_flags |= EV_CLEAR; /* automatically set */ + + /* XXX locking? this might compete with another process. */ + SLIST_INSERT_HEAD(&i_msqptr->q_klist, kn, kn_selnext); + + return (0); +} + +/* + * The knote may be attached to a message queue which is deleted out + * from under us by another process, leaving nothing for the knote to + * be attached to. So when the ,essage queue is deleted, the knote + * is marked as DETACHED and also flagged as ONESHOT so it will be + * deleted when read out. However, as part of the knote deletion, + * this routine is called, so a check is needed to avoid actually + * performing a detach, because the original message queue does not + * exist any more. Note that reusing the queue ID will bzero the list + * head, orphaning the events which were linked to it, so this does + * not have to be tracked (thought it seems a bit messy, this is what + * kqueue already does for exiting processes, FWIW). + */ +static void +filt_sysvmsgdetach(struct knote *kn) +{ + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if (kn->kn_status & KN_DETACHED) + return; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return; + + /* XXX locking? this might compete with another process. */ + SLIST_REMOVE(&i_msqptr->q_klist, kn, knote, kn_selnext); +} + +/* + * Handle events on a given message queue object; called once for + * each object. + */ +static int +filt_sysvmsg(struct knote *kn, long hint) +{ + u_int event; + int msqid; + register struct msqid_ds *msqptr; + + /* + * mask data out of "hint". + */ + event = (u_int)(hint & NOTE_SVMCMASK); + msqid = (int)(hint & NOTE_SVMDMASK); + + if ((msqptr = msqid_to_msqptr(msqid)) == NULL) + return(0); + + /* + * if the user is interested in this event, record it. + */ + if (kn->kn_sfflags & event) + kn->kn_fflags |= event; + + switch( event) { + case NOTE_IPC_RMID: /* message queue is being removed */ + /* flag the event as finished */ + kn->kn_status |= KN_DETACHED; + kn->kn_flags |= (EV_EOF | EV_ONESHOT); + break; + + case NOTE_SYSVMSG: /* a message was enqueued */ + kn->kn_data = msqptr->msg_qnum; /* # of messages now in queue */ + break; + } + + return (kn->kn_fflags != 0); +} + +struct filterops sysvmsg_filtops = + { 0, filt_sysvmsgattach, filt_sysvmsgdetach, filt_sysvmsg }; Index: sys/event.h =================================================================== RCS file: /usr/cvs/src/sys/sys/event.h,v retrieving revision 1.5.2.5 diff -u -r1.5.2.5 event.h --- sys/event.h 14 Dec 2001 19:21:22 -0000 1.5.2.5 +++ sys/event.h 15 Aug 2002 12:59:53 -0000 @@ -36,8 +36,9 @@ #define EVFILT_PROC (-5) /* attached to struct proc */ #define EVFILT_SIGNAL (-6) /* attached to struct proc */ #define EVFILT_TIMER (-7) /* timers */ +#define EVFILT_SYSVMSG (-8) /* System V messages */ -#define EVFILT_SYSCOUNT 7 +#define EVFILT_SYSCOUNT 8 #define EV_SET(kevp, a, b, c, d, e, f) do { \ (kevp)->ident = (a); \ @@ -103,6 +104,14 @@ #define NOTE_TRACK 0x00000001 /* follow across forks */ #define NOTE_TRACKERR 0x00000002 /* could not track child */ #define NOTE_CHILD 0x00000004 /* am a child process */ + +/* + * data/hint flags for EVFILT_SYSVMSG, shared with userspace + */ +#define NOTE_IPC_RMID 0x80000000 /* message queue deleted */ +#define NOTE_SYSVMSG 0x40000000 /* message enqueued */ +#define NOTE_SVMCMASK 0xf0000000 /* mask for hint bits */ +#define NOTE_SVMDMASK 0x000fffff /* mask for msqid */ /* * This is currently visible to userland to work around broken --------------AB3423182009884E14B98646-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 10:22:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E06137B401 for ; Thu, 15 Aug 2002 10:22:46 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5163343E42 for ; Thu, 15 Aug 2002 10:22:46 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g7FHLHG37409; Thu, 15 Aug 2002 10:21:17 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Thu, 15 Aug 2002 10:21:17 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: "Daniel O'Connor" , Subject: Re: possible to expand a file for vn-device FS usage ? In-Reply-To: <3D5B5BB7.BC424E72@mindspring.com> Message-ID: <20020815102056.J58763-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What is the negative effect of this fragmentation, and does it mean I won't be able to use all of the space that I added ? On Thu, 15 Aug 2002, Terry Lambert wrote: > Daniel O'Connor wrote: > > On Thu, 2002-08-15 at 17:04, Patrick Thomas wrote: > > > Any suggestions on how to expand that file without doing the dump/restore > > > steps ? > > > > man 8 growfs perchance? :) > > You can unmount it, grow the underlying file with: > > dd if-/dev/zero bs=XXX,count=XXX >> filename > > and *THEN* use growfs(8) on it. > > Doing this will leave the allocation layout in the same state > that it is at present, so the bottom half of the FS will end > up fragmented, even though there is free space at the top (FS > growing does not equally redistribute the FS content into the > newly enlarged space). > > The best approach is the same as it would be for a device: > dump and restore the FS from the old image to the new. In > the vn device case, you could just create a new empty FS of > the necessary size, and dump from the old piped to a restore > of the new. > > If you can live with the internal fragmentation, use growfs(8); > if you can't, use dump/restore. IMO, you will have less > potential for future problems if you use dump/restore. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 11:17: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E200737B400 for ; Thu, 15 Aug 2002 11:17:01 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FBE143E3B for ; Thu, 15 Aug 2002 11:17:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g7FIH0Y28940 for ; Thu, 15 Aug 2002 11:17:00 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 15 Aug 2002 11:17:00 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: hackers@freebsd.org Subject: question about Giant && Rebooting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm getting: syncing disks... 6 done Uptime: 1d1h5m30s lock order reversal 1st 0xc0edd008 shutdown_post_sync (shutdown_post_sync) @ /usr/src/sys/kern/kern_shutdown.c:341 2nd 0xc04759e0 Giant (Giant) @ /usr/src/sys/dev/isp/isp_freebsd.c:2067 but the code in question is: CAMLOCK_2_ISPLOCK(isp); error = isp_start((XS_T *) ccb); switch (error) { case CMD_QUEUED: ccb->ccb_h.status |= CAM_SIM_QUEUED; if (ccb->ccb_h.timeout != CAM_TIME_INFINITY) { u_int64_t ticks = (u_int64_t) hz; if (ccb->ccb_h.timeout == CAM_TIME_DEFAULT) ticks = 60 * 1000 * ticks; else ticks = ccb->ccb_h.timeout * hz; ticks = ((ticks + 999) / 1000) + hz + hz; if (ticks >= 0x80000000) { isp_prt(isp, ISP_LOGERR, "timeout overflow"); ticks = 0x7fffffff; } ccb->ccb_h.timeout_ch = timeout(isp_watchdog, (caddr_t)ccb, (int)ticks); } else { callout_handle_init(&ccb->ccb_h.timeout_ch); } ISPLOCK_2_CAMLOCK(isp); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<---- Where CAMLOCK_2_ISPLOCK supposedly drops Giant so it can pick up the ISP mutex and ISPLOCK_2_CAMLOCK drops the isp lock so it can reacquire Giant- this is because CAM is covered by Giant. So- why the whine? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 11:42:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C870937B400; Thu, 15 Aug 2002 11:42:27 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0694B43E42; Thu, 15 Aug 2002 11:42:25 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7FIgGZ43573; Thu, 15 Aug 2002 21:42:16 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7FIg9We001362; Thu, 15 Aug 2002 21:42:09 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D5BF635.3764C796@FreeBSD.org> Date: Thu, 15 Aug 2002 21:43:01 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: hackers@FreeBSD.org, net@FreeBSD.org Subject: Increasing size of if_flags field in the ifnet structure [patch for review] Content-Type: multipart/mixed; boundary="------------6E58B69EA83C65AC034DB0DB" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------6E58B69EA83C65AC034DB0DB Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Folks, When implementing ability to switch interface into promisc mode using ifconfig(8) I've stumbled into the problem with already exhausted space in the `short if_flags' field in the ifnet structure. I need to allocate one new flag, while we already have 16 IFF_* flags, and even one additional flag which is implemented using currently free if_ipending field of the said structure. Attached patch is aimed at increasing size of if_flags to 32 bits, as well as to clean-up if_ipending abuse. Granted, it will break backward ABI compatibility, but IMO it is not a big problem. Comments and suggestions are greatly appreciated. Thanks! -Maxim --------------6E58B69EA83C65AC034DB0DB Content-Type: text/plain; charset=koi8-r; name="if_flags.32bit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_flags.32bit.patch" Index: src/share/man/man4/netintro.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/netintro.4,v retrieving revision 1.20 diff -d -u -r1.20 netintro.4 --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 @@ -197,7 +197,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags; + int ifru_flags; int ifru_metric; int ifru_mtu; int ifru_phys; Index: src/share/man/man9/ifnet.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/ifnet.9,v retrieving revision 1.25 diff -d -u -r1.25 ifnet.9 --- src/share/man/man9/ifnet.9 10 Jan 2002 11:57:10 -0000 1.25 +++ src/share/man/man9/ifnet.9 15 Aug 2002 18:33:43 -0000 @@ -284,7 +284,7 @@ (Set by driver, decremented by generic watchdog code.) .It Va if_flags -.Pq Vt short +.Pq Vt int Flags describing operational parameters of this interface (see below). (Manipulated by both driver and generic code.) .It Va if_capabilities Index: src/sys/compat/linux/linux_ioctl.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_ioctl.c,v retrieving revision 1.86 diff -d -u -r1.86 linux_ioctl.c --- src/sys/compat/linux/linux_ioctl.c 26 Jun 2002 15:53:11 -0000 1.86 +++ src/sys/compat/linux/linux_ioctl.c 15 Aug 2002 18:33:45 -0000 @@ -1963,7 +1963,7 @@ { l_short flags; - flags = ifp->if_flags; + flags = ifp->if_flags & 0xffff; /* these flags have no Linux equivalent */ flags &= ~(IFF_SMART|IFF_OACTIVE|IFF_SIMPLEX| IFF_LINK0|IFF_LINK1|IFF_LINK2); Index: src/sys/dev/fxp/if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v retrieving revision 1.138 diff -d -u -r1.138 if_fxp.c --- src/sys/dev/fxp/if_fxp.c 9 Aug 2002 01:48:28 -0000 1.138 +++ src/sys/dev/fxp/if_fxp.c 15 Aug 2002 18:33:46 -0000 @@ -1193,7 +1193,7 @@ #ifdef DEVICE_POLLING struct ifnet *ifp = &sc->sc_if; - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) return; if (ether_poll_register(fxp_poll, ifp)) { /* disable interrupts */ @@ -1785,7 +1785,7 @@ * ... but only do that if we are not polling. And because (presumably) * the default is interrupts on, we need to disable them explicitly! */ - if ( ifp->if_ipending & IFF_POLLING ) + if ( ifp->if_flags & IFF_POLLING ) CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE); else #endif /* DEVICE_POLLING */ Index: src/sys/dev/vx/if_vx.c =================================================================== RCS file: /home/ncvs/src/sys/dev/vx/if_vx.c,v retrieving revision 1.36 diff -d -u -r1.36 if_vx.c --- src/sys/dev/vx/if_vx.c 20 Mar 2002 02:07:47 -0000 1.36 +++ src/sys/dev/vx/if_vx.c 15 Aug 2002 18:33:47 -0000 @@ -285,7 +285,7 @@ register struct ifnet *ifp = &sc->arpcom.ac_if; int i, j, k; char *reason, *warning; - static short prev_flags; + static int prev_flags; static char prev_conn = -1; if (prev_conn == -1) { Index: src/sys/kern/kern_poll.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_poll.c,v retrieving revision 1.9 diff -d -u -r1.9 kern_poll.c --- src/sys/kern/kern_poll.c 4 Aug 2002 21:00:49 -0000 1.9 +++ src/sys/kern/kern_poll.c 15 Aug 2002 18:33:48 -0000 @@ -383,7 +383,7 @@ for (i = 0 ; i < poll_handlers ; i++) { if (pr[i].handler && pr[i].ifp->if_flags & IFF_RUNNING) { - pr[i].ifp->if_ipending &= ~IFF_POLLING; + pr[i].ifp->if_flags &= ~IFF_POLLING; pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); } pr[i].handler=NULL; @@ -415,7 +415,7 @@ return 0; if ( !(ifp->if_flags & IFF_UP) ) /* must be up */ return 0; - if (ifp->if_ipending & IFF_POLLING) /* already polling */ + if (ifp->if_flags & IFF_POLLING) /* already polling */ return 0; s = splhigh(); @@ -440,7 +440,7 @@ pr[poll_handlers].handler = h; pr[poll_handlers].ifp = ifp; poll_handlers++; - ifp->if_ipending |= IFF_POLLING; + ifp->if_flags |= IFF_POLLING; splx(s); if (idlepoll_sleeping) wakeup(&idlepoll_sleeping); @@ -459,14 +459,14 @@ int i; mtx_lock(&Giant); - if ( !ifp || !(ifp->if_ipending & IFF_POLLING) ) { + if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { mtx_unlock(&Giant); return 0; } for (i = 0 ; i < poll_handlers ; i++) if (pr[i].ifp == ifp) /* found it */ break; - ifp->if_ipending &= ~IFF_POLLING; /* found or not... */ + ifp->if_flags &= ~IFF_POLLING; /* found or not... */ if (i == poll_handlers) { mtx_unlock(&Giant); printf("ether_poll_deregister: ifp not found!!!\n"); Index: src/sys/net/if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.144 diff -d -u -r1.144 if.c --- src/sys/net/if.c 1 Aug 2002 21:15:53 -0000 1.144 +++ src/sys/net/if.c 15 Aug 2002 18:33:48 -0000 @@ -1438,7 +1438,7 @@ struct ifnet *ifp; struct ifreq *ifr; int error; - short oif_flags; + int oif_flags; switch (cmd) { case SIOCGIFCONF: Index: src/sys/net/if.h =================================================================== RCS file: /home/ncvs/src/sys/net/if.h,v retrieving revision 1.73 diff -d -u -r1.73 if.h --- src/sys/net/if.h 25 May 2002 20:17:04 -0000 1.73 +++ src/sys/net/if.h 15 Aug 2002 18:33:49 -0000 @@ -139,14 +139,6 @@ #define IFF_LINK2 0x4000 /* per link layer defined bit */ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connection */ #define IFF_MULTICAST 0x8000 /* supports multicast */ - -/* - * The following flag(s) ought to go in if_flags, but we cannot change - * struct ifnet because of binary compatibility, so we store them in - * if_ipending, which is not used so far. - * If possible, make sure the value is not conflicting with other - * IFF flags, so we have an easier time when we want to merge them. - */ #define IFF_POLLING 0x10000 /* Interface is in polling mode. */ /* flags set internally only: */ @@ -232,7 +224,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags[2]; + int ifru_flags[2]; short ifru_index; int ifru_metric; int ifru_mtu; Index: src/sys/net/if_tap.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_tap.c,v retrieving revision 1.19 diff -d -u -r1.19 if_tap.c --- src/sys/net/if_tap.c 6 May 2002 19:31:28 -0000 1.19 +++ src/sys/net/if_tap.c 15 Aug 2002 18:33:49 -0000 @@ -654,7 +654,7 @@ struct ifnet *ifp = &tp->tap_if; struct tapinfo *tapp = NULL; int s; - short f; + int f; switch (cmd) { case TAPSIFINFO: @@ -728,7 +728,7 @@ break; case VMIO_SIOCSIFFLAGS: /* VMware/VMnet SIOCSIFFLAGS */ - f = *(short *)data; + f = *(int *)data; f &= 0x0fff; f &= ~IFF_CANTCHANGE; f |= IFF_UP; Index: src/sys/net/if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.48 diff -d -u -r1.48 if_var.h --- src/sys/net/if_var.h 14 Aug 2002 01:37:22 -0000 1.48 +++ src/sys/net/if_var.h 15 Aug 2002 18:33:50 -0000 @@ -138,7 +138,7 @@ u_short if_index; /* numeric abbreviation for this if */ short if_unit; /* sub-unit for lower level driver */ short if_timer; /* time 'til if_watchdog called */ - short if_flags; /* up/down, broadcast, etc. */ + int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ int if_ipending; /* interrupts pending */ Index: src/sys/net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.75 diff -d -u -r1.75 rtsock.c --- src/sys/net/rtsock.c 18 Jun 2002 07:42:01 -0000 1.75 +++ src/sys/net/rtsock.c 15 Aug 2002 18:33:51 -0000 @@ -757,7 +757,7 @@ return; ifm = mtod(m, struct if_msghdr *); ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; route_proto.sp_protocol = 0; @@ -958,7 +958,7 @@ ifm = (struct if_msghdr *)w->w_tmem; ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = info.rti_addrs; error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); Index: src/sys/netatm/atm_if.c =================================================================== RCS file: /home/ncvs/src/sys/netatm/atm_if.c,v retrieving revision 1.14 diff -d -u -r1.14 atm_if.c --- src/sys/netatm/atm_if.c 14 Jun 2002 16:59:38 -0000 1.14 +++ src/sys/netatm/atm_if.c 15 Aug 2002 18:33:51 -0000 @@ -1057,7 +1057,7 @@ break; case SIOCGIFFLAGS: - *(short *)data = ifp->if_flags; + *(int *)data = ifp->if_flags; break; case SIOCSIFFLAGS: Index: src/sys/netinet6/in6_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_var.h,v retrieving revision 1.10 diff -d -u -r1.10 in6_var.h --- src/sys/netinet6/in6_var.h 19 Apr 2002 04:46:22 -0000 1.10 +++ src/sys/netinet6/in6_var.h 15 Aug 2002 18:33:51 -0000 @@ -234,7 +234,7 @@ union { struct sockaddr_in6 ifru_addr; struct sockaddr_in6 ifru_dstaddr; - short ifru_flags; + int ifru_flags; int ifru_flags6; int ifru_metric; caddr_t ifru_data; Index: src/sys/nfsclient/bootp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/nfsclient/bootp_subr.c,v retrieving revision 1.41 diff -d -u -r1.41 bootp_subr.c --- src/sys/nfsclient/bootp_subr.c 31 May 2002 11:52:34 -0000 1.41 +++ src/sys/nfsclient/bootp_subr.c 15 Aug 2002 18:33:53 -0000 @@ -385,7 +385,7 @@ printf("%s%d flags %x, addr ", ifp->if_name, ifp->if_unit, - (unsigned short) ifp->if_flags); + ifp->if_flags); print_sin_addr((struct sockaddr_in *) ifa->ifa_addr); printf(", broadcast "); print_sin_addr((struct sockaddr_in *) ifa->ifa_dstaddr); Index: src/sys/pci/if_dc.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.74 diff -d -u -r1.74 if_dc.c --- src/sys/pci/if_dc.c 30 Jun 2002 22:05:46 -0000 1.74 +++ src/sys/pci/if_dc.c 15 Aug 2002 18:33:55 -0000 @@ -2483,7 +2483,7 @@ while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -2885,7 +2885,7 @@ DC_LOCK(sc); ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(dc_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, DC_IMR, 0x00000000); @@ -3265,7 +3265,7 @@ * the case of polling. Some cards (e.g. fxp) turn interrupts on * after a reset. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, DC_IMR, 0x00000000); else #endif Index: src/sys/pci/if_rl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.72 diff -d -u -r1.72 if_rl.c --- src/sys/pci/if_rl.c 30 Jul 2002 17:31:42 -0000 1.72 +++ src/sys/pci/if_rl.c 15 Aug 2002 18:33:56 -0000 @@ -1187,7 +1187,7 @@ while((CSR_READ_1(sc, RL_COMMAND) & RL_CMD_EMPTY_RXBUF) == 0) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1416,7 +1416,7 @@ ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(rl_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_2(sc, RL_IMR, 0x0000); @@ -1654,7 +1654,7 @@ /* * Disable interrupts if we are polling. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_2(sc, RL_IMR, 0); else /* otherwise ... */ #endif /* DEVICE_POLLING */ Index: src/sys/pci/if_sis.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sis.c,v retrieving revision 1.53 diff -d -u -r1.53 if_sis.c --- src/sys/pci/if_sis.c 7 Aug 2002 16:08:54 -0000 1.53 +++ src/sys/pci/if_sis.c 15 Aug 2002 18:33:57 -0000 @@ -1285,7 +1285,7 @@ while(SIS_OWNDESC(&sc->sis_ldata.sis_rx_list[i])) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1508,7 +1508,7 @@ SIS_LOCK(sc); #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(sis_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, SIS_IER, 0); @@ -1810,7 +1810,7 @@ * ... only enable interrupts if we are not polling, make sure * they are off otherwise. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, SIS_IER, 0); else #endif /* DEVICE_POLLING */ Index: src/usr.sbin/mrouted/config.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mrouted/config.c,v retrieving revision 1.14 diff -d -u -r1.14 config.c --- src/usr.sbin/mrouted/config.c 28 Aug 1999 01:17:03 -0000 1.14 +++ src/usr.sbin/mrouted/config.c 15 Aug 2002 18:33:57 -0000 @@ -32,7 +32,7 @@ register vifi_t vifi; int n; u_int32 addr, mask, subnet; - short flags; + int flags; int num_ifreq = 32; ifc.ifc_len = num_ifreq * sizeof(struct ifreq); --------------6E58B69EA83C65AC034DB0DB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 11:48:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C341C37B400; Thu, 15 Aug 2002 11:48:35 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46AB343E65; Thu, 15 Aug 2002 11:48:35 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7FImXwu022758; Thu, 15 Aug 2002 11:48:33 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7FImXWR022757; Thu, 15 Aug 2002 11:48:33 -0700 Date: Thu, 15 Aug 2002 11:48:33 -0700 From: Brooks Davis To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] Message-ID: <20020815114830.A21334@Odin.AC.HMC.Edu> References: <3D5BF635.3764C796@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5BF635.3764C796@FreeBSD.org>; from sobomax@FreeBSD.ORG on Thu, Aug 15, 2002 at 09:43:01PM +0300 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2002 at 09:43:01PM +0300, Maxim Sobolev wrote: >=20 > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. Sounds reasionable to me. We're going to break the API and ABI shortly for if_xname conversion anyway. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9W/d9XY6L6fI4GtQRAr3vAKCUSyK4GTaJ6GgWK9kQA3MEkr4vDwCgvaSc Js83NCI5VNTe5la9WqMTMFY= =Xecb -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 12: 0:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A48E37B401; Thu, 15 Aug 2002 12:00:24 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427D043E65; Thu, 15 Aug 2002 12:00:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815190021.UEJW1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 19:00:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA27740; Thu, 15 Aug 2002 11:51:00 -0700 (PDT) Date: Thu, 15 Aug 2002 11:50:59 -0700 (PDT) From: Julian Elischer To: Maxim Sobolev Cc: hackers@FreeBSD.org, net@FreeBSD.org Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <3D5BF635.3764C796@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG you cannot break ABIs in 4.x in 5.x it will probably be ok until (say) 5.1 or something. On Thu, 15 Aug 2002, Maxim Sobolev wrote: > Folks, > > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. > > Comments and suggestions are greatly appreciated. Thanks! > > -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 14:44:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C8337B400 for ; Thu, 15 Aug 2002 14:44:20 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED6E43E7B for ; Thu, 15 Aug 2002 14:44:20 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0454.cvx21-bradley.dialup.earthlink.net ([209.179.193.199] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fSPX-0005GE-00; Thu, 15 Aug 2002 14:44:08 -0700 Message-ID: <3D5C2070.4F2C17A3@mindspring.com> Date: Thu, 15 Aug 2002 14:43:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Daniel O'Connor , freebsd-hackers@FreeBSD.ORG Subject: Re: possible to expand a file for vn-device FS usage ? References: <20020815102056.J58763-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > What is the negative effect of this fragmentation, and does it mean I > won't be able to use all of the space that I added ? Old disk: [X X ][XX ][ XX ][X X][ XX] New disk (initial state): [X X ][XX ][ XX ][X X][ XX][ ][ ][ ][ ][ ] New disk (after 10 allocations): [XXX ][XX X][XXX ][XX X][ XXX][X ][ X ][ X][ X ][ X ] New disk (after 20 allocations): [XXXX][XXXX][XXXX][XXXX][XXXX][X X ][XX ][ X X][ XX ][ XX] Result: slowed access times, very long allocation cycle, even though there is a lot of free space (100% fill on bottom half, 50% fill on top half, when it should have an overall 50% fill). You get to spend all of your time generating random numbers until you find a cylinder group that isn't full. 50/50 chance of getting one of the bottom instead of top sectors each time. Performance falls off exponentially, just like the whole disk was almost full, even if the top half is really half empty. In the graphic example above, the fill on the disk is an *average* 75%; selection of disk space is a hash function, which, if you read Knuth: "Seminumerical algorithms: Sorting and Searching", would not have a performance hit at all until 85% full... IF the distribution was perfectly random, which it isn't because you added disk space without reallocating already allocated "random" allocations -- thus introducing an artificial selection bias "history". So: you'll be able to use the space, but your performance will suck, probably sooner, rather than later. FWIW, LFS and EXT2FS and EXT3FS and Reiser and NTFS all have this issue, but some of those have "cleaners"/defragmenters. Note: this example started with the bottom disk 50% full; you are much more likely to add disk space only after you really need it, and it's not likely to be double. Therefore (1) your performance will suck almost immediately, rather than the suck being delayed, and (2) the base of the exponential curve will be much, much higher, and (3) you will spend all your CPU on looking for an empty cluster in a cylinder group somewhere. In normal operation, FFS never has this problem because the free reserve guarantees that the hash never gets full enough to have a problem (well, except FreeBSD has reduced the default free reserve below the 10% speed/space tradeoff level to 8%, when 15% would be optimal [100% - 85% = 15%]), but then growing your disk space available is an abnormal operation not considered in the original design of FFS (all disk packs are 4M, and that's *luxury*). See the "newfs" man page, and the FFS design paper for details. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 15:46:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C13F37B400; Thu, 15 Aug 2002 15:46:34 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A45C643E75; Thu, 15 Aug 2002 15:46:33 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from monica.cs.rpi.edu (monica.cs.rpi.edu [128.213.7.3]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA43959; Thu, 15 Aug 2002 18:46:32 -0400 (EDT) Received: from monica.cs.rpi.edu (crossd@localhost) by monica.cs.rpi.edu (8.11.6/8.11.6) with ESMTP id g7FMkVA00544; Thu, 15 Aug 2002 18:46:31 -0400 (EDT) (envelope-from crossd@monica.cs.rpi.edu) Message-Id: <200208152246.g7FMkVA00544@monica.cs.rpi.edu> To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: 4.6.2-RELEASE and KRB5 Date: Thu, 15 Aug 2002 18:46:31 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just cvs-ed to RELENG_4_6_2_RELEASE and tried to do a "make buildworld" and I get the errors included below. It _appears_ to be related to the binutils/ld changes that went in, but I am unsure how that change affected this, and only this. ----errors bellow---- > make-roken.c cc -O -pipe -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT -DKRB4 -DINET6 make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 Stop in /usr/src/kerberos5/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 15 17:46: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA72037B400 for ; Thu, 15 Aug 2002 17:46:03 -0700 (PDT) Received: from 12-218-135-53.client.mchsi.com (12-218-135-53.client.mchsi.com [12.218.135.53]) by mx1.FreeBSD.org (Postfix) with SMTP id D80E743E4A for ; Thu, 15 Aug 2002 17:46:02 -0700 (PDT) (envelope-from erik@12-218-135-53.client.mchsi.com) Received: (qmail 18907 invoked by uid 1000); 16 Aug 2002 00:46:20 -0000 Date: Thu, 15 Aug 2002 19:46:20 -0500 From: Erik Greenwald To: freebsd-hackers@freebsd.org Subject: soaccept not returning host info? Message-ID: <20020816004620.GA18897@freya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi I'm writing a kernel module (for -current) that provides a listening inet socket, I have it establishing and binding the socket, tsleeping for the event, etc, and the soaccept() call seems to work fine. My problem is that the info about the connecting host info seems incomplete. It reports a length of 16, family of AF_INET (2), the rest is zero'd out. Even when the connecting client is on a remote machine... So my question is how do I get the appropriate host information. Is it nested in the pcb or proto block? I'm assuming an mbuf is used for the actual data transferred, that'd be accessed via the socket mbuf? Any pointers would be greatly appreciated, if it's an rtfm issue, pls point me to the right fm :) Thnx -- -Erik [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 0:36: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3211237B400 for ; Fri, 16 Aug 2002 00:36:00 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C7143E4A for ; Fri, 16 Aug 2002 00:35:59 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g7G7YDu89160; Fri, 16 Aug 2002 00:34:14 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Fri, 16 Aug 2002 00:34:13 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: "Daniel O'Connor" , Subject: Re: possible to expand a file for vn-device FS usage ? In-Reply-To: <3D5C2070.4F2C17A3@mindspring.com> Message-ID: <20020816003225.K58763-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank you for the very clear explanation. Does there exist a utility to immediately take a partition that has been growfs'd and "fix" it so that it does not experience this performance penalty ? That is, I am willing to sit and wait 10 minutes while some utility rearranges and reorganizes the unmounted filesystem if it means I don't have to dump/restore/blah/blah and if it allows me to avoid the performance penalty you mentioned... thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 1:32:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2156537B400 for ; Fri, 16 Aug 2002 01:32:32 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B26E143E3B for ; Fri, 16 Aug 2002 01:32:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0028.cvx22-bradley.dialup.earthlink.net ([209.179.198.28] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fcWs-0003fL-00; Fri, 16 Aug 2002 01:32:23 -0700 Message-ID: <3D5CB788.225785BA@mindspring.com> Date: Fri, 16 Aug 2002 01:27:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Daniel O'Connor , freebsd-hackers@FreeBSD.ORG Subject: Re: possible to expand a file for vn-device FS usage ? References: <20020816003225.K58763-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > Thank you for the very clear explanation. Does there exist a utility to > immediately take a partition that has been growfs'd and "fix" it so that > it does not experience this performance penalty ? > > That is, I am willing to sit and wait 10 minutes while some utility > rearranges and reorganizes the unmounted filesystem if it means I don't > have to dump/restore/blah/blah and if it allows me to avoid the > performance penalty you mentioned... You are talking about a defragmenter. It's possible to write one of these, but no one has written one yet, because no one really uses growfs(8) often enough that it ever becomes an issue. So the short answer is "no". The longer answer is that all a defragmenter would do is "make this disk look like it would have looked had i been this size all along". The easiest way to do this is a backup and restore. Note that this does not require a tape drive, if you have enough disk space for the dump image, so it's not like this will be an incredibly time consuming process or anything. How long it would take really depends on the size of your disks, and whether you can use a different drive for the backup image or not (concurrent access to the same disk with a lot of seeks will slow the process by a factor of ~3 on most IDE based systems). The even longer answer is that this sort of thing could forcibly migrate files away from an area of the disk, so it could be used to resize a disk *smaller* (something that isn't supported at all right now), or support relocation and resizing (ala the Power Quest "Partition Magic" program). I actually volunteered to write this code for "$1 and other valuable considerations" for Power Quest, Inc., to get them to support FFS with their tools, several times, but they were not interested. The offer still stands for them; without a payoff like FreeBSD support in the best commercial partitioning product, though, it's probably not worth it just as a standalone project, without cash being involved. Conceptually, if you want to write this code, of it's very easy; all you have to do is create an image of the metadata allocations as they would look on a disk of the appropriate size, if all the files were newly created for the first time, and then rewrite the disk contents to match the image your program has in mind. You can even make it incrementally restartable, by using a file to store the image, and another small file for an intention log, in case there is a power failure during the operation. This assumes that there is enough slack disk space around for you to store the log, and that you can make the log non-colliding with the rest of the FS contents (fairly easy, actually: treat it as an already relocated file in the new FS, and temporarily move file contents around, "fragmenting them worse" to clear the area where you plan to put the log). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 3:19:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A648637B400; Fri, 16 Aug 2002 03:19:40 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0D843E81; Fri, 16 Aug 2002 03:19:39 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17feCY-0008Wo-00; Fri, 16 Aug 2002 13:19:30 +0300 Date: Fri, 16 Aug 2002 13:19:30 +0300 (EEST) From: Iasen Kostov To: Julian Elischer Cc: Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: Message-ID: <20020816131654.H18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Please take a look at this patch. It implement 1 more flag to if_flags and ofcourse it increases size of this flag field by using if_ipending which is unused. On Thu, 15 Aug 2002, Julian Elischer wrote: > you cannot break ABIs in 4.x > in 5.x it will probably be ok until (say) 5.1 or something. > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > Folks, > > > > When implementing ability to switch interface into promisc mode using > > ifconfig(8) I've stumbled into the problem with already exhausted > > space in the `short if_flags' field in the ifnet structure. I need to > > allocate one new flag, while we already have 16 IFF_* flags, and even > > one additional flag which is implemented using currently free > > if_ipending field of the said structure. Attached patch is aimed at > > increasing size of if_flags to 32 bits, as well as to clean-up > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > but IMO it is not a big problem. > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > -Maxim > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 3:38:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 506D237B405; Fri, 16 Aug 2002 03:38:10 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E2143E42; Fri, 16 Aug 2002 03:38:08 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17feUP-0008m2-00; Fri, 16 Aug 2002 13:37:57 +0300 Date: Fri, 16 Aug 2002 13:37:57 +0300 (EEST) From: Iasen Kostov To: Julian Elischer Cc: Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <20020816131654.H18061-100000@shadowhand.OTEL.net> Message-ID: <20020816133655.U18061-200000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1999923416-1029494277=:18061" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1999923416-1029494277=:18061 Content-Type: TEXT/PLAIN; charset=US-ASCII Ops here is the patch (not enough sleep again :(). On Fri, 16 Aug 2002, Iasen Kostov wrote: > Please take a look at this patch. It implement 1 more flag to if_flags > and ofcourse it increases size of this flag field by using if_ipending > which is unused. > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > you cannot break ABIs in 4.x > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > Folks, > > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > -Maxim > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > --0-1999923416-1029494277=:18061 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ifcflags.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020816133757.Y18061@shadowhand.OTEL.net> Content-Description: Content-Disposition: attachment; filename="ifcflags.patch" LS0tIHN5cy9uZXQvaWYuYwlTdW4gQXByIDI4IDA4OjQwOjI1IDIwMDINCisr KyBzeXMvbmV0L2lmLm15LmMJU2F0IEp1biAgOCAyMDo1MjoxMiAyMDAyDQpA QCAtOTUyLDYgKzk1Miw3IEBADQogCXN0cnVjdCBpZnN0YXQgKmlmczsNCiAJ aW50IGVycm9yOw0KIAlzaG9ydCBvaWZfZmxhZ3M7DQorCWludCBmbGFnc2xv bmc7DQogDQogCXN3aXRjaCAoY21kKSB7DQogDQpAQCAtOTgwLDcgKzk4MSw4 IEBADQogCXN3aXRjaCAoY21kKSB7DQogDQogCWNhc2UgU0lPQ0dJRkZMQUdT Og0KLQkJaWZyLT5pZnJfZmxhZ3MgPSBpZnAtPmlmX2ZsYWdzOw0KKwkJZmxh Z3Nsb25nID0gaWZwLT5pZl9mbGFncyAmIDB4MDAwMGZmZmY7DQorCQlpZnIt Pmlmcl9mbGFnc2xvbmcgPSBmbGFnc2xvbmcgfCBpZnAtPmlmX2lwZW5kaW5n Ow0KIAkJYnJlYWs7DQogDQogCWNhc2UgU0lPQ0dJRkNBUDoNCkBAIC0xMDA0 LDYgKzEwMDYsNyBAQA0KIAkJZXJyb3IgPSBzdXNlcihwKTsNCiAJCWlmIChl cnJvcikNCiAJCQlyZXR1cm4gKGVycm9yKTsNCisJCWlmcC0+aWZfaXBlbmRp bmcgPSBpZnItPmlmcl9mbGFnc2xvbmcgJiAweGZmZmYwMDAwOw0KIAkJaWZy LT5pZnJfcHJldmZsYWdzID0gaWZwLT5pZl9mbGFnczsNCiAJCWlmIChpZnAt PmlmX2ZsYWdzICYgSUZGX1NNQVJUKSB7DQogCQkJLyogU21hcnQgZHJpdmVy cyB0d2lkZGxlIHRoZWlyIG93biByb3V0ZXMgKi8NCi0tLSBzeXMvbmV0L2lm LmgJU3VuIEZlYiAxMCAwMTowMjozOSAyMDAyDQorKysgc3lzL25ldC9pZi5t eS5oCVNhdCBKdW4gIDggMjA6NTI6MjAgMjAwMg0KQEAgLTEzOSw2ICsxMzks NyBAQA0KICAqIElGRiBmbGFncywgc28gd2UgaGF2ZSBhbiBlYXNpZXIgdGlt ZSB3aGVuIHdlIHdhbnQgdG8gbWVyZ2UgdGhlbS4NCiAgKi8NCiAjZGVmaW5l CUlGRl9QT0xMSU5HCTB4MTAwMDAJCS8qIEludGVyZmFjZSBpcyBpbiBwb2xs aW5nIG1vZGUuICovDQorI2RlZmluZQlJRkZfTk9ST1VURQkweDIwMDAwCQkv KiBJbnRlcmZhY2UgZG9lc24ndCBuZWVkIGhvc3Qgcm91dGUuICovDQogDQog LyogZmxhZ3Mgc2V0IGludGVybmFsbHkgb25seTogKi8NCiAjZGVmaW5lCUlG Rl9DQU5UQ0hBTkdFIFwNCkBAIC0yMjQsNiArMjI1LDcgQEANCiAJCXN0cnVj dAlzb2NrYWRkciBpZnJ1X2RzdGFkZHI7DQogCQlzdHJ1Y3QJc29ja2FkZHIg aWZydV9icm9hZGFkZHI7DQogCQlzaG9ydAlpZnJ1X2ZsYWdzWzJdOw0KKwkJ aW50CWlmcnVfZmxhZ3Nsb25nOw0KIAkJaW50CWlmcnVfbWV0cmljOw0KIAkJ aW50CWlmcnVfbXR1Ow0KIAkJaW50CWlmcnVfcGh5czsNCkBAIC0yMzYsNiAr MjM4LDcgQEANCiAjZGVmaW5lCWlmcl9icm9hZGFkZHIJaWZyX2lmcnUuaWZy dV9icm9hZGFkZHIJLyogYnJvYWRjYXN0IGFkZHJlc3MgKi8NCiAjZGVmaW5l CWlmcl9mbGFncwlpZnJfaWZydS5pZnJ1X2ZsYWdzWzBdCS8qIGZsYWdzICov DQogI2RlZmluZQlpZnJfcHJldmZsYWdzCWlmcl9pZnJ1LmlmcnVfZmxhZ3Nb MV0JLyogZmxhZ3MgKi8NCisjZGVmaW5lCWlmcl9mbGFnc2xvbmcJaWZyX2lm cnUuaWZydV9mbGFnc2xvbmcJLyogbG9uZyBmbGFncyAoaW50KSAqLw0KICNk ZWZpbmUJaWZyX21ldHJpYwlpZnJfaWZydS5pZnJ1X21ldHJpYwkvKiBtZXRy aWMgKi8NCiAjZGVmaW5lCWlmcl9tdHUJCWlmcl9pZnJ1LmlmcnVfbXR1CS8q IG10dSAqLw0KICNkZWZpbmUgaWZyX3BoeXMJaWZyX2lmcnUuaWZydV9waHlz CS8qIHBoeXNpY2FsIHdpcmUgKi8NCi0tLSBzYmluL2lmY29uZmlnL2lmY29u ZmlnLmMJV2VkIEFwciAgMyAxNDo0ODo0OCAyMDAyDQorKysgc2Jpbi9pZmNv bmZpZy9pZmNvbmZpZy5teS5jCVNhdCBKdW4gIDggMjE6MDU6MDAgMjAwMg0K QEAgLTIwNSw2ICsyMDUsOCBAQA0KIAl7ICItYWxpYXMiLAktSUZGX1VQLAlu b3RlYWxpYXMgfSwNCiAJeyAiZGVsZXRlIiwJLUlGRl9VUCwJbm90ZWFsaWFz IH0sDQogCXsgInJlbW92ZSIsCS1JRkZfVVAsCW5vdGVhbGlhcyB9LA0KKwl7 ICJub3JvdXRlIiwgICAgSUZGX05PUk9VVEUsICAgIHNldGlmZmxhZ3MgfSwN CisJeyAiLW5vcm91dGUiLCAgIC1JRkZfTk9ST1VURSwgICBzZXRpZmZsYWdz IH0sDQogI2lmZGVmIG5vdGRlZg0KICNkZWZpbmUJRU5fU1dBQklQUwkweDEw MDANCiAJeyAic3dhYmlwcyIsCUVOX1NXQUJJUFMsCXNldGlmZmxhZ3MgfSwN CkBAIC0xMDI4LDE0ICsxMDMwLDE0IEBADQogIAkJZXhpdCgxKTsNCiAgCX0N CiAJc3RybmNweShteV9pZnIuaWZyX25hbWUsIG5hbWUsIHNpemVvZiAobXlf aWZyLmlmcl9uYW1lKSk7DQotIAlmbGFncyA9IG15X2lmci5pZnJfZmxhZ3M7 DQorCWZsYWdzID0gbXlfaWZyLmlmcl9mbGFnc2xvbmc7DQogDQogCWlmICh2 YWx1ZSA8IDApIHsNCiAJCXZhbHVlID0gLXZhbHVlOw0KIAkJZmxhZ3MgJj0g fnZhbHVlOw0KIAl9IGVsc2UNCiAJCWZsYWdzIHw9IHZhbHVlOw0KLQlteV9p ZnIuaWZyX2ZsYWdzID0gZmxhZ3M7DQorCW15X2lmci5pZnJfZmxhZ3Nsb25n ID0gZmxhZ3M7DQogCWlmIChpb2N0bChzLCBTSU9DU0lGRkxBR1MsIChjYWRk cl90KSZteV9pZnIpIDwgMCkNCiAJCVBlcnJvcih2bmFtZSk7DQogfQ0KLS0t IHN5cy9uZXRpbmV0L2luLmMJU2F0IEp1biAgOCAyMToyMToxMiAyMDAyDQor Kysgc3lzL25ldGluZXQvaW4ubXkuYwlTYXQgSnVuICA4IDIwOjUzOjA2IDIw MDINCkBAIC03MzksMTUgKzczOSwxNiBAQA0KIAkgKiBYWFg6IFRoaXMgaXMg dWdseSAhICBUaGVyZSBzaG91bGQgYmUgYSB3YXkgZm9yIHRoZSBjYWxsZXIg dG8NCiAJICogICAgICBzYXkgdGhhdCB0aGV5IGRvbid0IHdhbnQgYSBob3N0 IHJvdXRlLg0KIAkgKi8NCi0JaWYgKGlhLT5pYV9hZGRyLnNpbl9hZGRyLnNf YWRkciAhPSBJTkFERFJfQU5ZIHx8DQotCSAgICBpYS0+aWFfbmV0bWFzayAh PSBJTl9DTEFTU0FfTkVUIHx8DQotCSAgICBpYS0+aWFfZHN0YWRkci5zaW5f YWRkci5zX2FkZHIgIT0gaHRvbmwoSU5fQ0xBU1NBX0hPU1QpKSB7DQotCQlp ZiAoKGVycm9yID0gcnRpbml0KCZpYS0+aWFfaWZhLCAoaW50KVJUTV9BREQs IGZsYWdzKSkgIT0gMCkgew0KLQkJCWlhLT5pYV9hZGRyID0gb2xkYWRkcjsN Ci0JCQkgICAgcmV0dXJuIChlcnJvcik7DQotCQl9DQotCQlpYS0+aWFfZmxh Z3MgfD0gSUZBX1JPVVRFOw0KLQl9DQorCWlmICghKGlmcC0+aWZfaXBlbmRp bmcgJiBJRkZfTk9ST1VURSkpDQorCSAgICBpZiAoaWEtPmlhX2FkZHIuc2lu X2FkZHIuc19hZGRyICE9IElOQUREUl9BTlkgfHwNCisJCWlhLT5pYV9uZXRt YXNrICE9IElOX0NMQVNTQV9ORVQgfHwNCisJCWlhLT5pYV9kc3RhZGRyLnNp bl9hZGRyLnNfYWRkciAhPSBodG9ubChJTl9DTEFTU0FfSE9TVCkpIHsNCisJ CSAgICBpZiAoKGVycm9yID0gcnRpbml0KCZpYS0+aWFfaWZhLCAoaW50KVJU TV9BREQsIGZsYWdzKSkgIT0gMCkgew0KKwkJICAgIAlpYS0+aWFfYWRkciA9 IG9sZGFkZHI7DQorCQkJcmV0dXJuIChlcnJvcik7DQorCQkgICAgfQ0KKwkJ ICAgIGlhLT5pYV9mbGFncyB8PSBJRkFfUk9VVEU7DQorCSAgICB9DQogDQog CS8qDQogCSAqIElmIHRoZSBpbnRlcmZhY2Ugc3VwcG9ydHMgbXVsdGljYXN0 LCBqb2luIHRoZSAiYWxsIGhvc3RzIg0K --0-1999923416-1029494277=:18061-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 3:40:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E9637B400 for ; Fri, 16 Aug 2002 03:40:40 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5AC343E6A for ; Fri, 16 Aug 2002 03:40:39 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #6) id 17feX0-000ECS-00 for freebsd-hackers@freebsd.org; Fri, 16 Aug 2002 11:40:38 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GAec3H058503 for ; Fri, 16 Aug 2002 11:40:38 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GAecMG058502 for freebsd-hackers@freebsd.org; Fri, 16 Aug 2002 11:40:38 +0100 (BST) Date: Fri, 16 Aug 2002 11:40:37 +0100 From: Jonathon McKitrick To: freebsd-hackers@freebsd.org Subject: When to consider the new scehduler? Message-ID: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A couple of months ago, I saw a note on daemonnews that there was a patch for a proportional share scheduler. When would this work better than the existing priority feedback scheduler? NOTE: Please CC me, as I am not currently subscribed. Thanks. jm -- My other computer is your windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 4: 1:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 625DA37B400; Fri, 16 Aug 2002 04:01:22 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F82643E70; Fri, 16 Aug 2002 04:01:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA30936; Fri, 16 Aug 2002 11:01:18 GMT Date: Fri, 16 Aug 2002 21:08:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <3D5BF635.3764C796@FreeBSD.org> Message-ID: <20020816204055.N6621-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 15 Aug 2002, Maxim Sobolev wrote: > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. Why isn't it a bug problem? It affects an application ABI (most socket ioctls). We have whole syscalls whose purpose is to avoid breaking application ABIs back to about 4.3BSD. Some of them may even work. > Index: src/share/man/man4/netintro.4 > =================================================================== > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > retrieving revision 1.20 > diff -d -u -r1.20 netintro.4 > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > @@ -197,7 +197,7 @@ > struct sockaddr ifru_addr; > struct sockaddr ifru_dstaddr; > struct sockaddr ifru_broadaddr; > - short ifru_flags; > + int ifru_flags; > int ifru_metric; > int ifru_mtu; > int ifru_phys; This particular ABI seems to have been broken before (in if.h 1.50 on 1999/02/09), since the actual struct has "short ifru_flags[2];" followed by "short if_index;" instead of "short ifru_flags;", and it has 2 new struct members at the end too. If the struct were actually as above, then changing the short to an int would almost be binary compatible since it would just expand ifru_flags to use the 2 bytes of unnamed padding caused by the poor layout, so the struct wouldn't expand and the other members wouldn't move. Enlarging ifru_flags itself might only break big-endian machines (little-endian ones wouldn't notice providing the padding is zeroed). > Index: src/share/man/man9/ifnet.9 Breaking kernel ABIs isn't so important. They should only be compatible within major releases. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 4:23:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A7A637B40D for ; Fri, 16 Aug 2002 04:23:28 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D1AE43E6A for ; Fri, 16 Aug 2002 04:23:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ffBt-0004iI-00; Fri, 16 Aug 2002 04:22:54 -0700 Message-ID: <3D5CDF48.9C9B30ED@mindspring.com> Date: Fri, 16 Aug 2002 04:17:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathon McKitrick Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonathon McKitrick wrote: > A couple of months ago, I saw a note on daemonnews that there was a > patch for a proportional share scheduler. When would this work better > than the existing priority feedback scheduler? > = > NOTE: Please CC me, as I am not currently subscribed. Thanks. Basically, you use it if you expect the system to be overloaded, and don't want to spend the engineering effort to prevent/handle the overload, and astill want the system to degrade gracefully. The "fixed" scheduling class used to support the X server in the UnixWare/SVR4.0.2/SVR4.2 case is, in the limit, a proportional share scheduler. Rather than addressing the lack of working set quotas that caused some programs (e.g. the linker) to thrash a large number of pages out, the fixed scheduling class was added to permit the X server sufficient CPU to trash the pages back in; it didn't fix the problem, and there was a lot of useless page thrashing, but the result was that the X server had sufficiently good interactive response to fullfill the "move mouse -> wiggle cursor" requirement amd avoid cognitive dissonance on the part of the user attached to the mouse. 8-). Here is an introduction from a moderately good paper on the subject. Note that not all proportional share schedulers implement all the attributes described here, and most are not O(1). I can't comment on Luigi's work in detail, because I haven't studied it in detail (soft real time systems are not very interesting to me unless they support deadlining). Abstracted from: http://www.cs.utah.edu/flux/papers/ps-rtss01/RegehrRTSS01wip.pdf | There are compelling reasons to use proportional share | scheduling techniques to support multimedia and other | soft real-time applications on general-purpose operating | systems. First, proportional share (PS) schedulers are | a good match for existing infrastructure such as a peri-odic | timer interrupt and mechanisms for assigning priori-ties | to applications=97priorities can be mapped to shares in | a proportional-share environment. Second, PS schedulers | provide stronger guarantees to applications than do tradi-tional | time-sharing schedulers: they allocate a specific frac-tion | of the CPU to each thread, and some schedulers provide | error bounds on the allocation rate. Third, PS schedulers | have clear semantics during underload: excess CPU time | is allocated fairly, in contrast with some reservation-based | schedulers that must idle or back off to a secondary scheduling | policy once all application budgets are exhausted. FWIW, here's a paper on an O(1) proportional share scheduler. It's not incredibly interesting, except in that it tries to implement fair queueing: http://citeseer.nj.nec.com/nieh01virtualtime.html For my money, the algorithm to use in networking equipment, in which you want to optimize packet throughput, is Weighted Fair Share Queueing (as in the IBM/UMass work on QLinux, which also implements Lazy REceiver Processing; see the QLinux site at http://lass.cs.umass.edu/software/qlinux/ ). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 4:34:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE3EF37B400; Fri, 16 Aug 2002 04:34:24 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF1643E6A; Fri, 16 Aug 2002 04:34:21 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GBY4Z79168; Fri, 16 Aug 2002 14:34:07 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GBXvWe005227; Fri, 16 Aug 2002 14:33:57 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GBXnIX005225; Fri, 16 Aug 2002 14:33:49 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161133.g7GBXnIX005225@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: ikostov@otel.net (Iasen Kostov) Date: Fri, 16 Aug 2002 14:33:49 +0300 (EEST) Cc: julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816131654.H18061-100000@shadowhand.OTEL.net> from "Iasen Kostov" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Please take a look at this patch. It implement 1 more flag to if_flags > and ofcourse it increases size of this flag field by using if_ipending > which is unused. There is no much point in this patch, because it will increase size of struct ifreq, which means that no ioctl's from older apps will be accepted anyway. Therefore, there is no difference between those two, while my approach is obviously cleaner. -Maxim > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > you cannot break ABIs in 4.x > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > Folks, > > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > -Maxim > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5: 0:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E523C37B406 for ; Fri, 16 Aug 2002 05:00:54 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B2E43F07 for ; Fri, 16 Aug 2002 05:00:43 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #6) id 17fflm-0001I4-00; Fri, 16 Aug 2002 12:59:58 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GBxw3H058906; Fri, 16 Aug 2002 12:59:58 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GBxvh2058905; Fri, 16 Aug 2002 12:59:57 +0100 (BST) Date: Fri, 16 Aug 2002 12:59:57 +0100 From: Jonathon McKitrick To: Terry Lambert Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? Message-ID: <20020816115957.GA58797@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5CDF48.9C9B30ED@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 16, 2002 at 04:17:28AM -0700, Terry Lambert wrote: | Jonathon McKitrick wrote: | > A couple of months ago, I saw a note on daemonnews that there was a | > patch for a proportional share scheduler. When would this work better | > than the existing priority feedback scheduler? | > | > NOTE: Please CC me, as I am not currently subscribed. Thanks. | | Basically, you use it if you expect the system to be overloaded, | and don't want to spend the engineering effort to prevent/handle | the overload, and astill want the system to degrade gracefully. Ah, I see. | thrashing, but the result was that the X server had sufficiently | good interactive response to fullfill the "move mouse -> wiggle | cursor" requirement amd avoid cognitive dissonance on the part | of the user attached to the mouse. 8-). Why don't they just add an extra CPU to handle the GUI?? ;-) | Here is an introduction from a moderately good paper on the subject. Interesting how these 'fundamental' concepts of CS are still being researched/refined over the years. Unix already applies so much research and development that was found to have real-world practicality, and yet still there is room for improvement in at least some circumstances. I'll check out these papers you referred to. | For my money, the algorithm to use in networking equipment, in | which you want to optimize packet throughput, is Weighted Fair | Share Queueing (as in the IBM/UMass work on QLinux, which also It would be nice if the 'instant workstation' port tweaked the system settings to meet a balance between needs of the network and needs of the user. Things like scheduler, sysctl settings, and so on. Of course, that's a bit of overkill, wouldn't ya say? ;-) jm -- My other computer is your Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5: 8:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B291537B400; Fri, 16 Aug 2002 05:08:49 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B7FA43E3B; Fri, 16 Aug 2002 05:08:48 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17ffu3-000AQU-00; Fri, 16 Aug 2002 15:08:31 +0300 Date: Fri, 16 Aug 2002 15:08:31 +0300 (EEST) From: Iasen Kostov To: Maxim Sobolev Cc: Julian Elischer , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161133.g7GBXnIX005225@vega.vega.com> Message-ID: <20020816150159.T18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > > > Please take a look at this patch. It implement 1 more flag to if_flags > > and ofcourse it increases size of this flag field by using if_ipending > > which is unused. > > There is no much point in this patch, because it will increase size of > struct ifreq, which means that no ioctl's from older apps will be accepted > anyway. Therefore, there is no difference between those two, while my > approach is obviously cleaner. It does not increase size of struct ifreq. This is a union not a struct as You see. union { struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; short ifru_flags[2]; int ifru_flagslong; int ifru_metric; int ifru_mtu; int ifru_phys; int ifru_media; caddr_t ifru_data; int ifru_cap[2]; } ifr_ifru; > > -Maxim > > > > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > > > you cannot break ABIs in 4.x > > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > > > Folks, > > > > > > > > When implementing ability to switch interface into promisc mode using > > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > > space in the `short if_flags' field in the ifnet structure. I need to > > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > > one additional flag which is implemented using currently free > > > > if_ipending field of the said structure. Attached patch is aimed at > > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > > but IMO it is not a big problem. > > > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > > > -Maxim > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:11:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE3CE37B400; Fri, 16 Aug 2002 05:11:47 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C302B43E72; Fri, 16 Aug 2002 05:11:43 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GCBQZ80641; Fri, 16 Aug 2002 15:11:27 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GCBKWe005352; Fri, 16 Aug 2002 15:11:20 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GCBDrL005351; Fri, 16 Aug 2002 15:11:13 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161211.g7GCBDrL005351@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: bde@zeta.org.au (Bruce Evans) Date: Fri, 16 Aug 2002 15:11:13 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816204055.N6621-100000@gamplex.bde.org> from "Bruce Evans" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > When implementing ability to switch interface into promisc mode using > > ifconfig(8) I've stumbled into the problem with already exhausted > > space in the `short if_flags' field in the ifnet structure. I need to > > allocate one new flag, while we already have 16 IFF_* flags, and even > > one additional flag which is implemented using currently free > > if_ipending field of the said structure. Attached patch is aimed at > > increasing size of if_flags to 32 bits, as well as to clean-up > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > but IMO it is not a big problem. > > Why isn't it a bug problem? It affects an application ABI (most socket > ioctls). We have whole syscalls whose purpose is to avoid breaking > application ABIs back to about 4.3BSD. Some of them may even work. > > > Index: src/share/man/man4/netintro.4 > > =================================================================== > > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > > retrieving revision 1.20 > > diff -d -u -r1.20 netintro.4 > > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > > @@ -197,7 +197,7 @@ > > struct sockaddr ifru_addr; > > struct sockaddr ifru_dstaddr; > > struct sockaddr ifru_broadaddr; > > - short ifru_flags; > > + int ifru_flags; > > int ifru_metric; > > int ifru_mtu; > > int ifru_phys; > > This particular ABI seems to have been broken before (in if.h 1.50 on > 1999/02/09), since the actual struct has "short ifru_flags[2];" followed > by "short if_index;" instead of "short ifru_flags;", and it has 2 new > struct members at the end too. If the struct were actually as above, > then changing the short to an int would almost be binary compatible > since it would just expand ifru_flags to use the 2 bytes of unnamed > padding caused by the poor layout, so the struct wouldn't expand and > the other members wouldn't move. Enlarging ifru_flags itself might > only break big-endian machines (little-endian ones wouldn't notice > providing the padding is zeroed). > > > Index: src/share/man/man9/ifnet.9 > > Breaking kernel ABIs isn't so important. They should only be compatible > within major releases. BTW, I've just realised that we can easily avoid breaking application ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) for storing another 16 flags. What do people think? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:22:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE54837B400; Fri, 16 Aug 2002 05:22:29 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953C243E65; Fri, 16 Aug 2002 05:22:27 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GCMEZ81179; Fri, 16 Aug 2002 15:22:14 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GCM8We005389; Fri, 16 Aug 2002 15:22:08 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GCM8Rt005388; Fri, 16 Aug 2002 15:22:08 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161222.g7GCM8Rt005388@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: ikostov@otel.net (Iasen Kostov) Date: Fri, 16 Aug 2002 15:22:07 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816150159.T18061-100000@shadowhand.OTEL.net> from "Iasen Kostov" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > There is no much point in this patch, because it will increase size of > > struct ifreq, which means that no ioctl's from older apps will be accepted > > anyway. Therefore, there is no difference between those two, while my > > approach is obviously cleaner. > > It does not increase size of struct ifreq. > This is a union not a struct as You see. Oh, yes, you are obviously correct. However, I still wonder if your patch is endianless-safe. -Maxim > union { > struct sockaddr ifru_addr; > struct sockaddr ifru_dstaddr; > struct sockaddr ifru_broadaddr; > short ifru_flags[2]; > int ifru_flagslong; > int ifru_metric; > int ifru_mtu; > int ifru_phys; > int ifru_media; > caddr_t ifru_data; > int ifru_cap[2]; > } ifr_ifru; > > > > -Maxim > > > > > > > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > > > > > you cannot break ABIs in 4.x > > > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > > > > > Folks, > > > > > > > > > > When implementing ability to switch interface into promisc mode using > > > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > > > space in the `short if_flags' field in the ifnet structure. I need to > > > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > > > one additional flag which is implemented using currently free > > > > > if_ipending field of the said structure. Attached patch is aimed at > > > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > > > but IMO it is not a big problem. > > > > > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > > > > > -Maxim > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:28:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E14737B400 for ; Fri, 16 Aug 2002 05:28:21 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D95B43E77 for ; Fri, 16 Aug 2002 05:28:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fgCo-000248-00; Fri, 16 Aug 2002 05:27:55 -0700 Message-ID: <3D5CEE39.51E55574@mindspring.com> Date: Fri, 16 Aug 2002 05:21:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathon McKitrick Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonathon McKitrick wrote: > | thrashing, but the result was that the X server had sufficiently > | good interactive response to fullfill the "move mouse -> wiggle > | cursor" requirement amd avoid cognitive dissonance on the part > | of the user attached to the mouse. 8-). > > Why don't they just add an extra CPU to handle the GUI?? ;-) They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) release, and 4.2 was the SMP enhanced version of UnixWare (released as UnixWare 2.0). I guess you could use it for other things, too... 8-). > | Here is an introduction from a moderately good paper on the subject. > > Interesting how these 'fundamental' concepts of CS are still being > researched/refined over the years. Unix already applies so much > research and development that was found to have real-world > practicality, and yet still there is room for improvement in at least > some circumstances. Not really. A lot of them are rehashing things we've known for a long time, and UNIX just hasn't implemented, for whatever reason (usually, failure to incorporate patches). For example, Luigi did FACK/SACK patches against FreeBSD around 1996, and Rice University did LRP against FreeBSD around 1998, and neither were commiited. Rutgers has implemented a stateful failover API with minor stack modifications against FreeBSD-STABLE, which they are very interested in seeing incorporated in FreeBSD, and they are basically being ignored. I'd say it was more "people who refuse to learn from history are doomed to repeat it". > | For my money, the algorithm to use in networking equipment, in > | which you want to optimize packet throughput, is Weighted Fair > | Share Queueing (as in the IBM/UMass work on QLinux, which also > > It would be nice if the 'instant workstation' port tweaked the system > settings to meet a balance between needs of the network and needs of > the user. Things like scheduler, sysctl settings, and so on. > > Of course, that's a bit of overkill, wouldn't ya say? ;-) Not really. It's possible to implement optimal networking algorithms, and have them be useful. A workstation experiencing a load based denial of service attack would function nearly normally, if its networking stack had Lazy Receiver Processing integrated (as one example). So I wouldn't categorize things as "workstation technology" vs. "server technology" simply because the person I'm talking two only has two buckets, and insists I pick one. 8-). I don't know where this whole idea of having a bunch of knobs that you have to turn away from the defaults to get non-mediocre performace came from, but the mythology that has grown up around the believe is, well, really annoying. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:28:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F7F37B401; Fri, 16 Aug 2002 05:28:30 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5067443E65; Fri, 16 Aug 2002 05:28:29 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17fgDB-000AmP-00; Fri, 16 Aug 2002 15:28:17 +0300 Date: Fri, 16 Aug 2002 15:28:17 +0300 (EEST) From: Iasen Kostov To: Maxim Sobolev Cc: Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161211.g7GCBDrL005351@vega.vega.com> Message-ID: <20020816152555.Y18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > Why isn't it a bug problem? It affects an application ABI (most socket > > ioctls). We have whole syscalls whose purpose is to avoid breaking > > application ABIs back to about 4.3BSD. Some of them may even work. > > > > > Index: src/share/man/man4/netintro.4 > > > =================================================================== > > > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > > > retrieving revision 1.20 > > > diff -d -u -r1.20 netintro.4 > > > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > > > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > > > @@ -197,7 +197,7 @@ > > > struct sockaddr ifru_addr; > > > struct sockaddr ifru_dstaddr; > > > struct sockaddr ifru_broadaddr; > > > - short ifru_flags; > > > + int ifru_flags; > > > int ifru_metric; > > > int ifru_mtu; > > > int ifru_phys; > > > > This particular ABI seems to have been broken before (in if.h 1.50 on > > 1999/02/09), since the actual struct has "short ifru_flags[2];" followed > > by "short if_index;" instead of "short ifru_flags;", and it has 2 new > > struct members at the end too. If the struct were actually as above, > > then changing the short to an int would almost be binary compatible > > since it would just expand ifru_flags to use the 2 bytes of unnamed > > padding caused by the poor layout, so the struct wouldn't expand and > > the other members wouldn't move. Enlarging ifru_flags itself might > > only break big-endian machines (little-endian ones wouldn't notice > > providing the padding is zeroed). > > > > > Index: src/share/man/man9/ifnet.9 > > > > Breaking kernel ABIs isn't so important. They should only be compatible > > within major releases. > > BTW, I've just realised that we can easily avoid breaking application > ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > for storing another 16 flags. What do people think? If something uses ifr_prevflags this could break compatibility, but if not it is the best solution I think :). > > -Maxim > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:30:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CAA37B400; Fri, 16 Aug 2002 05:30:16 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2310543E72; Fri, 16 Aug 2002 05:30:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fgEw-0003pR-00; Fri, 16 Aug 2002 05:30:06 -0700 Message-ID: <3D5CEEB8.EFDBF659@mindspring.com> Date: Fri, 16 Aug 2002 05:23:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Iasen Kostov , Julian Elischer , Maxim Sobolev , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch References: <200208161222.g7GCM8Rt005388@vega.vega.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > > There is no much point in this patch, because it will increase size of > > > struct ifreq, which means that no ioctl's from older apps will be accepted > > > anyway. Therefore, there is no difference between those two, while my > > > approach is obviously cleaner. > > > > It does not increase size of struct ifreq. > > This is a union not a struct as You see. > > Oh, yes, you are obviously correct. However, I still wonder if your patch > is endianless-safe. It's not, unless the structure packing is "just so". First thing I notices, and exactly what Bruce was pointing out when he referred to "other architectures", I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:35:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8037B401 for ; Fri, 16 Aug 2002 05:35:25 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C9C243E3B for ; Fri, 16 Aug 2002 05:35:24 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #6) id 17fgK3-000269-00; Fri, 16 Aug 2002 13:35:23 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GCZM3H059161; Fri, 16 Aug 2002 13:35:22 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GCZMkY059160; Fri, 16 Aug 2002 13:35:22 +0100 (BST) Date: Fri, 16 Aug 2002 13:35:21 +0100 From: Jonathon McKitrick To: Terry Lambert Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? Message-ID: <20020816123521.GB58797@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5CEE39.51E55574@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG | > Why don't they just add an extra CPU to handle the GUI?? ;-) | | They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) I thought only NT-SMP did that. I *thought* I was being funny. :-) | Not really. A lot of them are rehashing things we've known | for a long time, and UNIX just hasn't implemented, for whatever | reason (usually, failure to incorporate patches). For example, | Luigi did FACK/SACK patches against FreeBSD around 1996, and Rice | University did LRP against FreeBSD around 1998, and neither were | commiited. Rutgers has implemented a stateful failover API with | minor stack modifications against FreeBSD-STABLE, which they are | very interested in seeing incorporated in FreeBSD, and they are | basically being ignored. | | I'd say it was more "people who refuse to learn from history are | doomed to repeat it". | | | | > | For my money, the algorithm to use in networking equipment, in | > | which you want to optimize packet throughput, is Weighted Fair | > | Share Queueing (as in the IBM/UMass work on QLinux, which also | > | > It would be nice if the 'instant workstation' port tweaked the system | > settings to meet a balance between needs of the network and needs of | > the user. Things like scheduler, sysctl settings, and so on. | > | > Of course, that's a bit of overkill, wouldn't ya say? ;-) | | Not really. | | It's possible to implement optimal networking algorithms, and | have them be useful. A workstation experiencing a load based | denial of service attack would function nearly normally, if its | networking stack had Lazy Receiver Processing integrated (as one | example). So I wouldn't categorize things as "workstation | technology" vs. "server technology" simply because the person | I'm talking two only has two buckets, and insists I pick one. | 8-). | | I don't know where this whole idea of having a bunch of knobs | that you have to turn away from the defaults to get non-mediocre | performace came from, but the mythology that has grown up around | the believe is, well, really annoying. 8-(. | | -- Terry jm -- My other computer is your Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:36:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FF3937B401; Fri, 16 Aug 2002 05:36:24 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D9743E6E; Fri, 16 Aug 2002 05:36:22 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GCaF204836; Fri, 16 Aug 2002 14:36:15 +0200 (MEST) Date: Fri, 16 Aug 2002 14:36:15 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161211.g7GCBDrL005351@vega.vega.com> Message-ID: <20020816143437.D24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>BTW, I've just realised that we can easily avoid breaking application MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>for storing another 16 flags. What do people think? The ifr_prevflags may be used by snmp daemons to provide the necessary atomic rollback. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 5:40: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB88237B400 for ; Fri, 16 Aug 2002 05:39:57 -0700 (PDT) Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB59243E42 for ; Fri, 16 Aug 2002 05:39:56 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 17fgOL-000Ie8-00; Fri, 16 Aug 2002 13:39:49 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GCdm3H059204; Fri, 16 Aug 2002 13:39:48 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GCdmqU059203; Fri, 16 Aug 2002 13:39:48 +0100 (BST) Date: Fri, 16 Aug 2002 13:39:48 +0100 From: Jonathon McKitrick To: Terry Lambert Cc: freebsd-hackers@freebsd.org Subject: Re: When to consider the new scehduler? Message-ID: <20020816123948.GC58797@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5CEE39.51E55574@mindspring.com> User-Agent: Mutt/1.4i X-Scanner: exiscan *17fgOL-000Ie8-00*9phF3zMe29Y* (Manchester Computing, University of Manchester) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, my last email was sent prematurely. I hit 'send' a bit too soon. | > Why don't they just add an extra CPU to handle the GUI?? ;-) | | They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) I thought only NT did that. I was *trying* to be funny. :-) | Not really. A lot of them are rehashing things we've known | for a long time, and UNIX just hasn't implemented, for whatever | reason (usually, failure to incorporate patches). For example, I know that's an especially touchy point for you. :-) | Luigi did FACK/SACK patches against FreeBSD around 1996, and Rice | University did LRP against FreeBSD around 1998, and neither were | commiited. Rutgers has implemented a stateful failover API with | minor stack modifications against FreeBSD-STABLE, which they are | very interested in seeing incorporated in FreeBSD, and they are | basically being ignored. | | I'd say it was more "people who refuse to learn from history are | doomed to repeat it". See, this stuff annoys me. Getting people to contribute isn't easy. Especially quality code. Ignore volunteers, and they'll go away. | I don't know where this whole idea of having a bunch of knobs | that you have to turn away from the defaults to get non-mediocre | performace came from, but the mythology that has grown up around | the believe is, well, really annoying. 8-(. That's one thing I really like about Unix/FreeBSD. It really performs well in many situations, without needing a lot of tweaking. Of course, I'm a neophyte, so I've never really put it to the test, but still. :-) jm -- My other computer is your Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 6:52: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B33D37B400 for ; Fri, 16 Aug 2002 06:52:04 -0700 (PDT) Received: from lerlaptop.iadfw.net (lerlaptop.iadfw.net [206.66.13.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3BE343E3B for ; Fri, 16 Aug 2002 06:52:03 -0700 (PDT) (envelope-from ler@lerctr.org) Received: from localhost (localhost [127.0.0.1]) by lerlaptop.lerctr.org (8.12.5/8.12.5) with ESMTP id g7GCdZpM000955; Fri, 16 Aug 2002 07:39:35 -0500 (CDT) (envelope-from ler@lerctr.org) Subject: Re: When to consider the new scehduler? From: Larry Rosenman To: Jonathon McKitrick Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020816123521.GB58797@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> <20020816123521.GB58797@dogma.freebsd-uk.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Aug 2002 07:39:35 -0500 Message-Id: <1029501575.404.10.camel@lerlaptop.lerctr.org> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-08-16 at 07:35, Jonathon McKitrick wrote: > | > Why don't they just add an extra CPU to handle the GUI?? ;-) > | > | They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) > > I thought only NT-SMP did that. I *thought* I was being funny. :-) SVR4.2 is a totally threaded kernel. SVR5 (UnixWare 7/OpenUNIX 8) takes it even further. I run an OpenUnix 8+ box in addition to FreeBSD. if any FreeBSD developers want a shell account to look around, I can arrange it. [snip] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 6:56: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A15837B400; Fri, 16 Aug 2002 06:55:31 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C8A43E6E; Fri, 16 Aug 2002 06:55:28 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GDt8Z84931; Fri, 16 Aug 2002 16:55:08 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GDt1We005701; Fri, 16 Aug 2002 16:55:01 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GDsoup005697; Fri, 16 Aug 2002 16:54:50 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161354.g7GDsoup005697@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: brandt@fokus.gmd.de (Harti Brandt) Date: Fri, 16 Aug 2002 16:54:50 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), bde@zeta.org.au (Bruce Evans), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816143437.D24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.5686.1029506090--%" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --%--multipart-mixed-boundary-1.5686.1029506090--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > MS>BTW, I've just realised that we can easily avoid breaking application > MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > MS>for storing another 16 flags. What do people think? > > The ifr_prevflags may be used by snmp daemons to provide the necessary > atomic rollback. Could you please verify? Nothing in the base system uses it. Initially, ifr_prevflags was added with the following log message (rev.1.50): Since ifru_flags is a short, we can fit in a copy of the flags before they got changed. This can help eliminate much of the gymnastics drivers do in their ioctl routines to figure this out. but no drivers are using it so far. Just in the case, attached is updated patch, which utilises ifr_prevflags for extending ifr_flags. -Maxim --%--multipart-mixed-boundary-1.5686.1029506090--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: 'diff' output text Content-Disposition: attachment; filename="if_flags.32bit.patch" diff -druN src.preflags/sbin/ifconfig/ifconfig.c src/sbin/ifconfig/ifconfig.c --- src.preflags/sbin/ifconfig/ifconfig.c Thu Aug 15 09:47:46 2002 +++ src/sbin/ifconfig/ifconfig.c Fri Aug 16 16:12:09 2002 @@ -999,14 +999,15 @@ exit(1); } strncpy(my_ifr.ifr_name, name, sizeof (my_ifr.ifr_name)); - flags = my_ifr.ifr_flags; + flags = my_ifr.ifr_flags | (my_ifr.ifr_flagshigh << 16); if (value < 0) { value = -value; flags &= ~value; } else flags |= value; - my_ifr.ifr_flags = flags; + my_ifr.ifr_flags = flags & 0xffff; + my_ifr.ifr_flagshigh = flags >> 16; if (ioctl(s, SIOCSIFFLAGS, (caddr_t)&my_ifr) < 0) Perror(vname); } diff -druN src.preflags/share/man/man4/netintro.4 src/share/man/man4/netintro.4 --- src.preflags/share/man/man4/netintro.4 Thu Aug 15 09:47:47 2002 +++ src/share/man/man4/netintro.4 Fri Aug 16 16:11:11 2002 @@ -197,20 +197,21 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags; + short ifru_flags[2]; int ifru_metric; int ifru_mtu; int ifru_phys; caddr_t ifru_data; } ifr_ifru; -#define ifr_addr ifr_ifru.ifru_addr /* address */ -#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ +#define ifr_addr ifr_ifru.ifru_addr /* address */ +#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ -#define ifr_flags ifr_ifru.ifru_flags /* flags */ -#define ifr_metric ifr_ifru.ifru_metric /* metric */ -#define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ -#define ifr_phys ifr_ifru.ifru_phys /* physical wire */ -#define ifr_data ifr_ifru.ifru_data /* for use by interface */ +#define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ +#define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ +#define ifr_metric ifr_ifru.ifru_metric /* metric */ +#define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ +#define ifr_phys ifr_ifru.ifru_phys /* physical wire */ +#define ifr_data ifr_ifru.ifru_data /* for use by interface */ }; .Ed .Pp diff -druN src.preflags/share/man/man9/ifnet.9 src/share/man/man9/ifnet.9 --- src.preflags/share/man/man9/ifnet.9 Thu Aug 15 09:47:48 2002 +++ src/share/man/man9/ifnet.9 Thu Aug 15 11:36:46 2002 @@ -284,7 +284,7 @@ (Set by driver, decremented by generic watchdog code.) .It Va if_flags -.Pq Vt short +.Pq Vt int Flags describing operational parameters of this interface (see below). (Manipulated by both driver and generic code.) .It Va if_capabilities diff -druN src.preflags/sys/compat/linux/linux_ioctl.c src/sys/compat/linux/linux_ioctl.c --- src.preflags/sys/compat/linux/linux_ioctl.c Thu Aug 15 09:47:48 2002 +++ src/sys/compat/linux/linux_ioctl.c Thu Aug 15 11:48:59 2002 @@ -1963,7 +1963,7 @@ { l_short flags; - flags = ifp->if_flags; + flags = ifp->if_flags & 0xffff; /* these flags have no Linux equivalent */ flags &= ~(IFF_SMART|IFF_OACTIVE|IFF_SIMPLEX| IFF_LINK0|IFF_LINK1|IFF_LINK2); diff -druN src.preflags/sys/dev/fxp/if_fxp.c src/sys/dev/fxp/if_fxp.c --- src.preflags/sys/dev/fxp/if_fxp.c Thu Aug 15 09:47:50 2002 +++ src/sys/dev/fxp/if_fxp.c Thu Aug 15 21:17:11 2002 @@ -1193,7 +1193,7 @@ #ifdef DEVICE_POLLING struct ifnet *ifp = &sc->sc_if; - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) return; if (ether_poll_register(fxp_poll, ifp)) { /* disable interrupts */ @@ -1785,7 +1785,7 @@ * ... but only do that if we are not polling. And because (presumably) * the default is interrupts on, we need to disable them explicitly! */ - if ( ifp->if_ipending & IFF_POLLING ) + if ( ifp->if_flags & IFF_POLLING ) CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE); else #endif /* DEVICE_POLLING */ diff -druN src.preflags/sys/dev/vx/if_vx.c src/sys/dev/vx/if_vx.c --- src.preflags/sys/dev/vx/if_vx.c Thu Aug 15 09:47:57 2002 +++ src/sys/dev/vx/if_vx.c Thu Aug 15 13:51:27 2002 @@ -285,7 +285,7 @@ register struct ifnet *ifp = &sc->arpcom.ac_if; int i, j, k; char *reason, *warning; - static short prev_flags; + static int prev_flags; static char prev_conn = -1; if (prev_conn == -1) { diff -druN src.preflags/sys/kern/kern_poll.c src/sys/kern/kern_poll.c --- src.preflags/sys/kern/kern_poll.c Thu Aug 15 09:47:58 2002 +++ src/sys/kern/kern_poll.c Thu Aug 15 21:18:02 2002 @@ -383,7 +383,7 @@ for (i = 0 ; i < poll_handlers ; i++) { if (pr[i].handler && pr[i].ifp->if_flags & IFF_RUNNING) { - pr[i].ifp->if_ipending &= ~IFF_POLLING; + pr[i].ifp->if_flags &= ~IFF_POLLING; pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); } pr[i].handler=NULL; @@ -415,7 +415,7 @@ return 0; if ( !(ifp->if_flags & IFF_UP) ) /* must be up */ return 0; - if (ifp->if_ipending & IFF_POLLING) /* already polling */ + if (ifp->if_flags & IFF_POLLING) /* already polling */ return 0; s = splhigh(); @@ -440,7 +440,7 @@ pr[poll_handlers].handler = h; pr[poll_handlers].ifp = ifp; poll_handlers++; - ifp->if_ipending |= IFF_POLLING; + ifp->if_flags |= IFF_POLLING; splx(s); if (idlepoll_sleeping) wakeup(&idlepoll_sleeping); @@ -459,14 +459,14 @@ int i; mtx_lock(&Giant); - if ( !ifp || !(ifp->if_ipending & IFF_POLLING) ) { + if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { mtx_unlock(&Giant); return 0; } for (i = 0 ; i < poll_handlers ; i++) if (pr[i].ifp == ifp) /* found it */ break; - ifp->if_ipending &= ~IFF_POLLING; /* found or not... */ + ifp->if_flags &= ~IFF_POLLING; /* found or not... */ if (i == poll_handlers) { mtx_unlock(&Giant); printf("ether_poll_deregister: ifp not found!!!\n"); diff -druN src.preflags/sys/net/if.c src/sys/net/if.c --- src.preflags/sys/net/if.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/if.c Fri Aug 16 16:32:50 2002 @@ -1234,6 +1234,7 @@ struct ifreq *ifr; struct ifstat *ifs; int error = 0; + int new_flags; ifr = (struct ifreq *)data; switch (cmd) { @@ -1242,7 +1243,8 @@ break; case SIOCGIFFLAGS: - ifr->ifr_flags = ifp->if_flags; + ifr->ifr_flags = ifp->if_flags & 0xffff; + ifr->ifr_flagshigh = ifp->if_flags >> 16; break; case SIOCGIFCAP: @@ -1272,22 +1274,22 @@ error = suser(td); if (error) return (error); - ifr->ifr_prevflags = ifp->if_flags; + new_flags = ifr->ifr_flags | (ifr->ifr_flagshigh << 16); if (ifp->if_flags & IFF_SMART) { /* Smart drivers twiddle their own routes */ } else if (ifp->if_flags & IFF_UP && - (ifr->ifr_flags & IFF_UP) == 0) { + (new_flags & IFF_UP) == 0) { int s = splimp(); if_down(ifp); splx(s); - } else if (ifr->ifr_flags & IFF_UP && + } else if (new_flags & IFF_UP && (ifp->if_flags & IFF_UP) == 0) { int s = splimp(); if_up(ifp); splx(s); } ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) | - (ifr->ifr_flags &~ IFF_CANTCHANGE); + (new_flags &~ IFF_CANTCHANGE); if (ifp->if_ioctl) (void) (*ifp->if_ioctl)(ifp, cmd, data); getmicrotime(&ifp->if_lastchange); @@ -1438,7 +1440,7 @@ struct ifnet *ifp; struct ifreq *ifr; int error; - short oif_flags; + int oif_flags; switch (cmd) { case SIOCGIFCONF: @@ -1573,7 +1575,8 @@ return (0); ifp->if_flags &= ~IFF_PROMISC; } - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); if (error == 0) { log(LOG_INFO, "%s%d: promiscuous mode %s\n", @@ -1695,7 +1698,8 @@ if (onswitch) { if (ifp->if_amcount++ == 0) { ifp->if_flags |= IFF_ALLMULTI; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = ifp->if_ioctl(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); } } else { @@ -1704,7 +1708,8 @@ } else { ifp->if_amcount = 0; ifp->if_flags &= ~IFF_ALLMULTI; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff;; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = ifp->if_ioctl(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); } } @@ -1919,10 +1924,12 @@ */ if ((ifp->if_flags & IFF_UP) != 0) { ifp->if_flags &= ~IFF_UP; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); ifp->if_flags |= IFF_UP; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); #ifdef INET /* diff -druN src.preflags/sys/net/if.h src/sys/net/if.h --- src.preflags/sys/net/if.h Thu Aug 15 09:47:58 2002 +++ src/sys/net/if.h Fri Aug 16 16:09:01 2002 @@ -139,14 +139,6 @@ #define IFF_LINK2 0x4000 /* per link layer defined bit */ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connection */ #define IFF_MULTICAST 0x8000 /* supports multicast */ - -/* - * The following flag(s) ought to go in if_flags, but we cannot change - * struct ifnet because of binary compatibility, so we store them in - * if_ipending, which is not used so far. - * If possible, make sure the value is not conflicting with other - * IFF flags, so we have an easier time when we want to merge them. - */ #define IFF_POLLING 0x10000 /* Interface is in polling mode. */ /* flags set internally only: */ @@ -244,8 +236,8 @@ #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ -#define ifr_flags ifr_ifru.ifru_flags[0] /* flags */ -#define ifr_prevflags ifr_ifru.ifru_flags[1] /* flags */ +#define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ +#define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_metric ifr_ifru.ifru_metric /* metric */ #define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ #define ifr_phys ifr_ifru.ifru_phys /* physical wire */ diff -druN src.preflags/sys/net/if_tap.c src/sys/net/if_tap.c --- src.preflags/sys/net/if_tap.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/if_tap.c Thu Aug 15 19:30:15 2002 @@ -654,7 +654,7 @@ struct ifnet *ifp = &tp->tap_if; struct tapinfo *tapp = NULL; int s; - short f; + int f; switch (cmd) { case TAPSIFINFO: @@ -728,7 +728,7 @@ break; case VMIO_SIOCSIFFLAGS: /* VMware/VMnet SIOCSIFFLAGS */ - f = *(short *)data; + f = *(int *)data; f &= 0x0fff; f &= ~IFF_CANTCHANGE; f |= IFF_UP; diff -druN src.preflags/sys/net/if_var.h src/sys/net/if_var.h --- src.preflags/sys/net/if_var.h Thu Aug 15 09:47:58 2002 +++ src/sys/net/if_var.h Thu Aug 15 19:30:41 2002 @@ -138,7 +138,7 @@ u_short if_index; /* numeric abbreviation for this if */ short if_unit; /* sub-unit for lower level driver */ short if_timer; /* time 'til if_watchdog called */ - short if_flags; /* up/down, broadcast, etc. */ + int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ int if_ipending; /* interrupts pending */ diff -druN src.preflags/sys/net/rtsock.c src/sys/net/rtsock.c --- src.preflags/sys/net/rtsock.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/rtsock.c Thu Aug 15 19:36:03 2002 @@ -757,7 +757,7 @@ return; ifm = mtod(m, struct if_msghdr *); ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; route_proto.sp_protocol = 0; @@ -958,7 +958,7 @@ ifm = (struct if_msghdr *)w->w_tmem; ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = info.rti_addrs; error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); diff -druN src.preflags/sys/netatm/atm_if.c src/sys/netatm/atm_if.c --- src.preflags/sys/netatm/atm_if.c Thu Aug 15 09:47:58 2002 +++ src/sys/netatm/atm_if.c Thu Aug 15 21:32:44 2002 @@ -1057,7 +1057,7 @@ break; case SIOCGIFFLAGS: - *(short *)data = ifp->if_flags; + *(int *)data = ifp->if_flags; break; case SIOCSIFFLAGS: diff -druN src.preflags/sys/netinet6/in6_var.h src/sys/netinet6/in6_var.h --- src.preflags/sys/netinet6/in6_var.h Thu Aug 15 09:47:58 2002 +++ src/sys/netinet6/in6_var.h Thu Aug 15 20:24:38 2002 @@ -234,7 +234,7 @@ union { struct sockaddr_in6 ifru_addr; struct sockaddr_in6 ifru_dstaddr; - short ifru_flags; + int ifru_flags; int ifru_flags6; int ifru_metric; caddr_t ifru_data; diff -druN src.preflags/sys/nfsclient/bootp_subr.c src/sys/nfsclient/bootp_subr.c --- src.preflags/sys/nfsclient/bootp_subr.c Thu Aug 15 09:47:59 2002 +++ src/sys/nfsclient/bootp_subr.c Thu Aug 15 20:38:55 2002 @@ -385,7 +385,7 @@ printf("%s%d flags %x, addr ", ifp->if_name, ifp->if_unit, - (unsigned short) ifp->if_flags); + ifp->if_flags); print_sin_addr((struct sockaddr_in *) ifa->ifa_addr); printf(", broadcast "); print_sin_addr((struct sockaddr_in *) ifa->ifa_dstaddr); diff -druN src.preflags/sys/pci/if_dc.c src/sys/pci/if_dc.c --- src.preflags/sys/pci/if_dc.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_dc.c Thu Aug 15 21:18:57 2002 @@ -2483,7 +2483,7 @@ while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -2885,7 +2885,7 @@ DC_LOCK(sc); ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(dc_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, DC_IMR, 0x00000000); @@ -3265,7 +3265,7 @@ * the case of polling. Some cards (e.g. fxp) turn interrupts on * after a reset. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, DC_IMR, 0x00000000); else #endif diff -druN src.preflags/sys/pci/if_rl.c src/sys/pci/if_rl.c --- src.preflags/sys/pci/if_rl.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_rl.c Thu Aug 15 21:18:25 2002 @@ -1187,7 +1187,7 @@ while((CSR_READ_1(sc, RL_COMMAND) & RL_CMD_EMPTY_RXBUF) == 0) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1416,7 +1416,7 @@ ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(rl_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_2(sc, RL_IMR, 0x0000); @@ -1654,7 +1654,7 @@ /* * Disable interrupts if we are polling. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_2(sc, RL_IMR, 0); else /* otherwise ... */ #endif /* DEVICE_POLLING */ diff -druN src.preflags/sys/pci/if_sis.c src/sys/pci/if_sis.c --- src.preflags/sys/pci/if_sis.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_sis.c Thu Aug 15 21:18:41 2002 @@ -1285,7 +1285,7 @@ while(SIS_OWNDESC(&sc->sis_ldata.sis_rx_list[i])) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1508,7 +1508,7 @@ SIS_LOCK(sc); #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(sis_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, SIS_IER, 0); @@ -1810,7 +1810,7 @@ * ... only enable interrupts if we are not polling, make sure * they are off otherwise. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, SIS_IER, 0); else #endif /* DEVICE_POLLING */ diff -druN src.preflags/usr.sbin/mrouted/config.c src/usr.sbin/mrouted/config.c --- src.preflags/usr.sbin/mrouted/config.c Thu Aug 15 09:48:00 2002 +++ src/usr.sbin/mrouted/config.c Thu Aug 15 20:59:36 2002 @@ -32,7 +32,7 @@ register vifi_t vifi; int n; u_int32 addr, mask, subnet; - short flags; + int flags; int num_ifreq = 32; ifc.ifc_len = num_ifreq * sizeof(struct ifreq); --%--multipart-mixed-boundary-1.5686.1029506090--%-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 7:13:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0661E37B400; Fri, 16 Aug 2002 07:13:46 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D27943E3B; Fri, 16 Aug 2002 07:13:44 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GEDV222632; Fri, 16 Aug 2002 16:13:31 +0200 (MEST) Date: Fri, 16 Aug 2002 16:13:31 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Harti Brandt , Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161354.g7GDsoup005697@vega.vega.com> Message-ID: <20020816160306.S24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020816160306.B24938@beagle.fokus.gmd.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>BTW, I've just realised that we can easily avoid breaking application MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> atomic rollback. MS> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>ifr_prevflags was added with the following log message (rev.1.50): MS> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS> before they got changed. This can help eliminate much of the MS> gymnastics drivers do in their ioctl routines to figure this out. MS> MS>but no drivers are using it so far. I veryfied only net-snmp-current. It doesn't use it (I guess that variable is not SNMP-writeable in net-snmp). I use it however in the bsnmp daemon for NgATM. Its the only way to guarantee the atomicity required by SNMP. Removing something from the ABI which you cannot do otherwise from userspace is always a problem, because it may break 3rd party software (I mean not binary breakage, but functional breakage). Well, while thinking about it: With a user settable PROXY flag there is no way for an application to find out whether the flag was already set or not if the application sets it, excpect by inspecting the ifr_prevflags field. So two applications fiddling with this bit may entirly confuse each other. Count me as a vote for keeping the field and breaking binary compatibility instead of functionality. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 7:27: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CAA37B400; Fri, 16 Aug 2002 07:27:01 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8225243E6E; Fri, 16 Aug 2002 07:26:59 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GEQhZ86553; Fri, 16 Aug 2002 17:26:44 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GEQbWe005814; Fri, 16 Aug 2002 17:26:37 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GEQaxc005813; Fri, 16 Aug 2002 17:26:36 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161426.g7GEQaxc005813@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: brandt@fokus.gmd.de (Harti Brandt) Date: Fri, 16 Aug 2002 17:26:36 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), brandt@fokus.gmd.de (Harti Brandt), bde@zeta.org.au (Bruce Evans), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816160306.S24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > MS>> > MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: > MS>> > MS>> MS>BTW, I've just realised that we can easily avoid breaking application > MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > MS>> MS>for storing another 16 flags. What do people think? > MS>> > MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary > MS>> atomic rollback. > MS> > MS>Could you please verify? Nothing in the base system uses it. Initially, > MS>ifr_prevflags was added with the following log message (rev.1.50): > MS> > MS> Since ifru_flags is a short, we can fit in a copy of the flags > MS> before they got changed. This can help eliminate much of the > MS> gymnastics drivers do in their ioctl routines to figure this out. > MS> > MS>but no drivers are using it so far. > > I veryfied only net-snmp-current. It doesn't use it (I guess that > variable is not SNMP-writeable in net-snmp). I use it however in the > bsnmp daemon for NgATM. Its the only way to guarantee the atomicity > required by SNMP. > > Removing something from the ABI which you cannot do otherwise from > userspace is always a problem, because it may break 3rd party software > (I mean not binary breakage, but functional breakage). > > Well, while thinking about it: With a user settable PROXY flag there is no > way for an application to find out whether the flag was already set or not > if the application sets it, excpect by inspecting the ifr_prevflags field. > So two applications fiddling with this bit may entirly confuse each other. > Count me as a vote for keeping the field and breaking binary compatibility > instead of functionality. Hmm, I do not really see how this flag may help your application. To set or reset some flag from if_flags you have to read current values of those flags, so that you can use that value instead of ifr_prevflags. Of course it introduces some tiny race condition, but I do not see how presence of ifr_prevflags can help you in this case. Moreover, possibility of such race IMO is quite low, as interface flags are usually updated very rarely. Instead your bsnmp daemons should be using other ways to serialise write access to interface flags (e.g. lock file). -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 7:34:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA53A37B400; Fri, 16 Aug 2002 07:34:36 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BED843E6A; Fri, 16 Aug 2002 07:34:35 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GEYP226473; Fri, 16 Aug 2002 16:34:26 +0200 (MEST) Date: Fri, 16 Aug 2002 16:34:25 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Harti Brandt , Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161426.g7GEQaxc005813@vega.vega.com> Message-ID: <20020816162923.S24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>BTW, I've just realised that we can easily avoid breaking application MS>> MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> MS>> atomic rollback. MS>> MS> MS>> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>> MS>ifr_prevflags was added with the following log message (rev.1.50): MS>> MS> MS>> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS>> MS> before they got changed. This can help eliminate much of the MS>> MS> gymnastics drivers do in their ioctl routines to figure this out. MS>> MS> MS>> MS>but no drivers are using it so far. MS>> MS>> I veryfied only net-snmp-current. It doesn't use it (I guess that MS>> variable is not SNMP-writeable in net-snmp). I use it however in the MS>> bsnmp daemon for NgATM. Its the only way to guarantee the atomicity MS>> required by SNMP. MS>> MS>> Removing something from the ABI which you cannot do otherwise from MS>> userspace is always a problem, because it may break 3rd party software MS>> (I mean not binary breakage, but functional breakage). MS>> MS>> Well, while thinking about it: With a user settable PROXY flag there is no MS>> way for an application to find out whether the flag was already set or not MS>> if the application sets it, excpect by inspecting the ifr_prevflags field. MS>> So two applications fiddling with this bit may entirly confuse each other. MS>> Count me as a vote for keeping the field and breaking binary compatibility MS>> instead of functionality. MS> MS>Hmm, I do not really see how this flag may help your application. To set or MS>reset some flag from if_flags you have to read current values of those MS>flags, so that you can use that value instead of ifr_prevflags. Of course MS>it introduces some tiny race condition, but I do not see how presence of MS>ifr_prevflags can help you in this case. Moreover, possibility of such MS>race IMO is quite low, as interface flags are usually updated very rarely. Well, yes, you are right that I cannot prevent the race. MS>Instead your bsnmp daemons should be using other ways to serialise write MS>access to interface flags (e.g. lock file). This would require all programs that fiddle with interface flags to use that same lock file (including ifconfig). It seems rather silly to me to use a heavy weight lock file, to fiddle with a kernel flag. Ok, I take my vote back :-) kill ifr_prevflags harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 8:21:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1311437B405 for ; Fri, 16 Aug 2002 08:21:14 -0700 (PDT) Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D70843E42 for ; Fri, 16 Aug 2002 08:21:13 -0700 (PDT) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu ([12.216.242.20]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020816152113.UZOU7903.sccmmhc02.mchsi.com@math.missouri.edu> for ; Fri, 16 Aug 2002 15:21:13 +0000 Message-ID: <3D5D1863.2050209@math.missouri.edu> Date: Fri, 16 Aug 2002 10:21:07 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: runtime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG How do I do the following: 1) Find out how much time a program has currently consumed in computer time (something like what the time command outputs - but I want the program to do find this out about itself); 2) Have a thread wait for a specified amount of computer time (not actual time so nanosleep won't work). I looked at the man pages, but all I could find was runtime which seems only to be accessible from the kernel. -- Stephen Montgomery-Smith stephen@math.missouri.edu http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 8:28:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD51537B400 for ; Fri, 16 Aug 2002 08:28:32 -0700 (PDT) Received: from mail.asitatech.com (mail.asitatech.ie [193.120.151.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCAC143E70 for ; Fri, 16 Aug 2002 08:28:31 -0700 (PDT) (envelope-from devnull@asitatech.ie) Received: from yoda.asitatech.ie ([192.168.127.212]) by mail.asitatech.com (Merak 4.2.3) with ESMTP id FJA37319 for ; Fri, 16 Aug 2002 16:25:22 +0100 Received: by yoda.asitatech.ie (Postfix, from userid 1001) id A9E975A59; Fri, 16 Aug 2002 16:31:25 +0000 (GMT) Date: Fri, 16 Aug 2002 16:31:25 +0000 From: Sergey Lyubka To: freebsd-hackers@freebsd.org Subject: Re: runtime Message-ID: <20020816163125.GB12216@yoda.asitatech.ie> Mail-Followup-To: freebsd-hackers@freebsd.org References: <3D5D1863.2050209@math.missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5D1863.2050209@math.missouri.edu> User-Agent: Mutt/1.3.27i X-OS: FreeBSD 4.5-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Would getrusage() help ? On Fri, Aug 16, 2002 at 10:21:07AM -0500, Stephen Montgomery-Smith wrote: > How do I do the following: > > 1) Find out how much time a program has currently consumed in computer > time (something like what the time command outputs - but I want the > program to do find this out about itself); > > 2) Have a thread wait for a specified amount of computer time (not > actual time so nanosleep won't work). > > I looked at the man pages, but all I could find was runtime which seems > only to be accessible from the kernel. -- Sergey Lyubka Asita Technologies Int, Galway, Ireland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 8:31:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA39E37B400 for ; Fri, 16 Aug 2002 08:31:09 -0700 (PDT) Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AFB643E7B for ; Fri, 16 Aug 2002 08:31:09 -0700 (PDT) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu ([12.216.242.20]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020816153108.VSEA23220.sccmmhc01.mchsi.com@math.missouri.edu> for ; Fri, 16 Aug 2002 15:31:08 +0000 Message-ID: <3D5D1ABC.4080102@math.missouri.edu> Date: Fri, 16 Aug 2002 10:31:08 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: runtime References: <3D5D1863.2050209@math.missouri.edu> <20020816163125.GB12216@yoda.asitatech.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It looks like exactly what I want. Thanks. Sergey Lyubka wrote: > Would getrusage() help ? > > On Fri, Aug 16, 2002 at 10:21:07AM -0500, Stephen Montgomery-Smith wrote: > >>How do I do the following: >> >>1) Find out how much time a program has currently consumed in computer >>time (something like what the time command outputs - but I want the >>program to do find this out about itself); >> >>2) Have a thread wait for a specified amount of computer time (not >>actual time so nanosleep won't work). >> >>I looked at the man pages, but all I could find was runtime which seems >>only to be accessible from the kernel. > > -- Stephen Montgomery-Smith stephen@math.missouri.edu http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 8:33:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1DDC37B400 for ; Fri, 16 Aug 2002 08:33:47 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6F4743E77 for ; Fri, 16 Aug 2002 08:33:47 -0700 (PDT) (envelope-from ryans@gamersimpact.com) Received: from [24.207.158.217] (helo=[192.168.1.101]) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fj6f-0001PZ-00; Fri, 16 Aug 2002 08:33:45 -0700 Subject: Re: runtime From: Ryan Sommers To: Stephen Montgomery-Smith Cc: freebsd-hackers@freebsd.org In-Reply-To: <3D5D1863.2050209@math.missouri.edu> References: <3D5D1863.2050209@math.missouri.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Aug 2002 10:33:46 -0500 Message-Id: <1029512027.29404.2.camel@lobo> Mime-Version: 1.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-08-16 at 10:21, Stephen Montgomery-Smith wrote: > How do I do the following: > > 1) Find out how much time a program has currently consumed in computer > time (something like what the time command outputs - but I want the > program to do find this out about itself); 'man 5 procfs' might be a good place to start. -- Ryan "leadZERO" Sommers Gamer's Impact President ryans@gamersimpact.com ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 9: 5:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 715E137B400 for ; Fri, 16 Aug 2002 09:05:21 -0700 (PDT) Received: from mail2.qc.uunet.ca (mail2.qc.uunet.ca [198.168.54.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD71B43E6A for ; Fri, 16 Aug 2002 09:05:20 -0700 (PDT) (envelope-from anarcat@anarcat.ath.cx) Received: from xtanbul (IDENT:506@[216.94.147.34]) by mail2.qc.uunet.ca (8.9.3/8.9.3) with ESMTP id MAA12577 for ; Fri, 16 Aug 2002 12:05:12 -0400 Date: Fri, 16 Aug 2002 11:54:55 -0400 Subject: Re: runtime Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Antoine Beaupre To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <3D5D1863.2050209@math.missouri.edu> Message-Id: <8250B2F2-B130-11D6-8D53-0050E4A0BB3F@anarcat.ath.cx> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG man clocks holds all the answers. On Friday, August 16, 2002, at 11:21 AM, Stephen Montgomery-Smith wrote: > How do I do the following: > > 1) Find out how much time a program has currently consumed in computer > time (something like what the time command outputs - but I want the > program to do find this out about itself); > > 2) Have a thread wait for a specified amount of computer time (not > actual time so nanosleep won't work). > > I looked at the man pages, but all I could find was runtime which seems > only to be accessible from the kernel. > > > > -- Stephen Montgomery-Smith > stephen@math.missouri.edu > http://www.math.missouri.edu/~stephen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 10:44: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FF4F37B400 for ; Fri, 16 Aug 2002 10:44:03 -0700 (PDT) Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4911743E75 for ; Fri, 16 Aug 2002 10:44:02 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 17fkdX-00058P-00; Fri, 16 Aug 2002 18:11:48 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GHBh3H060843; Fri, 16 Aug 2002 18:11:43 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GHBcBF060842; Fri, 16 Aug 2002 18:11:38 +0100 (BST) Date: Fri, 16 Aug 2002 18:11:38 +0100 From: Jonathon McKitrick To: Larry Rosenman Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: When to consider the new scehduler? Message-ID: <20020816171138.GA60820@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> <20020816123521.GB58797@dogma.freebsd-uk.eu.org> <1029501575.404.10.camel@lerlaptop.lerctr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1029501575.404.10.camel@lerlaptop.lerctr.org> User-Agent: Mutt/1.4i X-Scanner: exiscan *17fkdX-00058P-00*QQDlbsYQm2o* (Manchester Computing, University of Manchester) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 16, 2002 at 07:39:35AM -0500, Larry Rosenman wrote: | On Fri, 2002-08-16 at 07:35, Jonathon McKitrick wrote: | > | > Why don't they just add an extra CPU to handle the GUI?? ;-) | > | | > | They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) | > | > I thought only NT-SMP did that. I *thought* I was being funny. :-) | SVR4.2 is a totally threaded kernel. SVR5 (UnixWare 7/OpenUNIX 8) takes | it even further. I run an OpenUnix 8+ box in addition to FreeBSD. if | any FreeBSD developers want a shell account to look around, I can | arrange it. | | [snip] I was just making a joke about how (IIRC) Win2K's use of a second CPU in the default setting is just to offload all of the GUI handling to it, so the UI stays snappy even when the machine is heavily loaded. I would expect more advanced OS's to use a much better scheduler to make better use of the other CPU. jm -- My other computer is your Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 10:47:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE20337B400 for ; Fri, 16 Aug 2002 10:47:14 -0700 (PDT) Received: from lerlaptop.iadfw.net (lerlaptop.iadfw.net [206.66.13.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7858743E7B for ; Fri, 16 Aug 2002 10:47:14 -0700 (PDT) (envelope-from ler@lerctr.org) Received: from localhost (localhost [127.0.0.1]) by lerlaptop.iadfw.net (8.12.5/8.12.5) with ESMTP id g7GHjnCp061489; Fri, 16 Aug 2002 12:45:53 -0500 (CDT) (envelope-from ler@lerctr.org) Subject: Re: When to consider the new scehduler? From: Larry Rosenman To: Jonathon McKitrick Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020816171138.GA60820@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> <20020816123521.GB58797@dogma.freebsd-uk.eu.org> <1029501575.404.10.camel@lerlaptop.lerctr.org> <20020816171138.GA60820@dogma.freebsd-uk.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Aug 2002 12:45:49 -0500 Message-Id: <1029519957.477.37.camel@lerlaptop.iadfw.net> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-08-16 at 12:11, Jonathon McKitrick wrote: > On Fri, Aug 16, 2002 at 07:39:35AM -0500, Larry Rosenman wrote: > | On Fri, 2002-08-16 at 07:35, Jonathon McKitrick wrote: > | > | > Why don't they just add an extra CPU to handle the GUI?? ;-) > | > | > | > | They did. 4.0.2 was the ES/MP (Enhanced Security/Multi Processing) > | > > | > I thought only NT-SMP did that. I *thought* I was being funny. :-) > | SVR4.2 is a totally threaded kernel. SVR5 (UnixWare 7/OpenUNIX 8) takes > | it even further. I run an OpenUnix 8+ box in addition to FreeBSD. if > | any FreeBSD developers want a shell account to look around, I can > | arrange it. > | > | [snip] > > I was just making a joke about how (IIRC) Win2K's use of a second CPU > in the default setting is just to offload all of the GUI handling to > it, so the UI stays snappy even when the machine is heavily loaded. I > would expect more advanced OS's to use a much better scheduler to > make better use of the other CPU. OIC. Just trying to get more information out. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 12:47:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B26037B400 for ; Fri, 16 Aug 2002 12:47:57 -0700 (PDT) Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 627AB43E6A for ; Fri, 16 Aug 2002 12:47:55 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 17fn4Q-000AQf-00; Fri, 16 Aug 2002 20:47:42 +0100 Received: from dogma.freebsd-uk.eu.org (localhost [127.0.0.1]) by dogma.freebsd-uk.eu.org (8.12.3/8.11.1) with ESMTP id g7GJlf3H061695; Fri, 16 Aug 2002 20:47:41 +0100 (BST) (envelope-from jcm@dogma.freebsd-uk.eu.org) Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.12.3/8.12.3/Submit) id g7GJlfrh061694; Fri, 16 Aug 2002 20:47:41 +0100 (BST) Date: Fri, 16 Aug 2002 20:47:41 +0100 From: Jonathon McKitrick To: Larry Rosenman Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: When to consider the new scehduler? Message-ID: <20020816194741.GA61677@dogma.freebsd-uk.eu.org> References: <20020816104037.GA58453@dogma.freebsd-uk.eu.org> <3D5CDF48.9C9B30ED@mindspring.com> <20020816115957.GA58797@dogma.freebsd-uk.eu.org> <3D5CEE39.51E55574@mindspring.com> <20020816123521.GB58797@dogma.freebsd-uk.eu.org> <1029501575.404.10.camel@lerlaptop.lerctr.org> <20020816171138.GA60820@dogma.freebsd-uk.eu.org> <1029519957.477.37.camel@lerlaptop.iadfw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1029519957.477.37.camel@lerlaptop.iadfw.net> User-Agent: Mutt/1.4i X-Scanner: exiscan *17fn4Q-000AQf-00*k.lXV5thEXU* (Manchester Computing, University of Manchester) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG | OIC. Just trying to get more information out. Still appreciated. I just didn't want my joke to *totally* go to waste, pathetic though it was. :-) jm -- My other computer is your Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 14:56: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACE0837B400 for ; Fri, 16 Aug 2002 14:55:58 -0700 (PDT) Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0EAE43E75 for ; Fri, 16 Aug 2002 14:55:57 -0700 (PDT) (envelope-from osgene@web.de) Received: from [80.132.116.249] (helo=badger.home) by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2) id 17fp4W-0007VY-00 for freebsd-hackers@freebsd.org; Fri, 16 Aug 2002 23:55:56 +0200 Received: (from gene@localhost) by badger.home (8.12.5/8.12.5) id g7GLu3Nm000211 for freebsd-hackers@freebsd.org; Fri, 16 Aug 2002 23:56:03 +0200 (CEST) (envelope-from gene) Date: Fri, 16 Aug 2002 23:56:03 +0200 From: Eugene Ossintsev To: freebsd-hackers@freebsd.org Subject: strange name of a device Message-ID: <20020816235603.A181@localhost> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hallo, Who knows, why that device is so funny named? from dmesg: acd0: CD-RW <@A CD\^LB C\^E $81"0B> at ata1-master PIO4 ^^^^^^^^^^^^^^^^^^^^^^^ It varies from stable to stable. Sometimes it's displayed correctly as acd0: CD-RW at ata1-master PIO4 -- Eugene Ossintsev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 16:40:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE6B37B400; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9171243E3B; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 6B56E2A7D6; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: ikostov@otel.net (Iasen Kostov), julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161222.g7GCM8Rt005388@vega.vega.com> Date: Fri, 16 Aug 2002 16:40:50 -0700 From: Peter Wemm Message-Id: <20020816234050.6B56E2A7D6@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > > There is no much point in this patch, because it will increase size of > > > struct ifreq, which means that no ioctl's from older apps will be accept ed > > > anyway. Therefore, there is no difference between those two, while my > > > approach is obviously cleaner. > > > > It does not increase size of struct ifreq. > > This is a union not a struct as You see. > > Oh, yes, you are obviously correct. However, I still wonder if your patch > is endianless-safe. FWIW, for 4.x, endianness is not a problem since all the 4.x platforms are little-endian. For 5.x we should make a clean break. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 16:45: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCB7A37B400 for ; Fri, 16 Aug 2002 16:44:57 -0700 (PDT) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262E143E42 for ; Fri, 16 Aug 2002 16:44:57 -0700 (PDT) (envelope-from *********@aol.com) Received: from *********@aol.com by imo-m03.mx.aol.com (mail_out_v33.5.) id n.ac.2bf39af0 (16484) for ; Fri, 16 Aug 2002 19:44:47 -0400 (EDT) From: *********@aol.com Message-ID: Date: Fri, 16 Aug 2002 19:44:47 EDT Subject: Want something to do? To: hackers@freebsd.org MIME-Version: 1.0 XXXXXXX-Type: ********************************************************************* X-Mailer: AOL 7.0 for Windows US sub 10513 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ************************************* ******************************************** ******************************* *************************************************************************** ************************************************************************** *********************************************************************** ***************************************************************************** ***************************************************************************** *************************************************************************** *************************************************************************** **************************************************************************** *********************************************************************** **************************************************************************** ********************************************************************** ************************************************************************* ***************************************************************************** ****************************************************************************** ***************************************************************************** **************************************************************************** ************************************************************************** ************************************************************************ ****************************************************************************** **************** *************************************************************** ************************************* ******************************************* ******************************* ****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** **** ***************************************************************************** *************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 19:14:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D259337B400 for ; Fri, 16 Aug 2002 19:14:26 -0700 (PDT) Received: from priv-edtnes28.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1472D43E6A for ; Fri, 16 Aug 2002 19:14:26 -0700 (PDT) (envelope-from sh@planetquake.com) Received: from dbs ([64.180.172.142]) by priv-edtnes28.telusplanet.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020817021425.GHNN25741.priv-edtnes28.telusplanet.net@dbs> for ; Fri, 16 Aug 2002 20:14:25 -0600 Message-ID: <000701c24593$ceb71810$8eacb440@slugabed.org> From: "Sean Hamilton" To: Subject: microuptime() and nanouptime() library? Date: Fri, 16 Aug 2002 19:14:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings, I just tried to use nanouptime, then microuptime, but was disappointed to find that a quick grep of /usr/lib revealed no libraries containing these symbols. Are they only available to the kernel. If so, how can I get a reasonable timer figure from user space? thanks, sh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 19:20:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3356737B400 for ; Fri, 16 Aug 2002 19:20:12 -0700 (PDT) Received: from squall.waterspout.com (squall.waterspout.com [208.13.56.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE0D743E6A for ; Fri, 16 Aug 2002 19:20:06 -0700 (PDT) (envelope-from will@csociety.org) Received: by squall.waterspout.com (Postfix, from userid 1050) id 21A669B3A; Fri, 16 Aug 2002 21:20:06 -0500 (EST) Date: Fri, 16 Aug 2002 21:20:06 -0500 From: Will Andrews To: Sean Hamilton Cc: hackers@freebsd.org Subject: Re: microuptime() and nanouptime() library? Message-ID: <20020817022005.GB18228@squall.waterspout.com> References: <000701c24593$ceb71810$8eacb440@slugabed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c24593$ceb71810$8eacb440@slugabed.org> User-Agent: Mutt/1.3.26i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 16, 2002 at 07:14:24PM -0700, Sean Hamilton wrote: > Greetings, > > I just tried to use nanouptime, then microuptime, but was disappointed to > find that a quick grep of /usr/lib revealed no libraries containing these > symbols. > > Are they only available to the kernel. If so, how can I get a reasonable > timer figure from user space? Yes, they are limited to kernel space, as the section they belong to implies: <1 5005-0> (21:16:41) [will@puck ~]% man 9 nanouptime|head -5 MICROUPTIME(9) FreeBSD Kernel Developer's Manual MICROUPTIME(9) NAME microuptime, getmicrouptime, nanouptime, getnanouptime - get the time elapsed since boot gettimeofday() will return a 'struct timeval' which is accurate to the microsecond. There is also a 'struct timespec' defined in sys/time.h but I believe it is restricted to kernel use (and nanotime() with it). [..checking stuff..] Actually.. perhaps not. See clock_gettime(2), but I know nothing about that system call. It does appear to be similar to gettimeofday() semantically and is a POSIX function, so it should also be portable. Regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 19:34: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F83B37B400; Fri, 16 Aug 2002 19:33:43 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22ED743E6E; Fri, 16 Aug 2002 19:33:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7H2Xgdc047570; Fri, 16 Aug 2002 19:33:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7H2XgqG047569; Fri, 16 Aug 2002 19:33:42 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Aug 2002 19:33:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200208170233.g7H2XgqG047569@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Commit schedule for bandwidth delay product pipeline limiting for TCP References: <200207200103.g6K135Ap081155@apollo.backplane.com> <3D3AB5AF.F2F637C3@pipeline.ch> <200207211747.g6LHlKHv003686@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, I'm back from vacation. I see nobody in the general group has commented much on my bandwidth delay product code. A couple of people have corresponded with me in email and generally the response is positive. Since this code must be enabled via a sysctl I feel it is safe to commit it to -current. I also intend to MFC it to -stable prior to the freeze (MFC after: 1 week). I believe that we can eventually enable the sysctl by default. I intend to commit this code on Saturday (tomorrow). I've included the patch set below for those who need a reminder of what this is. Generally speaking this code is very similar, though not intended to duplicate, the algorithm described by the TCP Vegas paper. I will also commit manual page updates to tcp(4) and tuning(7) to describe the effects of the sysctls. -Matt Index: netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.169 diff -u -r1.169 tcp_input.c --- netinet/tcp_input.c 15 Aug 2002 18:51:26 -0000 1.169 +++ netinet/tcp_input.c 17 Aug 2002 02:24:01 -0000 @@ -1018,6 +1018,7 @@ else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); acked = th->th_ack - tp->snd_una; tcpstat.tcps_rcvackpack++; tcpstat.tcps_rcvackbyte += acked; @@ -1819,6 +1820,7 @@ tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); /* * If all outstanding data is acked, stop retransmit @@ -2445,6 +2447,8 @@ delta -= tp->t_rttvar >> (TCP_RTTVAR_SHIFT - TCP_DELTA_SHIFT); if ((tp->t_rttvar += delta) <= 0) tp->t_rttvar = 1; + if (tp->t_rttbest > tp->t_srtt + tp->t_rttvar) + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } else { /* * No rtt measurement yet - use the unsmoothed rtt. @@ -2453,6 +2457,7 @@ */ tp->t_srtt = rtt << TCP_RTT_SHIFT; tp->t_rttvar = rtt << (TCP_RTTVAR_SHIFT - 1); + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } tp->t_rtttime = 0; tp->t_rxtshift = 0; @@ -2592,6 +2597,7 @@ if (rt->rt_rmx.rmx_locks & RTV_RTT) tp->t_rttmin = rtt / (RTM_RTTUNIT / hz); tp->t_srtt = rtt / (RTM_RTTUNIT / (hz * TCP_RTT_SCALE)); + tp->t_rttbest = tp->t_srtt + TCP_RTT_SCALE; tcpstat.tcps_usedrtt++; if (rt->rt_rmx.rmx_rttvar) { tp->t_rttvar = rt->rt_rmx.rmx_rttvar / Index: netinet/tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.67 diff -u -r1.67 tcp_output.c --- netinet/tcp_output.c 12 Aug 2002 03:22:46 -0000 1.67 +++ netinet/tcp_output.c 17 Aug 2002 02:24:01 -0000 @@ -168,6 +168,7 @@ sendalot = 0; off = tp->snd_nxt - tp->snd_una; win = min(tp->snd_wnd, tp->snd_cwnd); + win = min(win, tp->snd_bwnd); flags = tcp_outflags[tp->t_state]; /* @@ -780,7 +781,7 @@ tp->snd_max = tp->snd_nxt; /* * Time this transmission if not a retransmission and - * not currently timing anything. + * not currently timing anything. */ if (tp->t_rtttime == 0) { tp->t_rtttime = ticks; Index: netinet/tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.140 diff -u -r1.140 tcp_subr.c --- netinet/tcp_subr.c 1 Aug 2002 03:54:43 -0000 1.140 +++ netinet/tcp_subr.c 17 Aug 2002 02:24:01 -0000 @@ -146,6 +146,32 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, isn_reseed_interval, CTLFLAG_RW, &tcp_isn_reseed_interval, 0, "Seconds between reseeding of ISN secret"); +static int tcp_inflight_enable = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_enable, CTLFLAG_RW, + &tcp_inflight_enable, 0, "Enable automatic TCP inflight data limiting"); + +static int tcp_inflight_debug = 1; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_debug, CTLFLAG_RW, + &tcp_inflight_debug, 0, "Debug TCP inflight calculations"); + +static int tcp_inflight_min = 1024; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_min, CTLFLAG_RW, + &tcp_inflight_min, 0, "Lower-bound for TCP inflight window"); + +static int tcp_inflight_max = TCP_MAXWIN << TCP_MAX_WINSHIFT; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_max, CTLFLAG_RW, + &tcp_inflight_max, 0, "Upper-bound for TCP inflight window"); + +#if 0 +static int tcp_inflight_attack = 20; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_attack, CTLFLAG_RW, + &tcp_inflight_attack, 0, "TCP inflight compensation attack rate (%)"); + +static int tcp_inflight_shift = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_shift, CTLFLAG_RW, + &tcp_inflight_shift, 0, "TCP inflight compensation shift (+/-100) "); +#endif + static void tcp_cleartaocache(void); static struct inpcb *tcp_notify(struct inpcb *, int); @@ -566,8 +592,10 @@ tp->t_rttmin = tcp_rexmit_min; tp->t_rxtcur = TCPTV_RTOBASE; tp->snd_cwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->snd_ssthresh = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->t_rcvtime = ticks; + tp->t_bw_rtttime = ticks; /* * IPv4 TTL initialization is necessary for an IPv6 socket as well, * because the socket may be bound to an IPv6 wildcard address, @@ -1531,3 +1559,101 @@ tcp_cleartaocache() { } + +/* + * This code attempts to calculate the bandwidth-delay product. + * The problem with calculating this product is that our manipulation + * of the congestion window modifies both the perceived bandwidth + * and the srtt. It is possible to get a fairly stable maximal + * bandwidth by increasing the congestion window. The bandwidth + * calculation will be fairly good even if bwnd is set very high. + * However, figuring out the minimal srtt is far more difficult + * because we do not want the TCP stream to suffer greatly and therefore + * cannot reduce the congestion window to something very small. + * + * What we do is first increase the congestion window to try to + * obtain a maximal (or at least a 'larger') bandwidth, then decrease + * the congestion window to try to obtain a minimal (or at least a 'smaller') + * rtt. We also have to detect the case where BWND is too high and + * neither increasing nor decreasing it has the desired effect on the + * calculation. By detecting this special case we can stabilize the + * algorithm and recalculate bwnd within a reasonable period of time. + */ +void +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) +{ + u_long bw; + u_long bwnd; + int save_ticks; + + /* + * If inflight_enable is disabled in the middle of a tcp connection, + * make sure snd_bwnd is effectively disabled. + */ + if (tcp_inflight_enable == 0) { + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bandwidth = 0; + return; + } + + /* + * Figure out the bandwidth. Due to the tick granularity this + * is a very rough number and it MUST be averaged over a fairly + * long period of time. + */ + save_ticks = ticks; + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) + return; + + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz / + (save_ticks - tp->t_bw_rtttime); + tp->t_bw_rtttime = save_ticks; + tp->t_bw_rtseq = ack_seq; + if (tp->t_bw_rtttime == 0) + return; + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; + + tp->snd_bandwidth = bw; + + /* + * Calculate the semi-static bandwidth delay product, plus two maximal + * segments. The additional slop puts us squarely in the sweet + * spot and also handles the bandwidth run-up case. Without the + * slop we could be locking ourselves into a lower bandwidth. + * + * Situations Handled: + * (1) prevents over-queueing of packets on LANs, especially + * high speed LANs, allowing larger TCP buffers to be + * specified. + * + * (2) able to handle increased network loads (bandwidth drops + * so bwnd drops). + * + * (3) Randomly changes the window size in order to force + * bandwidth balancing between connections. + */ +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; + + if (tcp_inflight_debug > 0) { + static int ltime; + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { + ltime = ticks; + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n", + tp, + bw, + tp->t_rttbest, + tp->t_srtt, + bwnd + ); + } + } + if ((long)bwnd < tcp_inflight_min) + bwnd = tcp_inflight_min; + if (bwnd > tcp_inflight_max) + bwnd = tcp_inflight_max; + if ((long)bwnd < tp->t_maxseg * 2) + bwnd = tp->t_maxseg * 2; + tp->snd_bwnd = bwnd; +} + Index: netinet/tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.79 diff -u -r1.79 tcp_usrreq.c --- netinet/tcp_usrreq.c 29 Jul 2002 09:01:39 -0000 1.79 +++ netinet/tcp_usrreq.c 17 Aug 2002 02:24:01 -0000 @@ -875,6 +875,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* @@ -961,6 +962,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* Index: netinet/tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.82 diff -u -r1.82 tcp_var.h --- netinet/tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 +++ netinet/tcp_var.h 21 Jul 2002 02:26:36 -0000 @@ -124,10 +124,12 @@ u_long snd_wnd; /* send window */ u_long snd_cwnd; /* congestion-controlled window */ + u_long snd_bwnd; /* bandwidth-controlled window */ u_long snd_ssthresh; /* snd_cwnd size threshold for * for slow start exponential to * linear switch */ + u_long snd_bandwidth; /* calculated bandwidth or 0 */ tcp_seq snd_recover; /* for use in fast recovery */ u_int t_maxopd; /* mss plus options */ @@ -137,6 +139,9 @@ int t_rtttime; /* round trip time */ tcp_seq t_rtseq; /* sequence number being timed */ + int t_bw_rtttime; /* used for bandwidth calculation */ + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ + int t_rxtcur; /* current retransmit value (ticks) */ u_int t_maxseg; /* maximum segment size */ int t_srtt; /* smoothed round-trip time */ @@ -144,6 +149,7 @@ int t_rxtshift; /* log(2) of rexmt exp. backoff */ u_int t_rttmin; /* minimum rtt allowed */ + u_int t_rttbest; /* best rtt we've seen */ u_long t_rttupdated; /* number of times rtt sampled */ u_long max_sndwnd; /* largest window peer has offered */ @@ -473,6 +479,7 @@ struct tcpcb * tcp_timers(struct tcpcb *, int); void tcp_trace(int, int, struct tcpcb *, void *, struct tcphdr *, int); +void tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq); void syncache_init(void); void syncache_unreach(struct in_conninfo *, struct tcphdr *); int syncache_expand(struct in_conninfo *, struct tcphdr *, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 16 21:18:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 699A037B400; Fri, 16 Aug 2002 21:18:15 -0700 (PDT) Received: from patrocles.silby.com (d129.as9.nwbl0.wi.voyager.net [169.207.133.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BAD943E77; Fri, 16 Aug 2002 21:18:14 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g7H4MJB1006877; Fri, 16 Aug 2002 23:22:19 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g7H4MI8V006874; Fri, 16 Aug 2002 23:22:19 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 16 Aug 2002 23:22:18 -0500 (CDT) From: Mike Silbersack To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP In-Reply-To: <200208170233.g7H2XgqG047569@apollo.backplane.com> Message-ID: <20020816232011.E6515-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 16 Aug 2002, Matthew Dillon wrote: > Since this code must be enabled via a sysctl I feel it is safe to > commit it to -current. I also intend to MFC it to -stable prior > to the freeze (MFC after: 1 week). I believe that we can eventually > enable the sysctl by default. That seems reasonable, it'll be interesting to see results as users play around with the feature. You still have a few lines of #if 0 in there, you might want to clean them up before committing. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 1:52:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 512EB37B400; Sat, 17 Aug 2002 01:52:49 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B78C43E42; Sat, 17 Aug 2002 01:52:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0246.cvx22-bradley.dialup.earthlink.net ([209.179.198.246] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fzKB-0001sK-00; Sat, 17 Aug 2002 01:52:48 -0700 Message-ID: <3D5E0E3F.C00C14F6@mindspring.com> Date: Sat, 17 Aug 2002 01:50:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: stable@freebsd.org Cc: jlemon@freebsd.org Subject: PATCH2: Better kqueue patches Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG OK, these patches still add support for System V message queue integration into kqueue. They also fix the problems I noted before, by adding a third parameter to KNOTE(), and fixing up the kn_fop->f_event() functions to take a third parameter. This fixes the message queue ID > 65536 problem, and also fixes the event/hint mux problem with signal and proc notes (particularly, it allows for more than 20 bits of PID, if that's ever considered desirable at some point). It also adds support for a virtual event, if the System V message queue was not empty when the filter is first attached, to avoid the need to do the poll-after-attach, and to poll on reads to avoid the potential race condition (you would still need this for multiple readers on the same queue, though... obviously). I think this code is OK to commit, if someone want to review it and commit it. Context diffs vs. -STABLE attached. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 1:55:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8E2237B400; Sat, 17 Aug 2002 01:53:47 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B5FF43E70; Sat, 17 Aug 2002 01:53:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0246.cvx22-bradley.dialup.earthlink.net ([209.179.198.246] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fzKa-00025z-00; Sat, 17 Aug 2002 01:53:13 -0700 Message-ID: <3D5E0E57.3CCF4F70@mindspring.com> Date: Sat, 17 Aug 2002 01:50:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: stable@freebsd.org Cc: jlemon@freebsd.org Subject: PATCH2: Better kqueue patches Content-Type: multipart/mixed; boundary="------------28F74B3623B344F226551D0F" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------28F74B3623B344F226551D0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, these patches still add support for System V message queue integration into kqueue. They also fix the problems I noted before, by adding a third parameter to KNOTE(), and fixing up the kn_fop->f_event() functions to take a third parameter. This fixes the message queue ID > 65536 problem, and also fixes the event/hint mux problem with signal and proc notes (particularly, it allows for more than 20 bits of PID, if that's ever considered desirable at some point). It also adds support for a virtual event, if the System V message queue was not empty when the filter is first attached, to avoid the need to do the poll-after-attach, and to poll on reads to avoid the potential race condition (you would still need this for multiple readers on the same queue, though... obviously). I think this code is OK to commit, if someone want to review it and commit it. Context diffs vs. -STABLE attached. -- Terry --------------28F74B3623B344F226551D0F Content-Type: text/plain; charset=us-ascii; name="kqueue.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kqueue.diff" Index: kern/kern_event.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_event.c,v retrieving revision 1.2.2.8 diff -c -r1.2.2.8 kern_event.c *** kern/kern_event.c 14 Dec 2001 19:24:42 -0000 1.2.2.8 --- kern/kern_event.c 17 Aug 2002 06:41:39 -0000 *************** *** 86,100 **** static void knote_free(struct knote *kn); static void filt_kqdetach(struct knote *kn); ! static int filt_kqueue(struct knote *kn, long hint); static int filt_procattach(struct knote *kn); static void filt_procdetach(struct knote *kn); ! static int filt_proc(struct knote *kn, long hint); static int filt_fileattach(struct knote *kn); static void filt_timerexpire(void *knx); static int filt_timerattach(struct knote *kn); static void filt_timerdetach(struct knote *kn); ! static int filt_timer(struct knote *kn, long hint); static struct filterops file_filtops = { 1, filt_fileattach, NULL, NULL }; --- 86,100 ---- static void knote_free(struct knote *kn); static void filt_kqdetach(struct knote *kn); ! static int filt_kqueue(struct knote *kn, long hint, long id); static int filt_procattach(struct knote *kn); static void filt_procdetach(struct knote *kn); ! static int filt_proc(struct knote *kn, long hint, long id); static int filt_fileattach(struct knote *kn); static void filt_timerexpire(void *knx); static int filt_timerattach(struct knote *kn); static void filt_timerdetach(struct knote *kn); ! static int filt_timer(struct knote *kn, long hint, long id); static struct filterops file_filtops = { 1, filt_fileattach, NULL, NULL }; *************** *** 122,127 **** --- 122,128 ---- extern struct filterops aio_filtops; extern struct filterops sig_filtops; + extern struct filterops sysvmsg_filtops; /* * Table for for all system-defined filters. *************** *** 134,139 **** --- 135,141 ---- &proc_filtops, /* EVFILT_PROC */ &sig_filtops, /* EVFILT_SIGNAL */ &timer_filtops, /* EVFILT_TIMER */ + &sysvmsg_filtops, /* EVFILT_SYSVMSG */ }; static int *************** *** 167,173 **** /*ARGSUSED*/ static int ! filt_kqueue(struct knote *kn, long hint) { struct kqueue *kq = (struct kqueue *)kn->kn_fp->f_data; --- 169,175 ---- /*ARGSUSED*/ static int ! filt_kqueue(struct knote *kn, long hint, long id) { struct kqueue *kq = (struct kqueue *)kn->kn_fp->f_data; *************** *** 225,231 **** } static int ! filt_proc(struct knote *kn, long hint) { u_int event; --- 227,233 ---- } static int ! filt_proc(struct knote *kn, long hint, long id) { u_int event; *************** *** 261,267 **** /* * register knote with new process. */ ! kev.ident = hint & NOTE_PDATAMASK; /* pid */ kev.filter = kn->kn_filter; kev.flags = kn->kn_flags | EV_ADD | EV_ENABLE | EV_FLAG1; kev.fflags = kn->kn_sfflags; --- 263,269 ---- /* * register knote with new process. */ ! kev.ident = id; /* pid */ kev.filter = kn->kn_filter; kev.flags = kn->kn_flags | EV_ADD | EV_ENABLE | EV_FLAG1; kev.fflags = kn->kn_sfflags; *************** *** 335,341 **** } static int ! filt_timer(struct knote *kn, long hint) { return (kn->kn_data != 0); --- 337,343 ---- } static int ! filt_timer(struct knote *kn, long hint, long id) { return (kn->kn_data != 0); *************** *** 542,548 **** } s = splhigh(); ! if (kn->kn_fop->f_event(kn, 0)) KNOTE_ACTIVATE(kn); splx(s); --- 544,550 ---- } s = splhigh(); ! if (kn->kn_fop->f_event(kn, 0, 0)) KNOTE_ACTIVATE(kn); splx(s); *************** *** 656,662 **** continue; } if ((kn->kn_flags & EV_ONESHOT) == 0 && ! kn->kn_fop->f_event(kn, 0) == 0) { kn->kn_status &= ~(KN_QUEUED | KN_ACTIVE); kq->kq_count--; continue; --- 658,664 ---- continue; } if ((kn->kn_flags & EV_ONESHOT) == 0 && ! kn->kn_fop->f_event(kn, 0, 0) == 0) { kn->kn_status &= ~(KN_QUEUED | KN_ACTIVE); kq->kq_count--; continue; *************** *** 823,841 **** kq->kq_state &= ~KQ_SEL; selwakeup(&kq->kq_sel); } ! KNOTE(&kq->kq_sel.si_note, 0); } /* * walk down a list of knotes, activating them if their event has triggered. */ void ! knote(struct klist *list, long hint) { struct knote *kn; SLIST_FOREACH(kn, list, kn_selnext) ! if (kn->kn_fop->f_event(kn, hint)) KNOTE_ACTIVATE(kn); } --- 825,843 ---- kq->kq_state &= ~KQ_SEL; selwakeup(&kq->kq_sel); } ! KNOTE(&kq->kq_sel.si_note, 0, 0); } /* * walk down a list of knotes, activating them if their event has triggered. */ void ! knote(struct klist *list, long hint, long id) { struct knote *kn; SLIST_FOREACH(kn, list, kn_selnext) ! if (kn->kn_fop->f_event(kn, hint, id)) KNOTE_ACTIVATE(kn); } Index: kern/kern_exec.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_exec.c,v retrieving revision 1.107.2.15 diff -c -r1.107.2.15 kern_exec.c *** kern/kern_exec.c 30 Jul 2002 15:40:46 -0000 1.107.2.15 --- kern/kern_exec.c 17 Aug 2002 06:39:09 -0000 *************** *** 366,372 **** * Notify others that we exec'd, and clear the P_INEXEC flag * as we're now a bona fide freshly-execed process. */ ! KNOTE(&p->p_klist, NOTE_EXEC); p->p_flag &= ~P_INEXEC; /* --- 366,372 ---- * Notify others that we exec'd, and clear the P_INEXEC flag * as we're now a bona fide freshly-execed process. */ ! KNOTE(&p->p_klist, NOTE_EXEC, 0); p->p_flag &= ~P_INEXEC; /* Index: kern/kern_exit.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_exit.c,v retrieving revision 1.92.2.10 diff -c -r1.92.2.10 kern_exit.c *** kern/kern_exit.c 29 Apr 2002 09:42:35 -0000 1.92.2.10 --- kern/kern_exit.c 17 Aug 2002 06:40:30 -0000 *************** *** 320,326 **** /* * notify interested parties of our demise. */ ! KNOTE(&p->p_klist, NOTE_EXIT); /* * Notify parent that we're gone. If parent has the PS_NOCLDWAIT --- 320,326 ---- /* * notify interested parties of our demise. */ ! KNOTE(&p->p_klist, NOTE_EXIT, 0); /* * Notify parent that we're gone. If parent has the PS_NOCLDWAIT Index: kern/kern_fork.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_fork.c,v retrieving revision 1.72.2.11 diff -c -r1.72.2.11 kern_fork.c *** kern/kern_fork.c 30 Jul 2002 19:05:00 -0000 1.72.2.11 --- kern/kern_fork.c 17 Aug 2002 06:41:00 -0000 *************** *** 528,534 **** /* * tell any interested parties about the new process */ ! KNOTE(&p1->p_klist, NOTE_FORK | p2->p_pid); /* * Preserve synchronization semantics of vfork. If waiting for --- 528,534 ---- /* * tell any interested parties about the new process */ ! KNOTE(&p1->p_klist, NOTE_FORK, p2->p_pid); /* * Preserve synchronization semantics of vfork. If waiting for Index: kern/kern_sig.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_sig.c,v retrieving revision 1.72.2.16 diff -c -r1.72.2.16 kern_sig.c *** kern/kern_sig.c 3 Jul 2002 14:43:27 -0000 1.72.2.16 --- kern/kern_sig.c 17 Aug 2002 06:43:10 -0000 *************** *** 84,90 **** static int filt_sigattach(struct knote *kn); static void filt_sigdetach(struct knote *kn); ! static int filt_signal(struct knote *kn, long hint); struct filterops sig_filtops = { 0, filt_sigattach, filt_sigdetach, filt_signal }; --- 84,90 ---- static int filt_sigattach(struct knote *kn); static void filt_sigdetach(struct knote *kn); ! static int filt_signal(struct knote *kn, long hint, long id); struct filterops sig_filtops = { 0, filt_sigattach, filt_sigdetach, filt_signal }; *************** *** 1012,1018 **** } s = splhigh(); ! KNOTE(&p->p_klist, NOTE_SIGNAL | sig); splx(s); prop = sigprop(sig); --- 1012,1018 ---- } s = splhigh(); ! KNOTE(&p->p_klist, NOTE_SIGNAL, sig); splx(s); prop = sigprop(sig); *************** *** 1748,1760 **** * isn't worth the trouble. */ static int ! filt_signal(struct knote *kn, long hint) { if (hint & NOTE_SIGNAL) { ! hint &= ~NOTE_SIGNAL; ! ! if (kn->kn_id == hint) kn->kn_data++; } return (kn->kn_data != 0); --- 1748,1758 ---- * isn't worth the trouble. */ static int ! filt_signal(struct knote *kn, long hint, long id) { if (hint & NOTE_SIGNAL) { ! if (kn->kn_id == id) kn->kn_data++; } return (kn->kn_data != 0); Index: kern/sys_pipe.c =================================================================== RCS file: /usr/cvs/src/sys/kern/sys_pipe.c,v retrieving revision 1.60.2.13 diff -c -r1.60.2.13 sys_pipe.c *** kern/sys_pipe.c 5 Aug 2002 15:05:15 -0000 1.60.2.13 --- kern/sys_pipe.c 17 Aug 2002 06:44:40 -0000 *************** *** 105,112 **** }; static void filt_pipedetach(struct knote *kn); ! static int filt_piperead(struct knote *kn, long hint); ! static int filt_pipewrite(struct knote *kn, long hint); static struct filterops pipe_rfiltops = { 1, NULL, filt_pipedetach, filt_piperead }; --- 105,112 ---- }; static void filt_pipedetach(struct knote *kn); ! static int filt_piperead(struct knote *kn, long hint, long id); ! static int filt_pipewrite(struct knote *kn, long hint, long id); static struct filterops pipe_rfiltops = { 1, NULL, filt_pipedetach, filt_piperead }; *************** *** 382,388 **** } if ((cpipe->pipe_state & PIPE_ASYNC) && cpipe->pipe_sigio) pgsigio(cpipe->pipe_sigio, SIGIO, 0); ! KNOTE(&cpipe->pipe_sel.si_note, 0); } /* ARGSUSED */ --- 382,388 ---- } if ((cpipe->pipe_state & PIPE_ASYNC) && cpipe->pipe_sigio) pgsigio(cpipe->pipe_sigio, SIGIO, 0); ! KNOTE(&cpipe->pipe_sel.si_note, 0, 0); } /* ARGSUSED */ *************** *** 1213,1219 **** ppipe->pipe_state |= PIPE_EOF; wakeup(ppipe); ! KNOTE(&ppipe->pipe_sel.si_note, 0); ppipe->pipe_peer = NULL; } /* --- 1213,1219 ---- ppipe->pipe_state |= PIPE_EOF; wakeup(ppipe); ! KNOTE(&ppipe->pipe_sel.si_note, 0, 0); ppipe->pipe_peer = NULL; } /* *************** *** 1260,1266 **** /*ARGSUSED*/ static int ! filt_piperead(struct knote *kn, long hint) { struct pipe *rpipe = (struct pipe *)kn->kn_fp->f_data; struct pipe *wpipe = rpipe->pipe_peer; --- 1260,1266 ---- /*ARGSUSED*/ static int ! filt_piperead(struct knote *kn, long hint, long id) { struct pipe *rpipe = (struct pipe *)kn->kn_fp->f_data; struct pipe *wpipe = rpipe->pipe_peer; *************** *** 1279,1285 **** /*ARGSUSED*/ static int ! filt_pipewrite(struct knote *kn, long hint) { struct pipe *rpipe = (struct pipe *)kn->kn_fp->f_data; struct pipe *wpipe = rpipe->pipe_peer; --- 1279,1285 ---- /*ARGSUSED*/ static int ! filt_pipewrite(struct knote *kn, long hint, long id) { struct pipe *rpipe = (struct pipe *)kn->kn_fp->f_data; struct pipe *wpipe = rpipe->pipe_peer; Index: kern/sysv_msg.c =================================================================== RCS file: /usr/cvs/src/sys/kern/sysv_msg.c,v retrieving revision 1.23.2.3 diff -c -r1.23.2.3 sysv_msg.c *** kern/sysv_msg.c 1 Nov 2000 17:58:06 -0000 1.23.2.3 --- kern/sysv_msg.c 17 Aug 2002 06:48:29 -0000 *************** *** 40,45 **** --- 40,46 ---- #undef MSG_DEBUG_OK static void msg_freehdr __P((struct msg *msghdr)); + static struct msqid_ds *msqid_to_msqptr __P((int umsqid)); /* XXX casting to (sy_call_t *) is bogus, as usual. */ static sy_call_t *msgcalls[] = { *************** *** 112,118 **** /* 0..(MSGSEG-1) -> index of next segment */ }; ! #define MSG_LOCKED 01000 /* Is this msqid_ds locked? */ static int nfree_msgmaps; /* # of free map entries */ static short free_msgmaps; /* head of linked list of free map entries */ --- 113,124 ---- /* 0..(MSGSEG-1) -> index of next segment */ }; ! struct i_msqid_ds { ! struct msqid_ds e; /* externally visable */ ! struct klist q_klist; /* filters on this message queue */ ! }; ! ! #define MSG_LOCKED 01000 /* Is this i_msqid_ds locked? */ static int nfree_msgmaps; /* # of free map entries */ static short free_msgmaps; /* head of linked list of free map entries */ *************** *** 120,126 **** static char *msgpool; /* MSGMAX byte long msg buffer pool */ static struct msgmap *msgmaps; /* MSGSEG msgmap structures */ static struct msg *msghdrs; /* MSGTQL msg headers */ ! static struct msqid_ds *msqids; /* MSGMNI msqid_ds struct's */ static void msginit(dummy) --- 126,132 ---- static char *msgpool; /* MSGMAX byte long msg buffer pool */ static struct msgmap *msgmaps; /* MSGSEG msgmap structures */ static struct msg *msghdrs; /* MSGTQL msg headers */ ! static struct i_msqid_ds *i_msqids; /* MSGMNI i_msqid_ds struct's */ static void msginit(dummy) *************** *** 137,145 **** msghdrs = malloc(sizeof(struct msg) * msginfo.msgtql, M_MSG, M_WAITOK); if (msghdrs == NULL) panic("msghdrs is NULL"); ! msqids = malloc(sizeof(struct msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); ! if (msqids == NULL) ! panic("msqids is NULL"); /* * msginfo.msgssz should be a power of two for efficiency reasons. --- 143,151 ---- msghdrs = malloc(sizeof(struct msg) * msginfo.msgtql, M_MSG, M_WAITOK); if (msghdrs == NULL) panic("msghdrs is NULL"); ! i_msqids = malloc(sizeof(struct i_msqid_ds) * msginfo.msgmni, M_MSG, M_WAITOK); ! if (i_msqids == NULL) ! panic("i_msqids is NULL"); /* * msginfo.msgssz should be a power of two for efficiency reasons. *************** *** 183,195 **** } free_msghdrs = &msghdrs[0]; ! if (msqids == NULL) ! panic("msqids is NULL"); for (i = 0; i < msginfo.msgmni; i++) { ! msqids[i].msg_qbytes = 0; /* implies entry is available */ ! msqids[i].msg_perm.seq = 0; /* reset to a known value */ ! msqids[i].msg_perm.mode = 0; } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) --- 189,201 ---- } free_msghdrs = &msghdrs[0]; ! if (i_msqids == NULL) ! panic("i_msqids is NULL"); for (i = 0; i < msginfo.msgmni; i++) { ! i_msqids[i].e.msg_qbytes = 0; /* implies entry is available */ ! i_msqids[i].e.msg_perm.seq = 0; /* reset to a known value */ ! i_msqids[i].e.msg_perm.mode = 0; } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) *************** *** 243,248 **** --- 249,288 ---- free_msghdrs = msghdr; } + static struct msqid_ds * + msqid_to_msqptr(umsqid) + int umsqid; + { + int msqid; + struct msqid_ds *msqptr = 0; + + msqid = IPCID_TO_IX(umsqid); + + if (msqid < 0 || msqid >= msginfo.msgmni) { + #ifdef MSG_DEBUG_OK + printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, + msginfo.msgmni); + #endif + } else { + + msqptr = (struct msqid_ds *)&i_msqids[msqid]; + + if (msqptr->msg_qbytes == 0) { + #ifdef MSG_DEBUG_OK + printf("no such msqid\n"); + #endif + msqptr = NULL; + } else if (msqptr->msg_perm.seq != IPCID_TO_SEQ(umsqid)) { + #ifdef MSG_DEBUG_OK + printf("wrong sequence number\n"); + msqptr = NULL; + #endif + } + } + + return(msqptr); + } + #ifndef _SYS_SYSPROTO_H_ struct msgctl_args { int msqid; *************** *** 256,262 **** struct proc *p; register struct msgctl_args *uap; { - int msqid = uap->msqid; int cmd = uap->cmd; struct msqid_ds *user_msqptr = uap->buf; int rval, eval; --- 296,301 ---- *************** *** 270,299 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif return(EINVAL); - } - - msqptr = &msqids[msqid]; - - if (msqptr->msg_qbytes == 0) { - #ifdef MSG_DEBUG_OK - printf("no such msqid\n"); - #endif - return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { - #ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); - #endif - return(EINVAL); - } eval = 0; rval = 0; --- 309,316 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); eval = 0; rval = 0; *************** *** 303,310 **** --- 320,335 ---- case IPC_RMID: { struct msg *msghdr; + int s; if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_M))) return(eval); + + /* notify intent before actually removing message queue */ + s = splhigh(); + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_IPC_RMID, uap->msqid); + splx(s); + /* Free the message headers */ msghdr = msqptr->msg_first; while (msghdr != NULL) { *************** *** 411,417 **** if (key != IPC_PRIVATE) { for (msqid = 0; msqid < msginfo.msgmni; msqid++) { ! msqptr = &msqids[msqid]; if (msqptr->msg_qbytes != 0 && msqptr->msg_perm.key == key) break; --- 436,442 ---- if (key != IPC_PRIVATE) { for (msqid = 0; msqid < msginfo.msgmni; msqid++) { ! msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes != 0 && msqptr->msg_perm.key == key) break; *************** *** 448,454 **** * they are copying the message in/out. We can't * re-use the entry until they release it. */ ! msqptr = &msqids[msqid]; if (msqptr->msg_qbytes == 0 && (msqptr->msg_perm.mode & MSG_LOCKED) == 0) break; --- 473,479 ---- * they are copying the message in/out. We can't * re-use the entry until they release it. */ ! msqptr = (struct msqid_ds *)&i_msqids[msqid]; if (msqptr->msg_qbytes == 0 && (msqptr->msg_perm.mode & MSG_LOCKED) == 0) break; *************** *** 480,485 **** --- 505,511 ---- msqptr->msg_stime = 0; msqptr->msg_rtime = 0; msqptr->msg_ctime = time_second; + bzero(&((struct i_msqid_ds *)msqptr)->q_klist, sizeof(struct klist)); } else { #ifdef MSG_DEBUG_OK printf("didn't find it and wasn't asked to create it\n"); *************** *** 507,513 **** struct proc *p; register struct msgsnd_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; int msgflg = uap->msgflg; --- 533,538 ---- *************** *** 515,520 **** --- 540,546 ---- register struct msqid_ds *msqptr; register struct msg *msghdr; short next; + int s; #ifdef MSG_DEBUG_OK printf("call to msgsnd(%d, 0x%x, %d, %d)\n", msqid, user_msgp, msgsz, *************** *** 524,552 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif ! return(EINVAL); ! } ! ! msqptr = &msqids[msqid]; ! if (msqptr->msg_qbytes == 0) { ! #ifdef MSG_DEBUG_OK ! printf("no such message queue id\n"); ! #endif return(EINVAL); - } - if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { - #ifdef MSG_DEBUG_OK - printf("wrong sequence number\n"); - #endif - return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_W))) { #ifdef MSG_DEBUG_OK --- 550,557 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_W))) { #ifdef MSG_DEBUG_OK *************** *** 812,817 **** --- 817,827 ---- msqptr->msg_lspid = p->p_pid; msqptr->msg_stime = time_second; + s = splhigh(); + KNOTE(&((struct i_msqid_ds *)msqptr)->q_klist, + NOTE_SYSVMSG, uap->msqid); + splx(s); + wakeup((caddr_t)msqptr); p->p_retval[0] = 0; return(0); *************** *** 832,838 **** struct proc *p; register struct msgrcv_args *uap; { - int msqid = uap->msqid; void *user_msgp = uap->msgp; size_t msgsz = uap->msgsz; long msgtyp = uap->msgtyp; --- 842,847 ---- *************** *** 851,879 **** if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! msqid = IPCID_TO_IX(msqid); ! ! if (msqid < 0 || msqid >= msginfo.msgmni) { ! #ifdef MSG_DEBUG_OK ! printf("msqid (%d) out of range (0<=msqid<%d)\n", msqid, ! msginfo.msgmni); ! #endif ! return(EINVAL); ! } ! ! msqptr = &msqids[msqid]; ! if (msqptr->msg_qbytes == 0) { ! #ifdef MSG_DEBUG_OK ! printf("no such message queue id\n"); ! #endif ! return(EINVAL); ! } ! if (msqptr->msg_perm.seq != IPCID_TO_SEQ(uap->msqid)) { ! #ifdef MSG_DEBUG_OK ! printf("wrong sequence number\n"); ! #endif return(EINVAL); - } if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_R))) { #ifdef MSG_DEBUG_OK --- 860,867 ---- if (!jail_sysvipc_allowed && p->p_prison != NULL) return (ENOSYS); ! if ((msqptr = msqid_to_msqptr(uap->msqid)) == NULL) return(EINVAL); if ((eval = ipcperm(p, &msqptr->msg_perm, IPC_R))) { #ifdef MSG_DEBUG_OK *************** *** 1099,1101 **** --- 1087,1194 ---- p->p_retval[0] = msgsz; return(0); } + + static int + filt_sysvmsgattach(struct knote *kn) + { + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return (ESRCH); + + kn->kn_flags |= EV_CLEAR; /* automatically set */ + + /* XXX locking? this might compete with another process. */ + SLIST_INSERT_HEAD(&i_msqptr->q_klist, kn, kn_selnext); + + /* + * If the note being attached is watching for message insertion, + * and there are messages already present in the queue, then we + * force insertion of a matching event automatically. This *must* + * be done via KNOTE() to ensure that the ,essage ID is passed; it + * is a kludge to work around the 0 valued hint argument to the + * f_event() call through to filt_sysvmsg(). + */ + if ((kn->kn_sfflags & NOTE_SYSVMSG) && i_msqptr->e.msg_qnum != 0) { + int s = splhigh(); + KNOTE(&i_msqptr->q_klist, NOTE_SYSVMSG, msqid); + splx(s); + } + + return (0); + } + + /* + * The knote may be attached to a message queue which is deleted out + * from under us by another process, leaving nothing for the knote to + * be attached to. So when the ,essage queue is deleted, the knote + * is marked as DETACHED and also flagged as ONESHOT so it will be + * deleted when read out. However, as part of the knote deletion, + * this routine is called, so a check is needed to avoid actually + * performing a detach, because the original message queue does not + * exist any more. Note that reusing the queue ID will bzero the list + * head, orphaning the events which were linked to it, so this does + * not have to be tracked (thought it seems a bit messy, this is what + * kqueue already does for exiting processes, FWIW). + */ + static void + filt_sysvmsgdetach(struct knote *kn) + { + int msqid = kn->kn_id; + register struct i_msqid_ds *i_msqptr; + + if (kn->kn_status & KN_DETACHED) + return; + + if ((i_msqptr = (struct i_msqid_ds *)msqid_to_msqptr(msqid)) == NULL) + return; + + /* XXX locking? this might compete with another process. */ + SLIST_REMOVE(&i_msqptr->q_klist, kn, knote, kn_selnext); + } + + /* + * Handle events on a given message queue object; called once for + * each object. + */ + static int + filt_sysvmsg(struct knote *kn, long hint, long id) + { + u_int event; + register struct msqid_ds *msqptr; + + /* + * mask data out of "hint". + */ + event = (u_int)hint; + + if (kn->kn_id != id) + return(0); + + if ((msqptr = msqid_to_msqptr(id)) == NULL) + return(0); + + /* + * if the user is interested in this event, record it. + */ + if (kn->kn_sfflags & event) + kn->kn_fflags |= event; + + switch( event) { + case NOTE_IPC_RMID: /* message queue is being removed */ + /* flag the event as finished */ + kn->kn_status |= KN_DETACHED; + kn->kn_flags |= (EV_EOF | EV_ONESHOT); + break; + + case NOTE_SYSVMSG: /* a message was enqueued */ + kn->kn_data = msqptr->msg_qnum; /* # of messages now in queue */ + break; + } + + return (kn->kn_fflags != 0); + } + + struct filterops sysvmsg_filtops = + { 0, filt_sysvmsgattach, filt_sysvmsgdetach, filt_sysvmsg }; Index: kern/tty.c =================================================================== RCS file: /usr/cvs/src/sys/kern/tty.c,v retrieving revision 1.129.2.5 diff -c -r1.129.2.5 tty.c *** kern/tty.c 11 Mar 2002 01:32:31 -0000 1.129.2.5 --- kern/tty.c 17 Aug 2002 06:50:10 -0000 *************** *** 109,117 **** static void ttyrubo __P((struct tty *tp, int cnt)); static void ttyunblock __P((struct tty *tp)); static int ttywflush __P((struct tty *tp)); ! static int filt_ttyread __P((struct knote *kn, long hint)); static void filt_ttyrdetach __P((struct knote *kn)); ! static int filt_ttywrite __P((struct knote *kn, long hint)); static void filt_ttywdetach __P((struct knote *kn)); /* --- 109,117 ---- static void ttyrubo __P((struct tty *tp, int cnt)); static void ttyunblock __P((struct tty *tp)); static int ttywflush __P((struct tty *tp)); ! static int filt_ttyread __P((struct knote *kn, long hint, long id)); static void filt_ttyrdetach __P((struct knote *kn)); ! static int filt_ttywrite __P((struct knote *kn, long hint, long id)); static void filt_ttywdetach __P((struct knote *kn)); /* *************** *** 1137,1143 **** } static int ! filt_ttyread(struct knote *kn, long hint) { struct tty *tp = ((dev_t)kn->kn_hook)->si_tty; --- 1137,1143 ---- } static int ! filt_ttyread(struct knote *kn, long hint, long id) { struct tty *tp = ((dev_t)kn->kn_hook)->si_tty; *************** *** 1160,1168 **** } static int ! filt_ttywrite(kn, hint) struct knote *kn; long hint; { struct tty *tp = ((dev_t)kn->kn_hook)->si_tty; --- 1160,1169 ---- } static int ! filt_ttywrite(kn, hint, id) struct knote *kn; long hint; + long id; { struct tty *tp = ((dev_t)kn->kn_hook)->si_tty; *************** *** 2181,2187 **** if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); wakeup(TSA_HUP_OR_INPUT(tp)); ! KNOTE(&tp->t_rsel.si_note, 0); } /* --- 2182,2188 ---- if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); wakeup(TSA_HUP_OR_INPUT(tp)); ! KNOTE(&tp->t_rsel.si_note, 0, 0); } /* *************** *** 2206,2212 **** CLR(tp->t_state, TS_SO_OLOWAT); wakeup(TSA_OLOWAT(tp)); } ! KNOTE(&tp->t_wsel.si_note, 0); } /* --- 2207,2213 ---- CLR(tp->t_state, TS_SO_OLOWAT); wakeup(TSA_OLOWAT(tp)); } ! KNOTE(&tp->t_wsel.si_note, 0, 0); } /* Index: kern/uipc_socket.c =================================================================== RCS file: /usr/cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.21 diff -c -r1.68.2.21 uipc_socket.c *** kern/uipc_socket.c 1 May 2002 03:27:35 -0000 1.68.2.21 --- kern/uipc_socket.c 17 Aug 2002 06:51:37 -0000 *************** *** 65,74 **** #endif /* INET */ static void filt_sordetach(struct knote *kn); ! static int filt_soread(struct knote *kn, long hint); static void filt_sowdetach(struct knote *kn); ! static int filt_sowrite(struct knote *kn, long hint); ! static int filt_solisten(struct knote *kn, long hint); static struct filterops solisten_filtops = { 1, NULL, filt_sordetach, filt_solisten }; --- 65,74 ---- #endif /* INET */ static void filt_sordetach(struct knote *kn); ! static int filt_soread(struct knote *kn, long hint, long id); static void filt_sowdetach(struct knote *kn); ! static int filt_sowrite(struct knote *kn, long hint, long id); ! static int filt_solisten(struct knote *kn, long hint, long id); static struct filterops solisten_filtops = { 1, NULL, filt_sordetach, filt_solisten }; *************** *** 1583,1589 **** /*ARGSUSED*/ static int ! filt_soread(struct knote *kn, long hint) { struct socket *so = (struct socket *)kn->kn_fp->f_data; --- 1583,1589 ---- /*ARGSUSED*/ static int ! filt_soread(struct knote *kn, long hint, long id) { struct socket *so = (struct socket *)kn->kn_fp->f_data; *************** *** 1614,1620 **** /*ARGSUSED*/ static int ! filt_sowrite(struct knote *kn, long hint) { struct socket *so = (struct socket *)kn->kn_fp->f_data; --- 1614,1620 ---- /*ARGSUSED*/ static int ! filt_sowrite(struct knote *kn, long hint, long id) { struct socket *so = (struct socket *)kn->kn_fp->f_data; *************** *** 1636,1642 **** /*ARGSUSED*/ static int ! filt_solisten(struct knote *kn, long hint) { struct socket *so = (struct socket *)kn->kn_fp->f_data; --- 1636,1642 ---- /*ARGSUSED*/ static int ! filt_solisten(struct knote *kn, long hint, long id) { struct socket *so = (struct socket *)kn->kn_fp->f_data; Index: kern/uipc_socket2.c =================================================================== RCS file: /usr/cvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.55.2.15 diff -c -r1.55.2.15 uipc_socket2.c *** kern/uipc_socket2.c 21 May 2002 18:03:16 -0000 1.55.2.15 --- kern/uipc_socket2.c 17 Aug 2002 06:52:01 -0000 *************** *** 313,319 **** (*so->so_upcall)(so, so->so_upcallarg, M_DONTWAIT); if (sb->sb_flags & SB_AIO) aio_swake(so, sb); ! KNOTE(&sb->sb_sel.si_note, 0); } /* --- 313,319 ---- (*so->so_upcall)(so, so->so_upcallarg, M_DONTWAIT); if (sb->sb_flags & SB_AIO) aio_swake(so, sb); ! KNOTE(&sb->sb_sel.si_note, 0, 0); } /* Index: kern/uipc_syscalls.c =================================================================== RCS file: /usr/cvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.65.2.14 diff -c -r1.65.2.14 uipc_syscalls.c *** kern/uipc_syscalls.c 14 Aug 2002 22:23:05 -0000 1.65.2.14 --- kern/uipc_syscalls.c 17 Aug 2002 06:53:30 -0000 *************** *** 272,278 **** p->p_retval[0] = fd; /* connection has been removed from the listen queue */ ! KNOTE(&head->so_rcv.sb_sel.si_note, 0); so->so_state &= ~SS_COMP; so->so_head = NULL; --- 272,278 ---- p->p_retval[0] = fd; /* connection has been removed from the listen queue */ ! KNOTE(&head->so_rcv.sb_sel.si_note, 0, 0); so->so_state &= ~SS_COMP; so->so_head = NULL; Index: miscfs/fifofs/fifo_vnops.c =================================================================== RCS file: /usr/cvs/src/sys/miscfs/fifofs/Attic/fifo_vnops.c,v retrieving revision 1.45.2.3 diff -c -r1.45.2.3 fifo_vnops.c *** miscfs/fifofs/fifo_vnops.c 15 Jun 2001 21:20:55 -0000 1.45.2.3 --- miscfs/fifofs/fifo_vnops.c 17 Aug 2002 06:54:50 -0000 *************** *** 78,86 **** static int fifo_advlock __P((struct vop_advlock_args *)); static void filt_fifordetach(struct knote *kn); ! static int filt_fiforead(struct knote *kn, long hint); static void filt_fifowdetach(struct knote *kn); ! static int filt_fifowrite(struct knote *kn, long hint); static struct filterops fiforead_filtops = { 1, NULL, filt_fifordetach, filt_fiforead }; --- 78,86 ---- static int fifo_advlock __P((struct vop_advlock_args *)); static void filt_fifordetach(struct knote *kn); ! static int filt_fiforead(struct knote *kn, long hint, long id); static void filt_fifowdetach(struct knote *kn); ! static int filt_fifowrite(struct knote *kn, long hint, long id); static struct filterops fiforead_filtops = { 1, NULL, filt_fifordetach, filt_fiforead }; *************** *** 405,411 **** } static int ! filt_fiforead(struct knote *kn, long hint) { struct socket *so = (struct socket *)kn->kn_hook; --- 405,411 ---- } static int ! filt_fiforead(struct knote *kn, long hint, long id) { struct socket *so = (struct socket *)kn->kn_hook; *************** *** 429,435 **** } static int ! filt_fifowrite(struct knote *kn, long hint) { struct socket *so = (struct socket *)kn->kn_hook; --- 429,435 ---- } static int ! filt_fifowrite(struct knote *kn, long hint, long id) { struct socket *so = (struct socket *)kn->kn_hook; Index: sys/event.h =================================================================== RCS file: /usr/cvs/src/sys/sys/event.h,v retrieving revision 1.5.2.5 diff -c -r1.5.2.5 event.h *** sys/event.h 14 Dec 2001 19:21:22 -0000 1.5.2.5 --- sys/event.h 17 Aug 2002 07:12:04 -0000 *************** *** 36,43 **** #define EVFILT_PROC (-5) /* attached to struct proc */ #define EVFILT_SIGNAL (-6) /* attached to struct proc */ #define EVFILT_TIMER (-7) /* timers */ ! #define EVFILT_SYSCOUNT 7 #define EV_SET(kevp, a, b, c, d, e, f) do { \ (kevp)->ident = (a); \ --- 36,44 ---- #define EVFILT_PROC (-5) /* attached to struct proc */ #define EVFILT_SIGNAL (-6) /* attached to struct proc */ #define EVFILT_TIMER (-7) /* timers */ + #define EVFILT_SYSVMSG (-8) /* System V messages */ ! #define EVFILT_SYSCOUNT 8 #define EV_SET(kevp, a, b, c, d, e, f) do { \ (kevp)->ident = (a); \ *************** *** 105,110 **** --- 106,117 ---- #define NOTE_CHILD 0x00000004 /* am a child process */ /* + * data/hint flags for EVFILT_SYSVMSG, shared with userspace + */ + #define NOTE_IPC_RMID 0x80000000 /* message queue deleted */ + #define NOTE_SYSVMSG 0x40000000 /* message enqueued */ + + /* * This is currently visible to userland to work around broken * programs which pull in or . */ *************** *** 118,124 **** MALLOC_DECLARE(M_KQUEUE); #endif ! #define KNOTE(list, hint) if ((list) != NULL) knote(list, hint) /* * Flag indicating hint is a signal. Used by EVFILT_SIGNAL, and also --- 125,131 ---- MALLOC_DECLARE(M_KQUEUE); #endif ! #define KNOTE(list, hint,id) if ((list) != NULL) knote(list, hint, id) /* * Flag indicating hint is a signal. Used by EVFILT_SIGNAL, and also *************** *** 130,136 **** int f_isfd; /* true if ident == filedescriptor */ int (*f_attach) __P((struct knote *kn)); void (*f_detach) __P((struct knote *kn)); ! int (*f_event) __P((struct knote *kn, long hint)); }; struct knote { --- 137,143 ---- int f_isfd; /* true if ident == filedescriptor */ int (*f_attach) __P((struct knote *kn)); void (*f_detach) __P((struct knote *kn)); ! int (*f_event) __P((struct knote *kn, long hint, long id)); }; struct knote { *************** *** 163,169 **** struct proc; ! extern void knote(struct klist *list, long hint); extern void knote_remove(struct proc *p, struct klist *list); extern void knote_fdclose(struct proc *p, int fd); extern int kqueue_register(struct kqueue *kq, --- 170,176 ---- struct proc; ! extern void knote(struct klist *list, long hint, long id); extern void knote_remove(struct proc *p, struct klist *list); extern void knote_fdclose(struct proc *p, int fd); extern int kqueue_register(struct kqueue *kq, Index: ufs/ufs/ufs_readwrite.c =================================================================== RCS file: /usr/cvs/src/sys/ufs/ufs/Attic/ufs_readwrite.c,v retrieving revision 1.65.2.11 diff -c -r1.65.2.11 ufs_readwrite.c *** ufs/ufs/ufs_readwrite.c 22 Jun 2002 18:08:04 -0000 1.65.2.11 --- ufs/ufs/ufs_readwrite.c 17 Aug 2002 06:55:50 -0000 *************** *** 51,57 **** #include #define VN_KNOTE(vp, b) \ ! KNOTE((struct klist *)&vp->v_pollinfo.vpi_selinfo.si_note, (b)) /* * Vnode op for reading. --- 51,57 ---- #include #define VN_KNOTE(vp, b) \ ! KNOTE((struct klist *)&vp->v_pollinfo.vpi_selinfo.si_note, (b), 0) /* * Vnode op for reading. Index: ufs/ufs/ufs_vnops.c =================================================================== RCS file: /usr/cvs/src/sys/ufs/ufs/ufs_vnops.c,v retrieving revision 1.131.2.7 diff -c -r1.131.2.7 ufs_vnops.c *** ufs/ufs/ufs_vnops.c 5 Feb 2002 18:35:04 -0000 1.131.2.7 --- ufs/ufs/ufs_vnops.c 17 Aug 2002 06:57:07 -0000 *************** *** 108,116 **** static int ufsspec_close __P((struct vop_close_args *)); static int ufsspec_read __P((struct vop_read_args *)); static int ufsspec_write __P((struct vop_write_args *)); ! static int filt_ufsread __P((struct knote *kn, long hint)); ! static int filt_ufswrite __P((struct knote *kn, long hint)); ! static int filt_ufsvnode __P((struct knote *kn, long hint)); static void filt_ufsdetach __P((struct knote *kn)); static int ufs_kqfilter __P((struct vop_kqfilter_args *ap)); --- 108,116 ---- static int ufsspec_close __P((struct vop_close_args *)); static int ufsspec_read __P((struct vop_read_args *)); static int ufsspec_write __P((struct vop_write_args *)); ! static int filt_ufsread __P((struct knote *kn, long hint, long id)); ! static int filt_ufswrite __P((struct knote *kn, long hint, long id)); ! static int filt_ufsvnode __P((struct knote *kn, long hint, long id)); static void filt_ufsdetach __P((struct knote *kn)); static int ufs_kqfilter __P((struct vop_kqfilter_args *ap)); *************** *** 131,137 **** (q) = tmp.qcvt; \ } #define VN_KNOTE(vp, b) \ ! KNOTE(&vp->v_pollinfo.vpi_selinfo.si_note, (b)) /* * A virgin directory (no blushing please). --- 131,137 ---- (q) = tmp.qcvt; \ } #define VN_KNOTE(vp, b) \ ! KNOTE(&vp->v_pollinfo.vpi_selinfo.si_note, (b), 0) /* * A virgin directory (no blushing please). *************** *** 2275,2281 **** /*ARGSUSED*/ static int ! filt_ufsread(struct knote *kn, long hint) { struct vnode *vp = (struct vnode *)kn->kn_hook; struct inode *ip = VTOI(vp); --- 2275,2281 ---- /*ARGSUSED*/ static int ! filt_ufsread(struct knote *kn, long hint, long id) { struct vnode *vp = (struct vnode *)kn->kn_hook; struct inode *ip = VTOI(vp); *************** *** 2295,2301 **** /*ARGSUSED*/ static int ! filt_ufswrite(struct knote *kn, long hint) { /* --- 2295,2301 ---- /*ARGSUSED*/ static int ! filt_ufswrite(struct knote *kn, long hint, long id) { /* *************** *** 2310,2316 **** } static int ! filt_ufsvnode(struct knote *kn, long hint) { if (kn->kn_sfflags & hint) --- 2310,2316 ---- } static int ! filt_ufsvnode(struct knote *kn, long hint, long id) { if (kn->kn_sfflags & hint) --------------28F74B3623B344F226551D0F-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 3:40:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820C537B400 for ; Sat, 17 Aug 2002 03:40:28 -0700 (PDT) Received: from memphis.mephi.ru (memphis.mephi.ru [194.67.67.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 419DD43E7B for ; Sat, 17 Aug 2002 03:40:27 -0700 (PDT) (envelope-from timon@memphis.mephi.ru) Received: (from timon@localhost) by memphis.mephi.ru (8.11.6/8.11.6) id g7HAeL188721; Sat, 17 Aug 2002 14:40:21 +0400 (MSD) (envelope-from timon) Date: Sat, 17 Aug 2002 14:40:21 +0400 From: "Artem 'Zazoobr' Ignatjev" To: *********@aol.com, freebsd-hackers@freebsd.org Subject: Re: Want something to do? Message-ID: <20020817144021.A88117@memphis.mephi.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from *********@aol.com on Fri, Aug 16, 2002 at 07:44:47PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 16, 2002 at 07:44:47PM -0400, *********@aol.com wrote: > I used to work at a company that does background investigations. You know, [buzz skipped] > I dare anyone to hack this site! It's way too secure for you!!! We're hacking localhost or OUR sources. If you need script kiddiez, that's the wrong place. Sinceherely yours, Artem 'Zazoobr' Ignatjev. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 7: 4: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB3E37B400 for ; Sat, 17 Aug 2002 07:04:04 -0700 (PDT) Received: from rambo.401.cx (rambo.401.cx [80.65.205.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8422D43E42 for ; Sat, 17 Aug 2002 07:04:03 -0700 (PDT) (envelope-from listsub@401.cx) Received: from 401.cx (rocky [192.168.0.2]) by rambo.401.cx (8.12.5/8.12.5) with ESMTP id g7HE3eZu064804; Sat, 17 Aug 2002 16:03:42 +0200 (CEST) (envelope-from listsub@401.cx) Message-ID: <3D5E5843.70901@401.cx> Date: Sat, 17 Aug 2002 16:05:55 +0200 From: "Roger 'Rocky' Vetterberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eugene Ossintsev Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: strange name of a device References: <20020816235603.A181@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Eugene Ossintsev wrote: > Hallo, > > Who knows, why that device is so funny named? > > from dmesg: > > acd0: CD-RW <@A CD\^LB C\^E $81"0B> at ata1-master PIO4 > ^^^^^^^^^^^^^^^^^^^^^^^ > > It varies from stable to stable. Sometimes it's displayed correctly > as > > acd0: CD-RW at ata1-master PIO4 > Probably bad firmware in the CD itself, Ive seen this happen on harddrives as well. See if you can find a firmware upgrade utility from your manufacturer. -- R To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 10:49:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ACF337B400 for ; Sat, 17 Aug 2002 10:49:18 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8414E43E3B for ; Sat, 17 Aug 2002 10:49:17 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 47464 invoked by uid 1000); 17 Aug 2002 17:49:18 -0000 Date: Sat, 17 Aug 2002 10:49:18 -0700 (PDT) From: Nate Lawson To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP In-Reply-To: <200208170233.g7H2XgqG047569@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Comments below. Consider them only semi-informed. :) On Fri, 16 Aug 2002, Matthew Dillon wrote: > +void > +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) > +{ > + u_long bw; > + u_long bwnd; > + int save_ticks; > + > + /* > + * If inflight_enable is disabled in the middle of a tcp connection, > + * make sure snd_bwnd is effectively disabled. > + */ > + if (tcp_inflight_enable == 0) { > + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; > + tp->snd_bandwidth = 0; > + return; > + } > + > + /* > + * Figure out the bandwidth. Due to the tick granularity this > + * is a very rough number and it MUST be averaged over a fairly > + * long period of time. > + */ > + save_ticks = ticks; > + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) > + return; If tp->t_bw_rtttime is greater than save_ticks, the unsigned compare will fail. Can this ever happen (say with the "tick count goes backwards" issue)? Why not do this as a signed compare and check for <= 0? > + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz / > + (save_ticks - tp->t_bw_rtttime); > + tp->t_bw_rtttime = save_ticks; > + tp->t_bw_rtseq = ack_seq; > + if (tp->t_bw_rtttime == 0) > + return; > + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; I'm not familiar with the paper -- where does 15 come from? I'm guessing this is a cheap way to perturb the lower bits. > + tp->snd_bandwidth = bw; > + > + /* > + * Calculate the semi-static bandwidth delay product, plus two maximal > + * segments. The additional slop puts us squarely in the sweet > + * spot and also handles the bandwidth run-up case. Without the > + * slop we could be locking ourselves into a lower bandwidth. > + * > + * Situations Handled: > + * (1) prevents over-queueing of packets on LANs, especially > + * high speed LANs, allowing larger TCP buffers to be > + * specified. > + * > + * (2) able to handle increased network loads (bandwidth drops > + * so bwnd drops). > + * > + * (3) Randomly changes the window size in order to force > + * bandwidth balancing between connections. > + */ > +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) > + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; Would prefer an #undef USERTT after you're done with it. > + if (tcp_inflight_debug > 0) { > + static int ltime; What happens when multiple packets arrive at once. Can they make the calculation below fail? Do you want splimp or a lock on ltime? > + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { Why the division by a debug enable/disable int? Is it possible for this to ever be 0 at this point? > + ltime = ticks; > + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n", > + tp, > + bw, > + tp->t_rttbest, > + tp->t_srtt, > + bwnd > + ); > + } > + } > + if ((long)bwnd < tcp_inflight_min) > + bwnd = tcp_inflight_min; > + if (bwnd > tcp_inflight_max) > + bwnd = tcp_inflight_max; > + if ((long)bwnd < tp->t_maxseg * 2) > + bwnd = tp->t_maxseg * 2; > + tp->snd_bwnd = bwnd; > +} > + > Index: netinet/tcp_var.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v > retrieving revision 1.82 > diff -u -r1.82 tcp_var.h > --- netinet/tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 > +++ netinet/tcp_var.h 21 Jul 2002 02:26:36 -0000 > > @@ -137,6 +139,9 @@ > int t_rtttime; /* round trip time */ > tcp_seq t_rtseq; /* sequence number being timed */ > > + int t_bw_rtttime; /* used for bandwidth calculation */ Does this need to be signed? > + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ > + > int t_rxtcur; /* current retransmit value (ticks) */ > u_int t_maxseg; /* maximum segment size */ > int t_srtt; /* smoothed round-trip time */ > @@ -144,6 +149,7 @@ > > int t_rxtshift; /* log(2) of rexmt exp. backoff */ > u_int t_rttmin; /* minimum rtt allowed */ > + u_int t_rttbest; /* best rtt we've seen */ > u_long t_rttupdated; /* number of times rtt sampled */ > u_long max_sndwnd; /* largest window peer has offered */ -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 10:56:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75EF937B400; Sat, 17 Aug 2002 10:56:40 -0700 (PDT) Received: from memphis.mephi.ru (memphis.mephi.ru [194.67.67.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1580C43E6E; Sat, 17 Aug 2002 10:56:38 -0700 (PDT) (envelope-from timon@memphis.mephi.ru) Received: (from timon@localhost) by memphis.mephi.ru (8.11.6/8.11.6) id g7HHuPC21592; Sat, 17 Aug 2002 21:56:25 +0400 (MSD) (envelope-from timon) Date: Sat, 17 Aug 2002 21:56:24 +0400 From: "Artem 'Zazoobr' Ignatjev" To: Bruce Evans , freebsd-gnats-submit@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: bin/20633: fdisk doesn't handle LBA correctly Message-ID: <20020817215624.B88117@memphis.mephi.ru> References: <20020816224235.C16833@memphis.mephi.ru> <20020818011802.G11426-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020818011802.G11426-100000@gamplex.bde.org>; from bde@zeta.org.au on Sun, Aug 18, 2002 at 02:12:45AM +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote: >>>> Hi, if I understand what jhb said in audit trail, following patch >>>> should solve the issue. Stephen, if it still bothers you, could you try >>>> it? >>>> >>>> --- sbin/i386/fdisk/fdisk.c Fri Aug 16 16:24:27 2002 >>>> +++ sbin/i386/fdisk/fdisk.c Fri Aug 16 16:33:28 2002 >>>> @@ -468,13 +468,21 @@ >> [skip] >>>> - printf("\tbeg: cyl %d/ head %d/ sector %d;\n\tend: cyl %d/ head %d/ sector %d\n" >> [skip] >>>> + /* >>>> + * if C/H/S of start or end are all set to 0xff, then C/H/S don't have >>>> + * enough bits to hold the address, and one should use LBA instead. >>>> + */ >>>> + if ((partp->dp_scyl != 0xff || partp->dp_ssect != 0xff || >>>> + partp->dp_shd != 0xff) && (partp->dp_ecyl != 0xff || >>>> + partp->dp_esect != 0xff || partp->dp_ehd != 0xff)) >>>> + printf("\tbeg: cyl %d/ head %d/ sector %d;\n" >> [skip] >>> >>> Fdisk should print these values, at least optionally, since they are needed >>> for debugging. The magic values might be non-magic on old systems. >> Debugging WHAT? And, I can hardly imagine such a situation inside hard >> drives & slice tables. > > Debugging hard disk tables and slice tables. I do it routinely. It > can be important to look at the raw data, but the dp_scyl...dp_ehd > data is a little too raw. Ok, so we must add option to fdisk(8) to print CHS? And, BTW, does CHS makes sense inside an extended slices? >>> Also, the usual magic number of cylinders seems to be 1022, not 1023. >> I disagree. Now i'm hacking fdisk to work with extended slices, it can > > We don't get to decide. There are braindamaged conventions about this > to give compatibility with broken BIOSes and broken fdisks. > > Actually, 1023 is most magic (it is what the kernel expects), but the > data in the PR shows that 1022 is magic too. The magic 0xfe in the > kernel is for the ending head number. It can be important not to use > a starting or ending head number of 255 (== a head count of 256) because > some broken BIOSes crash on it, and there are now conventions that > prohibit using it. Maybe we should take as magic cyls >1021? And where can one read all this conventions? >> Take a look at the dump (I've cut all entries regarding extendeds below >> the top-level slicetable, since them all take space, but are of no >> interest now) >> >> Script started on Fri Aug 16 22:23:06 2002 [skip] >> Information from DOS bootblock is: >> The data for partition 1 is: >> sysid 6 (Primary 'big' DOS (> 32MB)), >> start 63, size 2088387 (1019 Meg), flag 0 >> beg: cyl 0/ head 1/ sector 1; >> end: cyl 129/ head 254/ sector 63 [skip] >> The data for partition 4 is: >> sysid 15 (Extended DOS, LBA), >> start 14667345, size 105435855 (51482 Meg), flag 0 >> beg: cyl 913/ head 0/ sector 1; >> end: cyl 1023/ head 254/ sector 63 >> The data for partition 5 is: >> sysid 130 (Linux swap or Solaris x86), >> start 14667408, size 256977 (125 Meg), flag 0 >> beg: cyl 913/ head 1/ sector 1; >> end: cyl 928/ head 254/ sector 63 Looks like there is no adjustment for CHS, while there are wierd adjustment requirements for LBA >> The data for partition 7 is: >> sysid 131 (Linux filesystem), >> start 14924448, size 16771797 (8189 Meg), flag 0 >> beg: cyl 929/ head 1/ sector 1; >> end: cyl 1023/ head 254/ sector 63 [skip] >> The data for partition 13 is: >> sysid 165 (FreeBSD/NetBSD/386BSD), >> start 80051958, size 8401932 (4102 Meg), flag 0 >> beg: cyl 1023/ head 254/ sector 63; >> end: cyl 1023/ head 254/ sector 63 >> Script done on Fri Aug 16 22:23:06 2002 > > Seems reasonable. It shows all of the magic beg and end values, because > the most magic one (all 0xff's) is so magic that it is never used :-). and how translates that value to CHS? Guess 1023/255/63? > >> A-ha! Better see once, than hear many times: magic value for start is >> 1023/1/1, and for end is 1023/254/63, but note my FreeBSD slice - it was >> created using linux fdisk, but even these strange values works ok. > > Linux fdisk apparently hasn't been dumbed down to follow current > conventions. It still uses a second-or third-best convention for the > "beg" values. These values should be as non-physical as possible so > that they don't get used by old BIOSes and are seen to be conventional > by most fdisks. The best values are probably 1023/255/63 for "beg" > and 1023/actual_heads/actual_sectors for "end". > >>> Writing the correct magic numbers is more interesting. fdisk(8) doesn't >>> support it directly. You may have to change the C/H/S values to the magic >>> ones manually. >> Is there any papers on the subject? All my knowledge was obtained experimentally, watching how my dad revives dead hds.... >> It looks like the magic is cyl=1023, regardless of h/s values... > > I haven't kept up with the current conventions except for following the > changes in the FreeBSD boot loader and MBR-reading code to keep down^Wup > with them. Search the web. 10 year ago, one of the best documents was > by Hale Landis. I searched for "hale landis mbr" and found something > saying that "Hale no longer attempts to keep up with all the silly > and stupid things that OS designers are doing in partition tables" :-). > It still says that there are no standards. There is a new standard > named something like EFI GPT. Any url? Or `google knows'? ;-) I suppose, that it will be better to follow the linux' fdisk.. Could you please look at http://memphis.mephi.ru/~timon/fdisk/ (and http://memphis.mephi.ru/~timon at all ;-) since you'll need a patch from there or manually define DOSPTYP_EXTX if you'll try to compile it )? And, one more : I suggest this discussion should go to -hackers... (Adding a CC there...) Sinceherely yours, Artem 'Zazoobr' Ignatjev. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 11:36:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 497DF37B400; Sat, 17 Aug 2002 11:36:21 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D258043E70; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7HIaKdc067941; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7HIaKZ3067940; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Aug 2002 11:36:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200208171836.g7HIaKZ3067940@apollo.backplane.com> To: Nate Lawson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Comments below. Consider them only semi-informed. :) : :> + save_ticks = ticks; :> + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) :> + return; : :If tp->t_bw_rtttime is greater than save_ticks, the unsigned compare will :fail. Can this ever happen (say with the "tick count goes :backwards" issue)? Why not do this as a signed compare and check for :<= 0? Yes, when ticks rolls over. This is on purpose and is designed to handle both the rollover condition and someone setting the time of day on the machine (though perhaps 'ticks' doesn't reverse index in that case, I wasn't sure). e.g. if ticks rolls over we fall through the conditional and proceed to the calculation, which resets t_bw_rtttime. :> + tp->t_bw_rtseq = ack_seq; :> + if (tp->t_bw_rtttime == 0) :> + return; :> + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; : :I'm not familiar with the paper -- where does 15 come from? I'm guessing :this is a cheap way to perturb the lower bits. It's a cheap way to do an exponential average. The >> 4 is a divide by 16. So the equivalent is: bw = (average_bw * 15 + bw) / 16 average_bw = bw; That should be more obvious to you... a long term exponential average of the bandwidth. :> + * bandwidth balancing between connections. :> + */ :> +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) :> + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; : :Would prefer an #undef USERTT after you're done with it. Too late, I just did the commit. I'll make the addition in my local tree. I expect to make more commits in the future to this segment of code and it will show up in one of those. :> + if (tcp_inflight_debug > 0) { :> + static int ltime; : :What happens when multiple packets arrive at once. Can they make the :calculation below fail? Do you want splimp or a lock on ltime? No, this is just debugging code designed to limit the rate of kernel printfs. A tcp_inflight_debug of 1 limits the rate to 1/sec. 2 will be 2/sec. 3 will be 3/sec. It's just debugging code, it isn't meant to be 100% robust. :> + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { : :Why the division by a debug enable/disable int? Is it possible for this :to ever be 0 at this point? No, because of the check above. Though I suppose in -current there could be a race. :> tcp_seq t_rtseq; /* sequence number being timed */ :> :> + int t_bw_rtttime; /* used for bandwidth calculation */ : :Does this need to be signed? I think you meant unsigned. No, it doesn't need to be unsigned. Hmm. though it's possible rollover will skew the 'bw' calculation for a few milliseconds. I'll look into that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 14:39:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83FD237B400; Sat, 17 Aug 2002 14:39:40 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7442643E4A; Sat, 17 Aug 2002 14:39:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA17620; Sat, 17 Aug 2002 21:39:26 GMT Date: Sun, 18 Aug 2002 07:45:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Artem 'Zazoobr' Ignatjev" Cc: freebsd-gnats-submit@freebsd.org, Subject: Re: bin/20633: fdisk doesn't handle LBA correctly In-Reply-To: <20020817215624.B88117@memphis.mephi.ru> Message-ID: <20020818072003.I12728-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 17 Aug 2002, Artem 'Zazoobr' Ignatjev wrote: > On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote: > >> [skip] > >>> > >>> Fdisk should print these values, at least optionally, since they are needed > >>> for debugging. The magic values might be non-magic on old systems. > >> Debugging WHAT? And, I can hardly imagine such a situation inside hard > >> drives & slice tables. > > > > Debugging hard disk tables and slice tables. I do it routinely. It > > can be important to look at the raw data, but the dp_scyl...dp_ehd > > data is a little too raw. > Ok, so we must add option to fdisk(8) to print CHS? If we displayed suppressed the existing display for cases where we know it is bogus, then there should be an option to display it for these cases. > And, BTW, does CHS makes sense inside an extended slices? I think so, since boot loaders might use at least the starting C/H/S if there are any boot loaders that support booting from logical drives in extended partitions (I think lilo can). Using them might even work for cylinders below 1024. > > ... > > Actually, 1023 is most magic (it is what the kernel expects), but the > > data in the PR shows that 1022 is magic too. The magic 0xfe in the > > kernel is for the ending head number. It can be important not to use > > a starting or ending head number of 255 (== a head count of 256) because > > some broken BIOSes crash on it, and there are now conventions that > > prohibit using it. > > Maybe we should take as magic cyls >1021? Don't assume much when displaying magic values, but only write values that satisfy current conventions. > And where can one read all > this conventions? google :-). > [skip] > >> The data for partition 13 is: > >> sysid 165 (FreeBSD/NetBSD/386BSD), > >> start 80051958, size 8401932 (4102 Meg), flag 0 > >> beg: cyl 1023/ head 254/ sector 63; > >> end: cyl 1023/ head 254/ sector 63 > >> Script done on Fri Aug 16 22:23:06 2002 > > > > Seems reasonable. It shows all of the magic beg and end values, because > > the most magic one (all 0xff's) is so magic that it is never used :-). > and how translates that value to CHS? Guess 1023/255/63? Something like "beg: [invalid]" for 1023/255/63, and "beg: [not used] for 1023/254/63. > I suppose, that it will be better to follow the linux' fdisk.. > Could you please look at http://memphis.mephi.ru/~timon/fdisk/ (and http://memphis.mephi.ru/~timon at all ;-) since you'll need a patch from there or manually define DOSPTYP_EXTX if you'll try to compile it )? Not sure if I have time to look at the details. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 17 23:21:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDECA37B400 for ; Sat, 17 Aug 2002 23:21:16 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AC7743E6A for ; Sat, 17 Aug 2002 23:21:16 -0700 (PDT) (envelope-from knightraven@attbi.com) Received: from quark ([12.224.189.20]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020818062114.JKMC1186.rwcrmhc52.attbi.com@quark> for ; Sun, 18 Aug 2002 06:21:14 +0000 Message-ID: <002801c2467f$731ebb60$14bde00c@quark> From: "Devon Stark" To: Subject: IPDIVERT, having issues? Date: Sat, 17 Aug 2002 23:20:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C24644.B2282110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C24644.B2282110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings! I am having a problem trying to get IPDIVERT to take.. I have setup my kernel conf to include the following lines options IPFIREWALL options IPDIVERT I have the nic configured and running just fine, for both local LAN and = for internet (both of my NICs are plugged into the same switch for now) My /etc/rc.conf has=20 gateway_enable=3D""YES" firewall_enable=3D"YES" natd_enable=3D"YES" Every time I boot the server I get a message saying that IP Packet = filtering is enabled, along with any other configuration I specified = (logging and such), but divert is always set to disabled!? I have gone to the point of building the kernel with '-DIPDIVERT' and = still getting the same results... The main effect of this problem is of course that I get an error when I = try to apply the following rule to my firewall 'ipfw add divert natd all from any to any via fxp0' The error is... =20 ip_fw_ctl: invalid command ipfw: getsockopt(IP_FW_ADD): Invalid argument I have checked and natd is in the services list and seems to be = configured properly. I have been searching for the answer for about 3 days now with little = luck finding the answer.=20 The only thing I can think of is that there is some other kernel option = that I am enabling that is causing this problem, or perhaps that there = is something that I am missing? I have included my config files here for review...=20 Kernel config file (I striped out all of the comments for the sake of = this post) machine i386 cpu I686_CPU ident THE-SERVER maxusers 256 options MATH_EMULATE =20 options INET =20 options FFS =20 options FFS_ROOT =20 options SOFTUPDATES =20 options UFS_DIRHASH =20 options MFS =20 options MD_ROOT =20 options NFS =20 options NFS_ROOT =20 options MSDOSFS =20 options CD9660 =20 options CD9660_ROOT =20 options PROCFS =20 options COMPAT_43 =20 options SCSI_DELAY=3D1000 =20 options UCONSOLE =20 options USERCONFIG =20 options VISUAL_USERCONFIG =20 options KTRACE =20 options SYSVSHM =20 options SYSVMSG =20 options SYSVSEM =20 options P1003_1B =20 options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM =20 options KBD_INSTALL_CDEV =20 options IPFIREWALL options IPDIVERT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=3D50 options BRIDGE options IPSTEALTH options TCP_DROP_SYNFIN options SMP =20 options APIC_IO =20 device isa device eisa device pci device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk =20 device atapicd =20 device atapifd =20 options ATA_STATIC_ID =20 device ahb =20 device ahc =20 device amd =20 device isp =20 device ncr =20 device sym =20 options SYM_SETUP_LP_PROBE_MAP=3D0x40 device adv0 at isa? device adw device bt0 at isa? device aha0 at isa? device aic0 at isa? device scbus =20 device da =20 device sa =20 device cd =20 device pass =20 device asr =20 device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? pseudo-device splash device sc0 at isa? flags 0x100 device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? disable flags 0x20=20 device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device ppc0 at isa? irq 7 device ppbus =20 device lpt =20 device miibus =20 device fxp =20 pseudo-device loop =20 pseudo-device ether =20 pseudo-device pty =20 pseudo-device md =20 pseudo-device bpf =20 device uhci =20 device ohci =20 device usb =20 device ugen =20 device uhid =20 device ukbd =20 device ulpt =20 device umass =20 device ums =20 device uscanner =20 device urio =20 device aue =20 device cue =20 device kue =20 Here is the /etc/rc.conf gateway_enable=3D"YES" inetd_enable=3D"YES" kern_securelevel_enable=3D"NO" linux_enable=3D"YES" moused_enable=3D"NO" nfs_reserved_port_only=3D"YES" sendmail_enable=3D"YES" sshd_enable=3D"YES" usbd_enable=3D"YES" ifconfig_fxp0=3D"DHCP" ifconfig_fxp1=3D"inet 172.17.0.1 netmask 255.255.255.0" hostname=3D"The-Server.KnightRaven.com" firewall_enable=3D"YES" firewall_type=3D"open" firewall_quiet=3D"NO" natd_enable=3D"YES" natd_flags=3D"-f /etc/natd.conf" natd_interface=3D"fxp0" Let me know if there are any other configuration files you need to look = at... Any ideas or help is greatly appreciated! Thank you! Devon ------=_NextPart_000_0023_01C24644.B2282110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greetings!
I am having a problem trying to get = IPDIVERT to=20 take..
I have setup my kernel conf to include = the=20 following lines
 
options IPFIREWALL
options IPDIVERT
 
I have the nic configured and running = just fine,=20 for both local LAN and for internet (both of my NICs are plugged into = the same=20 switch for now)
 
My /etc/rc.conf has
gateway_enable=3D""YES"
firewall_enable=3D"YES"
natd_enable=3D"YES"
 
Every time I boot the server I get a = message saying=20 that IP Packet filtering is enabled, along with any other configuration = I=20 specified (logging and such), but divert is always set to=20 disabled!?
I have gone to the point of building = the kernel=20 with '-DIPDIVERT' and still getting the same results...
The main effect of this problem is of = course that I=20 get an error when I try to apply the following rule to my = firewall
 
'ipfw add divert natd all from any to = any via=20 fxp0'
The error is...
 
ip_fw_ctl: invalid command
ipfw: getsockopt(IP_FW_ADD): Invalid=20 argument
 
I have checked and natd is in the = services list and=20 seems to be configured properly.
 
I have been searching for the answer = for about 3=20 days now with little luck finding the answer.
 
The only thing I can think of is that = there is some=20 other kernel option that I am enabling that is causing this problem, or = perhaps=20 that there is something that I am missing?

I have included my config files here for review...
 
Kernel config file (I striped out all of the comments for the sake = of this=20 post)

machine        =20 i386
cpu          &n= bsp; =20 I686_CPU
ident         &n= bsp;=20 THE-SERVER
maxusers       =20 256
options        =20 MATH_EMULATE          &= nbsp;=20
options        =20 INET           &nb= sp;       =20
options        =20 FFS           &nbs= p;        =20
options        =20 FFS_ROOT           = ;    =20
options        =20 SOFTUPDATES          &n= bsp; =20
options        =20 UFS_DIRHASH          &n= bsp; =20
options        =20 MFS           &nbs= p;        =20
options        =20 MD_ROOT           =      =20
options        =20 NFS           &nbs= p;        =20
options        =20 NFS_ROOT           = ;    =20
options        =20 MSDOSFS           =      =20
options        =20 CD9660           &= nbsp;     =20
options        =20 CD9660_ROOT          &n= bsp; =20
options        =20 PROCFS           &= nbsp;     =20
options        =20 COMPAT_43          &nbs= p;   =20
options        =20 SCSI_DELAY=3D1000        =20
options        =20 UCONSOLE           = ;    =20
options        =20 USERCONFIG          &nb= sp;  =20
options        =20 VISUAL_USERCONFIG      =20
options        =20 KTRACE           &= nbsp;     =20
options        =20 SYSVSHM           =      =20
options        =20 SYSVMSG           =      =20
options        =20 SYSVSEM           =      =20
options        =20 P1003_1B           = ;    =20
options        =20 _KPOSIX_PRIORITY_SCHEDULING
options      = ;  =20 ICMP_BANDLIM          &= nbsp;=20
options        =20 KBD_INSTALL_CDEV       =20
options        =20 IPFIREWALL
options        =20 IPDIVERT
options        =20 IPFIREWALL_FORWARD
options       &n= bsp;=20 IPFIREWALL_VERBOSE
options       &n= bsp;=20 IPFIREWALL_VERBOSE_LIMIT=3D50
options     &nb= sp;  =20 BRIDGE
options        =20 IPSTEALTH
options        =20 TCP_DROP_SYNFIN
options        = ;=20 SMP           &nbs= p;        =20
options        =20 APIC_IO           =      =20
device         =20 isa
device         =20 eisa
device         =20 pci
device         =20 fdc0    at isa? port IO_FD1 irq 6 drq=20 2
device         =20 fd0     at fdc0 drive=20 0
device         =20 ata0    at isa? port IO_WD1 irq=20 14
device         =20 ata1    at isa? port IO_WD2 irq=20 15
device         =20 ata
device         =20 atadisk           =      =20
device         =20 atapicd           =      =20
device         =20 atapifd           =      =20
options        =20 ATA_STATIC_ID          = =20
device         =20 ahb           &nbs= p;=20
device         =20 ahc           &nbs= p;=20
device         =20 amd           &nbs= p;=20
device         =20 isp           &nbs= p;=20
device         =20 ncr           &nbs= p;=20
device         =20 sym           &nbs= p;=20
options        =20 SYM_SETUP_LP_PROBE_MAP=3D0x40
device     &nbs= p;   =20 adv0    at=20 isa?
device         =20 adw
device         =20 bt0     at=20 isa?
device         =20 aha0    at=20 isa?
device         =20 aic0    at=20 isa?
device         =20 scbus          =20
device         =20 da            = ; =20
device         =20 sa            = ; =20
device         =20 cd            = ; =20
device         =20 pass           =20
device         =20 asr           &nbs= p;=20
device          atkbdc0 = at isa?=20 port = IO_KBD
device         =20 atkbd0  at atkbdc? irq 1 flags=20 0x1
device         =20 psm0    at atkbdc? irq=20 12
device         =20 vga0    at isa?
pseudo-device  =20 splash
device         =20 sc0     at isa? flags=20 0x100
device         =20 npx0    at nexus? port IO_NPX irq=20 13
device         =20 apm0    at nexus? disable flags 0x20=20
device         =20 sio0    at isa? port IO_COM1 flags 0x10 irq=20 4
device         =20 sio1    at isa? port IO_COM2 irq=20 3
device         =20 ppc0    at isa? irq=20 7
device         =20 ppbus          =20
device         =20 lpt           &nbs= p;=20
device         =20 miibus         =20
device         =20 fxp           &nbs= p;=20
pseudo-device  =20 loop           =20
pseudo-device  =20 ether          =20
pseudo-device  =20 pty           &nbs= p;=20
pseudo-device  =20 md            = ; =20
pseudo-device  =20 bpf           &nbs= p;=20
device         =20 uhci           =20
device         =20 ohci           =20
device         =20 usb           &nbs= p;=20
device         =20 ugen           =20
device         =20 uhid           =20
device         =20 ukbd           =20
device         =20 ulpt           =20
device         =20 umass          =20
device         =20 ums           &nbs= p;=20
device         =20 uscanner       =20
device         =20 urio           =20
device         =20 aue           &nbs= p;=20
device         =20 cue           &nbs= p;=20
device         =20 kue    
 
Here is the /etc/rc.conf
 
gateway_enable=3D"YES"
inetd_enable=3D"YES"
kern_securelevel_e= nable=3D"NO"
linux_enable=3D"YES"
moused_enable=3D"NO"
nfs_reser= ved_port_only=3D"YES"
sendmail_enable=3D"YES"
sshd_enable=3D"YES"usbd_enable=3D"YES"
ifconfig_fxp0=3D"DHCP"
ifconfig_fxp1=3D"inet = 172.17.0.1  netmask=20 255.255.255.0"
hostname=3D"The-Server.KnightRaven.com"
firewall_ena= ble=3D"YES"
firewall_type=3D"open"
firewall_quiet=3D"NO"
natd_en= able=3D"YES"
natd_flags=3D"-f=20 /etc/natd.conf"
natd_interface=3D"fxp0"
 
Let me know if there are any other configuration files you need to = look=20 at...
 
Any ideas or help is greatly appreciated!
 
Thank you!
Devon
 
------=_NextPart_000_0023_01C24644.B2282110-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message