From owner-freebsd-hackers Sun Aug 15 3:32:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B489B15344; Sun, 15 Aug 1999 03:31:57 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id MAA06192; Sun, 15 Aug 1999 12:27:12 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA59060; Sat, 14 Aug 1999 20:00:25 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908141800.UAA59060@yedi.iaf.nl> Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <93111.934635705@axl.noc.iafrica.com> from Sheldon Hearn at "Aug 14, 1999 3: 1:45 pm" To: sheldonh@uunet.co.za (Sheldon Hearn) Date: Sat, 14 Aug 1999 20:00:25 +0200 (CEST) Cc: walton@nordicrecords.com, nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Sheldon Hearn wrote ... > > > On Fri, 13 Aug 1999 23:42:48 MST, "Dave Walton" wrote: > > > If you really want to work on an encrypted telnet, check out The > > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. > > Cool, another non-exportable system available to US users only. :-) Yeah... isn't it time you Yanks got together and stormed that Trade Dept? I mean, if you can get excited over a few wooden crates containing tea... ;-) ;-) -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://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 15 13:27:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 3DBB415395; Sun, 15 Aug 1999 13:27:56 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 22C191C09; Sun, 15 Aug 1999 15:28:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 1477B3822; Sun, 15 Aug 1999 15:28:15 -0400 (EDT) Date: Sun, 15 Aug 1999 15:28:15 -0400 (EDT) From: Bill Fumerola To: Wilko Bulte Cc: Sheldon Hearn , walton@nordicrecords.com, nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <199908141800.UAA59060@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 14 Aug 1999, Wilko Bulte wrote: > Yeah... isn't it time you Yanks got together and stormed that Trade Dept? > I mean, if you can get excited over a few wooden crates containing tea... The federal agents carry sub-machine guns, this is less workable now-a-days. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 15 14:57: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 1B738153AC for ; Sun, 15 Aug 1999 14:56:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id OAA02500 for ; Sun, 15 Aug 1999 14:56:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id OAA98090 for hackers@freebsd.org; Sun, 15 Aug 1999 14:56:46 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 15 Aug 1999 14:56:45 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: hackers@freebsd.org Subject: Getting device and inode number from a vnode Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have two VFS-related questions which are probably pretty basic. 1. I have a pointer to a vnode and I want to get the corresponding dev_t and inode number. Is there a non-sleazy way to do that other than calling vn_stat? 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) says, "The file should not be locked on entry." But when stat calls vn_stat, the vnode is locked. Which is correct -- or doesn't it matter? Thanks, John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 15:16:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id 7083914D47 for ; Sun, 15 Aug 1999 15:16:48 -0700 (PDT) (envelope-from walton@nordicrecords.com) Received: (qmail 26171 invoked by alias); 15 Aug 1999 22:15:06 -0000 Message-ID: <19990815221506.26168.qmail@modgud.nordicrecords.com> Received: (qmail 26152 invoked from network); 15 Aug 1999 22:15:05 -0000 Received: from adsl-216-103-90-137.dsl.snfc21.pacbell.net (HELO walton) (216.103.90.137) by mail.nordicdms.com with SMTP; 15 Aug 1999 22:15:05 -0000 From: "Dave Walton" To: nsayer@freebsd.org, freebsd-hackers@freebsd.org, Kris Kennaway Date: Sun, 15 Aug 1999 15:13:23 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Whither makefiles for src/crypto/telnet/* ? Reply-To: walton@nordicrecords.com X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14 Aug 99, at 5:43, Nick Sayer wrote: > Dave Walton wrote: > > > > If you really want to work on an encrypted telnet, check out The > > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. > > Again, the problem is that there is administrative overhead - a separate > password database is required. Yes, there is /etc/tpasswd to deal with. I guess what I should have said is that I'd love to see SRP integrated into FreeBSD (as PAM, perhaps?). Properly done, the various system utilities would keep passwd, master.passwd and tpasswd in sync, and SRP authentication/encryption would be available to telnet, ftp, or anything else. (Disclaimer: Authentication and PAM are way outside of anything I know anything about, so I really have no idea what it would take to make that work.) > Keep in mind, also, that as long as AUTHTYPE_SRP and > AUTHTYPE_SRA are different numbers, both could be present. I > would even conceed that SRP should be tried before SRA. But I'd > sure as hell rather use SRA than nothing. Ok, Nick implements SRA for folks in heterogenous NIS environments, and Kris implements SRP for those of us without that restriction. How's that for a non-cryptographic compromise? :) Unfortunately, this whole discussion ignores one ugly problem: client availability. I've never heard of SRA before, and the only non- Unix SRP telnet client I'm aware of is a hacked version of TeraTerm and only supports authentication, not encryption. Without good clients on certain unnamed widespread OS's, most people will continue to use plaintext due to a complete lack of choice. Dave ---------------------------------------------------------------------- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide walton@nordicdms.com http://www.nordicdms.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 15 15:33:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 6838314CF3 for ; Sun, 15 Aug 1999 15:33:14 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id SAA24677; Sun, 15 Aug 1999 18:40:04 -0400 (EDT) Date: Sun, 15 Aug 1999 18:40:00 -0400 (EDT) From: Alfred Perlstein To: John Polstra Cc: hackers@FreeBSD.ORG Subject: Re: Getting device and inode number from a vnode In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, John Polstra wrote: > I have two VFS-related questions which are probably pretty basic. > > 1. I have a pointer to a vnode and I want to get the corresponding > dev_t and inode number. Is there a non-sleazy way to do that other > than calling vn_stat? use vn_todev from "vfs_subr.c" ~line 2970 of 2976 if you just need the dev_t. but you may wind up needing the GETATTR call for the inode lookup. > 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) > says, "The file should not be locked on entry." But when stat calls > vn_stat, the vnode is locked. Which is correct -- or doesn't it > matter? the lookup at the begininngin of the stat() call's side-effect is to lock the vnode it returns but kern/vnode.src seems to indicate that the vnode's locking state doesn't matter... so does the various states that vnodes are in when called from vfs_syscalls, such as the lseek syscall. it's slighly confusing, if the vnode is locked for "access" calls why is it not locked for attribute calls? -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 15:33:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 7F8A3153C2 for ; Sun, 15 Aug 1999 15:33:20 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from icarus.kfu.com (icarus.kfu.com [170.1.70.3]) by quack.kfu.com (8.9.2/8.8.5) with ESMTP id PAA14301; Sun, 15 Aug 1999 15:33:43 -0700 (PDT) Received: from quack.kfu.com by icarus.kfu.com with ESMTP (8.9.2//ident-1.0) id PAA20862; Sun, 15 Aug 1999 15:33:43 -0700 (PDT) Message-ID: <37B74041.F24CCFB4@quack.kfu.com> Date: Sun, 15 Aug 1999 15:33:37 -0700 From: Nick Sayer Reply-To: nsayer@freebsd.org X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: walton@nordicrecords.com Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? References: <19990815221506.26168.qmail@modgud.nordicrecords.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms99BFC59FDAB7C51D27174F09" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms99BFC59FDAB7C51D27174F09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Walton wrote: > > On 14 Aug 99, at 5:43, Nick Sayer wrote: > > > Dave Walton wrote: > > > > > > If you really want to work on an encrypted telnet, check out The > > > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > > > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. > > > > Again, the problem is that there is administrative overhead - a separate > > password database is required. > > Yes, there is /etc/tpasswd to deal with. I guess what I should have > said is that I'd love to see SRP integrated into FreeBSD (as PAM, > perhaps?). Properly done, the various system utilities would keep > passwd, master.passwd and tpasswd in sync, and SRP > authentication/encryption would be available to telnet, ftp, or > anything else. True enough. You'd have to force your users to run 'passwd' once as a conversion step, and you'd have to modify scripts like 'adduser' to set up the new format. > (Disclaimer: Authentication and PAM are way outside of anything I > know anything about, so I really have no idea what it would take to > make that work.) > > > Keep in mind, also, that as long as AUTHTYPE_SRP and > > AUTHTYPE_SRA are different numbers, both could be present. I > > would even conceed that SRP should be tried before SRA. But I'd > > sure as hell rather use SRA than nothing. > > Ok, Nick implements SRA for folks in heterogenous NIS > environments, and Kris implements SRP for those of us without > that restriction. How's that for a non-cryptographic compromise? :) I can commit SRA into src/crypto/telnet immediately, if it is appropriate to do so. > Unfortunately, this whole discussion ignores one ugly problem: > client availability. It's a chicken and egg problem. But I am sure that if we build it, they will come. But only if it comes by default and has no overhead and works with legacy systems -- that is, it is a no effort drop-in. People who type "telnet" will just magically see that their session is encrypted without them doing anything different. THAT'S the only way it will start to happen. --------------ms99BFC59FDAB7C51D27174F09 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 MIIIYQYJKoZIhvcNAQcCoIIIUjCCCE4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bg0wggLMMIICNaADAgECAgMBD9UwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5 OTguOS4xNjAeFw05OTA2MzAxODQ5MThaFw0wMDA2MjkxODQ5MThaMEYxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFG5zYXllckBxdWFjay5rZnUu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtPesTaUkUiIKTgqTaoEnwlLO1SBnO RPric7/C6uigrRTS79US/3P4Lcbvu4wSy5fnsrfxqlF407Ph8D6AZyzNYStjJIG9JQmjqS/D dftViyzYAews9wnB1/fRv4MHGjLcihsxbvN8tvT97jrRk8NKTjEjZgzVw8bIKMyUAxrOVQID AQABo1QwUjARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQC MAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEA Z42MrXC1NX3nIG/c3WsEPDhhrYKXJx5H41OnPaf6WO1mK8VdNBuxKl05zaFP+MmxoN/FP142 ZUb9lNM+2AnDGt70MIW6NKt9uXgW5Pc0NOaGTm12MnjVGMa0/ugDcIRR/eZ/7PVChF7nz5GI 79q9+YrQeicewj9qy5j4HIDcsFswggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTgw OTE2MTc1NTM0WhcNMDAwOTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQG A1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAHAhWEa4/Q kyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmkHpcesOK4 m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwIDAQABozcw NTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX539IfnxrIO MA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHCuqZ2nTyV QNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3X50n25ot ThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYICHDCCAhgCAQEwgcEw gbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJh bnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBG IFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgIDAQ/VMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwODE1MjIzMzQwWjAjBgkqhkiG 9w0BCQQxFgQUwtOKncE+/69nRgcmka71BnAMVXMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYAyGHc5taFbzrQDEdMwmu0YqA19Z3zQJmofa+cu/W1r vuG2QMdSJoSH1mSjV49SoncIzt9Twk8pyuywFXQblozccRR+DRMdzNqpb2CZOSOAhVm03Naf 1zF4TbU8xk4K9FumYM7lNoLMghPS8eSfgEPEEuTqay6U9EIbc0wMmjIM3g== --------------ms99BFC59FDAB7C51D27174F09-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 15:34: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 7C5111564A; Sun, 15 Aug 1999 15:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 710C21CD7BC; Sun, 15 Aug 1999 15:33:58 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Sun, 15 Aug 1999 15:33:58 -0700 (PDT) From: Kris Kennaway To: Dave Walton Cc: nsayer@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <19990815221506.26169.qmail@modgud.nordicrecords.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Dave Walton wrote: > > Again, the problem is that there is administrative overhead - a separate > > password database is required. > > Yes, there is /etc/tpasswd to deal with. I guess what I should have > said is that I'd love to see SRP integrated into FreeBSD (as PAM, > perhaps?). Properly done, the various system utilities would keep > passwd, master.passwd and tpasswd in sync, and SRP > authentication/encryption would be available to telnet, ftp, or > anything else. > > (Disclaimer: Authentication and PAM are way outside of anything I > know anything about, so I really have no idea what it would take to > make that work.) /etc/tpasswd is a way of storing the SRP information separately for systems which cannot handle it being in /etc/passwd directly. At least with my replacement libcrypt this isn't an issue as far as I know. > > Keep in mind, also, that as long as AUTHTYPE_SRP and > > AUTHTYPE_SRA are different numbers, both could be present. I > > would even conceed that SRP should be tried before SRA. But I'd > > sure as hell rather use SRA than nothing. > > Ok, Nick implements SRA for folks in heterogenous NIS > environments, and Kris implements SRP for those of us without > that restriction. How's that for a non-cryptographic compromise? :) I don't have a problem with that. The only issue which (to my knowledge) has never been addressed anywhere is the authentication protocol exchange between client and server and a formalized API (PAM doesn't do this: it communicates between a server and arbitrary backend, among other things, but doesn't specify the client/server interaction). Ideally, things like SRP, SRA, CHAP, PAP, etc, should be available as plugins to client/server apps, so we don't have to make separate patches to telnet/telnetd, ftp/ftpd, etc, for all of the authentication protocols-of-the-day. This would make a good RFC if one does not already exist. > Unfortunately, this whole discussion ignores one ugly problem: > client availability. I've never heard of SRA before, and the only non- > Unix SRP telnet client I'm aware of is a hacked version of TeraTerm > and only supports authentication, not encryption. Without good > clients on certain unnamed widespread OS's, most people will > continue to use plaintext due to a complete lack of choice. I think I've heard rumours of agreements by some of the superpowers (Microsoft, etc) to standardize on SRP. This presumably means a common protocol. I should look into this more - anyone have any real information? Kris > > Dave > > > ---------------------------------------------------------------------- > Dave Walton > Webmaster, Postmaster Nordic Entertainment Worldwide > walton@nordicdms.com http://www.nordicdms.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 15 15:47:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0DB0A15271 for ; Sun, 15 Aug 1999 15:47:17 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id PAA02661; Sun, 15 Aug 1999 15:47:40 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id PAA98225; Sun, 15 Aug 1999 15:47:40 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 15 Aug 1999 15:47:40 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Alfred Perlstein Subject: Re: Getting device and inode number from a vnode Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > On Sun, 15 Aug 1999, John Polstra wrote: >> >> 1. I have a pointer to a vnode and I want to get the corresponding >> dev_t and inode number. Is there a non-sleazy way to do that other >> than calling vn_stat? > > use vn_todev from "vfs_subr.c" ~line 2970 of 2976 if you just > need the dev_t. Thanks. I didn't make it clear in my question, but I want the dev_t of the filesystem containing the file (st_dev rather than st_rdev). > but you may wind up needing the GETATTR call for the inode lookup. OK. >> 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) >> says, "The file should not be locked on entry." But when stat calls >> vn_stat, the vnode is locked. Which is correct -- or doesn't it >> matter? > > the lookup at the begininngin of the stat() call's side-effect is to > lock the vnode it returns but kern/vnode.src seems to indicate > that the vnode's locking state doesn't matter... Ah, good. That helps. > so does the various states that vnodes are in when called from > vfs_syscalls, such as the lseek syscall. Yes, and fstat doesn't lock it either. > it's slighly confusing, if the vnode is locked for "access" calls > why is it not locked for attribute calls? I'm confused too. :-) John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 15:55:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CED6415271; Sun, 15 Aug 1999 15:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B79F61CD663; Sun, 15 Aug 1999 15:55:20 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Sun, 15 Aug 1999 15:55:20 -0700 (PDT) From: Kris Kennaway To: Dave Walton Cc: nsayer@freebsd.org, freebsd-hackers@freebsd.org Subject: SRP (Was: Re: Whither makefiles for src/crypto/telnet/* ?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Kris Kennaway wrote: > The only issue which (to my knowledge) has never been addressed anywhere > is the authentication protocol exchange between client and server and a > formalized API (PAM doesn't do this: it communicates between a server and > arbitrary backend, among other things, but doesn't specify the > client/server interaction). Ideally, things like SRP, SRA, CHAP, PAP, etc, > should be available as plugins to client/server apps, so we don't have to > make separate patches to telnet/telnetd, ftp/ftpd, etc, for all of the > authentication protocols-of-the-day. This would make a good RFC if one > does not already exist. RFC 2222, Simple Authentication and Security Layer (SASL) seems to cover this from my initial skimming. This would be the way to go for both SRP and SRA, IMO. There may already be RFCs describing the integration of telnet with SASL (although I couldn't find any). SASL doesn't specify the API as far as I can tell. We should look for existing efforts and try and standardize. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 16:34:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id F083D15028 for ; Sun, 15 Aug 1999 16:34:45 -0700 (PDT) (envelope-from walton@nordicrecords.com) Received: (qmail 26446 invoked by alias); 15 Aug 1999 23:34:58 -0000 Message-ID: <19990815233458.26443.qmail@modgud.nordicrecords.com> Received: (qmail 26432 invoked from network); 15 Aug 1999 23:34:58 -0000 Received: from adsl-216-103-90-137.dsl.snfc21.pacbell.net (HELO walton) (216.103.90.137) by mail.nordicdms.com with SMTP; 15 Aug 1999 23:34:58 -0000 From: "Dave Walton" To: nsayer@freebsd.org, freebsd-hackers@freebsd.org Date: Sun, 15 Aug 1999 16:33:15 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Whither makefiles for src/crypto/telnet/* ? Reply-To: walton@nordicrecords.com In-reply-to: <37B74041.F24CCFB4@quack.kfu.com> X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Aug 99, at 15:33, Nick Sayer wrote: > True enough. You'd have to force your users to run 'passwd' once as a > conversion step, and you'd have to modify scripts like 'adduser' to > set up the new format. And on a fresh install you wouldn't even need to do that. > I can commit SRA into src/crypto/telnet immediately, if it is > appropriate to do so. Great. Fire off a quick note to Bill Clinton asking if it's ok. > It's a chicken and egg problem. But I am sure that if we build it, > they will come. But only if it comes by default and has no > overhead and works with legacy systems -- that is, it is a no > effort drop-in. People who type "telnet" will just magically see > that their session is encrypted without them doing anything different. > THAT'S the only way it will start to happen. Yup, which is why SRP is so attractive to me compared to SSH, Kerberos, and whatever other systems there are that I've never had time to learn how to use... Dave ---------------------------------------------------------------------- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide walton@nordicdms.com http://www.nordicdms.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 15 16:50:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id C5AA614C45 for ; Sun, 15 Aug 1999 16:50:22 -0700 (PDT) (envelope-from walton@nordicrecords.com) Received: (qmail 26475 invoked by alias); 15 Aug 1999 23:50:19 -0000 Message-ID: <19990815235019.26473.qmail@modgud.nordicrecords.com> Received: (qmail 26462 invoked from network); 15 Aug 1999 23:50:18 -0000 Received: from adsl-216-103-90-137.dsl.snfc21.pacbell.net (HELO walton) (216.103.90.137) by mail.nordicdms.com with SMTP; 15 Aug 1999 23:50:18 -0000 From: "Dave Walton" To: Kris Kennaway , freebsd-hackers@freebsd.org Date: Sun, 15 Aug 1999 16:48:35 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Whither makefiles for src/crypto/telnet/* ? Reply-To: walton@nordicrecords.com References: <19990815221506.26169.qmail@modgud.nordicrecords.com> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Aug 99, at 15:33, Kris Kennaway wrote: > /etc/tpasswd is a way of storing the SRP information separately for > systems which cannot handle it being in /etc/passwd directly. At least > with my replacement libcrypt this isn't an issue as far as I know. Even better. > Ideally, things like SRP, SRA, CHAP, PAP, etc, > should be available as plugins to client/server apps, so we don't have to > make separate patches to telnet/telnetd, ftp/ftpd, etc, for all of the > authentication protocols-of-the-day. I thought that the purpose of PAM was to do just that, at least for the server side (telnetd, ftpd, etc). Am I mistaken? > I think I've heard rumours of agreements by some of the superpowers > (Microsoft, etc) to standardize on SRP. Oh hell, now it's ruined. :) > This presumably means a common protocol. Until someone pulls "embrace and extend" on us... > I should look into this more - anyone have any real information? It's news to me. The only time I've seen SRP and Microsoft in the same sentence, it's meant "Suggested Retail Price". On the other hand, a quick search for "Microsoft and SRP" led me to discover that Kermit95 supports SRP authentication. It's a start, at least. Dave ---------------------------------------------------------------------- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide walton@nordicdms.com http://www.nordicdms.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 15 17:11: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id B1E3015137 for ; Sun, 15 Aug 1999 17:11:00 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from medusa.kfu.com (medusa.kfu.com [170.1.70.5]) by quack.kfu.com (8.9.2/8.8.5) with ESMTP id RAA19192; Sun, 15 Aug 1999 17:09:51 -0700 (PDT) Received: from localhost (nsayer@localhost) by medusa.kfu.com (8.9.2/8.8.8) with ESMTP id RAA03263; Sun, 15 Aug 1999 17:09:51 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) X-Authentication-Warning: medusa.kfu.com: nsayer owned process doing -bs Date: Sun, 15 Aug 1999 17:09:49 -0700 (PDT) From: Nick Sayer X-Sender: nsayer@medusa.kfu.com To: Dave Walton Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <19990815233458.26444.qmail@modgud.nordicrecords.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 15 Aug 1999, Dave Walton wrote: > Great. Fire off a quick note to Bill Clinton asking if it's ok. > Um, I will have to make sure, but my understanding is that src/crypto on freefall (at least) is US-only, so that should be ok. Anyone who wants to grab the SRA stuff from that University in Germany and add it to an international equivalent would be welcome to do so. I can provide a server for interoperability testing (but I probably can't help any more than that). -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBN7dWz0CLGriVtPIREQKPOwCfV7/dsuLVWjm0HbX0g8tZdcQZPPsAn2qb 25Cov0asJ7cpG/rSiPyA8XKZ =RRup -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 17:50:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 58A9414FBE; Sun, 15 Aug 1999 17:50:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 468B71CD689; Sun, 15 Aug 1999 17:50:49 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Sun, 15 Aug 1999 17:50:49 -0700 (PDT) From: Kris Kennaway To: Dave Walton Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <19990815235019.26474.qmail@modgud.nordicrecords.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Dave Walton wrote: > > Ideally, things like SRP, SRA, CHAP, PAP, etc, > > should be available as plugins to client/server apps, so we don't have to > > make separate patches to telnet/telnetd, ftp/ftpd, etc, for all of the > > authentication protocols-of-the-day. > > I thought that the purpose of PAM was to do just that, at least for > the server side (telnetd, ftpd, etc). Am I mistaken? PAM manages the interaction between a server and a backend - e.g. a passwd file, a RADIUS server or a kerberos ticket server. An application says to PAM "this guy is claiming to be this user, go and authenticate him and tell me whether you succeed". This is fine - PAM should definitely be used for SRP authentication - but it doesn't specify the format of the authentication exchange back with the client. That should (my working hypothesis) be done via SASL (Simple Authentication and Security Layer), for which there are internet drafts about operation with telnet and other protocols, but I really haven't thought about the murky details of implementation yet. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 18:21:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id EB82814D45 for ; Sun, 15 Aug 1999 18:20:51 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id QAA00570 for ; Sun, 15 Aug 1999 16:56:27 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.1) id QAA76131 for hackers@freebsd.org; Sun, 15 Aug 1999 16:56:27 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199908152356.QAA76131@realtime.exit.com> Subject: Another odd problem. To: hackers@freebsd.org Date: Sun, 15 Aug 1999 16:56:27 -0700 (PDT) Reply-To: frank@exit.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have an old NE2000 ethernet card that's been running fine for years. I just upgraded to 3.2-stable, and now it regularly spits out the errors "ed0: remote transmit DMA failed to complete" and "ed: packets buffered, but transmitter idle". Did something change in the driver? Is my card dying? What gives? -- Frank Mayhar frank@exit.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 15 18:21:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 9132F14D45 for ; Sun, 15 Aug 1999 18:20:51 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id QAA00804 for ; Sun, 15 Aug 1999 16:06:27 -0700 (PDT) (envelope-from frank@tinker.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.1) id QAA76006 for hackers@freebsd.org; Sun, 15 Aug 1999 16:06:26 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199908152306.QAA76006@realtime.exit.com> Subject: Keyboard problems w/3.2-stable. To: hackers@freebsd.org Date: Sun, 15 Aug 1999 16:06:26 -0700 (PDT) Reply-To: frank@exit.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM934758386-75982-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM934758386-75982-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems to be working okay, except the keyboard. It works fine under the BIOS, and during the bootstrap, but by the time it gets to the login prompt, it stops responding entirely. I've tried several different fixes (changing console drivers, cycling power on the system, and things like that), but nothing is working. It's bound to be something simple I'm missing; it worked fine under 2.2.8. I've enclosed the dmesg and config file as attachments. Any pointers would be greatly appreciated. -- Frank Mayhar frank@exit.com --ELM934758386-75982-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=tinker.dmesg Content-Description: tinker.dmesg Content-Transfer-Encoding: 7bit Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sun Aug 15 15:06:08 PDT 1999 frank@realtime.exit.com:/usr/src/sys/compile/TINKER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 132632402 Hz CPU: Pentium/P54C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 62164992 (60708K bytes) Preloaded elf kernel "kernel" at 0xc02cd000. Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.7.0 vga0: rev 0x00 on pci0.9.0 tl0: rev 0x10 int a irq 12 on pci0.10.0 tl0: Ethernet address: 00:08:c7:28:52:93 tl0: autoneg complete, link status good (full-duplex, 100Mbps) ahc0: rev 0x00 int a irq 11 on pci0.12.0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x320-0x33f irq 10 on isa ed0: address 00:40:05:11:b2:70, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 flags 0x10 on isa sio1: type 16550A ppc0 at 0x278 irq 7 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging limited to 100 packets/entry ccd0-15: Concatenated disk drivers Waiting 8 seconds for SCSI devices to settle changing root device to da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 6.756MB/s transfers (6.756MHz, offset 15) da1: 1170MB (2396970 512 byte sectors: 255H 63S/T 149C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 8.064MB/s transfers (8.064MHz, offset 8) da2: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da3: 1001MB (2051000 512 byte sectors: 64H 32S/T 1001C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) --ELM934758386-75982-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=TINKER Content-Description: TINKER Content-Transfer-Encoding: 7bit # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.140 1998/12/27 13:55:47 sos Exp $ machine "i386" cpu "I586_CPU" ident TINKER maxusers 128 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device options NFS #Network Filesystem options MFS #Memory File System options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE #Allow users to grab the console options "NSWAPDEV=8" options COMPAT_LINUX options SYSVSHM options SYSVSEM options SYSVMSG options KTRACE #kernel tracing options "MAXDSIZ=(512*1024*1024)" options "DFLDSIZ=(512*1024*1024)" options "MD5" options MROUTING options SOFTUPDATES options IPFIREWALL options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPDIVERT #divert sockets options ICMP_BANDLIM options DDB #kernel debugger options DDB_UNATTENDED #Recover from panics. config kernel root on da0 controller isa0 controller pci0 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 #controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 controller ahc0 controller scbus0 at ahc0 # Single bus device options AHC_ALLOW_MEMIO controller scbus0 at ahc0 disk da0 at scbus0 target 0 disk da1 at scbus0 target 1 disk da2 at scbus0 target 2 disk da3 at scbus0 target 3 device sa0 #SCSI tapes device cd0 #SCSI CD-ROMs device pass0 #CAM passthrough driver device pt0 at scbus? # SCSI processor type options SCSI_DELAY=8000 # Be pessimistic about Joe SCSI device #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #device mcd1 at isa? port 0x340 bio irq 11 vector mcdintr #controller matcd0 at isa? port ? bio #device scd0 at isa? port 0x230 bio # The keyboard controller; it controls the keyboard and the PS/2 mouse. controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at atkbdc? irq 1 device psm0 at isa? disable tty irq 12 device vga0 at isa? port ? conflicts # The syscons console driver (sco color console compatible). device sc0 at isa? tty options MAXCONS=4 # splash screen/screen saver pseudo-device splash # The pcvt console driver (vt220 compatible). #device vt0 at isa? tty #options XSERVER # support for running an X server. #options FAT_CURSOR # start with block cursor # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=211 #options "PCVT_NSCREENS=4" # Four screens #options PCVT_PRETTYSCRNS options XSERVER # include code for XFree86 device npx0 at isa? port IO_NPX irq 13 device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 flags 0x10 irq 3 #device sio0 at isa? port IO_COM1 flags 0x10 irq 4 vector siointr #device sio1 at isa? port IO_COM2 flags 0x10 irq 3 vector siointr #device lpt0 at isa? port? tty irq 7 vector lptintr controller ppbus0 device lpt0 at ppbus? device ppc0 at isa? port? irq 7 #device lpt0 at isa? port? tty irq 7 vector lptintr #device lpt1 at isa? port? tty #device lpt2 at isa? port? tty #device qcam0 at isa? port "IO_LPT2" tty # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device tl0 device ed0 at isa? port 0x320 irq 10 iomem 0xd8000 #device ed0 at isa? port 0x320 irq 10 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether #pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 4 pseudo-device pty 64 pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device vn #Vnode driver pseudo-device ccd 16 # 16 Concatenated disk devices. --ELM934758386-75982-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 18:26: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.218.96.75]) by hub.freebsd.org (Postfix) with ESMTP id 4E45514D45 for ; Sun, 15 Aug 1999 18:26:01 -0700 (PDT) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (housley@localhost [127.0.0.1]) by thehousleys.net (8.9.3/8.9.3) with ESMTP id VAA22290; Sun, 15 Aug 1999 21:26:17 -0400 (EDT) (envelope-from jim@thehousleys.net) Message-ID: <37B768B9.CCED7660@thehousleys.net> Date: Sun, 15 Aug 1999 21:26:17 -0400 From: "James E. Housley" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: frank@exit.com Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard problems w/3.2-stable. References: <199908152306.QAA76006@realtime.exit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Frank Mayhar wrote: > > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. > I see the atkbdc (Keyboard controller) but not atckbd0 (the keyboard device) # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 That is probably your problem. -- James E. Housley PGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: pagejim@notepage.com 7C F0 B5 BF 27 8B 92 FE "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 18:33:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 589ED14E95 for ; Sun, 15 Aug 1999 18:33:16 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:hFgGAQdh8XVsWoS4WNrNqkQ1+6bQNr1w@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id KAA25428; Mon, 16 Aug 1999 10:33:30 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id KAA19867; Mon, 16 Aug 1999 10:37:49 +0900 (JST) Message-Id: <199908160137.KAA19867@zodiac.mech.utsunomiya-u.ac.jp> To: frank@exit.com Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Keyboard problems w/3.2-stable. In-reply-to: Your message of "Sun, 15 Aug 1999 16:06:26 MST." <199908152306.QAA76006@realtime.exit.com> References: <199908152306.QAA76006@realtime.exit.com> Date: Mon, 16 Aug 1999 10:37:48 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ># The keyboard controller; it controls the keyboard and the PS/2 mouse. >controller atkbdc0 at isa? port IO_KBD tty >device atkbd0 at atkbdc? irq 1 ~~~~~~~ -> isa? >device psm0 at isa? disable tty irq 12 >device vga0 at isa? port ? conflicts Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 18:39:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.218.96.75]) by hub.freebsd.org (Postfix) with ESMTP id A8999153FC for ; Sun, 15 Aug 1999 18:39:34 -0700 (PDT) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (housley@localhost [127.0.0.1]) by thehousleys.net (8.9.3/8.9.3) with ESMTP id VAA22463; Sun, 15 Aug 1999 21:39:58 -0400 (EDT) (envelope-from jim@thehousleys.net) Message-ID: <37B76BED.E9B5198C@thehousleys.net> Date: Sun, 15 Aug 1999 21:39:57 -0400 From: "James E. Housley" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: Kazutaka YOKOTA Subject: Re: Keyboard problems w/3.2-stable. References: <199908152306.QAA76006@realtime.exit.com> <199908160137.KAA19867@zodiac.mech.utsunomiya-u.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kazutaka YOKOTA wrote: > > ># The keyboard controller; it controls the keyboard and the PS/2 mouse. > >controller atkbdc0 at isa? port IO_KBD tty > >device atkbd0 at atkbdc? irq 1 > ~~~~~~~ -> isa? > You are right. They kept changing that in LINT/GENERIC. I guess I missed the last one. Jim -- James E. Housley PGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: pagejim@notepage.com 7C F0 B5 BF 27 8B 92 FE "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 19:29: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by hub.freebsd.org (Postfix) with ESMTP id 52AC314BE1 for ; Sun, 15 Aug 1999 19:29:01 -0700 (PDT) (envelope-from assar@sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id EAA07342; Mon, 16 Aug 1999 04:30:16 +0200 (CEST) To: John Polstra Cc: hackers@FreeBSD.ORG Subject: Re: Getting device and inode number from a vnode References: Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 16 Aug 1999 04:30:15 +0200 In-Reply-To: John Polstra's message of "Sun, 15 Aug 1999 14:56:45 -0700 (PDT)" Message-ID: <5lhfm0lao7.fsf@assaris.sics.se> Lines: 17 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra writes: > 1. I have a pointer to a vnode and I want to get the corresponding > dev_t and inode number. Is there a non-sleazy way to do that other > than calling vn_stat? I think you just want to call VOP_GETATTR(vp, vap, cred, proc) and then look at vap->va_fsid and vap->va_fileid. > 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) > says, "The file should not be locked on entry." But when stat calls > vn_stat, the vnode is locked. Which is correct -- or doesn't it > matter? According to vnode_if.src getattr shouldn't change the locked status of a vnode. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 20: 4:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-17.ppp.wenet.net [206.15.85.17]) by hub.freebsd.org (Postfix) with ESMTP id CBEC4153E9 for ; Sun, 15 Aug 1999 20:04:19 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id UAA36722; Sun, 15 Aug 1999 20:04:41 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 15 Aug 1999 20:04:40 -0700 (PDT) From: Alex Zepeda To: Bill Fumerola Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Bill Fumerola wrote: > On Sat, 14 Aug 1999, Wilko Bulte wrote: > > > Yeah... isn't it time you Yanks got together and stormed that Trade Dept? > > I mean, if you can get excited over a few wooden crates containing tea... > > The federal agents carry sub-machine guns, this is less workable now-a-days. And we have a reliable postal service now too. So you could either push a bunch of employees over the edge, or start a letter writing campain. E-mail is much easier to ignore than say a barrage of letters. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 20:12: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id 74DC2153CE for ; Sun, 15 Aug 1999 20:11:58 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id XAA18045 for ; Sun, 15 Aug 1999 23:12:04 -0400 (EDT) (envelope-from lile@stdio.com) Date: Sun, 15 Aug 1999 23:12:04 -0400 (EDT) From: Larry Lile To: hackers@freebsd.org Subject: How do you allocate dma channel with newbus? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am feeling a little dense today, how do you allocate a dma channel for a PCI busmaster device with newbus? Larry Lile lile@stdio.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 15 21:26:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 7C5A814BD0 for ; Sun, 15 Aug 1999 21:25:55 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id VAA14603; Sun, 15 Aug 1999 21:24:33 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37B79283.26E5253A@gorean.org> Date: Sun, 15 Aug 1999 21:24:35 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0811 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: gethostbyaddr() and threads. References: <199908140241.TAA25764@usr04.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > I object because it perpetuates a situation which has made it > take this long to get the issue addressed. > > I also object because BIND 9 is currently in the works, and there > is talk of replacing the AAAA records with A6 records in the DNSEXT > working group. > > The resolver should be in a seperate library to facilitate speedy > integration of future releases, and because its designers put it > in a seperate library. > > The correct way to get historical BSD behaviour, i.e. linking libc > gives you the resolver, is to take advantage of ELF, and link the > libc against the libresolver, and thus incorporate it by reference > (if this doesn't work in FreeBSD, it should; I haven't checked). > > Of course, my ideal world would update all of the Makefiles for > all of the network utilities (including the ports) to know about > libresolver explicitly, but that's unlikely to come to pass. Here here. Think of this as a "me too," or a vote in favor of each of the points above. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 22:18:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from colin.muc.de (colin.muc.de [193.149.48.1]) by hub.freebsd.org (Postfix) with SMTP id D347514F10; Sun, 15 Aug 1999 22:18:49 -0700 (PDT) (envelope-from lutz@muc.de) Received: from tavari.muc.de ([193.149.49.22]) by colin.muc.de with SMTP id <140565-3>; Mon, 16 Aug 1999 07:19:08 +0200 Received: (from uucp@localhost) by tavari.muc.de (8.8.8/8.8.7) id HAA16334; Mon, 16 Aug 1999 07:15:53 +0200 (CEST) Received: from ripley.tavari.muc.de(192.168.42.202), claiming to be "RIPLEY" via SMTP by smptd, id smtpdb16332; Mon Aug 16 07:15:53 1999 Date: Mon, 16 Aug 1999 07:15:41 +0200 From: Lutz Albers To: Kris Kennaway , Dave Walton Cc: nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: SRP (Was: Re: Whither makefiles for src/crypto/telnet/* ?) Message-ID: <2779837825.934787741@RIPLEY> In-Reply-To: Originator-Info: login-id=lutz; server=mail X-Mailer: Mulberry (Win32) [1.4.4, s/n U-301229] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --On Sonntag, 15. August 1999, 15:55 -0700 Kris Kennaway wrote: > On Sun, 15 Aug 1999, Kris Kennaway wrote: > > RFC 2222, Simple Authentication and Security Layer (SASL) > seems to cover this from my initial skimming. This would be the way to go > for both SRP and SRA, IMO. There may already be RFCs describing the > integration of telnet with SASL (although I couldn't find any). > > SASL doesn't specify the API as far as I can tell. We should look for > existing efforts and try and standardize. You might want to check the Cyrus-SASL library as ftp://ftp.andrew.cmu.edu/pub/cyrus-mail. I haven't looked into it, but it seems like what you're searching for. ciao lutz -- Lutz Albers, lutz@muc.de, pgp key available from Do not take life too seriously, you will never get out of it alive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 15 22:42:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 3AD6C14F3F for ; Sun, 15 Aug 1999 22:42:29 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id WAA00441; Sun, 15 Aug 1999 22:41:00 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.1) id WAA77811; Sun, 15 Aug 1999 22:41:00 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199908160541.WAA77811@realtime.exit.com> Subject: Re: Keyboard problems w/3.2-stable. In-Reply-To: From frank at "Aug 15, 1999 4: 6:26 pm" To: frank@exit.com Date: Sun, 15 Aug 1999 22:40:59 -0700 (PDT) Cc: hackers@freebsd.org Reply-To: frank@exit.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar frank@exit.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 15 22:49:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 36D7E14FDC for ; Sun, 15 Aug 1999 22:49:38 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id WAA00586 for ; Sun, 15 Aug 1999 22:48:28 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.1) id WAA77862 for hackers@freebsd.org; Sun, 15 Aug 1999 22:48:27 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199908160548.WAA77862@realtime.exit.com> Subject: Re: Keyboard problems w/3.2-stable. In-Reply-To: From frank at "Aug 15, 1999 4: 6:26 pm" To: frank@exit.com Date: Sun, 15 Aug 1999 22:40:59 -0700 (PDT) Cc: hackers@freebsd.org Reply-To: frank@exit.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar frank@exit.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 15 23:11:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles524.castles.com [208.214.165.88]) by hub.freebsd.org (Postfix) with ESMTP id 30ADF15506 for ; Sun, 15 Aug 1999 23:11:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA16944; Sun, 15 Aug 1999 23:06:11 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908160606.XAA16944@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Larry Lile Cc: hackers@freebsd.org Subject: Re: How do you allocate dma channel with newbus? In-reply-to: Your message of "Sun, 15 Aug 1999 23:12:04 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Aug 1999 23:06:11 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am feeling a little dense today, how do you allocate a > dma channel for a PCI busmaster device with newbus? It's a bus master, so you don't. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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 16 1: 9:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 6FC6A14F5C; Mon, 16 Aug 1999 01:09:30 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 16 Aug 1999 09:06:31 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Q99XZFMX; Mon, 16 Aug 1999 09:06:21 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 11GHn7-000Luz-00; Mon, 16 Aug 1999 09:06:49 +0100 Date: Mon, 16 Aug 1999 09:06:49 +0100 To: "Brian F. Feldman" Cc: James Howard , Mike Smith , Jason Thorpe , Terry Lambert , Mark Tinguely , Hackers@FreeBSD.org Subject: Re: BSD XFS Port & BSD VFS Rewrite Message-Id: <19990816090648.A84226@voodoo.pandhm.co.uk> References: MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Brian F. Feldman on Sat, Aug 14, 1999 at 12:23:00PM -0400 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Aug 14, 1999 at 12:23:00PM -0400, Brian F. Feldman wrote: > On Sat, 14 Aug 1999, James Howard wrote: > > I heard somewhere that Linux was released under a slightly modified GPL to > > permit the inclusion of BSD code. I assumed they did this to steal the IP > > stack. > > Most likely. Nope. Linux has always had it's own IP stack. That's where the "Linux's network performance is poor" arguments came from. Of course, it's a lot better these days. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Finally, when replying to messages only quote the parts of the message your will be discussing or that are relevant. Quoting whole messages and adding two lines at the top is not good etiquette." -- Elias Levy -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 1:36:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 933E314F54 for ; Mon, 16 Aug 1999 01:36:13 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id EAA20312; Mon, 16 Aug 1999 04:35:58 -0400 From: Bill Paul Message-Id: <199908160835.EAA20312@skynet.ctr.columbia.edu> Subject: Re: How do you allocate dma channel with newbus? To: mike@smith.net.au (Mike Smith) Date: Mon, 16 Aug 1999 04:35:57 -0400 (EDT) Cc: lile@stdio.com, hackers@freebsd.org In-Reply-To: <199908160606.XAA16944@dingo.cdrom.com> from "Mike Smith" at Aug 15, 99 11:06:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3678 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Mike Smith had to walk into mine and say: > > > > I am feeling a little dense today, how do you allocate a > > dma channel for a PCI busmaster device with newbus? > > It's a bus master, so you don't. The logical conclusion is that Larry really does have a question, but he asked it badly. Since he asked it so badly that we really don't know what he meant, we should attempt to throw information at him in the hopes that we'll end up telling him what he wants. This is not as efficient as asking the question correctly the first time, but communication seems to be a lost art these days, so what can you do. First of all, with newbus, you now have pci_read_config() and pci_write_config() instead of pci_conf_read() and pci_conf_write(). The former accept a device_t and let you specify the register width (as opposed to forcing to you to use 32-bit accesses all the time). You may need to enable bus mastering and PIO/memory mapping mode in the PCI command register as before. Once you do that, you have to allocate the "resources" that you need. The first resource is the register access space. This can be either an I/O address in iospace or a memory base address. The second is the interrupt. You need to keep track of these resources in your softc structure. They are allocated with bus_alloc_resource(). For PCI devices, you used to use pci_map_port() or pci_map_mem(); now you use bus_alloc_resource() instead, which ultimately has the same effect. When you allocate the register space resource, you have to pass a pointer to a resource ID, which for PCI devices is the register to use. For the SYS_RES_IOPORT resource type, you specify the PCI iobase address register. For SYS_RES_MEMORY, you specify the the memory base address register. Once you have allocated the iospace resource, you can then use rman_get_bustag() and rman_get_bushandle() to get the bustag and bushandle that you can use with the bus_space_read()/bus_space_write() routines to read/write the device registers. The bustag and bushandle should be treated as opaque; they will let you read from iospace or memory mapped space depending on the resource type that you allocated. You also use bus_space_alloc() to allocate the interrupt resource using SYS_RES_IRQ (the resource ID is 0). To actually map the interrupt to a handler function, you need to use bus_setup_intr(). Resources can be released with bus_release_resource(), and the interrupt handler can be detached with bus_teardown_intr(). This allows you to unload drivers. For bus master DMA, you can still use vtophys() to map kernel virtual addresses to physical addresses as before. Ideally one should use the busdma routines for that, however I haven't figured out how to use them with network device drivers yet, and nobody has come forward with a nice simple example that shows how to do it (and no, I don't mean a NetBSD driver: I mean an example which will actually work in FreeBSD). The fxp, xl, sf, sk, ti and other drivers have been newbused and use bus master DMA; hopefully these should provide decent examples. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 1:48: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5BC0915436; Mon, 16 Aug 1999 01:47:58 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA31439; Mon, 16 Aug 1999 10:47:32 +0200 (CEST) (envelope-from des) To: Ruslan Ermilov Cc: Dag-Erling Smorgrav , Mark Murray , FreeBSD Hackers Subject: Re: [Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config) References: <199908111732.KAA91686@freefall.freebsd.org> <19990812120825.A87115@relay.ucb.crimea.ua> <19990812124106.B87115@relay.ucb.crimea.ua> <19990812162007.H87115@relay.ucb.crimea.ua> <19990813180020.A23485@relay.ucb.crimea.ua> From: Dag-Erling Smorgrav Date: 16 Aug 1999 10:47:31 +0200 In-Reply-To: Ruslan Ermilov's message of "Fri, 13 Aug 1999 18:00:20 +0300" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ruslan Ermilov writes: > How about the following patch. It adds an OPTIONAL_MANPATH directive, > which is equivalent to the MANDATORY_MANPATH, except an absence of the > directory is not considered an error. Sure. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 2: 0:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.uni-koeln.de (1-212.K.dial.o-tel-o.net [212.144.1.212]) by hub.freebsd.org (Postfix) with ESMTP id 6A54214E3D; Mon, 16 Aug 1999 02:00:10 -0700 (PDT) (envelope-from se@zpr.uni-koeln.de) Received: by dialup124.zpr.uni-koeln.de (Postfix, from userid 200) id 598FACDF; Sat, 14 Aug 1999 02:12:38 +0200 (CEST) Date: Sat, 14 Aug 1999 02:12:38 +0200 From: Stefan Esser To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: Configuration mechanism of PCI bus Message-ID: <19990814021238.A662@dialup124.zpr.uni-koeln.de> Reply-To: se@freebsd.org Mail-Followup-To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Zhihui Zhang on Mon, Aug 09, 1999 at 10:08:16PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-08-09 22:08 -0400, Zhihui Zhang wrote: > > Even with "PCI System Architecture, 4th edition" at hand, I still have > some problems understanding the code in isa/pcibus.c. Please point out > any misunderstanding I may have in the following: It has been some time since I write that code, but I'll try to remember why it became the way you found it ... ;-) > (1) At first, you can not modify the address port at 0xcf8 without a FULL > 32-bit write. The routine pci_cfgopen() seems to use this fact. Yes. > (2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only > 4 bits can be used as bus number, so we can have at most 16 PCI buses. This is partially true. The code assumes (and I have yet to meet a PCI BIOS that violates that assumption), that the address register will not have any of the bits masked by 0x7ff00000 set. This is generally true, since the **last** prior access to PCI config space by the BIOS will have been to a PCI bridge (i.e. to a bus number much lower than the highest PCI bus number in the system). You are correct: If the previous config cycle was to a bus higher than 15, then this heuristic will assume that there is no configuration mechanism 1 address register. I had to add that heuristic in order to prevent the PCI porbe from crahsing EISA only systems. > (3) The variable "mode1res" seems to refer to any residual left by BIOS in > the address port. If it is non-zero, we will try to find a device using > configuration mechanism 1. Yes. Writing 0xff000000 should result in 0x80000000 being read back. Only the MSB is writable, the remaining high order bits are wired to 0. This is another test that is most likely to fail for non-PCI systems. > (3) The magic constant 0xf870ff excludes many devices. How it is chosen? > I guess those excluded devices are not important or supported by FreeBSD. > It seems to me that if pci_cfgcheck() finds at least one device, then the > configuration mechanism is regarded as correctly detected. Yes. After testing for config mechanism 1 or 2, another last test is done to make sure, there is at least one PCI device on the bus. The mask is chosen in such a way, that there is at least one device on PCI bus 0, which satisfies the following conditions: class in 0..7 subclass in 0..15 or equal 0x80 (in fact 0x80 .. 0x8f are accepted) prog if equal 0 and finally class not equal 0 or subclass not equal 0 This will for example be true for a PCI VGA card (present in just about every system), which has class=0 and subclass=1 or class=3 and subclass in {0,1,0x80}. But in any PCI 2.0 or later system, the chip-set will also be present on PCI bus 0 and will cause a match with class=6 and subclass in 0 .. 7 (or 0x80). Any disk or network controller should also suffice to make this test succeed. The only case that will have this test fail is an ancient (pre PCI-2.0) system with no PCI VGA card. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 5:24:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id D5B8914F83 for ; Mon, 16 Aug 1999 05:24:43 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 183651C1F; Mon, 16 Aug 1999 20:25:06 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Larry Lile Cc: hackers@FreeBSD.org Subject: Re: How do you allocate dma channel with newbus? In-reply-to: Your message of "Sun, 15 Aug 1999 23:12:04 -0400." Date: Mon, 16 Aug 1999 20:25:06 +0800 From: Peter Wemm Message-Id: <19990816122506.183651C1F@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Larry Lile wrote: > > I am feeling a little dense today, how do you allocate a > dma channel for a PCI busmaster device with newbus? You don't. PCI busmastering doesn't use dma channels. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 8: 4:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 29FD614EBD for ; Mon, 16 Aug 1999 08:04:41 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA143097; Mon, 16 Aug 1999 09:04:06 -0600 (MDT) Date: Mon, 16 Aug 1999 09:04:06 -0600 From: "Ronald G. Minnich" To: Marc Tardif Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared memory crash In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG don't use shmget if you can. Use mmap'ed files. The SYSV shm interface is incredibly dumb. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 8:10:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from beowulf.utmb.edu (beowulf.utmb.edu [129.109.59.83]) by hub.freebsd.org (Postfix) with ESMTP id 891B914E60 for ; Mon, 16 Aug 1999 08:10:05 -0700 (PDT) (envelope-from bdodson@beowulf.utmb.edu) Received: (from bdodson@localhost) by beowulf.utmb.edu (8.9.3/8.9.2) id KAA05407; Mon, 16 Aug 1999 10:08:26 -0500 (CDT) (envelope-from bdodson) Date: Mon, 16 Aug 1999 10:08:26 -0500 (CDT) Message-Id: <199908161508.KAA05407@beowulf.utmb.edu> From: "M. L. Dodson" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "rtoren" Cc: Subject: PCCard can't get CIS for 3com card In-Reply-To: <000501bee67c$9ec69460$0a00000a@hwrd1.md.home.com> References: <000501bee67c$9ec69460$0a00000a@hwrd1.md.home.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG rtoren writes: > The card came with the Dell Inspiron and is a 3com 3CCFEM656B. > Unfortunately, I don't think 3.2R is getting enough data to attempt an ID. I > saw an archived query just like my situation in the mail archives from a > year ago, but there was no reply. > Once I get past this, I can worry about the pccard.conf and such. > I think that this is a cardbus card. If so, it is not supported. I had to buy a cheap NE2000 clone for my Inspiron 7K. The good news is that they are cheap; the bad news is that your fancy ethernet card is going to sit in a drawer until cardbus support is finished. > Boot time entries appear to be: > > fred /kernel: PC-Card VLSI 82C146 (5mem & 2 I/O windows) > fred /kernel: pcic: controller irq 3 > fred /kernel: Initializing PC-card drivers: ep sio > fred /kernel: Card inserted, slot 0 > fred pccardd[64]: No card in database for ""("") > fred pccardd[64] pccard started > > Command line probing gives > > fred# pccardc dumpcis > Configuration data for card in slot 0 > Tuple #1, code = 0xff (Terminator), length = 0 > 2 slots found > > Any assistance would be greatly appreciated > Rip Toren > rtoren@bronzedragon.net > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- M. L. Dodson bdodson@scms.utmb.edu 409-772-2178 FAX: 409-772-1790 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 8:31:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 912CD14FE9 for ; Mon, 16 Aug 1999 08:31:10 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id IAA08126; Mon, 16 Aug 1999 08:31:30 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpdAAAQKaOTp; Mon Aug 16 08:31:23 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id IAA12294; Mon, 16 Aug 1999 08:31:20 -0700 (MST) From: Terry Lambert Message-Id: <199908161531.IAA12294@usr04.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov (Bill Studenmund) Date: Mon, 16 Aug 1999 15:31:20 +0000 (GMT) Cc: tlambert@primenet.com, tinguely@plains.NoDak.edu, howardjp@wam.umd.edu, Hackers@FreeBSD.ORG In-Reply-To: from "Bill Studenmund" at Aug 13, 99 04:01:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > Has anyone mentioned to them that they will be unable to incorporate > > changes made to the GPL'ed version of XFS back into the IRIX version > > of XFS, without IRIX becoming GPL'ed? > > Given that they say they're dropping IRIX and going with Linux, I don't > think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? PS: I fired off a note to Dr. Forest Baskett at SGI (their senior VP for R & D, and their CTO) about the license, and FS researchers in the BSD community (e.g. Dr. Margo Seltzer, Dr. Kirk McKusick, John Heidemann, et. al.) which will be unable to participated in driving their technology forward because of the license. I will report the response (if any). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 8:51: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 1560014CBB for ; Mon, 16 Aug 1999 08:50:57 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11GP22-000PB4-00; Mon, 16 Aug 1999 17:50:42 +0200 From: Sheldon Hearn To: hackers@freebsd.org Cc: Andrew Lofthouse Subject: Re: IDE quirk in 3.2-STABLE kernel ? Date: Mon, 16 Aug 1999 17:50:42 +0200 Message-ID: <96785.934818642@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 8:51:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12]) by hub.freebsd.org (Postfix) with SMTP id 2C678154B3 for ; Mon, 16 Aug 1999 08:51:05 -0700 (PDT) (envelope-from vev@michvhf.com) Received: (qmail 6880 invoked by uid 1001); 16 Aug 1999 15:51:08 -0000 Date: Mon, 16 Aug 1999 11:51:08 -0400 (EDT) From: Vince Vielhaber To: Terry Lambert Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908161531.IAA12294@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > > > Has anyone mentioned to them that they will be unable to incorporate > > > changes made to the GPL'ed version of XFS back into the IRIX version > > > of XFS, without IRIX becoming GPL'ed? > > > > Given that they say they're dropping IRIX and going with Linux, I don't > > think it'll be a problem. > > Can you please site a reference for this, other than wishful > thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.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 16 9:20:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3090014FA0 for ; Mon, 16 Aug 1999 09:20:26 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA21525; Mon, 16 Aug 1999 09:19:51 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd021432; Mon Aug 16 09:19:42 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id JAA14130; Mon, 16 Aug 1999 09:19:36 -0700 (MST) From: Terry Lambert Message-Id: <199908161619.JAA14130@usr04.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: vev@michvhf.com (Vince Vielhaber) Date: Mon, 16 Aug 1999 16:19:36 +0000 (GMT) Cc: tlambert@primenet.com, Hackers@FreeBSD.ORG In-Reply-To: from "Vince Vielhaber" at Aug 16, 99 11:51:08 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > > > > > Has anyone mentioned to them that they will be unable to incorporate > > > > changes made to the GPL'ed version of XFS back into the IRIX version > > > > of XFS, without IRIX becoming GPL'ed? > > > > > > Given that they say they're dropping IRIX and going with Linux, I don't > > > think it'll be a problem. > > > > Can you please site a reference for this, other than wishful > > thinking by the Linux camp? > > Here's one: > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html > > But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. Nintendo 64 uses MIPS. It also seems a bit overzealous. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 9:35: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12]) by hub.freebsd.org (Postfix) with SMTP id A7AE814BFF for ; Mon, 16 Aug 1999 09:34:50 -0700 (PDT) (envelope-from vev@michvhf.com) Received: (qmail 6978 invoked by uid 1001); 16 Aug 1999 16:35:20 -0000 Date: Mon, 16 Aug 1999 12:35:20 -0400 (EDT) From: Vince Vielhaber To: Terry Lambert Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908161619.JAA14130@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > > > > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > > > > > > > Has anyone mentioned to them that they will be unable to incorporate > > > > > changes made to the GPL'ed version of XFS back into the IRIX version > > > > > of XFS, without IRIX becoming GPL'ed? > > > > > > > > Given that they say they're dropping IRIX and going with Linux, I don't > > > > think it'll be a problem. > > > > > > Can you please site a reference for this, other than wishful > > > thinking by the Linux camp? > > > > Here's one: > > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html > > > > But just about every trade rag covered it. > > > Begging your pardon, but: > > > | --- With the help of Veritas Software Corp., SGI will work to add > | key features of its Irix operating system to the Linux platform. > | Currently, Irix runs on the MIPS platform. Once SGI switches > | entirely to Intel Corp.'s IA/64 platform, that will be the end of > | Irix. > | > | SGI is also forming an alliance with NEC Corp. to increase its > | market share in Japan. > > These paragraphs are contradictory. It implies an end to MIPS. > > Nintendo 64 uses MIPS. > > It also seems a bit overzealous. No argument here. Perhaps they're just trying to float a few trial baloons in hopes of finding something popular/feasable. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.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 16 9:41:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web1001.mail.yahoo.com (web1001.mail.yahoo.com [128.11.23.91]) by hub.freebsd.org (Postfix) with SMTP id 19EF9152CB for ; Mon, 16 Aug 1999 09:41:39 -0700 (PDT) (envelope-from bvmcg@yahoo.com) Message-ID: <19990816164048.28824.rocketmail@web1001.mail.yahoo.com> Received: from [206.71.110.99] by web1001.mail.yahoo.com; Mon, 16 Aug 1999 09:40:48 PDT Date: Mon, 16 Aug 1999 09:40:48 -0700 (PDT) From: Brian McGroarty Reply-To: brian@pobox.com Subject: Re: BSD XFS Port & BSD VFS Rewrite To: Terry Lambert , Vince Vielhaber Cc: Hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --- Terry Lambert wrote: > > > > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > > > > > Can you please site a reference for this, other than > wishful > > > thinking by the Linux camp? > > > > Here's one: > > > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html > > > > But just about every trade rag covered it. > > Begging your pardon, but: > > > | --- With the help of Veritas Software Corp., SGI will work > to add > | key features of its Irix operating system to the Linux > platform. > | Currently, Irix runs on the MIPS platform. Once SGI switches > | entirely to Intel Corp.'s IA/64 platform, that will be the > end of > | Irix. > | > | SGI is also forming an alliance with NEC Corp. to increase > | its market share in Japan. > > These paragraphs are contradictory. It implies an end to > MIPS. Contradictory how? NEC's a big PC manufacurer in Japan. If SGI is moving toward more conventional off-the-shelf components, they stand to gain tremendously by an alliance, both from manufacturing and distribution standpoints. > Nintendo 64 uses MIPS. > > It also seems a bit overzealous. So do the old and new Playstation models. The MIPS core is being manufactured by several companies: IDT alone has something like a dozen variants available with and without MMU, FP, 5000 vs 10000 core, etc. and is in far wider use than in just PCs and gaming consoles. I doubt if SGI machines abandoning MIPS processors would put much of a dent in MIPS' profitability. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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 16 9:51:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 08AA414BFF for ; Mon, 16 Aug 1999 09:51:23 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id KAA147746; Mon, 16 Aug 1999 10:50:57 -0600 (MDT) Date: Mon, 16 Aug 1999 10:50:57 -0600 From: "Ronald G. Minnich" To: Vince Vielhaber Cc: Terry Lambert , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I lost track of the quotes. > > | --- With the help of Veritas Software Corp., SGI will work to add > > | key features of its Irix operating system to the Linux platform. > > | Currently, Irix runs on the MIPS platform. Once SGI switches > > | entirely to Intel Corp.'s IA/64 platform, that will be the end of > > | Irix. > > | > > | SGI is also forming an alliance with NEC Corp. to increase its > > | market share in Japan. > > These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 9:51:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cits-darla.robins.af.mil (cits-darla.robins.af.mil [137.244.215.8]) by hub.freebsd.org (Postfix) with ESMTP id 245A015284 for ; Mon, 16 Aug 1999 09:51:25 -0700 (PDT) (envelope-from Andrew.Lofthouse@robins.af.mil) Received: from cits-darla.robins.af.mil (root@localhost) by cits-darla.robins.af.mil with ESMTP id MAA01804; Mon, 16 Aug 1999 12:51:26 -0400 (EDT) Received: from fsuhhz31.robins.af.mil (fsuhhz31.robins.af.mil [137.244.190.209]) by cits-darla.robins.af.mil with ESMTP id MAA01798; Mon, 16 Aug 1999 12:51:26 -0400 (EDT) Received: by fsuhhz31.robins.af.mil with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 16:51:18 -0000 Message-ID: <3F69A3D5863ED211B31F0000F809353502D1E3F0@FSUHHZ33> From: Lofthouse Andrew 2Lt WRALC/TIECT To: Sheldon Hearn , hackers@freebsd.org Cc: Lofthouse Andrew 2Lt WRALC/TIECT Subject: RE: IDE quirk in 3.2-STABLE kernel ? Date: Mon, 16 Aug 1999 16:51:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 9:51:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id E34EC154E0; Mon, 16 Aug 1999 09:51:30 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id JAA51849; Mon, 16 Aug 1999 09:51:30 -0700 (PDT) Date: Mon, 16 Aug 1999 09:51:30 -0700 (PDT) From: David Wolfskill Message-Id: <199908161651.JAA51849@pau-amma.whistle.com> To: kris@hub.freebsd.org, nsayer@FreeBSD.ORG Subject: Re: Whither makefiles for src/crypto/telnet/* ? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Sat, 14 Aug 1999 14:35:34 -0700 (PDT) >From: Kris Kennaway >I also have prototype code which can store multiple password hashes in the >password file, and retrieves "secondaries" in a new field in struct >passwd. You could conceivably set it up to keep a DES password in sync >with the SRP one, and distribute only the DES over NIS. I don't know how >extensible NIS is, but maybe we could hide the other hashes in there as >well for those who understand them. I'm hardly an "expert" with NIS, but it is actually fairly flexible... as long as changes imposed are on its own terms. :-) For example, you can easily create a new NIS "map" (as was done with the master.passwd.by{name,uid} maps). However, systems that don't know to look anything up in such a construct will not pay attention to it. (For example, a Solaris system hasn't a clue that the map master.passwd.byname exists, much less that it shoudl be used for anything, so "login" on such a system ignores that map and tries to do password verification using the passwd.byname map. If the NIS master server is a FreeBSD box, by default the passwd.byname map merely has "*" as the encrypted password, while placing the encrypted password in master.passwd.byname. This is why it's necessary, in such a situation, to set the "UNSECURE" flag -- that way, the FreeBSD box will place the encrypted password in passwd.byname, which placates the Solaris box(en). On a FreeBSD system, there are special checks to see if the process accessing the master.passwd.by{name,uid} maps has an euid of 0; if so, the access is permitted; if not, it isn't. But the Solaris box, since it never knew about the map, certainly doesn't treat it specially, so though there's no code to access it to make any decisions, J. Random User is quite able to do (say) a "ypcat -k master.passwd.byname" from the Solaris box.) In an (arguably) similar vein, it is possible to use (new) NIS maps to hold (say) amd maps. (We do this here.) One merely needs to add the appropriate stanza(s) to the /var/yp/Makefile, and be sure that there is code in the appropriate places to go look for information in the NIS maps in question to the /var/yp/Makefile, and be sure that there is code in the appropriate places to go look for information in the NIS maps in question. So you could create new NIS maps to hold nearly any (textual) key/value pairs you feel like creating. (Unique keys for a given map would make this easier.) Whether or not actually using such a mechanism for decision-making is a Good Idea(tm) is a rather different issue, though (and is likely to be implementation (among other things) -dependent). Hope someone finds a bit of this of use, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 9:57: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cits-darla.robins.af.mil (cits-darla.robins.af.mil [137.244.215.8]) by hub.freebsd.org (Postfix) with ESMTP id 6D90715284 for ; Mon, 16 Aug 1999 09:57:03 -0700 (PDT) (envelope-from Andrew.Lofthouse@robins.af.mil) Received: from cits-darla.robins.af.mil (root@localhost) by cits-darla.robins.af.mil with ESMTP id MAA03116; Mon, 16 Aug 1999 12:55:51 -0400 (EDT) Received: from fsuhhz30.robins.af.mil (fsuhhz30.robins.af.mil [137.244.190.201]) by cits-darla.robins.af.mil with ESMTP id MAA03112; Mon, 16 Aug 1999 12:55:50 -0400 (EDT) Received: by fsuhhz30.robins.af.mil with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 16:55:29 -0000 Message-ID: <3F69A3D5863ED211B31F0000F809353502D1E3F9@FSUHHZ33> From: Lofthouse Andrew 2Lt WRALC/TIECT To: "'Sheldon Hearn'" , "'hackers@freebsd.org'" Cc: Lofthouse Andrew 2Lt WRALC/TIECT Subject: RE: IDE quirk in 3.2-STABLE kernel ? Date: Mon, 16 Aug 1999 16:55:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. NOTE on last e-mail: I mis-typed the device names; should be 'wdc0' and 'wdc1' (instead of 'wcd0' and 'wcd1') I apologize for the missing information. This problem has been posted several times (by me) to the -stable mailing list, and I simply forgot to include all the details with the bug report. The only reason why this would be a critical bug is if there were drives connected to the primary controller. In this case, I only have IDE drives, which means that the kernel cannot mount the root filesystem without wcd0 being detected. I have two drives on wcd0: a 1.27 GB Samsung as master (with root filesystem) and a 6.54 GB Seagate (with /usr, and others). I have an ATAPI CD-ROM drive as master on wcd1 (which is detected just fine). I've noticed this behaviour with every 3.- branch installation I've had on my machine (3.2-RELEASE boot disks, 3.2-STABLE). I have 4 other OSs on the same machine, so I would prefer not to mess with the physical configuration (i.e. moving disks from one controller to another, etc), which would mess up their drive configurations. Please note that this is not a problem with IRQ's, etc. I've had 2.2.8-RELEASE and -STABLE running on the same machine with absolutely no problems detecting wcd0 (and the default IRQ's and port addresses for both 2.2.8 and 3.2 are the same). Any help is appreciated. Andrew J. Lofthouse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10: 9:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id BA637154E1; Mon, 16 Aug 1999 10:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A45AC1CD892; Mon, 16 Aug 1999 10:09:29 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Mon, 16 Aug 1999 10:09:29 -0700 (PDT) From: Kris Kennaway To: David Wolfskill Cc: nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <199908161651.JAA51849@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, David Wolfskill wrote: > I'm hardly an "expert" with NIS, but it is actually fairly flexible... > as long as changes imposed are on its own terms. :-) Thanks for the information. I noticed some rumblings on the srp-dev mailing list about developing NIS support - I don't think anything has come of it yet, but that would be the place to discuss it so we can get some kind of cross-platform compatability. I'll certainly look into that further when I can start working on this again. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:17: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id BB28814E14 for ; Mon, 16 Aug 1999 10:17:04 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id KAA21891; Mon, 16 Aug 1999 10:17:19 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpdAAA9Xa4JQ; Mon Aug 16 10:17:12 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id KAA16010; Mon, 16 Aug 1999 10:17:11 -0700 (MST) From: Terry Lambert Message-Id: <199908161717.KAA16010@usr04.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: rminnich@acl.lanl.gov (Ronald G. Minnich) Date: Mon, 16 Aug 1999 17:17:11 +0000 (GMT) Cc: vev@michvhf.com, tlambert@primenet.com, Hackers@FreeBSD.ORG In-Reply-To: from "Ronald G. Minnich" at Aug 16, 99 10:50:57 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I lost track of the quotes. > > > > | --- With the help of Veritas Software Corp., SGI will work to add > > > | key features of its Irix operating system to the Linux platform. > > > | Currently, Irix runs on the MIPS platform. Once SGI switches > > > | entirely to Intel Corp.'s IA/64 platform, that will be the end of > > > | Irix. > > > | > > > | SGI is also forming an alliance with NEC Corp. to increase its > > > | market share in Japan. > > > These paragraphs are contradictory. It implies an end to MIPS. > > an end to irix and an end to MIPS on desktop and server platforms has no > big effect on MIPS processors. The big volume for MIPS is embedded, or so > I am told. > > For an interesting take on all this visit www.mipsabi.org Uh, that site is dead, as of the end of this month. See the first link ("announcement"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:19:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 8554314CF2 for ; Mon, 16 Aug 1999 10:19:51 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id KAA22159; Mon, 16 Aug 1999 10:18:04 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpdAAA47aGiR; Mon Aug 16 10:17:54 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id KAA16022; Mon, 16 Aug 1999 10:17:59 -0700 (MST) From: Terry Lambert Message-Id: <199908161717.KAA16022@usr04.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: vev@michvhf.com (Vince Vielhaber) Date: Mon, 16 Aug 1999 17:17:59 +0000 (GMT) Cc: tlambert@primenet.com, Hackers@FreeBSD.ORG In-Reply-To: from "Vince Vielhaber" at Aug 16, 99 12:35:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > These paragraphs are contradictory. It implies an end to MIPS. > > > > Nintendo 64 uses MIPS. > > > > It also seems a bit overzealous. > > No argument here. Perhaps they're just trying to float a few trial > baloons in hopes of finding something popular/feasable. That was my take on things, since no source was attributed. Either that, or press zealotry. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:23:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id C178714C31 for ; Mon, 16 Aug 1999 10:23:46 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id UAA23737; Mon, 16 Aug 1999 20:22:21 +0300 (EEST) Date: Mon, 16 Aug 1999 20:22:21 +0300 (EEST) From: Narvi To: Terry Lambert Cc: Vince Vielhaber , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908161619.JAA14130@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > > > > On Fri, 13 Aug 1999, Terry Lambert wrote: > > > > > > > > > Has anyone mentioned to them that they will be unable to incorporate > > > > > changes made to the GPL'ed version of XFS back into the IRIX version > > > > > of XFS, without IRIX becoming GPL'ed? > > > > > > > > Given that they say they're dropping IRIX and going with Linux, I don't > > > > think it'll be a problem. > > > > > > Can you please site a reference for this, other than wishful > > > thinking by the Linux camp? > > > > Here's one: > > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html > > > > But just about every trade rag covered it. > > > Begging your pardon, but: > > > | --- With the help of Veritas Software Corp., SGI will work to add > | key features of its Irix operating system to the Linux platform. > | Currently, Irix runs on the MIPS platform. Once SGI switches > | entirely to Intel Corp.'s IA/64 platform, that will be the end of > | Irix. > | Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch to IA/64, but with IRIX. If SGI wants to continue building Origins, esp the high CPU count ones, IRIX is to stay for a long time. > | SGI is also forming an alliance with NEC Corp. to increase its > | market share in Japan. > > These paragraphs are contradictory. It implies an end to MIPS. > An end to high-end MIPS may come ... if Merced, etc. peform well enough. As this is a topic beaten to death on comp.arch, everybody interested should look there. > Nintendo 64 uses MIPS. > Which doesn't matter all that much. MIPS cpus for nintendo could be made by say MISP, not SGI (and SGI sold/is trying to sell MIPS). > It also seems a bit overzealous. > You bet. It seems it is to hard foir the journalists to actually read the press releases. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:26: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 3F4EE154C7 for ; Mon, 16 Aug 1999 10:25:59 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA55290; Mon, 16 Aug 1999 13:26:03 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199908161619.JAA14130@usr04.primenet.com> References: <199908161619.JAA14130@usr04.primenet.com> Date: Mon, 16 Aug 1999 13:26:24 -0400 To: Terry Lambert From: Garance A Drosihn Subject: Re: BSD XFS Port & BSD VFS Rewrite Cc: Hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 4:19 PM +0000 8/16/99, Terry Lambert wrote: >Begging your pardon, but: > > >| --- With the help of Veritas Software Corp., SGI will work to add >| key features of its Irix operating system to the Linux platform. >| Currently, Irix runs on the MIPS platform. Once SGI switches >| entirely to Intel Corp.'s IA/64 platform, that will be the end >| of Irix. >| >| SGI is also forming an alliance with NEC Corp. to increase its >| market share in Japan. > >These paragraphs are contradictory. It implies an end to MIPS. > >Nintendo 64 uses MIPS. I don't think those paragraphs are all that contradictory. They just imply the end of SGI selling MIPS-based workstations running IRIX. Nintendo can keep using MIPS, and my guess is that Nintendo is not running IRIX on their machines. What is the contradiction? I'm making the assumption here that Nintendo sells more Nintendo 64 games than SGI sells workstations, and thus SGI dropping MIPS for workstations does *-NOT-* imply the end of MIPS. It only implies the end of IRIX. In any case, even if it is contradictory in some sense, there is no question that SGI is *claiming* that they are all buddy-buddy with linux, and thus they are already comfortable with gnu-licensed software. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:26:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CB2AA14D1D; Mon, 16 Aug 1999 10:26:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BB6F61CD892; Mon, 16 Aug 1999 10:26:57 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Mon, 16 Aug 1999 10:26:57 -0700 (PDT) From: Kris Kennaway To: nsayer@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <37B5E8CD.EBEFACDB@quack.kfu.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for not responding to this earlier, I missed it in my inbox. On Sat, 14 Aug 1999, Nick Sayer wrote: > > Where do you store the keys, or do you generate them dynamically? The > > latter would take time to verify primality. > > If by "keys" you mean the DH generator and such, they are constants in > the code at present. It is possible to extend the protocol in such a > way as to pass them from server to client, but at present it does not > do this. Having them be constant does not significantly weaken DH. If > they weren't, you'd have to pass them from the server at session > start. Are you sure about this? Having constant p, g, x and y for every telnet client and server surely makes it much easier to attack? In theory you could probably pregenerate all of the arithmetic. > > Because it does not interoperate with legacy servers over NIS? Any other > > reasons? > > If you're saying that you're going to have a new format of the second > field of the master passwd file ($3$[^:]* ?), then I suppose the only > other one left is having to convert legacy password files and manage > the N and g values that SRP requires. You'll have to fix things that > add users to have them default to the new scheme. Probably a PAM module which rehashes passwords into the new format. I'd expect one such module already exists. So you'd set up the PAM module to run as part of the login module stack and tell libcrypt that the user gets a default password of SRP. Alternatively, expire all their passwords and when they pick a new one it will be SRP. > And don't sniff at breaking NIS. Most sites I deal with use it. And I > don't know of any site that uses NIS that isn't heterogenous, which > requires the legacy password format. As David Wolfskill explained this should be solvable. > > In my scheme I distribute these as part of the password "hash". N and g > > are both public values known to both client and server(s). > > SRP has them in configuration files. They have to be set up. Yes, on the server. This is a non-issue. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 10:33:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 4A55514D1D for ; Mon, 16 Aug 1999 10:33:33 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id KAA12773; Mon, 16 Aug 1999 10:33:35 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Mon, 16 Aug 1999 10:33:35 -0700 Date: Mon, 16 Aug 1999 10:33:35 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Garance A Drosihn Cc: Terry Lambert , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: drosih@rpi.edu,tlambert@primenet.com,Hackers@FreeBSD.ORG X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't think that this is an appropriate forum but I will put in my two cents nonetheless. At least as of a couple of years age MIPS was the most widely used embedded processor in the world. Thus, MIPS is in no way dependent on IRIX. Not to mention that Linux runs on MIPS. -Kip On Mon, 16 Aug 1999, Garance A Drosihn wrote: > At 4:19 PM +0000 8/16/99, Terry Lambert wrote: > >Begging your pardon, but: > > > > > >| --- With the help of Veritas Software Corp., SGI will work to add > >| key features of its Irix operating system to the Linux platform. > >| Currently, Irix runs on the MIPS platform. Once SGI switches > >| entirely to Intel Corp.'s IA/64 platform, that will be the end > >| of Irix. > >| > >| SGI is also forming an alliance with NEC Corp. to increase its > >| market share in Japan. > > > >These paragraphs are contradictory. It implies an end to MIPS. > > > >Nintendo 64 uses MIPS. > > I don't think those paragraphs are all that contradictory. They > just imply the end of SGI selling MIPS-based workstations running > IRIX. Nintendo can keep using MIPS, and my guess is that Nintendo > is not running IRIX on their machines. What is the contradiction? > > I'm making the assumption here that Nintendo sells more Nintendo 64 > games than SGI sells workstations, and thus SGI dropping MIPS for > workstations does *-NOT-* imply the end of MIPS. It only implies > the end of IRIX. > > In any case, even if it is contradictory in some sense, there is > no question that SGI is *claiming* that they are all buddy-buddy > with linux, and thus they are already comfortable with gnu-licensed > software. > > > --- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or drosih@rpi.edu > Rensselaer Polytechnic Institute > > > 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 Mon Aug 16 10:42:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 0266014D20 for ; Mon, 16 Aug 1999 10:42:12 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2448.0) id ; Mon, 16 Aug 1999 11:42:07 -0600 Message-ID: <64003B21ECCAD11185C500805F31EC0303786CCD@houston.matchlogic.com> From: Charles Randall To: freebsd-hackers@freebsd.org Subject: illegal ATAPI command in wdc probe? Date: Mon, 16 Aug 1999 11:42:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The VMWare guest OS page for FreeBSD (http://www.vmware.com/support/technotesfreebsd.html) states, --- One caveat with all versions of FreeBSD is that there is a problem probing for the CD-ROM device wdc1; FreeBSD sends an illegal ATAPI command to the IDE controller and ignores the error status reply. This results in approximately a 1 minute delay each time the system boots. --- Is this true? Charles To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 11:18: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9735114D95 for ; Mon, 16 Aug 1999 11:17:53 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id OAA08086; Mon, 16 Aug 1999 14:18:04 -0400 (EDT) Date: Mon, 16 Aug 1999 14:18:04 -0400 (EDT) From: "Matthew N. Dodd" To: Larry Lile Cc: hackers@FreeBSD.ORG Subject: Re: How do you allocate dma channel with newbus? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Aug 1999, Larry Lile wrote: > I am feeling a little dense today, how do you allocate a > dma channel for a PCI busmaster device with newbus? I don't think PCI devices use the ISA DMA controller. "It just works." (EISA has this advantage too.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 11:36:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leaf.crc.ricoh.com (gateway.crc.ricoh.com [205.226.66.126]) by hub.freebsd.org (Postfix) with ESMTP id CDBAA15487; Mon, 16 Aug 1999 11:36:32 -0700 (PDT) (envelope-from mjaffe@rsv.ricoh.com) Received: from adc1.adc.rsv.ricoh.com (adc1.adc.rsv.ricoh.com [172.30.31.30]) by leaf.crc.ricoh.com (8.9.3/8.9.1) with ESMTP id LAA23229; Mon, 16 Aug 1999 11:35:28 -0700 (PDT) Received: from rsv.ricoh.com by adc1.adc.rsv.ricoh.com (8.8.8/3.6Wpre2-98122121) id LAA05603; Mon, 16 Aug 1999 11:36:58 -0700 (PDT) Message-ID: <37B86A59.9462A5AB@rsv.ricoh.com> Date: Mon, 16 Aug 1999 12:45:29 -0700 From: Mark Jaffe Organization: Ricoh Silicon Valley X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: [Fwd: [URGENT] CVS problems] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Jaffe wrote: > > Jordan, > > CVS is issuing an "out of memory" message on attempting to checkin a > 12MB file. What can I do? There is 300M of swap on the machine, it is > running FreeBSD 2.2.8, and CVS says: > "Concurrent Versions System (CVS) 1.9.26 (client/server)" > > I'll post this to the lists, too. > -- Anyone help? -- ------------------------------------------- Mark Jaffe | Build Meister Ricoh Silicon Valley | ADC (408) 863-8066 | mjaffe@rsv.ricoh.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 16 11:43: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from guardian.sftw.com (guardian.sftw.com [209.157.37.25]) by hub.freebsd.org (Postfix) with ESMTP id E4B4F158FE; Mon, 16 Aug 1999 11:43:04 -0700 (PDT) (envelope-from nsayer@sftw.com) Received: from sftw.com (yoda.sftw.com [209.157.37.177]) by guardian.sftw.com (8.9.3/8.9.3) with ESMTP id LAA75451; Mon, 16 Aug 1999 11:43:27 -0700 (PDT) (envelope-from nsayer@sftw.com) Message-ID: <37B85BCA.7DE71FF2@sftw.com> Date: Mon, 16 Aug 1999 11:43:23 -0700 From: Nick Sayer Reply-To: nsayer@freebsd.org X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > > Are you sure about this? Having constant p, g, x and y for every > telnet client and server surely makes it much easier to attack? In theory > you could probably pregenerate all of the arithmetic. Maybe we're not using the constant names the same way. In SRA the modulus and base are constants. I don't think that those being public helps an attacker too much. The client and server must agree on these values before you start an authentication, so at the very least a single failed authentication attempt would provide these values to an attacker anyway. And it's computationally too difficult to generate suitable values on the fly. Each side picks Xmine, each side passes Nmine=B^Xmine % m, each then computes K=B^(Nhis*Xmine) % m. That's straight DH, right? SRA then uses the common K to make a DES key to pass auth data from client to server. Simple. You can attack the protocol either by brute forcing DES, factoring the DH exchange, or with MiM. I regard each of these tasks as approximately equally difficult. I could hack SRA to use larger numbers, even pre generate them on the server, but that would break compatibility with existing SRA implementations (which do exist, believe it or not). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 11:49:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id D908214BCE for ; Mon, 16 Aug 1999 11:49:47 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id OAA00448 for ; Mon, 16 Aug 1999 14:49:39 -0400 (EDT) Date: Mon, 16 Aug 1999 14:36:22 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: kernel symbol `gd_curpcb' not found Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have tried to debug a kernel by simulating a panic without success. I have read the handbook and searched the mailinglist. I even tried not to strip the debug kernel at all. Still I get the above message and I do not know how to go on. The following are the commands that I used: now5# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. ...... This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file /kernel Reading symbols from /kernel...done. (kgdb) exec-file kernel.6 (kgdb) core-file vmcore.6 IdlePTD 3600384 kernel symbol `gd_curpcb' not found. (kgdb) where No stack. Thanks for any help. -------------------------------------------------- Zhihui Zhang. Please visit http://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 16 12:12: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 89DC515497 for ; Mon, 16 Aug 1999 12:12:01 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id NAA153453; Mon, 16 Aug 1999 13:11:55 -0600 (MDT) Date: Mon, 16 Aug 1999 13:11:55 -0600 From: "Ronald G. Minnich" To: Terry Lambert Cc: vev@michvhf.com, Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908161717.KAA16010@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > > For an interesting take on all this visit www.mipsabi.org > Uh, that site is dead, as of the end of this month. See the > first link ("announcement"). Precisely my point ... ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 12:44:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from loves.to.idle.za.org (loves.to.idle.za.org [209.212.100.194]) by hub.freebsd.org (Postfix) with ESMTP id 27B64153D1 for ; Mon, 16 Aug 1999 12:44:36 -0700 (PDT) (envelope-from lists@idle.za.org) Received: from loves.to.idle.za.org (lists@loves.to.idle.za.org [209.212.100.194]) by loves.to.idle.za.org (8.9.3/8.9.3) with ESMTP id VAA88602 for ; Mon, 16 Aug 1999 21:48:52 GMT (envelope-from lists@idle.za.org) Date: Mon, 16 Aug 1999 21:48:52 +0000 (GMT) From: FreeBSD mailing lists X-Sender: lists@loves.to.idle.za.org To: freebsd-hackers@freebsd.org Subject: Raw Packet code containing security bits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wonder if anyone here could perhaps of be assistance, Im currently playing with implementing certain things in trusted bsd to do with ip security classes and how the system responds to security bits, and implementing certain things the stack etc. However my first piece of test code playing with raw packets to test how things respond to packets with the security bit set, doesnt seem to want to work. This code compiles fine, however when I try and run it it says invalid argument when it tries to send the packet. If anyone could give me any insight as to why this code doesnt run properly, it would be much appreciated, and would certainly help me in my efforts to continue expanding trusted bsd. Ive included the code below.. Thanks Andrew --- Code starts here --- #include #include #include #include #include #include #include #include #include #include #include #include #define IPVERSION 4 /* Define the IP Version (always 4, until we go ipv6) */ #define DEFAULT_TTL 60 /* Define the default Time to Live as 60 */ #define DESTPORT 1700 struct pseudohdr { struct in_addr source_address; struct in_addr dest_address; u_char place_holder; u_char proto; u_short length; } pseudohdr; u_short in_chksum(u_short *addr, int len) { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return(answer); }; u_short trans_check(u_char proto, char *packet, int length, struct in_addr source_address, struct in_addr dest_address) { char *pseudo_packet; u_short answer; pseudohdr.proto = proto; pseudohdr.length = htons(length); pseudohdr.place_holder = 0; pseudohdr.source_address = source_address; pseudohdr.dest_address = dest_address; if((pseudo_packet = malloc(sizeof(struct pseudohdr) + length)) == NULL) { perror("malloc"); exit(-1); } memcpy(pseudo_packet, &pseudohdr, sizeof(pseudohdr)); memcpy((pseudo_packet + sizeof(pseudo_packet)), packet, length); answer = (u_short)in_chksum((u_short *)pseudo_packet, (length + sizeof(pseudohdr))); free(pseudo_packet); return answer; }; void ipgenerate(char *packet, u_char protocol, struct in_addr saddr, struct in_addr daddr, u_short length) { struct ip *iphead; iphead = (struct ip *)packet; memset((char *)iphead, '\0', sizeof(struct ip)); iphead->ip_hl = 5; /* Define the ip header length as 6, this is standard packet + security class option, counted in 32 bit words */ iphead->ip_v = IPVERSION; /* Set the ip version to 4 as its ipv4 not ipv6 */ iphead->ip_len = htons(length); /* Set the packet length in network byte order */ iphead->ip_id = htons(getpid()); /* Set the packet id to the process id */ iphead->ip_ttl = DEFAULT_TTL; /* Set the time to live to the default defined (60 seconds) */ iphead->ip_p = protocol; /* Set the protocol (tcp/udp/icmp) */ iphead->ip_src = saddr; /* Set the source address */ iphead->ip_dst = daddr; /* Set the destination address */ iphead->ip_sum = (u_short)in_chksum((u_short *)iphead, sizeof(struct ip)); /* Set the checksum */ printf("sizeof: %d\n",sizeof(struct ip)); }; void addsecure(char *packet) { char *pack; pack = (char *)packet+sizeof(struct ip); pack[0] = 0x82; /* We want a security option that is copied on all fragmentation */ pack[1] = 0xB; pack[2] = 0x6B; /* We class this packet as top secret */ pack[3] = 0xC5; pack[4] = 0; /* Packet is non compartmentalized */ pack[5] = 0; pack[6] = 0; /* More security crap from DIAM 65-19 */ pack[7] = 0; pack[8] = 0; /* Still more crap leave this 0 */ pack[9] = 0; pack[10] = 0; pack[11] = 0; /* Terminate the packet options */ /* Packet data now starts at (char *)packet+sizeof(struct ip)+12 */ }; void addudphead(char *packet, u_short sport, u_short dport, u_short length) { struct udphdr *udphead; udphead = (struct udphdr *)packet; udphead->uh_sport = 0; udphead->uh_dport = DESTPORT; udphead->uh_ulen = length; }; int main(int argc, char *argv[]) { char *packetdata; /* Data going into our UDP Packet */ struct in_addr saddr, daddr; /* Source and Destination address structs */ u_short sport, dport; /* Source and Destination ports */ struct sockaddr_in rawsocket; /* The socket we will be talking over */ int sockd, on = 1; /* Socket stuff */ struct udphdr *udpheader; /* UDP header used for generating checksums */ u_short datalength = strlen("Test UDP Packet") +5; u_short packetlength = sizeof(struct ip) + sizeof(struct udphdr) + 12 + datalength; u_char entirepacket[packetlength]; u_char *tempstr; if (argc < 5) { printf("\nRaw UDP packet + security bit transmitter\n(c) 1999 Andrew Alston\n"); printf("Usage: %s source_port source_address destination_port destination_address\n" ,argv[0]); exit(-1); }; if((packetdata = malloc(datalength)) == NULL) { perror("malloc"); exit(-1); }; /* Allocate some memory for the packet data */ memset(packetdata, '\0', datalength); /* Fill the string with 0's */ snprintf(packetdata, strlen("Test UDP Packet")+5, "Test UDP Packet\n"); memset(entirepacket, '\0', packetlength); /* 0 out the entire packet */ sport = (u_short)atoi(argv[1]); /* Source port from argument 1 */ saddr.s_addr = htonl(inet_addr(argv[2])); /* Source address from argument 2 */ dport = (u_short)atoi(argv[3]); /* Destination port from argument 3 */ daddr.s_addr = htonl(inet_addr(argv[4])); /* Destination address from argument 4 */ if((sockd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0 ) { perror("Socket"); exit(-1); }; /* Set up the socket and die on faliure */ if(setsockopt(sockd, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) < 0) { perror("setsockopt"); exit(-1); }; /* Request permission to include own ip header */ ipgenerate(entirepacket, IPPROTO_UDP, saddr, daddr, packetlength); addsecure(entirepacket); udpheader = (struct udphdr *)(entirepacket + sizeof(struct ip) + 12); addudphead((char *)udpheader, sport, dport, sizeof(struct udphdr) + datalength); udpheader->uh_sum = trans_check(IPPROTO_UDP, (char *)udpheader, (datalength + sizeof(struct udphdr)), saddr, daddr); tempstr = entirepacket + sizeof(struct ip) + sizeof(struct udphdr) + 12; strncpy(tempstr, packetdata, strlen(packetdata)); memset(&rawsocket, '\0', sizeof(struct sockaddr_in)); rawsocket.sin_family = AF_INET; rawsocket.sin_port = htons(dport); rawsocket.sin_addr = daddr; printf("Length of packet: %d\n",sizeof(entirepacket)); printf("Packetlength: %d\n", packetlength); if(sendto(sockd,&entirepacket,packetlength,0x0,(struct sockaddr *)&rawsocket, sizeof(rawsocket)) != packetlength) { perror("send to"); exit(-1); }; return(0); }; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 13:22:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 8A1A815554 for ; Mon, 16 Aug 1999 13:22:09 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA01752; Mon, 16 Aug 1999 13:22:12 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd001708; Mon Aug 16 13:22:06 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA02321; Mon, 16 Aug 1999 13:22:03 -0700 (MST) From: Terry Lambert Message-Id: <199908162022.NAA02321@usr09.primenet.com> Subject: Re: Filesystem question... To: rminnich@acl.lanl.gov (Ronald G. Minnich) Date: Mon, 16 Aug 1999 20:22:02 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Ronald G. Minnich" at Jul 26, 99 08:44:14 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, i'd expect far fewer problems for the private mounts than for > user mounts which modify the name space for all processes ... The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. This is actually the problem at issue in an SMBFS implementation, and for which the Linux guys punted: the credential in SMB is per connection, not per user. There is some newer stuff in LANMan to deal with this inter-NT, and SAMBA incorporates this, but session ID's are not supported over a single VC by all LANMan servers. NetWare has the same problem, FWIW, as does NUC (a client FS for NetWare). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 13:27:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id AFFBA14D1A; Mon, 16 Aug 1999 13:27:52 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA17516; Mon, 16 Aug 1999 13:25:18 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAA_OaW7H; Mon Aug 16 13:25:04 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA02573; Mon, 16 Aug 1999 13:25:00 -0700 (MST) From: Terry Lambert Message-Id: <199908162025.NAA02573@usr09.primenet.com> Subject: Re: Whither makefiles for src/crypto/telnet/* ? To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 16 Aug 1999 20:25:00 +0000 (GMT) Cc: sheldonh@uunet.co.za, walton@nordicrecords.com, nsayer@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908141800.UAA59060@yedi.iaf.nl> from "Wilko Bulte" at Aug 14, 99 08:00:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Cool, another non-exportable system available to US users only. :-) > > Yeah... isn't it time you Yanks got together and stormed that Trade Dept? > I mean, if you can get excited over a few wooden crates containing tea... > > ;-) ;-) Pound for pound (no pun intended), Tea was much more expensive than gold at the time. That's why all real antique tea cozy's have functional locks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 13:50:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id DF2F8156AB; Mon, 16 Aug 1999 13:49:57 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id NAA20782; Mon, 16 Aug 1999 13:48:16 -0700 (PDT) Date: Mon, 16 Aug 1999 13:48:16 -0700 (PDT) From: Bill Studenmund Reply-To: Bill Studenmund To: Terry Lambert Cc: Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908140150.SAA23891@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 14 Aug 1999, Terry Lambert wrote: > > I am currently conducting a thorough study of the VFS subsystem > > in preparation for an all-out effort to port SGI's XFS filesystem to > > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon > > has written in hackers- that the VFS subsystem is presently not > > well understood by any of the active kernel code contributers and > > that it will be rewritten later this year. This is obviously of great > > concern to me in this port. > > It is of great concern to me that a rewrite, apparently because of > non-understanding, is taking place at all. That concerns me too. Many aspects of the 4.4 vnode interface were there for specific reasons. Even if they were hack solutions, to re-write them because of a lack of understanding is dangerous as the new code will likely run into the same problems as before. :-) Also, it behooves all the *BSD's to not get too divergent. Sharing code between us all helps all. Given that I'm working on the kernel side of a data migration file system using NetBSD, I can assure you there are things which FreeBSD would get access to more easily the more-similar the two VFS interface are. :-) > I would suggest that anyone planning on this rewrite should talk, > in depth, with John Heidemann prior to engaging in such activity. > John is very approachable, and is a deep thinker. Any rewrite > that does not meet his original design goals for his stacking > architecture is, I think, a Very Bad Idea(tm). > > > > I greatly appreciate all assistance in answering the following > > questions: > > > > 1) What are the perceived problems with the current VFS? > > 2) What options are available to us as remedies? > > 3) To what extent will existing FS code require revision in order > > to be useful after the rewrite? > > 4) Will Chapters 6,7,8 & 9 of "The Design and Implementation of > > the 4.4BSD Operating System" still pertain after the rewrite? > > 5) How important are questions 3 & 4 in the design of the new > > VFS? > > > > I believe that the VFS is conceptually sound and that the existing > > semantics should be strictly retained in the new code. Any new > > functionality should be added in the form of entirely new kernel > > routines and system calls, or possibly by such means as > > converting the existing routines to the vararg format &etc. > > Here some of the problems I'm aware of, and my suggested remedies: > > 1. The interface is not reflexive, with regard to cn_pnbuf. > > Specifically, path buffers are allocated by the caller, but > not freed by the caller, and various routines in each FS > implementation are expected to deal with this. > > Each FS duplicates code, and such duplication is subject > to error. Not to mention that it makes your kernel fat. Yep, that's not good. > 2. Advisory locks are hung off private backing objects. > > Advisory locks are passed into VOP_ADVLOCK in each FS > instance, and then each FS applies this by hanging the > locks off a list on a private backing object. For FFS, > this is the in core inode. > > A more correct approach would be to hang the lock off the > vnode. This effectively obviates the need for having a > VOP_ADVLOCK at all, except for the NFS client FS, which > will need to propagate lock requests across the net. The > most efficient mechanism for this would be to institute > a pass/fail response for VOP_ADVLOCK calls, with a default > of "pass", and an actual implementation of the operand only > in the NFS client FS. I agree that it's better for all fs's to share this functionality as much as possible. I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an efficiency concern. If we actually make a VOP call, that should be the end of the story. I.e either add a vnode flag to indicate pas/fail-ness, or add a genfs/std call to handle the problem. I'd actually vote for the latter. Hang the byte-range locking off of the vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on OS flavor) to handle the call. That way all fs's that can share code, and the callers need only call VO_ADVLOCK() - no other logic. NetBSD actually needs this to get unionfs to work. Do you want to talk privately about it? > Again, each FS must duplicate the advisory locking code, > at present, and such duplication is subject to error. Agreed. > 3. Object locks are implemented locally in many FS's. > > The VOP_LOCK interface is implemented via vop_stdlock() > calls in many FS's. This is done using the "vfs_default" > mechanism. In other FS's, it's implemented locally. > > The intent of the VOP_LOCK mechanism being implemented > as a VOP at all was to allow it to be proxied to another > machine over a network, using the original Heidemann > design. This is also the reason for the use of descriptors > for all VOP arguments, since they can be opaquely proxied to > another machine via a general mechanism. Unlike NFS based > network filesystems, this would allow you to add VOP's to > both machines, without having to teach the transport about > the new VOP for it to be usable remotely. Just for a point of comparison, I recently got almost all the NetBSD fs's to use common code. After our -Lite2 merge, all fs's were either calling the lock manager, or using genfs_nolock() (a version for non-locking fs's). Now there's a struct lock * and struct lock in struct vnode. The fs exports its locking behavior via the struct lock *. For most fs's, the struct lock * points to the struct lock, and genfs_lock() feeds that to the lock manager. But we've kept the ability to do something different (like call over the network) alive. If the struct lock * is NULL, you have to call VOP_LOCK on that fs. Note that this difference only matters for layered fs's - everything else should be calling VOP_LOCK() and letting the dispatch code figure out the right thing to do. > Like the VOP_ADVLOCK, the need for VOP_LOCK is for proxy > purposes, and it, too, should generate a pass/fail response, > and be largely implemented in non-filesystem specific > higher level code. To an extent, that's that the exported struct lock * does, though the only clients are layered filesystems. Everyone else calls VOP_LOCK. :-) > Again, each FS which duplicates code for this function is > subject to duplication errors. Agreed. > 4. The VOP_READIR interface is irrational. > > The VOP_READDIR interface returns its responses in "host > cannonical format" (struct dirent, in sys/dirent.h). > Internally, FFS operates on "directory entry blocks" that > contain exactly these structures (an intentaional coincidence). > > The problem with this approach, is that it makes the getdents > system call sensitive to file systems for which some of the > information returned (e.g. d_fileno, d_reclen, d_type, d_namlen) > are synthetic. What this means is that a native file system > directory implementation single directory block must be able > to fit into the buffer passed to the getdirentries(2) system > call, or a directory listing is not a valid snapshot of the > current state of the directory. > > It also vastly complicates directory traversal restarts (hence > the ncookies and a_cookies arguments, since the NFS server > requires the ability to restart traversal, mid-block, since > the NFSv2 protocol returns directory entries one at a time). > > The "cookie" idea must be carried out faithfully, in an FS > specific fashion, for each FS which is allowed to be NFS > exported. This code duplication is subject to error, or > worse, non-implementation due to its complexity. > > A more rational approach would be to split the operation > into two seperate VOP's: one to acquire a snapshot of a set > of FS specific directory entries of an arbitrary size, and > the second to extract rentries into the user's buffer, in > cannonical format. Sounds interesting... > 5. The idea of "root" vs. "non-root" mounts is inherently bad. > > Right now, there are several operations, all wrapped into > a single "mount" entry point. This is actually a partial > transition to a more cannonically correct implemetnation. > > The reason for the "root" vs. "non-root" knowledge in the > code has to do with several logical operations: > > 1) "Mounting" the filesystem; that is, getting the > vnode for the device to be mounted, and doing any > FS specific operations necessary to cause the > correct in-core context to be established. > > 2) Covering the vnode at the mount point. > > This operation updates the vnode of the mount > point so that traversals of the mount point will > get you the root directory of the FS that was > mounted instead of the directory that is covered > by the mount. > > 3) Saving the "last mounted on" information. > > This is a clerical detail. Read-only FS's, and > some read-write FS's, do not implement this. It > is mostly a nicety for tools that manipulate FFS > directly. > > 4) Initialize the FS stat information. > > Part of the in-core data for any FS is the mnt_stat > data, which is what comes back from a VFS_STATFS() > call You forgot: 5) Update export lists If you call the mount routine with no device name (args.fspec == 0) and with MNT_UPDATE, you get routed to the vfs_export routine > The first operation is invariant. It must be done for all > FS's, whether they are "root" or "non-root". > > The second operation is specific to "non-root" FS's. It > could be moved to common, higher level code -- specifically, > it could be moved into the mount system call. I thought it was? Admitedly the only reference code I have is the ntfs code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it is, I thought it'd be an ok reference. > The third operation is also specific to "non-root" FS's. It > could be discarded, or it could be moved to a seperate VFS > operation, e.g. VFS_SETMNTINFO(). I would recommend moving > it to a seperate VFSOP, instead of discarding it. The reason > for this is that an intelligent person could reasonably decide > to add the setting of this data in newfs and tunefs, and do > away with /etc/fstab. > > The fourth operation is invariant. It must be done for all > FS's, whether they are "root" or "non-root". For comparison, NetBSD has a mount entry point, and a mountroot entry point. But all the other ick is there too. > We can now see that we have two discrete operations: > > 1) Placement of any FS, regardless of how it is intended > to be used, into the list of mounted filesystems. > > 2) Mapping a filesystem from the list of mounted FS's > into the directory hierarchy. 3) Updating export information. > The job of the per FS mount code should be to take a mount > structure, the vnode of a device, the FS specific arguments, > the mount point credentials, and the process requesting the > mount, and _only_ do #1 and #4. > > The conversion of the root device into a vnode pointer, or > a path to a device into a vnode pointer, is the job of upper > level code -- specifically, the mount system call, and the > common code for booting. My one concern about this is you've assumed that the user is mounting a device onto a filesystem. Layered filesystems won't do that. nullfs, umaptfs, and unionfs will want a directory. The hierarchical storage system I'm working on will want a file. kernfs, procfs, and an fs which I haven't checked into the NetBSD tree don't really need the extra parameter. Supporting all these different cases would be a hassle for upstream code. > This removes a large amount of complex code from each of > the file systems, and centralizes the maintenance task into > one set of code that either works for everyone, or no one > (removing the duplication of code/introduction of errors > issue). Might I suggest a common library of routines which different mount routines can call? That way we'd get code sharing while letting the fs make decisions about what it expects of the input arguments. I've been looking forward to ripping the export updating out of the mount call. It'd be nice if we could rototill both FreeBSD & NetBSD's mount interfaces the same way at the same time. :-) > In addition, the lack of "root" specific code in many FS's > VFS_MOUNT entry points is the reason that they can not be > mounted as "/". This change would open it up, such that any > FS that was supported by the kernel could be used as the > root filesystem. > > 6. The "vfs_default" code damages stacking > > The intent of the stacking architecture was to have the > default operation for any VOP unknown to an FS fall through > to the lower level code, and fail if it was not implemented. > > The use of the "vfs_default" to make unimplemented VOP's > fall through to code which implements function, while well > intentioned, is misguided. > > Consider the case of a VOP proxy that proxies requests. These > might be requests to another machine, as in the previous > proxy example, or they might be requests to user space, to > allow for easy developement of new filesystem layers. > > In addition, in order to get a default operation to actually > fail, you have to intentionally create a failing VOP for that > particular FS. > > Finally, the paradigm can not support new VOP's without a > kernel recompilation. This means that in order to add to > the list of VOP's known to the system when you add a new FS, > you don't merely have to reallocate the in-core copy of the > vnodeop_desc to include a new (failing) member, you have to > create a default behaviour for it, and modify the default > operations table. In other words, it's not extensible, as > it was architected to be. This problem is FreeBSD-specific. Your analysis seems sound. > 7. The struct nameidata (namei.h) is broken in conception. > > One issue that recurrs frequently, and remains unaddressed, > is the issue of namespace abstraction. > > This issue is nowhere more apparent than in the VFAT and NTFS > filesystems, where there are two namespaces: one 8.3, and the > second, 16 bit Unicode. > > The problem is one of coherency, and one of reference, and > is not easily resolved in the context of the current nameidata > structure. Both NTFS and the VFAT FS try to cover this issue, > both with varing degress of success. > > The problem is that there is no cannonical format that the > kernel can use to communicate namespace data to FS's. Unlike > VOP_READDIR, which has the abstract (though ill-implemented) > struct dirent, there is no abstract representation of the > data in a pathname buffer, which would allow you to treat > path components as opaque entities. > > One potential remedy for this situation would be to cannonize > any path into an ordered list of components. Ideally, this > would be done in 16 bit Unicode (looking toward the future), > but would minimally be seperate components with length counts > to allow faster rejection of non-matching components, and > frequent recalculation of length. NetBSD's name cache is a bit different from FreeBSD's, and might win here. We have just VOP_LOOKUP, which calls the cache lookup routine, rather than both a VOP_LOOKUP and a VOP_CACHEDLOOKUP. Jaromir Dolecek has been discussing adding a canonicalized component name to the cache entries. That way the VOP_LOOKUP routine gets called, canonicalizes the name as it sees fit (say making it all upper case) if it chooses to, and hands off to the cache lookup routine. The advantage is that each fs can chose its on canonicalization, if it wants to. For instance, ffs won't do anything (it's case sensetive), while other case-insensitive fs's will do different things. > 8. The filesystems have knowledge of the name cache. > > Entries into the name cache, and deletion of entries from > the name cache, should be handled in FS independent code > at a higher level. This can avoid expensive VFS_LOOKUP calls > in many cases, and save marshalling arguments into and out of > the descriptor structure, in addition to drastically reducing > the function call overhead. > > Someone recently profiling FreeBSD's FS to detemine speed > bottleneck (I believe it was Mike Smith, attempting to > optimize for a ZD Labs benchmark) found that FreeBSD spends > much of its time in namei(). I'm interested in what you suggest, because I'd expect all *BSD's could use a more efficient namei. But I'm concerned that pushing too much into upper-level routines would remove the fs's ability to make policy decisions. > 9. The implementation of namei() is POSIX non-compliant > > The implementation of namei() is by means of coroutine > "recursion"; this is similar to the only recursion you can > achieve in FORTRAN. > > The upshot of this is that the use of the "//" namespace > escape allowed by POSIX can not be usefully implemented. > This is because it is not possible to inherit a namespace > escape deeper than a single path component for a stack of > more than one layer in depth. > > This needs to be fixed, both for "natural" SMBFS support, > and for other uses of the namespace escape (HTTP "tunnels", > extended attribute and/or resource fork access in an OS/2 > HPFS or Macintosh HFS implementation, etc.), including > forward looking research. > > This is related to item 7. I'm sorry. This point didn't parse. Could you give an example? I don't see how the namei recursion method prevents catching // as a namespace escape. > 10. Stacking is broken > > This is really an issue of not having a coherency protocol > which can be applied between stacks of files. It is somewhat > related to almost all of the above issues. > > The current thinking which has been forwarded by Matt and > John is that a vnode should have an associated vm_object_t, > and that coherency should be maintained that way. > > This thinking is flawed for a number of reasons: > > a. The main utility of this would be for an MFS > implementation. While a "fast MFS" is a > laudable goal, it isn't sufficient to drive this. > > b. A coherency protocol is required in any case, > since a proxied VOP is not necessarily on the > same machine or in the same VM space. This > approach would disallow the possibility of a > user space filesystem developement framework. > > c. There already exist aliases (VM implementation > errors); intentionally adding aliases as an > implementation detail will futher obfuscate them. > Minimally, the VM system should pass a full > branch path analysis based test procedure before > they are introduced. Even then, I would argue > that it would open up a large complexity space > that would prevent us from ever being sure about > problem resoloution again. > > d. Filesystems which need to transform data can > never operate correctly, since they need to > make local copies of the transformed content. > This includes cryptographic, character set > translation, compression, and similar stacking > layers. > > Instead, I think the interface design issues (VOP_ADVLOCK, > VOP_GETPAGES, VOP_PUTPAGES, VOP_READ, VOP_WRITE, et. al.) > that drive the desire to implement coherency in this > fashion be examined. I believe that an ideal soloution > would be to never have the pages replicated at more than a > single vnode. This would likewise solve the coherency > problem, without the additional complexity. The issue > would devolve into locating the real backing object, and > potentially, translating extents. As NetBSD's UBC work is moving in a similar direction, and I'm interested in working on a compressing fs, I'm interested in the solution you propose. > 11. The function call "footprint" of filesystems is too large > > Attempt the following: > > Compile up all of the files which make up an > individual filesystem. You can take all of > the files for the ufs/ffs objects and the > vnode_if.o from a compiled kernel for this > exercise. > > Now link them. Ignore the missing "main"; how > many undefined functions are there? > > The problem you are seeing is the incursion of the VM > system, and sloppy programming practices, into each VFS > implementation. > > This footprint impacts filesystem portability, and is > one reason, among many (including some of the above) that > VFS modules are no longer very portable between BSD > flavors. > > Minimally, the VFS incursions need to be macrotized, and > not assume a unified VM and buffer cache (or a non-unified > VM and buffer cache, as well, for that matter). This would > improve portability considerably. Sounds good. :-) > In addition to this change, a function minimzation effort > should take place. > > If the underlying interface utilized by VFS layers was not > the kernel (for local media FS's, like FFS or NTFS), but > instead a variable granularity block store with a numeric > namespace, then the "top" and "bottom" interfaces could be > identical. For now, however, some work can be done (and > should be done) to reduce the function call footprint. > This is important work, which can only aid developement > of future work (such as a user space filesystem framework > for use by developers and researchers). > > I hesitate to suggest this, but it might be reasonable to > consider a struct containing externally referenced functions, > which is registered into the FS via mount, and which is > identical for all FS's. This would, likewise, promote the > idea of a user space framework. > > Ideally, work would be done to port the Heidemann framework > to Linux, so that their developers could be leveraged. > > > > Some FFS-specific problems are: > > 1. The directory code in the UFS layer is intertwined with the > filespace code > > Ideally, one would be able to mount a filesystem as a flat > numeric namespace (see #7, above), and then mount the idea > of directory management over top of that. > > 2. The quota subsystem is too tightly integrated > > Quotas should be an abstract stacking layer that can be > applied to any FS, instead of an FFS specific monstrosity. It should certainly be possible to add a quota layer on top of any leaf fs. That way you could de-couple quotas. :-) > The current quota system is also limited to 16 bits for a > number of values which, in FreeBSD, can be greater than > 16 bits (e.g. UID's). > > The current quota system is also broken for Y2038. > > 3. The filesystem itself is broken for Y2038 > > The space which was historically reserved for the Y2038 fix > (a 64 bit time_t) was absconeded with for subsecond resoloution. > > This change should be reverted, and fsck modified to re-zero > the values, given a specific argument. > > The subsecond resoloution doesn't really matter, but if it is > seen as an issue which needs to be addressed, the only value > which could reasonably require this is the modification time, > and there is sufficient free space in the inode to be able > to provide for this (there are 2x32 bit spares). I think all the *BSD's need to do the same thing here. :-) One other suggestion I've heard is to split the 64 bits we have for time into 44 bits for seconds, and 20 bits for microseconds. That's more than enough modification resolution, and also pushes things to past year 500,000 AD. Versioning the indoe would cover this easily. > I have other suggestions, but the above covers the most obvious > damage. Well taken. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 14: 6: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id A19BF1551D for ; Mon, 16 Aug 1999 14:05:58 -0700 (PDT) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id RAA20638 for freebsd-hackers@freebsd.org; Mon, 16 Aug 1999 17:06:05 -0400 (EDT) Date: Mon, 16 Aug 1999 17:06:05 -0400 From: Christian Kuhtz To: freebsd-hackers@freebsd.org Subject: Re: Filesystem question... Message-ID: <19990816170605.F18416@ns1.adsu.bellsouth.com> References: <199908162022.NAA02321@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199908162022.NAA02321@usr09.primenet.com>; from Terry Lambert on Mon, Aug 16, 1999 at 08:22:02PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 16, 1999 at 08:22:02PM +0000, Terry Lambert wrote: > This is actually the problem at issue in an SMBFS implementation, > and for which the Linux guys punted: the credential in SMB is > per connection, not per user. Per connection creds suck performance wise (=I haven't seen an implementation which didn't). But, oh well.. > There is some newer stuff in LANMan to deal with this inter-NT, > and SAMBA incorporates this, but session ID's are not supported > over a single VC by all LANMan servers. > > NetWare has the same problem, FWIW, as does NUC (a client FS for > NetWare). At the risk of being flamed to death, you could use krb5 for that purpose.. Perhaps time to revive AFS? Seems that some of the issues here were solved in Transarc's/IBM's AFS that I used a while back (ok, it was a pain to run sometimes, but there's nothing per se that says you couldn't unbreak those things -- it's an implementation and availability of tools issue more than anything). Cheerios, Chris -- Christian Kuhtz, Sr. Network Architect BellSouth Corporation -wk, -hm Advanced Data Services "Affiliation given for identification, not representation." Atlanta, GA, U.S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 14:18:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id E270A14BD5; Mon, 16 Aug 1999 14:18:29 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA24762; Mon, 16 Aug 1999 14:18:56 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd024727; Mon Aug 16 14:18:47 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA04940; Mon, 16 Aug 1999 14:18:45 -0700 (MST) From: Terry Lambert Message-Id: <199908162118.OAA04940@usr09.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov Date: Mon, 16 Aug 1999 21:18:45 +0000 (GMT) Cc: tlambert@primenet.com, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: from "Bill Studenmund" at Aug 16, 99 01:48:16 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 2. Advisory locks are hung off private backing objects. > > > > Advisory locks are passed into VOP_ADVLOCK in each FS > > instance, and then each FS applies this by hanging the > > locks off a list on a private backing object. For FFS, > > this is the in core inode. > > > > A more correct approach would be to hang the lock off the > > vnode. This effectively obviates the need for having a > > VOP_ADVLOCK at all, except for the NFS client FS, which > > will need to propagate lock requests across the net. The > > most efficient mechanism for this would be to institute > > a pass/fail response for VOP_ADVLOCK calls, with a default > > of "pass", and an actual implementation of the operand only > > in the NFS client FS. > > I agree that it's better for all fs's to share this functionality as much > as possible. > > I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an > efficiency concern. If we actually make a VOP call, that should be the > end of the story. I.e either add a vnode flag to indicate pas/fail-ness, > or add a genfs/std call to handle the problem. > > I'd actually vote for the latter. Hang the byte-range locking off of the > vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on > OS flavor) to handle the call. That way all fs's that can share code, and > the callers need only call VO_ADVLOCK() - no other logic. OK. Here's the problem with that: NFS client locks in a stacked FS on top the the NFS client FS. Specifically, you need to seperate the idea of asserting a lock against the local vnode, asserting the lock via NFS locking, and coelescing the local lock list, after both have succeeded, or reverting the local assertion, should the remote assertion fail. This is particularly important for transformative layers, specifically cryptographic or compressing layers. A similar issue exists for character sets, e.g. a Unicode enabled OS NFS mounting via NFS an ISO 8859-1 filesystem, and having to do the directory (de)bloat on the fly. > NetBSD actually needs this to get unionfs to work. Do you want to talk > privately about it? If you want. FreeBSD needs it for unionfs and nullfs, so it's something that would be worth airing. I think you could say that no locking routine was an approval of the uuper level lock. This lets you bail on all FS's except NFS, where you have to deal with the approve/reject from the remote host. The problem with this on FreeBSD is the VFS_default stuff, which puts a non-NULL interface on all FS's for all VOP's. > > 3. Object locks are implemented locally in many FS's. > > > > The VOP_LOCK interface is implemented via vop_stdlock() > > calls in many FS's. This is done using the "vfs_default" > > mechanism. In other FS's, it's implemented locally. > > > > The intent of the VOP_LOCK mechanism being implemented > > as a VOP at all was to allow it to be proxied to another > > machine over a network, using the original Heidemann > > design. This is also the reason for the use of descriptors > > for all VOP arguments, since they can be opaquely proxied to > > another machine via a general mechanism. Unlike NFS based > > network filesystems, this would allow you to add VOP's to > > both machines, without having to teach the transport about > > the new VOP for it to be usable remotely. > > Just for a point of comparison, I recently got almost all the NetBSD fs's > to use common code. After our -Lite2 merge, all fs's were either calling > the lock manager, or using genfs_nolock() (a version for non-locking > fs's). Now there's a struct lock * and struct lock in struct vnode. The fs > exports its locking behavior via the struct lock *. For most fs's, the > struct lock * points to the struct lock, and genfs_lock() feeds that to > the lock manager. > > But we've kept the ability to do something different (like call over the > network) alive. If the struct lock * is NULL, you have to call VOP_LOCK on > that fs. Note that this difference only matters for layered fs's - > everything else should be calling VOP_LOCK() and letting the dispatch code > figure out the right thing to do. Yes, this NULL is the same NULL I suggested for advisory locks, above. FreeBSD has moved to more common code, but it's all call-down based because of the vfs_default stuff again. > > 5. The idea of "root" vs. "non-root" mounts is inherently bad. > > > > Right now, there are several operations, all wrapped into > > a single "mount" entry point. This is actually a partial > > transition to a more cannonically correct implemetnation. > > > > The reason for the "root" vs. "non-root" knowledge in the > > code has to do with several logical operations: > > > > 1) "Mounting" the filesystem; that is, getting the > > vnode for the device to be mounted, and doing any > > FS specific operations necessary to cause the > > correct in-core context to be established. > > > > 2) Covering the vnode at the mount point. > > > > This operation updates the vnode of the mount > > point so that traversals of the mount point will > > get you the root directory of the FS that was > > mounted instead of the directory that is covered > > by the mount. > > > > 3) Saving the "last mounted on" information. > > > > This is a clerical detail. Read-only FS's, and > > some read-write FS's, do not implement this. It > > is mostly a nicety for tools that manipulate FFS > > directly. > > > > 4) Initialize the FS stat information. > > > > Part of the in-core data for any FS is the mnt_stat > > data, which is what comes back from a VFS_STATFS() > > call > > You forgot: > > 5) Update export lists > > If you call the mount routine with no device name > (args.fspec == 0) and with MNT_UPDATE, you get > routed to the vfs_export routine This must be the job of the upper level code, so that there is a single control point for export information, instead of spreading it throughout ead FS's mount entry point. > > The first operation is invariant. It must be done for all > > FS's, whether they are "root" or "non-root". > > > > The second operation is specific to "non-root" FS's. It > > could be moved to common, higher level code -- specifically, > > it could be moved into the mount system call. > > I thought it was? Admitedly the only reference code I have is the ntfs > code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it > is, I thought it'd be an ok reference. No. Basically, what you would have is the equivalent of a variable length "mounted volume" table, from which mappings (and exports, based on the mappings) are externalized into the namespace. > > The third operation is also specific to "non-root" FS's. It > > could be discarded, or it could be moved to a seperate VFS > > operation, e.g. VFS_SETMNTINFO(). I would recommend moving > > it to a seperate VFSOP, instead of discarding it. The reason > > for this is that an intelligent person could reasonably decide > > to add the setting of this data in newfs and tunefs, and do > > away with /etc/fstab. > > > > The fourth operation is invariant. It must be done for all > > FS's, whether they are "root" or "non-root". > > For comparison, NetBSD has a mount entry point, and a mountroot entry > point. But all the other ick is there too. Right. It should just have a "mount" entry point, and the rest of the stuff moves to higher level code, called by the mount system call, and the mountroot stuff during boot, to externalize the root volume at the top of the hierarchy. An ideal world would mount a / that had a /dev under it, and then do transparent mounts over top of that. > > We can now see that we have two discrete operations: > > > > 1) Placement of any FS, regardless of how it is intended > > to be used, into the list of mounted filesystems. > > > > 2) Mapping a filesystem from the list of mounted FS's > > into the directory hierarchy. > > 3) Updating export information. Built into the higher level code, same place as #2. > > The job of the per FS mount code should be to take a mount > > structure, the vnode of a device, the FS specific arguments, > > the mount point credentials, and the process requesting the > > mount, and _only_ do #1 and #4. > > > > The conversion of the root device into a vnode pointer, or > > a path to a device into a vnode pointer, is the job of upper > > level code -- specifically, the mount system call, and the > > common code for booting. > > My one concern about this is you've assumed that the user is mounting a > device onto a filesystem. No. Vnoide, not bdevvp. The bdevvp stuff is for the boot time stuff in the upper level code, and only applies to the root volume. > Layered filesystems won't do that. nullfs, > umaptfs, and unionfs will want a directory. The hierarchical storage > system I'm working on will want a file. kernfs, procfs, and an fs which I > haven't checked into the NetBSD tree don't really need the extra > parameter. Supporting all these different cases would be a hassle for > upstream code. > > > This removes a large amount of complex code from each of > > the file systems, and centralizes the maintenance task into > > one set of code that either works for everyone, or no one > > (removing the duplication of code/introduction of errors > > issue). > > Might I suggest a common library of routines which different mount > routines can call? That way we'd get code sharing while letting the fs > make decisions about what it expects of the input arguments. This is the "footprint" problem, all over again. Reject/accept (or "accept if no VOP") seems more elegant, and also reduces footprint. > I've been looking forward to ripping the export updating out of the mount > call. It'd be nice if we could rototill both FreeBSD & NetBSD's mount > interfaces the same way at the same time. :-) 8-). > > 7. The struct nameidata (namei.h) is broken in conception. > > > > One issue that recurrs frequently, and remains unaddressed, > > is the issue of namespace abstraction. > > > > This issue is nowhere more apparent than in the VFAT and NTFS > > filesystems, where there are two namespaces: one 8.3, and the > > second, 16 bit Unicode. > > > > The problem is one of coherency, and one of reference, and > > is not easily resolved in the context of the current nameidata > > structure. Both NTFS and the VFAT FS try to cover this issue, > > both with varing degress of success. > > > > The problem is that there is no cannonical format that the > > kernel can use to communicate namespace data to FS's. Unlike > > VOP_READDIR, which has the abstract (though ill-implemented) > > struct dirent, there is no abstract representation of the > > data in a pathname buffer, which would allow you to treat > > path components as opaque entities. > > > > One potential remedy for this situation would be to cannonize > > any path into an ordered list of components. Ideally, this > > would be done in 16 bit Unicode (looking toward the future), > > but would minimally be seperate components with length counts > > to allow faster rejection of non-matching components, and > > frequent recalculation of length. > > NetBSD's name cache is a bit different from FreeBSD's, and might win here. > We have just VOP_LOOKUP, which calls the cache lookup routine, rather than > both a VOP_LOOKUP and a VOP_CACHEDLOOKUP. > > Jaromir Dolecek has been discussing adding a canonicalized component name > to the cache entries. That way the VOP_LOOKUP routine gets called, > canonicalizes the name as it sees fit (say making it all upper case) if > it chooses to, and hands off to the cache lookup routine. The advantage is > that each fs can chose its on canonicalization, if it wants to. For > instance, ffs won't do anything (it's case sensetive), while other > case-insensitive fs's will do different things. Can you push a Unicode name down from an appropriate system call? I don't see any way to deal with an NT FS for characters outside ISO 8859-1, otherwise. 8-(. > > 9. The implementation of namei() is POSIX non-compliant > > > > The implementation of namei() is by means of coroutine > > "recursion"; this is similar to the only recursion you can > > achieve in FORTRAN. > > > > The upshot of this is that the use of the "//" namespace > > escape allowed by POSIX can not be usefully implemented. > > This is because it is not possible to inherit a namespace > > escape deeper than a single path component for a stack of > > more than one layer in depth. > > > > This needs to be fixed, both for "natural" SMBFS support, > > and for other uses of the namespace escape (HTTP "tunnels", > > extended attribute and/or resource fork access in an OS/2 > > HPFS or Macintosh HFS implementation, etc.), including > > forward looking research. > > > > This is related to item 7. > > I'm sorry. This point didn't parse. Could you give an example? > > I don't see how the namei recursion method prevents catching // as a > namespace escape. //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork You can't inherit the fact that you are looking at the resource fork in the terminal component, ONLY. > > Instead, I think the interface design issues (VOP_ADVLOCK, > > VOP_GETPAGES, VOP_PUTPAGES, VOP_READ, VOP_WRITE, et. al.) > > that drive the desire to implement coherency in this > > fashion be examined. I believe that an ideal soloution > > would be to never have the pages replicated at more than a > > single vnode. This would likewise solve the coherency > > problem, without the additional complexity. The issue > > would devolve into locating the real backing object, and > > potentially, translating extents. > > As NetBSD's UBC work is moving in a similar direction, and I'm interested > in working on a compressing fs, I'm interested in the solution you > propose. Matt Dillion is apparently the person doing the work here. It seems I am out of date on the current thinking, as the vm_object_t apprach has apparently been discarded. > > 2. The quota subsystem is too tightly integrated > > > > Quotas should be an abstract stacking layer that can be > > applied to any FS, instead of an FFS specific monstrosity. > > It should certainly be possible to add a quota layer on top of any leaf > fs. That way you could de-couple quotas. :-) Yes, assuming stacking works in the first place... > > 3. The filesystem itself is broken for Y2038 > > > > The space which was historically reserved for the Y2038 fix > > (a 64 bit time_t) was absconeded with for subsecond resoloution. > > > > This change should be reverted, and fsck modified to re-zero > > the values, given a specific argument. > > > > The subsecond resoloution doesn't really matter, but if it is > > seen as an issue which needs to be addressed, the only value > > which could reasonably require this is the modification time, > > and there is sufficient free space in the inode to be able > > to provide for this (there are 2x32 bit spares). > > I think all the *BSD's need to do the same thing here. :-) > > One other suggestion I've heard is to split the 64 bits we have for time > into 44 bits for seconds, and 20 bits for microseconds. That's more than > enough modification resolution, and also pushes things to past year > 500,000 AD. Versioning the indoe would cover this easily. Ugh. But possible... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 15:12:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 4244814C13 for ; Mon, 16 Aug 1999 15:12:21 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id QAA161893 for ; Mon, 16 Aug 1999 16:12:20 -0600 (MDT) Date: Mon, 16 Aug 1999 16:12:19 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem question... In-Reply-To: <199908162022.NAA02321@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > The concept of private namespaces does not exist on FreeBSD. > It would require a modification of the lookup mechanism, and, > potentially, a seperation of credentials from the process into > a session manager. Yeah but you can fake it pretty well without such mods. I've done it once already on linux and the same techniques I used would work on freebsd. But I can't get anyone interested :-( ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 15:24:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 2FDD915656 for ; Mon, 16 Aug 1999 15:23:56 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id PAA01176; Mon, 16 Aug 1999 15:18:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908162218.PAA01176@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Ronald G. Minnich" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem question... In-reply-to: Your message of "Mon, 16 Aug 1999 16:12:19 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 15:18:53 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On Mon, 16 Aug 1999, Terry Lambert wrote: > > The concept of private namespaces does not exist on FreeBSD. > > It would require a modification of the lookup mechanism, and, > > potentially, a seperation of credentials from the process into > > a session manager. > > Yeah but you can fake it pretty well without such mods. I've done it once > already on linux and the same techniques I used would work on freebsd. > > But I can't get anyone interested :-( Uh, we're all interested; where's the code? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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 16 15:26:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id EE10514CAC for ; Mon, 16 Aug 1999 15:26:22 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id QAA140683 for ; Mon, 16 Aug 1999 16:26:09 -0600 (MDT) Date: Mon, 16 Aug 1999 16:26:09 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem question... In-Reply-To: <199908162218.PAA01176@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Mike Smith wrote: > > But I can't get anyone interested :-( > Uh, we're all interested; where's the code? v9fs is the first piece. The servers are done. But I'm mostly out of the freebsd hacking business at this point (except for maybe via drivers) so I need some help to get the rest of it plugged into freebsd. I'm no longer supported to do this kind of thing. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 15:38:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 826E914C13 for ; Mon, 16 Aug 1999 15:38:47 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 1F6931912; Tue, 17 Aug 1999 00:38:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 1EADF49D4 for ; Tue, 17 Aug 1999 00:38:57 +0200 (CEST) Date: Tue, 17 Aug 1999 00:38:52 +0200 (CEST) From: Andrzej Bialecki To: freebsd-hackers@freebsd.org Subject: Saving system image to disk (NOT on a laptop) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, To all you low-level kernel and bootloader hackers: what would it take to save and restore a running system image (presumably from dedicated raw partition) so that the system would continue where it left before reboot? It doesn't sound that difficult to me - after all, laptops somehow do it - but I know too little low-level stuff to try implementing it myself... Any comments? Some code? ;-) Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 15:53:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id F1C7215902 for ; Mon, 16 Aug 1999 15:53:34 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id PAA01394; Mon, 16 Aug 1999 15:47:45 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908162247.PAA01394@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrzej Bialecki Cc: freebsd-hackers@freebsd.org Subject: Re: Saving system image to disk (NOT on a laptop) In-reply-to: Your message of "Tue, 17 Aug 1999 00:38:52 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 15:47:45 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > To all you low-level kernel and bootloader hackers: what would it take to > save and restore a running system image (presumably from dedicated raw > partition) so that the system would continue where it left before reboot? > > It doesn't sound that difficult to me - after all, laptops somehow do it - > but I know too little low-level stuff to try implementing it myself... It's quite difficult, in that it requires intimate low-level knowledge of the hardware in order to save/restore its state correctly. In the case of laptops it's much easier because the hardware can't be changed under the image, and the BIOS knows all about the hardware. To do it "right" in the generic case, you'd virtually have to go through the entire boot process again. It might make more sense to try an alternative arrangement whereby you paged _everything_ out to swap, then saved the entire kernel data and bss segments somewhere. You'd have fun at the restore's cutover point though, and any stateful hardware would still be a bitch to deal with. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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 16 15:54:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 4B1FA15616 for ; Mon, 16 Aug 1999 15:54:28 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id AAA68174 for ; Tue, 17 Aug 1999 00:54:45 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Tue, 17 Aug 1999 00:54:45 +0200 (CEST) From: Leif Neland To: freebsd-hackers@freebsd.org Subject: vnc on nat-proxy/firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I need to remote-control an NT behind a unix-box running nat-proxy/firewall/gateway. Would it be possible first to connect from the outside to a vnc-server on gateway, then to run vnc-client on the gateway to connect to a vnc-server on the nt? Or is it possible to have a vnc-proxy on the gateway to redirect to the nt? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 16: 1:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 5302015560 for ; Mon, 16 Aug 1999 16:00:52 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id SAA25341; Mon, 16 Aug 1999 18:58:12 -0400 (EDT) Date: Mon, 16 Aug 1999 18:58:11 -0400 (EDT) From: Bosko Milekic To: lists@idle.za.org Cc: freebsd-hackers@freebsd.org Subject: Re: Raw Packet code containing security bits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Andrew, When filling your struct ip *iphead, try replacing: iphead->ip_len = htons(length); with: iphead->ip_len = length; or, for portability reasons, you may want to do something like: #ifdef LINUX || OpenBSD21 #define BO(x) htons(x) #else #define BO(x) (x) #endif And, when filling the ip packet length, do a: iphead->ip_len = BO(length); This is a byte-order issue that has often caused confusion for Linux people... /usr/include/machine/endian.h provides some insight... /Bosko. > I wonder if anyone here could perhaps of be assistance, Im currently > playing with implementing certain things in trusted bsd to do with ip > security classes and how the system responds to security bits, and > implementing certain things the stack etc. However my first piece of > test > code playing with raw packets to test how things respond to packets with > the security bit set, doesnt seem to want to work. This code compiles > fine, however when I try and run it it says invalid argument when it > tries > to send the packet. If anyone could give me any insight as to why this > code doesnt run properly, it would be much appreciated, and would > certainly help me in my efforts to continue expanding trusted bsd. > > Ive included the code below... > > Thanks > Andrew [snipped] <----- - - . . Bosko Milekic http://www.dsuper.net/~bmilekic/ Network Operations - Delphi SuperNet, an Internet Direct company +1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/ . . - - -----> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 16:15:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 4EA33155D6; Mon, 16 Aug 1999 16:09:19 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA04563; Tue, 17 Aug 1999 00:31:42 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 62B648795; Mon, 16 Aug 1999 23:47:52 +0200 (CEST) Date: Mon, 16 Aug 1999 23:47:52 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [Fwd: [URGENT] CVS problems] Message-ID: <19990816234752.A68226@keltia.freenix.fr> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <37B86A59.9462A5AB@rsv.ricoh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <37B86A59.9462A5AB@rsv.ricoh.com>; from Mark Jaffe on Mon, Aug 16, 1999 at 12:45:29PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Mark Jaffe: > > CVS is issuing an "out of memory" message on attempting to checkin a > > 12MB file. What can I do? There is 300M of swap on the machine, it is > > running FreeBSD 2.2.8, and CVS says: > > "Concurrent Versions System (CVS) 1.9.26 (client/server)" > > > > I'll post this to the lists, too. Check the limits for the user running the command (datasize & stacksize), both locally and remotely. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 16:28:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 24F1714DA5; Mon, 16 Aug 1999 16:28:28 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id QAA03157; Mon, 16 Aug 1999 16:04:11 -0700 (PDT) Date: Mon, 16 Aug 1999 16:04:11 -0700 (PDT) From: Bill Studenmund Reply-To: Bill Studenmund To: Terry Lambert Cc: Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908162118.OAA04940@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999, Terry Lambert wrote: > > > 2. Advisory locks are hung off private backing objects. > > I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an > > efficiency concern. If we actually make a VOP call, that should be the > > end of the story. I.e either add a vnode flag to indicate pas/fail-ness, > > or add a genfs/std call to handle the problem. > > > > I'd actually vote for the latter. Hang the byte-range locking off of the > > vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on > > OS flavor) to handle the call. That way all fs's that can share code, and > > the callers need only call VO_ADVLOCK() - no other logic. > > OK. Here's the problem with that: NFS client locks in a stacked > FS on top the the NFS client FS. Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to do that. Though it would mean growing the fs footprint. > Specifically, you need to seperate the idea of asserting a lock > against the local vnode, asserting the lock via NFS locking, and > coelescing the local lock list, after both have succeeded, or > reverting the local assertion, should the remote assertion fail. Right. But my thought was that you'd be calling an NFS routine, so it could do the right thing. > > NetBSD actually needs this to get unionfs to work. Do you want to talk > > privately about it? > > If you want. FreeBSD needs it for unionfs and nullfs, so it's > something that would be worth airing. > > I think you could say that no locking routine was an approval of > the uuper level lock. This lets you bail on all FS's except NFS, > where you have to deal with the approve/reject from the remote > host. The problem with this on FreeBSD is the VFS_default stuff, > which puts a non-NULL interface on all FS's for all VOP's. I'm not familiar with the VFS_default stuff. All the vop_default_desc routines in NetBSD point to error routines. > Yes, this NULL is the same NULL I suggested for advisory locks, > above. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. > > > 5. The idea of "root" vs. "non-root" mounts is inherently bad. > > You forgot: > > > > 5) Update export lists > > > > If you call the mount routine with no device name > > (args.fspec == 0) and with MNT_UPDATE, you get > > routed to the vfs_export routine > > This must be the job of the upper level code, so that there is > a single control point for export information, instead of spreading > it throughout ead FS's mount entry point. I agree it should be detangled, but think it should remain the fs's job to choose to call vfs_export. Otherwise an fs can't impliment its own export policies. :-) > > I thought it was? Admitedly the only reference code I have is the ntfs > > code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it > > is, I thought it'd be an ok reference. > > No. We've lost the context, but what I was trying to say was that I thought the marking-the-vnode-as-mounted-on bit was done in the mount syscall at present. At least that's what http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_syscalls.c?rev=1.130 seems to be doing. > Basically, what you would have is the equivalent of a variable > length "mounted volume" table, from which mappings (and exports, > based on the mappings) are externalized into the namespace. Ahh, sounds like you're talking about a new formalism.. > Right. It should just have a "mount" entry point, and the rest > of the stuff moves to higher level code, called by the mount system > call, and the mountroot stuff during boot, to externalize the root > volume at the top of the hierarchy. > > An ideal world would mount a / that had a /dev under it, and then > do transparent mounts over top of that. That would be quite a different place than we have now. ;-) > > > The conversion of the root device into a vnode pointer, or > > > a path to a device into a vnode pointer, is the job of upper > > > level code -- specifically, the mount system call, and the > > > common code for booting. > > > > My one concern about this is you've assumed that the user is mounting a > > device onto a filesystem. > > No. Vnoide, not bdevvp. The bdevvp stuff is for the boot time stuff > in the upper level code, and only applies to the root volume. Maybe I mis-parsed. I thought you were talking about parsing the first mount option (in mount /dev/disk there, the /dev/disk option) into a vnode. The concern below is that different fs's have different ideas as to what that node should be. Some want it a device node which no one else is using (most leaf fs's), while some others want a directory (nullfs, etc), some want a file or device (the HSM system I'm working on) while others don't care (in mount -t kernfs /kern /kern , the first kern doesn't matter at all). But all is well with different support routines which the mount_foo() routine can call. > > Layered filesystems won't do that. nullfs, > > umaptfs, and unionfs will want a directory. The hierarchical storage > > system I'm working on will want a file. kernfs, procfs, and an fs which I > > haven't checked into the NetBSD tree don't really need the extra > > parameter. Supporting all these different cases would be a hassle for > > upstream code. > > > > > This removes a large amount of complex code from each of > > > the file systems, and centralizes the maintenance task into > > > one set of code that either works for everyone, or no one > > > (removing the duplication of code/introduction of errors > > > issue). > > > > Might I suggest a common library of routines which different mount > > routines can call? That way we'd get code sharing while letting the fs > > make decisions about what it expects of the input arguments. > > This is the "footprint" problem, all over again. Reject/accept (or > "accept if no VOP") seems more elegant, and also reduces footprint. Very true. The problem is that the current VFS system was designed as a black box. It gets handed all calls, and it gets to decide policy, and do everything on its own. We're now basically discussing ways of having the plethora of fs's we now have do things the same way. :-) > > > 7. The struct nameidata (namei.h) is broken in conception. > > Can you push a Unicode name down from an appropriate system call? > > I don't see any way to deal with an NT FS for characters outside > ISO 8859-1, otherwise. 8-(. Hmmm. I think the real problem is that the kernel(s) is(are) not at all designed well for different laguages. > > > 9. The implementation of namei() is POSIX non-compliant > > > > > > The implementation of namei() is by means of coroutine > > > "recursion"; this is similar to the only recursion you can > > > achieve in FORTRAN. > > > > > > The upshot of this is that the use of the "//" namespace > > > escape allowed by POSIX can not be usefully implemented. > > > This is because it is not possible to inherit a namespace > > > escape deeper than a single path component for a stack of > > > more than one layer in depth. > > > > > > This needs to be fixed, both for "natural" SMBFS support, > > > and for other uses of the namespace escape (HTTP "tunnels", > > > extended attribute and/or resource fork access in an OS/2 > > > HPFS or Macintosh HFS implementation, etc.), including > > > forward looking research. > > > > > > This is related to item 7. > > > > I'm sorry. This point didn't parse. Could you give an example? > > > > I don't see how the namei recursion method prevents catching // as a > > namespace escape. > > > //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork > > You can't inherit the fact that you are looking at the resource fork > in the terminal component, ONLY. Yep, there's no easy way to do that now.. The one thing which comes to mind is to have lookup() rip out the first component and save it in the namei struct. Though the devil's advocate in me points out that this difficulty is not inherent in the recursion setup, but in how lookup() is designed. :-) > > > Quotas should be an abstract stacking layer that can be > > > applied to any FS, instead of an FFS specific monstrosity. > > > > It should certainly be possible to add a quota layer on top of any leaf > > fs. That way you could de-couple quotas. :-) > > Yes, assuming stacking works in the first place... Except for a minor buglet with device nodes, stacking works in NetBSD at present. :-) > > One other suggestion I've heard is to split the 64 bits we have for time > > into 44 bits for seconds, and 20 bits for microseconds. That's more than > > enough modification resolution, and also pushes things to past year > > 500,000 AD. Versioning the indoe would cover this easily. > > Ugh. But possible... I agree it's ugly, but it has the advantage that it doesn't grow the on-disk inode. A lot of flks have designs on the remaining 64 bits free. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 17: 3:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 1EF6E1556D for ; Mon, 16 Aug 1999 17:03:24 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA26793; Mon, 16 Aug 1999 17:03:20 -0700 (PDT) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id RAA18821; Mon, 16 Aug 1999 17:02:37 -0700 (PDT) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id RAA09883; Mon, 16 Aug 1999 17:03:17 -0700 (PDT) Message-Id: <199908170003.RAA09883@mina.sr.hp.com> To: Mark Jaffe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [Fwd: [URGENT] CVS problems] Reply-To: Darryl Okahata In-reply-to: Your message of "Mon, 16 Aug 1999 12:45:29 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Aug 1999 17:03:17 -0700 From: Darryl Okahata Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mark Jaffe wrote: > > > > CVS is issuing an "out of memory" message on attempting to checkin a > > 12MB file. What can I do? There is 300M of swap on the machine, it is > > running FreeBSD 2.2.8, and CVS says: > > "Concurrent Versions System (CVS) 1.9.26 (client/server)" > > Anyone help? How big is the history file size (compared to the processes' max allowed data size)? CVS has a number of brain-damanged areas; one in particular is that CVS reads the *ENTIRE* history file into memory when doing stuff ... and it's doing so simply to scan the history file line-by-line .... -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 17:49:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from stumpy.dannyland.org (stumpy.dannyland.org [209.157.133.194]) by hub.freebsd.org (Postfix) with ESMTP id 40DF114D91 for ; Mon, 16 Aug 1999 17:48:49 -0700 (PDT) (envelope-from dannyman@stumpy.dannyland.org) Received: by stumpy.dannyland.org (Postfix, from userid 1000) id B12493C2D; Mon, 16 Aug 1999 17:48:22 -0700 (PDT) Date: Mon, 16 Aug 1999 17:48:22 -0700 From: dannyman To: Sheldon Hearn Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: Using legacy sysinstall to upgrade live system Message-ID: <19990816174822.F353@stumpy.dannyland.org> References: <19990813175110.C38502@stumpy.dannyland.org> <91474.934626582@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <91474.934626582@axl.noc.iafrica.com>; from Sheldon Hearn on Sat, Aug 14, 1999 at 12:29:42PM +0200 X-Loop: djhoward@uiuc.edu X-URL: http://www.dannyland.org/~dannyman/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Aug 14, 1999 at 12:29:42PM +0200, Sheldon Hearn wrote: > On Fri, 13 Aug 1999 17:51:10 MST, dannyman wrote: > > > Uhmmm, what if we don't have a floppy drive? > > Then you probably have a CDROM drive or a network interface, both of > which can be used to get sysinstall onto your machine. :-) The point of it is, it's easy enough to download the floppies, but it's really hard to boot a system off an .flp image. :p Or, the real point of it is, that aside from "make world from source" there is no good way to update an existing system without doing something lame like having to boot ... off ... a .... floppy ... uncompressing kernel ... please wait ... But, on to my original question, has anybody been looking at a more "user friendly" "upgrade the darn thing *REAL EASY*" kind of setup? maybe invoke a networked pkg_add to run the latest sysinstall w dependencies? -dman -- dannyman - http://www.dannyland.org/~dannyman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 18: 8:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 9613B14DF1 for ; Mon, 16 Aug 1999 18:08:24 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id KAA43741; Tue, 17 Aug 1999 10:36:36 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908170106.KAA43741@gizmo.internode.com.au> Subject: Re: Using legacy sysinstall to upgrade live system To: dannyman@dannyland.org (dannyman) Date: Tue, 17 Aug 1999 10:36:36 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <19990816174822.F353@stumpy.dannyland.org> from "dannyman" at Aug 16, 99 05:48:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dannyman wrote: > The point of it is, it's easy enough to download the floppies, but > it's really hard to boot a system off an .flp image. :p 1. boot single-user 2. dd if=/some/dir/boot.flp of=/dev/da0s1b 3. reboot 4. When boot1 gives you the 5-second paused baton, press any key 5. enter "da(0,b)" at the Boot: prompt Us FreeBSD people can pretend we can do miniroot installs too :-) [ admittedly, I haven't tried this since before the new boot blocks were committed, but it worked perfectly last year... ] - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 18:50:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8DC6214E01 for ; Mon, 16 Aug 1999 18:50:23 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id SAA36553; Mon, 16 Aug 1999 18:44:01 -0700 (PDT) Date: Mon, 16 Aug 1999 18:45:03 -0700 (PDT) From: Julian Elischer To: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vnc on nat-proxy/firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG vnc is cool, but also check out back-orafice (not sure where you get it but the new one can take over NT as well as W95) On Tue, 17 Aug 1999, Leif Neland wrote: > I need to remote-control an NT behind a unix-box running > nat-proxy/firewall/gateway. > > Would it be possible first to connect from the outside to a vnc-server on > gateway, then to run vnc-client on the gateway to connect to a vnc-server > on the nt? > > Or is it possible to have a vnc-proxy on the gateway to redirect to the > nt? > > Leif > > > > > 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 Mon Aug 16 19: 9:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 9FDFC14E5D for ; Mon, 16 Aug 1999 19:09:36 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id LAA28981; Tue, 17 Aug 1999 11:37:14 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990817113714:5835=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: Date: Tue, 17 Aug 1999 11:37:14 +0930 (CST) From: "Daniel O'Connor" To: Julian Elischer Subject: Re: vnc on nat-proxy/firewall Cc: freebsd-hackers@FreeBSD.ORG, Leif Neland Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990817113714:5835=_ Content-Type: text/plain; charset=us-ascii On 17-Aug-99 Julian Elischer wrote: > vnc is cool, but also check out back-orafice > (not sure where you get it but the new one can take over NT as well as > W95) BO2K does NT (much to MS's chagrin)... --- 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 --_=XFMail.1.3.p0.FreeBSD:990817113714:5835=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7jD0lbYW/HEoF9pAQGgnwP+M4O4iaQAYTLfwVZaqsuLsUfRrTGw7XpU SBe8MhEFqEAp5MaHk79mHS8avlp8NdyE/fonxUUlCEM7JzHeCRwtVX+gZKi3utiZ IW/I4tEDF5MIK8KTgnawGhV3S1+TjzDrAmqlEAMKKCW/+yfKDAFf1SwIeBjUpJb4 nI7KG1dQuhM= =EbrT -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990817113714:5835=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 19:33: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id E37FB14D15; Mon, 16 Aug 1999 19:32:53 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA19029; Mon, 16 Aug 1999 19:31:20 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd019018; Mon Aug 16 19:31:18 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA08526; Mon, 16 Aug 1999 19:31:16 -0700 (MST) From: Terry Lambert Message-Id: <199908170231.TAA08526@usr02.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov Date: Tue, 17 Aug 1999 02:31:16 +0000 (GMT) Cc: tlambert@primenet.com, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: from "Bill Studenmund" at Aug 16, 99 04:04:11 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > 2. Advisory locks are hung off private backing objects. > > > > > > I'd vote againsts your implimentation suggestion for VOP_ADVLOCK on an > > > efficiency concern. If we actually make a VOP call, that should be the > > > end of the story. I.e either add a vnode flag to indicate pas/fail-ness, > > > or add a genfs/std call to handle the problem. > > > > > > I'd actually vote for the latter. Hang the byte-range locking off of the > > > vnode, and add a genfs_advlock() or vop_stdadvlock() routine (depending on > > > OS flavor) to handle the call. That way all fs's that can share code, and > > > the callers need only call VO_ADVLOCK() - no other logic. > > > > OK. Here's the problem with that: NFS client locks in a stacked > > FS on top the the NFS client FS. > > Ahh, but it'd be the fs's decision to map genfs_advlock()/vop_stdadvlock() > to its vop_advlock_desc entry or not. In this case, NFS wouldn't want to > do that. > > Though it would mean growing the fs footprint. Nope; that's not really the problem. The problem is if I have two local processes that get into a race in order to obtain a remote lock. Because the remote lock is not asserted, there's no way to ensure that the order of service for the request is the same as the order of request -- consider cooperating programs, like sendmail and pine or elm (or whatever). The only way to resolve this is to ensure that the cooperating programs on the same system are lockstepped: at the client. The only way to do this is to assert the lock locally, then remotely, if the local assertion succeeds. In the case of our cooperating local processes, this resolves the race condition (depending on F_SETLCK/F_SETLCKW, they behave as if the locks were local. Which is what you want. > > Specifically, you need to seperate the idea of asserting a lock > > against the local vnode, asserting the lock via NFS locking, and > > coelescing the local lock list, after both have succeeded, or > > reverting the local assertion, should the remote assertion fail. > > Right. But my thought was that you'd be calling an NFS routine, so it > could do the right thing. The problem is that the local lock doesn't belong to NFS. Even if it did (I think this would be an error for a remotely mounted "whiteout" in a "translucent" local FS), the problem is that in doing the local assertion, you will intrinsically coeelesce locks. Now if the lock mode you are requesting overlaps a previous lock, and the modes are not exactly the same, there's no way to back out the local promotion or demotion without a coelesce. This doesn't resolve the most complex cases you could contrive, with multiple stacking layers that don't support a distributed coherency protocol for locks for two or more players, but it handles the local vs. NFS issues acceptably. > > > NetBSD actually needs this to get unionfs to work. Do you want to talk > > > privately about it? > > > > If you want. FreeBSD needs it for unionfs and nullfs, so it's > > something that would be worth airing. > > > > I think you could say that no locking routine was an approval of > > the uuper level lock. This lets you bail on all FS's except NFS, > > where you have to deal with the approve/reject from the remote > > host. The problem with this on FreeBSD is the VFS_default stuff, > > which puts a non-NULL interface on all FS's for all VOP's. > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > routines in NetBSD point to error routines. In FreeBSD, they now point to default routines that are *not* error routines. This is the problem. I admit the change was very well intentioned, since it made the code a hell of a lot more readable, but choosing between readable and additional function, I take function over form (I think the way I would have "fixed" the readability is by making the operations that result in the descriptor set for a mounted FS instance be both discrete, and named for their specific function). > > Yes, this NULL is the same NULL I suggested for advisory locks, > > above. > > I'm not sure. The struct lock * is only used by layered filesystems, so > they can keep track both of the underlying vnode lock, and if needed their > own vnode lock. For advisory locks, would we want to keep track both of > locks on our layer and the layer below? Don't we want either one or the > other? i.e. layers bypass to the one below, or deal with it all > themselves. I think you want the lock on the intermediate layer: basically, on every vnode that has data associated with it that is unique to a layer. Let's not forget, also, that you can expose a layer into the namespace in one place, and expose it covered under another layer, at another. If you locked down to the backing object, then the only issue you would be left with is one or more intermediate backing objects. For a layer with an intermediate backing object, I'm prepared to declare it "special", and proxy the operation down to any inferior backing object (e.g. a union FS that adds files from two FS's together, rather than just directoriy entry lists). I think such layers are the exception, not the rule. > > > > 5. The idea of "root" vs. "non-root" mounts is inherently bad. > > > You forgot: > > > > > > 5) Update export lists > > > > > > If you call the mount routine with no device name > > > (args.fspec == 0) and with MNT_UPDATE, you get > > > routed to the vfs_export routine > > > > This must be the job of the upper level code, so that there is > > a single control point for export information, instead of spreading > > it throughout ead FS's mount entry point. > > I agree it should be detangled, but think it should remain the fs's job to > choose to call vfs_export. Otherwise an fs can't impliment its own export > policies. :-) I think that export policies are the realm of /etc/exports. The problem with each FS implementing its own policy, is that this is another place that copyinstr() gets called, when it shouldn't. > > > I thought it was? Admitedly the only reference code I have is the ntfs > > > code in the NetBSD kernel. But given how full of #ifdef (__FreeBSD__)'s it > > > is, I thought it'd be an ok reference. > > > > No. > > We've lost the context, but what I was trying to say was that I thought > the marking-the-vnode-as-mounted-on bit was done in the mount syscall at > present. At least that's what > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_syscalls.c?rev=1.130 > seems to be doing. > > > Basically, what you would have is the equivalent of a variable > > length "mounted volume" table, from which mappings (and exports, > > based on the mappings) are externalized into the namespace. > > Ahh, sounds like you're talking about a new formalism.. Right. The "covering" operation is not the same as the "marking as covered" operation. Both need to be at the higher level. If you wanted to get gross, you could say that it was a volume table, and the use POSIX namespace escapes, such as "//DISK/2/..." to access each disk as its own "/". This sounds gross, but if you had 4M extents on a very large disk, it would be nearly ideal for installing software: each package would get its own "disk", and you could share "packages" instead of "FS"'s. For something like mobile computing, consider a package as a shared resource. You have your presentation package which you mount off your local net, you fly to New York to present, and you mount the same presentation package from the network where you are a guest. Forget paths, installation, and all that crap. > > Right. It should just have a "mount" entry point, and the rest > > of the stuff moves to higher level code, called by the mount system > > call, and the mountroot stuff during boot, to externalize the root > > volume at the top of the hierarchy. > > > > An ideal world would mount a / that had a /dev under it, and then > > do transparent mounts over top of that. > > That would be quite a different place than we have now. ;-) Not really. Julian Elisher had code that mounted a /devfs under / automatically, before the user was ever allowed to see /. As a result, the FS that you were left with was indistinguishable from what I describe. The only real difference is that, as a translucent mount over /devfs, the one I describe would be capable of implementing persistant changes to the /devfs, as whiteouts. I don't think this is really that desirable, but some people won't accept a devfs that doesn't have traditional persistance semantics (e.g. "chmod" vs. modifying a well known kernel data structure as an administrative operation). I guess the other difference is that you don't have to worry about large minor numbers when you are bringing up a new platform via NFS from an old platform that can't support large minors in its FS at all. ;-). > > > > The conversion of the root device into a vnode pointer, or > > > > a path to a device into a vnode pointer, is the job of upper > > > > level code -- specifically, the mount system call, and the > > > > common code for booting. > > > > > > My one concern about this is you've assumed that the user is mounting a > > > device onto a filesystem. > > > > No. Vnode, not bdevvp. The bdevvp stuff is for the boot time stuff > > in the upper level code, and only applies to the root volume. > > Maybe I mis-parsed. I thought you were talking about parsing the first > mount option (in mount /dev/disk there, the /dev/disk option) into a > vnode. The concern below is that different fs's have different ideas as to > what that node should be. Some want it a device node which no one else is > using (most leaf fs's), while some others want a directory (nullfs, etc), > some want a file or device (the HSM system I'm working on) while others > don't care (in mount -t kernfs /kern /kern , the first kern doesn't matter > at all). But all is well with different support routines which the > mount_foo() routine can call. I would resolve this by passing a standard option to the mount code in user space. For root mounts, a vnode is passed down. For other mounts, the vnode is parsed and passed if the option is specified. I think that you will only be able to find rare examples of FS's that don't take device names as arguments. But for those, you don't specify the option, and it gets "NULL", and whatever local options you specify. The point is that, for FS's that can be both root and sub-root, the mount code doesn't have to make the decision, it can be punted to higher level code, in one place, where the code can be centrally maintained and kept from getting "stale" when things change out from under it. > > > Might I suggest a common library of routines which different mount > > > routines can call? That way we'd get code sharing while letting the fs > > > make decisions about what it expects of the input arguments. > > > > This is the "footprint" problem, all over again. Reject/accept (or > > "accept if no VOP") seems more elegant, and also reduces footprint. > > Very true. The problem is that the current VFS system was designed as a > black box. It gets handed all calls, and it gets to decide policy, and do > everything on its own. We're now basically discussing ways of having the > plethora of fs's we now have do things the same way. :-) I don't think so. I like to think in terms of "VFS consumer" and "VFS producer". The implied semantics are the provenanace of the "VFS consumer". A good example of this is to look at another VFS consumer, the NFS server. It really doesn't want implied semantics, and, in fact, wants to have a set of semantics (server locking information) sent in through a seperate communications channel. The way things are right now, as a VFS consumer, the NFS server is a second class citizen. One could imagine an AppleTalk or SMB server in the kernel, as well, also VFS consumers. And one could imagine doing VFS operations against files _from within the kernel_ (say in a "quota" stacking layer, or a resource fork/extended attributes stacking layer). The point is, you want to stop implying some semantics for these consumers. Where you draw the line is where you imply sematics via call-down, or via reject/accept. If you don't want them implied all the time, for all consumers, then they belong in the system call layer; othersise, they belong in the VFS layer doing the implementation. There's an abstraction here: is the VFS stacking layer you are talking about one that implements semantics? For an ACL stacking layer, your answer is yes. But for an NFS server stacked on a VFS? Or a namespace hiding layer? > > > > 7. The struct nameidata (namei.h) is broken in conception. > > > > Can you push a Unicode name down from an appropriate system call? > > > > I don't see any way to deal with an NT FS for characters outside > > ISO 8859-1, otherwise. 8-(. > > Hmmm. I think the real problem is that the kernel(s) is(are) not at all > designed well for different laguages. Well, if you make the path component descriptor into an opaque object, you can pass it down to the point you get to someone who understands the encapsulated data. The interpretation is a rendesvous -- an agreement -- between the source providing the data, and the target interpreting it. > > > > 9. The implementation of namei() is POSIX non-compliant > > > > > > > > The implementation of namei() is by means of coroutine > > > > "recursion"; this is similar to the only recursion you can > > > > achieve in FORTRAN. [ ... ] > > > > > > I'm sorry. This point didn't parse. Could you give an example? > > > > > > I don't see how the namei recursion method prevents catching // as a > > > namespace escape. > > > > > > //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork > > > > You can't inherit the fact that you are looking at the resource fork > > in the terminal component, ONLY. > > Yep, there's no easy way to do that now.. The one thing which comes to > mind is to have lookup() rip out the first component and save it in the > namei struct. > > Though the devil's advocate in me points out that this difficulty is not > inherent in the recursion setup, but in how lookup() is designed. :-) If it were a parameter, "namespace", to the function, it'd work, too. The problem is that you really want to install "namespace handlers" for these escapes, probably on a per FS basis. The only way I can see this working is to place the namespace into the path descriptor _seperately_ from the path components (however they get parsed out by that namespace). This shows the evils of "copyinstr()" in the full light of day: I can't have a "//unicode/..." name space escape, unless I assume ISO-8859-1, like the NTFS currently does, or unless I engage in some unnatural act with my "..." following the escape (e.g. UTF-8). > > > > Quotas should be an abstract stacking layer that can be > > > > applied to any FS, instead of an FFS specific monstrosity. > > > > > > It should certainly be possible to add a quota layer on top of any leaf > > > fs. That way you could de-couple quotas. :-) > > > > Yes, assuming stacking works in the first place... > > Except for a minor buglet with device nodes, stacking works in NetBSD at > present. :-) Have you tried Heidemann's student's stacking layers? There is one encryption, and one per-file compression with namespace hiding, that I think it would be hard pressed to keep up with. But I'll give it the benefit of the doubt. 8-). > > > One other suggestion I've heard is to split the 64 bits we have for time > > > into 44 bits for seconds, and 20 bits for microseconds. That's more than > > > enough modification resolution, and also pushes things to past year > > > 500,000 AD. Versioning the indoe would cover this easily. > > > > Ugh. But possible... > > I agree it's ugly, but it has the advantage that it doesn't grow the > on-disk inode. A lot of flks have designs on the remaining 64 bits free. > :-) Well, so long as we can resolve the issue for a long, long time; I plan on being around to have to put up with the bugs, if I can wrangle it... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 19:45: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cc158233-a.catv1.md.home.com (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (Postfix) with ESMTP id 48C4314D28 for ; Mon, 16 Aug 1999 19:45:06 -0700 (PDT) (envelope-from sjr@home.net) Received: (from sjr@localhost) by cc158233-a.catv1.md.home.com (8.9.3/8.9.3) id WAA92263 for freebsd-hackers@FreeBSD.ORG; Mon, 16 Aug 1999 22:45:28 -0400 (EDT) (envelope-from sjr) Message-Id: <199908170245.WAA92263@cc158233-a.catv1.md.home.com> Date: Mon, 16 Aug 1999 22:45:28 -0400 (EDT) From: "Stephen J. Roznowski" Subject: How much memory (max) will FreeBSD use? To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've looked at http://www.freebsd.org/FAQ/FAQ51.html, but the answer seems to be lacking... On a stock system (3.2 and 4.0), how much RAM will a system be able to use? Will a stock system use all 4GB? Thanks, -- Stephen J. Roznowski (sjr@home.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 21:54:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9716C155E8 for ; Mon, 16 Aug 1999 21:54:01 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id AAA17059 for ; Tue, 17 Aug 1999 00:51:28 -0400 (EDT) Date: Tue, 17 Aug 1999 00:51:27 -0400 (EDT) From: "Matthew N. Dodd" To: freebsd-hackers@freebsd.org Subject: Kerberos 5 integration. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Who were the parties that were heading up the Kerberos 5 integration? I have questions. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 22:37:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9C30E14C15 for ; Mon, 16 Aug 1999 22:37:14 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Gbvs-0001BM-00; Tue, 17 Aug 1999 07:37:12 +0200 From: Sheldon Hearn To: dannyman Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: Using legacy sysinstall to upgrade live system In-reply-to: Your message of "Mon, 16 Aug 1999 17:48:22 MST." <19990816174822.F353@stumpy.dannyland.org> Date: Tue, 17 Aug 1999 07:37:12 +0200 Message-ID: <4547.934868232@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999 17:48:22 MST, dannyman wrote: > The point of it is, it's easy enough to download the floppies, but > it's really hard to boot a system off an .flp image. :p Presumably you saw the posted trick about dd'ing the floppy image to your swap partition and booting off _that_? :-) > But, on to my original question, has anybody been looking at a more > "user friendly" "upgrade the darn thing *REAL EASY*" kind of setup? > maybe invoke a networked pkg_add to run the latest sysinstall w > dependencies? Your original question? I started this thread. ;-) The best answer someone who is neither omniscient nor omnipresent can give you is I expect I'd be surprised to find that anybody was working on such a thing. Assume that further silence on the issue confirms that feeling. I've seen lots of people come up with ideas that they felt were good and worthy of lots of argument, but the ideas always seem to be all talk(1) and no diff(1). ;-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 23:21:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id B7D0B15580 for ; Mon, 16 Aug 1999 23:21:10 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Gcay-0001TX-00; Tue, 17 Aug 1999 08:19:40 +0200 From: Sheldon Hearn To: "Stephen J. Roznowski" Cc: hackers@freebsd.org Subject: Re: How much memory (max) will FreeBSD use? In-reply-to: Your message of "Mon, 16 Aug 1999 22:45:28 -0400." <199908170245.WAA92263@cc158233-a.catv1.md.home.com> Date: Tue, 17 Aug 1999 08:19:40 +0200 Message-ID: <5674.934870780@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Aug 1999 22:45:28 -0400, "Stephen J. Roznowski" wrote: > On a stock system (3.2 and 4.0), how much RAM will a system be able to > use? Will a stock system use all 4GB? I expect that someone else will answer your question. I just want to clear up a possible misunderstanding that could cost you a lot of wasted time later. The word "stock" doesn't apply to 4.0 . That's the development edge of FreeBSD, which is not recommended for use in production environments by people who aren't prepared to bleed graciously. :-) Make sure you're familiar with the information at the following URLs before choosing to run 4.0-CURRENT: http://www.freebsd.org/handbook/cutting-edge.html http://www.freebsd.org/FAQ/FAQ7.html Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 23:21:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 53873155B7 for ; Mon, 16 Aug 1999 23:21:24 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11GcbU-0001Tr-00; Tue, 17 Aug 1999 08:20:12 +0200 From: Sheldon Hearn To: "Matthew N. Dodd" Cc: freebsd-hackers@freebsd.org Subject: Re: Kerberos 5 integration. In-reply-to: Your message of "Tue, 17 Aug 1999 00:51:27 -0400." Date: Tue, 17 Aug 1999 08:20:12 +0200 Message-ID: <5694.934870812@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999 00:51:27 -0400, "Matthew N. Dodd" wrote: > Who were the parties that were heading up the Kerberos 5 integration? > > I have questions. Seek Ye first the kingdom of Mark. (markm) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 23:27:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 150D914D2A for ; Mon, 16 Aug 1999 23:27:34 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA42102; Tue, 17 Aug 1999 00:26:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA36764; Tue, 17 Aug 1999 00:26:57 -0600 (MDT) Message-Id: <199908170626.AAA36764@harmony.village.org> To: brian@pobox.com Subject: Re: BSD XFS Port & BSD VFS Rewrite Cc: Terry Lambert , Vince Vielhaber , Hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Aug 1999 09:40:48 PDT." <19990816164048.28824.rocketmail@web1001.mail.yahoo.com> References: <19990816164048.28824.rocketmail@web1001.mail.yahoo.com> Date: Tue, 17 Aug 1999 00:26:57 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990816164048.28824.rocketmail@web1001.mail.yahoo.com> Brian McGroarty writes: : So do the old and new Playstation models. The MIPS core is being : manufactured by several companies: IDT alone has something like : a dozen variants available with and without MMU, FP, 5000 vs : 10000 core, etc. and is in far wider use than in just PCs and : gaming consoles. I doubt if SGI machines abandoning MIPS : processors would put much of a dent in MIPS' profitability. NEC also makes about a dozen. Although they aren't stupid enough to make any without MMUs :-) I really don't like the IDT 4650, can you tell... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 16 23:28:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3419D155E7 for ; Mon, 16 Aug 1999 23:28:51 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA42115; Tue, 17 Aug 1999 00:29:16 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA36794; Tue, 17 Aug 1999 00:30:02 -0600 (MDT) Message-Id: <199908170630.AAA36794@harmony.village.org> To: Narvi Subject: Re: BSD XFS Port & BSD VFS Rewrite Cc: Terry Lambert , Vince Vielhaber , Hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Aug 1999 20:22:21 +0300." References: Date: Tue, 17 Aug 1999 00:30:02 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Narvi writes: : > Nintendo 64 uses MIPS. : > : : Which doesn't matter all that much. MIPS cpus for nintendo could be made : by say MISP, not SGI (and SGI sold/is trying to sell MIPS). Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC. I think the new Nintendo will use a different (non-mips) processor, but I'm not completely sure what the new one will be (when NEC announced this, MIPS stock took a dive). SGI has already spun out MIPS and has been slowly reducing its stake in MIPS for some time now. However, there is another gaming machine based on a 128bit MIPS design in the pipeline from, I think, Sony. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 0:34:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 2FEBC155D9 for ; Tue, 17 Aug 1999 00:34:35 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Gdjx-0001eB-00; Tue, 17 Aug 1999 09:33:01 +0200 From: Sheldon Hearn To: Warner Losh Cc: Narvi , Terry Lambert , Vince Vielhaber , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Tue, 17 Aug 1999 00:30:02 CST." <199908170630.AAA36794@harmony.village.org> Date: Tue, 17 Aug 1999 09:33:01 +0200 Message-ID: <6334.934875181@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999 00:30:02 CST, Warner Losh wrote: > Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC. !!! I've been dethreading this subject line for a few days now, so I'm quite relieved to see this, the one e-mail message which I happened to check in on to make sure that I'm not missing anything. Has anyone invoked Godwin's Law yet? And is anyone recycling the bottle-rockets? :-P Ciao, Sheldon. PS: Yes, there's a comma missing from that first paragraph, but at least there were no split infinitives. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 0:35:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from medulla.hippocampus.net (medulla.hippocampus.net [204.138.241.6]) by hub.freebsd.org (Postfix) with ESMTP id E490715602 for ; Tue, 17 Aug 1999 00:35:18 -0700 (PDT) (envelope-from marc@netstor.com) Received: from localhost (marc@localhost) by medulla.hippocampus.net (8.9.2/8.9.2) with ESMTP id DAA09675; Tue, 17 Aug 1999 03:40:22 -0400 (EDT) Date: Tue, 17 Aug 1999 03:40:22 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: Andrzej Bialecki Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Saving system image to disk (NOT on a laptop) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wasn't there already a project that did this??? The project name escapes me, but I believe it was linked from the FreeBSD Projects page... -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com "Fast, Expandable and Affordable Internet Caching Products" 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 On Tue, 17 Aug 1999, Andrzej Bialecki wrote: > Hi, > > To all you low-level kernel and bootloader hackers: what would it take to > save and restore a running system image (presumably from dedicated raw > partition) so that the system would continue where it left before reboot? > > It doesn't sound that difficult to me - after all, laptops somehow do it - > but I know too little low-level stuff to try implementing it myself... > > Any comments? Some code? ;-) > > > Andrzej Bialecki > > // WebGiro AB, Sweden (http://www.webgiro.com) > // ------------------------------------------------------------------- > // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- > > > > 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 17 1: 0:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relex.relex.ru (slip.relex.ru [195.98.69.100]) by hub.freebsd.org (Postfix) with ESMTP id 5450A1577C for ; Tue, 17 Aug 1999 01:00:01 -0700 (PDT) (envelope-from alec@relex.relex.ru) Received: from alec.relex.ru (alec.relex.ru [195.98.69.163]) by relex.relex.ru (8.8.8/Relcom-2A) with SMTP id LAA14248 for ;Tue, 17 Aug 1999 11:49:23 +0400 (MSD) Message-ID: <01b001bee885$cca7b570$a34562c3@alec.relex.ru> From: "Alec Kalinin" To: Subject: Probably bug with allocation memory in FreeBSD-3.2-RELEASE Date: Tue, 17 Aug 1999 11:54:57 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I think, mentioned below program probably show the bug in virtual memory subsystem in FreeBSD-3.2-RELEASE. After running this program, FreeBSD comes into "out of swap" state, then hungs. Why i think this is bug? Because any user can hung FreeBSD, settings in /etc/login.conf can't help. Note: in FreeBSD-2.2.8 there is no this problem. The 2.2.8-system successfully kill this program. -------------------------------------------------------------------- #include #include #define NALLOC 1000 #define SIZEALLOC 1024*1024 void main() { char *p_mem; int i, j; if (fork() != 0) return; for (i=0; i; Tue, 17 Aug 1999 01:30:25 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id RAA70438; Tue, 17 Aug 1999 17:56:56 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908170826.RAA70438@gizmo.internode.com.au> Subject: Re: Probably bug with allocation memory in FreeBSD-3.2-RELEASE To: alec@relex.ru (Alec Kalinin) Date: Tue, 17 Aug 1999 17:56:55 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <01b001bee885$cca7b570$a34562c3@alec.relex.ru> from "Alec Kalinin" at Aug 17, 99 11:54:57 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alec Kalinin wrote: > I think, mentioned below program probably show the bug in virtual memory > subsystem in FreeBSD-3.2-RELEASE. After running this program, FreeBSD comes > into "out of swap" state, then hungs. Well, yeah, that's becuase you're running it out of swap by trying to allocate a gigabyte of memory. > Why i think this is bug? Because any user can hung FreeBSD, settings in > /etc/login.conf can't help. Are you sure about that? Setting datasize limits will prevent malloc() from doing what you're trying to make it do. Are you sure you're setting your login.conf settings properly? - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 2:11:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relex.relex.ru (slip.relex.ru [195.98.69.100]) by hub.freebsd.org (Postfix) with ESMTP id 2F2A814BF6 for ; Tue, 17 Aug 1999 02:10:19 -0700 (PDT) (envelope-from alec@relex.relex.ru) Received: from alec.relex.ru (alec.relex.ru [195.98.69.163]) by relex.relex.ru (8.8.8/Relcom-2A) with SMTP id MAA15047 ;Tue, 17 Aug 1999 12:56:32 +0400 (MSD) Message-ID: <027401bee88f$2e503b90$a34562c3@alec.relex.ru> From: "Alec Kalinin" To: "Mark Newton" Cc: "Oleg Derevenetz" , Subject: Re: Probably bug with allocation memory in FreeBSD-3.2-RELEASE Date: Tue, 17 Aug 1999 13:02:06 +0400 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello ! > > I think, mentioned below program probably show the bug in virtual memory > > subsystem in FreeBSD-3.2-RELEASE. After running this program, FreeBSD >> comes into "out of swap" state, then hungs. >Well, yeah, that's becuase you're running it out of swap by trying to >allocate a gigabyte of memory. Yes. I try to modeling "out of swap" in FreeBSD-3.2-RELEASE. > > Why i think this is bug? Because any user can hung FreeBSD, settings in > > /etc/login.conf can't help. >Are you sure about that? Setting datasize limits will prevent >malloc() from doing what you're trying to make it do. Are you >sure you're setting your login.conf settings properly? I am sure, that setting limits in "/etc/login.conf" is not good decision. I try to explain. First of all, if i set limits more than swap space, one user can hung system. But, if i set limit equal half swap space, two different users can hung system. Than, i don't set limits for root process. And combinantion "squid + Netscape with java applet" from root may hung system. While 3.2-system can't simply kill this process like 2.2.8-system? I think, killing this process -- best solution. Good luck, Alec. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 2:13:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id D4620156AC for ; Tue, 17 Aug 1999 02:13:24 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id LAA39046; Tue, 17 Aug 1999 11:12:55 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908170912.LAA39046@gratis.grondar.za> To: "Matthew N. Dodd" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. Date: Tue, 17 Aug 1999 11:12:54 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Who were the parties that were heading up the Kerberos 5 integration? > > I have questions. Me. I will be bringiong in Heimdal (when it interoperates with MIT-K5). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 17 2:25:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from patriot.wipinfo.soft.net (patriot.wipinfo.soft.net [164.164.6.21]) by hub.freebsd.org (Postfix) with ESMTP id 4819514E44 for ; Tue, 17 Aug 1999 02:25:28 -0700 (PDT) (envelope-from bee@wipinfo.soft.net) Received: from barbie.wipinfo.soft.net (root@barbie.wipinfo.soft.net [192.168.200.175]) by patriot.wipinfo.soft.net (8.9.2/8.9.2) with ESMTP id OAA03272 for ; Tue, 17 Aug 1999 14:55:33 -0500 (GMT) Received: from wipro.tcpn.com ([172.31.41.11]) by barbie.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id PAA06330 for ; Tue, 17 Aug 1999 15:13:19 +0530 Received: from keeravani (keeravani.wipro.tcpn.com [172.31.41.136]) by wipro.tcpn.com (8.9.3/8.9.3) with SMTP id OAA01118 for ; Tue, 17 Aug 1999 14:57:11 +0530 (IST) Reply-To: From: "Biju Susmer" Cc: Subject: RE: Probably bug with allocation memory in FreeBSD-3.2-RELEASE Date: Tue, 17 Aug 1999 14:54:41 +0530 Message-ID: <008801bee892$5703f920$88291fac@wipro.tcpn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199908170826.RAA70438@gizmo.internode.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Disposition-Notification-To: "Biju Susmer" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Well, yeah, that's becuase you're running it out of swap by trying to > allocate a gigabyte of memory. but this is done in steps of 1MB. Once it reaches out of memory, malloc should return NULL. Since there is no checking for NULL in this code, it should hit a signal, isn't it? Why that is not happening? -biju To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 4:18:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 0F34D15649 for ; Tue, 17 Aug 1999 04:17:51 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id OAA05640 for hackers@freebsd.org; Tue, 17 Aug 1999 14:19:41 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id OAA02565 for hackers@freebsd.org; Tue, 17 Aug 1999 14:08:46 +0400 (MSD) Message-Id: <199908171008.OAA02565@scorpion.crimea.ua> Subject: bftp(1) To: hackers@freebsd.org Date: Tue, 17 Aug 1999 14:08:46 +0400 (MSD) From: "Alexey M. Zelkin" X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, Man page for telnetd(8) references to bftp(1) which will be installed into /usr/ucb/bftp and of course does not exists. Can someone describe in few words is this staff still supported ? If so, there bftp(1) staff can be received/downloaded ? Otherwise I think it's good idea to remove this staff from manpage and probably from source code. -- Sincerely Yours, | phantom@crimea.edu (primary) Alexey Zelkin | phantom@scorpion.crimea.ua (home) | ICQ: #6196584, FIDO: 2:460/12.26 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 6:45:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 11E03156B5 for ; Tue, 17 Aug 1999 06:45:11 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id PAA32648; Tue, 17 Aug 1999 15:09:52 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id LAA20941; Tue, 17 Aug 1999 11:55:07 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908170955.LAA20941@yedi.iaf.nl> Subject: Re: Using legacy sysinstall to upgrade live system In-Reply-To: <199908170106.KAA43741@gizmo.internode.com.au> from Mark Newton at "Aug 17, 1999 10:36:36 am" To: newton@internode.com.au (Mark Newton) Date: Tue, 17 Aug 1999 11:55:07 +0200 (CEST) Cc: dannyman@dannyland.org, hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Mark Newton wrote ... > dannyman wrote: > > > The point of it is, it's easy enough to download the floppies, but > > it's really hard to boot a system off an .flp image. :p > > 1. boot single-user > 2. dd if=/some/dir/boot.flp of=/dev/da0s1b > 3. reboot > 4. When boot1 gives you the 5-second paused baton, press any key > 5. enter "da(0,b)" at the Boot: prompt > > Us FreeBSD people can pretend we can do miniroot installs too :-) Not completely. You also need a standalone 'disklabel' before you can use a factory fresh disk. Like SunOS 3.x etc used. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://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 17 7:18: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 0C5D9156C4; Tue, 17 Aug 1999 07:17:54 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.9.3/8.9.3) with SMTP id OAA17678; Tue, 17 Aug 1999 14:18:07 GMT Date: Tue, 17 Aug 1999 23:18:06 +0900 (JST) From: Michael Hancock To: Terry Lambert Cc: wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908170231.TAA08526@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > > routines in NetBSD point to error routines. > > In FreeBSD, they now point to default routines that are *not* error > routines. This is the problem. I admit the change was very well > intentioned, since it made the code a hell of a lot more readable, > but choosing between readable and additional function, I take function > over form (I think the way I would have "fixed" the readability is by > making the operations that result in the descriptor set for a mounted > FS instance be both discrete, and named for their specific function). As I recall most of FBSD's default routines are also error routines, if the exceptions were a problem it would would be trivial to fix. I think fixing resource allocation/deallocation for things like vnodes, cnbufs, and locks are a higher priority for now. There are examples such as in detached threading where it might make sense for the detached child to be responsible for releasing resources allocated to it by the parent, but in stacking this model is very messy and unnatural. This is why the purpose of VOP_ABORTOP appears to be to release cnbufs but this is really just an ugly side effect. With stacking the code that allocates should be the code that deallocates. Substitute, "code" with "layer" to be more correct. I fixed a lot of the vnode and locking cases, unfortunately the ones that remain are probably ugly cases where you have to reacquire locks that had to be unlocked somewhere in the executing layer. See VOP_RENAME for an example. Compare the number of WILLRELEs in vnode_if.src in FreeBSD and NetBSD, ideally there'd be none. Regards, Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 7:40:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web1005.mail.yahoo.com (web1005.mail.yahoo.com [128.11.23.95]) by hub.freebsd.org (Postfix) with SMTP id ABEBE14E60 for ; Tue, 17 Aug 1999 07:40:33 -0700 (PDT) (envelope-from bvmcg@yahoo.com) Message-ID: <19990817143812.20033.rocketmail@web1005.mail.yahoo.com> Received: from [206.71.110.100] by web1005.mail.yahoo.com; Tue, 17 Aug 1999 07:38:12 PDT Date: Tue, 17 Aug 1999 07:38:12 -0700 (PDT) From: Brian McGroarty Reply-To: brian@pobox.com Subject: Re: BSD XFS Port & BSD VFS Rewrite To: Warner Losh Cc: Terry Lambert , Vince Vielhaber , Hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --- Warner Losh wrote: > In message > <19990816164048.28824.rocketmail@web1001.mail.yahoo.com> > Brian McGroarty writes: > : So do the old and new Playstation models. The MIPS core is > : being manufactured by several companies: IDT alone has > : something like a dozen variants available with and without > : MMU, FP, 5000 vs 10000 core, etc. and is in far wider use > : than in just PCs and gaming consoles. I doubt if SGI > : machines abandoning MIPS processors would put much of a dent > : in MIPS' profitability. > > NEC also makes about a dozen. Although they aren't stupid > enough to make any without MMUs :-) I really don't like the > IDT 4650, can you tell... If you think that's bad, try writing 3D games on the MIPS without a MMU, FPU or a data cache. Welcome to Playstation programming. Admittedly it's got a direct-mapped scratchpad where you can drop temporary data and some really esoteric low-precision fixed-point matrix operators, but it's never -quite- what you're looking for. My last Playstation title saw upward of fifteen hundred lines of tightly tuned assembly before all the special effects were up to 60fps again. The Lego Racers team have had an average of one and a half programmers tuning their rendering engine for over a year now. I think at this point they're assembly from the BSP traversal on down. Next project's Windows, Playstation 2 and FreeBSD/Linux internally at the least. I'm finally a happy camper. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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 17 7:42:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 143B9156C4 for ; Tue, 17 Aug 1999 07:42:24 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id JAA65622; Tue, 17 Aug 1999 09:42:09 -0500 (CDT) (envelope-from dan) Date: Tue, 17 Aug 1999 09:42:09 -0500 From: Dan Nelson To: "Alexey M. Zelkin" Cc: hackers@FreeBSD.ORG Subject: Re: bftp(1) Message-ID: <19990817094208.A65132@dan.emsphone.com> References: <199908171008.OAA02565@scorpion.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199908171008.OAA02565@scorpion.crimea.ua>; from "Alexey M. Zelkin" on Tue Aug 17 14:08:46 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Aug 17), Alexey M. Zelkin said: > Man page for telnetd(8) references to bftp(1) which will be installed > into /usr/ucb/bftp and of course does not exists. Can someone > describe in few words is this staff still supported ? If so, there > bftp(1) staff can be received/downloaded ? Otherwise I think it's > good idea to remove this staff from manpage and probably from source > code. I did an Altavista search for bftp and it looks like it's a background FTP client. Original source is at http://astro.temple.edu/~yxue , and a '97 paper re-implementing it is at http://renoir.vill.edu/~yhang . It looks like ports/ftp/ncftp3 has all the features of bftp (scheduled background transfers, auto-resume, multiple file xfers) except it doens't email the user then the transfer is done. -- Dan Nelson dnelson@emsphone.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 17 7:47:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 816661564F for ; Tue, 17 Aug 1999 07:47:05 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2448.0) id ; Tue, 17 Aug 1999 08:46:19 -0600 Message-ID: <64003B21ECCAD11185C500805F31EC0303786D2A@houston.matchlogic.com> From: Charles Randall To: freebsd-hackers@FreeBSD.ORG Subject: RE: Probably bug with allocation memory in FreeBSD-3.2-RELEASE Date: Tue, 17 Aug 1999 08:46:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The program in question does attempt to core dump when trying to fill the memory returned from malloc when malloc returns null. It almost seems like the attempt to dump core in an "out of swap" condition causes what seems like a machine hang (although you can still ping the machine). Charles -----Original Message----- From: Biju Susmer [mailto:bee@wipinfo.soft.net] Sent: Tuesday, August 17, 1999 3:25 AM Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: Probably bug with allocation memory in FreeBSD-3.2-RELEASE > > Well, yeah, that's becuase you're running it out of swap by trying to > allocate a gigabyte of memory. but this is done in steps of 1MB. Once it reaches out of memory, malloc should return NULL. Since there is no checking for NULL in this code, it should hit a signal, isn't it? Why that is not happening? -biju 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 17 7:49: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id BA97D14F1C for ; Tue, 17 Aug 1999 07:47:39 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id AAA71878; Wed, 18 Aug 1999 00:17:12 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908171447.AAA71878@gizmo.internode.com.au> Subject: Re: Probably bug with allocation memory in FreeBSD-3.2-RELEASE To: bee@wipinfo.soft.net Date: Wed, 18 Aug 1999 00:17:12 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <008801bee892$5703f920$88291fac@wipro.tcpn.com> from "Biju Susmer" at Aug 17, 99 02:54:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Biju Susmer wrote: > > Well, yeah, that's becuase you're running it out of swap by trying to > > allocate a gigabyte of memory. > > but this is done in steps of 1MB. Once it reaches out of memory, malloc > should return NULL. Since there is no checking for NULL in this code, > it should hit a signal, isn't it? Why that is not happening? We only had this thread a week ago. Please consult the archives. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 9:20:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 9B5BE1503B; Tue, 17 Aug 1999 09:20:27 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id JAA08787; Tue, 17 Aug 1999 09:20:29 -0700 (PDT) Date: Tue, 17 Aug 1999 09:20:29 -0700 (PDT) From: Bill Studenmund To: Michael Hancock Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Michael Hancock wrote: > As I recall most of FBSD's default routines are also error routines, if > the exceptions were a problem it would would be trivial to fix. > > I think fixing resource allocation/deallocation for things like vnodes, > cnbufs, and locks are a higher priority for now. There are examples such > as in detached threading where it might make sense for the detached child > to be responsible for releasing resources allocated to it by the parent, > but in stacking this model is very messy and unnatural. This is why the > purpose of VOP_ABORTOP appears to be to release cnbufs but this is really > just an ugly side effect. With stacking the code that allocates should be > the code that deallocates. Substitute, "code" with "layer" to be more > correct. > > I fixed a lot of the vnode and locking cases, unfortunately the ones that > remain are probably ugly cases where you have to reacquire locks that had > to be unlocked somewhere in the executing layer. See VOP_RENAME for an > example. Compare the number of WILLRELEs in vnode_if.src in FreeBSD and > NetBSD, ideally there'd be none. I've compared the two, and making the NetBSD number match the FreeBSD number is one of my goals. :-) Any suggestions, or just plod&fix? Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 9:32:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id AB6CF156D0 for ; Tue, 17 Aug 1999 09:32:39 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id MAA26304; Tue, 17 Aug 1999 12:31:21 -0400 (EDT) Date: Tue, 17 Aug 1999 12:31:21 -0400 (EDT) From: "Matthew N. Dodd" To: Mark Murray Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: <199908170912.LAA39046@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Mark Murray wrote: > > Who were the parties that were heading up the Kerberos 5 integration? > > > > I have questions. > > Me. > > I will be bringiong in Heimdal (when it interoperates with MIT-K5). What do you think about moving all the current '#ifdef KERBEROS' to '#ifdef KERBEROS4' and starting to integrate the '#ifdef KERBEROS5' bits in ftp, telnet, rsh, rlogin etc? I don't see a reason to rip out the krb4 stuff and delay on the krb5 userland integration. Since the userland stuff doesn't involve actual crypto code I think we're pretty safe no? I'd also be interested in hearing reasons for or against putting the krb4 specific stuff (kinit, klist whatever) in /usr/krb4, and the krb5 bits in /usr/krb5. This would simplify the task of leaving krb4 in the tree. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 9:59:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 998E414F32; Tue, 17 Aug 1999 09:59:33 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.9.3/8.9.3) with SMTP id RAA18271; Tue, 17 Aug 1999 17:00:02 GMT Date: Wed, 18 Aug 1999 02:00:02 +0900 (JST) From: Michael Hancock To: Bill Studenmund Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Bill Studenmund wrote: > I've compared the two, and making the NetBSD number match the FreeBSD > number is one of my goals. :-) > > Any suggestions, or just plod&fix? It can be very cumbersome tracking down references being bumped by vref/VREF and other operations. Among the uncompleted operations are VOPs that pre-release the returned vpp to the caller. I think in VOP_MKNOD this was done as a convenience and you might have to add code to handle device vp aliases correctly. Just remember the rule, the allocating layer must be the layer that deallocates. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10: 8:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 2862714F32 for ; Tue, 17 Aug 1999 10:08:45 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA56086; Tue, 17 Aug 1999 13:07:05 -0400 (EDT) Message-Id: <199908171707.NAA56086@cs.rpi.edu> To: "Matthew N. Dodd" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Kerberos 5 integration. In-Reply-To: Message from "Matthew N. Dodd" of "Tue, 17 Aug 1999 12:31:21 EDT." Date: Tue, 17 Aug 1999 13:07:05 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I offered (to Theo T'So) before our (Computer Science Department at RPI) resources to setup a RO CVS repo for Kerberos V. He accepted out offer but things stagnated after that on setting up the details. My fault mostly for not taking the tourch that has been passed. I am [now] offering again, and I think we can do it. If someone can contact me we can get this setup ASAP. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 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 Tue Aug 17 10:10: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id E183215640 for ; Tue, 17 Aug 1999 10:10:00 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id NAA26767; Tue, 17 Aug 1999 13:08:56 -0400 (EDT) Date: Tue, 17 Aug 1999 13:08:56 -0400 (EDT) From: "Matthew N. Dodd" To: "David E. Cross" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: <199908171707.NAA56086@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, David E. Cross wrote: > I offered (to Theo T'So) before our (Computer Science Department at > RPI) resources to setup a RO CVS repo for Kerberos V. He accepted out > offer but things stagnated after that on setting up the details. My > fault mostly for not taking the tourch that has been passed. I am > [now] offering again, and I think we can do it. If someone can > contact me we can get this setup ASAP. Maybe I'm a little slow here but what purpose would this serve? The changes I'm proposing can be carried out on -current with no problems. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10:15:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 3557C1571B for ; Tue, 17 Aug 1999 10:15:46 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA56225; Tue, 17 Aug 1999 13:14:11 -0400 (EDT) Message-Id: <199908171714.NAA56225@cs.rpi.edu> To: "David E. Cross" Cc: "Matthew N. Dodd" , Mark Murray , freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Kerberos 5 integration. In-Reply-To: Message from "David E. Cross" of "Tue, 17 Aug 1999 13:07:05 EDT." <199908171707.NAA56086@cs.rpi.edu> Date: Tue, 17 Aug 1999 13:14:10 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am terribly sorry. I had 2 messages about kerboers5 come in at the same time (one from -hackers, one from mit), I replied to to wrong one. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 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 Tue Aug 17 10:29:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 5B4D1156E1 for ; Tue, 17 Aug 1999 10:27:35 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id TAA82893; Tue, 17 Aug 1999 19:20:33 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Tue, 17 Aug 1999 19:20:33 +0200 (CEST) From: Leif Neland To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vnc on nat-proxy/firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The main problem is to get past the firewall. On Mon, 16 Aug 1999, Julian Elischer wrote: > vnc is cool, but also check out back-orafice > (not sure where you get it but the new one can take over NT as well as > W95) > > > On Tue, 17 Aug 1999, Leif Neland wrote: > > > I need to remote-control an NT behind a unix-box running > > nat-proxy/firewall/gateway. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10:33:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 370121571B for ; Tue, 17 Aug 1999 10:33:46 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA41154; Tue, 17 Aug 1999 19:30:57 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908171730.TAA41154@gratis.grondar.za> To: "Matthew N. Dodd" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. Date: Tue, 17 Aug 1999 19:30:56 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What do you think about moving all the current '#ifdef KERBEROS' to > '#ifdef KERBEROS4' and starting to integrate the '#ifdef KERBEROS5' bits > in ftp, telnet, rsh, rlogin etc? I don't see a reason to rip out the krb4 > stuff and delay on the krb5 userland integration. Since the userland > stuff doesn't involve actual crypto code I think we're pretty safe no? I have a better idea; PAM-ify everything (that can be pammed). The rest of the stuff, I intend to do as you say. > I'd also be interested in hearing reasons for or against putting the krb4 > specific stuff (kinit, klist whatever) in /usr/krb4, and the krb5 bits in > /usr/krb5. This would simplify the task of leaving krb4 in the tree. Hmm. Methinks I might name the version-specific stuff k[45]${FOO} for FOO in init, list, destroy, etc. Telnetd and FTPD should be PAMmable, likewise the r.*d's. The userland ftp and telnets can have both (Isuspect), and the r-utils also. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 17 10:34: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 78FBE15758 for ; Tue, 17 Aug 1999 10:33:55 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id NAA27123; Tue, 17 Aug 1999 13:31:29 -0400 (EDT) Date: Tue, 17 Aug 1999 13:31:26 -0400 (EDT) From: "Matthew N. Dodd" To: "David E. Cross" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: <199908171714.NAA56225@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, David E. Cross wrote: > I am terribly sorry. I had 2 messages about kerboers5 come in at the same > time (one from -hackers, one from mit), I replied to to wrong one. Ah. Had me terribly confused. :) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10:40:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 99D6315689 for ; Tue, 17 Aug 1999 10:40:03 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id NAA27199; Tue, 17 Aug 1999 13:38:45 -0400 (EDT) Date: Tue, 17 Aug 1999 13:38:45 -0400 (EDT) From: "Matthew N. Dodd" To: Mark Murray Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: <199908171730.TAA41154@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Mark Murray wrote: > I have a better idea; PAM-ify everything (that can be pammed). The rest > of the stuff, I intend to do as you say. Hummm... That might be the way to go... I'm not that familliar with PAM though. This would be nice since it would let us rip all the cruft out of everything and keep it in one place. I'm pretty sure there is a kerberos5 pam module floating around somewhere... > > I'd also be interested in hearing reasons for or against putting the krb4 > > specific stuff (kinit, klist whatever) in /usr/krb4, and the krb5 bits in > > /usr/krb5. This would simplify the task of leaving krb4 in the tree. > > Hmm. Methinks I might name the version-specific stuff k[45]${FOO} > for FOO in init, list, destroy, etc. Telnetd and FTPD should be > PAMmable, likewise the r.*d's. The userland ftp and telnets can > have both (Isuspect), and the r-utils also. Indeed. What is holding back the work in the userland stuff then? Time? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10:46: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 9FCD514EBB for ; Tue, 17 Aug 1999 10:45:52 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA41357; Tue, 17 Aug 1999 19:44:45 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908171744.TAA41357@gratis.grondar.za> To: "Matthew N. Dodd" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. Date: Tue, 17 Aug 1999 19:44:45 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What is holding back the work in the userland stuff then? Time? No; the lack thereof ;-) The current rush of things crypto has piqued my interest, so I am hammering away quite hard these days. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 17 10:49:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id D52FC1570E for ; Tue, 17 Aug 1999 10:49:37 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id NAA27383; Tue, 17 Aug 1999 13:49:58 -0400 (EDT) Date: Tue, 17 Aug 1999 13:49:58 -0400 (EDT) From: "Matthew N. Dodd" To: Mark Murray Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: <199908171744.TAA41357@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Mark Murray wrote: > > What is holding back the work in the userland stuff then? Time? > > No; the lack thereof ;-) > > The current rush of things crypto has piqued my interest, so I am > hammering away quite hard these days. Well, would it be useful for me to commit the KERBEROS -> KERBEROS4 changes? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 10:53: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id D03A114EBB for ; Tue, 17 Aug 1999 10:52:49 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA41479; Tue, 17 Aug 1999 19:52:39 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908171752.TAA41479@gratis.grondar.za> To: "Matthew N. Dodd" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. Date: Tue, 17 Aug 1999 19:52:39 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The current rush of things crypto has piqued my interest, so I am > > hammering away quite hard these days. > > Well, would it be useful for me to commit the KERBEROS -> KERBEROS4 > changes? Er, no; please submit them to me as patches. :-) Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 17 12:26:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id A4B2D155EE for ; Tue, 17 Aug 1999 12:26:29 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id MAA04640; Tue, 17 Aug 1999 12:26:09 -0700 (PDT) From: Archie Cobbs Message-Id: <199908171926.MAA04640@bubba.whistle.com> Subject: Re: Unsafe code in libc in 3.0-RELEASE FreeBSD i386 In-Reply-To: from Dag-Erling Smorgrav at "Aug 11, 1999 05:23:33 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Tue, 17 Aug 1999 12:26:09 -0700 (PDT) Cc: igusarov@chat.ru (Igor Gousarov), freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Archie Cobbs writes: > > Igor Gousarov writes: > > > The source file for setlocale function (/usr/src/lib/libc/locale/setlocale.c) > > > contains the line which might put libc into infinite loop: > > > [...] > > Please file a PR to make sure that this doesn't "slip through > > the cracks"... > > It seems to have slipped through the cracks. Good thing I had a > process mark on this message. What do you think of the attached patch > (against -CURRENT)? > > I think there's still a possibility of new_categories being overrun, > since there's no bounds checking on i in the do ... while (*locale) > loop. I suggest that a careful audit by somebody who knows this code > (or at least knows what it's supposed to do). Sorry for the late reply.. I think I understand what that do { } while loop is trying to do. Basically, LC_ALL can either be a single locale, in which case all categories should get that locale, or else several locales all separated by slashes, in which case consecutive categories get the respective locales. I've re-written your patch and simplified it a bit. Let me know what you think (ie, please review). Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: setlocale.c =================================================================== RCS file: /home/ncvs/src/lib/libc/locale/setlocale.c,v retrieving revision 1.23 diff -u -r1.23 setlocale.c --- setlocale.c 1998/04/29 22:39:56 1.23 +++ setlocale.c 1999/08/17 19:23:31 @@ -105,8 +105,8 @@ int category; const char *locale; { - int i, j, len; - char *env, *r; + int i, j; + char *env; if (category < LC_ALL || category >= _LC_LAST) return (NULL); @@ -150,32 +150,26 @@ (void)strncpy(new_categories[category], locale, ENCODING_LEN); new_categories[category][ENCODING_LEN] = '\0'; } else { - if ((r = strchr(locale, '/')) == NULL) { - for (i = 1; i < _LC_LAST; ++i) { - (void)strncpy(new_categories[i], locale, ENCODING_LEN); - new_categories[i][ENCODING_LEN] = '\0'; - } - } else { - for (i = 1; r[1] == '/'; ++r); - if (!r[1]) - return (NULL); /* Hmm, just slashes... */ - do { - len = r - locale > ENCODING_LEN ? ENCODING_LEN : r - locale; - (void)strncpy(new_categories[i], locale, len); - new_categories[i][len] = '\0'; - i++; - locale = r; - while (*locale == '/') - ++locale; - while (*++r && *r != '/'); - } while (*locale); - while (i < _LC_LAST) - (void)strcpy(new_categories[i], - new_categories[i-1]); + char *s, buf[(_LC_LAST - 1) * (ENCODING_LEN + 1)]; + + /* Parse out setting(s) separated by slashes */ + buf[sizeof(buf) - 1] = '\0'; + (void)strncpy(buf, locale, sizeof(buf)); + if (buf[sizeof(buf) - 1] != '\0') + return (NULL); /* arg(s) too long */ + for (i = 1, s = strtok(buf, "/"); + i < _LC_LAST && s != NULL; + ++i, s = strtok(NULL, "/")) { + (void)strncpy(new_categories[i], s, ENCODING_LEN); + new_categories[i][ENCODING_LEN] = '\0'; } + + /* Copy last setting for all remaining categories */ + for (; i < _LC_LAST; i++) + (void)strcpy(new_categories[i], new_categories[i - 1]); } - if (category) + if (category != LC_ALL) return (loadlocale(category)); for (i = 1; i < _LC_LAST; ++i) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 12:44: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 27B7F14EA8 for ; Tue, 17 Aug 1999 12:44:01 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id MAA66188; Tue, 17 Aug 1999 12:35:29 -0700 (PDT) Date: Tue, 17 Aug 1999 12:36:35 -0700 (PDT) From: Julian Elischer To: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vnc on nat-proxy/firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG going in or going out? (draw picture) On Tue, 17 Aug 1999, Leif Neland wrote: > The main problem is to get past the firewall. > > On Mon, 16 Aug 1999, Julian Elischer wrote: > > > vnc is cool, but also check out back-orafice > > (not sure where you get it but the new one can take over NT as well as > > W95) > > > > > > On Tue, 17 Aug 1999, Leif Neland wrote: > > > > > I need to remote-control an NT behind a unix-box running > > > nat-proxy/firewall/gateway. > > > > > > > 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 17 13: 2:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id DD5CC14DC1 for ; Tue, 17 Aug 1999 13:02:08 -0700 (PDT) (envelope-from kwchen@dnrc.bell-labs.com) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Aug 17 16:01:14 EDT 1999 Received: from blacktip.dnrc.bell-labs.com (blacktip [135.180.144.173]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA16559 for ; Tue, 17 Aug 1999 16:01:42 -0400 (EDT) From: Kuo Wei H Chen Received: (from kwchen@localhost) by blacktip.dnrc.bell-labs.com (8.9.3/8.9.3) id QAA12350 for freebsd-hackers@freebsd.org; Tue, 17 Aug 1999 16:01:44 -0400 (EDT) Date: Tue, 17 Aug 1999 16:01:44 -0400 (EDT) Message-Id: <199908172001.QAA12350@blacktip.dnrc.bell-labs.com> To: freebsd-hackers@freebsd.org Subject: profiling FreeBSD kernel Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To enable kernel profiling on FreeBSD Rel 3.2, I did the following, (according to a posting by Bruce Evans on 9/11/1996): config -p make clean make depend make But I got link errors on several files: mcount.o: multiple def. of mcount prof_machdep.o: first defined here (????) device_if.o: many undefined reference to mcount exception.o: undefined reference to _btrap and _bintr i386-gdbstub.o: many undefined reference to mcount prof_machdep.o: undefined reference to mcount, __gmonparam psm.o: many undefined reference to mcount Did I miss any steps? Thanks for the help. K. Herman Chen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 13: 3:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mobil.surnet.ru (mobil.surnet.ru [195.54.2.7]) by hub.freebsd.org (Postfix) with ESMTP id 80B28157A3 for ; Tue, 17 Aug 1999 13:03:08 -0700 (PDT) (envelope-from ilia@cgilh.chel.su) Received: (from uucgilh@localhost) by mobil.surnet.ru (8.9.1a/8.9.1) with UUCP id BAA02216; Wed, 18 Aug 1999 01:56:20 +0600 (UDT) Received: (from uucp@localhost) by cgilh.chel.su (8.8.7/8.8.7) with UUCP id BAA01329; Wed, 18 Aug 1999 01:25:56 +0600 Received: from localhost (ilia@localhost) by localhost.cgu.chel.su (8.9.2/8.9.2) with ESMTP id BAA01673; Wed, 18 Aug 1999 01:24:53 +0600 (ESS) (envelope-from ilia@cgilh.chel.su) X-Authentication-Warning: localhost.cgu.chel.su: ilia owned process doing -bs Date: Wed, 18 Aug 1999 01:24:53 +0600 (ESS) From: Ilia Chipitsine X-Sender: ilia@localhost.cgu.chel.su To: Alec Kalinin Cc: Mark Newton , Oleg Derevenetz , freebsd-hackers@FreeBSD.ORG Subject: Re: Probably bug with allocation memory in FreeBSD-3.2-RELEASE In-Reply-To: <027401bee88f$2e503b90$a34562c3@alec.relex.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Alec Kalinin wrote: > > > Why i think this is bug? Because any user can hung FreeBSD, settings in > > > /etc/login.conf can't help. > > >Are you sure about that? Setting datasize limits will prevent > >malloc() from doing what you're trying to make it do. Are you > >sure you're setting your login.conf settings properly? > guys, just a silly question ! how dod you think login.conf works with xdm ?! right ! xdm simply ignores it ... > > I am sure, that setting limits in "/etc/login.conf" is not good decision. I > try to explain. > > First of all, if i set limits more than swap space, one user can hung > system. But, if i set limit equal half swap space, two different users can > hung system. > > Than, i don't set limits for root process. And combinantion "squid + > Netscape with java applet" from root may hung system. > > While 3.2-system can't simply kill this process like 2.2.8-system? I think, > killing this process -- best solution. > > Good luck, > Alec. > > > > 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 17 13:45:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B68E4157FE; Tue, 17 Aug 1999 13:44:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A87061CD8A2; Tue, 17 Aug 1999 13:44:44 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Tue, 17 Aug 1999 13:44:44 -0700 (PDT) From: Kris Kennaway To: "Matthew N. Dodd" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Matthew N. Dodd wrote: > I'm pretty sure there is a kerberos5 pam module floating around > somewhere... ftp://ftp.dementia.org/pub/pam/ http://www-personal.engin.umich.edu/~itoi/ Both referenced from http://www.us.kernel.org/pub/linux/libs/pam/modules.html Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 13:45:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id CDD94157FD; Tue, 17 Aug 1999 13:44:24 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id NAA27035; Tue, 17 Aug 1999 13:44:34 -0700 (PDT) Date: Tue, 17 Aug 1999 13:44:34 -0700 (PDT) From: Bill Studenmund Reply-To: Bill Studenmund To: Terry Lambert Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908170231.TAA08526@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Terry Lambert wrote: > > > > > 2. Advisory locks are hung off private backing objects. > > I'm not sure. The struct lock * is only used by layered filesystems, so > > they can keep track both of the underlying vnode lock, and if needed their > > own vnode lock. For advisory locks, would we want to keep track both of > > locks on our layer and the layer below? Don't we want either one or the > > other? i.e. layers bypass to the one below, or deal with it all > > themselves. > > I think you want the lock on the intermediate layer: basically, on > every vnode that has data associated with it that is unique to a > layer. Let's not forget, also, that you can expose a layer into > the namespace in one place, and expose it covered under another > layer, at another. If you locked down to the backing object, then > the only issue you would be left with is one or more intermediate > backing objects. Right. That exported struct lock * makes locking down to the lowest-level file easy - you just feed it to the lock manager, and you're locking the same lock the lowest level fs uses. You then lock all vnodes stacked over this one at the same time. Otherwise, you just call VOP_LOCK below and then lock yourself. > For a layer with an intermediate backing object, I'm prepared to > declare it "special", and proxy the operation down to any inferior > backing object (e.g. a union FS that adds files from two FS's > together, rather than just directoriy entry lists). I think such > layers are the exception, not the rule. Actually isn't the only problem when you have vnode fan-in (union FS)? i.e. a plain compressing layer should not introduce vnode locking problems. > I think that export policies are the realm of /etc/exports. > > The problem with each FS implementing its own policy, is that this > is another place that copyinstr() gets called, when it shouldn't. Well, my thought was that, like with current code, most every fs would just call vfs_export() when it's presented an export operation. But by retaining the option of having the fs do its own thing, we can support different export semantics if desired. > Right. The "covering" operation is not the same as the "marking as > covered" operation. Both need to be at the higher level. > Not really. Julian Elisher had code that mounted a /devfs under > / automatically, before the user was ever allowed to see /. As a > result, the FS that you were left with was indistinguishable from > what I describe. > > The only real difference is that, as a translucent mount over /devfs, > the one I describe would be capable of implementing persistant changes > to the /devfs, as whiteouts. I don't think this is really that > desirable, but some people won't accept a devfs that doesn't have > traditional persistance semantics (e.g. "chmod" vs. modifying a > well known kernel data structure as an administrative operation). That wouldn't be hard to do. :-) > I guess the other difference is that you don't have to worry about > large minor numbers when you are bringing up a new platform via > NFS from an old platform that can't support large minors in its FS > at all. ;-). True. :-) > I would resolve this by passing a standard option to the mount code > in user space. For root mounts, a vnode is passed down. For other > mounts, the vnode is parsed and passed if the option is specified. Or maybe add a field to vfsops. This info says what the mount call will expect (I want a block device, a regular file, a directory, etc), so it fits. :-) Also, if we leave it to userland, what happens if someone writes a program which calls sys_mount with something the fs doesn't expect. :-) > I think that you will only be able to find rare examples of FS's > that don't take device names as arguments. But for those, you > don't specify the option, and it gets "NULL", and whatever local > options you specify. I agree I can't see a leaf fs not taking a device node. But layered fs's certainly will want something else. :-) > The point is that, for FS's that can be both root and sub-root, > the mount code doesn't have to make the decision, it can be punted > to higher level code, in one place, where the code can be centrally > maintained and kept from getting "stale" when things change out > from under it. True. And with good comments we can catch the times when the centrally located code changes & brakes an assumption made by the fs. :-) > > Except for a minor buglet with device nodes, stacking works in NetBSD at > > present. :-) > > Have you tried Heidemann's student's stacking layers? There is one > encryption, and one per-file compression with namespace hiding, that > I think it would be hard pressed to keep up with. But I'll give it > the benefit of the doubt. 8-). Nope. The problem is that while stacking (null, umap, and overlay fs's) work, we don't have the coherency issues worked out so that upper layers can cache data. i.e. so that the lower fs knows it has to ask the uper layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > I agree it's ugly, but it has the advantage that it doesn't grow the > > on-disk inode. A lot of flks have designs on the remaining 64 bits free. > > :-) > > Well, so long as we can resolve the issue for a long, long time; > I plan on being around to have to put up with the bugs, if I can > wrangle it... 8-). :-) I bet by then (559447 AD) we won't be using ffs, so the problem will be moot. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 14: 6:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (Postfix) with ESMTP id AD45B157DF; Tue, 17 Aug 1999 14:06:01 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.9.3/8.9.3) with SMTP id VAA18756; Tue, 17 Aug 1999 21:05:08 GMT Date: Wed, 18 Aug 1999 06:05:08 +0900 (JST) From: Michael Hancock To: Bill Studenmund Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Have you tried Heidemann's student's stacking layers? There is one > > encryption, and one per-file compression with namespace hiding, that > > I think it would be hard pressed to keep up with. But I'll give it > > the benefit of the doubt. 8-). > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > work, we don't have the coherency issues worked out so that upper layers > can cache data. i.e. so that the lower fs knows it has to ask the uper > layers to give pages back. :-) But multiple ls -lR's work fine. :-) Interesting, have you read the Heidemann paper that outlines a solution that uses a cache manager? You can probably find it somewhere here, http://www.isi.edu/~johnh/SOFTWARE/UCLA_STACKING/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 14:12:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 736DA157F4; Tue, 17 Aug 1999 14:12:11 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id OAA29074; Tue, 17 Aug 1999 14:12:22 -0700 (PDT) Date: Tue, 17 Aug 1999 14:12:22 -0700 (PDT) From: Bill Studenmund To: Michael Hancock Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Michael Hancock wrote: > Interesting, have you read the Heidemann paper that outlines a solution > that uses a cache manager? > > You can probably find it somewhere here, > http://www.isi.edu/~johnh/SOFTWARE/UCLA_STACKING/ Nope. I've read his dissertation, and his discussion of the lock management inspired the struct lock * work I did for NetBSD (we use the address of the lock, not the vnode, but other than that it's the same). Thanks for the ref! Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 14:17:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 1E41115818; Tue, 17 Aug 1999 14:17:12 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.9.3/8.9.3) with SMTP id VAA18787; Tue, 17 Aug 1999 21:14:47 GMT Date: Wed, 18 Aug 1999 06:14:47 +0900 (JST) From: Michael Hancock To: Bill Studenmund Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I forgot I had some old diffs that may be of help, http://www.freebsd.org/~mch/vop1a.diff You'll notice that just about everywhere that I moved vput() to the appropriate layer a path component buffer was also freed in the wrong place. John Dyson put these buffers in zones so the free routine probably looks very different than in netbsd. zfree(namei_zone, cnp->cn_pnbuf); - vput(dvp); Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 14:49:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 17C23157F3; Tue, 17 Aug 1999 14:49:39 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id OAA15932; Tue, 17 Aug 1999 14:48:45 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id OAA21621; Tue, 17 Aug 1999 14:48:44 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id OAA02073; Tue, 17 Aug 1999 14:48:39 -0700 (PDT) From: Don Lewis Message-Id: <199908172148.OAA02073@salsa.gv.tsc.tdk.com> Date: Tue, 17 Aug 1999 14:48:39 -0700 In-Reply-To: Terry Lambert "Re: BSD XFS Port & BSD VFS Rewrite" (Aug 16, 9:18pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , wrstuden@nas.nasa.gov Subject: Re: BSD XFS Port & BSD VFS Rewrite Cc: Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Aug 16, 9:18pm, Terry Lambert wrote: } Subject: Re: BSD XFS Port & BSD VFS Rewrite } > I don't see how the namei recursion method prevents catching // as a } > namespace escape. } } } //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork } } You can't inherit the fact that you are looking at the resource fork } in the terminal component, ONLY. I don't think this is a good example. How would you access the resource fork of a file relative to the current directory? IMHO, the necessary goop needs to go at the end of the path name. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 14:53:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 514F2157FF; Tue, 17 Aug 1999 14:53:30 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id RAA01181; Tue, 17 Aug 1999 17:53:58 -0400 (EDT) Date: Tue, 17 Aug 1999 17:53:57 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kennaway Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Kris Kennaway wrote: > On Tue, 17 Aug 1999, Matthew N. Dodd wrote: > > I'm pretty sure there is a kerberos5 pam module floating around > > somewhere... > > ftp://ftp.dementia.org/pub/pam/ > http://www-personal.engin.umich.edu/~itoi/ > > Both referenced from > http://www.us.kernel.org/pub/linux/libs/pam/modules.html Already found that. :) I'm still a bit confused about PAM though. While it is possible to do what kinit does and verify a password, the real reason we like kerberos is because we don't have to enter passwords; we get a ticket and the server verifies that the ticket is valid. How exactly does this fit in the PAM model? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 15:46:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0B11F14CC7; Tue, 17 Aug 1999 15:46:48 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA13293; Tue, 17 Aug 1999 15:44:35 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA13692; Tue, 17 Aug 1999 15:38:34 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA27793; Tue, 17 Aug 1999 16:44:30 -0600 Message-ID: <37B9E5CE.8E7B8AFD@softweyr.com> Date: Tue, 17 Aug 1999 16:44:30 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: Terry Lambert , wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite References: <199908172148.OAA02073@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don Lewis wrote: > > On Aug 16, 9:18pm, Terry Lambert wrote: > } Subject: Re: BSD XFS Port & BSD VFS Rewrite > > } > I don't see how the namei recursion method prevents catching // as a > } > namespace escape. > } > } > } //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork > } > } You can't inherit the fact that you are looking at the resource fork > } in the terminal component, ONLY. > > I don't think this is a good example. How would you access the resource > fork of a file relative to the current directory? IMHO, the necessary > goop needs to go at the end of the path name. Pick a separator character that nobody in their right mind would use in a file path. "\" strikes me as a good candidate. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 17 16: 0: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 3E3F414D87 for ; Tue, 17 Aug 1999 15:59:53 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id BAA49584; Wed, 18 Aug 1999 01:00:13 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Wed, 18 Aug 1999 01:00:12 +0200 (CEST) From: Leif Neland To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vnc on nat-proxy/firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Julian Elischer wrote: > going in or going out? > > (draw picture) vnc server +----+ +---+ NT | +-------------+ +-----+ ISDN +--------------+ | +----+ | Vnc client |---+--| RAS |-----Z----| NAT/Firewall |---| +-------------+ | +-----+ +--------------+ | +----+ | +---+ PC | Internet | +----+ Private Lan > > > > I need to remote-control an NT behind a unix-box running > > > > nat-proxy/firewall/gateway. > > > > Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 16:22:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B321B15860; Tue, 17 Aug 1999 16:22:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A54A41CD8A8; Tue, 17 Aug 1999 16:22:21 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Tue, 17 Aug 1999 16:22:21 -0700 (PDT) From: Kris Kennaway To: "Matthew N. Dodd" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Matthew N. Dodd wrote: > I'm still a bit confused about PAM though. While it is possible to do > what kinit does and verify a password, the real reason we like kerberos is > because we don't have to enter passwords; we get a ticket and the server > verifies that the ticket is valid. How exactly does this fit in the PAM > model? At a guess, it is given your username, obtains the ticket from wherever that is stored locally and goes off and verifies it against the server. If the server comes back affirmative, it grants you access. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 16:29:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id A1C081585B; Tue, 17 Aug 1999 16:29:25 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id TAA02596; Tue, 17 Aug 1999 19:29:56 -0400 (EDT) Date: Tue, 17 Aug 1999 19:29:56 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kennaway Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Kris Kennaway wrote: > At a guess, it is given your username, obtains the ticket from wherever > that is stored locally and goes off and verifies it against the server. If > the server comes back affirmative, it grants you access. Which is the problem if you're say, using ftp to a remote system right? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 16:32:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 020B915879; Tue, 17 Aug 1999 16:32:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E36811CD8A8; Tue, 17 Aug 1999 16:32:18 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Tue, 17 Aug 1999 16:32:18 -0700 (PDT) From: Kris Kennaway To: "Matthew N. Dodd" Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Matthew N. Dodd wrote: > > At a guess, it is given your username, obtains the ticket from wherever > > that is stored locally and goes off and verifies it against the server. If > > the server comes back affirmative, it grants you access. > > Which is the problem if you're say, using ftp to a remote system right? In the non-PAM world, how would the ticket get from the client to the FTP server? Some kind of subchannel? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 16:40: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id C1BDD14C83; Tue, 17 Aug 1999 16:39:53 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id TAA02737; Tue, 17 Aug 1999 19:39:25 -0400 (EDT) Date: Tue, 17 Aug 1999 19:39:23 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kennaway Cc: Mark Murray , freebsd-hackers@FreeBSD.ORG Subject: Re: Kerberos 5 integration. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Kris Kennaway wrote: > > Which is the problem if you're say, using ftp to a remote system right? > > In the non-PAM world, how would the ticket get from the client to the FTP > server? Some kind of subchannel? With FTP, one uses GSSAPI. With telnet/rlogin/rsh authentication is negotiated in such a way that it is possible for the client to say "Hey, we want to give you a kerberos ticket to authenticate ourselves." The server replies with something like "Sure, let me have it." or "Kerberos?", or "Yea, but only if you promise to give me a Kerberos 5 ticket." or smething like that. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 16:51:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id C09BB14F31; Tue, 17 Aug 1999 16:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 989851CD8A8; Tue, 17 Aug 1999 16:51:34 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Tue, 17 Aug 1999 16:51:34 -0700 (PDT) From: Kris Kennaway To: Marc Nicholas Cc: Andrzej Bialecki , freebsd-hackers@FreeBSD.ORG Subject: Re: Saving system image to disk (NOT on a laptop) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Marc Nicholas wrote: > Wasn't there already a project that did this??? The project name escapes > me, but I believe it was linked from the FreeBSD Projects page... Maybe you're thinking of the RIO project (RAM I/O): http://www.eecs.umich.edu/Rio/ Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 17:42: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from medulla.hippocampus.net (medulla.hippocampus.net [204.138.241.6]) by hub.freebsd.org (Postfix) with ESMTP id 2542E14EA8; Tue, 17 Aug 1999 17:41:55 -0700 (PDT) (envelope-from marc@netstor.com) Received: from localhost (marc@localhost) by medulla.hippocampus.net (8.9.2/8.9.2) with ESMTP id UAA14650; Tue, 17 Aug 1999 20:48:07 -0400 (EDT) Date: Tue, 17 Aug 1999 20:48:07 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: Kris Kennaway Cc: Andrzej Bialecki , freebsd-hackers@FreeBSD.ORG Subject: Re: Saving system image to disk (NOT on a laptop) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yeah...I was thinking of RIO which isn't 100% what Andrzej wanted...but maybe a step in the right direction? -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com "Fast, Expandable and Affordable Internet Caching Products" 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 On Tue, 17 Aug 1999, Kris Kennaway wrote: > On Tue, 17 Aug 1999, Marc Nicholas wrote: > > > Wasn't there already a project that did this??? The project name escapes > > me, but I believe it was linked from the FreeBSD Projects page... > > Maybe you're thinking of the RIO project (RAM I/O): > http://www.eecs.umich.edu/Rio/ > > Kris > > > > 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 17 18:29:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6FAC514F3A for ; Tue, 17 Aug 1999 18:29:40 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA30116 for ; Tue, 17 Aug 1999 21:30:12 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Tue, 17 Aug 1999 21:30:30 -0400 To: hackers@FreeBSD.org From: Garance A Drosihn Subject: lpd security check for changed-file vs NFS Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lpr has the '-s' option that tells it to create a symlink to the file you want to print, instead of copying the file into the spool directory. As a security precaution, it does a 'stat' call on the file it links to, and saves away the device_id and file_number that it found. When lpd later goes to print the file, it also does a stat to make sure it's getting the same file that the user originally specified on lpr. (so the user can't play games and use lpr to print out a file they have no access to) Generally, this works fine. Last week we updated a few critical administration boxes to use the same lpr/lpd we use everywhere else. They are on an AIX box (as are many of our workstations), but they also happen to mount many directories via NFS from another AIX box (which happens just about nowhere else on campus). It turns out this symlink check does not seem to work on files serviced up from an AIX box working as an NFS server. This was super- critical-urgent-die-die-die, so my quick fix was to just change my version of lpd to ignore the error if the file in question was NFS-mounted. (I used fstatvfs to find that out). - - - That's the background -- now the hacker-type question. Is there some other check I could use to make sure the file has not changed, if the standard st_dev+st_ino check is not going to work? Seems to me I should be checking something, instead of just ignoring the issue for NFS mounts (*all* NFS mounts, because I can't tell if the NFS server is AIX). Maybe do some sort of MD5 checksum of the first thousand bytes of the file? Any other suggestions? --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 18:39:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D74C155D5 for ; Tue, 17 Aug 1999 18:39:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA41356; Tue, 17 Aug 1999 18:37:46 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Aug 1999 18:37:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199908180137.SAA41356@apollo.backplane.com> To: Garance A Drosihn Cc: hackers@FreeBSD.ORG Subject: Re: lpd security check for changed-file vs NFS References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :lpr has the '-s' option that tells it to create a symlink to :the file you want to print, instead of copying the file into :... :has not changed, if the standard st_dev+st_ino check is not :going to work? Seems to me I should be checking something, :instead of just ignoring the issue for NFS mounts (*all* :NFS mounts, because I can't tell if the NFS server is AIX). : :Maybe do some sort of MD5 checksum of the first thousand :bytes of the file? Any other suggestions? : :--- :Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu If you removed the stat test, I would simply get rid of the -s option entirely - require that all files be queued to the print spool. -Matt Matthew Dillon :Senior Systems Programmer or drosih@rpi.edu :Rensselaer Polytechnic Institute : : :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 17 19: 2:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id C0FFF1576B for ; Tue, 17 Aug 1999 19:02:20 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA06500; Tue, 17 Aug 1999 22:02:51 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199908180137.SAA41356@apollo.backplane.com> References: <199908180137.SAA41356@apollo.backplane.com> Date: Tue, 17 Aug 1999 22:03:09 -0400 To: Matthew Dillon From: Garance A Drosihn Subject: Re: lpd security check for changed-file vs NFS Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:37 PM -0700 8/17/99, Matthew Dillon wrote: > If you removed the stat test, I would simply get rid of the -s > option entirely - require that all files be queued to the print > spool. The administration would kill me. I would prefer to avoid that. (note that the check isn't completely removed, it's "only" nullified for NFS-mounted files. We use AFS for most things here, so the vast majority of the machines that I have to care about do not have any NFS files. The few that do are also limited-access machines. Still, I'd prefer a better check than nothing for those NFS files) Any advice on how to kick AIX so the st_dev+st_ino check will work right is also welcome. It baffles me why AIX does things the way it does. It kinda looks like the values it uses are pointers to some other info, and maybe *that* info is constant for a given file, but I haven't had the time to pursue that yet. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 19:19: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 8063E14CF6 for ; Tue, 17 Aug 1999 19:19:07 -0700 (PDT) (envelope-from wsanchez@scv1.apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id TAA62768 for ; Tue, 17 Aug 1999 19:19:12 -0700 Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Tue, 17 Aug 1999 19:17:50 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id TAA03970; Tue, 17 Aug 1999 19:17:49 -0700 (PDT) Message-Id: <199908180217.TAA03970@scv1.apple.com> To: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Need some advice regarding portable user IDs Cc: pwd@apple.com, warner.c@apple.com, umeshv@apple.com Date: Tue, 17 Aug 1999 19:17:45 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A group of us at Apple are trying to figure out how to handle situations where a filesystem with "foreign" user ID's are present. The basic problem is that the user experience using Unix semantics are not really pleasant. I think some examples would help: I'm working with Joe on a project, and I have some sources I want him to take a look at, so I mount a floppy disk. Well, that's a bad example, because floppies are "out"... So I mount a zip disk with UFS on it, and I copy my source tree onto it, and hand this to Joe. Joe takes the disk home, and sticks it in his computer, and he finds that he can't read the files, because I have a lamer umask, and as a bonus, I don't have an account on his machine, so the files are owned by some random UID. I think the desired behaviour would be that since this is effectively now Joe's zip disk, he should be able to do as he pleases. One proposal might be to give the console user the equivalent of root's priveledges on any removeable media he inserts into the machine while he's logged in on the console. This solves the immediate problem of permissions for Joe, since the file owners are, on his machine and in this situation, largely irrelevant. Presumably the console user is the one fiddling with the external media. As another example, a similar situation often comes up on the net with tar files containing UIDs and GIDs other than zero. One problem with my proposal (setting security and perhaps other implications aside for the moment), is that knowing what media is removeable is becoming increasingly difficult. Hot-swappable drives (eg. FireWire) are effectively removeable, and may be transported between machines fairly regularly. Furthermore, your "internal" drives, which are presently presumed to be local, may be on the same bus and indistinguishable from the "external" drives. So perhaps there needs to be a way to mark a drive as local (perhaps with a host ID of some sort?) and noticing when a volume is "foreign" that you need to do something special. Certainly you might want to ignore setuid bits, for starters. This could simply be something like fstab, which lists the local drives, and everything else isn't considered local. But then the question is, how do we want to deal with non-local filesystems? The ideal thing would be to have a way to transport user information with the filesystem (eg. uids on disk are mapped to system uids via a per-filesystem database with more global IDs like email addresses), but that could be expensive. Am I spewing babel? :-) Has anyone dived into this area already and have some experience with it? It's confusing me pretty good. Thanks, -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 19:35: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 7346614E73 for ; Tue, 17 Aug 1999 19:34:54 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA26487; Wed, 18 Aug 1999 12:04:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818120428:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180217.TAA03970@scv1.apple.com> Date: Wed, 18 Aug 1999 12:04:28 +0930 (CST) From: "Daniel O'Connor" To: Wilfredo Sanchez Subject: RE: Need some advice regarding portable user IDs Cc: umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818120428:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Wilfredo Sanchez wrote: > I think the desired behaviour would be that since this is > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves > the immediate problem of permissions for Joe, since the file owners > are, on his machine and in this situation, largely irrelevant. > Presumably the console user is the one fiddling with the external > media. How about just adding some flags to mount and modifying UFS so that you can override the uid/gid on mount.. I assume you mean Joe uses something like sudo so he can mount the disk.. So allow users to use the fancy new mount command (with certain limitations on the mountable device node of course...) > As another example, a similar situation often comes up on the net > with tar files containing UIDs and GIDs other than zero. Add an option to tar to override UID's and GID's.. Not that you can chown a file as non root anyway, but it IS annoying when you untar something as root to find the files are owned by some weird UID:GID. > One problem with my proposal (setting security and perhaps other > implications aside for the moment), is that knowing what media is > removeable is becoming increasingly difficult. Hot-swappable drives > (eg. FireWire) are effectively removeable, and may be transported > between machines fairly regularly. Furthermore, your "internal" > drives, which are presently presumed to be local, may be on the same > bus and indistinguishable from the "external" drives. And hot swappable internal drives don't help the distinction either :) > "foreign" that you need to do something special. Certainly you might > want to ignore setuid bits, for starters. This could simply be > something like fstab, which lists the local drives, and everything > else isn't considered local. Another mount option? You could have UID:GID override mount options, and you can already mount an FS and have the kernel ignore setuid. (-o nosuid, nodev, noexec(maybe)) You could even use umapfs (assuming it works) and write some nice shell scripts to do it automatically.. Alternativly you could just use MSDOSFS for all intermachine transfers, its crap, but everything reads it and you don't get those nasty UID:GID problems either ;) --- 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 --_=XFMail.1.3.p0.FreeBSD:990818120428:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7obtFbYW/HEoF9pAQFe8QP+Pjv/dDqkvueN9UZRUBiTZktVpIjwVsMl qCxVpjWazu6n0dyBK2Fr0wZs9mUe1WnxXvqvSI6W38wUNegfWYU3OAEaOpsZXfNP /9lPPQnkccwiDJYKj97HahIlVqWDx+9TGb0Ajx67sbzdBX7rIxOReJ7jDzJLFvTv /4ctMyFKwHU= =y33O -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818120428:5786=_-- End of MIME 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 17 19:38:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marvin.ece.utexas.edu (marvin.ece.utexas.edu [128.83.52.151]) by hub.freebsd.org (Postfix) with ESMTP id 21CD114C30 for ; Tue, 17 Aug 1999 19:38:47 -0700 (PDT) (envelope-from bgrayson@marvin.ece.utexas.edu) Received: (from bgrayson@localhost) by marvin.ece.utexas.edu (8.8.8/8.6.9) id VAA28713; Tue, 17 Aug 1999 21:37:19 -0500 (CDT) Message-ID: <19990817213718.A28662@marvin.ece.utexas.edu> Date: Tue, 17 Aug 1999 21:37:18 -0500 From: "Brian C. Grayson" To: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Cc: pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs References: <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199908180217.TAA03970@scv1.apple.com>; from Wilfredo Sanchez on Tue, Aug 17, 1999 at 07:17:45PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. (I don't know if this has already been mentioned -- it hasn't on tech-userlevel@netbsd.org, which is where I saw this.) Have you looked at mount_umap(8)? I (naively) think it would solve most of your concerns. ``The mount_umap command is used to mount a sub-tree of an existing file system that uses a different set of uids and gids than the local system. Such a file system could be mounted from a remote site via NFS or it could be a file system on removable media brought from some foreign loca- tion that uses a different password file.'' Brian Grayson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 19:46:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CD8814C33 for ; Tue, 17 Aug 1999 19:46:43 -0700 (PDT) (envelope-from wsanchez@scv3.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id TAA18942 for ; Tue, 17 Aug 1999 19:46:46 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 17 Aug 1999 19:46:42 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id TAA06434; Tue, 17 Aug 1999 19:46:40 -0700 Message-Id: <199908180246.TAA06434@scv3.apple.com> To: "Daniel O'Connor" Subject: Re: RE: Need some advice regarding portable user IDs Cc: umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199908180217.TAA03970@scv1.apple.com> Date: Tue, 17 Aug 1999 19:46:37 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | I assume you mean Joe uses something like sudo | so he can mount the disk.. Joe doesn't use the shell. The Finder will do this for him; when you insert a floppy in Mac OS, it gets mounted and shows up on your desktop. This is the case with all media. | So allow users to use the fancy new mount command (with certain limitations on | the mountable device node of course...) Yes, the fancy command is what the Finder does for him. Options are details, and not really interesting. The question is what should the behaviour be, and what's happening underneath the covers to support that? Are we mapping UID's to something meaningful? How? Or is Joe a superuser for that volume? Which volumes get treated this way, and how to you choose them? -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 19:58: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CBBA014DC4 for ; Tue, 17 Aug 1999 19:58:00 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA45585; Tue, 17 Aug 1999 20:55:40 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA00507; Tue, 17 Aug 1999 20:55:12 -0600 (MDT) Message-Id: <199908180255.UAA00507@harmony.village.org> To: "Daniel O'Connor" Subject: Re: Need some advice regarding portable user IDs Cc: Wilfredo Sanchez , umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org In-reply-to: Your message of "Wed, 18 Aug 1999 12:04:28 +0930." References: Date: Tue, 17 Aug 1999 20:55:12 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Daniel O'Connor" writes: : How about just adding some flags to mount and modifying UFS so that : you can override the uid/gid on mount.. I assume you mean Joe uses : something like sudo so he can mount the disk.. Doesn't umapfs do that? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 19:58:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 1F1E414E99 for ; Tue, 17 Aug 1999 19:58:05 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA26747; Wed, 18 Aug 1999 12:25:47 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818122546:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180246.TAA06434@scv3.apple.com> Date: Wed, 18 Aug 1999 12:25:47 +0930 (CST) From: "Daniel O'Connor" To: Wilfredo Sanchez Subject: Re: RE: Need some advice regarding portable user IDs Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818122546:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Wilfredo Sanchez wrote: > Joe doesn't use the shell. The Finder will do this for him; when > you insert a floppy in Mac OS, it gets mounted and shows up on your > desktop. This is the case with all media. Yes... Why is this a FreeBSD problem then? I would have thought it would be up to MacOS to do the UID remapping (I must be missing something) > support that? Are we mapping UID's to something meaningful? How? > Or is Joe a superuser for that volume? Which volumes get treated > this way, and how to you choose them? If you want proper username mapping shouldn't you be using a distributed user map (like NIS)? --- 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 --_=XFMail.1.3.p0.FreeBSD:990818122546:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7ogslbYW/HEoF9pAQFErAP/Y7sh82TgDUFqo0of45aUu0Ww+rELNd75 Q3C4V9L9qPTAZJfxMT7HKuJgOXMUWFkoPxmZQ+tywW6iG7YfmuQENNqkkAmu+yTY 7uXEeQgYDDKkTRm7lg6cfFYXNMB3u7dNHOFW7G27vFSuTFx6Bmmnwm1CKf3PUFRg S6qEFr+ooZQ= =RR8W -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818122546:5786=_-- End of MIME 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 17 20: 3:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 1929414DC4 for ; Tue, 17 Aug 1999 20:03:20 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id MAA75162; Wed, 18 Aug 1999 12:31:29 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908180301.MAA75162@gizmo.internode.com.au> Subject: Re: RE: Need some advice regarding portable user IDs To: doconnor@gsoft.com.au (Daniel O'Connor) Date: Wed, 18 Aug 1999 12:31:29 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Daniel O'Connor" at Aug 18, 99 12:25:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > On 18-Aug-99 Wilfredo Sanchez wrote: > > Joe doesn't use the shell. The Finder will do this for him; when > > you insert a floppy in Mac OS, it gets mounted and shows up on your > > desktop. This is the case with all media. > > Yes... Why is this a FreeBSD problem then? I would have thought it would > be up to MacOS to do the UID remapping (I must be missing something) "Think Different": The MacOS is BSD. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 20: 4:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 09D9914DC4 for ; Tue, 17 Aug 1999 20:04:30 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA26879; Wed, 18 Aug 1999 12:32:31 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818123231:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180255.UAA00507@harmony.village.org> Date: Wed, 18 Aug 1999 12:32:31 +0930 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: Need some advice regarding portable user IDs Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com, Wilfredo Sanchez Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818123231:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Warner Losh wrote: > : you can override the uid/gid on mount.. I assume you mean Joe uses > : something like sudo so he can mount the disk.. > Doesn't umapfs do that? Yes.. half way through reading the mail I realised and didn't re-edit it.. IMHO being abe to override UID:GID's would be useful in a normal mount because umapfs adds more complexity to work. (Though I can see that doing it in the various FS's would suck royally) --- 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 --_=XFMail.1.3.p0.FreeBSD:990818123231:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7oiR1bYW/HEoF9pAQEbaAQAogsSYIsP5EUggyeodO6kl2hycoTNcPU4 aKyDqK1y0+mCeCvWIKanAVhGou9wdPg1VD2sg8kNkXGwQLbaqs4JhXUTxRwdNAzl fmJ2cONC6pBwifbdxuVq8Ayqik5kSDMgcoo+z1ubHNB4Kcrhgm9s9SIiBiV9JLkS 3hmaGok3rKE= =A7N2 -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818123231:5786=_-- End of MIME 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 17 20: 8:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 07BED14DC4 for ; Tue, 17 Aug 1999 20:08:05 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA45658; Tue, 17 Aug 1999 21:08:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA00764; Tue, 17 Aug 1999 21:08:06 -0600 (MDT) Message-Id: <199908180308.VAA00764@harmony.village.org> To: "Daniel O'Connor" Subject: Re: Need some advice regarding portable user IDs Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com, Wilfredo Sanchez In-reply-to: Your message of "Wed, 18 Aug 1999 12:32:31 +0930." References: Date: Tue, 17 Aug 1999 21:08:05 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Daniel O'Connor" writes: : IMHO being abe to override UID:GID's would be useful in a normal : mount because umapfs adds more complexity to work. (Though I can see : that doing it in the various FS's would suck royally) I don't understand the objection... umapfs is generic and relatively small.... I don't know if it actually works under FreeBSD-stable or -current, but it is in the tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 20:12:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 2F370155B8 for ; Tue, 17 Aug 1999 20:12:54 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id XAA08271; Tue, 17 Aug 1999 23:09:11 -0400 (EDT) Message-ID: <19990817230910.A6171@netmonger.net> Date: Tue, 17 Aug 1999 23:09:10 -0400 From: Christopher Masto To: Soren Schmidt , Vince Vielhaber Cc: hackers@FreeBSD.ORG Subject: Re: Onstream? References: <199908041047.MAA80548@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199908041047.MAA80548@freebsd.dk>; from Soren Schmidt on Wed, Aug 04, 1999 at 12:47:30PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 04, 1999 at 12:47:30PM +0200, Soren Schmidt wrote: > It seems Vince Vielhaber wrote: > > > > Out of curiousity, have there been any successes in the drivers for > > the OnStream tape drives (SCSI or IDE)? > > Working on it (for IDE that is), support is planned for, but I have > no release date yet... I know that there is work done on the SCSI > end too... Do they still not allow you to release the specs? How is the code going to become part of FreeBSD if they won't allow its release? I have considerable motivation to help, when it becomes possible for me to do so. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://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 17 20:14:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 1DCD21543A for ; Tue, 17 Aug 1999 20:14:19 -0700 (PDT) (envelope-from wsanchez@scv4.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id UAA67376 for ; Tue, 17 Aug 1999 20:14:54 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 17 Aug 1999 20:14:48 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv4.apple.com (8.9.3/8.9.3) with SMTP id UAA47224; Tue, 17 Aug 1999 20:14:46 -0700 Message-Id: <199908180314.UAA47224@scv4.apple.com> To: "Daniel O'Connor" Subject: Re: RE: Need some advice regarding portable user IDs Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com In-Reply-To: <199908180246.TAA06434@scv3.apple.com> Date: Tue, 17 Aug 1999 20:14:42 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Yes... Why is this a FreeBSD problem then? I would have thought it would be up | to MacOS to do the UID remapping (I must be missing something) I'm trying to support a user experience similar to Mac OS using BSD underneath (for Mac OS version 10). The goal being simplicity for the user, which I think might interest some FreeBSD users as well as my customers. | If you want proper username mapping shouldn't you be using a distributed user | map (like NIS)? And what happens accross NIS domains? -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 20:15:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 60466155B8 for ; Tue, 17 Aug 1999 20:15:00 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA27025; Wed, 18 Aug 1999 12:44:51 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818124450:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180308.VAA00764@harmony.village.org> Date: Wed, 18 Aug 1999 12:44:50 +0930 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: Need some advice regarding portable user IDs Cc: Wilfredo Sanchez , umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818124450:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Warner Losh wrote: > I don't understand the objection... umapfs is generic and relatively > small.... I don't know if it actually works under FreeBSD-stable or > -current, but it is in the tree. Well I don't know if it works either.. I thought someone fixed it, but it might be broken again :) --- 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 --_=XFMail.1.3.p0.FreeBSD:990818124450:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7olKlbYW/HEoF9pAQHyugP+PkPLztlHqLh1Uwuwx9Pb6BaguIxYbq1P d/KmYvQMjSmTuvHBVHy66EINSedxvIYbdwEXZYIfB12VAzvzjeNSohtSZ9EvFNAB BLRqY6wl+tUTIz/rwZS4w1ogUY70g9tZTLjveIokf4BoHzTGNz28S5deMi4qsVhY wTHYM/bFNLI= =hbxR -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818124450:5786=_-- End of MIME 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 17 20:25:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 65FF215627 for ; Tue, 17 Aug 1999 20:25:14 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA27188; Wed, 18 Aug 1999 12:55:25 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818125524:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180314.UAA47224@scv4.apple.com> Date: Wed, 18 Aug 1999 12:55:24 +0930 (CST) From: "Daniel O'Connor" To: Wilfredo Sanchez Subject: Re: RE: Need some advice regarding portable user IDs Cc: umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818125524:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Wilfredo Sanchez wrote: > I'm trying to support a user experience similar to Mac OS using > BSD underneath (for Mac OS version 10). The goal being simplicity > for the user, which I think might interest some FreeBSD users as well > as my customers. Right.. sorry, I didn't mean to sound rude :) > | map (like NIS)? > And what happens accross NIS domains? Design failure :) I suppose you could carry a UID, GID mapping on the disks, and have mount look out for it.. If you had a 'removable disk' flag in /etc/fstab, then have the kernel look for those files, and use umapfs with them on the mounted FS. It could be rather dangerous security wise though.. Maybe have an option somewhere else (sysctl?) that tells mount wether removable disks are allowed to have files that are executable/devices/s[ug]id on it. (ie automatically have -o noexec,nosuid,nodevice done automatically based on user prefs) If there where no mapping files on the disk have a default setting.. Perhaps you could 'sign' the files on the disk so that when you inserted it, it checked the mapping files where signed by someone so you could opt to trust certain people, and have less restrictive options for their disks. You could even have it so it asks for your key phrase (thinking pgp/ssh terms) when you insert the disk so you can verify the person, which would prevent someone getting a disk trusted by you and modifying it and using it in your machine. Ahh, the complexities are endless :) --- 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 --_=XFMail.1.3.p0.FreeBSD:990818125524:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7onpFbYW/HEoF9pAQG3kwQAnVIyvBgWlNvuRNx2eG68HcVS9c+uh+P5 cDgFNPKAV/J7bD4tDycDiFik6GMqe0fbqQKP8FPDPXzliEeYagtFd88gQ8ihg2ms /omt1RwoE050F0Os1xR+D7vipggNEFL2QTxitIcB+aqU06Xku9vj5A4oGnWQ5iNy x/0pq9j65ZY= =hHrs -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818125524:5786=_-- End of MIME 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 17 21: 8: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id C233614C9D for ; Tue, 17 Aug 1999 21:07:53 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA17804; Wed, 18 Aug 1999 00:06:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 18 Aug 1999 00:06:35 -0400 To: "Daniel O'Connor" , Wilfredo Sanchez From: Garance A Drosihn Subject: Re: RE: Need some advice regarding portable user IDs Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:25 PM +0930 8/18/99, Daniel O'Connor wrote: >On 18-Aug-99 Wilfredo Sanchez wrote: > > Joe doesn't use the shell. The Finder will do this for him; when > > you insert a floppy in Mac OS, it gets mounted and shows up on your > > desktop. This is the case with all media. > >Yes... Why is this a FreeBSD problem then? I would have thought it would be up >to MacOS to do the UID remapping (I must be missing something) The question is being sent to several different BSD groups. One of the newer BSD's being MacOS X (Ten) from Apple (follow on to NeXTSTEP, except that it's a much more MacOS-ish as far as the user interface). MacOS X (Ten) Server already uses code from FreeBSD, NetBSD, and OpenBSD. This isn't a freebsd problem per se, but wouldn't it be nice if Apple went with a solution that made sense to the other BSD groups? (particularly if someone in *BSD-land has already thought about the same issues). Some of Apple's OS-level changes have been donated back to the BSD groups, and if they implement a good solution to this problem then the other BSD's might want to pick it up. It's nice to see them asking for ideas before casting some implementation in stone... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 21:25:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 7264914C8F for ; Tue, 17 Aug 1999 21:25:54 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id AAA11586; Wed, 18 Aug 1999 00:24:50 -0400 (EDT) Message-ID: <19990818002450.B6171@netmonger.net> Date: Wed, 18 Aug 1999 00:24:50 -0400 From: Christopher Masto To: wsanchez@apple.com, "Daniel O'Connor" Cc: umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: RE: Need some advice regarding portable user IDs Mail-Followup-To: wsanchez@apple.com, Daniel O'Connor , umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG References: <199908180217.TAA03970@scv1.apple.com> <199908180246.TAA06434@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199908180246.TAA06434@scv3.apple.com>; from Wilfredo Sanchez on Tue, Aug 17, 1999 at 07:46:37PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 17, 1999 at 07:46:37PM -0700, Wilfredo Sanchez wrote: > Yes, the fancy command is what the Finder does for him. Options > are details, and not really interesting. The question is what should > the behaviour be, and what's happening underneath the covers to > support that? Are we mapping UID's to something meaningful? How? > Or is Joe a superuser for that volume? Which volumes get treated > this way, and how to you choose them? I think it's pretty much a given that there's going to have to be configuration for this to say which devices are "special" in this way (and perhaps for which users and under what conditions they are special). Ok, so given that /dev/fd0, for example, is marked as "insecure", some mechanism lets me say "anyone who is in group 'operator' can mount /dev/fd0 in such a way that they appear to own all the files (and when they do so, default to turning on nosuid and such)". I think you're looking for a solution to the common problem of someone popping a Zip disk in the drive. Devising a mechanism to perform a complicated mapping and carrying around of user information on removable media sounds like overkill (not to mention it wouldn't work for "just any" UFS Zip disk you have lying around, only the ones that were built on MacOS). I don't know what the administration model is for MacOS, but I think that if someone's moving a hard drive from one machine to another, it isn't unfair to expect a step up in complexity and privileges required, versus a simple floppy.. er, I mean Zip drive. You can lead a Unix to Macintosh, but you can't make it drool. Under the hood, performing the gyrations necessary to mount it through umap is an interesting approach, although last time I touched mount_umap it easily panicked my machine. It certainly seems better than hacking the kernel directly (an approach which the other BSDs will be less keen to accept). Good luck with it. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://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 17 21:49:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from virtual-voodoo.com (virtual-voodoo.com [204.120.165.254]) by hub.freebsd.org (Postfix) with ESMTP id 7CD1E14D17 for ; Tue, 17 Aug 1999 21:49:48 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: (from steve@localhost) by virtual-voodoo.com (8.9.3/8.9.3) id XAA38600 for freebsd-hackers@freebsd.org; Tue, 17 Aug 1999 23:50:28 -0500 (EST) (envelope-from steve) Date: Tue, 17 Aug 1999 23:50:28 -0500 (EST) From: Steven Ames Message-Id: <199908180450.XAA38600@virtual-voodoo.com> To: freebsd-hackers@freebsd.org Subject: OpenLDAP tests? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a project at work where using LDAP would make my life much simpler. So... on my home PC (running FBSD 4.0-CURRENT 8.2.99) I installed openldap from the ports collection (V1.2.3...ports cvsuped about an hour ago from cvsup5.freebsd.org). I cd into the test area /usr/ports/work/ldap/tests and type 'make'. Looking good... until... on test0003-search it stops. It just holds. My CPU is up to 99% and its chewed up 18 minutes of CPU before I hit Ctrl-C and stopped it. I did a 'make clean' moved scripts/test0003-seach to scripts/test0009-search (so it would run last) and tried again. Same results on test0004-modify. *sigh* Do the tests just not run? I didn't dare to just go ahead and use it as I'm not familiar enough with LDAP to judge if a failure is my fault or a system problem. I'd feel a lot safer if the tests all passed so that if anything goes wrong from that point I can call it user error. Anyone? -Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 22: 8:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id BF20D14D8B for ; Tue, 17 Aug 1999 22:08:41 -0700 (PDT) (envelope-from wsanchez@scv4.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id WAA41752 for ; Tue, 17 Aug 1999 22:08:29 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 17 Aug 1999 22:08:25 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv4.apple.com (8.9.3/8.9.3) with SMTP id WAA55082; Tue, 17 Aug 1999 22:08:24 -0700 Message-Id: <199908180508.WAA55082@scv4.apple.com> To: "Daniel O'Connor" Subject: Re: RE: Need some advice regarding portable user IDs Cc: umeshv@apple.com, warner.c@apple.com, pwd@apple.com, tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199908180314.UAA47224@scv4.apple.com> Date: Tue, 17 Aug 1999 22:08:20 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | I suppose you could carry a UID, GID mapping on the disks, and have mount look | out for it.. If you had a 'removable disk' flag in /etc/fstab, then have the | kernel look for those files, and use umapfs with them on the mounted FS. It | could be rather dangerous security wise though.. Maybe have an option somewhere | else (sysctl?) that tells mount wether removable disks are allowed to have | files that are executable/devices/s[ug]id on it. (ie automatically have -o | noexec,nosuid,nodevice done automatically based on user prefs) I would assume that unless the user has the appropriate priveledges and specifies otherwise, that all non-local media will not honor setuid and so on. So far, I'm thinking of local media as: 1) The root device, (which holds the kernel, so you have to trust it) 2) Volumes that were initialized locally and have been kept local. 3) Any devices the administrator has specified as such. #1 is easy. #2 implies some way of knowing what's been kept local, which is hard. #3 sounds easy. Aside from the setuid business, I might want to toss out any UID from non-local media, since they may not be relevant. On the other hand, they might be, and it would be nice if I could keep them in that case. And all of this wants happen without user intervention where possible. Oh, about fstab... right... (This is just FYI.) So we have a program called autodiskmount, which at boot time looks for available media and mounts it (mount point is determined by the volume label). We don't use fstab normally, mostly because we want users to be able to attach a drive and not have to configure it; it just shows up when they boot. The Finder does a similar thing: it gets notified when new media is available and it will try to mount it. The present behaviour in Mac OS X Server is that everything mounted this way is trusted, though the Finder should be requesting nosetuid; I should check that. It's also possible that the kernel will number drives in a different order (eg. /dev/sd0a this boot might be /dev/sd1a next boot), particularly if you are shuffling drives around. (Remember that hot-swap complicates this.) So a string like "/dev/sd0a" in fstab is fragile, and it works out better if we keep that information on the mounted media rather than on the root volume. -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 22:14:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id DFC7214D8B for ; Tue, 17 Aug 1999 22:14:54 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA19078; Wed, 18 Aug 1999 01:14:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199908180217.TAA03970@scv1.apple.com> References: <199908180217.TAA03970@scv1.apple.com> Date: Wed, 18 Aug 1999 01:14:41 -0400 To: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org From: Garance A Drosihn Subject: Re: Need some advice regarding portable user IDs Cc: pwd@apple.com, warner.c@apple.com, umeshv@apple.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote: > I think the desired behaviour would be that since this is >effectively now Joe's zip disk, he should be able to do as he >pleases. One proposal might be to give the console user the >equivalent of root's priveledges on any removeable media he inserts >into the machine while he's logged in on the console. While thinking about this, there's also the question of what access someone other than Joe would have to those files if they are (say) ssh-ed into the machine when he attaches the removable media. Not important for most home users, but relevant in "MacOS 10 Server" configurations. I forget exactly how nextstep did this, but there were some situations where it didn't work quite the way I wanted (at the time), and yet I couldn't decide on a clean way it should be changed so I'd get more of what I wanted... > One problem with my proposal (setting security and perhaps other >implications aside for the moment), is that knowing what media is >removeable is becoming increasingly difficult. Hot-swappable drives >(eg. FireWire) are effectively removeable, and may be transported >between machines fairly regularly. Does firewire also allow multiple computers to access a given drive at the same time (by "same time", I mean "without having to rewire any hardware"). IBM's SSA disks also have this idea of multiple hosts for a single disk, even if the hosts consider that disk as "local"... > So perhaps there needs to be a way to mark a drive as local >(perhaps with a host ID of some sort?) and noticing when a volume is >"foreign" that you need to do something special. Certainly you might >want to ignore setuid bits, for starters. This could simply be >something like fstab, which lists the local drives, and everything >else isn't considered local. What happens when that entry isn't made right, though? To take another example from NeXTSTEP experience, consider the confusion caused when people did forget to make a correct fstab entry when they added a hard disk which WAS considered local and non-removable. Files were always owned by whoever logged in, and were actually written to the disk with UID=nobody or root (I forget which). This caused a different set of problems once they realized the mistake, and then put the correct fstab entry in. At that point, no one but root had access, since all the original-creator info was gone. So, if you do have a marker to indicate a local drive, what happens when the marker is switched on<->off? > But then the question is, how do we want to deal with non-local >filesystems? The ideal thing would be to have a way to transport >user information with the filesystem (eg. uids on disk are mapped to >system uids via a per-filesystem database with more global IDs like >email addresses), but that could be expensive. Obviously I'm not helping much here... I have thought about this from time-to-time (due to my nextstations), and if I think about it enough I generally end up with a headache and go home. If considering some database like this, also consider that changing machines does not necessarily mean different accounting info. I may have several different G3's with the exact same accounts, quite delibrately, so I don't think a "host ID" marker is quite the right marker. A school with multiple labs of machines, for instance. Each lab might be the exact same id's, with different ids between labs. If I bounce around between thirty different machines in one lab, modifying files on my own little zip disk, it'll be weird to have that listed as thirty different UID's on the filesystem. I imagine it is workable, it just seems weird. Also note that different machines may deliberately have the same UID's, even though they are not using the same netinfo server. My machine at home vs my machine in the office, for instance. Some kind of signing/encryption of files (the actual data) might work, but I'm not sure an average person would want to try to keep track of the encryption keys (passwords, mappings between them, whatever). My head is starting to throb. I think I'll go home... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 22:17:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 6B6F414D8B for ; Tue, 17 Aug 1999 22:17:22 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA01621; Wed, 18 Aug 1999 14:47:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990818144736:5786=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <199908180508.WAA55082@scv4.apple.com> Date: Wed, 18 Aug 1999 14:47:36 +0930 (CST) From: "Daniel O'Connor" To: Wilfredo Sanchez Subject: Re: RE: Need some advice regarding portable user IDs Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990818144736:5786=_ Content-Type: text/plain; charset=us-ascii On 18-Aug-99 Wilfredo Sanchez wrote: > when new media is available and it will try to mount it. The present > behaviour in Mac OS X Server is that everything mounted this way is > trusted, though the Finder should be requesting nosetuid; I should > check that. It's also possible that the kernel will number drives in > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next > boot), particularly if you are shuffling drives around. (Remember > that hot-swap complicates this.) So a string like "/dev/sd0a" in > fstab is fragile, and it works out better if we keep that information > on the mounted media rather than on the root volume. You could wire all the disks down.. :) What happens with conflicting names? --- 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 --_=XFMail.1.3.p0.FreeBSD:990818144736:5786=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN7pB8FbYW/HEoF9pAQFx+wP9ETiv7rCar4SQVfb1Axl4EQQdLHykdp/9 kCgEGwIyGIroCpAZmSgw44fPTfDHugjqan1ChqpjJPglfZnB+S3w100RdMEZcKBx dV7CZiRarIc4tv8zKCGRP9+TJImTQi1RU/1Xyp8Hl66ednch4CIhndPStFcNZS/V 7D/1owvceuM= =qLSI -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990818144736:5786=_-- End of MIME 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 17 22:27:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.theinternet.com.au (zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (Postfix) with ESMTP id E160A156FB for ; Tue, 17 Aug 1999 22:27:08 -0700 (PDT) (envelope-from akm@mail.theinternet.com.au) Received: (from akm@localhost) by mail.theinternet.com.au (8.9.3/8.9.3) id PAA16220; Wed, 18 Aug 1999 15:23:51 +1000 (EST) (envelope-from akm) From: Andrew Kenneth Milton Message-Id: <199908180523.PAA16220@mail.theinternet.com.au> Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <199908180217.TAA03970@scv1.apple.com> from Wilfredo Sanchez at "Aug 17, 1999 7:17:45 pm" To: wsanchez@apple.com Date: Wed, 18 Aug 1999 15:23:50 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG +----[ Wilfredo Sanchez ]--------------------------------------------- | A group of us at Apple are trying to figure out how to handle | situations where a filesystem with "foreign" user ID's are present. | The basic problem is that the user experience using Unix semantics | are not really pleasant. I think some examples would help: Why not simply translate unknown ids to the current user? I don't mean modifying the owners on disk. The real problem comes if a new user gets that unknown ID, but, you have this problem anyway where the user exists. I say "simply" as in concept, not as in work required :-) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|Specialist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 22:39:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from virtual-voodoo.com (virtual-voodoo.com [204.120.165.254]) by hub.freebsd.org (Postfix) with ESMTP id 557F314CC3 for ; Tue, 17 Aug 1999 22:39:27 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: from localhost (steve@localhost) by virtual-voodoo.com (8.9.3/8.9.3) with ESMTP id AAA71100; Wed, 18 Aug 1999 00:38:30 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Date: Wed, 18 Aug 1999 00:38:30 -0500 (EST) From: Steven Ames To: Jaye Mathisen Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenLDAP tests? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks! I'll check the site (but would appreciate your sending it to me also). -Steve On Tue, 17 Aug 1999, Jaye Mathisen wrote: > > There is a patch that fixes this, I found it, and submitted a bug report > on their web page. > > I don't have it handy, but if you go to www.openldap.org and to their > faq-o-matic, and it should be in there. > > I'll see if I can find it and send it to you in the mean time. > > On Tue, 17 Aug 1999, Steven Ames wrote: > > > > > I've got a project at work where using LDAP would make my life > > much simpler. So... on my home PC (running FBSD 4.0-CURRENT 8.2.99) > > I installed openldap from the ports collection (V1.2.3...ports cvsuped > > about an hour ago from cvsup5.freebsd.org). > > > > I cd into the test area /usr/ports/work/ldap/tests and type 'make'. > > Looking good... until... on test0003-search it stops. It just holds. > > My CPU is up to 99% and its chewed up 18 minutes of CPU before I hit > > Ctrl-C and stopped it. I did a 'make clean' moved scripts/test0003-seach > > to scripts/test0009-search (so it would run last) and tried again. > > Same results on test0004-modify. *sigh* > > > > Do the tests just not run? I didn't dare to just go ahead and use it > > as I'm not familiar enough with LDAP to judge if a failure is my fault > > or a system problem. I'd feel a lot safer if the tests all passed so that > > if anything goes wrong from that point I can call it user error. > > > > Anyone? > > > > -Steve > > > > > > 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 17 22:40:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles542.castles.com [208.214.165.106]) by hub.freebsd.org (Postfix) with ESMTP id 97F05157B9 for ; Tue, 17 Aug 1999 22:40:47 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00489; Tue, 17 Aug 1999 22:33:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908180533.WAA00489@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: wsanchez@apple.com Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-reply-to: Your message of "Tue, 17 Aug 1999 19:17:45 PDT." <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Aug 1999 22:33:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: Basically, you have two alternatives; transport the user credentials with the media, or map the credentials on the media to something that's more sensible. In different situations, one or the other of these might make more sense. Throwing some examples: a) You put some files on a removable device. They are "owned" by you. You give the media to someone else, who then mounts it on their own system (which is logically totally disjoint to yours). The desired goal is for the recipient to be able to access the files just as you could. In this case, possession of the media is the desired credential, so the media itself should (ideally) not contain any other credential information (or it should be ignored). b) You move a disk from one server on your network to another. The disk contains files owned by hundreds of users. The desired goal in this case is for the users that could access the files on the first server to be able to access the same files in the same fashion when the disk is on the second server. In this case, the credentials are external to the media and need to be verified against it. One possible way of differentiating these two cases would be to have a flag associated with the media (filesystem perhaps) that indicates whether the media has "security features" enabled. If it doesn't, the media should appear as though everything on it is owned by the user that has mounted it. You would default "security features" off when removable media were initialised. With "security features" on, the media behaviour would be what we consider normal; permissions on files, directories etc. are checked and so forth. The issues related to migrating volumes with "security features" enabled are more interesting; the only atomic way to migrate the credential verification information is to write it to the disk before it's removed. eg. You would offer a "prepare disk for export" option which scanned the disk and wrote out a passwd/group-style database containing the credentials for the uids and gids represented on the volume; this would then need to be integrated into the new system in a suitable fashion, either by merging apparently identical users/groups (and possibly scanning the disk volume to update uid/gid values) into the new system's authentication databases (this would have some perhaps slightly interesting consequences), or by applying the per-volume list as a translation to allow users known to the media to access the system in some suitably limited fashion in order to get at the data on the media. One alternative that would allow migration within a heterogenous network but prevent dealing with the quite complex issues of migrating credentials would simply be to scan every volume with "security features" enabled which didn't appear to have been last used locally and check that all the users represented there were locally valid. This would benefit from having the uid:username and gid:groupname mappings available (maybe it would be faster just to dump the entire database to the disk?) since the scan could fall back to using a network authentication service (NIS, etc.) to obtain the data required to support the users locally. I'm probably being as confusing as you thought you were. Any of this any use? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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 17 23:12:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 5B40B15801 for ; Tue, 17 Aug 1999 23:12:22 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 12594 invoked from network); 18 Aug 1999 05:12:56 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 18 Aug 1999 05:12:56 -0000 Date: Tue, 17 Aug 1999 22:11:34 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: Steven Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenLDAP tests? In-Reply-To: <199908180450.XAA38600@virtual-voodoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There is a patch that fixes this, I found it, and submitted a bug report on their web page. I don't have it handy, but if you go to www.openldap.org and to their faq-o-matic, and it should be in there. I'll see if I can find it and send it to you in the mean time. On Tue, 17 Aug 1999, Steven Ames wrote: > > I've got a project at work where using LDAP would make my life > much simpler. So... on my home PC (running FBSD 4.0-CURRENT 8.2.99) > I installed openldap from the ports collection (V1.2.3...ports cvsuped > about an hour ago from cvsup5.freebsd.org). > > I cd into the test area /usr/ports/work/ldap/tests and type 'make'. > Looking good... until... on test0003-search it stops. It just holds. > My CPU is up to 99% and its chewed up 18 minutes of CPU before I hit > Ctrl-C and stopped it. I did a 'make clean' moved scripts/test0003-seach > to scripts/test0009-search (so it would run last) and tried again. > Same results on test0004-modify. *sigh* > > Do the tests just not run? I didn't dare to just go ahead and use it > as I'm not familiar enough with LDAP to judge if a failure is my fault > or a system problem. I'd feel a lot safer if the tests all passed so that > if anything goes wrong from that point I can call it user error. > > Anyone? > > -Steve > > > 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 17 23:13:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 33BAB15906 for ; Tue, 17 Aug 1999 23:13:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA46367; Wed, 18 Aug 1999 00:14:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA16101; Wed, 18 Aug 1999 00:13:36 -0600 (MDT) Message-Id: <199908180613.AAA16101@harmony.village.org> To: Christopher Masto Subject: Re: Onstream? Cc: Soren Schmidt , Vince Vielhaber , hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 17 Aug 1999 23:09:10 EDT." <19990817230910.A6171@netmonger.net> References: <19990817230910.A6171@netmonger.net> <199908041047.MAA80548@freebsd.dk> Date: Wed, 18 Aug 1999 00:13:36 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990817230910.A6171@netmonger.net> Christopher Masto writes: : Do they still not allow you to release the specs? How is the code : going to become part of FreeBSD if they won't allow its release? I didn't sign an NDA to get my copy of the spec or the hardware... I also don't have time to devote to the onstream IDE project. I'm looking for someone with the kernel skills and track record to take over for me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 17 23:40:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oleg.sani-c.vrn.ru (oleg.sani-c.vrn.ru [195.98.74.83]) by hub.freebsd.org (Postfix) with ESMTP id 0A37C1579F for ; Tue, 17 Aug 1999 23:40:02 -0700 (PDT) (envelope-from oleg@oleg.sani-c.vrn.ru) Received: from localhost (oleg@localhost) by oleg.sani-c.vrn.ru (8.9.2/8.9.2) with ESMTP id KAA38511; Wed, 18 Aug 1999 10:38:28 +0400 (MSD) (envelope-from oleg@oleg.sani-c.vrn.ru) Date: Wed, 18 Aug 1999 10:38:28 +0400 (MSD) From: Oleg Derevenetz To: Ilia Chipitsine Cc: Alec Kalinin , Mark Newton , freebsd-hackers@FreeBSD.ORG Subject: Re: Probably bug with allocation memory in FreeBSD-3.2-RELEASE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Ilia Chipitsine wrote: > > > > Why i think this is bug? Because any user can hung FreeBSD, settings in > > > > /etc/login.conf can't help. > > > > >Are you sure about that? Setting datasize limits will prevent > > >malloc() from doing what you're trying to make it do. Are you > > >sure you're setting your login.conf settings properly? > > > > guys, just a silly question ! > how dod you think login.conf works with xdm ?! > right ! xdm simply ignores it ... > This is only example. 'Stable system' must be stable in any time, even out-of-swap occured. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 1:58:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id 9625A14CA5 for ; Wed, 18 Aug 1999 01:58:20 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id JAA86515; Wed, 18 Aug 1999 09:57:16 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA00573; Wed, 18 Aug 1999 09:08:45 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199908180808.JAA00573@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Somers Cc: Josef Karthauser , Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp In-reply-to: Your message of "Tue, 06 Jul 1999 21:04:28 BST." <199907062004.VAA74215@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Aug 1999 09:08:45 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > > Brian, > > > > The i4b stuff seems to have some sophisticated costing control code (isdn.rates). > > It appears that you can define the costs at different times of day and thereby > > vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". > > I've added it to my todo list. I'll probably look at the BACP or MP+ > stuff first though, and then at the ``when to bring up another link'' > code.... all fun & games :-) [.....] FWIW, ppp can now be given a minimum idle timer. While not covering everything, it does address the minimum call charge side of things. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 2: 3:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gbtb.com (modem3.tekrab.net [208.30.20.203]) by hub.freebsd.org (Postfix) with ESMTP id 5988014D93 for ; Wed, 18 Aug 1999 02:03:04 -0700 (PDT) (envelope-from mrami@gbtb.com) Received: from localhost (mrami@localhost) by gbtb.com (8.9.3/8.9.3) with ESMTP id FAA29052; Wed, 18 Aug 1999 05:00:49 -0400 (EDT) (envelope-from mrami@gbtb.com) Date: Wed, 18 Aug 1999 05:00:48 -0400 (EDT) From: Marc Ramirez X-Sender: mrami@mrami.ghostgbtb.com To: Wilfredo Sanchez Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <199908180217.TAA03970@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Wilfredo Sanchez wrote: > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: I was thinking about this the other day, while mousting a series of floppy disks, and it seems to me that what you're looking for, at least for removable media, is a sort of single-user UFS that says "Joe Schmoe owns this file system." Assuming that neither you nor Joe have accounts on each other's machines: 0) Non-root users should be able to mount disks. This really goes without saying for desktop systems. 1) You mount_suufs his disk with some sort of "foreign-user" option, and the system chooses an unused, per device UID and GID, and all the directories are mapped to that ownership. 2) You copy the files to a world wrx directory, and they all automagically become foreign ownership. 3) Joe goes to his computer and mounts his disk, and voila, he owns everything (it's his filesystem after all). This handles the simple case of just shuffling files around. If you wanted more elaborate collaborations, you'd really have to give each other accounts. You could monkey around with keeping passwd files and such on the medium and umapping, but you couldn't copy files from the Zip to the local FS without future-user-clash. This also affords Joe more than your normal level of security, assuming he trusts root on all the systems involved. Marc. -- Marc Ramirez - Owner Great Big Throbbing Brains mrami@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 2:38:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 99DB014DAB; Wed, 18 Aug 1999 02:38:14 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11H28T-00046z-00; Wed, 18 Aug 1999 11:35:57 +0200 From: Sheldon Hearn To: Brian Feldman Cc: hackers@freebsd.org Subject: Re: cvs commit: src/bin/test test.c In-reply-to: Your message of "Tue, 17 Aug 1999 17:18:53 MST." <199908180018.RAA84904@freefall.freebsd.org> Date: Wed, 18 Aug 1999 11:35:57 +0200 Message-ID: <15808.934968957@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Hi-jacked out of cvs-committers & cvs-all] On Tue, 17 Aug 1999 17:18:53 MST, Brian Feldman wrote: > green 1999/08/17 17:18:53 PDT > > Modified files: > bin/test test.c > Log: > The new test(1) did not use access() correctly. I don't know why, since > supposedly it's ksh-derived, and it's not broken in pdksh. I've added > a test for test running as root: if testing for -x, the file must be > mode & 0111 to get "success", rather than just existant. > > Reviewed by: chris What were you actually trying to fix, here? I didn't see any discussion of this on hackers, current or bugs, nor in response to my initial commit message. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 2:45:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from setec.org (setec.org [205.136.35.171]) by hub.freebsd.org (Postfix) with ESMTP id 232FD14DAB for ; Wed, 18 Aug 1999 02:45:10 -0700 (PDT) (envelope-from izaac@2600.com) Received: from localhost (localhost [[UNIX: localhost]]) by setec.org (8.8.8/8.8.8) with SMTP id FAA26270; Wed, 18 Aug 1999 05:45:27 -0400 (EDT) X-Authentication-Warning: setec.org: izaac owned process doing -bs Date: Wed, 18 Aug 1999 05:45:26 -0400 (EDT) From: Izaac Reply-To: Izaac To: Wilfredo Sanchez Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <199908180217.TAA03970@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Wilfredo Sanchez wrote: > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. [...] > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. [...] > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves [...] > implications aside for the moment), is that knowing what media is > removeable is becoming increasingly difficult. Hot-swappable drives [...] > So perhaps there needs to be a way to mark a drive as local > (perhaps with a host ID of some sort?) and noticing when a volume is > "foreign" that you need to do something special. Certainly you might [...] This has been tackled by folks distributing via ISO9660+RockRidge.. It's based on a few assumptions: 1) It's data specifically tagged for export. 2) If you're giving it to Other Guy, you obviously want him to be able to read it and navigate it without impediment (otherwise, you wouldn't have put it on there, would you?) 3) Other Guy is responsible for managing his new files. So, let's remove the ROM mentality and apply it to our "removable" media problem: 1) The data may or may not be specifically tagged export. With a ROM, you only decide once what this child of your creativity's purpose will be in life. Is it staying home or going abroad? It would be safe to assume that a very solid majority of users will be neither familiar with mastering nor happy with having the inflexibility of being forced to decide at "Erase Disk..." time (who changed it to that anyway? :P ) whether this volume is local or exported. 2) You'll still want Other Guy to be able to navigate without impediment. The default action would be to save ownership/permission information on media for local use and present a least common denominator view (chown -R 0.0 && chmod -R a=rX) for other recipients. It ought to be transparent, but otherwise able to be manually fiddled with (sometimes you just don't want other people to be able to find out your uname is "fuckwit1"). So yeah, you'll want to tag your media as MINE. A superhappyfun-hash of the hostname and something else ought to make a nice tag. So far as where to put it depends on the FS. Take a looksee at RockRidge's RRIP and SUSP at: ftp://ftp.ymi.com/pub/rockridge/ Or be slicker with UDF at: http://www.osta.org/html/ostatech.html#udf 3) Other guy is still responsible for managing his new files. This can and will get oftly interesting oftly quickly. a) Other Guy goes to mount the media the originator gave him. He checks the superhappyfun-hash ID, which doesn't match his system. The disk is considered alien and goes to LCD mode. One could blindly assume that if Other Guy was able to mount the media (not necessarily be at console) that he ought to own everything on it. Reasonable. b) Other Guy (optionally) has his machine try a little harder to figure out what's actually going on. It could look at the ownership/permissions on the media itself, get a feel for what's what and where, then try to construct a filesystem utopia. This can, in and of itself, get oftly intersting oftly quickly. c) Other Guy (optionally) tweaks things himself. d) From there? He could designate himself the new originator of the media by relabeling the source ID to 'OGsuperhappyfun-hash'. Or, he could store his own o/p map .. locally or maybe on the media itself? He could also remaster the media ("fuckwit2").. Ohh, what a tangled web we do weave ... :) Personally, I like the redesignation.. This could get very expensive, though, for large volumes and/or frequent system swaps (remap, move, remap, move, remap, move, remap.) > As another example, a similar situation often comes up on the net > with tar files containing UIDs and GIDs other than zero. No it doesn't. If you can't chown, touch, or chmod the extracted file to match the archived state, you won't. It's yours with your umask. ___ ___ . . ___ \ / |\ |\ \ _\_ /__ |-\ |-\ \__ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 2:59:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by hub.freebsd.org (Postfix) with ESMTP id 6DAE414DB0 for ; Wed, 18 Aug 1999 02:58:32 -0700 (PDT) (envelope-from ignatios@theory.cs.uni-bonn.de) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA05519; Wed, 18 Aug 1999 11:57:09 +0200 (MET DST) Message-ID: <19990818115709.A4507@theory.cs.uni-bonn.de> Date: Wed, 18 Aug 1999 11:57:09 +0200 From: Ignatios Souvatzis Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs References: <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Marc Ramirez on Wed, Aug 18, 1999 at 05:00:48AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > I was thinking about this the other day, while mousting a series of floppy > disks, and it seems to me that what you're looking for, at least for > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > this file system." our(*) msdos and ados filesystems (at least) do (sort of) this. Regards, -is *) where we = NetBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 3:33:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gbtb.com (modem3.tekrab.net [208.30.20.203]) by hub.freebsd.org (Postfix) with ESMTP id 449EE14D15 for ; Wed, 18 Aug 1999 03:33:06 -0700 (PDT) (envelope-from mrami@gbtb.com) Received: from localhost (mrami@localhost) by gbtb.com (8.9.3/8.9.3) with ESMTP id GAA29361; Wed, 18 Aug 1999 06:30:07 -0400 (EDT) (envelope-from mrami@gbtb.com) Date: Wed, 18 Aug 1999 06:30:07 -0400 (EDT) From: Marc Ramirez X-Sender: mrami@mrami.ghostgbtb.com To: Ignatios Souvatzis Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <19990818115709.A4507@theory.cs.uni-bonn.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Ignatios Souvatzis wrote: > On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > > > I was thinking about this the other day, while mousting a series of floppy > > disks, and it seems to me that what you're looking for, at least for > > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > > this file system." > > our(*) msdos and ados filesystems (at least) do (sort of) this. Yeah. That's definitely where I'd start from. I think the main obstacle for any *BSD system in the ease-of-use department will be the must-mount-as-root issue. I don't know what's involved in getting that to work properly. Maybe the best solution is to have some sort of automount daemon. That would more than likely work for devices with media detection (Mac floppys come to mind... :) The devil's in the details... Marc. > Regards, > -is > > *) where we = NetBSD > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Marc Ramirez - Owner Great Big Throbbing Brains mrami@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 4:23:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by hub.freebsd.org (Postfix) with ESMTP id 5EA18157FB for ; Wed, 18 Aug 1999 04:23:09 -0700 (PDT) (envelope-from sommerfeld@orchard.arlington.ma.us) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id LAA27515; Wed, 18 Aug 1999 11:19:46 GMT Message-Id: <199908181119.LAA27515@orchard.arlington.ma.us> To: Marc Ramirez Cc: Ignatios Souvatzis , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message from Marc Ramirez of "Wed, 18 Aug 1999 06:30:07 EDT." Date: Wed, 18 Aug 1999 07:19:46 -0400 From: Bill Sommerfeld Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yeah. That's definitely where I'd start from. I think the main obstacle > for any *BSD system in the ease-of-use department will be the > must-mount-as-root issue. huh? NetBSD (at least) allows non-root mounts (forced to nodev,nosuid, ..) if the user owns the mount point and has appropriate access to the underlying device.. I thought that was a 4.4Lite feature.. - Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 4:35:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 5E98214DB0 for ; Wed, 18 Aug 1999 04:35:28 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id HAA15107; Wed, 18 Aug 1999 07:34:52 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id HAA07347; Wed, 18 Aug 1999 07:34:50 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id HAA37644; Wed, 18 Aug 1999 07:34:49 -0400 (EDT) Date: Wed, 18 Aug 1999 07:34:49 -0400 (EDT) From: Thomas David Rivers Message-Id: <199908181134.HAA37644@lakes.dignus.com> To: mrami@gbtb.com, wsanchez@apple.com Subject: Re: Need some advice regarding portable user IDs Cc: freebsd-hackers@FreeBSD.ORG, pwd@apple.com, tech-userlevel@netbsd.org, umeshv@apple.com, warner.c@apple.com In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had a thought on this.... It seems you are trying to provide the "floppy model" that users currently have with their PCs. User A writes the floppy, User B can read it and do whatever he wants... (I know this is Apple - but I'll stick to MSDOS for the discussion, and "floppy" indicates any removable media.) The reason for this is that MSDOS filesystems don't keep any user credentials. So, use B can read anything on any floppy he can find. Wouldn't creating a file system that didn't support user credentials solve your problem? Format the floppy in that file system and hand it to user B. When user B mounts it, he can do whatever he wants. User A is aware of how the floppy was created, as presumably some special step is required to create the "discard credential" file system on the floppy. Perhaps, such a file system could even be a UFS with a special marker somewhere? Then, this marker could be "twiddled" after the fact. For example, user A formats and makes a new UFS file system on the floppy, and copies the files over. Marks it as having no credentials (twiddles the bit) and hands it to user B. User B mounts it, with a regular UFS mount - but because the magic bit is "twiddled" GID and UID are ??? (here's where things break down, just what do you use for those? root/nobody/user's gid&uid?) Just some thoughts... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 4:42:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gbtb.com (modem3.tekrab.net [208.30.20.203]) by hub.freebsd.org (Postfix) with ESMTP id 22CAE14F68 for ; Wed, 18 Aug 1999 04:42:09 -0700 (PDT) (envelope-from mrami@gbtb.com) Received: from localhost (mrami@localhost) by gbtb.com (8.9.3/8.9.3) with ESMTP id HAA30150; Wed, 18 Aug 1999 07:39:11 -0400 (EDT) (envelope-from mrami@gbtb.com) Date: Wed, 18 Aug 1999 07:39:11 -0400 (EDT) From: Marc Ramirez X-Sender: mrami@mrami.ghostgbtb.com To: Bill Sommerfeld Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <199908181119.LAA27515@orchard.arlington.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ CC's trimmed ] On Wed, 18 Aug 1999, Bill Sommerfeld wrote: > > Yeah. That's definitely where I'd start from. I think the main obstacle > > for any *BSD system in the ease-of-use department will be the > > must-mount-as-root issue. > > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. Oh! I was under the impression that it just didn't work, even with correct perms, but I use FreeBSD. Lemme try it... Can't mount, even with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first time! Marc. > I thought that was a 4.4Lite feature.. > > - Bill -- Marc Ramirez - Owner Great Big Throbbing Brains mrami@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 5: 3:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 6B86115702 for ; Wed, 18 Aug 1999 05:03:33 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 18 Aug 1999 13:01:27 +0100 (BST) Date: Wed, 18 Aug 1999 13:01:27 +0100 From: David Malone To: Marc Ramirez Cc: Bill Sommerfeld , freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990818130126.A77917@walton.maths.tcd.ie> References: <199908181119.LAA27515@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Marc Ramirez on Wed, Aug 18, 1999 at 07:39:11AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I think. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 5: 6:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wit401310.student.utwente.nl (wit401310.student.utwente.nl [130.89.236.150]) by hub.freebsd.org (Postfix) with ESMTP id EEC5B14D2E for ; Wed, 18 Aug 1999 05:06:28 -0700 (PDT) (envelope-from dalroi@wit401310.student.utwente.nl) Received: from wit401310.student.utwente.nl (localhost [127.0.0.1]) by wit401310.student.utwente.nl (Postfix) with ESMTP id 27BC81D58; Wed, 18 Aug 1999 14:07:04 +0200 (CEST) Date: Wed, 18 Aug 1999 14:07:03 +0200 (CEST) From: Alban Hertroys Subject: Re: Need some advice regarding portable user IDs To: Marc Ramirez Cc: Bill Sommerfeld , freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <19990818120704.27BC81D58@wit401310.student.utwente.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18 Aug, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! > > Marc. No miracle, the mount command has uid 0 hardcoded in the source where you are checked if you are allowed to use the mount command. I've been thinking of a neat way to re-organize that code myself for some time now, and thought I had come up with a solution (It's the reason I subscribed to this list in the first place). With the current discussion, I figure it has some major shortcomings. It adds some things too, though, like the permissions to audio devices, etc. Anyway, I wrote a "paper" about it that I can post here if anybody is interested. In that case, which format s liked best: plain text, TeX or postscript? I assume the first. -- Alban Hertroys. http://wit401310.student.utwente.nl == If there is a here-after, then there are much more people dead than alive. Even that much more that the number of living people is insignificant in comparison to the dead ones. Thus it is safe to say that we don't exist. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 5:23:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from karl.tools.de (karl.TooLs.DE [192.76.135.65]) by hub.freebsd.org (Postfix) with ESMTP id E27D4157C9 for ; Wed, 18 Aug 1999 05:22:43 -0700 (PDT) (envelope-from ws@tools.de) Received: from kurt.tools.de (kurt.TooLs.DE [192.76.135.70]) by karl.tools.de (8.8.8/8.8.8) with SMTP id OAA20739; Wed, 18 Aug 1999 14:22:11 +0200 (MET DST) Received: by kurt.tools.de (SMI-8.6/SMI-SVR4) id OAA26000; Wed, 18 Aug 1999 14:22:11 +0200 Date: Wed, 18 Aug 1999 14:22:11 +0200 From: ws@tools.de (Wolfgang Solfrank) Message-Id: <199908181222.OAA26000@kurt.tools.de> To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Need some advice regarding portable user IDs X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. Yes, it was part of 4.4Lite2. And I still have the discussion from 1994 between Chris Demetriou, Kirk McKusick and myself which triggered this feature. (For the record, (the equivalent of) core@netbsd.org was CC'ed on this discussion, and Theo kicked in later, too). Back then, I was arguing to use the mounter's uid, if it wasn't root, as owner for all files (well, we were discussing this more or less with respect to msdosfs only, so you have to set some uid as the owner of files anyway), but Chris was arguing that the man in front of the box should be able to mount some floppy for some other guy and give him access to his files. Actually substituting the mounter for the owner of the files should be quite easy to implement (since most filesystems now use the generic vaccess routine for access checking, it wouldn't even require changes to most filesystems), as the mounter is available in the mount structure anyway. (It is checked on an unmount, so only the mounter (and root, of course) can unmount a filesystem). However, if we'd make it an option to the generic mount code, it would probably be a good idea to make the substitution uid and gid extra arguments to the mount command for the reasons Chris mentioned back then. Ciao, Wolfgang PS: BTW, shouldn't this be on tech-kern@netbsd.org instead of tech-userlevel? -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 5:56:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.41.238]) by hub.freebsd.org (Postfix) with ESMTP id 7B30C14E6B; Wed, 18 Aug 1999 05:56:17 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id JAA00832; Wed, 18 Aug 1999 09:32:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bill Studenmund Cc: Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Mon, 16 Aug 1999 13:48:16 PDT." Date: Wed, 18 Aug 1999 09:32:52 +0200 Message-ID: <830.934961572@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bill Studenmund writes: >On Sat, 14 Aug 1999, Terry Lambert wrote: >> > I am currently conducting a thorough study of the VFS subsystem >> > in preparation for an all-out effort to port SGI's XFS filesystem to >> > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon >> > has written in hackers- that the VFS subsystem is presently not >> > well understood by any of the active kernel code contributers and >> > that it will be rewritten later this year. This is obviously of great >> > concern to me in this port. >> >> It is of great concern to me that a rewrite, apparently because of >> non-understanding, is taking place at all. > >That concerns me too. Many aspects of the 4.4 vnode interface were there >for specific reasons. Even if they were hack solutions, to re-write them >because of a lack of understanding is dangerous as the new code will >likely run into the same problems as before. :-) Matt doesn't represent the FreeBSD project, and even if he rewrites the VFS subsystem so he can understand it, his rewrite would face considerable resistance on its way into FreeBSD. I don't think there is reason to rewrite it, but there certainly are areas that need fixing. >> The use of the "vfs_default" to make unimplemented VOP's >> fall through to code which implements function, while well >> intentioned, is misguided. I beg to differ. The only difference is that we pass through multiple layers before we hit the bottom of the stack. There is no loss of functionality but significant gain of clarity and modularity. Adding a new VOP entails the same thing as it has always done. >> 3. The filesystem itself is broken for Y2038 >> >> The space which was historically reserved for the Y2038 fix >> (a 64 bit time_t) was absconeded with for subsecond resoloution. >> >> This change should be reverted, and fsck modified to re-zero >> the values, given a specific argument. That would break make(1) on contemporary machines. >One other suggestion I've heard is to split the 64 bits we have for time >into 44 bits for seconds, and 20 bits for microseconds. That's more than >enough modification resolution, and also pushes things to past year >500,000 AD. Versioning the indoe would cover this easily. This would be misguided, and given the current speed of evolution lead to other problems far before 2038. Both struct timespec and struct timeval are major mistakes, they make arithmetic on timestamps an expensive operation. Timestamps should be stored as integers using an fix-point notations, for instance 64bits with 32bit fractional seconds (the NTP timestamp), or in the future 128/48. Extending from 64 to 128bits would be a cheap shift and increased precision and range could go hand in hand. If we don't want to extend the size of the timestamps before 2038, (and we should not only look at filesystems here), then the correct fix will be to move the epoch and use the inode version to mark this fact. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 5:59:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 3A90C14E09; Wed, 18 Aug 1999 05:59:18 -0700 (PDT) (envelope-from mark@xaa.mpn.cp.philips.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id OAA24208; Wed, 18 Aug 1999 14:58:52 +0200 (MEST) (envelope-from mark@xaa.mpn.cp.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma024204; Wed, 18 Aug 99 14:58:52 +0200 Received: from xaa.mpn.cp.philips.com (xaa.mpn.cp.philips.com [130.139.64.114]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA27547; Wed, 18 Aug 1999 14:58:50 +0200 (MET DST) Received: by xaa.mpn.cp.philips.com (Postfix, from userid 1000) id 7CEAC505D; Wed, 18 Aug 1999 14:58:50 +0200 (CEST) Date: Wed, 18 Aug 1999 14:58:50 +0200 From: Mark Huizer To: freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org Subject: VMWare: porting kernel modules to FreeBSD Message-ID: <19990818145850.E17189@xaa.mpn.cp.philips.com> Reply-To: mark+freebsd@xaa.mpn.cp.philips.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi there, I had a look recently at the code for one of the kernel modules that VMWare requires (driver-only.tar), and it looks like something that should be portable to FreeBSD, although there is some messy stuff in it (assembly that seems to be using Linux specific stuff, brrr..) But anyway: it looks feasable. Is anyone already working on this, or are some people interested in helping with this? As far as I can see, the linux emulation is good enough to run the vmware program, "all" you need to do is implement /dev/vmmon and /dev/vmnet, given the fact that the code is written really unportable, so there is some rewriting to be done. Then with the KLD's vmmon,vmnet and linux you should be able to run vmware. Mark -- Mark Huizer - Mark.Huizer@nl.origin-it.com - xaa@xaa.iae.nl Reality is an illusion caused by lack of alcohol To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 6:48:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id D3E8814DED for ; Wed, 18 Aug 1999 06:48:23 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 34164 invoked from network); 18 Aug 1999 13:48:17 -0000 Received: from shell-2.enteract.com (dscheidt@207.229.143.41) by pop3-3.enteract.com with SMTP; 18 Aug 1999 13:48:17 -0000 Date: Wed, 18 Aug 1999 08:48:17 -0500 (CDT) From: David Scheidt To: Garance A Drosihn Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: lpd security check for changed-file vs NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Garance A Drosihn wrote: > At 6:37 PM -0700 8/17/99, Matthew Dillon wrote: > > If you removed the stat test, I would simply get rid of the -s > > option entirely - require that all files be queued to the print > > spool. > > The administration would kill me. I would prefer to avoid that. > > (note that the check isn't completely removed, it's "only" nullified > for NFS-mounted files. We use AFS for most things here, so the vast Couldn't you turn it off only for NFS mounted files? David scheidt > > Any advice on how to kick AIX so the st_dev+st_ino check will work > right is also welcome. It baffles me why AIX does things the way it > does. It kinda looks like the values it uses are pointers to some The joke about AIX is that it was created by aliens who were given the UNIX documentation, but no example system. I have seen very little that suggests this to be untrue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 6:54: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jasper.heartland.ab.ca (jasper.heartland.ab.ca [207.107.228.1]) by hub.freebsd.org (Postfix) with ESMTP id 565C614D05 for ; Wed, 18 Aug 1999 06:54:00 -0700 (PDT) (envelope-from dkwiebe@hagenhomes.com) Received: from freebsd.hagens.ab.ca (ppp2.heartland.ab.ca [207.107.228.130]) by jasper.heartland.ab.ca (8.9.0/8.8.5) with ESMTP id HAA25628 for ; Wed, 18 Aug 1999 07:46:16 -0600 (MDT) Received: from hagenhomes.com (dkwiebe.hagens.ab.ca [10.0.1.3]) by freebsd.hagens.ab.ca (8.9.2/8.9.2) with ESMTP id OAA03719 for ; Tue, 17 Aug 1999 14:45:24 -0600 (MDT) (envelope-from dkwiebe@hagenhomes.com) Message-ID: <37B9D682.2C9D9979@hagenhomes.com> Date: Tue, 17 Aug 1999 15:39:14 -0600 From: Darren WIebe X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: [Fwd: First FreeMWare release!] Content-Type: multipart/mixed; boundary="------------9A8E440C3DAFAA4FB2310FCB" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9A8E440C3DAFAA4FB2310FCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello: I thought that some of you might be interested in this. If this message should not have been posted to this list please let me know. Darren Wiebe dkwiebe@hagenhomes.com --------------9A8E440C3DAFAA4FB2310FCB Content-Type: message/rfc822; name="nsmail37B9D67A06302F0" Content-Disposition: inline; filename="nsmail37B9D67A06302F0" Return-Path: owner-freemware@fastxs.net Received: from localhost (localhost.hagens.ab.ca [127.0.0.1]) by freebsd.hagens.ab.ca (8.9.2/8.9.2) with ESMTP id MAA03019 for ; Tue, 17 Aug 1999 12:42:24 -0600 (MDT) (envelope-from owner-freemware@fastxs.net) Received: from jasper.heartland.ab.ca by localhost with IMAP (fetchmail-4.7.0) for dkwiebe@localhost (single-drop); Tue, 17 Aug 1999 18:42:25 +0000 (UTC) Received: from safeco2.safeco.net (safeco2.safeco.net [216.71.84.27]) by jasper.heartland.ab.ca (8.9.0/8.8.5) with ESMTP id NAA12248 for ; Tue, 17 Aug 1999 13:00:53 -0600 (MDT) Received: from lightning.fastxs.net (ns1.fastxs.net [212.204.201.31]) by safeco2.safeco.net (8.8.5/8.8.5) with ESMTP id OAA06273 for ; Tue, 17 Aug 1999 14:07:17 -0500 Delivered-To: freemware-list@fastxs.net Received: by lightning.fastxs.net (Postfix, from userid 0) id 59E23E8009; Tue, 17 Aug 1999 21:08:28 +0200 (CEST) Delivered-To: maillist@fastxs.net Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by lightning.fastxs.net (Postfix) with ESMTP for id 050C9E8009; Tue, 17 Aug 1999 21:08:21 +0200 (CEST) Received: from bochs.com (209-67-232-141.bst0.flashcom.net [209.67.232.141]) by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id MAA01679 for ; Tue, 17 Aug 1999 12:07:55 -0700 (PDT) Message-ID: <37B9B30F.2DBB2B54@bochs.com> Date: Tue, 17 Aug 1999 15:07:59 -0400 From: Kevin Lawton Organization: Bochs Software Company X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: freemware@fastxs.net Subject: First FreeMWare release! Content-Type: multipart/mixed; boundary="------------CD1214F931FF017AD0AF55AE" Sender: owner-freemware@fastxs.net Precedence: bulk Reply-To: freemware@fastxs.net X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------CD1214F931FF017AD0AF55AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey folks, It's been awhile. Sorry, I've been busy working on other fronts, but I did have time to put together a first go at the virtualization framework we need for FreeMWare. ftp://ftp.freemware.org/pub/freemware/fmw-990817b.tar.gz Which if you're having problems, is really just: ftp://bochs.com/pub/freemware/fmw-990817b.tar.gz Attached is the "fmw-990817b.README" that goes along with it. -Kevin --------------CD1214F931FF017AD0AF55AE Content-Type: text/plain; charset=us-ascii; name="fmw-990817b.README" Content-Disposition: inline; filename="fmw-990817b.README" Content-Transfer-Encoding: 7bit This is the beginnings to the virtualization framework that we need for FreeMWare. I have compiled it and run it on: Linux 2.0.36 (came with Red Hat 5.2) Linux 2.2.5-15 (came with Red Hat 6.0) I've made an attempt to keep things modularized in respect to the host OS. Anything OS specific should be put in "kernel/host-xyz.c" or "include/host-xyz.h". This code is extremely experimental, and will likely result in a system crash, and who knows what other ill effects. Don't run it on a system with any important data on it, and make liberal user of the sync command! Expect to have to use the power button. We have to clean up the ioctl interface, using macros instead of passing raw numbers I pulled out of a hat, etc, etc. This was my first Linux kernel driver, so don't assume I did anything correctly. :^) -Kevin Directions for install etc. --------------------------- Go into the user directory and type make. user> cd user user> make Go into the kernel directory and type make. user> cd ../kernel user> make Make the device node for freemware, as root user: root> mknod /dev/freemware0 c 63 0 Fire up the kernel module: root> insmod fmw.o As a regular user, fire up the user program: user> cd ../kernel user> ./user # defaults to 1 iteration -or user> ./user 10 # any number of iterations here Whenever you recompile the kernel stuff, or want to get rid of the kernel module, remove the old kernel module first. As root: root> rmmod fmw Each time the host switches to the monitor/guest environment and runs that context. Normally, execution will continue in that context until a hardware interrupt occurs or other exception. The monitor interrupt handler switches back to the host context to handle the interrupt. The monitor/guest context will not resume execution until the next ioctl() call from the user program. NOTE: By default, I have a macro called TEST_MODE set to 1, in kernel/monitor.c. In this mode, rather than waiting until an interrupt hits, control will be passed immediately back to the the host. This is to test that the switching back/forth between host/monitor+guest works, without interrupts. I have not yet got interrupts redirection working properly. If you set TEST_MODE to 0 and recompile, an interrupt seems to cause everything to switch back to the host context, but then the system hangs after a short period of time, or causes a kernel oops. I have not tracked this down yet. It does register in /proc/freemware, that a redirection of an IRQ0 occurred. Something is getting screwed up with interrupts in the kernel perhaps, after the software interrupt call to invoke the host kernel interrupt handler for the hardware interrupt we received while in guest context. Any ideas on what the problem is? --------------CD1214F931FF017AD0AF55AE-- --------------9A8E440C3DAFAA4FB2310FCB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 6:54:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id E2768158CD for ; Wed, 18 Aug 1999 06:54:19 -0700 (PDT) (envelope-from mcr@istari.sandelman.ottawa.on.ca) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id JAA26694; Wed, 18 Aug 1999 09:57:58 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost.sandelman.ottawa.on.ca [127.0.0.1]) by istari.sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id IAA27837; Wed, 18 Aug 1999 08:18:51 -0400 (EDT) Message-Id: <199908181218.IAA27837@istari.sandelman.ottawa.on.ca> To: wsanchez@apple.com Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Your message of "Tue, 17 Aug 1999 19:17:45 PDT." <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Aug 1999 08:18:50 -0400 From: "Michael C. Richardson" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Wilfredo" == Wilfredo Sanchez writes: Wilfredo> I think the desired behaviour would be that since this is Wilfredo> effectively now Joe's zip disk, he should be able to do as he Wilfredo> pleases. One proposal might be to give the console user the Wilfredo> equivalent of root's priveledges on any removeable media he inserts Right now, with MSDOS floppies, with no userids, the user owning the mount point gets his userid applied to the entire disk. This allows me to mount my floppies, etc. on mount points that I own, and I own all the resulting files. I think you want the same thing as an option for UFS mounts. Wilfredo> Presumably the console user is the one fiddling with the external Wilfredo> media. I don't think this is entirely true, and isn't a useful or enforceable restriction. Wilfredo> As another example, a similar situation often comes up on the net Wilfredo> with tar files containing UIDs and GIDs other than zero. Only with SYSV chown semantics that allow non-root to make files not owned by them. Wilfredo> So perhaps there needs to be a way to mark a drive as local Wilfredo> (perhaps with a host ID of some sort?) and noticing when a volume is Wilfredo> "foreign" that you need to do something special. Certainly you might Wilfredo> want to ignore setuid bits, for starters. This could simply be Wilfredo> something like fstab, which lists the local drives, and everything Wilfredo> else isn't considered local. This is solved by having the "nouid" or somesuch thing add to /etc/fstab by the admin who knows which ones should be trusted. Linux provides "user" to get the behaviour that we get for free. Wilfredo> Has anyone dived into this area already and have some experience Wilfredo> with it? It's confusing me pretty good. See what AT&T did with RFS. This may be a negative example (i.e. don't do this). :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 7: 6:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jasper.heartland.ab.ca (jasper.heartland.ab.ca [207.107.228.1]) by hub.freebsd.org (Postfix) with ESMTP id B8FBB14CFB; Wed, 18 Aug 1999 07:06:04 -0700 (PDT) (envelope-from dkwiebe@hagenhomes.com) Received: from freebsd.hagens.ab.ca (ppp2.heartland.ab.ca [207.107.228.130]) by jasper.heartland.ab.ca (8.9.0/8.8.5) with ESMTP id HAA25826; Wed, 18 Aug 1999 07:58:56 -0600 (MDT) Received: from hagenhomes.com (dkwiebe.hagens.ab.ca [10.0.1.3]) by freebsd.hagens.ab.ca (8.9.2/8.9.2) with ESMTP id HAA05690; Wed, 18 Aug 1999 07:16:42 -0600 (MDT) (envelope-from dkwiebe@hagenhomes.com) Message-ID: <37BABED4.C2A966AE@hagenhomes.com> Date: Wed, 18 Aug 1999 08:10:28 -0600 From: Darren WIebe X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: mark+freebsd@xaa.mpn.cp.philips.com Cc: freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD References: <19990818145850.E17189@xaa.mpn.cp.philips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello: One other thing that you might be interested in is the fact that Freemware has its first release out. ***It is not nearly complete yet*** They have something out though, and it needs people to work on the code for FreeBSD. Right now they are working mostly on the Linux stuff where it is OS sensitive. However, it would be appreciated if somebody wanted to work on the FreeBSD specific code. Darren Wiebe > I had a look recently at the code for one of the kernel modules that VMWare > requires (driver-only.tar), and it looks like something that should be > portable to FreeBSD, although there is some messy stuff in it (assembly > that seems to be using Linux specific stuff, brrr..) But anyway: it > looks feasable. > > Is anyone already working on this, or are some people interested in > helping with this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 7:17:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 8466A15894; Wed, 18 Aug 1999 07:17:28 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.2) with ESMTP id JAA55281; Wed, 18 Aug 1999 09:16:29 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 18 Aug 1999 09:16:29 -0500 (CDT) From: Chris Dillon To: Mark Huizer Cc: freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD In-Reply-To: <19990818145850.E17189@xaa.mpn.cp.philips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Mark Huizer wrote: > Hi there, > > I had a look recently at the code for one of the kernel modules that VMWare > requires (driver-only.tar), and it looks like something that should be > portable to FreeBSD, although there is some messy stuff in it (assembly > that seems to be using Linux specific stuff, brrr..) But anyway: it > looks feasable. > > Is anyone already working on this, or are some people interested in > helping with this? > > As far as I can see, the linux emulation is good enough to run the > vmware program, "all" you need to do is implement /dev/vmmon and > /dev/vmnet, given the fact that the code is written really unportable, > so there is some rewriting to be done. Then with the KLD's > vmmon,vmnet and linux you should be able to run vmware. WooHoo! Well, I can't celebrate quite yet, but I'll definately be buying a copy of VMWare if anyone gets this to work (WAY above my head, so no help from me, sorry). More than likely, many people other than myself would also buy a copy of VMWare for Linux just to run under FreeBSD, so maybe you can convince VMWare, Inc. to give you or whoever else decides to tackle this some monetary compensation? It would also help to bring us a step closer to a native FreeBSD version of VMWare, since some (most?) of the work would already be done for them (the porting of vmmon and vmnet). -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:11:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id 329C014EE1 for ; Wed, 18 Aug 1999 08:11:05 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id LAA14942; Wed, 18 Aug 1999 11:11:19 -0400 (EDT) (envelope-from lile@stdio.com) Date: Wed, 18 Aug 1999 11:11:19 -0400 (EDT) From: Larry Lile To: hackers@freebsd.org Cc: dlane@yahoo.com Subject: async v. sync v. default mode on ufs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It was pointed out to me by a co-worker that FreeBSD has actually three modes of operation for mounting ufs filesystems. Could someone please explain to me, and him, the differences between the three. Also does anyone knows how these compare to sync and async on Linux? Just a btw, you seem to be able to set sync and async on a filesystem at the same time. What gives? dlane# mount -u -o sync,async,noatime /var dlane-printer# mount /dev/wd0s1a on / (local, noatime, synchronous, writes: sync 405 async 23) /dev/wd0s1e on /usr (local, noatime, synchronous, writes: sync 118365 async 83882) /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: sync 93 async 216) procfs on /proc (local) dlane# /var looks questionable... I would never try that on purpose, but it just kinda happened, and when I looked at it I though "wow that's broken"! Larry Lile lile@stdio.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 18 8:11:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 9FA16158BA for ; Wed, 18 Aug 1999 08:11:16 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id LAA16512 for ; Wed, 18 Aug 1999 11:11:51 -0400 (EDT) Date: Wed, 18 Aug 1999 11:11:51 -0400 (EDT) From: Bosko Milekic To: freebsd-hackers@freebsd.org Subject: Question(s) regarding sys/vm/swap_pager.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This may seem to be a ridiculous question... (sorry) I have a question specifically regarding sys/vm/swap_pager.c, I'm not very familiar with sys/vm/*, but I've noticed that the value of the static int no_swap_space (which is initially set to 1) is almost never checked. The only times that this value appears to be changed is during checks of vm_swap_size in swap_pager_putpages and swap_pager_copy. Is this value actually ever checked to determine anything? What exactly is its purpose? Thanks, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:15:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 4BEC914DAE for ; Wed, 18 Aug 1999 08:15:48 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA202928 for ; Wed, 18 Aug 1999 09:16:23 -0600 (MDT) Date: Wed, 18 Aug 1999 09:16:23 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <19990817213718.A28662@marvin.ece.utexas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the only portable user ids are names as strings. you can kludge and kludge but at some point the kludges will pile up too high, fall over, and hurt somebody. how many new options did we see proposed in the last 12 hours for this problem? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:19:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id 9FFF914E16 for ; Wed, 18 Aug 1999 08:19:43 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id LAA15363; Wed, 18 Aug 1999 11:18:43 -0400 (EDT) (envelope-from lile@stdio.com) Date: Wed, 18 Aug 1999 11:18:43 -0400 (EDT) From: Larry Lile To: hackers@FreeBSD.ORG Cc: dklane@yahoo.com Subject: Re: async v. sync v. default mode on ufs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I blew the CC: line... On Wed, 18 Aug 1999, Larry Lile wrote: > > It was pointed out to me by a co-worker that FreeBSD has actually > three modes of operation for mounting ufs filesystems. Could someone > please explain to me, and him, the differences between the three. > > Also does anyone knows how these compare to sync and async on Linux? > > Just a btw, you seem to be able to set sync and async on a filesystem > at the same time. What gives? > > dlane# mount -u -o sync,async,noatime /var dlane-printer# mount > /dev/wd0s1a on / (local, noatime, synchronous, writes: sync 405 async 23) > /dev/wd0s1e on /usr (local, noatime, synchronous, writes: sync 118365 > async 83882) > /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: > sync 93 async 216) procfs on /proc (local) > dlane# > > /var looks questionable... > > I would never try that on purpose, but it just kinda happened, and when I > looked at it I though "wow that's broken"! > > Larry Lile > lile@stdio.com > > > > 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 18 8:29:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9DFED14DAE for ; Wed, 18 Aug 1999 08:29:52 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA47500; Wed, 18 Aug 1999 08:30:20 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Aug 1999 08:30:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199908181530.IAA47500@apollo.backplane.com> To: Bosko Milekic Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Question(s) regarding sys/vm/swap_pager.c References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :This may seem to be a ridiculous question... (sorry) : :I have a question specifically regarding sys/vm/swap_pager.c, :I'm not very familiar with sys/vm/*, but I've noticed that the value of :the static int no_swap_space (which is initially set to 1) is almost never :checked. The only times that this value appears to be changed is during :checks of vm_swap_size in swap_pager_putpages and swap_pager_copy. : :Is this value actually ever checked to determine anything? What exactly is :its purpose? : :Thanks, :Bosko. Under -STABLE no_swap_space appears to handle the startup case where swap has not yet been initialized. It prevents paging to swap from occuring until the swap system is both initialized and assigned at least one swap partition. Under -CURRENT this variable does not exist. The vm/swap_pager.c in STABLE has been depreciated - that is, it has been completely rewritten in CURRENT. -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 Wed Aug 18 8:33:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 0C273155B8; Wed, 18 Aug 1999 08:33:12 -0700 (PDT) (envelope-from mark@xaa.mpn.cp.philips.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id RAA18515; Wed, 18 Aug 1999 17:31:26 +0200 (MEST) (envelope-from mark@xaa.mpn.cp.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma018508; Wed, 18 Aug 99 17:31:27 +0200 Received: from xaa.mpn.cp.philips.com (xaa.mpn.cp.philips.com [130.139.64.114]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA27042; Wed, 18 Aug 1999 17:31:25 +0200 (MET DST) Received: by xaa.mpn.cp.philips.com (Postfix, from userid 1000) id 51891505D; Wed, 18 Aug 1999 17:31:24 +0200 (CEST) Date: Wed, 18 Aug 1999 17:31:24 +0200 From: Mark Huizer To: Darren WIebe Cc: mark+freebsd@xaa.mpn.cp.philips.com, freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD Message-ID: <19990818173124.G22394@xaa.mpn.cp.philips.com> Reply-To: mark+freebsd@xaa.mpn.cp.philips.com References: <19990818145850.E17189@xaa.mpn.cp.philips.com> <37BABED4.C2A966AE@hagenhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37BABED4.C2A966AE@hagenhomes.com>; from Darren WIebe on Wed, Aug 18, 1999 at 08:10:28AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 08:10:28AM -0600, Darren WIebe wrote: > Hello: > > One other thing that you might be interested in is the fact that Freemware > has its first release out. ***It is not nearly complete yet*** They have > something out though, and it needs people to work on the code for FreeBSD. > Right now they are working mostly on the Linux stuff where it is OS > sensitive. However, it would be appreciated if somebody wanted to work on the > FreeBSD specific code. I think that for my purpose it might be interesting, but taking way too long to become productive enough. I'm one of the big group of "You must run Outlook!" And I can probably arrange for the license, so no problem with using VMWare if possible. I'd prefer using FreeBSD though mark -- Mark Huizer - Mark.Huizer@nl.origin-it.com - xaa@xaa.iae.nl Faith is good, but skepticism is better (Guiseppe Verdi) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:50:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4ED1E14C27 for ; Wed, 18 Aug 1999 08:50:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA29875; Wed, 18 Aug 1999 08:49:41 -0700 Date: Wed, 18 Aug 1999 08:49:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Christopher Masto , Soren Schmidt , Vince Vielhaber , hackers@FreeBSD.ORG Subject: Re: Onstream? In-Reply-To: <199908180613.AAA16101@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <19990817230910.A6171@netmonger.net> Christopher Masto writes: > : Do they still not allow you to release the specs? How is the code > : going to become part of FreeBSD if they won't allow its release? > > I didn't sign an NDA to get my copy of the spec or the hardware... Neither did I. But I was requested by Jim Jonez of Onstream to not release the specs. > > I also don't have time to devote to the onstream IDE project. I'm > looking for someone with the kernel skills and track record to take > over for me. I thought Soren was doing it... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:52: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E765514CCA; Wed, 18 Aug 1999 08:51:59 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA29888; Wed, 18 Aug 1999 08:51:36 -0700 Date: Wed, 18 Aug 1999 08:51:35 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Christopher Masto , Soren Schmidt , Vince Vielhaber , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Onstream? In-Reply-To: <199908180613.AAA16101@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh- to give my status for the SCSI version: I lost time because the day and ahlf I had allocated to actually work on this got blown away by -current instabilities. I'll try and get another shot at it Sunday (*my* work schedule is such that right now that I don't have an employer I can stick this work for.....) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:55:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 66A6814EC8 for ; Wed, 18 Aug 1999 08:55:50 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA48297; Wed, 18 Aug 1999 09:54:58 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA25436; Wed, 18 Aug 1999 09:54:37 -0600 (MDT) Message-Id: <199908181554.JAA25436@harmony.village.org> To: mjacob@feral.com Subject: Re: Onstream? Cc: Christopher Masto , Soren Schmidt , Vince Vielhaber , hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 18 Aug 1999 08:49:40 PDT." References: Date: Wed, 18 Aug 1999 09:54:37 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Neither did I. But I was requested by Jim Jonez of Onstream to not release : the specs. Same here... Just pointing out that OnStream is being cooperative. : > I also don't have time to devote to the onstream IDE project. I'm : > looking for someone with the kernel skills and track record to take : > over for me. : : I thought Soren was doing it... He is, but since I also have hardware and docs to contribute to the effort and since I didn't have time, I thought I'd not horde the hardware if there was someone out there that did have the time and would be willing and able to help out. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 8:57:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gbtb.com (modem3.tekrab.net [208.30.20.203]) by hub.freebsd.org (Postfix) with ESMTP id 120F414C27 for ; Wed, 18 Aug 1999 08:57:07 -0700 (PDT) (envelope-from mrami@gbtb.com) Received: from localhost (mrami@localhost) by gbtb.com (8.9.3/8.9.3) with ESMTP id LAA30533; Wed, 18 Aug 1999 11:55:48 -0400 (EDT) (envelope-from mrami@gbtb.com) Date: Wed, 18 Aug 1999 11:55:48 -0400 (EDT) From: Marc Ramirez X-Sender: mrami@mrami.ghostgbtb.com To: David Malone Cc: Bill Sommerfeld , freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <19990818130126.A77917@walton.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, David Malone wrote: > On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > > Oh! I was under the impression that it just didn't work, even with > > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > > time! > > You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I > think. So it is. Thanks. Marc. -- Marc Ramirez - Owner Great Big Throbbing Brains mrami@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 9:15:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 7B7C814ED8; Wed, 18 Aug 1999 09:15:15 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id RAA66764; Wed, 18 Aug 1999 17:15:41 +0100 (BST) (envelope-from joe) Date: Wed, 18 Aug 1999 17:15:41 +0100 From: Josef Karthauser To: Chris Dillon Cc: Mark Huizer , freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD Message-ID: <19990818171541.A80710@pavilion.net> References: <19990818145850.E17189@xaa.mpn.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Chris Dillon on Wed, Aug 18, 1999 at 09:16:29AM -0500 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 09:16:29AM -0500, Chris Dillon wrote: > On Wed, 18 Aug 1999, Mark Huizer wrote: > > > Hi there, > > > > I had a look recently at the code for one of the kernel modules that VMWare > > requires (driver-only.tar), and it looks like something that should be > > portable to FreeBSD, although there is some messy stuff in it (assembly > > that seems to be using Linux specific stuff, brrr..) But anyway: it > > looks feasable. > > > > Is anyone already working on this, or are some people interested in > > helping with this? > > > > As far as I can see, the linux emulation is good enough to run the > > vmware program, "all" you need to do is implement /dev/vmmon and > > /dev/vmnet, given the fact that the code is written really unportable, > > so there is some rewriting to be done. Then with the KLD's > > vmmon,vmnet and linux you should be able to run vmware. > > WooHoo! Well, I can't celebrate quite yet, but I'll definately be > buying a copy of VMWare if anyone gets this to work (WAY above my > head, so no help from me, sorry). More than likely, many people other > than myself would also buy a copy of VMWare for Linux just to run > under FreeBSD, so maybe you can convince VMWare, Inc. to give you or > whoever else decides to tackle this some monetary compensation? It > would also help to bring us a step closer to a native FreeBSD version > of VMWare, since some (most?) of the work would already be done for > them (the porting of vmmon and vmnet). We will _definitely_ buy VMWare if we can run it on a FreeBSD host system - I believe that I've told them so in the past. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 9:53:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id B026E14F0E for ; Wed, 18 Aug 1999 09:53:25 -0700 (PDT) (envelope-from wsanchez@scv1.apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA22586 for ; Wed, 18 Aug 1999 09:52:30 -0700 Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Wed, 18 Aug 1999 09:30:45 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id JAA25969; Wed, 18 Aug 1999 09:30:45 -0700 (PDT) Message-Id: <199908181630.JAA25969@scv1.apple.com> To: "Daniel O'Connor" Subject: Re: RE: Need some advice regarding portable user IDs Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com In-Reply-To: <199908180508.WAA55082@scv4.apple.com> Date: Wed, 18 Aug 1999 09:30:48 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > when new media is available and it will try to mount it. The present | > behaviour in Mac OS X Server is that everything mounted this way is | > trusted, though the Finder should be requesting nosetuid; I should | > check that. It's also possible that the kernel will number drives in | > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next | > boot), particularly if you are shuffling drives around. (Remember | > that hot-swap complicates this.) So a string like "/dev/sd0a" in | > fstab is fragile, and it works out better if we keep that information | > on the mounted media rather than on the root volume. | | What happens with conflicting names? Append "_1", "_2", etc. -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 9:54:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 0505D14F0E for ; Wed, 18 Aug 1999 09:54:15 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 15221 invoked from network); 18 Aug 1999 16:54:02 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 18 Aug 1999 16:54:02 -0000 Date: Wed, 18 Aug 1999 09:52:39 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: Steven Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenLDAP tests? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Found it. This let the tests run fine for me. =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/daemon.c,v retrieving revision 1.14.2.7.2.8 retrieving revision 1.14.2.7.2.9 diff -u -r1.14.2.7.2.8 -r1.14.2.7.2.9 --- servers/slapd/daemon.c 1999/03/02 18:30:05 1.14.2.7.2.8 +++ servers/slapd/daemon.c 1999/07/20 05:10:35 1.14.2.7.2.9 @@ -390,7 +390,6 @@ void slap_set_shutdown( int sig ) { - Debug( LDAP_DEBUG_ANY, "slapd got shutdown signal %d\n", sig, 0, 0 ); slapd_shutdown = 1; ldap_pvt_thread_kill( listener_tid, LDAP_SIGUSR1 ); @@ -401,8 +400,6 @@ void slap_do_nothing( int sig ) { - Debug( LDAP_DEBUG_TRACE, "slapd got do_nothing signal %d\n", sig, 0, 0 ); - /* reinstall self */ (void) SIGNAL( sig, slap_do_nothing ); } On Wed, 18 Aug 1999, Steven Ames wrote: > Thanks! I'll check the site (but would appreciate your sending it to me > also). > > -Steve > > On Tue, 17 Aug 1999, Jaye Mathisen wrote: > > > > > There is a patch that fixes this, I found it, and submitted a bug report > > on their web page. > > > > I don't have it handy, but if you go to www.openldap.org and to their > > faq-o-matic, and it should be in there. > > > > I'll see if I can find it and send it to you in the mean time. > > > > On Tue, 17 Aug 1999, Steven Ames wrote: > > > > > > > > I've got a project at work where using LDAP would make my life > > > much simpler. So... on my home PC (running FBSD 4.0-CURRENT 8.2.99) > > > I installed openldap from the ports collection (V1.2.3...ports cvsuped > > > about an hour ago from cvsup5.freebsd.org). > > > > > > I cd into the test area /usr/ports/work/ldap/tests and type 'make'. > > > Looking good... until... on test0003-search it stops. It just holds. > > > My CPU is up to 99% and its chewed up 18 minutes of CPU before I hit > > > Ctrl-C and stopped it. I did a 'make clean' moved scripts/test0003-seach > > > to scripts/test0009-search (so it would run last) and tried again. > > > Same results on test0004-modify. *sigh* > > > > > > Do the tests just not run? I didn't dare to just go ahead and use it > > > as I'm not familiar enough with LDAP to judge if a failure is my fault > > > or a system problem. I'd feel a lot safer if the tests all passed so that > > > if anything goes wrong from that point I can call it user error. > > > > > > Anyone? > > > > > > -Steve > > > > > > > > > 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 18 10:19: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C52FF14C80; Wed, 18 Aug 1999 10:18:58 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id KAA01747; Wed, 18 Aug 1999 10:16:59 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd001627; Wed Aug 18 10:16:51 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA12220; Wed, 18 Aug 1999 10:16:46 -0700 (MST) From: Terry Lambert Message-Id: <199908181716.KAA12220@usr02.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 18 Aug 1999 17:16:46 +0000 (GMT) Cc: tlambert@primenet.com, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Aug 17, 99 11:18:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > > > routines in NetBSD point to error routines. > > > > In FreeBSD, they now point to default routines that are *not* error > > routines. This is the problem. I admit the change was very well > > intentioned, since it made the code a hell of a lot more readable, > > but choosing between readable and additional function, I take function > > over form (I think the way I would have "fixed" the readability is by > > making the operations that result in the descriptor set for a mounted > > FS instance be both discrete, and named for their specific function). > > As I recall most of FBSD's default routines are also error routines, if > the exceptions were a problem it would would be trivial to fix. You would have to de-collapse several VOP lists that have been pre-collapsed. The pre-collapse is also an issue for stacking, since the collapse is supposed to be late bound to the stacking operation itself. This lets you revisit it later when you need to add a new VOP into the system, so that there's a NULL pointer in the VOP slot for older FS's, in case you stack on top of them. This is particularly true of an FS stacked on an FS stacked on a proxy layer. > I think fixing resource allocation/deallocation for things like vnodes, > cnbufs, and locks are a higher priority for now. There are examples such > as in detached threading where it might make sense for the detached child > to be responsible for releasing resources allocated to it by the parent, > but in stacking this model is very messy and unnatural. This is why the > purpose of VOP_ABORTOP appears to be to release cnbufs but this is really > just an ugly side effect. With stacking the code that allocates should be > the code that deallocates. Substitute, "code" with "layer" to be more > correct. Yes. That's actually maintenance, not rewrite, and I think it's very important to address. I'm rather pleased with the way the NFS stuff has turned out (so far), and I was the one calling for a return to first principles (i.e. a rewrite from the specification). > I fixed a lot of the vnode and locking cases, unfortunately the ones that > remain are probably ugly cases where you have to reacquire locks that had > to be unlocked somewhere in the executing layer. See VOP_RENAME for an > example. Compare the number of WILLRELEs in vnode_if.src in FreeBSD and > NetBSD, ideally there'd be none. The way I handled this in the rename case on my hacking box was by adding a flag to the namei() call. You could call this flag the same as WILLRELE, but it had inverse semantics. Really, this is another issue of reflexivity being absent from an interface. You really don't want asymmetric interfaces (VOP_LOCK is an example, in many cases, based on internal use in the FFS). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 10:27:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 58B2B14C80; Wed, 18 Aug 1999 10:27:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA01171; Wed, 18 Aug 1999 19:24:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: michaelh@cet.co.jp (Michael Hancock), wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 17:16:46 -0000." <199908181716.KAA12220@usr02.primenet.com> Date: Wed, 18 Aug 1999 19:24:04 +0200 Message-ID: <1169.934997044@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908181716.KAA12220@usr02.primenet.com>, Terry Lambert writes: >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc >> > > routines in NetBSD point to error routines. >> > >> > In FreeBSD, they now point to default routines that are *not* error >> > routines. This is the problem. I admit the change was very well >> > intentioned, since it made the code a hell of a lot more readable, >> > but choosing between readable and additional function, I take function >> > over form (I think the way I would have "fixed" the readability is by >> > making the operations that result in the descriptor set for a mounted >> > FS instance be both discrete, and named for their specific function). >> >> As I recall most of FBSD's default routines are also error routines, if >> the exceptions were a problem it would would be trivial to fix. > >You would have to de-collapse several VOP lists that have been >pre-collapsed. You are talking gibberish here. Please show code where this is a problem. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 10:31: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id CAB8914F2D; Wed, 18 Aug 1999 10:31:02 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id KAA16496; Wed, 18 Aug 1999 10:30:39 -0700 (PDT) Date: Wed, 18 Aug 1999 10:30:39 -0700 (PDT) From: Bill Studenmund To: Poul-Henning Kamp Cc: Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <830.934961572@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > In message , Bill > Studenmund writes: > >On Sat, 14 Aug 1999, Terry Lambert wrote: > > Matt doesn't represent the FreeBSD project, and even if he rewrites > the VFS subsystem so he can understand it, his rewrite would face > considerable resistance on its way into FreeBSD. I don't think > there is reason to rewrite it, but there certainly are areas > that need fixing. Whew! That's reasuring. I agree there are things which need fixing. It'd be nice if both NetBSD and FreeBSD could fix things in the same way. > >> The use of the "vfs_default" to make unimplemented VOP's > >> fall through to code which implements function, while well > >> intentioned, is misguided. > > I beg to differ. The only difference is that we pass through > multiple layers before we hit the bottom of the stack. There is > no loss of functionality but significant gain of clarity and > modularity. If I understood the issue, it is that the leaf fs's (the bottom ones) would use a default routine for non-error functionality. I think Terry's point (which I agree with) was that a leaf fs's default routine should only return errors. > >> 3. The filesystem itself is broken for Y2038 > >One other suggestion I've heard is to split the 64 bits we have for time > >into 44 bits for seconds, and 20 bits for microseconds. That's more than > >enough modification resolution, and also pushes things to past year > >500,000 AD. Versioning the indoe would cover this easily. > > This would be misguided, and given the current speed of evolution > lead to other problems far before 2038. > > Both struct timespec and struct timeval are major mistakes, they > make arithmetic on timestamps an expensive operation. Timestamps > should be stored as integers using an fix-point notations, for > instance 64bits with 32bit fractional seconds (the NTP timestamp), > or in the future 128/48. I like that idea. One thing I should probably mention is that I'm not suggesting we ever do arighmetic on the 44/20 number, just we store it that way. struct inode would contain time fields in whatever format the host prefers, with the 44/20 stuff only being in struct dinode. Converting from 44/20 would only happen on initial read. Math would happen on the host format version. :-) If time structures go to 64/32 fixed-point math, then my suggestion can be re-phrased as storing 44.20 worth of that number in the on-disk inode. > Extending from 64 to 128bits would be a cheap shift and increased > precision and range could go hand in hand. I doubt we need more than 64 bit times. 2^63 seconds works out to 292,279,025,208 years, or 292 (american) billion years. Current theories put the age of the universe at I think 12 to 16 billion years. So 64-bit signed times in seconds will cover from before the big bang to way past any time we'll be caring about. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 10:36:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6636614C90; Wed, 18 Aug 1999 10:36:14 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA01242; Wed, 18 Aug 1999 19:36:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bill Studenmund Cc: Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 10:30:39 PDT." Date: Wed, 18 Aug 1999 19:36:22 +0200 Message-ID: <1240.934997782@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bill Studenmund writes: >Whew! That's reasuring. I agree there are things which need fixing. It'd >be nice if both NetBSD and FreeBSD could fix things in the same way. Well, >that< still remains to be seen... >> >> The use of the "vfs_default" to make unimplemented VOP's >> >> fall through to code which implements function, while well >> >> intentioned, is misguided. >> >> I beg to differ. The only difference is that we pass through >> multiple layers before we hit the bottom of the stack. There is >> no loss of functionality but significant gain of clarity and >> modularity. > >If I understood the issue, it is that the leaf fs's (the bottom ones) >would use a default routine for non-error functionality. I think Terry's >point (which I agree with) was that a leaf fs's default routine should >only return errors. I beg to differ. It is far more likely, in my mind, that you will want to handle a currently existing, unimplemented VOP than add a new one. Using the default for >all< unimplemented VOPs makes this possible, using the same logic which makes adding a VOP possible. Go back and review the diffs from when I did this, and my other argument why this is a good idea should be obvious. >I doubt we need more than 64 bit times. 2^63 seconds works out to >292,279,025,208 years, or 292 (american) billion years. Current theories >put the age of the universe at I think 12 to 16 billion years. So 64-bit >signed times in seconds will cover from before the big bang to way past >any time we'll be caring about. :-) But we cannot do time in seconds resolution, we need to resolve at least the cpu clock frequency, which right now is approaching 1GHz (30bit!) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 10:40:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B48D614C18 for ; Wed, 18 Aug 1999 10:40:13 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA00793; Wed, 18 Aug 1999 11:37:46 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA03569; Wed, 18 Aug 1999 11:37:46 -0600 Date: Wed, 18 Aug 1999 11:37:46 -0600 Message-Id: <199908181737.LAA03569@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Studenmund Cc: Poul-Henning Kamp , Terry Lambert , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: References: <830.934961572@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Both struct timespec and struct timeval are major mistakes, they > > make arithmetic on timestamps an expensive operation. Timestamps > > should be stored as integers using an fix-point notations, for > > instance 64bits with 32bit fractional seconds (the NTP timestamp), > > or in the future 128/48. ... > > > Extending from 64 to 128bits would be a cheap shift and increased > > precision and range could go hand in hand. > > I doubt we need more than 64 bit times. 2^63 seconds works out to > 292,279,025,208 years, or 292 (american) billion years. I think Poul's point is that in the future seconds is probably way too coarse grained. Computer's are getting faster all the time, and in the future we may need 64 seconds, plus an additional 64 bits for the fractions of a second, which will be necessary for accurate timekeeping. 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 18 10:56: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id F1C6C14D15; Wed, 18 Aug 1999 10:55:54 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id KAA19003; Wed, 18 Aug 1999 10:56:27 -0700 (PDT) Date: Wed, 18 Aug 1999 10:56:27 -0700 (PDT) From: Bill Studenmund To: Poul-Henning Kamp Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <1240.934997782@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > In message , Bill Studenmund writes: > > >Whew! That's reasuring. I agree there are things which need fixing. It'd > >be nice if both NetBSD and FreeBSD could fix things in the same way. > > Well, >that< still remains to be seen... :-) > >I doubt we need more than 64 bit times. 2^63 seconds works out to > >292,279,025,208 years, or 292 (american) billion years. Current theories > >put the age of the universe at I think 12 to 16 billion years. So 64-bit > >signed times in seconds will cover from before the big bang to way past > >any time we'll be caring about. :-) I was unclear. I was refering to the seconds side of things. Sub-second resolution would need other bits. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11: 5: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 71A30150C5 for ; Wed, 18 Aug 1999 11:04:58 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA01336; Wed, 18 Aug 1999 20:03:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: nate@mt.sri.com (Nate Williams) Cc: Bill Studenmund , Terry Lambert , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 11:37:46 MDT." <199908181737.LAA03569@mt.sri.com> Date: Wed, 18 Aug 1999 20:03:21 +0200 Message-ID: <1334.934999401@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908181737.LAA03569@mt.sri.com>, Nate Williams writes: >> > Both struct timespec and struct timeval are major mistakes, they >> > make arithmetic on timestamps an expensive operation. Timestamps >> > should be stored as integers using an fix-point notations, for >> > instance 64bits with 32bit fractional seconds (the NTP timestamp), >> > or in the future 128/48. >... >> >> > Extending from 64 to 128bits would be a cheap shift and increased >> > precision and range could go hand in hand. >> >> I doubt we need more than 64 bit times. 2^63 seconds works out to >> 292,279,025,208 years, or 292 (american) billion years. > >I think Poul's point is that in the future seconds is probably way too >coarse grained. Computer's are getting faster all the time, and in the >future we may need 64 seconds, plus an additional 64 bits for the >fractions of a second, which will be necessary for accurate timekeeping. No, 64bits of fractions will not be needed, at least until we start using FreeBSD as embedded computer in Heisenbergcompensators. I recall somebody saying that 100GHz was the highest realistic (or lowest unrealistic) clock frequency using digital logic, the argument was pretty convincing physically: light speed sets a size limit, that prescripes some voltage gradients which in turn produces EMC which in turn makes sure nothing works. Also various tunnel effects, and the general heisenberisms took their toll. State of the art time interval measuring equipment is into the "a few picosecond" territory (http://www.timing.com/). Based on that I would say that 40 to 48 bits will be OK for the fraction. As a sidebar: I had a kernel running which used 32i.32f timestamps and converted to timeval & timespec as needed and it actually made a lot of code look a lot more sane. I may go back and do it some day. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11: 6:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0FF5C14F5D; Wed, 18 Aug 1999 11:06:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA01364; Wed, 18 Aug 1999 20:04:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bill Studenmund Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 10:56:27 PDT." Date: Wed, 18 Aug 1999 20:04:49 +0200 Message-ID: <1362.934999489@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bill Studenmund writes: >> >I doubt we need more than 64 bit times. 2^63 seconds works out to >> >292,279,025,208 years, or 292 (american) billion years. Current theories >> >put the age of the universe at I think 12 to 16 billion years. So 64-bit >> >signed times in seconds will cover from before the big bang to way past >> >any time we'll be caring about. :-) > >I was unclear. I was refering to the seconds side of things. Sub-second >resolution would need other bits. Yes, but we need subsecond in the filesystems. Think about make(1) on a blinding fast machine... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11: 8: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 13FD81505D; Wed, 18 Aug 1999 11:07:53 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA09356; Wed, 18 Aug 1999 11:00:47 -0700 (PDT) Date: Wed, 18 Aug 1999 11:01:58 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <830.934961572@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > Matt doesn't represent the FreeBSD project, and even if he rewrites > the VFS subsystem so he can understand it, his rewrite would face > considerable resistance on its way into FreeBSD. I don't think > there is reason to rewrite it, but there certainly are areas > that need fixing. You are misinformed as far as I know.. From discussions I saw, th main architect of a VFS rewrite would be Kirk, and Matt would be acting as Kirk's right-hand-man. > > >> The use of the "vfs_default" to make unimplemented VOP's > >> fall through to code which implements function, while well > >> intentioned, is misguided. > > I beg to differ. The only difference is that we pass through > multiple layers before we hit the bottom of the stack. There is > no loss of functionality but significant gain of clarity and > modularity. Well I believe that Kirk considers them misguided too, but he stated that he wasn't going to remove them without serious thought about the alternatives. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:14:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id D819914E6F for ; Wed, 18 Aug 1999 11:14:15 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA01155; Wed, 18 Aug 1999 12:13:09 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA03840; Wed, 18 Aug 1999 12:13:09 -0600 Date: Wed, 18 Aug 1999 12:13:09 -0600 Message-Id: <199908181813.MAA03840@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: References: <830.934961572@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Matt doesn't represent the FreeBSD project, and even if he rewrites > > the VFS subsystem so he can understand it, his rewrite would face > > considerable resistance on its way into FreeBSD. I don't think > > there is reason to rewrite it, but there certainly are areas > > that need fixing. > > You are misinformed as far as I know.. From discussions I saw, th > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > Kirk's right-hand-man. Which discussions are these? Are they archived somewhere? 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 18 11:16: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 68E981505D; Wed, 18 Aug 1999 11:15:54 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA01443; Wed, 18 Aug 1999 20:15:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 11:01:58 PDT." Date: Wed, 18 Aug 1999 20:15:59 +0200 Message-ID: <1441.935000159@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Julian Elischer writes: >On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > >> Matt doesn't represent the FreeBSD project, and even if he rewrites >> the VFS subsystem so he can understand it, his rewrite would face >> considerable resistance on its way into FreeBSD. I don't think >> there is reason to rewrite it, but there certainly are areas >> that need fixing. > >You are misinformed as far as I know.. From discussions I saw, th >main architect of a VFS rewrite would be Kirk, and Matt would be acting as >Kirk's right-hand-man. I bet that Matt and Kirk uses "rewrite" for two very different concepts. The resulting reviews will be equally different. >> >> The use of the "vfs_default" to make unimplemented VOP's >> >> fall through to code which implements function, while well >> >> intentioned, is misguided. >> >> I beg to differ. The only difference is that we pass through >> multiple layers before we hit the bottom of the stack. There is >> no loss of functionality but significant gain of clarity and >> modularity. > >Well I believe that Kirk considers them misguided too, but he stated that >he wasn't going to remove them without serious thought about the alternatives. I'll be more than ready to discuss this with Kirk. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:20:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id C51B81595D; Wed, 18 Aug 1999 11:20:18 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA04794; Wed, 18 Aug 1999 11:19:40 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAFFaOvj; Wed Aug 18 11:19:33 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA14096; Wed, 18 Aug 1999 11:19:43 -0700 (MST) From: Terry Lambert Message-Id: <199908181819.LAA14096@usr02.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov Date: Wed, 18 Aug 1999 18:19:42 +0000 (GMT) Cc: tlambert@primenet.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: from "Bill Studenmund" at Aug 17, 99 01:44:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > 2. Advisory locks are hung off private backing objects. > > > I'm not sure. The struct lock * is only used by layered filesystems, so > > > they can keep track both of the underlying vnode lock, and if needed their > > > own vnode lock. For advisory locks, would we want to keep track both of > > > locks on our layer and the layer below? Don't we want either one or the > > > other? i.e. layers bypass to the one below, or deal with it all > > > themselves. > > > > I think you want the lock on the intermediate layer: basically, on > > every vnode that has data associated with it that is unique to a > > layer. Let's not forget, also, that you can expose a layer into > > the namespace in one place, and expose it covered under another > > layer, at another. If you locked down to the backing object, then > > the only issue you would be left with is one or more intermediate > > backing objects. > > Right. That exported struct lock * makes locking down to the lowest-level > file easy - you just feed it to the lock manager, and you're locking the > same lock the lowest level fs uses. You then lock all vnodes stacked over > this one at the same time. Otherwise, you just call VOP_LOCK below and > then lock yourself. I think this defeats the purpose of the stacking architecture; I think that if you look at an unadulterated NULLFS, you'll see what I mean. Intermediate FS's should not trap VOP's that are not applicable to them. One of the purposes of doing a VOP_LOCK on intermediate vnodes that aren't backing objects is to deal with the global vnode pool management. I'd really like FS's to own their vnode pools, but even without that, you don't need the locking, since you only need to flush data on vnodes that are backing objects. If we look at a stack of FS's with intermediate exposure into the namespace, then it's clear that the issue is really only applicable to objects that act as a backing store: ---------------------- ---------------------- -------------------- FS Exposed in hierarchy Backing object ---------------------- ---------------------- -------------------- top yes no intermediate_1 no no intermediate_2 no yes intermediate_3 yes no bottom no yes ---------------------- ---------------------- -------------------- So when we lock "top", we only lock in intermediate_2 and in bottom. Then we attempt to lock in intermediate_3, but it fails: not because there is a lock on the vnode in intermediate_3, but because there is a lock in bottom. It's unnecessary to lock the vnodes in the intermediate path, or even at the exposure level, unless they are vnodes that have an associated backing store. The need to lock in intermediate_2 exists because it is a translation layer or a namespace escape. It deals with compression, or it deals with file-as-a-directory folding, or it deals with file-hiding (perhaps for a quoata file), etc.. If it didn't, it wouldn't need backing store (and therefore wouldn't need to be locked). > > For a layer with an intermediate backing object, I'm prepared to > > declare it "special", and proxy the operation down to any inferior > > backing object (e.g. a union FS that adds files from two FS's > > together, rather than just directoriy entry lists). I think such > > layers are the exception, not the rule. > > Actually isn't the only problem when you have vnode fan-in (union FS)? > i.e. a plain compressing layer should not introduce vnode locking > problems. If it's a block compression layer, it will. Also a translation layer; consider a pure Unicode system that wants to remotely mount an FS from a legacy system. To do this, it needs to expand the pages from the legacy system [only it can, since the legacy system doesn't know about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock on a file on such a system. To propogate the lock, you have to do an arithmetic conversion at the translation layer. This gets worse if the lower end FS is exposed in the namespace as well. You could make the same arguments for other types of translation or namespace escapes. > > I think that export policies are the realm of /etc/exports. > > > > The problem with each FS implementing its own policy, is that this > > is another place that copyinstr() gets called, when it shouldn't. > > Well, my thought was that, like with current code, most every fs would > just call vfs_export() when it's presented an export operation. But by > retaining the option of having the fs do its own thing, we can support > different export semantics if desired. I think this bears down on whether the NFS server VFS consumer is allowed access to the VFS stack at the particular intermediate layer. I think this is really an administrative policy decision, and not an option for the VFS. I think it would be bad if a given VFS could refuse to participate in a stacking operation because it didn't like who was stacking. If we insist on the ability for a VFS to refused stacking, then we should generalize the idea, such that an intermediate VFS could refuse exposure into the filesystem namespace accessible to users. Consider the case of a VFS without quota support, stacked under a VFS layer that provided quota support by hiding a file in the top level directory ("quota") and then folding the directory closed by rerooting in a subdirectory of the top level directory ("root/"). It's reasonable to assume that most admins that want to enforce quotas would *not* want the possibility of exposing the VFS without quota support in the user accessible namespace. Should the VFS without quotas refuse such exposure? I think the answer is "no", and that it is an administrative control issue, not a VFS's preference issue. Administrators enforce this by protecting the path to exposure points, or by mounting stacks over top of exposure points, which results in the exposure being hidden under another mount. Using the QUOTAFS example, you mount the FS to be quota-enforced on /home, and then you mount the QUOTAFS over top of it, and have it cover "/home" itself, hiding the underlying FS from exposure. > > I would resolve this by passing a standard option to the mount code > > in user space. For root mounts, a vnode is passed down. For other > > mounts, the vnode is parsed and passed if the option is specified. > > Or maybe add a field to vfsops. This info says what the mount call will > expect (I want a block device, a regular file, a directory, etc), so it > fits. :-) This is actually an elegant soloution to the problem. Much of the time, we don't consider data interfaces when they are appropriate because of their widespread use in inappropriate ways (e.g. "ps"). > Also, if we leave it to userland, what happens if someone writes a > program which calls sys_mount with something the fs doesn't expect. :-) Well, that gets to another grail of mine: when a device containing a filesystem "arrives", I believe it should trigger a mount into the list of mounted filesystems. I don't necessarily mean that it should also be exported into the filesystem hierarchy at that point (but it's an option, using the "last mounted on" information). > > I think that you will only be able to find rare examples of FS's > > that don't take device names as arguments. But for those, you > > don't specify the option, and it gets "NULL", and whatever local > > options you specify. > > I agree I can't see a leaf fs not taking a device node. But layered > fs's certainly will want something else. :-) I think they want a vnode of an already mounted FS. The trick is to enforce the "already mounted" part of that. I'm comforable with doing this by saying "it's not already mounted until you can look up a vnode on it". > > The point is that, for FS's that can be both root and sub-root, > > the mount code doesn't have to make the decision, it can be punted > > to higher level code, in one place, where the code can be centrally > > maintained and kept from getting "stale" when things change out > > from under it. > > True. > > And with good comments we can catch the times when the centrally located > code changes & brakes an assumption made by the fs. :-) 8-). > > > Except for a minor buglet with device nodes, stacking works in NetBSD at > > > present. :-) > > > > Have you tried Heidemann's student's stacking layers? There is one > > encryption, and one per-file compression with namespace hiding, that > > I think it would be hard pressed to keep up with. But I'll give it > > the benefit of the doubt. 8-). > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > work, we don't have the coherency issues worked out so that upper layers > can cache data. i.e. so that the lower fs knows it has to ask the uper > layers to give pages back. :-) But multiple ls -lR's work fine. :-) With UVM in NetBSD, this is (supposedly) not an issue. You could actually think of it this way, as well: only FS's that contain vnodes that provide backing should implement VOP_GETPAGES and VOP_PUTPAGES, and all I/O should be done through paging. > > > I agree it's ugly, but it has the advantage that it doesn't grow the > > > on-disk inode. A lot of flks have designs on the remaining 64 bits free. > > > :-) > > > > Well, so long as we can resolve the issue for a long, long time; > > I plan on being around to have to put up with the bugs, if I can > > wrangle it... 8-). > > :-) > > I bet by then (559447 AD) we won't be using ffs, so the problem will be > moot. :-) Unless I'm the curator of a computer museum... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:23:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7878C1597A; Wed, 18 Aug 1999 11:23:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA48344; Wed, 18 Aug 1999 11:22:20 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Aug 1999 11:22:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199908181822.LAA48344@apollo.backplane.com> To: Julian Elischer Cc: Poul-Henning Kamp , Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: : :> Matt doesn't represent the FreeBSD project, and even if he rewrites :> the VFS subsystem so he can understand it, his rewrite would face :> considerable resistance on its way into FreeBSD. I don't think :> there is reason to rewrite it, but there certainly are areas :> that need fixing. : :You are misinformed as far as I know.. From discussions I saw, th :main architect of a VFS rewrite would be Kirk, and Matt would be acting as :Kirk's right-hand-man. Yes, this is correct. Kirk is going to be the main architect. I have been heavily involved and will continue to be. :> >> The use of the "vfs_default" to make unimplemented VOP's : :> I beg to differ. The only difference is that we pass through :> multiple layers before we hit the bottom of the stack. There is :... :Well I believe that Kirk considers them misguided too, but he stated that :he wasn't going to remove them without serious thought about the alternatives. The vfs op callout layering has not been on the radar screen. There are much too many other more serious problems. I really doubt that any changes will be made to this piece any time in the next year or even two, if at all. The main items on the radar screen are related to buffer management (struct buf stuff. For example, preventing VM blockages due to pages being wired by write I/O's), VFS locking and reference count issues (for example, namei lookups, blockages in the pager and syncer due to vnode locks held by blocked processes, etc...), and interactions between VFS and VM (for example: moving away from VOP_READ/VOP_WRITE and moving more towards a getpages/putpages model). None of the items have been set in stone yet. We're waiting for Kirk to get back from vacation and get back into the groove. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:37: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 73E8514F8A for ; Wed, 18 Aug 1999 11:36:50 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA10531; Wed, 18 Aug 1999 11:34:05 -0700 (PDT) Date: Wed, 18 Aug 1999 11:35:17 -0700 (PDT) From: Julian Elischer To: Nate Williams Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908181813.MAA03840@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The discussions between Kirk and matt over a glass of beer/drink at kirk's party at USENIX and at the Bay area User's group. On Wed, 18 Aug 1999, Nate Williams wrote: > > > Matt doesn't represent the FreeBSD project, and even if he rewrites > > > the VFS subsystem so he can understand it, his rewrite would face > > > considerable resistance on its way into FreeBSD. I don't think > > > there is reason to rewrite it, but there certainly are areas > > > that need fixing. > > > > You are misinformed as far as I know.. From discussions I saw, th > > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > > Kirk's right-hand-man. > > Which discussions are these? Are they archived somewhere? > > > 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 18 11:41:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id 2E3E115063; Wed, 18 Aug 1999 11:41:11 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-154-215.dsl.hstntx.swbell.net) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FGO00E6VBSYBO@mta2.rcsntx.swbell.net>; Wed, 18 Aug 1999 13:38:58 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id NAA98793; Wed, 18 Aug 1999 13:40:17 -0500 (CDT envelope-from chris) Date: Wed, 18 Aug 1999 13:40:16 -0500 From: Chris Costello Subject: Re: cvs commit: src/bin/test test.c In-reply-to: <15808.934968957@axl.noc.iafrica.com>; from Sheldon Hearn on Wed, Aug 18, 1999 at 11:35:57AM +0200 To: Sheldon Hearn Cc: Brian Feldman , hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19990818134016.E97181@holly.dyndns.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i References: <199908180018.RAA84904@freefall.freebsd.org> <15808.934968957@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999, Sheldon Hearn wrote: > > green 1999/08/17 17:18:53 PDT > > > > Modified files: > > bin/test test.c > > Log: > > The new test(1) did not use access() correctly. I don't know why, since > > supposedly it's ksh-derived, and it's not broken in pdksh. I've added > > a test for test running as root: if testing for -x, the file must be > > mode & 0111 to get "success", rather than just existant. > > > > Reviewed by: chris > > What were you actually trying to fix, here? I didn't see any discussion > of this on hackers, current or bugs, nor in response to my initial > commit message. He was "fixing" (though, as Bruce pointed out, it wasn't a valid fix) test -x. Apparently, access(2) will return 'success' on access(file, X_OK) if called by a program run by root. The patch partly solves the problem, but the euid-vs-ruid problem remains. -- |Chris Costello |Disc space, the final frontier! `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:48: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9761B14F8A; Wed, 18 Aug 1999 11:47:54 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA08775; Wed, 18 Aug 1999 11:48:06 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd008709; Wed Aug 18 11:48:03 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA14960; Wed, 18 Aug 1999 11:48:01 -0700 (MST) From: Terry Lambert Message-Id: <199908181848.LAA14960@usr02.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 18 Aug 1999 18:48:01 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <1169.934997044@critter.freebsd.dk> from "Poul-Henning Kamp" at Aug 18, 99 07:24:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > >> > > routines in NetBSD point to error routines. > >> > > >> > In FreeBSD, they now point to default routines that are *not* error > >> > routines. This is the problem. I admit the change was very well > >> > intentioned, since it made the code a hell of a lot more readable, > >> > but choosing between readable and additional function, I take function > >> > over form (I think the way I would have "fixed" the readability is by > >> > making the operations that result in the descriptor set for a mounted > >> > FS instance be both discrete, and named for their specific function). > >> > >> As I recall most of FBSD's default routines are also error routines, if > >> the exceptions were a problem it would would be trivial to fix. > > > >You would have to de-collapse several VOP lists that have been > >pre-collapsed. > > You are talking gibberish here. Please show code where this is > a problem. When you write a proxy stacking layer, such as John Heidemann's network proxy stacking layer (an NFS alternative), VOP's which would normally be handled by vfs_default have to be handled on the other end of the proxy, instead, in the same way that they would be handled by the vfs_default stuff. Some VOP's, like advisory locking, need both local assertion and remote proxy of the VOP to avoid introducing race windows. The result of this is that, if you rely on the vfs_default stuff, then you can't proxy those VOP's into a different address space, either on another machine, or to a user space VFS stacking layer developement environment. This is the same problem that embedding VM references directly into any FS causes, and that vm_object_t aliases would exacerbate. John has, in the past, sent me a number of stacking layers done by various people, with the requirement that I not redistribute them, as they are not what he would consider to be properly representative of finished work. Since John himself did the network proxy, you could perhaps get him to send you a copy, so you could have direct access to code where this was a problem. Make sure that the system you are talking to over the proxy is not assumed to be a FreeBSD system (e.g. don't assume that the vfs_default stuff exists on the other end of the proxy, or that it would be functional). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:57:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DC46A158DC; Wed, 18 Aug 1999 11:57:22 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA01776; Wed, 18 Aug 1999 20:56:58 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 18:48:01 -0000." <199908181848.LAA14960@usr02.primenet.com> Date: Wed, 18 Aug 1999 20:56:58 +0200 Message-ID: <1774.935002618@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908181848.LAA14960@usr02.primenet.com>, Terry Lambert writes: >> >You would have to de-collapse several VOP lists that have been >> >pre-collapsed. >> >> You are talking gibberish here. Please show code where this is >> a problem. > >When you write a proxy stacking layer, such as John Heidemann's >network proxy stacking layer (an NFS alternative), VOP's which >would normally be handled by vfs_default have to be handled on >the other end of the proxy, instead, in the same way that they >would be handled by the vfs_default stuff. And what prevents you from taking over the default op ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 11:59:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 18C031513F; Wed, 18 Aug 1999 11:59:06 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id LAA23974; Wed, 18 Aug 1999 11:59:01 -0700 (PDT) Date: Wed, 18 Aug 1999 11:59:01 -0700 (PDT) From: Bill Studenmund Reply-To: Bill Studenmund To: Terry Lambert Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <199908181819.LAA14096@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Terry Lambert wrote: > > Right. That exported struct lock * makes locking down to the lowest-level > > file easy - you just feed it to the lock manager, and you're locking the > > same lock the lowest level fs uses. You then lock all vnodes stacked over > > this one at the same time. Otherwise, you just call VOP_LOCK below and > > then lock yourself. > > I think this defeats the purpose of the stacking architecture; I > think that if you look at an unadulterated NULLFS, you'll see what I > mean. Please be more precise. I have looked at an unadulterated NULLFS, and found it lacking. I don't see how this change breaks stacking. > Intermediate FS's should not trap VOP's that are not applicable > to them. True. But VOP_LOCK is applicable to layered fs's. :-) > One of the purposes of doing a VOP_LOCK on intermediate vnodes > that aren't backing objects is to deal with the global vnode > pool management. I'd really like FS's to own their vnode pools, > but even without that, you don't need the locking, since you > only need to flush data on vnodes that are backing objects. > > If we look at a stack of FS's with intermediate exposure into the > namespace, then it's clear that the issue is really only applicable > to objects that act as a backing store: > > > ---------------------- ---------------------- -------------------- > FS Exposed in hierarchy Backing object > ---------------------- ---------------------- -------------------- > top yes no > intermediate_1 no no > intermediate_2 no yes > intermediate_3 yes no > bottom no yes > ---------------------- ---------------------- -------------------- > > So when we lock "top", we only lock in intermediate_2 and in bottom. No. One of the things Heidemann notes in his dissertation is that to prevent deadlock, you have to lock the whole stack of vnodes at once, not bit by bit. i.e. there is one lock for the whole thing. > > Actually isn't the only problem when you have vnode fan-in (union FS)? > > i.e. a plain compressing layer should not introduce vnode locking > > problems. > > If it's a block compression layer, it will. Also a translation layer; > consider a pure Unicode system that wants to remotely mount an FS > from a legacy system. To do this, it needs to expand the pages from > the legacy system [only it can, since the legacy system doesn't know > about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock > on a file on such a system. To propogate the lock, you have to do > an arithmetic conversion at the translation layer. This gets worse > if the lower end FS is exposed in the namespace as well. Wait. byte-range locking is different from vnode locking. I've been talking about vnode locking, which is different from the byte-range locking you're discussing above. > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > > work, we don't have the coherency issues worked out so that upper layers > > can cache data. i.e. so that the lower fs knows it has to ask the uper > > layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > With UVM in NetBSD, this is (supposedly) not an issue. UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM system. > You could actually think of it this way, as well: only FS's that > contain vnodes that provide backing should implement VOP_GETPAGES > and VOP_PUTPAGES, and all I/O should be done through paging. Right. That's part of UBC. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 12: 8:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id CABFA15870; Wed, 18 Aug 1999 12:08:30 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id MAA25525; Wed, 18 Aug 1999 12:08:22 -0700 (PDT) Date: Wed, 18 Aug 1999 12:08:22 -0700 (PDT) From: Bill Studenmund Reply-To: Bill Studenmund To: Poul-Henning Kamp Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <1362.934999489@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > Yes, but we need subsecond in the filesystems. Think about make(1) on > a blinding fast machine... Oh yes, I realize that. :-) It's just that I thought you were at one point suggesting having 128 bits to the left of the decimal point (128 bits worth of seconds). I was trying to say that'd be a bit much. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 12:16:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 12FF614CCE; Wed, 18 Aug 1999 12:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 042B91CD8A6; Wed, 18 Aug 1999 12:16:09 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Wed, 18 Aug 1999 12:16:09 -0700 (PDT) From: Kris Kennaway To: Marc Ramirez Cc: Bill Sommerfeld , freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 12:55:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 9F5A015BC0 for ; Wed, 18 Aug 1999 12:54:59 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id ABF90272; Wed, 18 Aug 1999 15:54:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with SMTP id A418C1EF for ; Wed, 18 Aug 1999 15:54:48 -0400 (EDT) Date: Wed, 18 Aug 1999 15:54:48 -0400 (EDT) From: David Miller To: freebsd-hackers@freebsd.org Subject: Gigabit ethernet support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any supported cards in 3.2.x? The HCL pages don't list any:( Thanks, --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 13: 1:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 40E7D14CA7 for ; Wed, 18 Aug 1999 13:01:26 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id NAA00235; Wed, 18 Aug 1999 13:01:30 -0700 (PDT) Date: Wed, 18 Aug 1999 13:01:30 -0700 (PDT) From: Bill Studenmund To: "Brian C. Grayson" Cc: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <19990817213718.A28662@marvin.ece.utexas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 13:20:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from console.prisa.com (gatekeeper.prisa.com [204.94.67.66]) by hub.freebsd.org (Postfix) with SMTP id 3C86A15C59; Wed, 18 Aug 1999 13:20:30 -0700 (PDT) (envelope-from nschein@prisa.com) Received: from nschein (nschein.prisa.com [172.16.129.137]) by console.prisa.com (8.6.12/8.6.12) with SMTP id NAA17898; Wed, 18 Aug 1999 13:51:48 -0700 From: "Nathaniel Schein" To: "Owner-Freebsd-Questions" Cc: Subject: yp_mkdb Date: Wed, 18 Aug 1999 13:23:34 -0700 Message-ID: <000901bee9b7$8bc47e70$898110ac@nschein.prisa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am in the process of upgrading a NIS master using version 2.1.0 to version 3.2. The 'Makefile' has been customized to include automount maps for our IRIX machines as was the 'Makefile' in the old NIS Master. The problem is that for some reason the program 'yp_mkdb' in 3.2 is much more picky. It does not tolerate lines as such: nschein -rw,intr nister:/usr/home:& It complains when it encounters the '-' if removed it works fine. Also it has problems with the '+' and absence of a whitespace following the first ASCI string in the following line: +auto.home What has changed in yp_mkdb? Is there a way to escape certain symbols? I have already tried \ '' "". Or is there another way to make the database file? Nathaniel Schein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 13:40:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from medulla.hippocampus.net (medulla.hippocampus.net [204.138.241.6]) by hub.freebsd.org (Postfix) with ESMTP id CBCC51620A for ; Wed, 18 Aug 1999 13:40:18 -0700 (PDT) (envelope-from marc@netstor.com) Received: from localhost (marc@localhost) by medulla.hippocampus.net (8.9.2/8.9.2) with ESMTP id QAA19817; Wed, 18 Aug 1999 16:47:11 -0400 (EDT) Date: Wed, 18 Aug 1999 16:47:11 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet support? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, several vendors cards are supported in 3.2...most notably cards based on Titon I or Titon II chipsets (Alteon cards, 3Com 3c985, Netgear GA620, etc). -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com "Fast, Expandable and Affordable Internet Caching Products" 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 On Wed, 18 Aug 1999, David Miller wrote: > Any supported cards in 3.2.x? The HCL pages don't list any:( > > Thanks, > > --- David > > > > 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 18 13:44:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id EA4F215D9F; Wed, 18 Aug 1999 13:43:47 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id NAA113206; Wed, 18 Aug 1999 13:43:27 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdDReHUa; Wed Aug 18 13:43:17 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA28863; Wed, 18 Aug 1999 13:43:14 -0700 (MST) From: Terry Lambert Message-Id: <199908182043.NAA28863@usr06.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov Date: Wed, 18 Aug 1999 20:43:14 +0000 (GMT) Cc: tlambert@primenet.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: from "Bill Studenmund" at Aug 18, 99 11:59:01 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Right. That exported struct lock * makes locking down to the lowest-level > > > file easy - you just feed it to the lock manager, and you're locking the > > > same lock the lowest level fs uses. You then lock all vnodes stacked over > > > this one at the same time. Otherwise, you just call VOP_LOCK below and > > > then lock yourself. > > > > I think this defeats the purpose of the stacking architecture; I > > think that if you look at an unadulterated NULLFS, you'll see what I > > mean. > > Please be more precise. I have looked at an unadulterated NULLFS, and > found it lacking. I don't see how this change breaks stacking. OK, there's the concept of "collapse" of stacking layer. This was first introduced in the Rosenthal stacking vnode architecture, out of Sun Microsystems. Rosenthal was concerned that, when you stack 500 putatively "null" NULLFS's, that the amount of function call overhead not increase proportionally. To resolve this, he introduced the concept of a "collapsed" VFS stack. That is, the actual array of function vectors is actually a one dimensional projection of a two dimensional stack, and that the visible portion is actually where the first layer on the way down the stack that implements a VOP occurs. We can visualize this like so: VOPs Layer | VOP1 VOP2 VOP3 VOP4 VOP5 VOP6 ... ----------------------------------------------------------- L1 - - - imp - - ... L2 imp - - imp - imp ... L3 imp - - imp imp - ... L4 - - imp - - - ... L5 imp imp imp imp imp imp ... The resulting "collapsed" array of entry vectors looks like so: L2VOP1 L5VOP2 L4VOP3 L1VOP4 L3VOP5 L2VOP6 ... There is an implicit assumption here that most stacks will not be randomly staggered like this example. The idea behind this assumption is that additional layers will most frequently add functionality, rather than replacing it. Heidemann carried this idea over into his architecture, to be employed at the point that a VFS stack is first instanced. The BSD4.4 implementation of this is partially flawed. There is an implicit implementation of this for the UFS/FFS "stack" of layers, in the VOP's descriptor array exported by the combination of the two being hard coded as being a precollapsed stack. This is actually antithetical to the design. The second place this flaw is apparent is in the inability to add VOP's into an existing kernel, since the entry point vector is a fixed size, and is not expanded implicitly by the act of adding a VFS layer containing a new VOP. For the use of non-error vfs_defaults, this is also flawed for proxies, but not for the consumer of the VFS stack, only for the producer end on the other side of the proxy, which although it does not implement a particular VOP, needs to _NOT_ use the local vfs_default for the VOP, but instead needs to proxy the VOP over to the other side for remote processing. The act of getting a vfs_default VOP after a collapse, instead of having a NULL entry point that the descriptor call mechanism treats as a call failure, damages the ability to proxy unknown VOP's. > > Intermediate FS's should not trap VOP's that are not applicable > > to them. > > True. But VOP_LOCK is applicable to layered fs's. :-) Only for translation layers that require local backing store. I'm prepared to make an exception for them, and require that they explicitly call the VOP in the underlying vnode over which they are stacked. This is the same compromise that both Rosenthal and Heidemann consciously chose. > > One of the purposes of doing a VOP_LOCK on intermediate vnodes > > that aren't backing objects is to deal with the global vnode > > pool management. I'd really like FS's to own their vnode pools, > > but even without that, you don't need the locking, since you > > only need to flush data on vnodes that are backing objects. > > > > If we look at a stack of FS's with intermediate exposure into the > > namespace, then it's clear that the issue is really only applicable > > to objects that act as a backing store: > > > > > > ---------------------- ---------------------- -------------------- > > FS Exposed in hierarchy Backing object > > ---------------------- ---------------------- -------------------- > > top yes no > > intermediate_1 no no > > intermediate_2 no yes > > intermediate_3 yes no > > bottom no yes > > ---------------------- ---------------------- -------------------- > > > > So when we lock "top", we only lock in intermediate_2 and in bottom. > > No. One of the things Heidemann notes in his dissertation is that to > prevent deadlock, you have to lock the whole stack of vnodes at once, not > bit by bit. > > i.e. there is one lock for the whole thing. This is not true for a unified VM and buffer cache environment, and a significant reduction in overhead can be achieved thereby. Heidemann did his work on SVR4, which does not have a unified VM and buffer cache. The deadlock discussion in his dissertation is only applicable to systems where the coherency model is such that each and every vnode has buffers associated with it. That is, it applies to vnodes which act as backing store (buffer cache object references). If you seperate the concept, such that you don't have to deal with vnodes that do not have coherency issues, then you can drastically reduce the number of coherency operations required (locking is a coherency operation). In addition to this, you can effectively obtain what neither the Rosenthal or the SVR4 version of the Heidemann stacking framework can otherwise obtain: intermediate VFS layer NULL VOP call collapse. The way you obtain this is by caching the vnode of the backing object in the intermediate layer, and dereferencing it to get at it's VOP vector directly. This means that a functional layer that shodows an underlying VOP, seperated by 1,000 NULLFS layers, does not result in a 1,000 function call overhead. > > > Actually isn't the only problem when you have vnode fan-in (union FS)? > > > i.e. a plain compressing layer should not introduce vnode locking > > > problems. > > > > If it's a block compression layer, it will. Also a translation layer; > > consider a pure Unicode system that wants to remotely mount an FS > > from a legacy system. To do this, it needs to expand the pages from > > the legacy system [only it can, since the legacy system doesn't know > > about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock > > on a file on such a system. To propogate the lock, you have to do > > an arithmetic conversion at the translation layer. This gets worse > > if the lower end FS is exposed in the namespace as well. > > Wait. byte-range locking is different from vnode locking. I've been > talking about vnode locking, which is different from the byte-range > locking you're discussing above. Conceptually, they're not really different at all. You want to apply an operation against a stack of vnodes, and only involve the relevent vnodes when you do it. > > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > > > work, we don't have the coherency issues worked out so that upper layers > > > can cache data. i.e. so that the lower fs knows it has to ask the uper > > > layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > > > With UVM in NetBSD, this is (supposedly) not an issue. > > UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM > system. I was under the impression that th "U" in "UVM" was for "Unified". Does NetBSD not have a unified VM and buffer cache? is th "U" in "UVM" referring not to buffer cache unification, but to platform unification? It was my understanding from John Dyson, who had to work on NetBSD for NCI, that the new NetBSD stuff actually unified the VM and the buffer cache. If this isn't the case, then, yes, you will need to lock all the way up and down, and eat the copy overhead for the concurrency for the intermediate vnodes. 8-(. > > You could actually think of it this way, as well: only FS's that > > contain vnodes that provide backing should implement VOP_GETPAGES > > and VOP_PUTPAGES, and all I/O should be done through paging. > > Right. That's part of UBC. :-) Yep. Again, if NetBSD doesn't have this, it's really important that it obtain it. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 13:54:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from poboxer.pobox.com (ferg5200-1-27.cpinternet.com [208.149.16.27]) by hub.freebsd.org (Postfix) with ESMTP id B085B14F26 for ; Wed, 18 Aug 1999 13:54:13 -0700 (PDT) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id PAA09427; Wed, 18 Aug 1999 15:53:40 -0500 (CDT) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Aug 1999 15:53:39 -0500 (CDT) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: wsanchez@apple.com Cc: hackers@freebsd.org Subject: Re: RE: Need some advice regarding portable user IDs X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14267.7374.658180.967408@avalon.east> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : And what happens accross NIS domains? UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14: 2:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 472E2151E1; Wed, 18 Aug 1999 14:02:05 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id OAA435022; Wed, 18 Aug 1999 14:02:07 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdaToVMa; Wed Aug 18 14:01:59 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA29646; Wed, 18 Aug 1999 14:01:54 -0700 (MST) From: Terry Lambert Message-Id: <199908182101.OAA29646@usr06.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 18 Aug 1999 21:01:53 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <1774.935002618@critter.freebsd.dk> from "Poul-Henning Kamp" at Aug 18, 99 08:56:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> >You would have to de-collapse several VOP lists that have been > >> >pre-collapsed. > >> > >> You are talking gibberish here. Please show code where this is > >> a problem. > > > >When you write a proxy stacking layer, such as John Heidemann's > >network proxy stacking layer (an NFS alternative), VOP's which > >would normally be handled by vfs_default have to be handled on > >the other end of the proxy, instead, in the same way that they > >would be handled by the vfs_default stuff. > > And what prevents you from taking over the default op ? It needs to be NULL, not taken over. machine 1 machine2 machine 3 vfs consumer upper proxy <---------> lower proxy vfs stacking layer upper proxy <---------> lower proxy vfs producer How do I get a VOP, unknown to machine 2, from the vfs consumer on machine 1 that does know about it, to the vfs producer on machine 3 that also knows about it? My understanding is that it is very hard, given vfs_default: On machine 1, since the upper proxy doesn't know from VOP's, it wants to locally satisfy it from vfs_default on machine 1. Taking over the default op doesn't really help me; I have to do surgery to the in core dispatch vector instance to do the job properly (e.g. zapping it out, not taking it over). On machine 2, it is out of range, but still needs to be passed through the stacking layer, from the lower porxy to the upper proxy (and the response, back). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:10:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wank.necropolis.org (wank.necropolis.org [207.246.128.93]) by hub.freebsd.org (Postfix) with ESMTP id 0929C159E8 for ; Wed, 18 Aug 1999 14:10:11 -0700 (PDT) (envelope-from todd@wank.necropolis.org) Received: from localhost (todd@localhost) by wank.necropolis.org (8.9.3/8.9.3) with ESMTP id OAA23718; Wed, 18 Aug 1999 14:14:35 -0700 (PDT) (envelope-from todd@wank.necropolis.org) Date: Wed, 18 Aug 1999 14:14:35 -0700 (PDT) From: Todd Backman To: Anthony Kimball Cc: wsanchez@apple.com, hackers@FreeBSD.ORG Subject: Re: RE: Need some advice regarding portable user IDs In-Reply-To: <14267.7374.658180.967408@avalon.east> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Anthony Kimball wrote: > > : And what happens accross NIS domains? > > UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not > Steve. > ROTFLMFAO (rolling on the floor laughing my f***ing a** off) ;^) Thanks for brightening my day with this grin inducing line. - Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:17:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id EA5DB14F06 for ; Wed, 18 Aug 1999 14:17:33 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2448.0) id ; Wed, 18 Aug 1999 14:30:41 -0600 Message-ID: <64003B21ECCAD11185C500805F31EC0303786DAC@houston.matchlogic.com> From: Charles Randall To: David Miller , freebsd-hackers@freebsd.org Cc: wpaul@skynet.ctr.columbia.edu Subject: RE: Gigabit ethernet support? Date: Wed, 18 Aug 1999 14:30:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. http://www.freebsd.org/~wpaul/Alteon/ FYI, Charles -----Original Message----- From: David Miller [mailto:dmiller@search.sparks.net] Sent: Wednesday, August 18, 1999 1:55 PM To: freebsd-hackers@freebsd.org Subject: Gigabit ethernet support? Any supported cards in 3.2.x? The HCL pages don't list any:( Thanks, --- David 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 18 14:17:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 9C92214ED3; Wed, 18 Aug 1999 14:17:30 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA02921; Wed, 18 Aug 1999 23:15:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite In-reply-to: Your message of "Wed, 18 Aug 1999 21:01:53 -0000." <199908182101.OAA29646@usr06.primenet.com> Date: Wed, 18 Aug 1999 23:15:49 +0200 Message-ID: <2919.935010949@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry, It is very fine with this example, but I'm not even going to bother much with it for several reasons, most of which you can find codified in the development rules for X11 which you can find in Scheiflers book. But for the record: your example would get even shorter on the code we had before I started using the default op sensibly because all the layers tended to shunt things they didn't understand to errno rather than pass them through, so in fact my change took us closer to being able to handle the rather lofty example you have here. Once you show me an actual implementation which has a problem with it, I will look at it again, until then, I think pretty much everything else is more important (Scheiflers 1st rule :-) Poul-Henning >> And what prevents you from taking over the default op ? > >It needs to be NULL, not taken over. > > >machine 1 machine2 machine 3 > >vfs consumer >upper proxy <---------> lower proxy > vfs stacking layer > upper proxy <---------> lower proxy > vfs producer > >How do I get a VOP, unknown to machine 2, from the vfs consumer >on machine 1 that does know about it, to the vfs producer on >machine 3 that also knows about it? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:27:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id D76FE14D4B for ; Wed, 18 Aug 1999 14:27:46 -0700 (PDT) (envelope-from wsanchez@scv4.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id OAA51196 for ; Wed, 18 Aug 1999 14:28:13 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 18 Aug 1999 14:28:11 -0700 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv4.apple.com (8.9.3/8.9.3) with SMTP id OAA22896; Wed, 18 Aug 1999 14:28:09 -0700 Message-Id: <199908182128.OAA22896@scv4.apple.com> To: Bill Studenmund Subject: Re: Need some advice regarding portable user IDs Cc: "Brian C. Grayson" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com In-Reply-To: <19990817213718.A28662@marvin.ece.utexas.edu> Date: Wed, 18 Aug 1999 14:28:14 -0700 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer-Extensions: SWSignature 1.3.2 X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Fred, right now what happens in MacOS when I take a disk which has sharing | credentials set up, and hook it into another machine? How are the | credentials handled there? I think Mac OS 8 will forget about the credentials. I don't actually know much about how sharing works. But the current file sharing behaviour is not entirely useful to think about, because it doesn't effect the local permissions (much), and the local permission are what I'm worried about. Exported filesystems are another story, and I don't want to compilcate things too much by worrying about that right now. -Fred -- Wilfredo Sanchez, wsanchez@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:37:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id A716814CAA for ; Wed, 18 Aug 1999 14:37:31 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id OAA46146; Wed, 18 Aug 1999 14:37:15 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37BB2793.29E61A8D@gorean.org> Date: Wed, 18 Aug 1999 14:37:23 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0815 i386) X-Accept-Language: en MIME-Version: 1.0 To: wsanchez@apple.com Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs References: <199908180217.TAA03970@scv1.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:42:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id EDE6614CB3 for ; Wed, 18 Aug 1999 14:42:09 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id RAA20872; Wed, 18 Aug 1999 17:42:02 -0400 (EDT) Date: Wed, 18 Aug 1999 17:42:02 -0400 (EDT) From: "Matthew N. Dodd" To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet support? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, David Miller wrote: > Any supported cards in 3.2.x? The HCL pages don't list any:( Support for the Alteon Tigon 1 & 2 based boards and the SysKonnect bards is in 3.2-STABLE. (Both drivers by Bill Paul.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 14:49:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id A6FBD1547E for ; Wed, 18 Aug 1999 14:49:17 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id OAA13679; Wed, 18 Aug 1999 14:48:25 -0700 (PDT) Date: Wed, 18 Aug 1999 14:48:24 -0700 (PDT) From: Bill Studenmund To: Wilfredo Sanchez Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <199908182128.OAA22896@scv4.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Wilfredo Sanchez wrote: > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My thought here was more that this was the closest thing to prior art that MacOS has, and that that might be a good user experience to emulate. ;-) Probably the thing to do is either have options to the mount call which have the mounting user own everything, or to set up a umap which maps the desired user to root for access on the filesystem. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:14:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 465E214EAC for ; Wed, 18 Aug 1999 15:14:38 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA25820; Wed, 18 Aug 1999 18:14:48 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 18 Aug 1999 18:15:05 -0400 To: David Scheidt From: Garance A Drosihn Subject: Re: lpd security check for changed-file vs NFS Cc: Matthew Dillon , hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:48 AM -0500 8/18/99, David Scheidt wrote: >On Tue, 17 Aug 1999, Garance A Drosihn wrote: > > > At 6:37 PM -0700 8/17/99, Matthew Dillon wrote: > > > If you removed the stat test, I would simply get rid of the -s > > > option entirely - require that all files be queued to the print > > > spool. > > > > The administration would kill me. I would prefer to avoid that. > > > > (note that the check isn't completely removed, it's "only" nullified > > for NFS-mounted files. We use AFS for most things here, so the vast > >Couldn't you turn it off only for NFS mounted files? I first took this to mean "turn off the security check", but now I see it means "turn off the -s option". In thinking about this suggestion, I think that as long as I allow-but-ignore the option for nfs files, it might work out better than I initially thought it would. I don't want to completely reject '-s' because they have that embedded in a lot of scripts and canned procedures that I doubt they want to search for right now. But just ignoring the option for NFS files might not be too bad. I do keep thinking that they would have a fit if some 'lpr -s' didn't work because it ran out of space to copy the file into the spool directory. Still, I'll have to think about this some more. Thanks. > > Any advice on how to kick AIX so the st_dev+st_ino check will work > > right is also welcome. It baffles me why AIX does things the way it > > does. It kinda looks like the values it uses are pointers to some > >The joke about AIX is that it was created by aliens who were given the >UNIX documentation, but no example system. I have seen very little >that suggests this to be untrue. Everytime I start thinking "well AIX isn't TOO bad", something like this comes along to remind me... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:14:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id E62A11593C for ; Wed, 18 Aug 1999 15:14:50 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.2) with ESMTP id RAA58859; Wed, 18 Aug 1999 17:15:16 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 18 Aug 1999 17:15:15 -0500 (CDT) From: Chris Dillon To: Bill Studenmund Cc: "Brian C. Grayson" , wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > > A group of us at Apple are trying to figure out how to handle > > > situations where a filesystem with "foreign" user ID's are present. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./ drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r----- 1 harry users 0 Aug 18 15:48 bar -rw-r----- 1 harry users 0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users 512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users 512 Aug 18 15:42 ./ drwxr-x--- 4 jake users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users 512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r----- 1 jake users 0 Aug 18 15:48 bar -rw-r----- 1 jake users 0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r----- 1 jake users 0 Aug 18 15:48 bar -rw-r----- 1 jake users 0 Aug 18 15:48 foo -rw-r----- 1 jake users 0 Aug 18 15:50 baz From jake's perspective, this happens as if it were an origin filesystem and he owned everything on it. Now, mount the filesystem again on it's origin system. drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./ drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/ Nothing changed here as far as credentials are concerned. ls -la dir1 -rw-r----- 1 harry users 0 Aug 18 15:48 bar -rw-r----- 1 harry users 0 Aug 18 15:48 foo -rw-r----- 1 harry users 0 Aug 18 15:50 baz The new file added by the foreign user inherited the credentials of its origin parent, just as it would have normally. Points to ponder: 1) When writing to a foreign filesystem, should file mode bits be inherited from the parent, or be based on the umask of the foreign user writing the file at that time? Can the umask of the foreign owner be preserved (which isn't necessarily the same thing as inheriting from the parent) and used? 2) How should chown and chgrp act when attempting to modify credentials on one of these foreign filesystems? Should it affect only the local credential mapping (temporarily) and not modify the foreign filesystem? Should you completely ignore the attempts and not do anything? I vote for temporarily changing credentials (until unmounted), but that is certainly a lot harder to implement than just ignoring the changes. :-) 3) What happens if you want to mount the filesystem on a machine besides the origin, but you do NOT want to do credential mapping (i.e. the systems both have the same sets of users)? This wouldn't matter if you just used a mount option or different filesystem type when mounting, but I'm assuming something automagic is wanted here. 4) What happens if you change the credentials of the mountpoint after you have mounted the foreign filesystem? Should the mappings follow the new credentials, or stay as they were when first mounted? Even if I have no idea what I'm talking about and this was the stupidest idea anyone has ever heard of, I hope that I at least sparked off a few new thought processes and got some more ideas flowing. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:33:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 730DD151CA for ; Wed, 18 Aug 1999 15:33:45 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA49934; Wed, 18 Aug 1999 16:34:06 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA27771; Wed, 18 Aug 1999 16:33:49 -0600 (MDT) Message-Id: <199908182233.QAA27771@harmony.village.org> To: David Scheidt Subject: Re: lpd security check for changed-file vs NFS Cc: Garance A Drosihn , Matthew Dillon , hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 18 Aug 1999 08:48:17 CDT." References: Date: Wed, 18 Aug 1999 16:33:49 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message David Scheidt writes: : Couldn't you turn it off only for NFS mounted files? For the general case (eg the code checked into the system), the check needs to remain enabled. Anything else is insecure. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:37:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B82E115000 for ; Wed, 18 Aug 1999 15:37:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA49807; Wed, 18 Aug 1999 15:37:51 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Aug 1999 15:37:51 -0700 (PDT) From: Matthew Dillon Message-Id: <199908182237.PAA49807@apollo.backplane.com> To: Warner Losh Cc: David Scheidt , Garance A Drosihn , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: lpd security check for changed-file vs NFS References: <199908182233.QAA27771@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :For the general case (eg the code checked into the system), the check :needs to remain enabled. Anything else is insecure. : :Warner I have to agree... whenever one starts discussing weird, esoteric workarounds one inevitably introduces security holes. I really think just disabling the -s option may be the best solution. Garance: I recommend you actually check to see how big your printer spools get. If they look reasonable then turning off -s is not going to hurt anything. I expect that most users don't even know the option exists and so don't use it anyway. -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 Wed Aug 18 15:41:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 64AC714EEC for ; Wed, 18 Aug 1999 15:40:58 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id XAA81914; Wed, 18 Aug 1999 23:40:31 +0100 (BST) (envelope-from nik) Date: Wed, 18 Aug 1999 23:40:31 +0100 From: Nik Clayton To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: BSD voice synthesis Message-ID: <19990818234031.A58007@catkin.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Julian Elischer on Tue, Aug 03, 1999 at 12:37:39AM -0700 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote: > Just fetched and compiled the "festival" package. > http://www.cstr.ed.ac.uk/projects/festival Likewise, based on your comments. Has anyone had any problems with the volume being far too low? The sound card on this box is a pcm2 (CS423x/Yamaha/AD1816 sn 0xffffffff) at 0x530-0x537 irq 5 drq 1 fl ags 0x13 on isa and I run mixer pcm 80 in /etc/rc.local, to set the volume to a comfortable level for playing .mp3 files and the like. If I turn the speakers right up then I can hear the output, but then everything else is distorted. Any thoughts? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:42:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id A3AA114ED2 for ; Wed, 18 Aug 1999 15:42:38 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA25589; Wed, 18 Aug 1999 18:43:25 -0400 From: Bill Paul Message-Id: <199908182243.SAA25589@skynet.ctr.columbia.edu> Subject: Re: Gigabit ethernet support? To: crandall@matchlogic.com (Charles Randall) Date: Wed, 18 Aug 1999 18:43:24 -0400 (EDT) Cc: dmiller@search.sparks.net, freebsd-hackers@freebsd.org In-Reply-To: <64003B21ECCAD11185C500805F31EC0303786DAC@houston.matchlogic.com> from "Charles Randall" at Aug 18, 99 02:30:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1790 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Charles Randall had to walk into mine and say: > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > http://www.freebsd.org/~wpaul/Alteon/ > > FYI, > Charles > > -----Original Message----- > From: David Miller [mailto:dmiller@search.sparks.net] > Sent: Wednesday, August 18, 1999 1:55 PM > To: freebsd-hackers@freebsd.org > Subject: Gigabit ethernet support? > > > Any supported cards in 3.2.x? The HCL pages don't list any:( The ti driver supports several cards, including the Alteon AceNIC, the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and possibly some from IBM as well, though I don't know the PCI vendor/device IDs for those so I can't be sure (if you find them out, you can try hacking them into the driver). All of these are supported by the same driver because they're all OEMed from Alteon. Also, there is a driver for the SysKonnect gigabit ethernet cards (www.syskonnect.com). The driver sk was merged into the 3.x branch recently. SysKonnect has both single port and dual port cards with multimode and single mode fiber interfaces. All types are supported. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:46:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 86A7E14EA3; Wed, 18 Aug 1999 15:46:11 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id PAA61412; Wed, 18 Aug 1999 15:44:56 -0700 (PDT) (envelope-from green@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: green owned process doing -bs Date: Wed, 18 Aug 1999 15:44:56 -0700 (PDT) From: "Brian F. Feldman" To: Nik Clayton Cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: BSD voice synthesis In-Reply-To: <19990818234031.A58007@catkin.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Nik Clayton wrote: > On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote: > > Just fetched and compiled the "festival" package. > > http://www.cstr.ed.ac.uk/projects/festival > > Likewise, based on your comments. > > Has anyone had any problems with the volume being far too low? I cannot get this far. Festival only coredumps when I try to start it up. Could you send me a description of how I can reproduce your exact build of Festival? > > N > -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is \ green@FreeBSD.org | indistinguishable from a feature." | FreeBSD: The Power to Serve! \ -- Rich Kulawiec / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:49:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 918CA14EA3 for ; Wed, 18 Aug 1999 15:49:39 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 11385 invoked from network); 18 Aug 1999 22:49:23 -0000 Received: from shell-2.enteract.com (dscheidt@207.229.143.41) by pop3-3.enteract.com with SMTP; 18 Aug 1999 22:49:23 -0000 Date: Wed, 18 Aug 1999 17:49:23 -0500 (CDT) From: David Scheidt To: Matthew Dillon Cc: Warner Losh , Garance A Drosihn , hackers@FreeBSD.ORG Subject: Re: lpd security check for changed-file vs NFS In-Reply-To: <199908182237.PAA49807@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Matthew Dillon wrote: > :For the general case (eg the code checked into the system), the check > :needs to remain enabled. Anything else is insecure. > : > :Warner Oh, absolutely. However, one of the reasons people use an operating system they have source to is to make it work for them. > > I have to agree... whenever one starts discussing weird, esoteric > workarounds one inevitably introduces security holes. I really think > just disabling the -s option may be the best solution. It is apparent that I was unclear. What I meant was use the fstat test for local files. For NFS mounted files, don't use the test, since it doesn't work, and don't allow the the -s option. (Better would be to accept, and ignore the -s, perhaps producing a warning?) David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 15:57:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 07C3B14F87; Wed, 18 Aug 1999 15:57:39 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id PAA23350; Wed, 18 Aug 1999 15:50:12 -0700 (PDT) Date: Wed, 18 Aug 1999 15:51:25 -0700 (PDT) From: Julian Elischer To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: BSD voice synthesis In-Reply-To: <19990818234031.A58007@catkin.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I haven't played with it for a few weeks, but I recall seeing a default volume somewhere. (in the documantation) I think you can set it in your init files but I can't go look right now. julian (it seemed ok to me but I didn't test it too much) On Wed, 18 Aug 1999, Nik Clayton wrote: > On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote: > > Just fetched and compiled the "festival" package. > > http://www.cstr.ed.ac.uk/projects/festival > > Likewise, based on your comments. > > Has anyone had any problems with the volume being far too low? > > The sound card on this box is a > > pcm2 (CS423x/Yamaha/AD1816 sn 0xffffffff) at 0x530-0x537 irq 5 drq 1 fl > ags 0x13 on isa > > and I run > > mixer pcm 80 > > in /etc/rc.local, to set the volume to a comfortable level for playing > .mp3 files and the like. > > If I turn the speakers right up then I can hear the output, but then > everything else is distorted. > > Any thoughts? > > N > -- > [intentional self-reference] can be easily accommodated using a blessed, > non-self-referential dummy head-node whose own object destructor severs > the links. > -- Tom Christiansen in <375143b5@cs.colorado.edu> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 16: 6: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from marcy.nas.nasa.gov (marcy.nas.nasa.gov [129.99.113.17]) by hub.freebsd.org (Postfix) with ESMTP id 51BAB14F87 for ; Wed, 18 Aug 1999 16:06:00 -0700 (PDT) (envelope-from wrstuden@marcy.nas.nasa.gov) Received: from localhost (wrstuden@localhost) by marcy.nas.nasa.gov (8.9.3/NAS8.8.7) with SMTP id QAA14746; Wed, 18 Aug 1999 16:06:01 -0700 (PDT) Date: Wed, 18 Aug 1999 16:06:01 -0700 (PDT) From: Bill Studenmund To: Chris Dillon Cc: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Chris Dillon wrote: > I'm probably being extremely naive myself, but I just envisioned a > scenario like this (pardon me if someone else has already suggested > this): > > When a filesystem is mounted as foreign (HOW that is determined I > won't talk about), every file in the filesytem has its credentials > mapped to that of the mountpoint. File mode bits are not remapped in > any way. New files gain the credentials of their _foreign_ parent. > > That's the skinny. Now I'll give a (much longer) example to clarify. Sounds fine, except I'd have the owner & group passed in in the initial mount, rather than taken from "the mount point". :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 16:55: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from perforce.com (spice.perforce.com [206.14.52.195]) by hub.freebsd.org (Postfix) with ESMTP id 110A015AAC for ; Wed, 18 Aug 1999 16:54:57 -0700 (PDT) (envelope-from seiwald@perforce.com) Received: (from seiwald@localhost) by perforce.com (8.9.3/8.9.3) id QAA09187 for freebsd-hackers@freebsd.org; Wed, 18 Aug 1999 16:56:48 -0700 (PDT) (envelope-from seiwald) Date: Wed, 18 Aug 1999 16:56:48 -0700 (PDT) From: Christopher Seiwald Message-Id: <199908182356.QAA09187@perforce.com> To: freebsd-hackers@freebsd.org Subject: anybody love qsort.c? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The FreeBSD qsort implementation has a rather nasty degenerate case. If you have data that partitions exactly about the median pivot, yet which is unsorted in either partition, you get get treated to an insertion sort. Example: 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 qsort picks 10 as the median, does no swaps on its first pass, and so decides to switch to an insertion sort. The idea is that if no swaps occur, the data is likely to be nearly already sorted and a good candidate for insertion sort. This turns out to be a (very) bad idea if you have some unsorted data buried in the middle of a (very) large dataset. The implementation claims to come from Bentley and McIlroy's paper, "Engineering a Sort Function," and this is largely true, but the insertion sort optimization(?) isn't in that paper. The GNU qsort.c only does an insertion sort if it is below a certain threshhold in size, and so never attempts such a sort on the whole dataset. (The GNU qsort does a number of other things pooh-poohed in the Bentley paper.) It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. Christopher ---- Christopher Seiwald Perforce Software 1-510-864-7400 seiwald@perforce.com f-f-f-fast SCM http://www.perforce.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 18 17:18:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 6F08615987; Wed, 18 Aug 1999 17:18:51 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id RAA11206; Wed, 18 Aug 1999 17:18:41 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAA4ka42v; Wed Aug 18 17:18:36 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA09816; Wed, 18 Aug 1999 17:18:41 -0700 (MST) From: Terry Lambert Message-Id: <199908190018.RAA09816@usr06.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 19 Aug 1999 00:18:41 +0000 (GMT) Cc: tlambert@primenet.com, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <2919.935010949@critter.freebsd.dk> from "Poul-Henning Kamp" at Aug 18, 99 11:15:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Terry, > > It is very fine with this example, but I'm not even going to bother > much with it for several reasons, most of which you can find codified > in the development rules for X11 which you can find in Scheiflers > book. > > But for the record: your example would get even shorter on > the code we had before I started using the default op sensibly > because all the layers tended to shunt things they didn't > understand to errno rather than pass them through, so in > fact my change took us closer to being able to handle the > rather lofty example you have here. > > Once you show me an actual implementation which has a problem > with it, I will look at it again, until then, I think pretty > much everything else is more important (Scheiflers 1st rule :-) > > Poul-Henning That's a fair requirement. I have some of Heidemann's code that runs into the problem, but I don't have any that I can redistribute. Would it be OK if I asked John to send you his code as well, if you will abide with the non-redistribution requirement? I understand the prioritization process, and FWIW, I agree with it, in a resource-starved situation (e.g.g FreeBSD). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 17:36:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 1F39615B60 for ; Wed, 18 Aug 1999 17:35:31 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id RAA36248; Wed, 18 Aug 1999 17:35:37 -0700 (PDT) From: Archie Cobbs Message-Id: <199908190035.RAA36248@bubba.whistle.com> Subject: Re: anybody love qsort.c? In-Reply-To: <199908182356.QAA09187@perforce.com> from Christopher Seiwald at "Aug 18, 1999 04:56:48 pm" To: seiwald@perforce.com (Christopher Seiwald) Date: Wed, 18 Aug 1999 17:35:37 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Seiwald writes: > The FreeBSD qsort implementation has a rather nasty degenerate case. > If you have data that partitions exactly about the median pivot, yet > which is unsorted in either partition, you get get treated to an insertion > sort. Example: > > 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 > > qsort picks 10 as the median, does no swaps on its first pass, and so > decides to switch to an insertion sort. The idea is that if no swaps > occur, the data is likely to be nearly already sorted and a good candidate > for insertion sort. This turns out to be a (very) bad idea if you have > some unsorted data buried in the middle of a (very) large dataset. > > The implementation claims to come from Bentley and McIlroy's paper, > "Engineering a Sort Function," and this is largely true, but the insertion > sort optimization(?) isn't in that paper. The GNU qsort.c only does an > insertion sort if it is below a certain threshhold in size, and so never > attempts such a sort on the whole dataset. (The GNU qsort does a number > of other things pooh-poohed in the Bentley paper.) > > It's a pretty straightforward change to bypass the insertion sort for > large subsets of the data. If no one has a strong love for qsort, I'll > educate myself on how to make and contribute this change. Sounds good to me.. let's fix it. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.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 18 18:19:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from virtual-voodoo.com (virtual-voodoo.com [204.120.165.254]) by hub.freebsd.org (Postfix) with ESMTP id 39BD314DE4 for ; Wed, 18 Aug 1999 18:19:15 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: (from steve@localhost) by virtual-voodoo.com (8.9.3/8.9.3) id UAA00958; Wed, 18 Aug 1999 20:18:40 -0500 (EST) (envelope-from steve) Date: Wed, 18 Aug 1999 20:18:40 -0500 (EST) From: Steven Ames Message-Id: <199908190118.UAA00958@virtual-voodoo.com> To: mrcpu@internetcds.com, steve@virtual-voodoo.com Subject: Re: OpenLDAP tests? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Me too. Remarkable what removing a couple of Debug lines will do for you. Thanks! -Steve > Found it. > > This let the tests run fine for me. > > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/daemon.c,v > retrieving revision 1.14.2.7.2.8 > retrieving revision 1.14.2.7.2.9 > diff -u -r1.14.2.7.2.8 -r1.14.2.7.2.9 > --- servers/slapd/daemon.c 1999/03/02 18:30:05 1.14.2.7.2.8 > +++ servers/slapd/daemon.c 1999/07/20 05:10:35 1.14.2.7.2.9 > @@ -390,7 +390,6 @@ > void > slap_set_shutdown( int sig ) > { > - Debug( LDAP_DEBUG_ANY, "slapd got shutdown signal %d\n", sig, 0, 0 > ); > slapd_shutdown = 1; > ldap_pvt_thread_kill( listener_tid, LDAP_SIGUSR1 ); > > @@ -401,8 +400,6 @@ > void > slap_do_nothing( int sig ) > { > - Debug( LDAP_DEBUG_TRACE, "slapd got do_nothing signal %d\n", sig, > 0, 0 ); > - > /* reinstall self */ > (void) SIGNAL( sig, slap_do_nothing ); > } > > > > > > > > On Wed, 18 Aug 1999, Steven Ames wrote: > > > Thanks! I'll check the site (but would appreciate your sending it to me > > also). > > > > -Steve > > > > On Tue, 17 Aug 1999, Jaye Mathisen wrote: > > > > > > > > There is a patch that fixes this, I found it, and submitted a bug report > > > on their web page. > > > > > > I don't have it handy, but if you go to www.openldap.org and to their > > > faq-o-matic, and it should be in there. > > > > > > I'll see if I can find it and send it to you in the mean time. > > > > > > On Tue, 17 Aug 1999, Steven Ames wrote: > > > > > > > > > > > I've got a project at work where using LDAP would make my life > > > > much simpler. So... on my home PC (running FBSD 4.0-CURRENT 8.2.99) > > > > I installed openldap from the ports collection (V1.2.3...ports cvsuped > > > > about an hour ago from cvsup5.freebsd.org). > > > > > > > > I cd into the test area /usr/ports/work/ldap/tests and type 'make'. > > > > Looking good... until... on test0003-search it stops. It just holds. > > > > My CPU is up to 99% and its chewed up 18 minutes of CPU before I hit > > > > Ctrl-C and stopped it. I did a 'make clean' moved scripts/test0003-seach > > > > to scripts/test0009-search (so it would run last) and tried again. > > > > Same results on test0004-modify. *sigh* > > > > > > > > Do the tests just not run? I didn't dare to just go ahead and use it > > > > as I'm not familiar enough with LDAP to judge if a failure is my fault > > > > or a system problem. I'd feel a lot safer if the tests all passed so that > > > > if anything goes wrong from that point I can call it user error. > > > > > > > > Anyone? > > > > > > > > -Steve > > > > > > > > > > > > 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 18 18:19:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id B89AA14DE4 for ; Wed, 18 Aug 1999 18:19:44 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 19 Aug 1999 02:20:04 +0100 (BST) Date: Thu, 19 Aug 1999 02:20:03 +0100 From: David Malone To: Bill Paul Cc: crandall@matchlogic.com, dmiller@search.sparks.net, freebsd-hackers@freebsd.org Subject: Re: Gigabit ethernet support? Message-ID: <19990819022003.A92446@walton.maths.tcd.ie> References: <64003B21ECCAD11185C500805F31EC0303786DAC@houston.matchlogic.com> <199908182243.SAA25589@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199908182243.SAA25589@skynet.ctr.columbia.edu>; from Bill Paul on Wed, Aug 18, 1999 at 06:43:24PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 06:43:24PM -0400, Bill Paul wrote: Just out of curiosity, I thought I saw that you could get Intel Etherexpress 1Gb/s cards. Do these exist and if so would they work with the fxp driver as it is? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 18:32:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 5A0B214ED0 for ; Wed, 18 Aug 1999 18:32:23 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id SAA01007; Wed, 18 Aug 1999 18:28:57 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA06198; Wed, 18 Aug 1999 18:22:43 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id TAA08033; Wed, 18 Aug 1999 19:28:43 -0600 Message-ID: <37BB5DCB.4847C0BE@softweyr.com> Date: Wed, 18 Aug 1999 19:28:43 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Paul Cc: Charles Randall , dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet support? References: <199908182243.SAA25589@skynet.ctr.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Paul wrote: > > Of all the gin joints in all the towns in all the world, Charles Randall > had to walk into mine and say: > > > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > > > http://www.freebsd.org/~wpaul/Alteon/ > > > > FYI, > > Charles > > > > -----Original Message----- > > From: David Miller [mailto:dmiller@search.sparks.net] > > Sent: Wednesday, August 18, 1999 1:55 PM > > To: freebsd-hackers@freebsd.org > > Subject: Gigabit ethernet support? > > > > > > Any supported cards in 3.2.x? The HCL pages don't list any:( > > The ti driver supports several cards, including the Alteon AceNIC, > the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the > SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and > possibly some from IBM as well, though I don't know the PCI vendor/device > IDs for those so I can't be sure (if you find them out, you can try > hacking them into the driver). All of these are supported by the same > driver because they're all OEMed from Alteon. We have two of the NetGear GA620's here, and they work quite nicely. I use them for testing throughput via Gig-E on our switches. Mine is running in a lowly PII/233, on a 32-bit x 33 Mhz slot, and can push bits at 320 Mbps. The GA620 will work in any 32 or 64 bit, 33 or 66 Mhz slot. A 64x66 slot would probably speed things up appreciably. They're relatively cheap, too, going for $339 at DataComm Warehouse. I'm still working on those Packet Engine cards, Bill. They're really quite disorganized and difficult to work with up there in Spokane... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 18 18:41:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id DAE1214F75 for ; Wed, 18 Aug 1999 18:41:45 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id VAA25841; Wed, 18 Aug 1999 21:44:09 -0400 From: Bill Paul Message-Id: <199908190144.VAA25841@skynet.ctr.columbia.edu> Subject: Re: Gigabit ethernet support? To: dwmalone@maths.tcd.ie (David Malone) Date: Wed, 18 Aug 1999 21:44:08 -0400 (EDT) Cc: crandall@matchlogic.com, dmiller@search.sparks.net, hackers@freebsd.org In-Reply-To: <19990819022003.A92446@walton.maths.tcd.ie> from "David Malone" at Aug 19, 99 02:20:03 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2816 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, David Malone had to walk into mine and say: > On Wed, Aug 18, 1999 at 06:43:24PM -0400, Bill Paul wrote: > > Just out of curiosity, I thought I saw that you could get Intel > Etherexpress 1Gb/s cards. Do these exist and if so would they work > with the fxp driver as it is? > > David. The Intel gigabit ethernet cards are nothing like the EtherExpress fast ethernet adapters. Getting information out of Intel is like trying to squeeze blood from a stone. Either they want you to sign a non disclosure agreement that prevents you from releasing driver source (or makes it hard) or they won't give you any information at all. Sometimes they also play a different game where they release some information and pretend they're being 'open' but in reality the stuff they release is just fluff and you still have to sign an NDA to get your hands on the good stuff. As an aside, there are bound to be extra problems with the Intel gigabit NICs because, if I'm not mistaken, then use an on-board i960 processor to drive them. This means that in order to make the NIC work, you have to load firmware into it, and with firmware comes sticky licensing issues. The Alteon Tigon chipset also requires firmware (it has embedded MIPS R4000 CPUs) but Alteon actually released the firmware source code along with all the other Tigon development information. They even have a mailing list where you can send in questions regarding the firmware and get answers from a real live developer. Until such time as Intel gets its head out of its ass in this regard, I refuse to have anything to do with their networking products, especially when I have two other sources of perfectly good gigabit ethernet NICs available to me with full, unencumbered documentation. Initially this was not true of SysKonnect: they had a Linux driver for their cards but no programming info available. Much to my surprise, after a lengthy e-mail discussion, they actually agreed to release the manual for their GEnesis ASIC not just to me but to anybody without NDA on their web site. You would think that Intel would be prepared to make the same commitment to their customers, but so far as I know, they're still stuck in their proprietary ways. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 19:52:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id DEE4215184 for ; Wed, 18 Aug 1999 19:52:37 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id UAA24348; Wed, 18 Aug 1999 20:49:54 -0600 (MDT) (envelope-from ken) Message-Id: <199908190249.UAA24348@panzer.kdm.org> Subject: Re: Gigabit ethernet support? In-Reply-To: <37BB5DCB.4847C0BE@softweyr.com> from Wes Peters at "Aug 18, 1999 07:28:43 pm" To: wes@softweyr.com (Wes Peters) Date: Wed, 18 Aug 1999 20:49:54 -0600 (MDT) Cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), crandall@matchlogic.com (Charles Randall), dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote... > Bill Paul wrote: > > > > Of all the gin joints in all the towns in all the world, Charles Randall > > had to walk into mine and say: > > > > > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > > > > > http://www.freebsd.org/~wpaul/Alteon/ > > > > > > FYI, > > > Charles > > > > > > -----Original Message----- > > > From: David Miller [mailto:dmiller@search.sparks.net] > > > Sent: Wednesday, August 18, 1999 1:55 PM > > > To: freebsd-hackers@freebsd.org > > > Subject: Gigabit ethernet support? > > > > > > > > > Any supported cards in 3.2.x? The HCL pages don't list any:( > > > > The ti driver supports several cards, including the Alteon AceNIC, > > the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the > > SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and > > possibly some from IBM as well, though I don't know the PCI vendor/device > > IDs for those so I can't be sure (if you find them out, you can try > > hacking them into the driver). All of these are supported by the same > > driver because they're all OEMed from Alteon. > > We have two of the NetGear GA620's here, and they work quite nicely. I use > them for testing throughput via Gig-E on our switches. Mine is running in > a lowly PII/233, on a 32-bit x 33 Mhz slot, and can push bits at 320 Mbps. > The GA620 will work in any 32 or 64 bit, 33 or 66 Mhz slot. A 64x66 slot > would probably speed things up appreciably. I doubt a faster PCI interface would really speed things up. My guess is that you've got some other bottleneck other than PCI bandwidth. Is the CPU pegged on either end? I would recommend that you make sure you've got a couple of things tweaked, they may increase your performance somewhat: - set your MTU to 9000, unless of course you're going through a switch that can't handle it - turn on net.inet.tcp.rfc1323, it enables support for TCP windows larger than 64K - increase net.inet.tcp.sendspace and net.inet.tcp.recvspace to 256K. You'll have to edit src/sys/socketvar.h and increase SB_MAX. From what I've seen (this may not be quite correct, but it's close enough) SB_MAX has to be double whatever you want to set sendspace and recvspace to. This has the effect of changing the TCP window size to 256K, I think. From what I've seen, increasing it to 512K is counterproductive unless you've got a card with 1MB of SRAM on board. (The Netgear boards have 512K.) And finally, netperf seems to work reasonably well for testing performance: http://www.netperf.org > They're relatively cheap, too, going for $339 at DataComm Warehouse. FWIW, NECX has them for $310. 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 Wed Aug 18 21:56:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 2756414F0F for ; Wed, 18 Aug 1999 21:56:07 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id VAA26040; Wed, 18 Aug 1999 21:53:11 -0700 (PDT) Message-ID: <19990818215311.49180@hydrogen.fircrest.net> Date: Wed, 18 Aug 1999 21:53:11 -0700 From: John-Mark Gurney To: Christopher Seiwald Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? References: <199908182356.QAA09187@perforce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199908182356.QAA09187@perforce.com>; from Christopher Seiwald on Wed, Aug 18, 1999 at 04:56:48PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Seiwald scribbled this message on Aug 18: > It's a pretty straightforward change to bypass the insertion sort for > large subsets of the data. If no one has a strong love for qsort, I'll > educate myself on how to make and contribute this change. why don't you implement this w/ the 5 element median selection qsort algorithm? my professor for cis413 talked about this algorithm and that it really is the fastest qsort algorithm... I don't have any pointers to a paper on this... but I might be able to dig some info up on it if you are interested... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 22:39:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 48CC714F15 for ; Wed, 18 Aug 1999 22:39:38 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id OAA11938; Thu, 19 Aug 1999 14:39:15 +0900 (JST) Message-ID: <37BB814A.92EFFD20@newsguy.com> Date: Thu, 19 Aug 1999 13:00:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Ronald G. Minnich" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Ronald G. Minnich" wrote: > > the only portable user ids are names as strings. you can kludge and kludge > but at some point the kludges will pile up too high, fall over, and hurt > somebody. how many new options did we see proposed in the last 12 hours > for this problem? Actually, I think that's a kludge too. I'd rather go for encrypted data with a signature based on a public/private key algorithm, having the signature stand for "user id". But then, I have trouble going half way when it comes down to security. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 22:40: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id ADD24150D2 for ; Wed, 18 Aug 1999 22:40:03 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id OAA12006; Thu, 19 Aug 1999 14:39:47 +0900 (JST) Message-ID: <37BB92E3.3CE11E86@newsguy.com> Date: Thu, 19 Aug 1999 14:15:15 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Larry Lile Cc: hackers@FreeBSD.ORG, dlane@yahoo.com Subject: Re: async v. sync v. default mode on ufs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Larry Lile wrote: > > It was pointed out to me by a co-worker that FreeBSD has actually > three modes of operation for mounting ufs filesystems. Could someone > please explain to me, and him, the differences between the three. There are two kinds of stuff written to the fs: data and metadata. Data is what goes inside files, metadata are things like filenames and sizes (gross simplification, emphasis on gross). Default for FreeBSD is async data and sync data. Sync and Async modes go full sync/async for both metadata and data (in theory, anyway :). The advantage with sync metadata is that the fs never gets "too" damaged. With async metadata writes, the fs can get in a state that fsck won't be able to get back to life. Sync metadata writes will be restricted to recoverable inconsistencies (ie, you may lose files and directories, but not the filesystem). > Also does anyone knows how these compare to sync and async on Linux? Sync and async modes on Linux, last I checked, are like full sync and full async modes on FreeBSD. Then, there is softupdates, which is a whole new ball game. Softupdates is async, but it will order, delete, collapse and expand metadata writes so the file system will never get in an inconsistent state. > > Just a btw, you seem to be able to set sync and async on a filesystem > at the same time. What gives? Beats me. > dlane# mount -u -o sync,async,noatime /var dlane-printer# mount > /dev/wd0s1a on / (local, noatime, synchronous, writes: sync 405 async 23) > /dev/wd0s1e on /usr (local, noatime, synchronous, writes: sync 118365 > async 83882) > /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: > sync 93 async 216) procfs on /proc (local) > dlane# > > /var looks questionable... Indeed. :-) > I would never try that on purpose, but it just kinda happened, and when I > looked at it I though "wow that's broken"! Looks that way. Try opening a PR. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 22:41:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 7C26E14F15; Wed, 18 Aug 1999 22:41:17 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id OAA11981; Thu, 19 Aug 1999 14:39:39 +0900 (JST) Message-ID: <37BB88F3.7184305@newsguy.com> Date: Thu, 19 Aug 1999 13:32:51 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Terry Lambert Cc: Poul-Henning Kamp , michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite References: <199908181848.LAA14960@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Make sure that the system you are talking to over the proxy is > not assumed to be a FreeBSD system (e.g. don't assume that the > vfs_default stuff exists on the other end of the proxy, or that > it would be functional). Now, Terry, that is ridiculous. One has to assume that both ends play by the same rules. That is not only a reasonably expectation, it's minimum requirement for any protocol to work. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 18 23:42:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 3F6D61515E for ; Wed, 18 Aug 1999 23:42:14 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11HLtn-0004zL-00; Thu, 19 Aug 1999 00:42:07 -0600 Message-ID: <37BBA73D.37765DD5@softweyr.com> Date: Thu, 19 Aug 1999 00:42:05 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: Bill Paul , Charles Randall , dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet support? References: <199908190249.UAA24348@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > > Wes Peters wrote... > > Bill Paul wrote: > > > > > > Of all the gin joints in all the towns in all the world, Charles Randall > > > had to walk into mine and say: > > > > > > > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > > > > > > > http://www.freebsd.org/~wpaul/Alteon/ > > > > > > > > FYI, > > > > Charles > > > > > > > > -----Original Message----- > > > > From: David Miller [mailto:dmiller@search.sparks.net] > > > > Sent: Wednesday, August 18, 1999 1:55 PM > > > > To: freebsd-hackers@freebsd.org > > > > Subject: Gigabit ethernet support? > > > > > > > > > > > > Any supported cards in 3.2.x? The HCL pages don't list any:( > > > > > > The ti driver supports several cards, including the Alteon AceNIC, > > > the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the > > > SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and > > > possibly some from IBM as well, though I don't know the PCI vendor/device > > > IDs for those so I can't be sure (if you find them out, you can try > > > hacking them into the driver). All of these are supported by the same > > > driver because they're all OEMed from Alteon. > > > > We have two of the NetGear GA620's here, and they work quite nicely. I use > > them for testing throughput via Gig-E on our switches. Mine is running in > > a lowly PII/233, on a 32-bit x 33 Mhz slot, and can push bits at 320 Mbps. > > The GA620 will work in any 32 or 64 bit, 33 or 66 Mhz slot. A 64x66 slot > > would probably speed things up appreciably. > > I doubt a faster PCI interface would really speed things up. My guess is > that you've got some other bottleneck other than PCI bandwidth. Is the CPU > pegged on either end? Not on mine, it's running about 45%. The other end is much faster, a PII/400, and is just discarding the packets, so it's not sweating. > I would recommend that you make sure you've got a couple of things tweaked, > they may increase your performance somewhat: > > - set your MTU to 9000, unless of course you're going through a switch that > can't handle it Not yet, that's part of what I will be developing. ;^) Due to architectural limitations, we may not be able to support jumbo frames larger than 8k. > - turn on net.inet.tcp.rfc1323, it enables support for TCP windows larger > than 64K OK. > - increase net.inet.tcp.sendspace and net.inet.tcp.recvspace to 256K. > You'll have to edit src/sys/socketvar.h and increase SB_MAX. From what > I've seen (this may not be quite correct, but it's close enough) SB_MAX > has to be double whatever you want to set sendspace and recvspace to. > This has the effect of changing the TCP window size to 256K, I think. > From what I've seen, increasing it to 512K is counterproductive unless > you've got a card with 1MB of SRAM on board. (The Netgear boards have > 512K.) OK. > And finally, netperf seems to work reasonably well for testing performance: > > http://www.netperf.org Cool. I've been using several tools, since we do our real performance testing with a SmartBits. I use spray to generate UDP traffic and a hacked-up version of tcpblast for tcp traffic. I'll clean it up and re-release it one of these days. > > They're relatively cheap, too, going for $339 at DataComm Warehouse. > > FWIW, NECX has them for $310. Cool. We don't have an account there; if I get one from DataComm all I have to do is give them the account number and it shows up on my desk the next morning. It's MORE convenient than going to the store. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 2:26:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 884FE14E8A for ; Thu, 19 Aug 1999 02:26:44 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP for hackers@freebsd.org; Thu, 19 Aug 1999 10:31:56 +0100 Message-ID: <37BBCA94.4519D6D5@baker.ie> Date: Thu, 19 Aug 1999 10:12:52 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: user mount f/s with kld's Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I just setup my system so that "Joe" user can mount /dev/fd0 on a mountpoint "Joe" owns..grand no problem.. ..BUT it only works when the f/s code for that f/s type is available (ie. compiled into the kernel or has been previously loaded as a module) however if it's not compiled into the kernel, or already loaded as a module, user "Joe" can't mount the disk because the module for that f/s type won't be loaded dynamically.. I presume this is because root is only allowed to use kldload.. ? - Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 5:18:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from karl.tools.de (karl.TooLs.DE [192.76.135.65]) by hub.freebsd.org (Postfix) with ESMTP id AB36515102 for ; Thu, 19 Aug 1999 05:18:35 -0700 (PDT) (envelope-from ws@tools.de) Received: from kurt.tools.de (kurt.TooLs.DE [192.76.135.70]) by karl.tools.de (8.8.8/8.8.8) with SMTP id OAA13717; Thu, 19 Aug 1999 14:17:50 +0200 (MET DST) Received: by kurt.tools.de (SMI-8.6/SMI-SVR4) id OAA28628; Thu, 19 Aug 1999 14:17:49 +0200 Date: Thu, 19 Aug 1999 14:17:49 +0200 From: ws@tools.de (Wolfgang Solfrank) Message-Id: <199908191217.OAA28628@kurt.tools.de> To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Need some advice regarding portable user IDs Cc: tech-kern@netbsd.org X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. BTW, since non-root users can mount anything, we should make the filesystems' code more robust, so that one cannot take the machine down by inserting random media and mounting it. Ciao, Wolfgang -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 7:21:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lupo.thebarn.com (x101-182-203.unreg.umn.edu [128.101.182.203]) by hub.freebsd.org (Postfix) with ESMTP id 6599C150F5; Thu, 19 Aug 1999 07:21:15 -0700 (PDT) (envelope-from cattelan@thebarn.com) Received: from thebarn.com ([128.101.182.201]) by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id BAA86916; Thu, 19 Aug 1999 01:01:15 -0500 (CDT) Message-ID: <37BB9DAB.E7F0FED0@thebarn.com> Date: Thu, 19 Aug 1999 01:01:15 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alton, Matthew" Cc: "'Hackers@FreeBSD.ORG'" , "'fs@FreeBSD.ORG'" Subject: Re: BSD-XFS Update References: <0740CBD1D149D31193EB0008C7C56836EB8B05@STLABCEXG012> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Alton, Matthew" wrote: > SGI has released a portion of the XFS source code under the GPL: > > http://oss.sgi.com/projects/xfs/download/ > > the source file is xfs_log.tar.gz. > > Of greater interest at this stage are the documents in: > > http://oss.sgi.com/projects/xfs/design_docs/ > > I am currently researching methods for implementing the 64-bit > syscalls stat64(), fstat64(), lseek64() &etc. delineated in the > SGI design doc _64 Bit File Access_ by Adam Sweeney. The xxxx64 calls are no longer an issue as of IRIX 6.(something 2 I think) all the standard calls were converted to use 64 bit types directly. Have a better one for you to research. Find out if buffers can be pined? if not what is it going to take to fix that. > > The BSD-XFS port will be made available as a patch to the RELEASE > FreeBSD kernels. Given the size of XFS it might be easier to make FreeBSD a patch to XFS. <- major humor here. :-) :-) > > > Matthew Alton > Computer Services - UNIX Systems Administration > (314)632-6644 matthew.alton@anheuser-busch.com > alton@plantnet.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Russell Cattelan cattelan@thebarn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 7:21:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lupo.thebarn.com (x101-182-203.unreg.umn.edu [128.101.182.203]) by hub.freebsd.org (Postfix) with ESMTP id AA72D1511C; Thu, 19 Aug 1999 07:21:15 -0700 (PDT) (envelope-from cattelan@thebarn.com) Received: from thebarn.com ([128.101.182.201]) by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id AAA86822; Thu, 19 Aug 1999 00:41:29 -0500 (CDT) Message-ID: <37BB9909.53D356FE@thebarn.com> Date: Thu, 19 Aug 1999 00:41:29 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alton, Matthew" Cc: "'Hackers@FreeBSD.ORG'" , "'fs@FreeBSD.ORG'" Subject: Re: BSD XFS Port & BSD VFS Rewrite References: <0740CBD1D149D31193EB0008C7C56836EB8AFC@STLABCEXG012> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Glad to hear somebody is willing to dive in to XFS. Right now I am one of three people working on the XFS to linux port, so I have pretty good view of what is currently happening. When is it going to be ready? Don't hold your breath. Officially SGI has said by the end of the year, technically... whew frankly I can't even guess. I would hope within a month or so we will have the basics of a FS. There are a lot of hurtles to overcome. XFS is a very very complex file system that relies on some of the more advanced features of IRIX. The buffer cache and chunk cache (chunking buffers together to do large IO) are two examples that come to mind. SGI is rewriting the buffer cache (calling it the page cache) such that is will be able to support XFS. chunk cache... ? not sure what we are going to do with that. We have been having several discussions about the best way to "interface". IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface but of course very IRIX specific. Linux's vfs/vnode is different from either. Realizing this, a lot of our discussions have been around how to go at making a new/modify existing interface layer that might be more "universal" i.e. not irix not linux not bsd not etc.... specific. In reading Terry's & Bill's comments seems there is a a lot of room for improvement. Initially we trying to make as few changes as possible to XFS to get an initial implementation running on linux. After we get things running we will start to analyze where the problems exist, and decide what direction in terms of interface to take at that time. I would like any constructive input people have on this matter. I have a pretty good chance of setting design direction. Be waned: SGI at the moment is committed to linux, development directions will favor that platform. They are not against other OS's being XFS'atized but SGI is in the business of selling hardware/solutions based on that hardware and linux one of the OS they have decided to use for their intel based boxes. Also as far as the GPL issue goes, get over it! I understand the issues and agree with many of the points. My suggestion lets find a way to work with the GPL (i.e. loadable kernel module / softupdates model) If somebody has a very very good argument/solution to the licensing debate let me know, I can present it to the people dealing with the lawyers. The license issue has slowed the release of the actual code more than anything else, and will not be revisited again without great pain. > I am currently conducting a thorough study of the VFS subsystem > in preparation for an all-out effort to port SGI's XFS filesystem to > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon > has written in hackers- that the VFS subsystem is presently not > well understood by any of the active kernel code contributers and > that it will be rewritten later this year. This is obviously of great > concern to me in this port. I greatly appreciate all assistance in > answering the following questions: > > 1) What are the perceived problems with the current VFS? > 2) What options are available to us as remedies? > 3) To what extent will existing FS code require revision in order > to be useful after the rewrite? > 4) Will Chapters 6,7,8 & 9 of "The Design and Implementation of > the 4.4BSD Operating System" still pertain after the rewrite? > 5) How important are questions 3 & 4 in the design of the new > VFS? > > I believe that the VFS is conceptually sound and that the existing > semantics should be strictly retained in the new code. Any new > functionality should be added in the form of entirely new kernel > routines and system calls, or possibly by such means as > converting the existing routines to the vararg format &etc. > > Does anyone know when SGI will release XFS? > > -- Russell Cattelan cattelan@thebarn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 7:22:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id E46AA15151 for ; Thu, 19 Aug 1999 07:22:44 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id KAA91343 for ; Thu, 19 Aug 1999 10:21:42 -0400 (EDT) Message-Id: <199908191421.KAA91343@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: CDROM boot on a ThinkPad 600E... Date: Thu, 19 Aug 1999 10:21:40 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been attempting to track down why cdrom boots will not work with /boot/loader, but do just fine with the boot-block. I have come to the following wild speculation, and stab in the dark. /boot/loader uses some int13 stuff, which I found while reading in the boot0inst man page may cause trouble on certain machines. I believe this may be our smoking gun, but I lack the time and experience to actually track it down. I could use boot0cfg to set 'packet' mode, but I am affraid that by doing so I may loose all access to my machine and need to attack it with a boot floppy. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 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 19 8:14:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4EB40150B0 for ; Thu, 19 Aug 1999 08:14:20 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id LAA92421 for ; Thu, 19 Aug 1999 11:13:37 -0400 (EDT) Message-Id: <199908191513.LAA92421@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: PCI programming woes. Date: Thu, 19 Aug 1999 11:13:36 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to write a very kludgey/monolithic driver for a CardBus ethernet adapter. I have run into a bit of a stumbling block on some issues. One such issue is the attach (I need to map some registers of the adapter into memory space so I can read/write values.). Anyway if someone could explain some of the following I would be very thankfull. Take your average run-to-the mill PCI network driver... like FPA or FXP. Now look for the attach routines... there are *2* of them, with the exact same function name, and different arguments?!?! Huh, what is going on here? Help? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 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 19 8:17:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id 05539151B2 for ; Thu, 19 Aug 1999 08:17:33 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id SAA21703; Thu, 19 Aug 1999 18:16:38 +0300 (EEST) Date: Thu, 19 Aug 1999 18:16:38 +0300 (EEST) From: Narvi To: Christopher Seiwald Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? In-Reply-To: <199908182356.QAA09187@perforce.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doesn't the qsort just switch to isort *if* the partition to sort is short enough? Got to check it out, but afaik the size at that qsorts switch to isort is usually between 8 and 24, with 16 being most common - both halfs are shorter than 16, so they get isorted. Sander There is no love, no good, no happiness and no future - all these are just illusions. On Wed, 18 Aug 1999, Christopher Seiwald wrote: > The FreeBSD qsort implementation has a rather nasty degenerate case. > If you have data that partitions exactly about the median pivot, yet > which is unsorted in either partition, you get get treated to an insertion > sort. Example: > > 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 > > qsort picks 10 as the median, does no swaps on its first pass, and so > decides to switch to an insertion sort. The idea is that if no swaps > occur, the data is likely to be nearly already sorted and a good candidate > for insertion sort. This turns out to be a (very) bad idea if you have > some unsorted data buried in the middle of a (very) large dataset. > > The implementation claims to come from Bentley and McIlroy's paper, > "Engineering a Sort Function," and this is largely true, but the insertion > sort optimization(?) isn't in that paper. The GNU qsort.c only does an > insertion sort if it is below a certain threshhold in size, and so never > attempts such a sort on the whole dataset. (The GNU qsort does a number > of other things pooh-poohed in the Bentley paper.) > > It's a pretty straightforward change to bypass the insertion sort for > large subsets of the data. If no one has a strong love for qsort, I'll > educate myself on how to make and contribute this change. > > Christopher > ---- > Christopher Seiwald Perforce Software 1-510-864-7400 > seiwald@perforce.com f-f-f-fast SCM http://www.perforce.com > > > > 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 Thu Aug 19 8:34:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by hub.freebsd.org (Postfix) with ESMTP id 82365150B0 for ; Thu, 19 Aug 1999 08:34:06 -0700 (PDT) (envelope-from peter.edwards@isocor.ie) Received: from isocor.ie (194.106.155.218) by penrose.isocor.ie; 19 Aug 1999 16:29:45 +0100 Message-ID: <37BC23B1.93A419DA@isocor.ie> Date: Thu, 19 Aug 1999 16:33:05 +0100 From: Peter Edwards Organization: ISOCOR X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: "David E. Cross" Cc: freebsd-hackers@freebsd.org Subject: Re: PCI programming woes. References: <199908191513.LAA92421@cs.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David E. Cross" wrote: > [snip] > Take your average run-to-the mill PCI network driver... like FPA or FXP. Now > look for the attach routines... there are *2* of them, with the exact same > function name, and different arguments?!?! > > Huh, what is going on here? Help? In if_fxp.c, goto the first definition of fxp_attach, search backwards for '#if defined(__NetBSD__)', note the matching '#else /* __FreeBSD__ */', then get some sleep :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 8:47: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 06922150B0; Thu, 19 Aug 1999 08:46:42 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id KAA02280; Thu, 19 Aug 1999 10:47:29 -0500 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma002157; Thu, 19 Aug 99 10:46:42 -0500 Received: from stlabcexg006.anheuser-busch.com ([151.145.101.161]) by 151.145.101.130 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Aug 1999 15:44:28 0000 (GMT) Received: by stlabcexg006.anheuser-busch.com with Internet Mail Service (5.5.2448.0) id ; Thu, 19 Aug 1999 10:44:06 -0500 Message-ID: <0740CBD1D149D31193EB0008C7C56836EB8B14@STLABCEXG012> From: "Alton, Matthew" To: "'Russell Cattelan'" Cc: "'Hackers@FreeBSD.ORG'" , "'fs@FreeBSD.ORG'" Subject: RE: BSD XFS Port & BSD VFS Rewrite Date: Thu, 19 Aug 1999 10:44:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do you have access to more of the code than is currently posted on SGI's web page? I am willing to sign an NDA in order to get access to all relevant source. I would like to assist in porting XFS to Linux also. I would very much like to see SGI succeed by using open source software in the commercial realm. As for licensing issues, I am purely agnostic -- I trust that any legal issues can be worked out after the fact by the proper people. > -----Original Message----- > From: Russell Cattelan [SMTP:cattelan@thebarn.com] > Sent: Thursday, August 19, 1999 12:41 AM > To: Alton, Matthew > Cc: 'Hackers@FreeBSD.ORG'; 'fs@FreeBSD.ORG' > Subject: Re: BSD XFS Port & BSD VFS Rewrite > > Glad to hear somebody is willing to dive in to XFS. > > > Right now I am one of three people working on the XFS to linux port, so I > have > pretty good view of what is currently happening. > > When is it going to be ready? > Don't hold your breath. Officially SGI has said by the end of the year, > technically... whew > frankly I can't even guess. I would hope within a month or so we will > have the basics of a FS. > > There are a lot of hurtles to overcome. XFS is a very very complex file > system that relies on > some of the more advanced features of IRIX. The buffer cache and chunk > cache (chunking > buffers together to do large IO) are two examples that come to mind. SGI > is rewriting > the buffer cache (calling it the page cache) such that is will be able to > support XFS. > chunk cache... ? not sure what we are going to do with that. > > We have been having several discussions about the best way to > "interface". > IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface > but of course very IRIX specific. Linux's vfs/vnode is different from > either. > Realizing this, a lot of our discussions have been around how to go at > making a > new/modify existing interface layer that might be more "universal" > i.e. not irix not linux not bsd not etc.... specific. > > In reading Terry's & Bill's comments seems there is a a lot of room for > improvement. > > Initially we trying to make as few changes as possible to XFS to get an > initial implementation > running on linux. After we get things running we will start to analyze > where the problems exist, > and decide what direction in terms of interface to take at that time. > > I would like any constructive input people have on this matter. I have a > pretty good > chance of setting design direction. > Be waned: SGI at the moment is committed to linux, development directions > will favor that platform. > They are not against other OS's being XFS'atized but SGI is in the > business of selling > hardware/solutions based on that hardware and linux one of the OS they > have decided to use for > their intel based boxes. > > Also as far as the GPL issue goes, get over it! I understand the issues > and agree with many > of the points. > My suggestion lets find a way to work with the GPL (i.e. loadable kernel > module / > softupdates model) > If somebody has a very very good argument/solution to the licensing > debate let me > know, I can present it to the people dealing with the lawyers. > The license issue has slowed the release of the actual code more than > anything else, > and will not be revisited again without great pain. > > > > I am currently conducting a thorough study of the VFS subsystem > > in preparation for an all-out effort to port SGI's XFS filesystem to > > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon > > has written in hackers- that the VFS subsystem is presently not > > well understood by any of the active kernel code contributers and > > that it will be rewritten later this year. This is obviously of great > > concern to me in this port. I greatly appreciate all assistance in > > answering the following questions: > > > > 1) What are the perceived problems with the current VFS? > > 2) What options are available to us as remedies? > > 3) To what extent will existing FS code require revision in order > > to be useful after the rewrite? > > 4) Will Chapters 6,7,8 & 9 of "The Design and Implementation of > > the 4.4BSD Operating System" still pertain after the rewrite? > > 5) How important are questions 3 & 4 in the design of the new > > VFS? > > > > I believe that the VFS is conceptually sound and that the existing > > semantics should be strictly retained in the new code. Any new > > functionality should be added in the form of entirely new kernel > > routines and system calls, or possibly by such means as > > converting the existing routines to the vararg format &etc. > > > > Does anyone know when SGI will release XFS? > > > > > > -- > Russell Cattelan > cattelan@thebarn.com > > > > > > 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 Thu Aug 19 8:56: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 0B16914C37; Thu, 19 Aug 1999 08:56:00 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id KAA04634; Thu, 19 Aug 1999 10:57:39 -0500 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma004561; Thu, 19 Aug 99 10:57:18 -0500 Received: from stlabcexg004.anheuser-busch.com ([151.145.101.160]) by 151.145.101.130 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Aug 1999 15:55:03 0000 (GMT) Received: by stlabcexg004.anheuser-busch.com with Internet Mail Service (5.5.2448.0) id ; Thu, 19 Aug 1999 10:54:54 -0500 Message-ID: <0740CBD1D149D31193EB0008C7C56836EB8B15@STLABCEXG012> From: "Alton, Matthew" To: "'Russell Cattelan'" Cc: "'Hackers@FreeBSD.ORG'" , "'fs@FreeBSD.ORG'" Subject: RE: BSD-XFS Update Date: Thu, 19 Aug 1999 10:55:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pinned in the AIX-style "pinned memory" sense? Succinctly, AIX allows userland programs to tag memory pages so as to guarantee that they will not be swapped to backing store. Portions of the _KERNEL_ are paged out instead if necessary. I assume that the pinning is of the AIX sort and that it is desirable, if not necessary, for the realtime throughput guarantee policy. Nes pas? > -----Original Message----- > From: Russell Cattelan [SMTP:cattelan@thebarn.com] > Sent: Thursday, August 19, 1999 1:01 AM > To: Alton, Matthew > Cc: 'Hackers@FreeBSD.ORG'; 'fs@FreeBSD.ORG' > Subject: Re: BSD-XFS Update > > "Alton, Matthew" wrote: > > > SGI has released a portion of the XFS source code under the GPL: > > > > http://oss.sgi.com/projects/xfs/download/ > > > > the source file is xfs_log.tar.gz. > > > > Of greater interest at this stage are the documents in: > > > > http://oss.sgi.com/projects/xfs/design_docs/ > > > > I am currently researching methods for implementing the 64-bit > > syscalls stat64(), fstat64(), lseek64() &etc. delineated in the > > SGI design doc _64 Bit File Access_ by Adam Sweeney. > > The xxxx64 calls are no longer an issue as of IRIX 6.(something 2 I > think) all > the standard calls were converted to use 64 bit types directly. > > Have a better one for you to research. > Find out if buffers can be pined? if not what is it going to take to fix > that. > > > > > The BSD-XFS port will be made available as a patch to the RELEASE > > FreeBSD kernels. > > Given the size of XFS it might be easier to make FreeBSD a patch to XFS. > <- major humor here. > :-) :-) > > > > > > > Matthew Alton > > Computer Services - UNIX Systems Administration > > (314)632-6644 matthew.alton@anheuser-busch.com > > alton@plantnet.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Russell Cattelan > cattelan@thebarn.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" 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 Thu Aug 19 9:10:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 6AE2F14C37 for ; Thu, 19 Aug 1999 09:10:14 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA09341 for ; Thu, 19 Aug 1999 12:09:28 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id MAA00362 for ; Thu, 19 Aug 1999 12:09:27 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908191609.MAA00362@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: sio doesn't do HW flow correctly?!? Date: Thu, 19 Aug 1999 12:09:27 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I thought I'd give people a chance to jump on this before I opened a PR on it. I'm currently using a Cyclades board at 115200 to talk to my PII laptop with a 16550A UART on board via a null modem cable. I'm trying to run PPP over the link with crtscts set, although I see the same problems using programs other than PPP. I stuck a printf() at line 2113 of /usr/src/sys/i386/isa/sio.c to see if CRTS_IFLOW was being turned on, whereas CRTS_IFLOW is the input half of crtscts. I managed to get the printf, so I'm assuming that sio is being advised to do RTS input flow control. However, when I start running data, I get silo overflows. Sometimes its more frequent than others, but its enough to keep most of the packets from going through the link. I have a breakout box on the line, as well as detectors in the Cyclades driver for sensing line state change, and RTS never drops on the 16550A. It just happily overflows. I realize that 99% of the time, sio is used with a modem. Therefore, also being a modem tester, I realize that its rare to completely saturate a 115200bps link between the modem and the UART in the PC (we have exactly one test case with highly-compressible data where this happens reliably), so I suspect that this problem may go unnoticed in many cases, simply because you don't fill the FIFO. I also went so far as to check individual RS232 signals via TIOCMSET to make sure that the port functioned as commanded. It did so. So, I suspect the problem is that the driver is not correctly driving flow control. I will therefore start to dive in to the problem to isolate it. However, I figured I'd give everyone a chance to comment before I filed a PR. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 9:13: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 200E115024 for ; Thu, 19 Aug 1999 09:13:01 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 4.0.1) with ESMTP id ; Thu, 19 Aug 1999 17:10:02 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Q99XZ29N; Thu, 19 Aug 1999 17:09:48 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 11HUlh-000Mjv-00; Thu, 19 Aug 1999 17:10:21 +0100 Date: Thu, 19 Aug 1999 17:10:21 +0100 To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: user mount f/s with kld's Message-ID: <19990819171020.A84183@voodoo.pandhm.co.uk> References: <37BBCA94.4519D6D5@baker.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37BBCA94.4519D6D5@baker.ie>; from Cillian Sharkey on Thu, Aug 19, 1999 at 10:12:52AM +0100 From: Dominic Mitchell Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 19, 1999 at 10:12:52AM +0100, Cillian Sharkey wrote: > I just setup my system so that "Joe" user can mount > /dev/fd0 on a mountpoint "Joe" owns..grand no problem.. > > ..BUT it only works when the f/s code for that f/s type is > available (ie. compiled into the kernel or has been previously > loaded as a module) > > however if it's not compiled into the kernel, or already > loaded as a module, user "Joe" can't mount the disk because > the module for that f/s type won't be loaded dynamically.. > > I presume this is because root is only allowed to use > kldload.. ? Yes. To get around this, I preloaded any FS modules I thought I would need in /boot/loader.conf. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Finally, when replying to messages only quote the parts of the message your will be discussing or that are relevant. Quoting whole messages and adding two lines at the top is not good etiquette." -- Elias Levy ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 9:29:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 2B974151A3 for ; Thu, 19 Aug 1999 09:29:22 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id MAA13645 for ; Thu, 19 Aug 1999 12:29:12 -0400 (EDT) Date: Thu, 19 Aug 1999 12:15:51 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: Kernel debugging questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am using FreeBSD 4.0 and have two questions on kernel debugging: (1) Can I specify /usr/src/sys/compile/MYKERN/kernel.debug as the kernel to boot from manually without copying that file under /? It seems I can not do so. I guess the reason is that the /usr is not mounted at that time. (2) After bootup, I try the following to debug the live system (after reading some pages of the book "Panic! Unix system crash dump analysis"): now4# gdb -k /kernel.debug /dev/mem (kgdb) run Starting program: /kernel.debug Program terminated with signal SIGABRT, Aborted. The program no longer exists. You can't do that without a process to debug. Is there something wrong? I did the same thing with the postmortem coredump files and got similar messages. Maybe I am using gdb in a wrong way. Any help is appreciated. -------------------------------------------------- Zhihui Zhang. Please visit http://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 Thu Aug 19 10:11:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id AE76B14E52 for ; Thu, 19 Aug 1999 10:11:31 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA31017; Thu, 19 Aug 1999 11:11:07 -0600 (MDT) (envelope-from ken) Message-Id: <199908191711.LAA31017@panzer.kdm.org> Subject: Re: Gigabit ethernet support? In-Reply-To: <37BBA73D.37765DD5@softweyr.com> from Wes Peters at "Aug 19, 1999 00:42:05 am" To: wes@softweyr.com (Wes Peters) Date: Thu, 19 Aug 1999 11:11:07 -0600 (MDT) Cc: wpaul@skynet.ctr.columbia.edu, crandall@matchlogic.com, dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote... > "Kenneth D. Merry" wrote: > > Wes Peters wrote... > > > We have two of the NetGear GA620's here, and they work quite nicely. I use > > > them for testing throughput via Gig-E on our switches. Mine is running in > > > a lowly PII/233, on a 32-bit x 33 Mhz slot, and can push bits at 320 Mbps. > > > The GA620 will work in any 32 or 64 bit, 33 or 66 Mhz slot. A 64x66 slot > > > would probably speed things up appreciably. > > > > I doubt a faster PCI interface would really speed things up. My guess is > > that you've got some other bottleneck other than PCI bandwidth. Is the CPU > > pegged on either end? > > Not on mine, it's running about 45%. The other end is much faster, a PII/400, > and is just discarding the packets, so it's not sweating. The window size tweaks may help you somewhat. > > I would recommend that you make sure you've got a couple of things tweaked, > > they may increase your performance somewhat: > > > > - set your MTU to 9000, unless of course you're going through a switch that > > can't handle it > > Not yet, that's part of what I will be developing. ;^) Due to architectural > limitations, we may not be able to support jumbo frames larger than 8k. That's unfortunate, since you won't be compliant with the pseudo-standard. With 1500 byte packets, you probably won't be able to get much better throughput than what you're getting now. I can get about 340Mbps with standard sized packets with a couple Pentium II 350's, and the CPU isn't pegged on either end. 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 Thu Aug 19 11: 3:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 4D249159DE; Thu, 19 Aug 1999 11:03:25 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA13024; Thu, 19 Aug 1999 11:02:27 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAAH8aWyz; Thu Aug 19 11:02:23 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA25563; Thu, 19 Aug 1999 11:02:34 -0700 (MST) From: Terry Lambert Message-Id: <199908191802.LAA25563@usr06.primenet.com> Subject: Re: BSD XFS Port & BSD VFS Rewrite To: dcs@newsguy.com (Daniel C. Sobral) Date: Thu, 19 Aug 1999 18:02:34 +0000 (GMT) Cc: tlambert@primenet.com, phk@critter.freebsd.dk, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG In-Reply-To: <37BB88F3.7184305@newsguy.com> from "Daniel C. Sobral" at Aug 19, 99 01:32:51 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Terry Lambert wrote: > > > > Make sure that the system you are talking to over the proxy is > > not assumed to be a FreeBSD system (e.g. don't assume that the > > vfs_default stuff exists on the other end of the proxy, or that > > it would be functional). > > Now, Terry, that is ridiculous. One has to assume that both ends > play by the same rules. That is not only a reasonably expectation, > it's minimum requirement for any protocol to work. That's kind of the point. No other VFS stacking system out there plays by FreeBSD's revamped rules. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 11:16:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3A0D9151D5 for ; Thu, 19 Aug 1999 11:16:00 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id LAA94818; Thu, 19 Aug 1999 11:10:13 -0700 (PDT) From: Archie Cobbs Message-Id: <199908191810.LAA94818@bubba.whistle.com> Subject: Re: anybody love qsort.c? In-Reply-To: from Narvi at "Aug 19, 1999 06:16:38 pm" To: narvi@haldjas.folklore.ee (Narvi) Date: Thu, 19 Aug 1999 11:10:13 -0700 (PDT) Cc: seiwald@perforce.com (Christopher Seiwald), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Narvi writes: > Doesn't the qsort just switch to isort *if* the partition to sort is short > enough? That's exactly Christopher's point. It should do this but it doesn't. The code is complex but from a quick glance it appears that the decision to switch to insertion sort does not depend on the total array length. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 11:16:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4BA7215976 for ; Thu, 19 Aug 1999 11:16:32 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA17858 for FreeBSD-hackers@freebsd.org; Thu, 19 Aug 1999 20:11:48 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA78676 for FreeBSD-hackers@freebsd.org; Thu, 19 Aug 1999 20:09:56 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908191809.UAA78676@yedi.iaf.nl> Subject: recommended reading for PCI bus/drivers? To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Thu, 19 Aug 1999 20:09:56 +0200 (CEST) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm looking for background (reading) info on the PCI bus. Looking for the tech detail required for writing PCI device drivers. I invite suggestions for books that can help me in this matter. ISBNs would be practical I guess. Thanks, Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://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 Thu Aug 19 11:32:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B2F2614FAF for ; Thu, 19 Aug 1999 11:32:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA01142; Thu, 19 Aug 1999 11:31:41 -0700 Date: Thu, 19 Aug 1999 11:31:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: FreeBSD hackers list Subject: Re: recommended reading for PCI bus/drivers? In-Reply-To: <199908191809.UAA78676@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think very highly of the MindShare book "PCI System Architecture" Addison-Wesley, 1995 ISBN 0-201-40993-3 On Thu, 19 Aug 1999, Wilko Bulte wrote: > I'm looking for background (reading) info on the PCI bus. Looking > for the tech detail required for writing PCI device drivers. > > I invite suggestions for books that can help me in this matter. ISBNs > would be practical I guess. > > Thanks, > > Wilko > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > > > 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 Thu Aug 19 11:39:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell3.ba.best.com (shell3.ba.best.com [206.184.139.134]) by hub.freebsd.org (Postfix) with ESMTP id 1738A156C6 for ; Thu, 19 Aug 1999 11:39:35 -0700 (PDT) (envelope-from gena@shell3.ba.best.com) Received: (from gena@localhost) by shell3.ba.best.com (8.9.3/8.9.2/best.sh) id LAA19182 for hackers@freebsd.org; Thu, 19 Aug 1999 11:38:59 -0700 (PDT) From: Gena Gulchin Message-Id: <199908191838.LAA19182@shell3.ba.best.com> Subject: Question regarding Xaccel To: hackers@freebsd.org Date: Thu, 19 Aug 1999 11:38:58 -0700 (PDT) Organization: MCCP dot com X-Class: Fast Reply-To: gena@MCCP.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 11:43:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 37DFB15166 for ; Thu, 19 Aug 1999 11:42:53 -0700 (PDT) (envelope-from mcr@istari.sandelman.ottawa.on.ca) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id OAA28738; Thu, 19 Aug 1999 14:45:31 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost.sandelman.ottawa.on.ca [127.0.0.1]) by istari.sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id NAA02016; Thu, 19 Aug 1999 13:05:51 -0400 (EDT) Message-Id: <199908191705.NAA02016@istari.sandelman.ottawa.on.ca> To: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Your message of "Wed, 18 Aug 1999 17:15:15 CDT." Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Aug 1999 13:05:51 -0400 From: "Michael C. Richardson" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com] >>>>> "Chris" == Chris Dillon writes: Chris> An origin filesystem (created by and mounted on the same system) which Chris> happens to have stuff owned by several different users (this is all Chris> pseudo... don't mind sizes, dates, and link counts in this example): Chris> drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/ Chris> ls -la dir1 Chris> -rw-r----- 1 harry users 0 Aug 18 15:48 bar Chris> -rw-r----- 1 harry users 0 Aug 18 15:48 foo Chris> Take this filesystem and mount it as a "foreign" filesystem on another Chris> machine. User 'jake' owns the mountpoint on the machine. Chris> drwxr-xr-x 2 jake users 512 Jan 4 1999 /mnt/ Chris> mount_foreign /dev/whatever /mnt Chris> ls -la /mnt Chris> drwxr-xr-x 4 jake users 512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 jake users 512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 jake users 512 Jul 1 18:40 dir2/ Chris> ls -la /mnt/dir1/ Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 bar Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 foo Chris> Note file mode bits were not affected, but everything gained the Chris> user/group of the mountpoint. I agree up to this point. Chris> Now what happens if user 'jake' adds something to the filesystem? Chris> touch /mnt/dir1/baz Chris> ls -la /mnt/dir1/ Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 bar Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 foo Chris> -rw-r----- 1 jake users 0 Aug 18 15:50 baz >> From jake's perspective, this happens as if it were an origin Chris> filesystem and he owned everything on it. Chris> Now, mount the filesystem again on it's origin system. First, a question: if the disk was mounted by root on the origin system, then I'm not sure it is safe to mount it again after it has been in another's hand. I would suggest that to facilitate cooperation, that the new file should be made with "jake"'s userid. That may conflict, but I suggest that this is a higher level issue. Chris> 1) When writing to a foreign filesystem, should file mode bits Chris> be inherited from the parent, or be based on the umask of the foreign Chris> user writing the file at that time? Can the umask of the foreign Chris> owner be preserved (which isn't necessarily the same thing as Chris> inheriting from the parent) and used? I'd say you leave things as is for a file system now. Chris> 2) How should chown and chgrp act when attempting to modify Chris> credentials on one of these foreign filesystems? Should it affect Chris> only the local credential mapping (temporarily) and not modify the Chris> foreign filesystem? Should you completely ignore the attempts and I suggest that they fail as non-root can't do chown. If you are root doing this, then you have no problem, but you don't mount as root. chgrp continues to function as normal, which may be wrong if groupids aren't shared, but I suggest that is too, a higher level problem. Chris> 3) What happens if you want to mount the filesystem on a Chris> machine besides the origin, but you do NOT want to do credential Chris> mapping (i.e. the systems both have the same sets of users)? This Chris> wouldn't matter if you just used a mount option or different Chris> filesystem type when mounting, but I'm assuming something automagic is Chris> wanted here. You have to mount as root. Chris> 4) What happens if you change the credentials of the Chris> mountpoint after you have mounted the foreign filesystem? Should the Chris> mappings follow the new credentials, or stay as they were when first Chris> mounted? It requires some kind of mount/umount operation. It might be as simple as doing: "eject floppy" which will fail because the file system is mounted, but it will then reexamine the mount point. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12: 5:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id EDC0D15183 for ; Thu, 19 Aug 1999 12:05:16 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-163.skylink.it [194.185.55.163]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id VAA25078; Thu, 19 Aug 1999 21:04:58 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id VAA07669; Thu, 19 Aug 1999 21:05:15 +0200 (CEST) Date: Thu, 19 Aug 1999 21:05:14 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: gena@MCCP.com Cc: hackers@FreeBSD.ORG Subject: Re: Question regarding Xaccel In-Reply-To: <199908191838.LAA19182@shell3.ba.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Could you post a URL? Nick > on Xinside site (www.xig.com) it says... > > FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD > core team. > > Why was that advice given... > > > -Gena > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:12:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from perforce.com (spice.perforce.com [206.14.52.195]) by hub.freebsd.org (Postfix) with ESMTP id 192A914E32 for ; Thu, 19 Aug 1999 12:12:38 -0700 (PDT) (envelope-from seiwald@perforce.com) Received: (from seiwald@localhost) by perforce.com (8.9.3/8.9.3) id MAA10750; Thu, 19 Aug 1999 12:14:46 -0700 (PDT) (envelope-from seiwald) Date: Thu, 19 Aug 1999 12:14:46 -0700 (PDT) From: Christopher Seiwald Message-Id: <199908191914.MAA10750@perforce.com> To: archie@whistle.com, gurney_j@efn.org, narvi@haldjas.folklore.ee Subject: Re: anybody love qsort.c? Cc: freebsd-hackers@freebsd.org In-Reply-To: <199908191810.LAA94818@bubba.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Answers to sundry comments: | why don't you implement this w/ the 5 element median selection qsort | algorithm? my professor for cis413 talked about this algorithm and | that it really is the fastest qsort algorithm... qsort algorithms are like stock market tips: only good in retrospect. The bentley scheme uses a 9 element median selection (80% better?). | Doesn't the qsort just switch to isort *if* the partition to sort is short | enough? Yes -- if it is < 7 elements, it always does isort. But the problem is that it will switch to isort if it believes the data is mostly sorted, and it comes to this conclusion incorrectly. Unfortunately, I haven't found a sure-fire way to improve this. | The code is complex but from a quick glance it appears that the decision | to switch to insertion sort does not depend on the total array length. Right. Actually, once you get into it, the code is relatively simple. It is one of the features of the Bentley code. Christopher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:18:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrtc.org (waena.mrtc.org [199.4.33.17]) by hub.freebsd.org (Postfix) with ESMTP id 5210D1517D for ; Thu, 19 Aug 1999 12:18:29 -0700 (PDT) (envelope-from puga@maui.com) Received: from maui.com (puga.mauibuilt.com [205.166.10.2]) by mrtc.org (8.8.4/8.8.4) with ESMTP id JAA02979 for ; Thu, 19 Aug 1999 09:29:57 -1000 (HST) Message-ID: <37BC57B8.54E11F99@maui.com> Date: Thu, 19 Aug 1999 09:15:04 -1000 From: Richard Puga Organization: Maui Built Machines X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: WaveLAN IEEE device timeout Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am having a problem with 2 WaveLan IEE Turbo PC cards. One is running via an isa adaptor in a desktop which is lynked in ad-hoc mode to a lap top a couple of miles away through the use of external anennas. Obvously both machines are stationary and dont move. I am running 3.2-RELEASE-PAO on both machines. I am running PAO because I was not able to intergrate the driver itself to 3.2R although I will try when I have more time. The PAO install may have somgint to do with my problem so I wanted to point it out. However I am using the lastest driver I found on your web page located at http://www.freebsd.org/~wpaul/WaveLAN/3.0 and dated July 20th. The cards work great and I have a solid lynk according to the WaveLAN diagnostics in windows95. Under FreeBSD I get about 4.6 megabits tranfer, which I am very happy with. But there does seem to be an intermitant problem. On occation (sometimes days somtimes hours) the card will lock up. Both lights on the card will just stay on. I get the following messages on the console. Aug 15 07:21:06 cray100 /kernel: wi0: failed to allocate 1594 bytes on NIC Aug 15 07:21:06 cray100 /kernel: wi0: tx buffer allocation failed Aug 15 07:21:06 cray100 /kernel: wi0: failed to allocate 1594 bytes on NIC Aug 15 07:21:06 cray100 /kernel: wi0: mgmt. buffer allocation failed Aug 15 07:21:09 cray100 /kernel: wi0: xmit failed Aug 15 07:21:15 cray100 /kernel: wi0: device timeout Aug 15 07:21:15 cray100 /kernel: wi0: init failed I thought it might be a problem with a particular card but it hapens at both ends. The machine it has happend more often on is an AMD K6 running at 350Mhz and is the computer with the ISA adaptor. The other is a Panasonic 166Mhz laptop. I there is any more information I can provde please let me know. Thank you for your time Richard Puga puga@mauibuilt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:24:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id F006A14E32 for ; Thu, 19 Aug 1999 12:24:27 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA07455; Thu, 19 Aug 1999 12:17:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908191917.MAA07455@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "David E. Cross" Cc: freebsd-hackers@freebsd.org Subject: Re: PCI programming woes. In-reply-to: Your message of "Thu, 19 Aug 1999 11:13:36 EDT." <199908191513.LAA92421@cs.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Aug 1999 12:17:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am trying to write a very kludgey/monolithic driver for a CardBus ethernet > adapter. I have run into a bit of a stumbling block on some issues. One such > issue is the attach (I need to map some registers of the adapter into memory > space so I can read/write values.). Anyway if someone could explain some > of the following I would be very thankfull. You're making life far too hard for yourself. FreeBSD doesn't reward you for trying to kludge things; the infrastructure you're looking for wants you to be using our bus interfaces. Have a look at pmap_mapdev() for what you're trying to do. > Take your average run-to-the mill PCI network driver... like FPA or FXP. Now > look for the attach routines... there are *2* of them, with the exact same > function name, and different arguments?!?! You're picking bad examples to work with, since both those drivers support multiple operating systems. Try a much cleaner driver like, eg. if_tl. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:37:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id CE30514E32 for ; Thu, 19 Aug 1999 12:37:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA07521; Thu, 19 Aug 1999 12:30:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908191930.MAA07521@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian McGovern Cc: hackers@freebsd.org Subject: Re: sio doesn't do HW flow correctly?!? In-reply-to: Your message of "Thu, 19 Aug 1999 12:09:27 EDT." <199908191609.MAA00362@bmcgover-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Aug 1999 12:30:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I thought I'd give people a chance to jump on this before I opened a PR on it. > > I'm currently using a Cyclades board at 115200 to talk to my PII laptop with > a 16550A UART on board via a null modem cable. I'm trying to run PPP over the > link with crtscts set, although I see the same problems using programs > other than PPP. > > I stuck a printf() at line 2113 of /usr/src/sys/i386/isa/sio.c to see if > CRTS_IFLOW was being turned on, whereas CRTS_IFLOW is the input half of > crtscts. > > I managed to get the printf, so I'm assuming that sio is being advised to do > RTS input flow control. > > However, when I start running data, I get silo overflows. Sometimes its more > frequent than others, but its enough to keep most of the packets from going > through the link. > > I have a breakout box on the line, as well as detectors in the Cyclades driver > for sensing line state change, and RTS never drops on the 16550A. It just > happily overflows. > > I realize that 99% of the time, sio is used with a modem. Therefore, also being > a modem tester, I realize that its rare to completely saturate a 115200bps link > between the modem and the UART in the PC (we have exactly one test case with > highly-compressible data where this happens reliably), so I suspect that this > problem may go unnoticed in many cases, simply because you don't fill the FIFO. > > I also went so far as to check individual RS232 signals via TIOCMSET to make > sure that the port functioned as commanded. It did so. > > So, I suspect the problem is that the driver is not correctly driving flow > control. > > I will therefore start to dive in to the problem to isolate it. However, I > figured I'd give everyone a chance to comment before I filed a PR. "Silo overflow" is "the input FIFO filled up before the interrupt handler managed to respond". Since flow control on the 8250-family parts is handled entirely in software, the problem is not that flow control is not being "correctly driven", but rather that interrupt response time on your system is sufficiently poor that the time between the interrupt trigger at either 8 or 14 (I forget) characters in the FIFO and overflow (at the 17th character) is less than the time it takes your system to respond to the interrupt. In order to debug this, you will need to use a logic analyser to trap the case where the interrupt is not handled quickly enough, and snoop enough of the rest of the system (probably parts of the PCI bus at least) to work out what it's actually doing to keep it away from the UART. A few weeks ago I was at a local embedded FreeBSD shop while they were debugging a similar problem they experience with their product, which turned out to be an extension of a known erratum in the Cyrix MediaGX's PIC macrocell, whereby multiple simultaneous interrupts are not handled correctly and thus the UART interrupts are lost completely. You may be facing a similar problem, but without the right test equipment and access to suitable documentation you may have considerable trouble in determining this for certain. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:40:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 440A7154C2 for ; Thu, 19 Aug 1999 12:40:23 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA07552; Thu, 19 Aug 1999 12:34:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908191934.MAA07552@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel debugging questions In-reply-to: Your message of "Thu, 19 Aug 1999 12:15:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Aug 1999 12:34:14 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am using FreeBSD 4.0 and have two questions on kernel debugging: > > (1) Can I specify /usr/src/sys/compile/MYKERN/kernel.debug as the kernel > to boot from manually without copying that file under /? It seems I can > not do so. I guess the reason is that the /usr is not mounted at that > time. Yes, although it's not particularly simple and will cause applications that use libkvm to become quite confused. For example, if your /usr filesystem is on wd0s1e, you can say load disk0s1e:/src/sys/compile/MYKERN/kernel.debug inside the loader (you may need to say 'unload' first to remove the default kernel). This will leave the kern.bootfile sysctl saying "/src/sys/compile/MYKERN/kernel.debug" and thus any application trying to read the kernel symbol table will fail. You can hack around this by placing a suitable symlink in /. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:47:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 801A6151C6 for ; Thu, 19 Aug 1999 12:47:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA07616; Thu, 19 Aug 1999 12:41:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908191941.MAA07616@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte Cc: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Subject: Re: recommended reading for PCI bus/drivers? In-reply-to: Your message of "Thu, 19 Aug 1999 20:09:56 +0200." <199908191809.UAA78676@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Aug 1999 12:41:15 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm looking for background (reading) info on the PCI bus. Looking > for the tech detail required for writing PCI device drivers. > > I invite suggestions for books that can help me in this matter. ISBNs > would be practical I guess. Tech data on the PCI bus isn't a lot of help when it comes to writing device drivers, actually. The best reading on the latter is probably the collection in /sys/pci. If you're looking for a basic grounding, the Mindshare "PCI System Architecture" book is pretty good, and cheap enough that you won't feel that you were ripped off... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 12:52:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 28ACE151C6 for ; Thu, 19 Aug 1999 12:51:54 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id MAA64007; Thu, 19 Aug 1999 12:48:53 -0700 (PDT) Date: Thu, 19 Aug 1999 12:50:11 -0700 (PDT) From: Julian Elischer To: Mike Smith Cc: Brian McGovern , hackers@FreeBSD.ORG Subject: Re: sio doesn't do HW flow correctly?!? In-Reply-To: <199908191930.MAA07521@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Aug 1999, Mike Smith wrote: > > A few weeks ago I was at a local embedded FreeBSD shop while they were > debugging a similar problem they experience with their product, which > turned out to be an extension of a known erratum in the Cyrix MediaGX's > PIC macrocell, whereby multiple simultaneous interrupts are not handled > correctly and thus the UART interrupts are lost completely. You may be > facing a similar problem, but without the right test equipment and > access to suitable documentation you may have considerable trouble in > determining this for certain. A Well here at the local embedded FreeBSD shop, we later went on to discover 2 differnt sources to teh problem, neither of which was what we thought it was when Mike was here.. Certainly, we were getting a lot of spurious interrupts on ANOTHER port (check `systat -vmstat 1` to see if this is happenning) and the system was spendign too much time looping looking at that port to react to the real interrupts ont the sio port in question.. the other was that the DISK controller (I hear you say "huh? how does DISK come into this?") was HOGGING the PCI bus for upto 4mSec at a time which was long enough for the sio to overflow. Remember that the ISA bus is usually reached VIA the PCI bus on modern systems. I have fixed the UDMA driver to run the Cyrix disk DMA engine in a slightly slower mode so that it doesn't hog the PCI bus quite as much and now we can actually get to the ISA bus while the dik is doing DMA. This just goes top show that sometimes it's really hard to figure out why you are missing interrupts.. It took a $50,000 logic analyser on the PCI bus (and the uart chip) to figure that one out so it may or may not bbe so simple... julian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 13:23:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id B145315273 for ; Thu, 19 Aug 1999 13:23:05 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA17555; Thu, 19 Aug 1999 16:22:53 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id QAA01004; Thu, 19 Aug 1999 16:22:51 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908192022.QAA01004@bmcgover-pc.cisco.com> To: Mike Smith Cc: hackers@freebsd.org Subject: Re: sio doesn't do HW flow correctly?!? In-reply-to: Your message of "Thu, 19 Aug 1999 12:30:08 PDT." <199908191930.MAA07521@dingo.cdrom.com> Date: Thu, 19 Aug 1999 16:22:51 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks, Mike. I don't think they'll let me rip apart my laptop to test this. I guess I'll try it on a normal PC, and try to track it if it continues. Thanks. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 14: 1:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id 2BD001515F; Thu, 19 Aug 1999 14:01:15 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id WAA27646; Thu, 19 Aug 1999 22:40:23 +0200 (CEST) Message-Id: <199908192040.WAA27646@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: mark+freebsd@xaa.mpn.cp.philips.com Cc: freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD Reply-To: Gary Jennejohn In-reply-to: Your message of "Wed, 18 Aug 1999 14:58:50 +0200." <19990818145850.E17189@xaa.mpn.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Aug 1999 22:40:23 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Huizer writes: >Hi there, > >I had a look recently at the code for one of the kernel modules that VMWare >requires (driver-only.tar), and it looks like something that should be >portable to FreeBSD, although there is some messy stuff in it (assembly >that seems to be using Linux specific stuff, brrr..) But anyway: it >looks feasable. > >Is anyone already working on this, or are some people interested in >helping with this? > >As far as I can see, the linux emulation is good enough to run the >vmware program, "all" you need to do is implement /dev/vmmon and >/dev/vmnet, given the fact that the code is written really unportable, >so there is some rewriting to be done. Then with the KLD's >vmmon,vmnet and linux you should be able to run vmware. > Soren mentioned that he might look into it a few weeks ago, but that's the last thing I remember seeing. I'm interested in helping with this, though. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 15:56:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id AF21314D4E for ; Thu, 19 Aug 1999 15:56:53 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from ivy (ivy.ezo.net [206.150.211.171]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id SAA09571; Thu, 19 Aug 1999 18:55:03 -0400 (EDT) Message-ID: <002d01beea96$0c18d2e0$abd396ce@eznet> From: "Jim Flowers" To: "Richard Puga" , References: <37BC57B8.54E11F99@maui.com> Subject: Re: WaveLAN IEEE device timeout Date: Thu, 19 Aug 1999 18:56:17 -0400 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I use the WaveLAN ISA/IEEE card in FreeBSD systems without problems (4 of them so far). I had to use cvsup to get Bill Paul's driver installed as part of 3.2-stable. The driver seems to be very stable and so far we have not had any lockups or other mis-operations (about 2 months). Not as good a record for the WaveLAN/EC converters. They appear to be a little sensitive and currently do not support raw bit rates above 2Mb/s although the Turbo cards work OK at that rate in them. Best data rates are obtained from an ISA/IEEE card in a fbsd box to a fbsd box connected to the Ethernet port of WavePOINT II access controller, both using Turbo cards. The WaveLAN fbsd is plain vanilla and works OK with natd and ipfw on the wi0 interface. Can't use the SKIP port with the wi0 interface due to some sort of interaction that I was never able to figure out. Doing both point-to-point and point-to-multipoint over distances to 2.1 miles. No dropouts. I would suggest you try -stable. It's worth the effort and the standard LINT kernel entries and rc.conf setup stuff is about all you need. Even supports hot card swapping. ----- Original Message ----- From: Richard Puga To: Sent: Thursday, August 19, 1999 3:15 PM Subject: WaveLAN IEEE device timeout > I am having a problem with 2 WaveLan IEE Turbo PC cards. > > One is running via an isa adaptor in a desktop which is lynked in ad-hoc > > mode to a lap top a couple of miles away through the use of external > anennas. > > Obvously both machines are stationary and dont move. I am running > 3.2-RELEASE-PAO on both machines. I am running PAO because I was not > able to intergrate the driver itself to 3.2R although I will > try when I have more time. The PAO install may have somgint to do with > my problem so I wanted to point it out. However I am using the lastest > driver I found on your web page located at > http://www.freebsd.org/~wpaul/WaveLAN/3.0 and dated July 20th. > > > The cards work great and I have a solid lynk according to the WaveLAN > diagnostics in windows95. > > Under FreeBSD I get about 4.6 megabits tranfer, which I am very happy > with. > > But there does seem to be an intermitant problem. > > On occation (sometimes days somtimes hours) the card will lock up. Both > lights on the card will just stay on. I get the following messages > on the console. > > Aug 15 07:21:06 cray100 /kernel: wi0: failed to allocate 1594 bytes on > NIC > Aug 15 07:21:06 cray100 /kernel: wi0: tx buffer allocation failed > Aug 15 07:21:06 cray100 /kernel: wi0: failed to allocate 1594 bytes on > NIC > Aug 15 07:21:06 cray100 /kernel: wi0: mgmt. buffer allocation failed > Aug 15 07:21:09 cray100 /kernel: wi0: xmit failed > Aug 15 07:21:15 cray100 /kernel: wi0: device timeout > Aug 15 07:21:15 cray100 /kernel: wi0: init failed > > I thought it might be a problem with a particular card but it hapens at > both ends. > > The machine it has happend more often on is an AMD K6 running at 350Mhz > and is the computer with > the ISA adaptor. The other is a Panasonic 166Mhz laptop. > > I there is any more information I can provde please let me know. > > Thank you for your time > > Richard Puga > puga@mauibuilt.com > > > > 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 Thu Aug 19 16:19: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 5F13915099 for ; Thu, 19 Aug 1999 16:19:01 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id SAA14692; Thu, 19 Aug 1999 18:17:20 -0500 (CDT) Date: Thu, 19 Aug 1999 18:17:20 -0500 From: "Matthew D. Fuller" To: "Daniel C. Sobral" Cc: Larry Lile , hackers@FreeBSD.ORG, dlane@yahoo.com Subject: Re: async v. sync v. default mode on ufs Message-ID: <19990819181720.C2131@futuresouth.com> References: <37BB92E3.3CE11E86@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37BB92E3.3CE11E86@newsguy.com>; from Daniel C. Sobral on Thu, Aug 19, 1999 at 02:15:15PM +0900 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 19, 1999 at 02:15:15PM +0900, a little birdie told me that Daniel C. Sobral remarked > Larry Lile wrote: > > > > /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: > > sync 93 async 216) procfs on /proc (local) > > > > /var looks questionable... > > Indeed. :-) I'm still looking for a 'splanation for this one: /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) ^^^^^^^^^^^ ^^^^^^^^^ I don't WANT async writes! -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 16:52:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id AD97D15208 for ; Thu, 19 Aug 1999 16:52:11 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id SAA16811; Thu, 19 Aug 1999 18:52:04 -0500 (CDT) Date: Thu, 19 Aug 1999 18:52:04 -0500 From: "Matthew D. Fuller" To: Julian Elischer Cc: "Daniel C. Sobral" , Larry Lile , hackers@FreeBSD.ORG, dlane@yahoo.com Subject: Re: async v. sync v. default mode on ufs Message-ID: <19990819185204.D2131@futuresouth.com> References: <19990819181720.C2131@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Julian Elischer on Thu, Aug 19, 1999 at 04:40:43PM -0700 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 19, 1999 at 04:40:43PM -0700, a little birdie told me that Julian Elischer remarked > That one looks like a bug, either in reporting them or in doing them.. > > > /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) > > what version are you running? FreeBSD 4.0-CURRENT #1: Mon Aug 9 19:22:55 CDT 1999 -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 16:57:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 27AF915135 for ; Thu, 19 Aug 1999 16:57:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA75930; Thu, 19 Aug 1999 16:39:24 -0700 (PDT) Date: Thu, 19 Aug 1999 16:40:43 -0700 (PDT) From: Julian Elischer To: "Matthew D. Fuller" Cc: "Daniel C. Sobral" , Larry Lile , hackers@FreeBSD.ORG, dlane@yahoo.com Subject: Re: async v. sync v. default mode on ufs In-Reply-To: <19990819181720.C2131@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG That one looks like a bug, either in reporting them or in doing them.. On Thu, 19 Aug 1999, Matthew D. Fuller wrote: > > I'm still looking for a 'splanation for this one: > /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) > ^^^^^^^^^^^ ^^^^^^^^^ > > I don't WANT async writes! what version are you running? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 17: 4: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 6355B14E1F for ; Thu, 19 Aug 1999 17:04:03 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id UAA26540; Thu, 19 Aug 1999 20:11:00 -0400 (EDT) Date: Thu, 19 Aug 1999 20:10:59 -0400 (EDT) From: Alfred Perlstein To: "Alton, Matthew" Cc: "'Russell Cattelan'" , "'Hackers@FreeBSD.ORG'" Subject: RE: BSD XFS Port & BSD VFS Rewrite In-Reply-To: <0740CBD1D149D31193EB0008C7C56836EB8B14@STLABCEXG012> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Aug 1999, Alton, Matthew wrote: > Do you have access to more of the code than is currently posted on SGI's > web page? I am willing to sign an NDA in order to get access to all > relevant source. I would like to assist in porting XFS to Linux also. I would > very much like to see SGI succeed by using open source software in the > commercial realm. As for licensing issues, I am purely agnostic -- I trust that > any legal issues can be worked out after the fact by the proper people. You mean like the USL lawsuit? :) And why are we talking about Linux and crossposting it to two seperate FreeBSD mailing lists? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 17: 4:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id D288C152C6 for ; Thu, 19 Aug 1999 17:04:13 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id UAA15434; Thu, 19 Aug 1999 20:11:52 -0400 (EDT) Date: Thu, 19 Aug 1999 20:11:51 -0400 (EDT) From: Alfred Perlstein To: Cillian Sharkey Cc: hackers@FreeBSD.ORG Subject: Re: user mount f/s with kld's In-Reply-To: <37BBCA94.4519D6D5@baker.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Aug 1999, Cillian Sharkey wrote: > Hi, > > I just setup my system so that "Joe" user can mount > /dev/fd0 on a mountpoint "Joe" owns..grand no problem.. > > ..BUT it only works when the f/s code for that f/s type is > available (ie. compiled into the kernel or has been previously > loaded as a module) > > however if it's not compiled into the kernel, or already > loaded as a module, user "Joe" can't mount the disk because > the module for that f/s type won't be loaded dynamically.. > > I presume this is because root is only allowed to use > kldload.. ? Yes, otherwise it would be a giant security risk. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 17: 6:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 53EA614E1F for ; Thu, 19 Aug 1999 17:06:22 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA25555; Fri, 20 Aug 1999 09:35:32 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA61385; Fri, 20 Aug 1999 09:35:30 +0930 (CST) Date: Fri, 20 Aug 1999 09:35:30 +0930 From: Greg Lehey To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel debugging questions Message-ID: <19990820093530.G14964@freebie.lemis.com> References: <199908191934.MAA07552@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Zhihui Zhang on Thu, Aug 19, 1999 at 12:15:51PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 19 August 1999 at 12:15:51 -0400, Zhihui Zhang wrote: > > I am using FreeBSD 4.0 and have two questions on kernel debugging: > > (2) After bootup, I try the following to debug the live system (after > reading some pages of the book "Panic! Unix system crash dump analysis"): > > now4# gdb -k /kernel.debug /dev/mem > (kgdb) run > Starting program: /kernel.debug > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > You can't do that without a process to debug. > > Is there something wrong? Yes. You shouldn't try to run the kernel. > I did the same thing with the postmortem coredump files and got > similar messages. Maybe I am using gdb in a wrong way. You can't control the execution of the kernel, you can just look at the way things are. With the core dump, you at least have the advantage that things won't change while you look at them; you can't even do that with /dev/mem. The other alternative is remote serial debugging, where you *can* influence the execution of the kernel, for example by setting breakpoints. But remember that the kernel is already running when you attach to it, so you don't say 'run', you say 'c[ontinue]'. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 17:45:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 4AD7314D6E for ; Thu, 19 Aug 1999 17:45:02 -0700 (PDT) (envelope-from justin@rhapture.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id RAA66762 for ; Thu, 19 Aug 1999 17:45:03 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 19 Aug 1999 17:44:49 -0700 Received: from rhapture.apple.com (rhapture.apple.com [17.202.40.59]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id RAA25306; Thu, 19 Aug 1999 17:44:48 -0700 Received: (from justin@localhost) by rhapture.apple.com (8.9.1/8.9.1) id RAA00682; Thu, 19 Aug 1999 17:44:48 -0700 (PDT) Message-Id: <199908200044.RAA00682@rhapture.apple.com> To: wsanchez@apple.com Subject: Re: Need some advice regarding portable user IDs Cc: Bill Studenmund , "Brian C. Grayson" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com In-Reply-To: <19990817213718.A28662@marvin.ece.utexas.edu> Date: Thu, 19 Aug 1999 17:44:47 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Wilfredo Sanchez > Date: 1999-08-18 14:28:54 -0700 > To: Bill Studenmund > Subject: Re: Need some advice regarding portable user IDs > Cc: "Brian C. Grayson" > ,freebsd-hackers@FreeBSD.ORG, > tech-userlevel@netbsd.org, pwd@apple.com,warner.c@apple.com, > umeshv@apple.com > In-reply-to: <19990817213718.A28662@marvin.ece.utexas.edu> > X-Loop: FreeBSD.ORG > Delivered-to: freebsd-hackers@freebsd.org > X-Mailer: by Apple MailViewer (2.106) > X-Mailer-Extensions: SWSignature 1.3.2 > > | Fred, right now what happens in MacOS when I take a disk which has > sharing > | credentials set up, and hook it into another machine? How are the > | credentials handled there? > > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS doesn't understand identity, permissions, etc., so it can't "talk" about them; and (b) when you share a volume from a remote server, you "login" to that volume using a mechanism supported by the server. The client system isn't involved. Since you, at the keyboard, are really the only user of that system, the issue of what "another logged-in user" can do is moot. Note that although the "enhanced" HFS supports credentials (i.e, owner and group identity), Mac OS doesn't use this capability, and wouldn't know what to do with a volume that had this info filled in (i.e., can't make use of it). The whole issue of associating identity with permission is a bit perplexing. DCE attempted to solve this problem, and it got quickly out of hand. Regardless of whether you are using 32-bit integers, or 8-character login names, there's little or no guarantee that when you move a device containing this info from one site to another, the "mapping" from that identity to who you are will remain valid. In the meanwhile, there ought to be a simple version of this problem that we can solve :-}. I think I'll get down off this soap box for a bit... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 18:11:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jason.argos.org (a1-3a123.neo.rr.com [24.93.180.123]) by hub.freebsd.org (Postfix) with ESMTP id 863FE14D3B for ; Thu, 19 Aug 1999 18:11:18 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id VAA24441 for ; Thu, 19 Aug 1999 21:11:13 -0400 Date: Thu, 19 Aug 1999 21:11:13 -0400 (EDT) From: Mike Nowlin To: freebsd-hackers@freebsd.org Subject: Tru64 UNIX -- really strange problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I know this has very little to do with FreeBSD, but the tru64-hackers list is a little slow.... :) Here's the situation: DEC Alpha 3000/500S box, running Compaq Tru64 UNIX V4.0F (formerly known as the operating system Digital Unix, which is the operating system formerly known as DEC OSF/1) -- plus Intersystems ISM 6.4-F.14.... In a nutshell, one of the drives is mounted as /usr2, and there's a directory in it /usr2/lab/fla. In /home, there's a sym link pointing from "/home/b -> /usr2"... So basically, /home/b/lab/fla SHOULD be the same as /usr2/lab/fla -- file comparisons between these two directories show that they are. However -- if you cd into /usr2/lab/fla, then run the ISM application, it gives different results than if you cd into /home/b/lab/fla. (ISM is dealing with files in ".", for all intents and purposes.) Instead of digging through billions of man pages for a function that might not even be used in the program, does anybody know of any calls that (optionally) don't handle files arrived at through sym links correctly? Intersystems really doesn't have an idea -- got another conference call with them (and probably Digital) in the morning... It would be nice to have some possible solutions. Thanks... Mike (the next message will be back to 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 19 18:26:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by hub.freebsd.org (Postfix) with ESMTP id D997014E81 for ; Thu, 19 Aug 1999 18:26:41 -0700 (PDT) (envelope-from a-wada@mars.dti.ne.jp) Received: from a.mars.dti.ne.jp (PPP27.tachikawa-ap4.dti.ne.jp [202.216.255.27]) by smtp2.dti.ne.jp (8.9.3/3.7W) with SMTP id KAA23025; Fri, 20 Aug 1999 10:23:25 +0900 (JST) Message-Id: <199908200122.AA00048@a.mars.dti.ne.jp> From: Akira Wada Date: Fri, 20 Aug 1999 10:22:33 +0900 To: seiwald@perforce.com (Christopher Seiwald) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Seiwald writes: > The FreeBSD qsort implementation has a rather nasty degenerate case. > If you have data that partitions exactly about the median pivot, yet > which is unsorted in either partition, you get get treated to an insertion > sort. Example: > > 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 > > qsort picks 10 as the median, does no swaps on its first pass, and so > decides to switch to an insertion sort. The idea is that if no swaps > occur, the data is likely to be nearly already sorted and a good candidate > for insertion sort. This turns out to be a (very) bad idea if you have > some unsorted data buried in the middle of a (very) large dataset. > > The implementation claims to come from Bentley and McIlroy's paper, > "Engineering a Sort Function," and this is largely true, but the insertion > sort optimization(?) isn't in that paper. The GNU qsort.c only does an > insertion sort if it is below a certain threshhold in size, and so never > attempts such a sort on the whole dataset. (The GNU qsort does a number > of other things pooh-poohed in the Bentley paper.) > > It's a pretty straightforward change to bypass the insertion sort for > large subsets of the data. If no one has a strong love for qsort, I'll > educate myself on how to make and contribute this change. How about the code following sig. ? And the other codes and information on: http://www.mars.dti.ne.jp/~a-wada/qsortlib.html -- Akira Wada --------------------------------------------------------------------------------- /* a-wada/qsortlib/ccn/qsorts.c Mar. 30, 1999 */ /* Copyright (c) 1999 Akira Wada */ /* Quick sort compatible with "qsort (); in " */ /* efficiency by reducing the times of key comparisons and */ /* word_mode_swapping for word_aligned object */ /* prevention from the degeneration caused by peculiar input */ /* This qsort is not stable, but could avoid the bad behavior by many */ /* equal sort-keys. For stability, add a unique-key to compare-function. */ /* If the object to be sorted is an array of pointers to structs with */ /* an unsigned integer key in ascending order, set the 3'rd argument */ /* to the key position in bytes and the 4'th to NULL, then */ /* radixsort would be applied. for example : */ /* kps = 16; qsort (pv, n, kps, (ftp) 0); */ #include #include void radixspi (void *, size_t, size_t); void srandom (unsigned long); /* if not in */ unsigned long random (); /* if not in */ #define MDT 16 /* threshold for median of the 5 or the more, MDT >= 8 */ #define MDA 2 /* adjusting threshold slightly, MDT + MDA >= 4 */ #define MDM 2 /* multiplier for threshold, MDM >= 2 */ #define DGT 256 /* threshold for checking degeneration */ #define DGV 16 /* degeneration assumed if the smaller < DGL */ #define DGM 0 /* threshold for selecting no median */ #define DGS 2 /* threshold for samples distributed uniformly */ #define DGU 4 /* threshold for sampling at random */ #define DGL ((unsigned) psz / DGV) * rl #define defdgn int dgn = 0, nsp, itv #define ckdgnr(s, e) if (psz >= DGT && s + DGL > e) dgn++ #define no_med (psz > MDT && DGM < dgn && dgn <= DGS) #define symptm (psz > MDT && dgn > DGS) #define xcsmpl() do { \ if (dgn <= DGU) { /* samples distributed uniformly */\ nsp = 3; while (psz > thr) thr *= MDM, nsp += 2; \ itv = ((unsigned) psz / (nsp - 1)) * rl; k = l, n = r; \ for (thr = MDT; psz > thr; thr *= MDM) { \ i += rl, k += itv; swap (i, k); \ j -= rl, n -= itv; swap (n, j);}} \ else { /* samples at random */\ if (dgn == DGU + 1) dgn++, srandom (time (0)); \ for (thr = (unsigned) thr / MDM; psz > thr; thr *= MDM) { \ rdmsmpl (i, i, j); i += rl; \ rdmsmpl (j, i, j); j -= rl;} \ rdmsmpl (m, i, j);} \ i = l, j = r, thr = MDT;} while (0) #define rdmsmpl(x, s, e) if (x != (n = s + rl * ( \ random () % ((unsigned) (e - (s)) / rl + 1)))) swap (x, n) #define swpwrk int t, w, z = sizeof (int), alg = ((int) av | rl) & (z - 1) #define swap(i, j) do { \ w = rl; if (alg == 0) do \ w -= z, t = *((int *) (i + w)), \ *((int *) (i + w)) = *((int *) (j + w)), \ *((int *) (j + w)) = t; while (w > 0); \ else do \ --w, t = *(i + w), *(i + w) = *(j + w), *(j + w) = t; \ while (w > 0);} while (0) #define rotate(i, j, k) do { \ w = rl; if (alg == 0) do \ w -= z, t = *((int *) (i + w)), \ *((int *) (i + w)) = *((int *) (j + w)), \ *((int *) (j + w)) = *((int *) (k + w)), \ *((int *) (k + w)) = t; while (w > 0); \ else do \ --w, t = *(i + w), *(i + w) = *(j + w), \ *(j + w) = *(k + w), *(k + w) = t; while (w > 0);} while (0) #define findxc(minmax, x, s, e, m) do { \ n = x, k = s; do \ if ((*qcmp) minmax > 0) n = k; while ((k += rl) <= e); \ if (n == x) swap (m, x); else rotate (m, n, x);} while (0) #define MIN (n, k) #define MAX (k, n) #define cksrtd(l, r) if (psz > MDT) do { \ k = l; while (k < r && (*qcmp)(k, k + rl) <= 0) k += rl; \ if (k >= r) i = j; else if (k >= m) i = m;} while (0) #define stack ptrtyp s[stksz], *p = s #define stksz sizeof (size_t) * 8 * 2 #define push(x, y) *(p++) = x, *(p++) = y #define empty (s >= p) #define pop(y, x) y = *(--p), x = *(--p) #define defwrk ptrtyp k, n; defdgn; swpwrk; stack typedef int (*ftp) (const void *, const void *); typedef char * ptrtyp; void qsort (void *av, size_t rn, size_t rl, ftp qcmp) { ptrtyp l, r, m, i, j; int psz, thr, cst, c; defwrk; if (qcmp == (ftp) 0) radixspi (av, rn, rl); else /* call RADIX SORT */ if (rn > 1 && rl > 0) { l = (char *) av, r = l + (rn - 1) * rl; for ( ; ; ) { /* initialize for current partition */ m = l + ((unsigned) (psz = (r - l) / rl) / 2) * rl, i = l, j = r, thr = MDT, psz -= (MDA), cst = 1; if (!no_med) { if (symptm) xcsmpl (); for ( ; ; ) { /* bring median of samples to middle */ if ((*qcmp)(m, j) <= 0) { if (i < m && (*qcmp)(i, m) > 0) { findxc (MIN, i, j, r, m); cst = 0;}} else { if (i >= m || (*qcmp)(i, m) > 0) swap (i, j); else findxc (MAX, j, l, i, m); cst = 0;} i += rl, j -= rl; if (psz > thr) thr *= MDM; else break;}} if (cst != 0) cksrtd (l, r); if (i < j) { /* do partitioning by middle as pivot */ for (n = m; ; ) { /* gathering equal keys close to pivot */ while (i < m) { if ((c = (*qcmp)(i, m)) < 0) i += rl; else if (c > 0) break; else { while (i < (m -= rl) && (c = (*qcmp)(m, i)) == 0); if (i >= m) break; swap (i, m); if (c > 0) break; else i += rl;}} while (n < j) { if ((c = (*qcmp)(n, j)) < 0) j -= rl; else if (c > 0) break; else { while ((n += rl) < j && (c = (*qcmp)(j, n)) == 0); if (n >= j) break; swap (n, j); if (c > 0) break; else j -= rl;}} if (i >= m && n >= j) break; if (n == j) { if (m == n) { swap (i, j); j -= rl, n = m = i;} else if (i < (m -= rl)) { rotate (i, m, j); n = j -= rl;} else { swap (i, j); j -= rl; break;}} else if (i == m) { if (n == m) { swap (i, j); i += rl; m = n = j;} else if ((n += rl) < j) { rotate (j, n, i); m = i += rl;} else { swap (i, j); i += rl; break;}} else { swap (i, j); j -= rl, i += rl;}} /* select subpartition for next iteration */ if ((i -= rl) - l < r - (j += rl)) { ckdgnr (l, j); if (l >= i) l = j; else { push (j, r), r = i; continue;}} else { ckdgnr (i, r); if (j >= r) r = i; else { push (l, i), l = j; continue;}} if (l < r) continue;} /* pop up next partition from stack */ if (!empty) pop (r, l); else break;}}} #include "radixspi-ar.c" /* a-wada/qsortlib/ccn/qsorts.c end */ /*----------------------------------------------------------------------------** *source codes on : radix_ar.c (original for array of unsigned longs by Andre Reinald) http://www.cubic.org/~submissive/sourcerer/download/radix_ar.c 25-May-97 radixspi-ar.c (modified for array of pointers to structs with u_int key) http://www.mars.dti.ne.jp/~a-wada/qsortlib/ccn/radixspi-ar.c **----------------------------------------------------------------------------*/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 19: 3:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 0D8391518D for ; Thu, 19 Aug 1999 19:03:12 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id WAA01530; Thu, 19 Aug 1999 22:01:20 -0400 (EDT) Date: Thu, 19 Aug 1999 21:48:00 -0400 (EDT) From: Zhihui Zhang To: Greg Lehey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel debugging questions In-Reply-To: <19990820093530.G14964@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Greg Lehey wrote: > You can't control the execution of the kernel, you can just look at > the way things are. With the core dump, you at least have the > advantage that things won't change while you look at them; you can't > even do that with /dev/mem. The other alternative is remote serial > debugging, where you *can* influence the execution of the kernel, for > example by setting breakpoints. But remember that the kernel is > already running when you attach to it, so you don't say 'run', you say > 'c[ontinue]'. Thanks for your response. I can not think of those points myself. However, on page 7 of the book "Panic! Unix system crash dump analysis", it says that a debugger named kadb in SunOS can load the real kernel during boot and treat the latter like a great, big, user program, stepping through its execution, examining and modifying values on the fly. It seems to me that FreeBSD does not have such a debugger. Maybe ddb can do so, but it works with assembly. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 19:14:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (law2-f171.hotmail.com [216.32.181.171]) by hub.freebsd.org (Postfix) with SMTP id 0DB2D14C11 for ; Thu, 19 Aug 1999 19:14:14 -0700 (PDT) (envelope-from biao_jin@hotmail.com) Received: (qmail 23305 invoked by uid 0); 20 Aug 1999 02:12:15 -0000 Message-ID: <19990820021215.23304.qmail@hotmail.com> Received: from 202.101.1.110 by www.hotmail.com with HTTP; Thu, 19 Aug 1999 19:12:15 PDT X-Originating-IP: [202.101.1.110] From: "jin biao" To: hackers@freebsd.org Subject: location of the function(recvfrom,socket...) Date: Thu, 19 Aug 1999 19:12:15 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Sir, Could you tell me where is the code of the functions(sendto, recvfrom,socket,bind...) located at FreeBSD source tree. I will appreciate your help. Thank you, Michael Jin. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 19:49:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from poboxer.pobox.com (ferg5200-1-20.cpinternet.com [208.149.16.20]) by hub.freebsd.org (Postfix) with ESMTP id BE61A14DA0 for ; Thu, 19 Aug 1999 19:49:08 -0700 (PDT) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id VAA15629; Thu, 19 Aug 1999 21:48:59 -0500 (CDT) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 1999 21:48:59 -0500 (CDT) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: hackers@freebsd.org Subject: Re: async v. sync v. default mode on ufs X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14268.49546.349252.744818@avalon.east> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : From: "Daniel C. Sobral" : Default for FreeBSD is async [meta]data and sync data. Sync and Async : modes go full sync/async for both metadata and data... : > Just a btw, you seem to be able to set sync and async on a filesystem : > at the same time. What gives? : Beats me. Logically, then, -o sync,async means asynchronous data, synchronous metadata. Seems very clean and orthogonal to me. The way things ought to be. In practice I doubt the implementation is as described. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 20: 6:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 4549114DA0 for ; Thu, 19 Aug 1999 20:06:43 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40344>; Fri, 20 Aug 1999 12:45:07 +1000 Date: Fri, 20 Aug 1999 13:05:00 +1000 From: Peter Jeremy Subject: Re: sio doesn't do HW flow correctly?!? In-reply-to: To: hackers@FreeBSD.ORG Cc: bmcgover@cisco.com Message-Id: <99Aug20.124507est.40344@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian McGovern wrote: >However, when I start running data, I get silo overflows. At which end? What else is the box getting SILO overflows doing? PIO access to disks or network cards is good for disrupting interrupt latencies. PLIP is virtually guaranteed to disrupt anything that cares about interrupt latencies. Anything very fast on the ISA bus is also likely to clag the system (simply because the ISA bus is sooo slow). Mike Smith wrote: > interrupt >response time on your system is sufficiently poor that the time between >the interrupt trigger at either 8 or 14 (I forget) characters in the >FIFO This can be configured in the UART. The driver switches between two FIFO levels depending on speed (look at the FIFO_RX_... macros), but I'm not sure of the absolute levels. You could try reducing the trigger level (this should make the SILO overflows go away, but at the cost of more interrupts). >In order to debug this, you will need to use a logic analyser to trap >the case where the interrupt is not handled quickly enough, A slightly less invasive method, that will probably give you some clues, is to instrument the hard interrupt entry points (defined via INTR() in i386/isa/icu_vector.s or i386/isa/apic_vector.s), as well as the siointr() function. Some background: FreeBSD (should) only disable interrupts for very short periods. Due to the (lack of) speed accessing the ICUs, the SPL levels are held in software rather than in the ICU. This means that an interrupt arrives in the kernel fairly quickly after it's raised in hardware. The kernel checks the SPL mask to determine whether the interrupt can be treated immediately. If not, it sets a flag and calls the interrupt handler when the SPL level is dropped. You could add code to check the time (eg by reading the TSC) and SPL mask on interrupt and then check the time when siointr in invoked. If the time is excessive, the SPL mask will give you some idea of what was in progress. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 20:11:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from chuq.com (w130.z209220044.sjc-ca.dsl.cnc.net [209.220.44.130]) by hub.freebsd.org (Postfix) with ESMTP id 0BCC614DA0; Thu, 19 Aug 1999 20:11:15 -0700 (PDT) (envelope-from chuq@chuq.com) Received: (from chs@localhost) by chuq.com (8.8.8/8.8.8) id UAA02199; Thu, 19 Aug 1999 20:10:58 -0700 (PDT) Date: Thu, 19 Aug 1999 20:10:57 -0700 From: Chuck Silvers To: Terry Lambert Cc: wrstuden@nas.nasa.gov, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Message-ID: <19990819201057.A2185@chuq.chuq.com> References: <199908182043.NAA28863@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <199908182043.NAA28863@usr06.primenet.com>; from Terry Lambert on Wed, Aug 18, 1999 at 08:43:14PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 08:43:14PM +0000, Terry Lambert wrote: > > > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > > > > work, we don't have the coherency issues worked out so that upper layers > > > > can cache data. i.e. so that the lower fs knows it has to ask the uper > > > > layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > > > > > With UVM in NetBSD, this is (supposedly) not an issue. > > > > UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM > > system. > > I was under the impression that th "U" in "UVM" was for "Unified". > > Does NetBSD not have a unified VM and buffer cache? is th "U" in > "UVM" referring not to buffer cache unification, but to platform > unification? > > It was my understanding from John Dyson, who had to work on NetBSD > for NCI, that the new NetBSD stuff actually unified the VM and the > buffer cache. > > If this isn't the case, then, yes, you will need to lock all the way > up and down, and eat the copy overhead for the concurrency for the > intermediate vnodes. 8-(. netbsd w/UVM currently doesn't have unified caches. that feature is what I named UBC, for "unified buffer cache" (ala DEC's UBC). the U in UVM doesn't actually stand for anything. :-) > > > You could actually think of it this way, as well: only FS's that > > > contain vnodes that provide backing should implement VOP_GETPAGES > > > and VOP_PUTPAGES, and all I/O should be done through paging. > > > > Right. That's part of UBC. :-) > > Yep. Again, if NetBSD doesn't have this, it's really important > that it obtain it. 8-(. I'm workin' on it... it'll go in soon after the branch for the next release is created (ie. it won't be in the next release, but the one after that). -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 21:32:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from perforce.com (spice.perforce.com [206.14.52.195]) by hub.freebsd.org (Postfix) with ESMTP id 7680B14E9B for ; Thu, 19 Aug 1999 21:32:55 -0700 (PDT) (envelope-from seiwald@perforce.com) Received: (from seiwald@localhost) by perforce.com (8.9.3/8.9.3) id VAA11779; Thu, 19 Aug 1999 21:33:30 -0700 (PDT) (envelope-from seiwald) Date: Thu, 19 Aug 1999 21:33:30 -0700 (PDT) From: Christopher Seiwald Message-Id: <199908200433.VAA11779@perforce.com> To: a-wada@mars.dti.ne.jp Subject: Re: anybody love qsort.c? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908200122.AA00048@a.mars.dti.ne.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | How about the code following sig. ? | And the other codes and information on: | | http://www.mars.dti.ne.jp/~a-wada/qsortlib.html Unfortunately, I only use about 5% of my brain, and am incapable of convincing myself (or anyone else) of the correctness or efficiency of your qsort algorithm. In my quick attempt to educate myself, I did read your page and found it interesting. But as I'm proposing a change to a fairly sensitive piece of code, I'd like to keep the change as modest as possible. Christopher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 22:13:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id CBA6D150B1 for ; Thu, 19 Aug 1999 22:13:28 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Hgz1-0001UW-00; Thu, 19 Aug 1999 23:12:56 -0600 Message-ID: <37BCE3D8.E6FD43DA@softweyr.com> Date: Thu, 19 Aug 1999 23:12:56 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jin biao Cc: hackers@FreeBSD.ORG Subject: Re: location of the function(recvfrom,socket...) References: <19990820021215.23304.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jin biao wrote: > > Dear Sir, > > Could you tell me where is the code of the functions(sendto, > recvfrom,socket,bind...) located at FreeBSD source tree. /usr/src/sys/kern/uipc_syscalls.c. I found this with the command: find /usr/src/sys -name '*.c' | xargs grep recvfrom Now you can too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 22:19:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 3DA49150B1 for ; Thu, 19 Aug 1999 22:19:15 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Hh3D-0001wH-00; Thu, 19 Aug 1999 23:17:15 -0600 Message-ID: <37BCE4D9.8A3D65E6@softweyr.com> Date: Thu, 19 Aug 1999 23:17:13 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: justin@apple.com Cc: wsanchez@apple.com, Bill Studenmund , "Brian C. Grayson" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs References: <199908200044.RAA00682@rhapture.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin C. Walker" wrote: > > My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS > doesn't understand identity, permissions, etc., so it can't "talk" > about them; and (b) when you share a volume from a remote server, you > "login" to that volume using a mechanism supported by the server. For NFS, this is typically pcnfsd on the PC side, and a pcnfsd client on the Mac. > The client system isn't involved. Since you, at the keyboard, are > really the only user of that system, the issue of what "another > logged-in user" can do is moot. This is not true if the user is someone else 10 minutes later. > Note that although the "enhanced" HFS supports credentials (i.e, > owner and group identity), Mac OS doesn't use this capability, and > wouldn't know what to do with a volume that had this info filled in > (i.e., can't make use of it). > > The whole issue of associating identity with permission is a bit > perplexing. DCE attempted to solve this problem, and it got quickly > out of hand. Regardless of whether you are using 32-bit integers, or > 8-character login names, there's little or no guarantee that when > you move a device containing this info from one site to another, the > "mapping" from that identity to who you are will remain valid. There is no guarantee. My uid here is 1001 because mine was the first account added to each of the FreeBSD machines here. At work, it's my employee number. > In the meanwhile, there ought to be a simple version of this problem > that we can solve :-}. I think I'll get down off this soap box for > a bit... pcnfsd? Open source versions have existed for years, at least the server side. If you have the server, a client shouldn't be all that hard to do. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 22:19:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 6388A1526B for ; Thu, 19 Aug 1999 22:19:31 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Hh4M-00021t-00; Thu, 19 Aug 1999 23:18:26 -0600 Message-ID: <37BCE522.70A524F2@softweyr.com> Date: Thu, 19 Aug 1999 23:18:26 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Onstream? References: <19990817230910.A6171@netmonger.net> <199908041047.MAA80548@freebsd.dk> <199908180613.AAA16101@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <19990817230910.A6171@netmonger.net> Christopher Masto writes: > : Do they still not allow you to release the specs? How is the code > : going to become part of FreeBSD if they won't allow its release? > > I didn't sign an NDA to get my copy of the spec or the hardware... > > I also don't have time to devote to the onstream IDE project. I'm > looking for someone with the kernel skills and track record to take > over for me. I'd like to take it over, but I'm up to my ears right now. I barely have time left to get in some sailing. If they're still up for grabs in a month maybe I'll take it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 19 23:28: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iservern.teligent.se (www.teligent.se [194.17.198.46]) by hub.freebsd.org (Postfix) with ESMTP id E28FD14F66; Thu, 19 Aug 1999 23:27:51 -0700 (PDT) (envelope-from jakob@teligent.se) Received: from fwse.teligent.se (gateway.teligent.se [192.168.3.254] (may be forged)) by iservern.teligent.se (8.8.7/8.8.7) with SMTP id IAA27330; Fri, 20 Aug 1999 08:27:08 +0200 (CEST) (envelope-from jakob@teligent.se) Date: Fri, 20 Aug 1999 08:25:18 +0200 (CEST) From: Jakob Alvermark Reply-To: alvermark@teligent.se To: Gary Jennejohn Cc: mark+freebsd@xaa.mpn.cp.philips.com, freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: VMWare: porting kernel modules to FreeBSD In-Reply-To: <199908192040.WAA27646@teligent.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like help too.=20 /Jakob Alvermark On Thu, 19 Aug 1999, Gary Jennejohn wrote: > Mark Huizer writes: > >Hi there, > > > >I had a look recently at the code for one of the kernel modules that VMW= are > >requires (driver-only.tar), and it looks like something that should be > >portable to FreeBSD, although there is some messy stuff in it (assembly > >that seems to be using Linux specific stuff, brrr..) But anyway: it > >looks feasable. > > > >Is anyone already working on this, or are some people interested in > >helping with this? > > > >As far as I can see, the linux emulation is good enough to run the > >vmware program, "all" you need to do is implement /dev/vmmon and > >/dev/vmnet, given the fact that the code is written really unportable, > >so there is some rewriting to be done. Then with the KLD's > >vmmon,vmnet and linux you should be able to run vmware. > > >=20 > Soren mentioned that he might look into it a few weeks ago, but that's th= e > last thing I remember seeing. >=20 > I'm interested in helping with this, though. >=20 > --- > Gary Jennejohn > Home - garyj@muc.de > Work - garyj@fkr.dec.com >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-emulation" in the body of the message >=20 >=20 ------------------------------------------------------- Teligent AB, P.O. Box 213, S-149 23 Nyn=E4shamn, Sweden =20 Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36=20 Direct +46-(0)8 520 660 32 * GSM +46-(0)70 792 16 57 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 0:35:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 7545915239 for ; Fri, 20 Aug 1999 00:35:23 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA86828; Fri, 20 Aug 1999 00:35:01 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: gena@MCCP.com Cc: hackers@FreeBSD.ORG, jeremy@xig.com Subject: Re: Question regarding Xaccel In-reply-to: Your message of "Thu, 19 Aug 1999 11:38:58 PDT." <199908191838.LAA19182@shell3.ba.best.com> Date: Fri, 20 Aug 1999 00:35:01 -0700 Message-ID: <86825.935134501@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan > on Xinside site (www.xig.com) it says... > > FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD > core team. > > Why was that advice given... > > > -Gena > > > 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 20 1:38: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by hub.freebsd.org (Postfix) with SMTP id 17B8C152BA for ; Fri, 20 Aug 1999 01:37:59 -0700 (PDT) (envelope-from ashah@MIT.EDU) Received: from ALL-NIGHT-TOOL.MIT.EDU by MIT.EDU with SMTP id AA17524; Fri, 20 Aug 99 04:37:52 EDT Received: by all-night-tool.mit.edu (8.8.7/4.7) id EAA14725; Fri, 20 Aug 1999 04:37:54 -0400 (EDT) Message-Id: <199908200837.EAA14725@all-night-tool.mit.edu> To: gena@MCCP.com Cc: hackers@FreeBSD.org, jeremy@xig.com Subject: Re: Question regarding Xaccel In-Reply-To: Your message of "Fri, 20 Aug 1999 00:35:01 PDT." <86825.935134501@localhost> Date: Fri, 20 Aug 1999 04:37:54 EDT From: Archit P Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X server, and the reply was that 3.x will be supported by year's end in version 5.1. The only issue the reply mentioned was aout vs. elf. The replier also said that I could run the current version under 3.x using compat22. --Archit (My first post to a freebsd mailing list, if I am breaking etiquette, please let me know) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 1:55:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 9A13014FD8 for ; Fri, 20 Aug 1999 01:55:54 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id BAA97976; Fri, 20 Aug 1999 01:19:51 -0400 (EDT) Date: Fri, 20 Aug 1999 01:19:51 -0400 (EDT) From: Ben Rosengart To: jin biao Cc: hackers@FreeBSD.ORG Subject: Re: location of the function(recvfrom,socket...) In-Reply-To: <19990820021215.23304.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Aug 1999, jin biao wrote: > Could you tell me where is the code of the functions(sendto, > recvfrom,socket,bind...) located at FreeBSD source tree. narcissus% pwd /sys narcissus% find . | xargs grep -a ^sendto ./kern/uipc_syscalls.c:sendto(p, uap) narcissus% The others are there too. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 2:30:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id D5D9715488 for ; Fri, 20 Aug 1999 02:30:17 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-163.skylink.it [194.185.55.163]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id LAA02843; Fri, 20 Aug 1999 11:13:10 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id KAA08932; Fri, 20 Aug 1999 10:56:09 +0200 (CEST) Date: Fri, 20 Aug 1999 10:56:09 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: "Jordan K. Hubbard" Cc: gena@MCCP.com, hackers@FreeBSD.ORG, jeremy@xig.com Subject: Re: Question regarding Xaccel In-Reply-To: <86825.935134501@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I know of at least someone who is using XiG on 3.2-STABLE. And he says it works without a problem. Nick On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: > It was given about a year ago and is now out of date. XiG promised > to update their web site, but evidently this just hasn't happened > yet. > > - Jordan > > > on Xinside site (www.xig.com) it says... > > > > FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD > > core team. > > > > Why was that advice given... > > > > > > -Gena > > > > > > 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 > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 3: 7:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from got-mail.com (deputy.cybersource.com.sg [203.127.94.131]) by hub.freebsd.org (Postfix) with SMTP id D2ADC14BF1 for ; Fri, 20 Aug 1999 03:07:47 -0700 (PDT) (envelope-from estee@cybersource.com.sg) Received: (qmail 26984 invoked from network); 20 Aug 1999 10:02:31 -0000 Received: from coral.cybersource.com.sg.0.152.127.203.in-addr.arpa (HELO coral) (203.127.152.6) by got-mail.com with SMTP; 20 Aug 1999 10:02:31 -0000 Message-Id: <3.0.6.32.19990820180603.0093ca30@server.cybersource.com.sg> X-Sender: estee@server.cybersource.com.sg X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 20 Aug 1999 18:06:03 To: freebsd-hackers@freebsd.org From: Estee Goh Subject: How to add a new domain to a domain name server Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Warmest regards, Estee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 3:34:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 079B415334 for ; Fri, 20 Aug 1999 03:34:11 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Fri, 20 Aug 1999 11:39:12 +0100 Message-ID: <37BD2BD3.1A95EED8@baker.ie> Date: Fri, 20 Aug 1999 11:20:03 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Estee Goh Cc: freebsd-hackers@freebsd.org Subject: Re: How to add a new domain to a domain name server References: <3.0.6.32.19990820180603.0093ca30@server.cybersource.com.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My name is estee, i am new in Freebsd. Can anyone help me to solve this > problem? I want to add a new domain name in domain name server(freebsd), > how i do it? Thanks in advance, please help, this is urgent... Well no doubt the FreeBSD box is running BIND...so the configuration file for named is either /etc/namedb/named.conf for version 8.x or /etc/namedb/named.boot if you have a 4.x version take a look at the man page for named and the files in /etc/namedb for more info. The book DNS & BIND from O'Reilly is very good too. Regards, Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 6:22: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 9096F14BE5 for ; Fri, 20 Aug 1999 06:22:07 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01889; Fri, 20 Aug 1999 09:22:06 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id JAA01890; Fri, 20 Aug 1999 09:22:06 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908201322.JAA01890@bmcgover-pc.cisco.com> To: Peter Jeremy Cc: hackers@FreeBSD.ORG Date: Fri, 20 Aug 1999 09:22:06 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Brian McGovern wrote: >>However, when I start running data, I get silo overflows. > >At which end? What else is the box getting SILO overflows doing? PIO >access to disks or network cards is good for disrupting interrupt >latencies. PLIP is virtually guaranteed to disrupt anything that >cares about interrupt latencies. Anything very fast on the ISA bus is >also likely to clag the system (simply because the ISA bus is sooo >slow). > Actually, the box with the silo overflows is doing 'not much'. Things like sendmail and the other daemons are running (no net connection, tho, so I know nothing is coming in/out), but otherwise, its a login, a copy of PPP, the clock tick interrupts, and the sio interrupts and corresponding network processing. I think it reports an average of 99.9% idle (the occational "blip" on the stats). >Mike Smith wrote: >> interrupt >>response time on your system is sufficiently poor that the time between >>the interrupt trigger at either 8 or 14 (I forget) characters in the >>FIFO > >This can be configured in the UART. The driver switches between two >FIFO levels depending on speed (look at the FIFO_RX_... macros), but >I'm not sure of the absolute levels. You could try reducing the trigger >level (this should make the SILO overflows go away, but at the cost of >more interrupts). > >>In order to debug this, you will need to use a logic analyser to trap >>the case where the interrupt is not handled quickly enough, > >A slightly less invasive method, that will probably give you some >clues, is to instrument the hard interrupt entry points (defined via >INTR() in i386/isa/icu_vector.s or i386/isa/apic_vector.s), as well >as the siointr() function. > >Some background: FreeBSD (should) only disable interrupts for very >short periods. Due to the (lack of) speed accessing the ICUs, the SPL >levels are held in software rather than in the ICU. This means that >an interrupt arrives in the kernel fairly quickly after it's raised in >hardware. The kernel checks the SPL mask to determine whether the >interrupt can be treated immediately. If not, it sets a flag and calls >the interrupt handler when the SPL level is dropped. > >You could add code to check the time (eg by reading the TSC) and SPL >mask on interrupt and then check the time when siointr in invoked. >If the time is excessive, the SPL mask will give you some idea of what >was in progress. > >Peter > My short term "punt" is to use a desktop system. If I keep seeing the problem there, I'll debug it some more. If it "goes away", I'll know it was the laptop being quirky. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 6:23:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 3DD7114DFD for ; Fri, 20 Aug 1999 06:23:43 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP for hackers@freebsd.org; Fri, 20 Aug 1999 14:29:09 +0100 Message-ID: <37BD61B7.F4C2CD28@baker.ie> Date: Fri, 20 Aug 1999 15:09:59 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, change to /sys/net/if.c which will print out "xxN: promiscuous mode disabled" msg to match its equiv. "xxN: promiscuous mode enabled" msg works on all my interfaces even if tcpdump is run multiple times etc. However it does not print out the disabled msg for tun0 interface for some mysterious reason.. (another interesting thing was if tun0 == kld and I try a tcpdump, tpcdump doesn't recognise tun0 at all !) patch against 3.2-STABLE (synced few minutes ago) *** if.c Fri Aug 20 14:42:44 1999 --- if.c.bak Fri Aug 20 14:50:42 1999 *************** *** 790,797 **** if (--ifp->if_pcount > 0) return (0); ifp->if_flags &= ~IFF_PROMISC; + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", + ifp->if_name, ifp->if_unit); } ifr.ifr_flags = ifp->if_flags; error = (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); --- 790,795 ---- Beware, next suggestion is pure vapourware :P I hacked the /sys/dev/syscons/syscons.c file to display kernel messages in a different colour (bright green if you want to know), I think it would be cool if we could change this either via OPTIONS KERNMSGCOLOR=FOO in kernel conf file or via sysctl perhaps.. ..as I warned you, ultimate in vapour ware :P - Cillian as a sidenote: Anyone else out there wonder why Linux console is so crap? ie: can only scroll up on *current* console, boot messages from kernel are messy and full of ad banners, kernel messages are in boring plain-text colour.. Enough hot air from me for today.. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 6:30:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 77BDB14BFA for ; Fri, 20 Aug 1999 06:30:21 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Hojp-0006jS-00; Fri, 20 Aug 1999 15:29:45 +0200 From: Sheldon Hearn To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c In-reply-to: Your message of "Fri, 20 Aug 1999 15:09:59 +0100." <37BD61B7.F4C2CD28@baker.ie> Date: Fri, 20 Aug 1999 15:29:45 +0200 Message-ID: <25881.935155785@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: > + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", > + ifp->if_name, ifp->if_unit); You're the second person other than me to request this. :-) So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7: 8:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 5A31F1506D for ; Fri, 20 Aug 1999 07:08:31 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Fri, 20 Aug 1999 15:12:32 +0100 Message-ID: <37BD6BE2.6FE8231C@baker.ie> Date: Fri, 20 Aug 1999 15:53:22 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c References: <25881.935155785@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", > > + ifp->if_name, ifp->if_unit); > > You're the second person other than me to request this. :-) Yes, i've seen it suggested before alright.. > So are there any _objections_ to having the kernel match promiscuous > "enabled" messages with "disabled" counterparts? I don't have any objections, so developers speak up and have your say !! apart from the tun0 problem that I described in previous messages the suggested change seems to work perfectly.. - Cillian PS: any thoughts on the other vapourware idea :P ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:10:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 064B8153BC for ; Fri, 20 Aug 1999 07:08:19 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id RAA55528; Fri, 20 Aug 1999 17:03:52 +0300 (EEST) (envelope-from ru) Date: Fri, 20 Aug 1999 17:03:52 +0300 From: Ruslan Ermilov To: Sheldon Hearn Cc: Cillian Sharkey , hackers@FreeBSD.ORG Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c Message-ID: <19990820170352.B50028@relay.ucb.crimea.ua> Mail-Followup-To: Sheldon Hearn , Cillian Sharkey , hackers@FreeBSD.ORG References: <37BD61B7.F4C2CD28@baker.ie> <25881.935155785@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <25881.935155785@axl.noc.iafrica.com>; from Sheldon Hearn on Fri, Aug 20, 1999 at 03:29:45PM +0200 X-Operating-System: FreeBSD 3.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 20, 1999 at 03:29:45PM +0200, Sheldon Hearn wrote: > > > On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: > > > + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", > > + ifp->if_name, ifp->if_unit); > > You're the second person other than me to request this. :-) > The third, in fact! > So are there any _objections_ to having the kernel match promiscuous > "enabled" messages with "disabled" counterparts? > I think, the "disabled" messages output should be put under `if (verbose)'. -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:14: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 4E1BF1506D for ; Fri, 20 Aug 1999 07:13:59 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Fri, 20 Aug 1999 15:14:59 +0100 Message-ID: <37BD6C71.B12E5934@baker.ie> Date: Fri, 20 Aug 1999 15:55:45 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c References: <37BD61B7.F4C2CD28@baker.ie> <25881.935155785@axl.noc.iafrica.com> <19990820170352.B50028@relay.ucb.crimea.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think, the "disabled" messages output should be put under `if (verbose)'. Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? - Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:15:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4140D1537D for ; Fri, 20 Aug 1999 07:14:45 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11HpOU-0006xO-00; Fri, 20 Aug 1999 16:11:46 +0200 From: Sheldon Hearn To: Cillian Sharkey Cc: Ruslan Ermilov , hackers@FreeBSD.ORG Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c In-reply-to: Your message of "Fri, 20 Aug 1999 15:55:45 +0100." <37BD6C71.B12E5934@baker.ie> Date: Fri, 20 Aug 1999 16:11:46 +0200 Message-ID: <26745.935158306@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: > Maybe..there was a lot of talk on another mailing list (-current I think?) > about boot messages, level of verbosity etc. etc. so perhaps > we should wait until this has been decided.. ? This has nothing to do with the boot messages, though, surely? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:20:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 3823B1506D for ; Fri, 20 Aug 1999 07:20:43 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Fri, 20 Aug 1999 15:21:11 +0100 Message-ID: <37BD6DEC.179D7D5@baker.ie> Date: Fri, 20 Aug 1999 16:02:05 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Ruslan Ermilov , hackers@FreeBSD.ORG Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c References: <26745.935158306@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: > > > Maybe..there was a lot of talk on another mailing list (-current I think?) > > about boot messages, level of verbosity etc. etc. so perhaps > > we should wait until this has been decided.. ? > > This has nothing to do with the boot messages, though, surely? Sorry, I meant kernel messages in general (of which boot messages are a part of) Basically the discussion was suggesting different levels of verbosity for the kernel as a whole, one level would be the bare mininum (ie. errors, warnings etc.) another level might include informational and another might include debug etc.. Of course as the saying goes: "Nothing works in practice like a good theory." :P Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:29:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 6C6B014C21 for ; Fri, 20 Aug 1999 07:29:45 -0700 (PDT) (envelope-from geoff@hangdog.is.co.za) Received: from admin.is.co.za (admin.is.co.za [196.23.0.9]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id QAA04577; Fri, 20 Aug 1999 16:27:46 +0200 Received: from hangdog.is.co.za (hangdog.is.co.za [196.23.0.108]) by admin.is.co.za (8.8.6/8.7.3/ISsubsidiary#1) with ESMTP id QAA24303; Fri, 20 Aug 1999 16:27:45 +0200 (GMT) Received: (from geoff@localhost) by hangdog.is.co.za (8.9.3/8.9.2) id QAA02524; Fri, 20 Aug 1999 16:27:44 +0200 (SAST) (envelope-from geoff) From: Geoff Rehmet Message-Id: <199908201427.QAA02524@hangdog.is.co.za> Subject: On TCP sequence numbers To: hackers@freebsd.org Date: Fri, 20 Aug 1999 16:27:44 +0200 (SAST) Cc: markm@iafrica.com Reply-To: "Geoff Rehmet" X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A topic that Mark and I have been discussing a little, is the algorithms that FreeBSD uses for generating initial TCP sequence numbers - that being with reference to the predictability of these numbers. (Work on this has been somewhere in Mark's todo list for a while.) This topic raises a few questions: How good, or how bad are the initial sequence numbers that FreeBSD uses? (It seems that we could improve them a little.) How unpredictable do we need to make the sequence numbers? Some testing with nmap shows that Linux is generating sequence numbers that are far more unpredictable than ours are. (Linux is, however, also using a 1MHz clock, as opposed to the 250kHz clock as outlined in the RFC.) We are only using a PRNG, as opposed to the entropy pool supplied by devrandom to generate sequence numbers (warning here - devrandom is only supported in the i386 port of FreeBSD). My testing indicates that we can improve the entropy input into our sequence numbers by using devrandom. However, this is VERY dependent on the entropy sources that you feed into the pool via rndcontrol(8). Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Ideally, I would like to do some improvements to our sequence number generation. Thoughts? Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geoffr@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 7:37:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id AEF2614BE5 for ; Fri, 20 Aug 1999 07:37:24 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Fri, 20 Aug 1999 15:42:24 +0100 Message-ID: <37BD72E3.1A2C2691@baker.ie> Date: Fri, 20 Aug 1999 16:23:16 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Geoff Rehmet Cc: hackers@freebsd.org, markm@iafrica.com Subject: Re: On TCP sequence numbers References: <199908201427.QAA02524@hangdog.is.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Another question that comes in to this is - how good a tool is nmap > for evaluating the predictability of the sequence numbers we generate? > > Ideally, I would like to do some improvements to our sequence number > generation. > > Thoughts? What is OpenBSD like in this regard ? AFAIR it has various algorithms for randomizing sequence numbers I think.. [Correct me if I'm wrong !] - Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 8:36:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 10B131534B for ; Fri, 20 Aug 1999 08:36:54 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id IAA24674; Fri, 20 Aug 1999 08:35:45 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Fri, 20 Aug 1999 08:35:45 -0700 Date: Fri, 20 Aug 1999 08:35:45 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Nick Hibma Cc: "Jordan K. Hubbard" , gena@MCCP.com, hackers@FreeBSD.ORG, jeremy@xig.com Subject: Re: Question regarding Xaccel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: hibma@skylink.it,jkh@zippy.cdrom.com,gena@MCCP.com,hackers@FreeBSD.ORG,jeremy@xig.com X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It is just as well that I did not know that - I am running it on 3.2, and have run it on all the 3.0-series. A word to the wise, if you want to run it on 3.2 install from the 3.1 CD and then upgrade by source. When I installed straight from the 3.2 cd it did not work because I needed to install compat22, and then when I did install compat22 Xsetup kept on crashing on a floating point exception. I did not have the time or inclination to find out if it was a bug in compat22. -Kip On Fri, 20 Aug 1999, Nick Hibma wrote: > Well, I know of at least someone who is using XiG on 3.2-STABLE. And he > says it works without a problem. > > Nick > > > On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: > > > It was given about a year ago and is now out of date. XiG promised > > to update their web site, but evidently this just hasn't happened > > yet. > > > > - Jordan > > > > > on Xinside site (www.xig.com) it says... > > > > > > FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD > > > core team. > > > > > > Why was that advice given... > > > > > > > > > -Gena > > > > > > > > > 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 > > > > > > -- > e-Mail: hibma@skylink.it > > > > 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 20 9: 2:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id D83281534F for ; Fri, 20 Aug 1999 09:02:39 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id RAA12419; Fri, 20 Aug 1999 17:56:23 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id QAA29141; Fri, 20 Aug 1999 16:40:48 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908201440.QAA29141@yedi.iaf.nl> Subject: Re: How to add a new domain to a domain name server In-Reply-To: <3.0.6.32.19990820180603.0093ca30@server.cybersource.com.sg> from Estee Goh at "Aug 20, 1999 6: 6: 3 pm" To: estee@cybersource.com.sg (Estee Goh) Date: Fri, 20 Aug 1999 16:40:48 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Estee Goh wrote ... > Hi, > > > My name is estee, i am new in Freebsd. Can anyone help me to solve this > problem? I want to add a new domain name in domain name server(freebsd), > how i do it? Thanks in advance, please help, this is urgent... Suggest you buy the book "DNS & BIND" by Albitz & Liu. Published by O'Reilly. This explains not only your question but the background of DNS as well. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://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 Fri Aug 20 10:16:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id AEE0C1523D; Fri, 20 Aug 1999 10:16:30 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id NAA28805; Fri, 20 Aug 1999 13:18:08 -0400 From: Bill Paul Message-Id: <199908201718.NAA28805@skynet.ctr.columbia.edu> Subject: Call for testers, new driver, blah blah blah... To: hackers@freebsd.org, hardware@freebsd.org Date: Fri, 20 Aug 1999 13:18:06 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3095 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a call for testers for a new device driver for yet another PCI fast ethernet controller: the Sundance Technologies ST201. This chipset is currently being used on the D-Link DFE-550TX. The chip on the D-Link is labeled DL10050, but it's actually an ST201. I don't know what other cards use this chip; D-Link contacted me about writing a driver and sent me two sample cards, and do far theirs is the only one that I know of. The driver is set up to recognize the stock Sundance PCI vendor/device ID as well as D-Link's. The Sundance ST201 is a clone of (wait for it) the 3Com 3c90x Etherlink XL series. No, really. Honest and for true. It uses the same DMA descriptor format and operation is very similar to the 3Com cards, although the actual register layout is different. The ST201 also has only a 64-bit multicast hash filtering table where the 3Com cards have a 256-bit table. Also, the ST201 supports only an MII transceiver interface and has no built in BNC/10baseT/AUI ports like the 3Coms. One thing that is a lot like the 3Coms is the fact that packet fragment buffers can be aligned on any byte boundaries, which means that there's no copying required to assure proper payload alignment on the alpha. Performance seems good so far though I haven't really torture tested it yet. Currently, there are drivers for 3.2+ and 4.0 available. You can download them from: http://www.freebsd.org/~wpaul/Sundance/3.0 http://www.freebsd.org/~wpaul/Sundance/4.0 Both versions support FreeBSD/i386 and FreeBSD/alpha and the 4.0 version uses newbus and can be compiled as a loadable module. There's no README yet, so here are some quick instructions: - Download the version of if_ste.c and if_stereg.h for your FreeBSD installation. - Copy if_ste.c and if_stereg.h to /sys/pci - Edit /sys/conf/files and add a line that says: pci/if_ste.c optional ste0 device-driver NOTE: for FreeBSD 4.0, leave out the "device-driver" part. It's no longer needed. - Edit your kernel config file, e.g. /sys/i386/conf/GENERIC and add a line that says: device ste0 - Config and compile a new kernel and boot it. Note that I chose the name "ste" so as not to get it confused with the SCSI tape device "st". I realize we use sa instead of st now, but I'll probably create a driver version for 2.2.x soon, and st is still used there. As usual, report problems or send large bags of cash to wpaul@skynet.ctr.columbia.edu. I plan to merge this driver into the -current branch just as soon as I can whip up a man page for it. Share and enjoy! -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 11:13:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.cioe.com (ns1.cioe.com [204.120.165.37]) by hub.freebsd.org (Postfix) with ESMTP id 4607C15300 for ; Fri, 20 Aug 1999 11:13:15 -0700 (PDT) (envelope-from steve@ns1.cioe.com) Received: (from steve@localhost) by ns1.cioe.com (8.9.3/8.9.3) id NAA66892 for freebsd-hackers@freebsd.org; Fri, 20 Aug 1999 13:13:06 -0500 (EST) (envelope-from steve) Date: Fri, 20 Aug 1999 13:13:06 -0500 (EST) From: Steve Ames Message-Id: <199908201813.NAA66892@ns1.cioe.com> To: freebsd-hackers@freebsd.org Subject: Async NFS exports? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? -Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 11:39:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 2C4CA14C9F for ; Fri, 20 Aug 1999 11:38:59 -0700 (PDT) (envelope-from thomma@BayNetworks.COM) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id LAA29232; Fri, 20 Aug 1999 11:32:47 -0700 (PDT) Received: from fedex.engwest.baynetworks.com (fedex.engwest.baynetworks.com [134.177.110.46]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with SMTP id LAA28206; Fri, 20 Aug 1999 11:32:13 -0700 (PDT) Received: from carrera.engwest (carrera.engwest.baynetworks.com) by fedex.engwest.baynetworks.com (4.1/SMI-4.1) Received: from localhost by carrera.engwest (SMI-8.6/SMI-SVR4) id LAA03503; Fri, 20 Aug 1999 11:29:51 -0700 To: ashah@MIT.EDU Cc: gena@MCCP.com, hackers@FreeBSD.ORG, jeremy@xig.com Subject: Re: Question regarding Xaccel In-Reply-To: Your message of "Fri, 20 Aug 1999 04:37:54 EDT" <199908200837.EAA14725@all-night-tool.mit.edu> References: <199908200837.EAA14725@all-night-tool.mit.edu> X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990820112950O.thomma@baynetworks.com> Date: Fri, 20 Aug 1999 11:29:50 -0700 From: Tamiji Homma X-Dispatcher: imput version 971024 Lines: 11 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X > server, and the reply was that 3.x will be supported by year's end in > version 5.1. The only issue the reply mentioned was aout vs. elf. The > replier also said that I could run the current version under 3.x using > compat22. I am one of satisfied Xaccel DS 5.0.2 users running under -current. Voodoo3 works great! Tammy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 11:39:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bsd.mbp.ee (bsd.mbp.ee [194.204.12.74]) by hub.freebsd.org (Postfix) with ESMTP id 2B4231524E; Fri, 20 Aug 1999 11:39:43 -0700 (PDT) (envelope-from mauri@aripaev.ee) Received: from lant.mbp.ee (lant.mbp.ee [194.204.12.41]) by bsd.mbp.ee (8.9.3/8.9.3) with ESMTP id VAA92772; Fri, 20 Aug 1999 21:38:14 +0300 (EEST) (envelope-from mauri@aripaev.ee) Received: by lant.mbp.ee with Internet Mail Service (5.5.2232.9) id ; Fri, 20 Aug 1999 21:37:41 +0300 Message-ID: <554419C71610D211B3F808003636280213B120@lant.mbp.ee> From: Lauri Laupmaa To: "'stable@freebsd.org'" , "'hackers@freebsd.org'" Subject: setting up -STABLE for hack contest Date: Fri, 20 Aug 1999 21:37:40 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-4" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi As the subject says i'm waiting for suggestions how to make a stable box very secure :) I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. TIA _____ Lauri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 11:45:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 3CB9815258; Fri, 20 Aug 1999 11:45:31 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id UAA40242; Fri, 20 Aug 1999 20:44:16 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199908201844.UAA40242@freebsd.dk> Subject: Re: VMWare: porting kernel modules to FreeBSD In-Reply-To: <199908192040.WAA27646@peedub.muc.de> from Gary Jennejohn at "Aug 19, 1999 10:40:23 pm" To: garyj@muc.de Date: Fri, 20 Aug 1999 20:44:16 +0200 (CEST) Cc: mark+freebsd@xaa.mpn.cp.philips.com, freebsd-emulation@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Gary Jennejohn wrote: > Mark Huizer writes: > >Hi there, > > > >I had a look recently at the code for one of the kernel modules that VMWare > >requires (driver-only.tar), and it looks like something that should be > >portable to FreeBSD, although there is some messy stuff in it (assembly > >that seems to be using Linux specific stuff, brrr..) But anyway: it > >looks feasable. > > > >Is anyone already working on this, or are some people interested in > >helping with this? > > > >As far as I can see, the linux emulation is good enough to run the > >vmware program, "all" you need to do is implement /dev/vmmon and > >/dev/vmnet, given the fact that the code is written really unportable, > >so there is some rewriting to be done. Then with the KLD's > >vmmon,vmnet and linux you should be able to run vmware. > > > > Soren mentioned that he might look into it a few weeks ago, but that's the > last thing I remember seeing. Yup, I have the files here, and have given it a quick look, doesn't look to difficult to do, but I havn't had time yet to get into the matter.. It will probably be awhile before I do have the time though, but if nobody else does it I'll get to it sooner or later... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 11:47:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.ham.muohio.edu (dragon.ham.muohio.edu [134.53.141.33]) by hub.freebsd.org (Postfix) with ESMTP id A452615258; Fri, 20 Aug 1999 11:47:19 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from localhost (howardjp@localhost) by dragon.ham.muohio.edu (8.9.3/8.9.3) with ESMTP id OAA09798; Fri, 20 Aug 1999 14:07:10 -0400 X-Authentication-Warning: dragon.ham.muohio.edu: howardjp owned process doing -bs Date: Fri, 20 Aug 1999 14:07:10 -0400 (EDT) From: Jamie Howard X-Sender: howardjp@dragon.ham.muohio.edu To: Lauri Laupmaa Cc: "'stable@freebsd.org'" , "'hackers@freebsd.org'" Subject: Re: setting up -STABLE for hack contest In-Reply-To: <554419C71610D211B3F808003636280213B120@lant.mbp.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Lauri Laupmaa wrote: > I would like to know how to change login screen and make it difficult to > guess what operating system is running, etc. Change the "default" entry in /etc/gettytab. On a 3.2-STABLEsustem (from the 19990812 snapshot), the default line looks like: default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: You can change it to something like this for fun: default:\ :cb:ce:ck:lc:fd#1000:im=\r\nOpenVMS\r\n\r\n:sp#1200: It is also trivial to hack login(1) to say "Username:" to instead of "login:". As you might have guessed, I did this to a FreeBSD 3.0 system about nine months ago. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 12: 8:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from finland.ispro.net.tr (finland.ispro.net.tr [195.174.18.1]) by hub.freebsd.org (Postfix) with ESMTP id EB015153C1 for ; Fri, 20 Aug 1999 12:08:09 -0700 (PDT) (envelope-from yurtesen@ispro.net.tr) Received: from ispro.net.tr (dyn-0-095.tku.netti.fi [195.16.223.96]) by finland.ispro.net.tr (8.9.3/8.9.3) with ESMTP id WAA83252; Fri, 20 Aug 1999 22:06:29 +0300 (EEST) (envelope-from yurtesen@ispro.net.tr) Message-ID: <37BDA6E7.1B8F3BFB@ispro.net.tr> Date: Fri, 20 Aug 1999 22:05:11 +0300 From: Evren Yurtesen X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Lauri Laupmaa Cc: hackers@freebsd.org Subject: Re: setting up -STABLE for hack contest References: <554419C71610D211B3F808003636280213B120@lant.mbp.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG it is possible to detect operating systems from their behaviours of replying to packets. see the program queso from ports/packages. but anyway you can change the login prompt from /etc/gettytab file Evren Yurtesen yurtesen@ispro.net.tr Lauri Laupmaa wrote: > > Hi > > As the subject says i'm waiting for suggestions how to make a stable box > very secure :) > > I would like to know how to change login screen and make it difficult to > guess what operating system is running, etc. > > TIA > _____ > Lauri > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" 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 20 12:11:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 078A414CA1 for ; Fri, 20 Aug 1999 12:11:22 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 11342 invoked from network); 20 Aug 1999 18:11:01 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 20 Aug 1999 18:11:01 -0000 Date: Fri, 20 Aug 1999 11:09:36 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Anybody cobbled together a getpwent() that uses libradius? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 12:14:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id D6D8D14CA1; Fri, 20 Aug 1999 12:14:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C93CA1CD8B6; Fri, 20 Aug 1999 12:14:54 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Fri, 20 Aug 1999 12:14:54 -0700 (PDT) From: Kris Kennaway To: Jaye Mathisen Cc: hackers@freebsd.org Subject: Re: Anybody cobbled together a getpwent() that uses libradius? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Jaye Mathisen wrote: > While whatever happens with PAM and LDAP, and all those great things, I > would like to validate passwords via Radius... > > It would be most convenient if it was just in getpwent()... This is the wrong place to put it - see the pam_radius module. Bloating libc with promiscuous knowledge of authentication services helps no-one. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 12:27:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 144A814CA1 for ; Fri, 20 Aug 1999 12:27:23 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id PAA17035 for ; Fri, 20 Aug 1999 15:26:08 -0400 (EDT) Date: Fri, 20 Aug 1999 15:12:48 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: Serial cable Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Rich: Can you find a serial cable for me? I need to connect two PCs together via RS232 ports. Thanks. -------------------------------------------------- Zhihui Zhang. Please visit http://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 Fri Aug 20 12:56:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 8D3BA14ED0 for ; Fri, 20 Aug 1999 12:56:10 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 4570 invoked from network); 20 Aug 1999 19:29:17 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 20 Aug 1999 19:29:17 -0000 Date: Fri, 20 Aug 1999 12:27:51 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: Kris Kennaway Cc: hackers@FreeBSD.ORG Subject: Re: Anybody cobbled together a getpwent() that uses libradius? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I completely missed that radius was working with pam. A check of radius related stuff in the man pages didn't show anything related to PAM, and the pam.conf page doesn't show anything related to radius. Should've checked the libs though. Thanks. On Fri, 20 Aug 1999, Kris Kennaway wrote: > On Fri, 20 Aug 1999, Jaye Mathisen wrote: > > > While whatever happens with PAM and LDAP, and all those great things, I > > would like to validate passwords via Radius... > > > > It would be most convenient if it was just in getpwent()... > > This is the wrong place to put it - see the pam_radius module. Bloating > libc with promiscuous knowledge of authentication services helps no-one. > > Kris > > > > 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 20 13: 6: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id CC79F14C12 for ; Fri, 20 Aug 1999 13:05:59 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 8CBDD1912; Fri, 20 Aug 1999 22:03:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 89F98499A; Fri, 20 Aug 1999 22:03:47 +0200 (CEST) Date: Fri, 20 Aug 1999 22:03:45 +0200 (CEST) From: Andrzej Bialecki To: Jaye Mathisen Cc: hackers@freebsd.org Subject: Re: Anybody cobbled together a getpwent() that uses libradius? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Jaye Mathisen wrote: > > While whatever happens with PAM and LDAP, and all those great things, I > would like to validate passwords via Radius... > > It would be most convenient if it was just in getpwent()... I beg to differ. It's extremely easy to use pam_radius module. No changes in sources - just edit /etc/pam.conf. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 13: 6:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id D7EB614CB8 for ; Fri, 20 Aug 1999 13:06:23 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 861581913; Fri, 20 Aug 1999 22:05:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 85472499A; Fri, 20 Aug 1999 22:05:08 +0200 (CEST) Date: Fri, 20 Aug 1999 22:05:08 +0200 (CEST) From: Andrzej Bialecki To: Jaye Mathisen Cc: Kris Kennaway , hackers@FreeBSD.ORG Subject: Re: Anybody cobbled together a getpwent() that uses libradius? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Jaye Mathisen wrote: > > I completely missed that radius was working with pam. A check of radius > related stuff in the man pages didn't show anything related to PAM, and ...they are on their way - check RELENG_3, i.e. STABLE. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 13: 8: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 21B1114ED0 for ; Fri, 20 Aug 1999 13:08:02 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id PAA21352; Fri, 20 Aug 1999 15:07:44 -0500 (CDT) Date: Fri, 20 Aug 1999 15:07:44 -0500 From: "Matthew D. Fuller" To: Steve Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? Message-ID: <19990820150744.G2131@futuresouth.com> References: <199908201813.NAA66892@ns1.cioe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199908201813.NAA66892@ns1.cioe.com>; from Steve Ames on Fri, Aug 20, 1999 at 01:13:06PM -0500 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Caveat: I'm making this up as I go along ] On Fri, Aug 20, 1999 at 01:13:06PM -0500, a little birdie told me that Steve Ames remarked > > I asked this on stable but didn't get a response... Would I get any > performance increases by mounting NFS exported partition as Async? > > Would my soul be tormented in purgatory for doing it? > > Just to be clear... I am wondering if mounting (on the NFS _server_) a > partition (that is exportable) as async will have any performance > benefits to the NFS clients? As a first guess, probably not unless you have a large number of active clients. Any modern hard disc will outperform ethernet/fast ethernet, especially for larger read/writes. For large numbers of smaller operations, or when there is a large number of simultaneous outstanding requests from clients, maybe. I'd say watch the disc itself (iostat is your friend), and if it's pegged (especially large numbers of tps) async might buy you some increase. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 13:16:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 2D95015836 for ; Fri, 20 Aug 1999 13:16:36 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from lal.cs.utah.edu (lal.cs.utah.edu [155.99.195.65]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id OAA06878; Fri, 20 Aug 1999 14:16:34 -0600 (MDT) From: David G Andersen Received: (from danderse@localhost) by lal.cs.utah.edu (8.8.8/8.8.8) id OAA08805; Fri, 20 Aug 1999 14:16:34 -0600 (MDT) Message-Id: <199908202016.OAA08805@lal.cs.utah.edu> Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c To: cillian@baker.ie (Cillian Sharkey) Date: Fri, 20 Aug 1999 14:16:33 -0600 (MDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <37BD61B7.F4C2CD28@baker.ie> from "Cillian Sharkey" at Aug 20, 99 03:09:59 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For the record, I'd love to see this made official, and under normal (not just verbose) logging. -Dave Lo and behold, Cillian Sharkey once said: > > Hi, > > change to /sys/net/if.c which will print out > "xxN: promiscuous mode disabled" msg to match its > equiv. "xxN: promiscuous mode enabled" msg > works on all my interfaces even if tcpdump is run > multiple times etc. However it does not print out > the disabled msg for tun0 interface for some mysterious > reason.. > > (another interesting thing was if tun0 == kld and I > try a tcpdump, tpcdump doesn't recognise tun0 at all !) > > patch against 3.2-STABLE (synced few minutes ago) > > *** if.c Fri Aug 20 14:42:44 1999 > --- if.c.bak Fri Aug 20 14:50:42 1999 > *************** > *** 790,797 **** > if (--ifp->if_pcount > 0) > return (0); > ifp->if_flags &= ~IFF_PROMISC; > + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", > + ifp->if_name, ifp->if_unit); > } > ifr.ifr_flags = ifp->if_flags; > error = (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); > --- 790,795 ---- > > > Beware, next suggestion is pure vapourware :P > > I hacked the /sys/dev/syscons/syscons.c file to > display kernel messages in a different colour > (bright green if you want to know), I think > it would be cool if we could change this > either via OPTIONS KERNMSGCOLOR=FOO in kernel > conf file or via sysctl perhaps.. > > ..as I warned you, ultimate in vapour ware :P > > - Cillian > > > as a sidenote: > Anyone else out there wonder why Linux console > is so crap? ie: can only scroll up on *current* > console, boot messages from kernel are messy > and full of ad banners, kernel messages > are in boring plain-text colour.. > > Enough hot air from me for today.. :) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah CS Department http://www.angio.net/ "If you haul a geek up a crack, you will bloody their fingers for a day... If you teach a geek to climb, you will bloody their fingers for life." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 13:29:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1424A14E4A for ; Fri, 20 Aug 1999 13:27:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64923; Fri, 20 Aug 1999 13:27:02 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 13:27:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199908202027.NAA64923@apollo.backplane.com> To: Steve Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve w/NFSv3 I doubt mounting the exported partitions async will increase performance much. I would not use an async mount - if this is an NFS server it needs to be as reliable as possible and async mounting the partition is going to hurt if the machine crashes. -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 Fri Aug 20 13:33:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5567E14BF3 for ; Fri, 20 Aug 1999 13:33:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64957; Fri, 20 Aug 1999 13:32:17 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 13:32:17 -0700 (PDT) From: Matthew Dillon Message-Id: <199908202032.NAA64957@apollo.backplane.com> To: "Matthew D. Fuller" Cc: Steve Ames , freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> <19990820150744.G2131@futuresouth.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Just to be clear... I am wondering if mounting (on the NFS _server_) a :> partition (that is exportable) as async will have any performance :> benefits to the NFS clients? : :As a first guess, probably not unless you have a large number of active :clients. Any modern hard disc will outperform ethernet/fast ethernet, :especially for larger read/writes. For large numbers of smaller :operations, or when there is a large number of simultaneous outstanding :requests from clients, maybe. I'd say watch the disc itself (iostat is :your friend), and if it's pegged (especially large numbers of tps) async :might buy you some increase. :-- :Matthew Fuller (MF4839) | fullermd@over-yonder.net Not much if at all, whether you have a large number of clients or not, at least if you are using NFSv3 mounts. The reason is due to the way NFSv3 issues writes. NFSv3 issues a write but no longer assumes that the write has been synced to the server's disk as of when the reply comes back. Instead it keeps the buffer around and does a later commit rpc to do the sync, presumably long after the server has already synced the data. So, effectively, all NFSv3 writes are async insofar as the client's buffer cache is able to keep abrest of the write-rate. Hmm, interesting. I see another optimization I can do to fix the buffer cache saturation case in CURRENT on the client. The COMMIT rpc's aren't being issued async. -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 Fri Aug 20 14:23:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by hub.freebsd.org (Postfix) with ESMTP id C27AB15B0F; Fri, 20 Aug 1999 14:22:29 -0700 (PDT) (envelope-from atrens@nortelnetworks.com) Received: from zcars01t by smtprch1.nortel.com; Fri, 20 Aug 1999 16:13:09 -0500 Received: from hcarp00g.ca.nortel.com by zcars01t; Fri, 20 Aug 1999 17:20:32 -0400 Received: from hcarp00g.ca.nortel.com (hcarp00g.ca.nortel.com [47.196.31.114]) by hcarp00g.ca.nortel.com (8.9.3/8.7.3) with ESMTP id RAA01424; Fri, 20 Aug 1999 17:22:29 -0400 (EDT) Date: Fri, 20 Aug 1999 17:22:29 -0400 (EDT) From: "Andrew Atrens" Reply-To: "Andrew Atrens" To: Poul-Henning Kamp Cc: current@freebsd.org, hackers@freebsd.org Subject: help! - strange vn behaviour In-Reply-To: <6117.935182962@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll cc: hackers and see if this rings a bell for anyone :| .. Andrew > >Btw, can you explain why this happens? > > > > > >$ partitionsize=256 > > > >$ sects=`/bin/expr $partitionsize '*' 64 '-' 1` > > > >$ vnconfig -e -s labels -S $partitionsize"m" /dev/vn0 > > > >$ disklabel -w -r vn0 auto > >disklabel: /dev/rvn0c: Device not configured > > > >$ disklabel vn0 > >disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device > > > >$ disklabel /dev/vn0 > ># /dev/vn0: > >type: unknown > >disk: amnesiac > >label: fictitious > >flags: > >bytes/sector: 4096 > >sectors/track: 32 > >tracks/cylinder: 8 > >sectors/cylinder: 256 > >cylinders: 256 > >sectors/unit: 65536 > >rpm: 3600 > >interleave: 1 > >trackskew: 0 > >cylinderskew: 0 > >headswitch: 0 # milliseconds > >track-to-track seek: 0 # milliseconds > >drivedata: 0 > >8 partitions: > ># size offset fstype [fsize bsize bps/cpg] > > c: 65536 0 unused 0 0 # (Cyl. 0-255) > >- > > Now, if I do a - $ vnconfig -u /dev/vn0c && echo "woohoo!" vnconfig: VNIOCDETACH: Device not configured $ vnconfig -u /dev/vn0 && echo "woohoo!" woohoo! > >... > > > > > >The vn device _is_ configured but not useable via /dev/vn0[abc..z] > > > >?????? > > > >Andrew. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 14:50:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caxton.correionet.com.br (caxton.correionet.com.br [200.246.35.7]) by hub.freebsd.org (Postfix) with ESMTP id 7BF8914D37 for ; Fri, 20 Aug 1999 14:50:15 -0700 (PDT) (envelope-from morte@correionet.com.br) Received: from caxton.correionet.com.br (caxton.correionet.com.br [200.246.35.7]) by caxton.correionet.com.br (8.9.3/8.9.3) with ESMTP id SAA01881 for ; Fri, 20 Aug 1999 18:12:46 -0300 (EST) Date: Fri, 20 Aug 1999 18:12:46 -0300 (EST) From: Luiz Morte da Costa Junior To: freebsd-hackers@freebsd.org Subject: L440GX+ Server Board Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-712198510-935183566=:86770" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk 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-712198510-935183566=:86770 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays "ok" again. I recompiled the kernel with "maxusers 128", but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de Redes E-mail: morte@correionet.com.br Telefone: +55 19 754-2532 Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil --0-712198510-935183566=:86770 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTE5OTkgRnJlZUJTRCBJbmMuDQpDb3B5cmln aHQgKGMpIDE5ODIsIDE5ODYsIDE5ODksIDE5OTEsIDE5OTMNCglUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCAzLjItUkVMRUFTRSAjMTogV2VkIEF1 ZyAxOCAxNzo0Mjo1MCBFU1QgMTk5OQ0KICAgIHJvb3RAY2F4dG9uLmNvcnJl aW9uZXQuY29tLmJyOi91c3Ivc3JjL3N5cy9jb21waWxlL0RVQUwNClRpbWVj b3VudGVyICJpODI1NCIgIGZyZXF1ZW5jeSAxMTkzMTgyIEh6DQpDUFU6IFBl bnRpdW0gSUlJICg2ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWlu ZUludGVsIiAgSWQgPSAweDY3MiAgU3RlcHBpbmc9Mg0KICBGZWF0dXJlcz0w eDM4N2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxB UElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsPGIxOD4sTU1Y LDxiMjQ+LDxiMjU+Pg0KcmVhbCBtZW1vcnkgID0gNTM2ODcwOTEyICg1MjQy ODhLIGJ5dGVzKQ0KY29uZmlnPiBkaSB6cDANCmNvbmZpZz4gZGkgemUwDQpj b25maWc+IGRpIGxuYzANCmNvbmZpZz4gZGkgbGUwDQpjb25maWc+IGRpIGll MA0KY29uZmlnPiBkaSBmZTANCmNvbmZpZz4gZGkgZXgwDQpjb25maWc+IGRp IGVwMA0KY29uZmlnPiBkaSBlZDANCmNvbmZpZz4gZGkgY3MwDQpjb25maWc+ IGRpIHNjZDANCmNvbmZpZz4gZGkgbWNkMA0KY29uZmlnPiBxDQphdmFpbCBt ZW1vcnkgPSA1MTkxODg0ODAgKDUwNzAyMEsgYnl0ZXMpDQpQcm9ncmFtbWlu ZyAyNCBwaW5zIGluIElPQVBJQyAjMA0KRnJlZUJTRC9TTVA6IE11bHRpcHJv Y2Vzc29yIG1vdGhlcmJvYXJkDQogY3B1MCAoQlNQKTogYXBpYyBpZDogIDEs IHZlcnNpb246IDB4MDAwNDAwMTEsIGF0IDB4ZmVlMDAwMDANCiBjcHUxIChB UCk6ICBhcGljIGlkOiAgMCwgdmVyc2lvbjogMHgwMDA0MDAxMSwgYXQgMHhm ZWUwMDAwMA0KIGlvMCAoQVBJQyk6IGFwaWMgaWQ6ICAyLCB2ZXJzaW9uOiAw eDAwMTcwMDExLCBhdCAweGZlYzAwMDAwDQpQcmVsb2FkZWQgZWxmIGtlcm5l bCAia2VybmVsIiBhdCAweGMwMzY2MDAwLg0KUHJlbG9hZGVkIHVzZXJjb25m aWdfc2NyaXB0ICIvYm9vdC9rZXJuZWwuY29uZiIgYXQgMHhjMDM2NjA5Yy4N ClByb2JpbmcgZm9yIGRldmljZXMgb24gUENJIGJ1cyAwOg0KY2hpcDA6IDxJ bnRlbCA4MjQ0M0dYIGhvc3QgdG8gUENJIGJyaWRnZT4gcmV2IDB4MDAgb24g cGNpMC4wLjANCmNoaXAxOiA8SW50ZWwgODI0NDNHWCBob3N0IHRvIEFHUCBi cmlkZ2U+IHJldiAweDAwIG9uIHBjaTAuMS4wDQphaGMwOiA8QWRhcHRlYyBh aWM3ODk2Lzk3IFVsdHJhMiBTQ1NJIGFkYXB0ZXI+IHJldiAweDAwIGludCBh IGlycSAxOSBvbiBwY2kwLjEyLjANCmFoYzA6IGFpYzc4OTYvOTcgV2lkZSBD aGFubmVsIEEsIFNDU0kgSWQ9NywgMTYvMjU1IFNDQnMNCmFoYzE6IDxBZGFw dGVjIGFpYzc4OTYvOTcgVWx0cmEyIFNDU0kgYWRhcHRlcj4gcmV2IDB4MDAg aW50IGEgaXJxIDE5IG9uIHBjaTAuMTIuMQ0KYWhjMTogYWljNzg5Ni85NyBX aWRlIENoYW5uZWwgQiwgU0NTSSBJZD03LCAxNi8yNTUgU0NCcw0KZnhwMDog PEludGVsIEV0aGVyRXhwcmVzcyBQcm8gMTAvMTAwQiBFdGhlcm5ldD4gcmV2 IDB4MDggaW50IGEgaXJxIDIxIG9uIHBjaTAuMTQuMA0KZnhwMDogRXRoZXJu ZXQgYWRkcmVzcyAwMDphMDpjOTpmYzoxNzo1NQ0KY2hpcDI6IDxJbnRlbCA4 MjM3MUFCIFBDSSB0byBJU0EgYnJpZGdlPiByZXYgMHgwMiBvbiBwY2kwLjE4 LjANCmlkZV9wY2kwOiA8SW50ZWwgUElJWDQgQnVzLW1hc3RlciBJREUgY29u dHJvbGxlcj4gcmV2IDB4MDEgb24gcGNpMC4xOC4xDQpjaGlwMzogPEludGVs IDgyMzcxQUIgUG93ZXIgbWFuYWdlbWVudCBjb250cm9sbGVyPiByZXYgMHgw MiBvbiBwY2kwLjE4LjMNCnZnYTA6IDxDaXJydXMgTG9naWMgbW9kZWwgMDBi YyBWR0EtY29tcGF0aWJsZSBkaXNwbGF5IGRldmljZT4gcmV2IDB4MjMgb24g cGNpMC4yMC4wDQpQcm9iaW5nIGZvciBkZXZpY2VzIG9uIFBDSSBidXMgMToN CmNoaXA0OiA8UENJIHRvIFBDSSBicmlkZ2UgKHZlbmRvcj0xMDExIGRldmlj ZT0wMDIzKT4gcmV2IDB4MDYgb24gcGNpMS4xNS4wDQpQcm9iaW5nIGZvciBk ZXZpY2VzIG9uIFBDSSBidXMgMjoNClByb2JpbmcgZm9yIFBuUCBkZXZpY2Vz Og0KUHJvYmluZyBmb3IgZGV2aWNlcyBvbiB0aGUgSVNBIGJ1czoNCnNjMCBv biBpc2ENCnNjMDogVkdBIGNvbG9yIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBm bGFncz0weDA+DQphdGtiZGMwIGF0IDB4NjAtMHg2ZiBvbiBtb3RoZXJib2Fy ZA0KYXRrYmQwIGlycSAxIG9uIGlzYQ0KcHNtMCBub3QgZm91bmQNCnNpbzAg YXQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2ENCnNpbzA6 IHR5cGUgMTY1NTBBDQpzaW8xIGF0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlz YQ0Kc2lvMTogdHlwZSAxNjU1MEENCmZkYzAgYXQgMHgzZjAtMHgzZjcgaXJx IDYgZHJxIDIgb24gaXNhDQpmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMg dGhyZXNob2xkDQpmZDA6IDEuNDRNQiAzLjVpbg0Kd2RjMCBub3QgZm91bmQg YXQgMHgxZjANCndkYzEgYXQgMHgxNzAtMHgxNzcgaXJxIDE1IG9uIGlzYQ0K d2RjMTogdW5pdCAwIChhdGFwaSk6IDxDUkVBVElWRUNENDgzMUUvMS4wMD4s IHJlbW92YWJsZSwgYWNjZWwsIGRtYSwgaW9yZGlzDQphY2QwOiBkcml2ZSBz cGVlZCAyNzU1IC0gNTUxMUtCL3NlYywgMjQwS0IgY2FjaGUNCmFjZDA6IHN1 cHBvcnRlZCByZWFkIHR5cGVzOiBDRC1SLCBDRC1SVywgQ0QtREENCmFjZDA6 IEF1ZGlvOiBwbGF5LCAyNTUgdm9sdW1lIGxldmVscw0KYWNkMDogTWVjaGFu aXNtOiBlamVjdGFibGUgdHJheQ0KYWNkMDogTWVkaXVtOiBuby9ibGFuayBk aXNjIGluc2lkZSwgdW5sb2NrZWQNCnd0MCBub3QgZm91bmQgYXQgMHgzMDAN Cm1hdGNkYzAgbm90IGZvdW5kIGF0IDB4MjMwDQpwcGMwIGF0IDB4Mzc4IGly cSA3IGZsYWdzIDB4NDAgb24gaXNhDQpwcGMwOiBHZW5lcmljIGNoaXBzZXQg KEVDUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUNCnBwYzA6IEZJ Rk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZA0KbHB0MDogPGdlbmVy aWMgcHJpbnRlcj4gb24gcHBidXMgMA0KbHB0MDogSW50ZXJydXB0LWRyaXZl biBwb3J0DQpwcGkwOiA8Z2VuZXJpYyBwYXJhbGxlbCBpL28+IG9uIHBwYnVz IDANCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMg MA0KbHB0MDogPGdlbmVyaWMgcHJpbnRlcj4gb24gcHBidXMgMA0KbHB0MDog SW50ZXJydXB0LWRyaXZlbiBwb3J0DQphZHYwIG5vdCBmb3VuZCBhdCAweDMz MA0KYnRfaXNhX3Byb2JlOiBQcm9iZSBmYWlsbGVkIGZvciBjYXJkIGF0IDB4 MzMwDQpidF9pc2FfcHJvYmU6IFByb2JlIGZhaWxsZWQgZm9yIGNhcmQgYXQg MHgzMzQNCmJ0X2lzYV9wcm9iZTogUHJvYmUgZmFpbGxlZCBmb3IgY2FyZCBh dCAweDIzMA0KYnRfaXNhX3Byb2JlOiBQcm9iZSBmYWlsbGVkIGZvciBjYXJk IGF0IDB4MjM0DQpidF9pc2FfcHJvYmU6IFByb2JlIGZhaWxsZWQgZm9yIGNh cmQgYXQgMHgxMzANCmJ0X2lzYV9wcm9iZTogUHJvYmUgZmFpbGxlZCBmb3Ig Y2FyZCBhdCAweDEzNA0KYnQwIG5vdCBmb3VuZCBhdCAweDEzNA0KYWhhMCBu b3QgZm91bmQgYXQgMHgxMzQNCnZnYTAgYXQgMHgzYjAtMHgzZGYgbWFkZHIg MHhhMDAwMCBtc2l6ZSAxMzEwNzIgb24gaXNhDQpucHgwIG9uIG1vdGhlcmJv YXJkDQpucHgwOiBJTlQgMTYgaW50ZXJmYWNlDQpBUElDX0lPOiBUZXN0aW5n IDgyNTQgaW50ZXJydXB0IGRlbGl2ZXJ5DQpBUElDX0lPOiByb3V0aW5nIDgy NTQgdmlhIHBpbiAyDQpXYWl0aW5nIDE1IHNlY29uZHMgZm9yIFNDU0kgZGV2 aWNlcyB0byBzZXR0bGUNClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQ0Kc2Ew IGF0IGFoYzEgYnVzIDAgdGFyZ2V0IDQgbHVuIDANCnNhMDogPEhQIEMxNTM3 QSBMNzA2PiBSZW1vdmFibGUgU2VxdWVudGlhbCBBY2Nlc3MgU0NTSS0yIGRl dmljZSANCnNhMDogMTAuMDAwTUIvcyB0cmFuc2ZlcnMgKDEwLjAwME1Ieiwg b2Zmc2V0IDMyKQ0KZGEwIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAN CmRhMDogPFNFQUdBVEUgU1QzOTE0MExXIDE0ODM+IEZpeGVkIERpcmVjdCBB Y2Nlc3MgU0NTSS0yIGRldmljZSANCmRhMDogNDAuMDAwTUIvcyB0cmFuc2Zl cnMgKDIwLjAwME1Ieiwgb2Zmc2V0IDE1LCAxNmJpdCksIFRhZ2dlZCBRdWV1 ZWluZyBFbmFibGVkDQpkYTA6IDg2ODNNQiAoMTc3ODMyNDAgNTEyIGJ5dGUg c2VjdG9yczogMjU1SCA2M1MvVCAxMTA2QykNCmRhMSBhdCBhaGMwIGJ1cyAw IHRhcmdldCAxIGx1biAwDQpkYTE6IDxTRUFHQVRFIFNUMzkxNDBMVyAxNDgz PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTE6IDQw LjAwME1CL3MgdHJhbnNmZXJzICgyMC4wMDBNSHosIG9mZnNldCAxNSwgMTZi aXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGExOiA4NjgzTUIgKDE3 NzgzMjQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTEwNkMpDQpj aGFuZ2luZyByb290IGRldmljZSB0byBkYTBzMWENCihkYTE6YWhjMDowOjE6 MCk6IFJFQUQoMDYpLiBDREI6IDggMSA4YiA0NiBhIDAgDQooZGExOmFoYzA6 MDoxOjApOiBSRUNPVkVSRUQgRVJST1IgYXNjOjVkLDMyDQooZGExOmFoYzA6 MDoxOjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQpwaWQgMzY3OTggKHBp bmUpLCB1aWQgNDQ3MjogZXhpdGVkIG9uIHNpZ25hbCA2IChjb3JlIGR1bXBl ZCkNCg== --0-712198510-935183566=:86770-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 14:50:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 86C9015B2D for ; Fri, 20 Aug 1999 14:50:32 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id RAA07128; Fri, 20 Aug 1999 17:56:34 -0400 (EDT) Date: Fri, 20 Aug 1999 17:56:32 -0400 (EDT) From: Alfred Perlstein To: Steve Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? In-Reply-To: <199908201813.NAA66892@ns1.cioe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Steve Ames wrote: > > I asked this on stable but didn't get a response... Would I get any > performance increases by mounting NFS exported partition as Async? > > Would my soul be tormented in purgatory for doing it? > > Just to be clear... I am wondering if mounting (on the NFS _server_) a > partition (that is exportable) as async will have any performance > benefits to the NFS clients? of course it will, but it'll also potentially cause catastrophic damage to your filesystem if the machine dies for some reason. have a look at: /usr/src/sys/contrib/softupdates/README or possibly /usr/src/contrib/softupdates/README also, play with the nfs sysctl's and mout options to tune performance. sysctl -a | grep nfs good luck, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 15: 8:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from voyager.fisicc-ufm.edu (ip-198-202.guate.net [209.198.197.202]) by hub.freebsd.org (Postfix) with ESMTP id ACC3B14D8D for ; Fri, 20 Aug 1999 15:07:17 -0700 (PDT) (envelope-from obonilla@voyager.fisicc-ufm.edu) Received: (from obonilla@localhost) by voyager.fisicc-ufm.edu (8.9.3/8.9.3) id QAA00707; Fri, 20 Aug 1999 16:04:03 -0600 (CST) (envelope-from obonilla) Date: Fri, 20 Aug 1999 16:04:03 -0600 From: Oscar Bonilla To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Serial cable Message-ID: <19990820160403.A673@fisicc-ufm.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Zhihui Zhang on Fri, Aug 20, 1999 at 03:12:48PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 20, 1999 at 03:12:48PM -0400, Zhihui Zhang wrote: > > Hi, Rich: > > Can you find a serial cable for me? I need to connect two PCs together > via RS232 ports. > Aha! Remote Kernel Debugging aren't we? Probably you did not intend this mail to go to the mailing list :) Regards, -Oscar -- For PGP Public Key: finger obonilla@fisicc-ufm.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 15: 8:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 31837159D5 for ; Fri, 20 Aug 1999 15:08:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA65547; Fri, 20 Aug 1999 15:06:53 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 15:06:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199908202206.PAA65547@apollo.backplane.com> To: Steve Ames Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve Ok, I've run some more tests. Basically you want to run NFSv3 under CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network this will give you unsaturated write performance in the ballpark of 9 MBytes/sec. Saturated write performance, that is where you write more then the client-side buffer cache can handle, will stabilize at 2.5 MBytes/sec. I have a patch for CURRENT which will increase the saturated write performance to 4.5 MBytes/sec (basically by moving the nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). Hopefully that patch will go in soon but there's a pretty big backlog of patches that haven't gone in yet, some over a week and a half old, so... In anycase, even without the patch if you run a couple of nfsiod's and do not saturated the buffer cache you should get optimal performance. Backing-porting the patch for nfs_commit to STABLE is possible but is not likely to help much because the major performance restriction in STABLE is related to buffer cache management, not NFS. OS #nfsiod's unsaturated saturated write perf. write perf. ( ..... 100BASETX ...... ) CURRENT 0 9 MBytes/sec 2.5 MBytes/sec CURRENT 4 9 MBytes/sec 4.5 MBytes/sec(w/patch) STABLE 0 3 MBytes/sec 3 MBytes/sec(1) STABLE 4 4 MBytes/sec 3 MBytes/sec(1) note(1): saturated performance under STABLE is extremely inconsistant -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 Fri Aug 20 15:25: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E197515391 for ; Fri, 20 Aug 1999 15:24:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA65688; Fri, 20 Aug 1999 15:22:18 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 15:22:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199908202222.PAA65688@apollo.backplane.com> To: Steve Ames , freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> <199908202206.PAA65547@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Ok, I've run some more tests. Basically you want to run NFSv3 under : CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network Oh, let me be a bit more clear: Run 3 nfsiod's on the client. Run 4 nfsd's on the server. e.g. 'nfsiod -n 3' on the client and 'nfsd -n 4' on the server. To realize maximum NFS performance both the server and client should be running CURRENT. If Non-FreeBSD clients cannot achieve good performance, the problem is with those clients and nothing you do on the server will help. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 15:52:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 07D3215373 for ; Fri, 20 Aug 1999 15:52:40 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id PAA21378; Fri, 20 Aug 1999 15:52:30 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAAc1aOUP; Fri Aug 20 15:52:24 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA17363; Fri, 20 Aug 1999 15:52:31 -0700 (MST) From: Terry Lambert Message-Id: <199908202252.PAA17363@usr09.primenet.com> Subject: Re: Async NFS exports? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 20 Aug 1999 22:52:31 +0000 (GMT) Cc: fullermd@futuresouth.com, steve@cioe.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908202032.NAA64957@apollo.backplane.com> from "Matthew Dillon" at Aug 20, 99 01:32:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The reason is due to the way NFSv3 issues writes. NFSv3 issues a > write but no longer assumes that the write has been synced to the > server's disk as of when the reply comes back. Instead it keeps the > buffer around and does a later commit rpc to do the sync, presumably > long after the server has already synced the data. > > So, effectively, all NFSv3 writes are async insofar as the client's > buffer cache is able to keep abrest of the write-rate. > > Hmm, interesting. I see another optimization I can do to fix the > buffer cache saturation case in CURRENT on the client. The COMMIT rpc's > aren't being issued async. If you are looking for more optimizations, you can delay NFS write operations for some interval X, on all write buffers, entirely. Sun does this (it is technically called "write gathering" in the literature). The upshot of introducing this latency between request and action is that multiple writes to adjacent regions on non-buffer boundaries are "batched up" for processing by the NFS server. The net result is that you can do more writes, while generating less wire traffic. Be forewarned, however, that you must include synchronization primitives at the appropriate places. Among these are: 1) When a write lock is acquired, a write is issued in a region spanned by the lock, and the lock released, the lock release must also be delayed. The reason for this is that the lock is being used to ensure distributed cache coherency (actually, in effect, a lease-stall for other clients wanting to do writes). 2) When a conflicting lock is requested, you need to initate a synchronization point. This is because even though they are proxied from the same system ID, the NFS locks are on different process ID's, and some NFS servers will enforce based on this, even though the locks are, putatively, advisory, not mandatory. 3) On file deletions. Generally, this just boils down to not being able to delete an NFS file in actuality, unless you are the last closer on the file. Implementation-wise, it means that a delete operation is a request-to-sync operation. 4) Etc.. While these aren't technically necessary right now (in FreeBSD, since FreeBSD fails to implement NFS locking), omitting them now will make it nearly impossible to repair later, should NFS locking support arise from my (or someone else's) kernel patches being applied, and someone hacking up the lock and stat daemons to make the proper system calls. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 16:23:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 1924115403 for ; Fri, 20 Aug 1999 16:23:15 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40322>; Sat, 21 Aug 1999 09:03:00 +1000 Date: Sat, 21 Aug 1999 09:23:01 +1000 From: Peter Jeremy Subject: Re: sio doesn't do HW flow correctly?!? In-reply-to: <199908201322.JAA01890@bmcgover-pc.cisco.com> To: bmcgover@cisco.com Cc: hackers@FreeBSD.ORG Message-Id: <99Aug21.090300est.40322@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian McGovern wrote: >My short term "punt" is to use a desktop system. If I keep seeing the problem >there, I'll debug it some more. If it "goes away", I'll know it was the laptop >being quirky. The other possibility is that the laptop's APM is putting it into some sort of sleep state and not waking it up fast enough. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 16:24:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mw5.texas.net (mw5.texas.net [206.127.30.15]) by hub.freebsd.org (Postfix) with ESMTP id 46B2E14D47 for ; Fri, 20 Aug 1999 16:24:24 -0700 (PDT) (envelope-from rsnow@lgc.com) Received: from basil.dympna.COM (mnet06-26.sat.texas.net [209.99.48.194]) by mw5.texas.net (2.4/2.4) with ESMTP id SAA12059; Fri, 20 Aug 1999 18:24:18 -0500 (CDT) Received: from lgc.com (IDENT:rsnow@turbo [134.132.228.6]) by basil.dympna.COM (8.9.3/8.8.7) with ESMTP id SAA11770; Fri, 20 Aug 1999 18:24:28 -0500 (CDT) (envelope-from rsnow@lgc.com) Message-ID: <37BDE39E.21EE705C@lgc.com> Date: Fri, 20 Aug 1999 18:24:14 -0500 From: Rob Snow X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> <199908202206.PAA65547@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Emm, I guess that answers my earlier question/mail: Why?---> basil# uname -a FreeBSD basil.dympna.com 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Thu Aug 19 23:59:50 CDT 1999 rsnow@basil.dympna.com:/export/current/src/sys/compile/Basil-SMP [Dual PPro-233's] basil# cd /stripe basil# df -k . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vinum/stripe 17197511 86511 15735200 1% /stripe basil# Bonnie -s 256 -------Sequential Output-------- ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 basil# mount_nfs -3 localhost:/stripe /mnt basil# cd /mnt basil# Bonnie -s 256 -------Sequential Output-------- ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Matthew Dillon wrote: > > :I asked this on stable but didn't get a response... Would I get any > :performance increases by mounting NFS exported partition as Async? > : > :Would my soul be tormented in purgatory for doing it? > : > :Just to be clear... I am wondering if mounting (on the NFS _server_) a > :partition (that is exportable) as async will have any performance > :benefits to the NFS clients? > : > :-Steve > > Ok, I've run some more tests. Basically you want to run NFSv3 under > CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network > this will give you unsaturated write performance in the ballpark of > 9 MBytes/sec. Saturated write performance, that is where you write more > then the client-side buffer cache can handle, will stabilize at > 2.5 MBytes/sec. I have a patch for CURRENT which will increase the > saturated write performance to 4.5 MBytes/sec (basically by moving the > nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). > Hopefully that patch will go in soon but there's a pretty big backlog of > patches that haven't gone in yet, some over a week and a half old, so... > > In anycase, even without the patch if you run a couple of nfsiod's and > do not saturated the buffer cache you should get optimal performance. > > Backing-porting the patch for nfs_commit to STABLE is possible but is > not likely to help much because the major performance restriction in > STABLE is related to buffer cache management, not NFS. > > OS #nfsiod's unsaturated saturated > write perf. write perf. > ( ..... 100BASETX ...... ) > > CURRENT 0 9 MBytes/sec 2.5 MBytes/sec > CURRENT 4 9 MBytes/sec 4.5 MBytes/sec(w/patch) > > STABLE 0 3 MBytes/sec 3 MBytes/sec(1) > STABLE 4 4 MBytes/sec 3 MBytes/sec(1) > > note(1): saturated performance under STABLE is extremely inconsistant > > -Matt > Matthew Dillon > > > 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 20 18:38: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 2820A15360 for ; Fri, 20 Aug 1999 18:38:05 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA48009; Fri, 20 Aug 1999 18:35:45 -0700 (PDT) From: Archie Cobbs Message-Id: <199908210135.SAA48009@bubba.whistle.com> Subject: Re: anybody love qsort.c? In-Reply-To: <199908200433.VAA11779@perforce.com> from Christopher Seiwald at "Aug 19, 1999 09:33:30 pm" To: seiwald@perforce.com (Christopher Seiwald) Date: Fri, 20 Aug 1999 18:35:45 -0700 (PDT) Cc: a-wada@mars.dti.ne.jp, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Seiwald writes: > But as I'm proposing a change to a fairly sensitive piece of code, I'd > like to keep the change as modest as possible. How about this? Index: qsort.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v retrieving revision 1.7 diff -u -r1.7 qsort.c --- qsort.c 1997/02/22 15:03:14 1.7 +++ qsort.c 1999/08/21 01:35:35 @@ -153,7 +153,7 @@ pb += es; pc -= es; } - if (swap_cnt == 0) { /* Switch to insertion sort */ + if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es) for (pl = pm; pl > (char *)a && cmp(pl - es, pl) > 0; pl -= es) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.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 20 19:40:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1EDA4150EE for ; Fri, 20 Aug 1999 19:40:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA69152; Fri, 20 Aug 1999 19:37:26 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 19:37:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199908210237.TAA69152@apollo.backplane.com> To: Rob Snow Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908201813.NAA66892@ns1.cioe.com> <199908202206.PAA65547@apollo.backplane.com> <37BDE39E.21EE705C@lgc.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Emm, I guess that answers my earlier question/mail: : :Why?---> : :/dev/vinum/stripe 17197511 86511 15735200 1% /stripe :basil# Bonnie -s 256 : -------Sequential Output-------- ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 : : :basil# mount_nfs -3 localhost:/stripe /mnt :basil# cd /mnt :basil# Bonnie -s 256 : : -------Sequential Output-------- ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Buffer copy and protocol overhead, plus the data is being cached twice: once on the server and once on the client (which happens to be the same machine). The machine becomes cpu-bound with all the extra work. This is what I get. Ignore the read numbers (the machine has a lot of memory). This is with nfsd -n 4 and nfsiod -n 4, NFSv3 UDP mount, on a duel P-III/450 running CURRENT. /dev/da0h 2338236 1235921 915257 57% /usr/obj -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 9979 51.4 9154 19.0 9814 22.5 19727 99.8 103863 100.0 2163.4 43.2 localhost:/usr/obj/ 2338236 1235921 915257 57% /mnt -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 3532 30.9 4164 7.6 4364 14.9 13700 99.9 75964 99.7 2779.7 162.1 As you can see, I get very similar numbers for writing. 9 MB/sec on the local filesystem and 4.3 MB/sec via a localhost: NFS mount. -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 Fri Aug 20 21:39: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bluerose.windmoon.nu (c255152-a.plstn1.sfba.home.com [24.7.89.179]) by hub.freebsd.org (Postfix) with ESMTP id 7E8B8153D7 for ; Fri, 20 Aug 1999 21:38:53 -0700 (PDT) (envelope-from fengyue@bluerose.windmoon.nu) Received: from localhost (fengyue@localhost) by bluerose.windmoon.nu (Windmoon-Patched/8.9.3/8.9.3) with ESMTP id VAA00971 for ; Fri, 20 Aug 1999 21:45:55 -0700 (PDT) Date: Fri, 20 Aug 1999 21:45:55 -0700 (PDT) From: =?ISO-9550?B?o8C359TCv82jwA==?= To: freebsd-hackers@FreeBSD.ORG Subject: pthread_set_concurrency() In-Reply-To: <199908210237.TAA69152@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello there, so it seems that pthread_set_concurrency() has not been implemented at least up to 3.2-stable. How could one ensure that their threads in an application can be "equally" distributed to all the processors in FreeBSD? Are there any documents on FreeBSD 3.*'s thread support(both kernel and user level)? The pthread man pages are quiet incompelete and some pthread calls have not been implemented. Thanks, Ming To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 21:59:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 314E514A09; Fri, 20 Aug 1999 21:59:21 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA08836; Sat, 21 Aug 1999 13:57:19 +0900 (JST) Message-ID: <37BE317E.4B1D7791@newsguy.com> Date: Sat, 21 Aug 1999 13:56:30 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Terry Lambert Cc: phk@critter.freebsd.dk, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite References: <199908191802.LAA25563@usr06.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > That's kind of the point. No other VFS stacking system out there > plays by FreeBSD's revamped rules. I look around and I see no standards. It is still time to be experimental. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 22:45: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3BFFC153DC for ; Fri, 20 Aug 1999 22:45:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA69698; Fri, 20 Aug 1999 22:44:35 -0700 (PDT) (envelope-from dillon) Date: Fri, 20 Aug 1999 22:44:35 -0700 (PDT) From: Matthew Dillon Message-Id: <199908210544.WAA69698@apollo.backplane.com> To: Terry Lambert Cc: fullermd@futuresouth.com, steve@cioe.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908202252.PAA17363@usr09.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The reason is due to the way NFSv3 issues writes. NFSv3 issues a :> write but no longer assumes that the write has been synced to the :> server's disk as of when the reply comes back. Instead it keeps the :.. : :If you are looking for more optimizations, you can delay NFS write :operations for some interval X, on all write buffers, entirely. : :Sun does this (it is technically called "write gathering" in the :literature). The client-side pushes a buffer out the moment it fills up. Since this corresponds to a maximally-sized NFS data packet the client will not be more efficient by delaying it. The server-side in the FreeBSD implementation *DOES* do write-clustering, as I demonstrate below. The server does a better job of write-clustering when the client is a FreeBSD-CURRENT box, though, because FreeBSD-CURRENT clients generate a more uniform data flow. The server is able to do write-clustering w/ NFSv3 mounts because data writes are not required to be synched to disk until the client requests a commit. Note that KB/t fields below. CURRENT server, CURRENT client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 0.00 0 0.00 0 0 1 0 99 0 43 1.00 1 0.00 0 0 0 0100 0 42 6.86 7 0.05 0 0 10 0 90 0 43 61.80 68 4.12 1 0 25 21 53 0 43 64.00 72 4.52 0 0 18 28 54 0 43 64.00 73 4.58 0 0 21 25 54 0 42 62.29 74 4.51 0 0 24 32 45 0 43 63.23 72 4.46 0 0 22 23 54 0 43 64.00 32 1.98 0 0 9 9 82 CURRENT server, STABLE client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 43.43 98 4.15 0 0 15 21 64 0 42 17.48 107 1.82 0 0 9 7 84 0 43 62.49 73 4.47 0 0 19 33 48 0 43 19.93 121 2.35 0 0 8 9 84 0 43 43.07 85 3.58 0 0 17 22 61 0 42 46.77 90 4.11 0 0 21 22 57 0 43 15.63 108 1.65 0 0 8 7 85 0 43 64.00 70 4.39 2 0 17 27 54 However, even a FreeBSD-CURRENT breaks down when its buffer cache saturates. The example below demonstrates this: CURRENT server, CURRENT client, iostat of server disks while client writes (client buffer cache not saturated) 0 43 0.00 0 0.00 0 0 0 0100 0 43 56.00 26 1.41 0 0 14 5 81 0 42 64.00 72 4.52 0 0 21 26 53 0 43 64.00 73 4.58 0 0 25 19 57 11 54 64.00 71 4.46 2 0 17 28 53 0 42 62.27 73 4.45 0 0 26 22 52 5 48 64.00 72 4.52 0 0 22 24 53 5 48 52.72 82 4.23 0 0 20 26 53 (client buffer cache saturates) 11 54 18.76 163 2.99 2 0 12 16 71 1 43 19.20 129 2.41 1 0 13 11 75 7 70 20.65 146 2.95 2 0 14 16 67 4 47 17.53 130 2.22 0 0 9 15 77 6 51 24.63 113 2.72 1 0 10 13 76 4 73 15.17 153 2.27 0 0 11 7 82 The problem that occurs on the FreeBSD server is simply that the nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* file, for every commit rpc, rather then syncing just the offset/range requested. I am looking into ways to fix this. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 22:47:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 295D4153DC for ; Fri, 20 Aug 1999 22:47:10 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id XAA01384; Fri, 20 Aug 1999 23:47:00 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id XAA18821; Fri, 20 Aug 1999 23:46:59 -0600 Date: Fri, 20 Aug 1999 23:46:59 -0600 Message-Id: <199908210546.XAA18821@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?ISO-9550?B?o8C359TCv82jwA==?= Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_set_concurrency() In-Reply-To: References: <199908210237.TAA69152@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > implemented at least up to 3.2-stable. How could one ensure that their > threads in an application can be "equally" distributed to all the > processors in FreeBSD? You can't. > Are there any documents on FreeBSD 3.*'s thread > support(both kernel and user level)? FreeBSD has no kernel 'thread' support, only user level. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 22:57:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 6FB06153F5 for ; Fri, 20 Aug 1999 22:57:47 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA22317 for ; Sat, 21 Aug 1999 01:57:47 -0400 (EDT) Message-Id: <199908210557.BAA22317@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: device_add_child?? Date: Sat, 21 Aug 1999 01:57:47 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been writing a nasty kludge to treat a CardBus bridge as a standard PCI bridge (with static config) . I have it to the point where I can (after the system is booted) 'pciconf -r pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get the bus to show up at PCI5: at bootup, but it seems to ignore it. following from pcisupport.c I also tried to 'bus_generic_attach()' it after device_add_child() finished. no go. Any suggestions? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 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 Fri Aug 20 23:49:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jason.argos.org (a1-3a123.neo.rr.com [24.93.180.123]) by hub.freebsd.org (Postfix) with ESMTP id B4D071505D for ; Fri, 20 Aug 1999 23:49:31 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA30635 for ; Sat, 21 Aug 1999 02:46:51 -0400 Date: Sat, 21 Aug 1999 02:46:51 -0400 (EDT) From: Mike Nowlin To: freebsd-hackers@freebsd.org Subject: I2C/SMBus/LPBB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had sent this message to -stable about a month ago, never heard anything -- so am trying it here. ---------- Forwarded message ---------- Date: Wed, 21 Jul 1999 03:24:38 -0400 (EDT) From: Mike Nowlin To: freebsd-stable@freebsd.org Subject: I2C/SMBus/LPBB OK -- I give up.... I'm trying to get the LPBB I2C driver working on my 3.2-stable machine, CVSUP'd earlier today... I have tried about a zillion and two different config file combinations, and can not get it to work. The relevant parts of the config file are: device ppc0 at isa? port? tty irq 7 controller pcf0 at isa? port? irq 5 controller iicbb0 controller smbus0 device smb0 at smbus? controller ppbus0 #device lpt0 at ppbus? #device ppi0 at ppbus? device lpbb0 at ppbus? controller iicbus0 device iic0 at iicbus? device iicsmb0 at iicbus? (.....As you can see, I took out the printer driver and the geek port during this hair-pulling session -- those two devices vanish, but nothing else appears.) The dmesg chunks that show up about this are: ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ... pcf0 at irq 5 on isa ... pcf0: iicbus0: on pcf0 addr 0xaa iicsmb0: on iicbus0 smbus0: on iicsmb0 smb0: on smbus0 iic0: on iicbus0 It seems to see the PCF8584 just fine, but it refuses to put the parallel port I2C interface in... If I remove the "controller pcf0" line, all of the I2C drivers disappear. Any ideas? --Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 20 23:51:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A4D4D1505D for ; Fri, 20 Aug 1999 23:51:08 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA58532; Sat, 21 Aug 1999 00:51:03 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA41509; Sat, 21 Aug 1999 00:51:13 -0600 (MDT) Message-Id: <199908210651.AAA41509@harmony.village.org> To: "David E. Cross" Subject: Re: device_add_child?? Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 21 Aug 1999 01:57:47 EDT." <199908210557.BAA22317@cs.rpi.edu> References: <199908210557.BAA22317@cs.rpi.edu> Date: Sat, 21 Aug 1999 00:51:13 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908210557.BAA22317@cs.rpi.edu> "David E. Cross" writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) . Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 0:50:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5BA9814E89 for ; Sat, 21 Aug 1999 00:50:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA70298; Sat, 21 Aug 1999 00:46:58 -0700 (PDT) (envelope-from dillon) Date: Sat, 21 Aug 1999 00:46:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199908210746.AAA70298@apollo.backplane.com> To: fullermd@futuresouth.com, steve@cioe.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? References: <199908202252.PAA17363@usr09.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : The problem that occurs on the FreeBSD server is simply that the : nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* : file, for every commit rpc, rather then syncing just the offset/range : requested. I am looking into ways to fix this. : Ok, I've verified the problem. The nfsrv_commit() code running on the server is definitely the culprit. I was able to make a tentitive patch which increased NFSv3 write performance to 10 MBytes/sec -- the maximum my 100BaseTX network can do. CURRENT in tree: 2.5 MBytes/sec CURRENT w/ asynchronized commit rpc: 4.5 MBytes/sec CURRENT w/ asy commit and fixed nfsrv_commit: 10 MBytes/sec (1) note(1): network is maxed out. Running bonnie returned around 5.2 MBytes/sec using putc, 3.5 MBytes/sec doing rewrite (but also 3.5 MBytes/sec going the other way), and 10 MBytes/sec writing intelligently. Throughout the test the low level disk I/O on the server was able to do sustained clustering at 64KB/t. I have a backlog of patches so it may be a week or more before this one gets tested and committed into CURRENT. It's a little racey for putting into STABLE but maybe after a month of testing on CURRENT we will be able to do it. -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 21 1:43:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id E474414F27 for ; Sat, 21 Aug 1999 01:43:49 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11I6Ei-0000Ov-00 for hackers@freebsd.org; Sat, 21 Aug 1999 02:10:49 -0600 Message-ID: <37BE5F07.3F91A2B8@softweyr.com> Date: Sat, 21 Aug 1999 02:10:47 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: mmap mapped segment length Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it. Is this intentional, or just an artifact of the implementation? Is there any reason NOT to change this to an off_t? Granted, I'm no VM hacker, but I'm willing to take a swing at it if there is any interest in putting it into the system. Otherwise, I have a workaround that works just fine for this application. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 2: 8:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 44E3F1544B for ; Sat, 21 Aug 1999 02:08:23 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA01609; Sat, 21 Aug 1999 02:06:25 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA17965; Sat, 21 Aug 1999 02:06:24 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA17706; Sat, 21 Aug 1999 02:06:23 -0700 (PDT) From: Don Lewis Message-Id: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> Date: Sat, 21 Aug 1999 02:06:23 -0700 In-Reply-To: Wes Peters "mmap mapped segment length" (Aug 21, 2:10am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Wes Peters , hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. } Is this intentional, or just an artifact of the implementation? Is there any } reason NOT to change this to an off_t? The type of size_t is supposed to be large enough to express the length of any object that will fit in the virtual address space of a process. Since a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't be any advantage to changing mmap() to use a 64 bit wide length parameter, since you wouldn't be able to access all of such a large object. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 2:13: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 8888B14DB7 for ; Sat, 21 Aug 1999 02:13:01 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-145.skylink.it [194.185.55.145]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id LAA24865; Sat, 21 Aug 1999 11:11:14 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id KAA17397; Sat, 21 Aug 1999 10:45:57 +0200 (CEST) Date: Sat, 21 Aug 1999 10:45:57 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Warner Losh Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: device_add_child?? In-Reply-To: <199908210651.AAA41509@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG man 9 device_probe_and_attach Nick On Sat, 21 Aug 1999, Warner Losh wrote: > In message <199908210557.BAA22317@cs.rpi.edu> "David E. Cross" writes: > : I have been writing a nasty kludge to treat a CardBus bridge as a standard > : PCI bridge (with static config) . > > Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) > > : I have > : it to the point where I can (after the system is booted) 'pciconf -r > : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would > : then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get > : the bus to show up at PCI5: at bootup, but it seems to ignore it. following > : from pcisupport.c I also tried to 'bus_generic_attach()' it after > : device_add_child() finished. no go. Any suggestions? > > device_add_child just adds it to the tree. It doesn't probe or attach > it. If you kludge adding it into the tree, you'll have to kludge > attaching it. You might want to look at my pccard kludge-o-matic for > examples. > > Warner > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 2:13:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id EF1E814EBE for ; Sat, 21 Aug 1999 02:13:08 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-145.skylink.it [194.185.55.145]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id LAA24869; Sat, 21 Aug 1999 11:11:18 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id LAA17434; Sat, 21 Aug 1999 11:05:09 +0200 (CEST) Date: Sat, 21 Aug 1999 11:05:09 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Archie Cobbs Cc: Christopher Seiwald , a-wada@mars.dti.ne.jp, freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? In-Reply-To: <199908210135.SAA48009@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You can check the change by recompiling a few utils with the change: (find . -name \*.c | xargs grep -l qsort) ./bin/ps/ps.c ./contrib/gcc/*.c ./contrib/top/commands.c ./games/fortune/strfile/strfile.c ./gnu/usr.bin/sort/sort.c ./sbin/fsck/pass2.c The fsck one is a nice one. Just wack your /usr and reboot :-) Nick On Fri, 20 Aug 1999, Archie Cobbs wrote: > Christopher Seiwald writes: > > But as I'm proposing a change to a fairly sensitive piece of code, I'd > > like to keep the change as modest as possible. > > How about this? > > Index: qsort.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v > retrieving revision 1.7 > diff -u -r1.7 qsort.c > --- qsort.c 1997/02/22 15:03:14 1.7 > +++ qsort.c 1999/08/21 01:35:35 > @@ -153,7 +153,7 @@ > pb += es; > pc -= es; > } > - if (swap_cnt == 0) { /* Switch to insertion sort */ > + if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ > for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es) > for (pl = pm; pl > (char *)a && cmp(pl - es, pl) > 0; > pl -= es) > > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 2:44: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1BA3E14EBE; Sat, 21 Aug 1999 02:43:56 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id SAA05512; Sat, 21 Aug 1999 18:39:36 +0900 (JST) Message-ID: <37BE6CE8.D59FF19C@newsguy.com> Date: Sat, 21 Aug 1999 18:10:00 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Terry Lambert , phk@critter.freebsd.dk, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite References: <199908191802.LAA25563@usr06.primenet.com> <37BE317E.4B1D7791@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Terry Lambert wrote: > > > > That's kind of the point. No other VFS stacking system out there > > plays by FreeBSD's revamped rules. > > I look around and I see no standards. It is still time to be > experimental. Since someone complained of my meekness, let me restate that... :-) 1) BS. That was not your point. Your point, in which you spent many paragraphs, was that the present way FreeBSD things does it stuff cannot support passing a method through an intermediate host/fs that does not know it. If your "point" was the above, you could just have said "no one else does it this way, so we won't be able to have non-FreeBSD intermediate/frontend/backend hosts". Only that does not prove that "our" way is not right. 2) There is *no* compatibility in the VFS out there. It's a jungle. If we implemented something compatible with anyone else, it would be a first. And given that everything out there have it's problems, it would be a huge mistake to adopt someone's standard just for the sake of being compatible. And if you disagree with point 2, feel free to argue against it. But in no way it will justify that absurd comment you made. Either that paragraph was trying to cover a flaw in your logic, or you just lost your train of thought. It certainly detracted from the content of the message. "You must assume that the intermediate host doesn't play by your rules". Bah. [not that I don't generally agree with you more often than it would be prudent to let it be publicly known :-) ] -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 4:54:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dyson.iquest.net. (iq-ind-dns003-90.iquest.net [198.70.149.90]) by hub.freebsd.org (Postfix) with ESMTP id B399C150C6 for ; Sat, 21 Aug 1999 04:54:24 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from toor@localhost) by dyson.iquest.net. (8.9.3/8.9.3) id GAA20218; Sat, 21 Aug 1999 06:53:09 -0500 (EST) (envelope-from toor) Message-Id: <199908211153.GAA20218@dyson.iquest.net.> Subject: Re: mmap mapped segment length In-Reply-To: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> from Don Lewis at "Aug 21, 1999 02:06:23 am" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sat, 21 Aug 1999 06:53:09 -0500 (EST) Cc: wes@softweyr.com (Wes Peters), hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don Lewis said: > On Aug 21, 2:10am, Wes Peters wrote: > } Subject: mmap mapped segment length > } I discovered to my dismay today that the length field in the mmap call is > } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file > } and found I was only processing the first 4 MBytes of it. > > 50 MB should comfortably fit in a size_t. > It seems that 4MB and 4GB are being confused :-). John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 5:19:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D3CA14C0B for ; Sat, 21 Aug 1999 05:19:46 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id NAA41955 for ; Sat, 21 Aug 1999 13:06:58 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id MAA29661 for hackers@freebsd.org; Sat, 21 Aug 1999 12:02:40 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Sat, 21 Aug 1999 12:02:40 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: Package creation without installation Message-ID: <19990821120240.A27252@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -hackers, I'm playing around with the pkg_create(1) command at the moment, trying to get the creation of pre-built versions (HTML, PS, etc) of the FDP documentation working. One of the things I'm trying to do is *not* require that the doc that's being packaged up be installed first. For example, if I'm building the PS version of the FAQ then I can # pwd /tmp/niks-package-build-area # cd doc/en_US.ISO_8859-1/books/faq # make FORMATS=ps What I'd like to do is then create a package from this file, such that when it is installed it does not default to installing in to /tmp/niks-package-build-area/docs/en_US.ISO_8859-1/books/faq but instead defaults to installing somewhere under /usr/doc/. From my read of the pkg_create(1) man page this should be possible, using either the -s command line option, or the @srcdir directive in the PLIST. But I can't get it to work. Using the above directories as an example, I would expect the following to work: # pkg_create -c COMMENT -d DESCR -f PLIST -p /usr/doc -s . faq.tgz (where PLIST contains one line, "book.ps"). From reading pkg_create(1), this should set the installation prefix to "/usr/doc", giving an installed filename of "/usr/doc/faq.ps", but should use the current directory when building the tar file. So at this point, /usr/doc/book.ps doesn't need to exist, as long as ./book.ps exists. However, this doesn't work, tar(1) complains that it can't add /usr/doc/faq.ps. This is unsurprising, as (a) /usr/doc/faq.ps doesn't exist, because I haven't done "make install", and (b) I don't see an option to tar(1) that lets you prepend a directory component to the start of all the filenames in the archive. So I assume that you can only produce packages from files that are already in the 'right' place in the filesystem, yes? That being the case, what is the '-s' option to pkg_create(1) for? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 5:29:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id B33B714C0B for ; Sat, 21 Aug 1999 05:29:12 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id OAA64095; Sat, 21 Aug 1999 14:28:41 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908211228.OAA64095@gratis.grondar.za> To: Sheldon Hearn Cc: Cillian Sharkey , hackers@FreeBSD.ORG Subject: Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c Date: Sat, 21 Aug 1999 14:28:40 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So are there any _objections_ to having the kernel match promiscuous > "enabled" messages with "disabled" counterparts? I strongly _request_ such a log message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 6:38:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by hub.freebsd.org (Postfix) with ESMTP id 886F914D06 for ; Sat, 21 Aug 1999 06:38:21 -0700 (PDT) (envelope-from assar@sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id PAA28516; Sat, 21 Aug 1999 15:37:44 +0200 (CEST) To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel debugging questions References: Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 21 Aug 1999 15:37:40 +0200 In-Reply-To: Zhihui Zhang's message of "Thu, 19 Aug 1999 21:48:00 -0400 (EDT)" Message-ID: <5lvha945ln.fsf@assaris.sics.se> Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Zhihui Zhang writes: > Thanks for your response. I can not think of those points myself. > However, on page 7 of the book "Panic! Unix system crash dump analysis", > it says that a debugger named kadb in SunOS can load the real kernel > during boot and treat the latter like a great, big, user program, stepping > through its execution, examining and modifying values on the fly. > > It seems to me that FreeBSD does not have such a debugger. Maybe ddb can > do so, but it works with assembly. kadb also works with assembly. That being said, I much prefer ddb to kadb, and of course remote gdb is *much* nicer. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 7:11:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id A0AA114F43 for ; Sat, 21 Aug 1999 07:11:19 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-135.skylink.it [194.185.55.135]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id QAA28245 for ; Sat, 21 Aug 1999 16:11:22 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id MAA17661 for ; Sat, 21 Aug 1999 12:54:32 +0200 (CEST) Date: Sat, 21 Aug 1999 12:54:32 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: from number to power of two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 -> 1 2,3 -> 2 4,5,6,7 -> 4 8,9,10,11,12,13,14,15 -> 8 etc. So %1101 should become either %10000 or %1000. The only solution I have so far is a table. That is a possibility as the the highest number will be 32 I think. Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 7:11:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 6121414F5E for ; Sat, 21 Aug 1999 07:11:20 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-135.skylink.it [194.185.55.135]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id QAA28248 for ; Sat, 21 Aug 1999 16:11:24 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id MAA17596 for ; Sat, 21 Aug 1999 12:02:23 +0200 (CEST) Date: Sat, 21 Aug 1999 12:02:23 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: DMA-able memory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How do I allocate DMA-able memory? Or is all memory DMA-able? Like so: #include dma_addr = vtophys(addr); The UHCI (and OHCI) USB controllers use DMA to access the queues with the TransferDescriptors and QueueHeads. This is going to be loads of small (4 to 32 byte) memory blocks. Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 7:24:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from at.dotat.com (zed.dotat.com [203.2.134.254]) by hub.freebsd.org (Postfix) with ESMTP id F2A8315008 for ; Sat, 21 Aug 1999 07:24:30 -0700 (PDT) (envelope-from hart@at.dotat.com) Received: from at.dotat.com (localhost.dotat.com [127.0.0.1]) by at.dotat.com (8.8.8/8.8.8) with ESMTP id XAA18455 for ; Sat, 21 Aug 1999 23:59:49 +0930 (CST) Message-Id: <199908211429.XAA18455@at.dotat.com> To: FreeBSD Hackers mailing list Subject: Re: from number to power of two In-reply-to: Your message of "Sat, 21 Aug 1999 12:54:32 +0200." Date: Sat, 21 Aug 1999 23:59:48 +0930 From: Leigh Hart Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG G'day Nick, Nick Hibma wrote: > > Does anyone know an inexpensive algorithm (O(1)) to go from > an number to the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. a bitwise shift left (to higher) or right (to lower) before or after masking out all but the most significant bit in the number. You just need to know how many bits to mask based on where the most significant bit is ;] I was tempted to throw something together but its late, and the idea should be enough to go on ... Cheers Leigh -- | "By the time they had diminished | Leigh Hart, | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 7:30: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 9AC1D15008 for ; Sat, 21 Aug 1999 07:30:03 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA29830; Sat, 21 Aug 1999 13:51:52 +0200 From: Luigi Rizzo Message-Id: <199908211151.NAA29830@labinfo.iet.unipi.it> Subject: Re: from number to power of two To: hibma@skylink.it Date: Sat, 21 Aug 1999 13:51:52 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Nick Hibma" at Aug 21, 99 12:54:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 661 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. > > The only solution I have so far is a table. That is a possibility as the > the highest number will be 32 I think. The kernel uses a 'ffs()' function for that but i seem to remember that some processors have this one as a machine instruction. ffs() is declared in /sys/sys/libkern.h and implemented in /sys/libkern/ffs.c but maybe there is an assembly version somewherewhich i can't find. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 7:45:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id 27FE115008 for ; Sat, 21 Aug 1999 07:45:29 -0700 (PDT) (envelope-from patryk@ilion.eu.org) Received: (from patrykz@localhost) by mycenae.ilion.eu.org (8.9.3/8.9.3) id AAA68174; Sun, 22 Aug 1999 00:44:07 +1000 (EST) (envelope-from patryk@ilion.eu.org) Date: Sun, 22 Aug 1999 00:44:07 +1000 (EST) Message-Id: <199908211444.AAA68174@mycenae.ilion.eu.org> X-Authentication-Warning: mycenae.ilion.eu.org: patrykz set sender to patryk@ilion.eu.org using -f From: Patryk Zadarnowski To: Nick Hibma Cc: hackers@FreeBSD.ORG Subject: Re: from number to power of two In-reply-to: Your message of "Sat, 21 Aug 1999 12:54:32 +0200." Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. > > The only solution I have so far is a table. That is a possibility as the > the highest number will be 32 I think. Nick, Probably the best solution I can think of is a binary search on the number. I'd estimate it as better than a table, as you save on memory references (tables sound cool, but, from experience, they cause enough extra data cache misses to kill any advantage, even in a highly-optimized inner loop. For 8-bit integets, a quick solution is: int round_up(int x) { if (x & 0xf0) { if (x & 0xc0) return (x & 0x80) ? 0x80 : 0x40; else { return (x & 0x20) ? 0x20 : 0x10; } } else { if (x & 0xc) return (x & 0x8) ? 0x8 : 0x4; else { return (x & 0x2) ? 0x2 : 0x1; } } } It's actually faster than the BSF/BSR operations on Pentium (and the ffs() libc function), as Pentium does a sequential search of the bit string and therefore is O(n) (eek!) The innermost comparison could probably be avoided if it wasn't 00:37 or if I didn't have to get up early in the morning. You could also combine that with a smaller lookup table to get the best of both worlds. Patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 9:30:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id D5B7D14BDD for ; Sat, 21 Aug 1999 09:30:22 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id MAA24645 for ; Sat, 21 Aug 1999 12:29:30 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sat, 21 Aug 1999 12:29:30 -0400 (EDT) From: Chuck Robey To: FreeBSD-Hackers@FreeBSD.ORG Subject: ATX power supplies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 9:54:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 8C88F14F64 for ; Sat, 21 Aug 1999 09:54:16 -0700 (PDT) (envelope-from toasty@dragondata.com) Received: from dino (dino [204.137.237.6]) by home.dragondata.com (8.9.2/8.9.2) with ESMTP id LAA28651; Sat, 21 Aug 1999 11:53:53 -0500 (CDT) Message-Id: <4.2.0.58.19990821115331.0095ca80@nfs.dragondata.com> X-Sender: toasty@nfs.dragondata.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 21 Aug 1999 11:53:48 -0500 To: Chuck Robey , FreeBSD-Hackers@FreeBSD.ORG From: Kevin Day Subject: Re: ATX power supplies In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: >Anyone know where the spec might be for how ATX power supplies work >(especially the interface to the motherboard, and their on'off methods?) > >Thanks. ftp://download.intel.com/design/motherbd/atx_201.pdf See section 4.2 Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 10: 7:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id CFEBE15160 for ; Sat, 21 Aug 1999 10:07:41 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id NAA24992; Sat, 21 Aug 1999 13:05:06 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sat, 21 Aug 1999 13:05:06 -0400 (EDT) From: Chuck Robey To: Kevin Day Cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: ATX power supplies In-Reply-To: <4.2.0.58.19990821115331.0095ca80@nfs.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Aug 1999, Kevin Day wrote: > At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: > >Anyone know where the spec might be for how ATX power supplies work > >(especially the interface to the motherboard, and their on'off methods?) > > > >Thanks. > > ftp://download.intel.com/design/motherbd/atx_201.pdf That's just what I wanted, thanks (also to Len, who sent something seconds later). I have to troubleshoot something. Time to get the trusty VOM out. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 10: 8: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 63FDB1538E for ; Sat, 21 Aug 1999 10:08:01 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id NAA08052 for ; Sat, 21 Aug 1999 13:07:50 -0400 (EDT) Date: Sat, 21 Aug 1999 12:54:26 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: Questions for vnconfig Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have successfully used vnconfig to add swap file and mount disk image files. However, I am still not sure about the following two things: (1) What does the count in "pseudo-device vn count" stand for? My guess is that if it is 2, then we can use /dev/vn0x and /dev/vn1x. If it is 1, then we can only use /dev/vn0x. The x stands for one of those eight partitions [a-h] in one slice. (2) For /dev/vn0[a-h], which one from a-h should I use for which purpose? Any help is appreciated. -------------------------------------------------- Zhihui Zhang. Please visit http://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 Sat Aug 21 10:13:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id 589A015160 for ; Sat, 21 Aug 1999 10:13:32 -0700 (PDT) (envelope-from k@numeri.campus.luth.se) Received: from numeri.campus.luth.se (localhost [127.0.0.1]) by numeri.campus.luth.se (8.9.3/8.9.3) with ESMTP id TAA76885; Sat, 21 Aug 1999 19:11:35 +0200 (CEST) (envelope-from k@numeri.campus.luth.se) Message-Id: <199908211711.TAA76885@numeri.campus.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Hibma Cc: FreeBSD Hackers mailing list Subject: Re: from number to power of two In-reply-to: Your message of "Sat, 21 Aug 1999 12:54:32 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Aug 1999 19:11:35 +0200 From: Johan Karlsson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Sat, 21 Aug 1999 12:54:32 +0200, Nick Hibma wrote: > >Does anyone know an inexpensive algorithm (O(1)) to go from an number to >the next (lower or higher) power of two. > >1 -> 1 >2,3 -> 2 >4,5,6,7 -> 4 >8,9,10,11,12,13,14,15 -> 8 >etc. > >So %1101 should become either %10000 or %1000. > >The only solution I have so far is a table. That is a possibility as the >the highest number will be 32 I think. This small prog works at least on x86 ===== #include #include int main(int argc, char **argv){ int i, j, k; sscanf(argv[1], "%d", &i); j = 1<<(fls(i)-1); k = 1<<(fls(i-1)); printf("%d %d %d\n", j, i, k); return 0; } ===== /Johan K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 10:19:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 07BCB15B51 for ; Sat, 21 Aug 1999 10:19:00 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id TAA25696 for freebsd-hackers@FreeBSD.ORG; Sat, 21 Aug 1999 19:18:09 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 1758D8795; Sat, 21 Aug 1999 11:08:56 +0200 (CEST) Date: Sat, 21 Aug 1999 11:08:56 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_set_concurrency() Message-ID: <19990821110856.A28321@keltia.freenix.fr> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <199908210237.TAA69152@apollo.backplane.com> <199908210546.XAA18821@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199908210546.XAA18821@mt.sri.com>; from Nate Williams on Fri, Aug 20, 1999 at 11:46:59PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Nate Williams: > FreeBSD has no kernel 'thread' support, only user level. That's not strictly true. The fact is we have both kernel and user threads but no mapping between the two... The kernel already internally use some threads. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 10:45:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BFED8153BB for ; Sat, 21 Aug 1999 10:40:51 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA08073; Sat, 21 Aug 1999 11:39:36 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA20723; Sat, 21 Aug 1999 11:39:35 -0600 Date: Sat, 21 Aug 1999 11:39:35 -0600 Message-Id: <199908211739.LAA20723@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ollivier Robert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_set_concurrency() In-Reply-To: <19990821110856.A28321@keltia.freenix.fr> References: <199908210237.TAA69152@apollo.backplane.com> <199908210546.XAA18821@mt.sri.com> <19990821110856.A28321@keltia.freenix.fr> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > FreeBSD has no kernel 'thread' support, only user level. > > That's not strictly true. The fact is we have both kernel and user > threads but no mapping between the two... The kernel already > internally use some threads. Your definition of kernel threads and mine are obviously quite different. :) 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 21 10:51:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lodge.guild.ab.ca (lodge.guild.ab.ca [209.91.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 48F4C14D32 for ; Sat, 21 Aug 1999 10:51:05 -0700 (PDT) (envelope-from davidc@lodge.guild.ab.ca) Received: from localhost (davidc@localhost) by lodge.guild.ab.ca (8.9.3/8.9.1) with ESMTP id LAA06262 for ; Sat, 21 Aug 1999 11:46:18 -0600 (MDT) Date: Sat, 21 Aug 1999 11:46:18 -0600 (MDT) From: Chad David To: freebsd-hackers@freebsd.org Subject: SCSI vs IDE with vinum Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just setup vinum for the first time on a brand new server, nd I am getting what I think are strange results in performance tests with rawio. My SCSI drives seem to be much slower that my IDE drives? Here is a dmesg from the machine: ####################################################################### Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sat Aug 21 06:52:28 MDT 1999 root@temple.guild.ab.ca:/usr/src/sys/compile/GUILD1 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383f9ff> real memory = 268435456 (262144K bytes) avail memory = 257900544 (251856K bytes) Preloaded elf kernel "kernel" at 0xc0332000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 ide_pci0: rev 0x01 on pci0.4.1 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x01 int a irq 10 on pci0.11.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x30 int a irq 11 on pci0.12.0 xl0: Ethernet address: 00:50:04:e1:3c:4d xl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 1: vga0: rev 0x5c int a irq 11 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-16 wd0: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 wd1: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xb0ffb0ff on isa wdc1: unit 0 (wd2): , LBA, DMA, 32-bit, multi-block-16 wd2: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1: unit 1 (wd3): , LBA, DMA, 32-bit, multi-block-16 wd3: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da0 at ahc0 bus 0 target 3 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 6 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) vinum: loaded vinum: reading configuration from /dev/wd3e vinum: updating configuration from /dev/da0e vinum: updating configuration from /dev/da1e vinum: updating configuration from /dev/wd2e ########################################################################## As you can see there are four 14.4 Gig IBM IDE drives, and 2 18Gig IBM SCSI drives. My vinum config is: drive scsi1 device /dev/da0e drive scsi2 device /dev/da1e drive ide1 device /dev/wd2e drive ide2 device /dev/wd3e volume exporthome plex org concat sd length 0 drive scsi1 sd length 0 drive scsi2 volume backup plex org concat sd length 0 drive ide1 sd length 0 drive ide2 SCSI # rawio -a -v 1 /dev/vinum/rexporthome Test ID K/sec /sec %User %Sys %Total RR anon 1774.1 110 0.1 0.7 0.7 16384 SR anon 14482.7 884 0.1 5.3 5.4 16384 RW anon 1573.7 98 0.1 0.6 0.6 16384 SW anon 1981.8 121 0.0 0.7 0.8 16384 /dev/rda0 is one of the raw drives in exporthome.. # rawio -a -v 1 /dev/rda0 Test ID K/sec /sec %User %Sys %Total RR anon 2241.3 138 0.1 0.5 0.6 16384 SR anon 19115.9 1167 0.1 4.5 4.5 16384 RW anon 959.1 60 0.0 0.2 0.3 16384 SW anon 2608.7 159 0.0 0.6 0.6 16384 IDE # rawio -a -v 1 /dev/vinum/rbackup Test ID K/sec /sec %User %Sys %Total RR anon 1372.9 86 0.0 0.4 0.4 16384 SR anon 28443.2 1736 0.4 7.5 7.8 16384 RW anon 601.3 37 0.0 0.2 0.2 16384 SW anon 12227.7 746 0.3 3.1 3.4 16384 /dev/rwd1 is just a stand alone IDE drive. # rawio -a -v 1 /dev/rwd1 Test ID K/sec /sec %User %Sys %Total RR anon 1610.0 100 0.0 0.2 0.3 16384 SR anon 28828.8 1760 0.4 3.3 3.7 16384 RW anon 1218.5 76 0.1 0.2 0.2 16384 SW anon 11628.1 710 0.0 1.5 1.5 16384 I could be wrong but shouldn't the SCSI system blow away the IDE system? Does anybody have any ideas about what I could be doing wrong? Could there be a termination problem? It is set to auto terminate, but I have read about problems with that. Any help would be greatly appreciated. On a side note, can you enable softupdates on a vinum fs? Thanks Chad davidc@guild.ab.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 11:11:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 710AC14CF3 for ; Sat, 21 Aug 1999 11:11:10 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id LAA13809; Sat, 21 Aug 1999 11:10:15 -0700 (PDT) Message-Id: <199908211810.LAA13809@lestat.nas.nasa.gov> To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length Reply-To: Jason Thorpe From: Jason Thorpe Date: Sat, 21 Aug 1999 11:10:14 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters wrote: > I discovered to my dismay today that the length field in the mmap call is > a size_t, not an off_t. I was attempting to process a large (~50 MByte) file > and found I was only processing the first 4 MBytes of it. ...first of all, I assume you mean GByte, not MByte. The type of the "len" argument is specified by multiple standards. You could change size_t to a 64-bit quantity, but then you have: (1) A serious ABI incompatibility issue with the rest of the x86 world. (2) You'd have to go to 64-bit arithmetic everywhere in the VM code which could seriously impact performance. > Is this intentional, or just an artifact of the implementation? Is there any > reason NOT to change this to an off_t? -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 12:10:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from donhm.calcasieu.com (tcnet05-62.austin.texas.net [209.99.42.62]) by hub.freebsd.org (Postfix) with ESMTP id 253E21546D for ; Sat, 21 Aug 1999 12:10:12 -0700 (PDT) (envelope-from dread@texas.net) Received: from donhm.calcasieu.com (localhost.calcasieu.com [127.0.0.1]) by donhm.calcasieu.com (8.8.8/8.8.8) with ESMTP id OAA28671; Sat, 21 Aug 1999 14:11:03 -0500 (CDT) (envelope-from dread@texas.net) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 21 Aug 1999 14:11:03 -0500 (CDT) From: Don Read To: Nick Hibma Subject: RE: from number to power of two Cc: FreeBSD Hackers mailing list Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21-Aug-99 Nick Hibma wrote: > > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. > > The only solution I have so far is a table. That is a possibility as the > the highest number will be 32 I think. a bit of fiddling around gives: int pw2(register unsigned i) { register unsigned cnt=1; do { i >>= 1; cnt <<=1; /* printf("[%x %x],",i, cnt); */ } while (i); /* return(cnt) /* higher */ return( cnt >> 1); /* in bound */ /* return(cnt >> 2); /* lower */ } Prolly should do boundry check for case 0 : 0 -> 0 ? 0 -> 1. Regards, --- Don Read dread@calcasieu.com EDP Manager dread@texas.net Calcasieu Lumber Co. Austin TX -- But I'm in good company, sendmail has kicked a great many butts in the past To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 14:38:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0A03514BFF for ; Sat, 21 Aug 1999 14:38:12 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA62772; Sat, 21 Aug 1999 15:38:10 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA48856; Sat, 21 Aug 1999 15:38:28 -0600 (MDT) Message-Id: <199908212138.PAA48856@harmony.village.org> To: Nick Hibma Subject: Re: from number to power of two Cc: FreeBSD Hackers mailing list In-reply-to: Your message of "Sat, 21 Aug 1999 12:54:32 +0200." References: Date: Sat, 21 Aug 1999 15:38:28 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Nick Hibma writes: : Does anyone know an inexpensive algorithm (O(1)) to go from an number to : the next (lower or higher) power of two. 1 << ffs(x) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 14:43:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9BD1714F6F for ; Sat, 21 Aug 1999 14:43:09 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA62784; Sat, 21 Aug 1999 15:41:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA48879; Sat, 21 Aug 1999 15:41:56 -0600 (MDT) Message-Id: <199908212141.PAA48879@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: pthread_set_concurrency() Cc: Ollivier Robert , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 21 Aug 1999 11:39:35 MDT." <199908211739.LAA20723@mt.sri.com> References: <199908211739.LAA20723@mt.sri.com> <199908210237.TAA69152@apollo.backplane.com> <199908210546.XAA18821@mt.sri.com> <19990821110856.A28321@keltia.freenix.fr> Date: Sat, 21 Aug 1999 15:41:56 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908211739.LAA20723@mt.sri.com> Nate Williams writes: : Your definition of kernel threads and mine are obviously quite : different. :) True. The kernel "threads" are just process context that a task can run in.... Lots of thread-like things are missing... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 15:14:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FC70153C2 for ; Sat, 21 Aug 1999 15:14:31 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id PAA28200; Sat, 21 Aug 1999 15:11:42 -0700 (PDT) Message-ID: <19990821151142.07786@hydrogen.fircrest.net> Date: Sat, 21 Aug 1999 15:11:42 -0700 From: John-Mark Gurney To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <37BE5F07.3F91A2B8@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <37BE5F07.3F91A2B8@softweyr.com>; from Wes Peters on Sat, Aug 21, 1999 at 02:10:47AM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters scribbled this message on Aug 21: > I discovered to my dismay today that the length field in the mmap call is > a size_t, not an off_t. I was attempting to process a large (~50 MByte) file > and found I was only processing the first 4 MBytes of it. as w/ others I'm assuming the file is 50gigs and you can only use map the first 4gigs... > Is this intentional, or just an artifact of the implementation? Is there any > reason NOT to change this to an off_t? > > Granted, I'm no VM hacker, but I'm willing to take a swing at it if there is > any interest in putting it into the system. Otherwise, I have a workaround > that works just fine for this application. I'm sure that you will find that if you try to map the first 4gigs of the file that it will not fit into memory, and the mapping will fail.. do what you are suppose to do, map 2gigs or so of it (I've mapped 1.8gigs w/o problems before on x86), work with it, then map the next 2gigs and so on... just use the offset to specify where in the file you want to map... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 15:25:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id D984514D11 for ; Sat, 21 Aug 1999 15:25:17 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id PAA28405; Sat, 21 Aug 1999 15:22:20 -0700 (PDT) Message-ID: <19990821152220.30704@hydrogen.fircrest.net> Date: Sat, 21 Aug 1999 15:22:20 -0700 From: John-Mark Gurney To: Nick Hibma Cc: FreeBSD Hackers mailing list Subject: Re: from number to power of two References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Nick Hibma on Sat, Aug 21, 1999 at 12:54:32PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma scribbled this message on Aug 21: > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. > > The only solution I have so far is a table. That is a possibility as the > the highest number will be 32 I think. hmmm.... how about: int fls(int n) { /* courtesy of fortune, of course this is O(lgn) */ /* swap the bits around */ n = ((n >> 1) & 0x55555555) | ((n << 1) & 0xaaaaaaaa); n = ((n >> 2) & 0x33333333) | ((n << 2) & 0xcccccccc); n = ((n >> 4) & 0x0f0f0f0f) | ((n << 4) & 0xf0f0f0f0); n = ((n >> 8) & 0x00ff00ff) | ((n << 8) & 0xff00ff00); n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000); /* mask all but the lowest bit off */ n = n & -n; /* swap them back to where they were originally */ n = ((n >> 1) & 0x55555555) | ((n << 1) & 0xaaaaaaaa); n = ((n >> 2) & 0x33333333) | ((n << 2) & 0xcccccccc); n = ((n >> 4) & 0x0f0f0f0f) | ((n << 4) & 0xf0f0f0f0); n = ((n >> 8) & 0x00ff00ff) | ((n << 8) & 0xff00ff00); n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000); return n; } now this is O(lgn) (where n is number of bits in an int), but I'm not sure how this will perform wrt the other posting.. it probably won't be that fast because of all the arithmetic that happens, and a binary search of the number would probably be faster (which I have implemented a few times)... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 17: 0:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by hub.freebsd.org (Postfix) with ESMTP id 8B4CE14BFF for ; Sat, 21 Aug 1999 17:00:30 -0700 (PDT) (envelope-from a-wada@mars.dti.ne.jp) Received: from a.mars.dti.ne.jp (PPP46.tachikawa-ap4.dti.ne.jp [202.216.255.46]) by smtp2.dti.ne.jp (8.9.3/3.7W) with SMTP id JAA06407; Sun, 22 Aug 1999 09:00:09 +0900 (JST) Message-Id: <199908212359.AA00049@a.mars.dti.ne.jp> From: Akira Wada Date: Sun, 22 Aug 1999 08:59:27 +0900 To: Archie Cobbs Cc: seiwald@perforce.com (Christopher Seiwald), freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? In-Reply-To: <199908210135.SAA48009@bubba.whistle.com> References: <199908210135.SAA48009@bubba.whistle.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote... >Christopher Seiwald writes: >> But as I'm proposing a change to a fairly sensitive piece of code, I'd >> like to keep the change as modest as possible. > >How about this? > >Index: qsort.c >=================================================================== >RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v >retrieving revision 1.7 >diff -u -r1.7 qsort.c >--- qsort.c 1997/02/22 15:03:14 1.7 >+++ qsort.c 1999/08/21 01:35:35 >@@ -153,7 +153,7 @@ > pb += es; > pc -= es; > } >- if (swap_cnt == 0) { /* Switch to insertion sort */ >+ if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ > for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es) > for (pl = pm; pl > (char *)a && cmp(pl - es, pl) > 0; > pl -= es) > > >-Archie I think your modification would avoid the degeneration indicated by Christopher Seiwald, but degrade the advantage for the dataset sorted completely or sorted in reversed order, down to nearly equal for random dataset. I added a routine before selecting pivot to test current partition sorted already and if so, to bypass partitioning. It works well for dataset sorted in order, but doesn't work for dataset in reversed order. I believe a reversed dataset would be partitioned into two subpartitions sorted in order at the 1'st pass of the partitionigs. Is this incorrect ? -------------------------------------------------------------- for qsort.c,v 1.9 1998/06/30 11:05:11 @@ -102,2 +102,5 @@ swap_cnt = 0; + pl = (char *)a; pn = (char *)a + (n - 1) * es; + while (pl < pn && cmp(pl, pl + es) pl += es; + if (pl >= pn) return; if (n < 7) { -------------------------------------------------------------- -Akira Wada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 17:59: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by hub.freebsd.org (Postfix) with ESMTP id 47725150EB for ; Sat, 21 Aug 1999 17:58:58 -0700 (PDT) (envelope-from a-wada@mars.dti.ne.jp) Received: from a.mars.dti.ne.jp (PPP23.tachikawa-ap4.dti.ne.jp [202.216.255.23]) by smtp2.dti.ne.jp (8.9.3/3.7W) with SMTP id JAA08121; Sun, 22 Aug 1999 09:56:25 +0900 (JST) Message-Id: <199908220056.AA00050@a.mars.dti.ne.jp> From: Akira Wada Date: Sun, 22 Aug 1999 09:56:03 +0900 To: Archie Cobbs Cc: seiwald@perforce.com (Christopher Seiwald), freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? In-Reply-To: <199908210135.SAA48009@bubba.whistle.com> References: <199908210135.SAA48009@bubba.whistle.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote... >Christopher Seiwald writes: >> But as I'm proposing a change to a fairly sensitive piece of code, I'd >> like to keep the change as modest as possible. > >How about this? > >Index: qsort.c >=================================================================== >RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v >retrieving revision 1.7 >diff -u -r1.7 qsort.c >--- qsort.c 1997/02/22 15:03:14 1.7 >+++ qsort.c 1999/08/21 01:35:35 >@@ -153,7 +153,7 @@ > pb += es; > pc -= es; > } >- if (swap_cnt == 0) { /* Switch to insertion sort */ >+ if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ > for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es) > for (pl = pm; pl > (char *)a && cmp(pl - es, pl) > 0; > pl -= es) > > >-Archie > >___________________________________________________________________________ >Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > I think your modification would avoid the degeneration indicated by Christopher Seiwald, but degrade the advantage for the dataset sorted completely or sorted in reversed order, down to nearly equal for random dataset. I added a routine before selecting pivot to test current partition sorted already and if so, to bypass partitioning. It works well for dataset sorted in order, but doesn't work for dataset in reversed order. I believe a reversed dataset would be partitioned into two subpartitions sorted in order at the 1'st pass of the partitionings. Is this incorrect ? -------------------------------------------------------------- for qsort.c,v 1.9 1998/06/30 11:05:11 @@ -102,2 +102,5 @@ swap_cnt = 0; + pl = (char *)a; pn = (char *)a + (n - 1) * es; + while (pl < pn && cmp(pl, pl + es) <= 0) pl += es; + if (pl >= pn) return; if (n < 7) { -------------------------------------------------------------- -Akira Wada ***************************************** $BOBED!!IK(B $B!?(B << Akira Wada >> $BEl5~ETJ!@8;TIpB"LnBf(B 1-27-5 $B%k%MJ!@8(B B609 (tel,fax) 042-552-1143 E-mail : a-wada@mars.dti.ne.jp ***************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 18: 6:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id DD3661549B for ; Sat, 21 Aug 1999 18:06:01 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11IM3y-000265-00; Sat, 21 Aug 1999 19:04:47 -0600 Message-ID: <37BF4C99.67814B7@softweyr.com> Date: Sat, 21 Aug 1999 19:04:25 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don Lewis wrote: > > On Aug 21, 2:10am, Wes Peters wrote: > } Subject: mmap mapped segment length > } I discovered to my dismay today that the length field in the mmap call is > } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file > } and found I was only processing the first 4 MBytes of it. > > 50 MB should comfortably fit in a size_t. Oh, duh. Notice the time on my message? Yeah, that's what I get for jumping into a mailing list when I've been up for way too long. > } Is this intentional, or just an artifact of the implementation? Is there any > } reason NOT to change this to an off_t? > > The type of size_t is supposed to be large enough to express the length of > any object that will fit in the virtual address space of a process. Since > a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't > be any advantage to changing mmap() to use a 64 bit wide length parameter, > since you wouldn't be able to access all of such a large object. Obviously. I'm not sure which memory space my HEAD was in last night, the moment I read your message I realized size_t spans 4 GB. Duh. Sorry to embarass myself in such a public manner. Now I've got to go figure out what *I've* screwed up. I fstat the file before mapping it and pass S.st_size as the map length. Is there any reason why mmap would return non-NULL but map less than the requested size? Scratching my head, -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 18:43:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 5678B14BD4 for ; Sat, 21 Aug 1999 18:43:40 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id SAA01537; Sat, 21 Aug 1999 18:42:47 -0700 (PDT) Message-ID: <19990821184246.00134@hydrogen.fircrest.net> Date: Sat, 21 Aug 1999 18:42:46 -0700 From: John-Mark Gurney To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> <37BF4C99.67814B7@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <37BF4C99.67814B7@softweyr.com>; from Wes Peters on Sat, Aug 21, 1999 at 07:04:25PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters scribbled this message on Aug 21: > Now I've got to go figure out what *I've* screwed up. I fstat the file before > mapping it and pass S.st_size as the map length. Is there any reason why > mmap would return non-NULL but map less than the requested size? no, there is NO reason why it wouldn't map the entire 50meg file... I have used ffsrecov w/ a 1.8gig file where I fstat it and map the entire file w/o a problem... also, mmap doesn't return NULL, it returns MAP_FAILED... the code for ffsrecov might give you some hints to make sure you aren't doing anything wrong... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 18:56:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from forbidden.dough.net (forbidden.dough.net [208.24.140.67]) by hub.freebsd.org (Postfix) with ESMTP id 3C6F814D91 for ; Sat, 21 Aug 1999 18:56:14 -0700 (PDT) (envelope-from archon@forbidden.dough.net) Received: (from archon@localhost) by forbidden.dough.net (8.9.3/8.9.3) id UAA23153 for hackers@FreeBSD.ORG; Sat, 21 Aug 1999 20:56:58 -0500 (CDT) (envelope-from archon) Date: Sat, 21 Aug 1999 20:56:58 -0500 From: Dennis Moore To: hackers@FreeBSD.ORG Subject: Re: BSD voice synthesis Message-ID: <19990821205658.A22611@forbidden.dough.net> References: <19990818234031.A58007@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Brian F. Feldman on Wed, Aug 18, 1999 at 03:44:56PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999 at 03:44:56PM -0700, Brian F. Feldman wrote: > On Wed, 18 Aug 1999, Nik Clayton wrote: > > > On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote: > > > Just fetched and compiled the "festival" package. > > > http://www.cstr.ed.ac.uk/projects/festival > > > > Likewise, based on your comments. > > > > Has anyone had any problems with the volume being far too low? > > I cannot get this far. Festival only coredumps when I try to start it > up. Could you send me a description of how I can reproduce your exact > build of Festival? did you compile with SHARED=1 with speech tools? that doesn't work on freebsd. -- ;for (74,1970500640,1634627444,1751478816,1348825708,543711587, 1801810465){for($x=1<<1^1;$x>=1>>1;$x--) {$q=hex ff,$r=oct($x=~s,\d,$&* 10,e,$x),$x/=1/.1,$q<<=$r,$s.=chr (($_&$q)>>$r),$t++}}while(-r$0&&-e$0) {$o=$o?$?:$/;$|=1;print $o?$s:$"x$t if$;;print"\b"x$t;sleep 1} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 21 19: 8:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7378E14D35 for ; Sat, 21 Aug 1999 19:08:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA75507; Sat, 21 Aug 1999 19:08:23 -0700 (PDT) (envelope-from dillon) Date: Sat, 21 Aug 1999 19:08:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199908220208.TAA75507@apollo.backplane.com> To: John-Mark Gurney Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> <37BF4C99.67814B7@softweyr.com> <19990821184246.00134@hydrogen.fircrest.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Wes Peters scribbled this message on Aug 21: :> Now I've got to go figure out what *I've* screwed up. I fstat the file before :> mapping it and pass S.st_size as the map length. Is there any reason why :> mmap would return non-NULL but map less than the requested size? : :no, there is NO reason why it wouldn't map the entire 50meg file... :I have used ffsrecov w/ a 1.8gig file where I fstat it and map the entire :file w/o a problem... : :also, mmap doesn't return NULL, it returns MAP_FAILED... : :the code for ffsrecov might give you some hints to make sure you aren't :doing anything wrong... : :-- : John-Mark Gurney Voice: +1 541 684 8449 : Cu Networking P.O. Box 5693, 97405 I would compile the program -Wall -Wstrict-prototypes. If you get warnings maybe the problem is that you've missed some important #include files. Many system calls take off_t arguments, including mmap, and without the correct prototype the compiler will not generate a good argument stack. mmap'ing a 50MB file definitely works. I run several databases which use mmap() that are several hundred megabytes in size. -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 21 19:48:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 22F8A150FD for ; Sat, 21 Aug 1999 19:48:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA75778; Sat, 21 Aug 1999 19:47:03 -0700 (PDT) (envelope-from dillon) Date: Sat, 21 Aug 1999 19:47:03 -0700 (PDT) From: Matthew Dillon Message-Id: <199908220247.TAA75778@apollo.backplane.com> To: Wes Peters Cc: Don Lewis , hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> <37BF4C99.67814B7@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Now I've got to go figure out what *I've* screwed up. I fstat the file before :mapping it and pass S.st_size as the map length. Is there any reason why :mmap would return non-NULL but map less than the requested size? : :Scratching my head, Note that mmap() returns (void *)-1 when an error occurs, *not* NULL. This is because it is legal to mmap at address 0. -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 21 23:33:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by hub.freebsd.org (Postfix) with ESMTP id 7448E14F99 for ; Sat, 21 Aug 1999 23:33:35 -0700 (PDT) (envelope-from a-wada@mars.dti.ne.jp) Received: from a.mars.dti.ne.jp (PPP24.tachikawa-ap4.dti.ne.jp [202.216.255.24]) by smtp2.dti.ne.jp (8.9.3/3.7W) with SMTP id PAA20711; Sun, 22 Aug 1999 15:33:01 +0900 (JST) Message-Id: <199908220631.AA00053@a.mars.dti.ne.jp> From: Akira Wada Date: Sun, 22 Aug 1999 15:31:53 +0900 To: Archie Cobbs Cc: seiwald@perforce.com (Christopher Seiwald), freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? References: <199908220056.AA00050@a.mars.dti.ne.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Following my previous post: I wrote .. >I believe a reversed dataset would be partitioned >into two subpartitions sorted in order at the 1'st pass of >the partitionings. Is this incorrect ? > Sorry, I'd confirmed BSD qsort's partitioning logic does not guarantee that "a reversed dataset would be partitioned into two subpartitions sorted in order at the 1'st pass of the partitionings". -Akira Wada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message