From owner-freebsd-arch Sun Jun 18 7:20:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from southern-software.com (rosetta.thundercat.com [203.37.173.7]) by hub.freebsd.org (Postfix) with SMTP id CDB4437B556; Sun, 18 Jun 2000 07:19:35 -0700 (PDT) (envelope-from info@southern-software.com) Received: from southern-software.com [198.142.196.124] by southern-software.com (SMTPD32-4.06) id A80EC73A0392; Sun, 18 Jun 2000 00:19:42 PDT From: info@southern-software.com Reply-To: info@southern-software.com To: info@southern-software.com Subject: Can you please assist ? Date: Sun, 18 Jun 2000 00:21:23 PDT Message-Id: <20000618141935.CDB4437B556@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ___________________________________________________________ We are a software development company that specializes in security software. For some time now we have been working on developing a Client email program that contains security features never before available. In order for us to make this program the best that it can possibly be, we ask your assistance by taking a few minutes to answer these important questions for us. Which of the following functions do you consider to be important or essential for an email program? For questions 1-7, please rate 1-5. (1 being the least important and 5 being most important). A client email program should have: Question 1: The ability to prevent certain attachments that may possibly be carrying a virus. (This allows you to accept only safe attachments) Importance Rating______ Question 2: Automatic searching for file attachments that have been renamed or tampered with. (Virus senders can rename vbs files to txt files hoping you will open them) Importance Rating______ Question 3: The ability to limit the size of incoming email and attachments. (Reduce time wasted downloading large files, graphics, audio files, jokes, etc.) Importance Rating______ Question 4: The ability to select the size of outgoing emails and attachments. (Saves bandwidth as large files are roughly doubled when transferred by email). Importance Rating______ Question 5: An encrypted Address Book. (This will stop worm viruses sending copies of itself to your clients and/or friends). Importance Rating______ Question 6: The ability to restrict the number of attachments and size of attachments sent or received. And the ability to the restrict types of attachments received. (Gives control to employers and eliminate privacy issues arising). Importance Rating______ Question 7: A viewable log file containing information such as; email deleted without being opened, when email was downloaded, when email was read (opened), if email was forwarded or replied to etc. (Mail management and accountability at a glance) Importance Rating______ Question 8: Has your company been the victim of a computer virus attack? Yes/No ________ Question 9: If yes to question 8, approximately how many hours did it take to fix the problem? Hours ________ Question 10: If an email program was developed with the above security features, would you be interested in trialing a free demonstration version? Yes/No ________ Question 11: What percentage of email traffic is personal email? __________% We sincerely thank you for your time in answering these important questions for us. Sincere thanks, Graeme A. Ryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 10:15:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D3B7937B53B for ; Sun, 18 Jun 2000 10:15:37 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA07135 for ; Sun, 18 Jun 2000 13:15:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 18 Jun 2000 13:15:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Extended attribute interfaces (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2131519597-961348536=:6424" Content-ID: Sender: owner-freebsd-arch@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-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Just to let people know, a discussion of extended attributes interfaces is about to take place on the POSIX.1e mailing list, in light of the recent workshop I attended at SGI to discuss portability in trusted operating system extensions. I've included the only message so far (mine) below for those interested in getting a sense of what will be discussed. You can subscribe to the list by sending "susbcribe posix1e" to majordomo@cyrus.watson.org. This is a cross-platform mailing list, with members of the HP/UX, Solaris, FreeBSD/TrustedBSD, IRIX, and Linux security worlds. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Sun, 18 Jun 2000 12:50:25 -0400 (EDT) From: Robert Watson To: posix1e@cyrus.watson.org Cc: Marius Bendiksen Subject: Extended attribute interfaces (this message is CC'd to Marius Bendiksen, who is working on new file system implementations, but is not subscribed to the POSIX.1e list, but probably should be as we talk about a lot of file system feature issues :-) Sorry to all for the long delay in doing this -- Andreas and I have been bantering around extended attribute interfaces for a while, and I dropped the ball on getting back to him with further discussion. As he now has an implementation, and we had the workshop at SGI, I figure now is a good time to try and find the ball I dropped, and propose we discuss, and preferably pseudo-standardize, interfaces for extended attribute access. Having the same interface on relevant platforms will make a big difference. I've attached six manual pages for components of the FreeBSD extended attribute interface. They are largely in sync with the implementation. VOP_GETEXTATTR.9.txt Kernel VFS interface to get extended attributes VOP_SETEXTATTR.9.txt Kernel VFS interface to set/remove ea's extattr.9.txt Kernel VFS introduction to ea's extattrctl.8.txt Userland FFS-specific ea initialization getextattr.8.txt Userland generic ea-fetching tool setextattr.8.txt Userland generic ea-setting tool Notable missings from the list would be syscall man pages, which are not yet written. However, here are the syscalls from the FreeBSD 5.0 syscall definition file, used to dynamically build kernel and libc stubs: 355 STD BSD { int extattrctl(const char *path, int cmd, \ const char *attrname, char *arg); } 356 STD BSD { int extattr_set_file(const char *path, \ const char *attrname, struct iovec *iovp, \ unsigned iovcnt); } 357 STD BSD { int extattr_get_file(const char *path, \ const char *attrname, struct iovec *iovp, \ unsigned iovcnt); } 358 STD BSD { int extattr_delete_file(const char *path, \ const char *attrname); } As before, extattrctl is FFS-specific, and used to prepare attribute backing files for the current implementation. extattr_set_file() accepts a path, null-terminate attribute name, and scatter-gather iovec of data to set. As with the VOP, this call replaces the current data present. extattr_get_file() does much the same, except it gets the attribute present. extattr_delete_file() delets an attribute from a file. Open points of discussion include: 1) Ability to retrieve list of attributes on a file or directory -- presumably something dirent-like, but I'd like to hear about what both the SGI folk and Andreas implemented, as there are many ways to do this (and I have implemented none of them :-). Retriving is useful for backups (probably only in the application namespace, see below). 2) Error value for non-present extended attribute. Currently I'm using ENOENT, which is blatently confusing and improper :-). There has been discussion of introducing a new error value, probably EEXTATTR or ENOATTR, both of which seem decent. 3) Namespace issues. The SGI implementation has two namespaces -- root and user. Properly speaking, I feel it should be "system" and "application", but I like the idea of seperate namespaces to distinguish application use from system use (security labels, for example). Ted also expressed concerns about exposing application extended attributes to userland, and I agree that there is the potential for some problems here. Seperate namespaces would allow, say, the Linux community to only permit system attributes and return an error for application ones :-). That said, the Trusted IRIX programmer's guide suggests a good use of application extended attributes for shared spool directories. Adding an additional argument for namespace control would make sense. However, what does this mean for file systems that don't currently have namespaces like that (HPFS, for example). My feeling is that for backup, also, backup programs should touch only the application namespace, retrieving system namespace stuff through appropriate ACL, capability, etc, APIs. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="VOP_GETEXTATTR.9.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpWT1BfR0VURVhUQVRUUig5KSAgICAgIEZyZWVCU0QgS2VybmVsIERldmVs b3BlcidzIE1hbnVhbCAgICAgVk9QX0dFVEVYVEFUVFIoOSkNCg0KTghOQQhB TQhNRQhFDQogICAgIFYIVk8IT1AIUF8IX0cIR0UIRVQIVEUIRVgIWFQIVEEI QVQIVFQIVFIIUiAtIFJldHJpZXZlIG5hbWVkIGV4dGVuZGVkIGF0dHJpYnV0 ZSBmcm9tIGEgdm5vZGUNCg0KUwhTWQhZTghOTwhPUAhQUwhTSQhJUwhTDQog ICAgICMII2kIaW4IbmMIY2wIbHUIdWQIZGUIZSA8CDxzCHN5CHlzCHMvCC9w CHBhCGFyCHJhCGFtCG0uCC5oCGg+CD4NCiAgICAgIwgjaQhpbghuYwhjbAhs dQh1ZAhkZQhlIDwIPHMIc3kIeXMIcy8IL3YIdm4Ibm8Ib2QIZGUIZS4ILmgI aD4IPg0KICAgICAjCCNpCGluCG5jCGNsCGx1CHVkCGRlCGUgPAg8cwhzeQh5 cwhzLwgvZQhleAh4dAh0YQhhdAh0dAh0cghyLgguaAhoPgg+DQoNCiAgICAg XwhpXwhuXwh0DQogICAgIFYIVk8IT1AIUF8IX0cIR0UIRVQIVEUIRVgIWFQI VEEIQVQIVFQIVFIIUihfCHNfCHRfCHJfCHVfCGNfCHQgXwh2XwhuXwhvXwhk XwhlIF8IKl8Idl8IcCwgXwhjXwhoXwhhXwhyIF8IKl8Ibl8IYV8IbV8IZSwg XwhzXwh0XwhyXwh1XwhjXwh0IF8IdV8IaV8IbyBfCCpfCHVfCGlfCG8sDQoJ ICAgICBfCHNfCHRfCHJfCHVfCGNfCHQgXwh1XwhjXwhyXwhlXwhkIF8IKl8I Y18Icl8IZV8IZCwgXwhzXwh0XwhyXwh1XwhjXwh0IF8IcF8Icl8Ib18IYyBf CCpfCHApDQoNCkQIREUIRVMIU0MIQ1IIUkkISVAIUFQIVEkISU8IT04ITg0K ICAgICBUaGlzIHZub2RlIGNhbGwgbWF5IGJlIHVzZWQgdG8gcmV0cmlldmUg YSBzcGVjaWZpYyBuYW1lZCBleHRlbmRlZCBhdC0NCiAgICAgdHJpYnV0ZSBm cm9tIGEgZmlsZSBvciBkaXJlY3RvcnkuDQoNCiAgICAgSXRzIGFyZ3VtZW50 cyBhcmU6DQoNCiAgICAgXwh2XwhwICAgIHRoZSB2bm9kZSBvZiB0aGUgZmls ZSBvciBkaXJlY3RvcnkNCg0KICAgICBfCG5fCGFfCG1fCGUgIHBvaW50ZXIg dG8gYSBudWxsLXRlcm1pbmF0ZWQgY2hhcmFjdGVyIHN0cmluZyBjb250YWlu aW5nIHRoZSBhdC0NCgkgICB0cmlidXRlIG5hbWUNCg0KICAgICBfCHVfCGlf CG8gICB0aGUgbG9jYXRpb24gb2YgdGhlIGRhdGEgdG8gYmUgcmVhZCBvciB3 cml0dGVuDQoNCiAgICAgXwhjXwhyXwhlXwhkICB0aGUgdXNlciBjcmVkZW50 aWFscyB0byB1c2UgaW4gYXV0aG9yaXppbmcgdGhlIHJlcXVlc3QNCg0KICAg ICBfCHAJICAgdGhlIHByb2Nlc3MgcmVxdWVzdGluZyB0aGUgZXh0ZW5kZWQg YXR0cmlidXRlDQoNCiAgICAgVGhlIF8IY18Icl8IZV8IZCBwb2ludGVyIG1h eSBiZSBOVUxMIHRvIGluZGljYXRlIHRoYXQgYWNjZXNzIGNvbnRyb2wgY2hl Y2tzIGFyZQ0KICAgICBub3QgdG8gYmUgcGVyZm9ybWVkLCBvZiBwb3NzaWJs ZS4JVGhpcyBjcmVkIHNldHRpbmcgbWlnaHQgYmUgdXNlZCB0byBhbC0NCiAg ICAgbG93IHRoZSBrZXJuZWwgdG8gYXV0aG9yaXplIGV4dGVuZGVkIGF0dHJp YnV0ZSByZXRyaWV2YWwgdGhhdCB0aGUgYWN0aXZlDQogICAgIHByb2Nlc3Mg bWlnaHQgbm90IGJlIHBlcm1pdHRlZCB0byBkby4NCg0KICAgICBFeHRlbmRl ZCBhdHRyaWJ1dGUgc2VtYW50aWNzIG1heSB2YXJ5IGJ5IGZpbGUgc3lzdGVt IGltcGxlbWVudGluZyB0aGUNCiAgICAgY2FsbC4gIE1vcmUgaW5mb3JtYXRp b24gb24gZXh0ZW5kZWQgYXR0cmlidXRlcyBtYXkgYmUgZm91bmQgaW4NCiAg ICAgZXh0YXR0cig5KS4NCg0KTAhMTwhPQwhDSwhLUwhTDQogICAgIE5vIGxv Y2tzIGFyZSByZXF1aXJlZCB0byBjYWxsIHRoaXMgdm5vZGUgbWV0aG9kLCBh bmQgYW55IGxvY2tzIGhlbGQgb24NCiAgICAgZW50cnkgd2lsbCBiZSBoZWxk IG9uIGV4aXQuDQoNClIIUkUIRVQIVFUIVVIIUk4ITiBWCFZBCEFMCExVCFVF CEVTCFMNCiAgICAgT24gc3VjY2VzcywgemVybyB3aWxsIGJlIHJldHVybmVk LCBhbmQgdGhlIHVpbyBzdHJ1Y3R1cmUgd2lsbCBiZSB1cGRhdGVkDQogICAg IHRvIHJlZmxlY3QgZGF0YSByZWFkLiAgT3RoZXJ3aXNlLCBhbiBhcHByb3By aWF0ZSBlcnJvciBjb2RlIGlzIHJldHVybmVkLg0KDQpFCEVSCFJSCFJPCE9S CFJTCFMNCiAgICAgW0VOT0VOVF0JCVRoZSBhdHRyaWJ1dGUgbmFtZSBpcyBu b3QgZGVmaW5lZCBmb3IgdGhpcyB2bm9kZQ0KDQogICAgIFtFQUNDRVNdCQlQ ZXJtaXNzaW9uIGRlbmllZA0KDQogICAgIFtFTlhJT10JCVRoZSByZXF1ZXN0 IHdhcyBub3QgdmFsaWQgaW4gdGhpcyBmaWxlIHN5c3RlbSBmb3IgdGhlDQoJ CQlzcGVjaWZpZWQgdm5vZGUgYW5kIGF0dHJpYnV0ZSBuYW1lLg0KDQogICAg IFtFTk9NRU1dCQlJbnN1ZmZpY2llbnQgbWVtb3J5IGF2YWlsYWJsZSB0byBm dWxmaWxsIHJlcXVlc3QNCg0KICAgICBbRUZBVUxUXQkJVGhlIHVpbyBzdHJ1 Y3R1cmUgcmVmZXJzIHRvIGFuIGludmFsaWQgdXNlcnNwYWNlIGFkLQ0KCQkJ ZHJlc3MuDQoNCiAgICAgW0VJTlZBTF0JCVRoZSBfCG5fCGFfCG1fCGUgb3Ig Xwh1XwhpXwhvIGFyZ3VtZW50IGlzIGludmFsaWQuDQoNCiAgICAgW0VPUE5P VFNVUFBdCVRoZSBmaWxlIHN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IFZPUF9H RVRFWFRBVFRSDQoNClMIU0UIRUUIRSBBCEFMCExTCFNPCE8NCiAgICAgZXh0 YXR0cig5KSwgIHZub2RlKDkpLCAgVk9QX1NFVEVYVEFUVFIoOSkNCg0KQlNE CQkJICAgICAgIERlY2VtYmVyIDIzLCAxOTk5CQkJICAgICAyDQo= --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="VOP_SETEXTATTR.9.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpWT1BfU0VURVhUQVRUUig5KSAgICAgIEZyZWVCU0QgS2VybmVsIERldmVs b3BlcidzIE1hbnVhbCAgICAgVk9QX1NFVEVYVEFUVFIoOSkNCg0KTghOQQhB TQhNRQhFDQogICAgIFYIVk8IT1AIUF8IX1MIU0UIRVQIVEUIRVgIWFQIVEEI QVQIVFQIVFIIUiAtIFNldCBuYW1lZCBleHRlbmRlZCBhdHRyaWJ1dGUgZm9y IGEgdm5vZGUNCg0KUwhTWQhZTghOTwhPUAhQUwhTSQhJUwhTDQogICAgICMI I2kIaW4IbmMIY2wIbHUIdWQIZGUIZSA8CDxzCHN5CHlzCHMvCC9wCHBhCGFy CHJhCGFtCG0uCC5oCGg+CD4NCiAgICAgIwgjaQhpbghuYwhjbAhsdQh1ZAhk ZQhlIDwIPHMIc3kIeXMIcy8IL3YIdm4Ibm8Ib2QIZGUIZS4ILmgIaD4IPg0K ICAgICAjCCNpCGluCG5jCGNsCGx1CHVkCGRlCGUgPAg8cwhzeQh5cwhzLwgv ZQhleAh4dAh0YQhhdAh0dAh0cghyLgguaAhoPgg+DQoNCiAgICAgXwhpXwhu Xwh0DQogICAgIFYIVk8IT1AIUF8IX1MIU0UIRVQIVEUIRVgIWFQIVEEIQVQI VFQIVFIIUihfCHNfCHRfCHJfCHVfCGNfCHQgXwh2XwhuXwhvXwhkXwhlIF8I Kl8Idl8IcCwgXwhjXwhoXwhhXwhyIF8IKl8Ibl8IYV8IbV8IZSwgXwhzXwh0 XwhyXwh1XwhjXwh0IF8IdV8IaV8IbyBfCCpfCHVfCGlfCG8sDQoJICAgICBf CHNfCHRfCHJfCHVfCGNfCHQgXwh1XwhjXwhyXwhlXwhkIF8IKl8IY18Icl8I ZV8IZCwgXwhzXwh0XwhyXwh1XwhjXwh0IF8IcF8Icl8Ib18IYyBfCCpfCHAp DQoNCkQIREUIRVMIU0MIQ1IIUkkISVAIUFQIVEkISU8IT04ITg0KICAgICBU aGlzIHZub2RlIGNhbGwgbWF5IGJlIHVzZWQgdG8gc2V0IHNwZWNpZmljIG5h bWVkIGV4dGVuZGVkIGF0dHJpYnV0ZSBmb3INCiAgICAgYSBmaWxlIG9yIGRp cmVjdG9yeS4NCg0KICAgICBJdHMgYXJndW1lbnRzIGFyZToNCg0KICAgICBf CHZfCHAgICAgdGhlIHZub2RlIG9mIHRoZSBmaWxlIG9yIGRpcmVjdG9yeQ0K DQogICAgIF8Ibl8IYV8IbV8IZSAgcG9pbnRlciB0byBhIG51bGwtdGVybWlu YXRlZCBjaGFyYWN0ZXIgc3RyaW5nIGNvbnRhaW5pbmcgdGhlIGF0LQ0KCSAg IHRyaWJ1dGUgbmFtZQ0KDQogICAgIF8IdV8IaV8IbyAgIHRoZSBsb2NhdGlv biBvZiB0aGUgZGF0YSB0byBiZSByZWFkIG9yIHdyaXR0ZW4NCg0KICAgICBf CGNfCHJfCGVfCGQgIHRoZSB1c2VyIGNyZWRlbnRpYWxzIHRvIHVzZSBpbiBh dXRob3JpemluZyB0aGUgcmVxdWVzdA0KDQogICAgIF8IcAkgICB0aGUgcHJv Y2VzcyBzZXR0aW5nIHRoZSBleHRlbmRlZCBhdHRyaWJ1dGUNCg0KICAgICBU aGUgdWlvIHN0cnVjdHVyZSBpcyB1c2VkIGluIGEgbWFubmVyIHNpbWlsYXIg dG8gdGhlIGFyZ3VtZW50IG9mIHRoZSBzYW1lDQogICAgIG5hbWUgaW4gVk9Q X1dSSVRFLiAgSG93ZXZlciwgYXMgZXh0ZW5kZWQgYXR0cmlidXRlcyBwcm92 aWRlIGEgc3RyaWN0DQogICAgICJuYW1lPXZhbHVlIiBzZW1hbnRpYywgbm9u LXplcm8gb2Zmc2V0cyB3aWxsIGJlIHJlamVjdGVkLg0KDQogICAgIFRoZSBf CHVfCGlfCG8gcG9pbnRlciBtYXkgYmUgTlVMTCB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBzcGVjaWZpZWQgZXh0ZW5kZWQgYXQtDQogICAgIHRyaWJ1dGUgc2hv dWxkIGJlIGRlbGV0ZWQuDQoNCiAgICAgVGhlIF8IY18Icl8IZV8IZCBwb2lu dGVyIG1heSBiZSBOVUxMIHRvIGluZGljYXRlIHRoYXQgYWNjZXNzIGNvbnRy b2wgY2hlY2tzIGFyZQ0KICAgICBub3QgdG8gYmUgcGVyZm9ybWVkLCBvZiBw b3NzaWJsZS4JVGhpcyBjcmVkIHNldHRpbmcgbWlnaHQgYmUgdXNlZCB0byBh bC0NCiAgICAgbG93IHRoZSBrZXJuZWwgdG8gYXV0aG9yaXplIGV4dGVuZGVk IGF0dHJpYnV0ZSBjaGFuZ2VzIHRoYXQgdGhlIGFjdGl2ZQ0KICAgICBwcm9j ZXNzIG1pZ2h0IG5vdCBiZSBwZXJtaXR0ZWQgdG8gbWFrZS4NCg0KICAgICBF eHRlbmRlZCBhdHRyaWJ1dGUgc2VtYW50aWNzIG1heSB2YXJ5IGJ5IGZpbGUg c3lzdGVtIGltcGxlbWVudGluZyB0aGUNCiAgICAgY2FsbC4gIE1vcmUgaW5m b3JtYXRpb24gb24gZXh0ZW5kZWQgYXR0cmlidXRlcyBtYXkgYmUgZm91bmQg aW4NCiAgICAgZXh0YXR0cig5KS4NCg0KTAhMTwhPQwhDSwhLUwhTDQogICAg IFRoZSB2bm9kZSB3aWxsIGJlIGxvY2tlZCBvbiBlbnRyeSBhbmQgc2hvdWxk IHJlbWFpbiBsb2NrZWQgb24gcmV0dXJuLg0KDQpSCFJFCEVUCFRVCFVSCFJO CE4gVghWQQhBTAhMVQhVRQhFUwhTDQogICAgIElmIHRoZSBleHRlbmRlZCBh dHRyaWJ1dGUgaXMgc3VjY2Vzc2Z1bGx5IHNldCwgdGhlbiB6ZXJvIGlzIHJl dHVybmVkLg0KICAgICBPdGhlcndpc2UsIGFuIGFwcHJvcHJpYXRlIGVycm9y IGNvZGUgaXMgcmV0dXJuZWQuDQoNCkUIRVIIUlIIUk8IT1IIUlMIUw0KICAg ICBbRUFDQ0VTXQkJUGVybWlzc2lvbiBkZW5pZWQNCg0KICAgICBbRU5YSU9d CQlUaGUgcmVxdWVzdCB3YXMgbm90IHZhbGlkIGluIHRoaXMgZmlsZSBzeXN0 ZW0gZm9yIHRoZQ0KCQkJc3BlY2lmaWVkIHZub2RlIGFuZCBhdHRyaWJ1dGUg bmFtZS4NCg0KICAgICBbRU5PTUVNXQkJSW5zdWZmaWNpZW50IG1lbW9yeSBh dmFpbGFibGUgdG8gZnVsZmlsbCByZXF1ZXN0DQoNCiAgICAgW0VGQVVMVF0J CVRoZSB1aW8gc3RydWN0dXJlIHJlZmVycyB0byBhbiBpbnZhbGlkIHVzZXJz cGFjZSBhZC0NCg0KCQkJZHJlc3MNCg0KICAgICBbRUlOVkFMXQkJVGhlIG5h bWUgb3IgdWlvIGFyZ3VtZW50IGlzIGludmFsaWQNCg0KICAgICBbRU9QTk9U U1VQUF0JVGhlIGZpbGUgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgVk9QX0dF VEVYVEFUVFINCg0KICAgICBbRU5PU1BDXQkJVGhlIGZpbGUgc3lzdGVtIGlz IG91dCBvZiBzcGFjZQ0KDQogICAgIFtFUk9GU10JCVRoZSBmaWxlIHN5c3Rl bSBpcyByZWFkLW9ubHkNCg0KUwhTRQhFRQhFIEEIQUwITFMIU08ITw0KICAg ICBleHRhdHRyKDkpLCAgdm5vZGUoOSksICBWT1BfR0VURVhUQVRUUig5KQ0K DQpBCEFVCFVUCFRICEhPCE9SCFJTCFMNCiAgICAgVGhpcyBtYW4gcGFnZSB3 YXMgd3JpdHRlbiBieSBSb2JlcnQgV2F0c29uLg0KDQpCU0QJCQkgICAgICAg RGVjZW1iZXIgMjMsIDE5OTkJCQkgICAgIDINCg== --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="extattr.9.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpFWFRBVFRSKDkpCSAgICAgICBGcmVlQlNEIEtlcm5lbCBEZXZlbG9wZXIn cyBNYW51YWwJICAgIEVYVEFUVFIoOSkNCg0KTghOQQhBTQhNRQhFDQogICAg IGUIZXgIeHQIdGEIYXQIdHQIdHIIciAtIHZpcnR1YWwgZmlsZSBzeXN0ZW0g bmFtZWQgZXh0ZW5kZWQgYXR0cmlidXRlcw0KDQpTCFNZCFlOCE5PCE9QCFBT CFNJCElTCFMNCiAgICAgIwgjaQhpbghuYwhjbAhsdQh1ZAhkZQhlIDwIPHMI c3kIeXMIcy8IL3AIcGEIYXIIcmEIYW0IbS4ILmgIaD4IPg0KICAgICAjCCNp CGluCG5jCGNsCGx1CHVkCGRlCGUgPAg8cwhzeQh5cwhzLwgvdgh2bghubwhv ZAhkZQhlLgguaAhoPgg+DQogICAgICMII2kIaW4IbmMIY2wIbHUIdWQIZGUI ZSA8CDxzCHN5CHlzCHMvCC9lCGV4CHh0CHRhCGF0CHR0CHRyCHIuCC5oCGg+ CD4NCg0KRAhERQhFUwhTQwhDUghSSQhJUAhQVAhUSQhJTwhPTghODQogICAg IE5hbWVkIGV4dGVuZGVkIGF0dHJpYnV0ZXMgYWxsb3cgYWRkaXRpb25hbCBt ZXRhLWRhdGEgdG8gYmUgYXNzb2NpYXRlZA0KICAgICB3aXRoIHZub2RlcyBy ZXByZXNlbnRpbmcgZmlsZXMgYW5kIGRpcmVjdG9yaWVzLiAgVGhlIHNlbWFu dGljcyBvZiB0aGlzDQogICAgIGFkZGl0aW9uYWwgZGF0YSBpcyB0aGF0IG9m IGEgIm5hbWU9dmFsdWUiIHBhaXIsIHdoZXJlIGEgbmFtZSBtYXkgYmUgZGUt DQogICAgIGZpbmVkIG9yIHVuZGVmaW5lZCwgYW5kIGlmIGRlZmluZWQsIGFz c29jaWF0ZWQgd2l0aCB6ZXJvIG9yIG1vcmUgYnl0ZXMgb2YNCiAgICAgYXJi aXRyYXJ5IGJpbmFyeSBkYXRhLiAgUmVhZHMgb2YgdGhpcyBkYXRhIG1heSBy ZXR1cm4gc3BlY2lmaWMgY29udGlndW91cw0KICAgICByZWdpb25zIG9mIHRo ZSBtZXRhLWRhdGEsIGluIHRoZSBzdHlsZSBvZiBWT1BfUkVBRCg5KSwgIGJ1 dCB3cml0ZXMgd2lsbA0KICAgICByZXBsYWNlIHRoZSBlbnRpcmUgY3VycmVu dCAidmFsdWUiIGFzc29jaWF0ZWQgd2l0aCBhIGdpdmVuIG5hbWUuICBBcw0K ICAgICB0aGVyZSBhcmUgYSBwbGV0aG9yYSBvZiBmaWxlIHN5c3RlbXMgd2l0 aCBkaWZmZXJpbmcgZXh0ZW5kZWQgYXR0cmlidXRlcywNCiAgICAgYXZhaWxh YmlsaXR5IGFuZCBmdW5jdGlvbmFsaXR5IG9mIHRoZXNlIGZ1bmN0aW9ucyBt YXkgYmUgbGltaXRlZCwgYW5kDQogICAgIHRoZXkgc2hvdWxkIGJlIHVzZWQg d2l0aCBhd2FyZW5lc3Mgb2YgdGhlIHVuZGVybHlpbmcgc2VtYW50aWNzIG9m IHRoZQ0KICAgICBzdXBwb3J0aW5nIGZpbGUgc3lzdGVtLiAgQXV0aG9yaXph dGlvbiBzY2hlbWVzIGZvciBleHRlbmRlZCBhdHRyaWJ1dGUgZGEtDQogICAg IHRhIG1heSBhbHNvIHZhcnkgYnkgZmlsZSBzeXN0ZW0sIGFzIHdlbGwgYXMg bWF4aW11bSBhdHRyaWJ1dGUgc2l6ZSwgYW5kDQogICAgIHdoZXRoZXIgb3Ig bm90IGFueSBvciBzcGVjaWZpYyBuZXcgYXR0cmlidXRlcyBtYXkgYmUgZGVm aW5lZC4NCg0KICAgICBFeHRlbmRlZCBhdHRyaWJ1dGVzIGFyZSBuYW1lZCB1 c2luZyBhIG51bGwtdGVybWluYXRlZCBjaGFyYWN0ZXIgc3RyaW5nLg0KICAg ICBEZXBlbmRpbmcgb24gZmlsZSBzeXN0ZW0gc2VtYW50aWNzLCB0aGlzIG5h bWUgbWF5IG9yIG1heSBub3QgYmUgY2FzZS1zZW4tDQogICAgIHNpdGl2ZS4g IEFwcHJvcHJpYXRlIHZub2RlIGV4dGVuZGVkIGF0dHJpYnV0ZSBjYWxscyBh cmU6IFZPUF9HRVRFWFRBVC0NCiAgICAgVFIoOSkgYW5kIFZPUF9TRVRFWFRB VFRSKDkpLg0KDQpTCFNFCEVFCEUgQQhBTAhMUwhTTwhPDQogICAgIFZGUyg5 KSwgIFZPUF9HRVRFWFRBVFRSKDkpLCAgVk9QX1NFVEVYVEFUVFIoOSkuDQoN CkEIQVUIVVQIVEgISE8IT1IIUlMIUw0KICAgICBUaGlzIG1hbiBwYWdlIHdh cyB3cml0dGVuIGJ5IFJvYmVydCBXYXRzb24uDQoNCkJTRAkJCSAgICAgICBE ZWNlbWJlciAyMywgMTk5OQkJCSAgICAgMQ0K --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="extattrctl.8.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpFWFRBVFRSQ1RMKDgpCQlGcmVlQlNEIFN5c3RlbSBNYW5hZ2VyJ3MgTWFu dWFsIAkgRVhUQVRUUkNUTCg4KQ0KDQpOCE5BCEFNCE1FCEUNCiAgICAgZQhl eAh4dAh0YQhhdAh0dAh0cghyYwhjdAh0bAhsIC0gbWFuYWdlIEZGUyBleHRl bmRlZCBhdHRyaWJ1dGVzDQoNClMIU1kIWU4ITk8IT1AIUFMIU0kISVMIUw0K ICAgICBlCGV4CHh0CHRhCGF0CHR0CHRyCHJjCGN0CHRsCGwgcwhzdAh0YQhh cghydAh0IF8IcF8IYV8IdF8IaA0KICAgICBlCGV4CHh0CHRhCGF0CHR0CHRy CHJjCGN0CHRsCGwgcwhzdAh0bwhvcAhwIF8IcF8IYV8IdF8IaA0KICAgICBl CGV4CHh0CHRhCGF0CHR0CHRyCHJjCGN0CHRsCGwgaQhpbghuaQhpdAh0YQhh dAh0dAh0cghyIF8IYV8IdF8IdF8Icl8Ic18IaV8Iel8IZSBfCGFfCHRfCHRf CHJfCGZfCGlfCGxfCGUNCiAgICAgZQhleAh4dAh0YQhhdAh0dAh0cghyYwhj dAh0bAhsIGUIZW4IbmEIYWIIYmwIbGUIZSBfCHBfCGFfCHRfCGggXwhhXwh0 Xwh0XwhyXwhuXwhhXwhtXwhlIF8IYV8IdF8IdF8Icl8IZl8IaV8IbF8IZQ0K ICAgICBlCGV4CHh0CHRhCGF0CHR0CHRyCHJjCGN0CHRsCGwgZAhkaQhpcwhz YQhhYghibAhsZQhlIF8IcF8IYV8IdF8IaCBfCGFfCHRfCHRfCHJfCG5fCGFf CG1fCGUNCg0KRAhERQhFUwhTQwhDUghSSQhJUAhQVAhUSQhJTwhPTghODQog ICAgIGUIZXgIeHQIdGEIYXQIdHQIdHIIcmMIY3QIdGwIbCBpcyB0aGUgbWFu YWdlbWVudCB1dGlsaXR5IGZvciBleHRlbmRlZCBhdHRyaWJ1dGVzIG92ZXIg dGhlIEZGUw0KICAgICBmaWxlIHN5c3RlbS4gIGUIZXgIeHQIdGEIYXQIdHQI dHIIcmMIY3QIdGwIbCBhbGxvd3MgdGhlIHN0YXJ0aW5nIGFuZCBzdG9wcGlu ZyBvZiBleHRlbmRlZCBhdC0NCiAgICAgdHJpYnV0ZXMgb24gYSBmaWxlIHN5 c3RlbSwgYXMgd2VsbCBhcyBpbml0aWFsaXphdGlvbiBvZiBhdHRyaWJ1dGUg YmFja2luZw0KICAgICBmaWxlcywgYW5kIGVuYWJsaW5nIGFuZCBkaXNhYmxp bmcgb2Ygc3BlY2lmaWMgZXh0ZW5kZWQgYXR0cmlidXRlcyBvbiBhDQogICAg IGZpbGUgc3lzdGVtLg0KDQogICAgIFRoZSBmaXJzdCBhcmd1bWVudCBvbiB0 aGUgY29tbWFuZCBsaW5lIGluZGljYXRlcyB0aGUgb3BlcmF0aW9uIHRvIGJl IHBlci0NCiAgICAgZm9ybWVuZC4gIE9wZXJhdGlvbiBtdXN0IGJlIG9uZSBv ZiB0aGUgZm9sbG93aW5nOg0KDQogICAgIHMIc3QIdGEIYXIIcnQIdCBfCHBf CGFfCHRfCGgNCgkgICAgIFN0YXJ0IGV4dGVuZGVkIGF0dHJpYnV0ZSBzdXBw b3J0IG9uIHRoZSBmaWxlIHN5c3RlbSBuYW1lZCB1c2luZw0KCSAgICAgXwhw XwhhXwh0XwhoLiBUaGUgZmlsZSBzeXN0ZW0gbXVzdCBiZSBhbiBGRlMgZmls ZSBzeXN0ZW0sIGFuZCB0aGUgRkZTX0VYLQ0KCSAgICAgVEFUVFIga2VybmVs IG9wdGlvbiBtdXN0IGhhdmUgYmVlbiBlbmFibGVkLg0KDQogICAgIHMIc3QI dG8Ib3AIcCBfCHBfCGFfCHRfCGgNCgkgICAgIFN0b3AgZXh0ZW5kZWQgYXR0 cmlidXRlIHN1cHBvcnQgb24gdGhlIGZpbGUgc3lzdGVtIG5hbWVkIHVzaW5n DQoJICAgICBfCHBfCGFfCHRfCGguIEV4dGVuZGVkIGF0dHJpYnV0ZSBzdXBw b3J0IG11c3QgcHJldmlvdXNseSBoYXZlIGJlZW4gc3RhcnQtDQoJICAgICBl ZC4NCg0KICAgICBpCGluCG5pCGl0CHRhCGF0CHR0CHRyCHIgWy0ILXAIcCBf CHBfCGFfCHRfCGhdIFstCC1yCHIgW18Ia18Icl8Ib18IYV1dIFstCC13CHcg W18Ia18Icl8Ib18IYV1dIF8IYV8IdF8IdF8Icl8Ic18IaV8Iel8IZSBfCGFf CHRfCHRfCHJfCGZfCGlfCGxfCGUNCgkgICAgIENyZWF0ZSBhbmQgaW5pdGlh bGl6ZSBhIGZpbGUgdG8gdXNlIGFzIGFuIGF0dHJpYnV0ZSBiYWNraW5nIGZp bGUuDQoJICAgICBZb3UgbXVzdCBzcGVjaWZ5IGEgbWF4aW11bSBwZXItaW5v ZGUgc2l6ZSBmb3IgdGhlIGF0dHJpYnV0ZSBpbg0KCSAgICAgYnl0ZXMgaW4g XwhhXwh0Xwh0XwhyXwhzXwhpXwh6XwhlLCBhcyB3ZWxsIGFzIHRoZSBmaWxl IHdoZXJlIHRoZSBhdHRyaWJ1dGUgd2lsbA0KCSAgICAgYmUgc3RvcmVkLCB1 c2luZyBfCGFfCHRfCHRfCHJfCGZfCGlfCGxfCGUuDQoNCgkgICAgIFRoZSAt CC1wCHAgXwhwXwhhXwh0XwhoIGFyZ3VtZW50IG1heSBiZSB1c2VkIHRvIHBy ZWFsbG9jYXRlIHNwYWNlIGZvciBhbGwgYXQtDQoJICAgICB0cmlidXRlcyBy YXRoZXIgdGhhbiByZWx5aW5nIG9uIHNwYXJzZSBmaWxlcyB0byBjb25zZXJ2 ZSBzcGFjZS4NCgkgICAgIFRoaXMgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZ3Vh cmFudGVlaW5nIHRoYXQgc3BhY2Ugd2lsbCBiZSBhdmFpbC0NCgkgICAgIGFi bGUgZm9yIGF0dHJpYnV0ZXMgd2hlbiB0aGV5IGFyZSB3cml0dGVuLCBwcmV2 ZW50aW5nIGxvdyBkaXNrDQoJICAgICBzcGFjZSBjb25kaXRpb25zIGZyb20g ZGVueWluZyBhdHRyaWJ1dGUgc2VydmljZS4NCg0KCSAgICAgVGhlIC0ILXII ciBhbmQgLQgtdwh3IG9wdGlvbnMgY2FuIGJlIHVzZWQgdG8gc2V0IHRoZSBy ZWFkIGFuZCB3cml0ZSBwZXItDQoJICAgICBtaXNzaW9ucyBvbiB0aGUgbmFt ZWQgYXR0cmlidXRlLCByZXNwZWN0aXZlbHkuICBUaGVyZSBhcmUgZm91cg0K CSAgICAgbGV2ZWxzIHBvc3NpYmxlIGZvciBib3RoIHJlYWQgYW5kIHdyaXRl OiBgYGsnJyBsaW1pdHMgcmVhZGluZyBvcg0KCSAgICAgd3JpdGluZyB0byB0 aGUga2VybmVsLCBgYHInJyBsaW1pdHMgYWN0aXZpdGllcyB0byByb290LCBg YG8nJw0KCSAgICAgbGltaXRzIGFjdGl2aXRpZXMgdG8gcm9vdCBhbmQgdGhl IG93bmVyIG9mIHRoZSBmaWxlIGhhdmluZyB0aGUNCgkgICAgIGF0dHJpYnV0 ZSByZWFkIG9yIHdyaXR0ZW4sIGFuZCBgYHEnJyBhbGxvd3MgYW55IHVzZXIg dG8gcGVyZm9ybQ0KCSAgICAgdGhlIGF0dHJpYnV0ZSBvcGVyYXRpb24uICBU aGUgZGVmYXVsdCBpcyB0byBsaW1pdCBhY3Rpdml0aWVzIHRvDQoJICAgICB0 aGUgcm9vdCB1c2VyLCBvciBgYHInJy4NCg0KCSAgICAgVGhpcyBmaWxlIHNo b3VsZCBub3QgZXhpc3QgYmVmb3JlIHJ1bm5pbmcgaQhpbghuaQhpdAh0YQhh dAh0dAh0cghyLgguDQoNCiAgICAgZQhlbghuYQhhYghibAhsZQhlIF8IcF8I YV8IdF8IaCBfCGFfCHRfCHRfCHJfCG5fCGFfCG1fCGUgXwhhXwh0Xwh0Xwhy XwhmXwhpXwhsXwhlDQoJICAgICBFbmFibGUgYW4gYXR0cmlidXRlIG5hbWVk IF8IYV8IdF8IdF8Icl8Ibl8IYV8IbV8IZSBvbiB0aGUgZmlsZSBzeXN0ZW0g aWRlbnRpZmllZA0KCSAgICAgdXNpbmcgXwhwXwhhXwh0XwhoLCBhbmQgYmFj a2VkIGJ5IGluaXRpYWxpemVkIGF0dHJpYnV0ZSBmaWxlIF8IYV8IdF8IdF8I cl8IZl8IaV8IbF8IZS4NCgkgICAgIFRoZSBiYWNraW5nIGZpbGUgbXVzdCBo YXZlIGJlZW4gaW5pdGlhbGl6ZWQgdXNpbmcgaQhpbghuaQhpdAh0YQhhdAh0 dAh0cghyIGJlZm9yZQ0KCSAgICAgaXRzIGZpcnN0IHVzZS4gIEF0dHJpYnV0 ZXMgbXVzdCBoYXZlIGJlZW4gc3RhcnRlZCBvbiB0aGUgZmlsZQ0KCSAgICAg c3lzdGVtIHByaW9yIHRvIHRoZSBlbmFibGluZyBvZiBhbnkgYXR0cmlidXRl cy4NCg0KICAgICBkCGRpCGlzCHNhCGFiCGJsCGxlCGUgXwhwXwhhXwh0Xwho IF8IYV8IdF8IdF8Icl8Ibl8IYV8IbV8IZQ0KCSAgICAgRGlzYWJsZSB0aGUg YXR0cmlidXRlZCBuYW1lZCBfCGFfCHRfCHRfCHJfCG5fCGFfCG1fCGUgb24g dGhlIGZpbGUgc3lzdGVtIGlkZW50aS0NCgkgICAgIGZpZWQgYnkgXwhwXwhh Xwh0XwhoLiBUaGUgZmlsZSBzeXN0ZW0gbXVzdCBoYXZlIGF0dHJpYnV0ZXMg c3RhcnRlZCBvbiBpdCwNCgkgICAgIGFuZCB0aGUgYXR0cmlidXRlIG1vc3Qg aGF2ZSBiZWVuIGVuYWJsZWQgdXNpbmcgZQhlbghuYQhhYghibAhsZQhlLg0K DQpFCEVYCFhBCEFNCE1QCFBMCExFCEVTCFMNCgkgICBleHRhdHRyY3RsIHN0 YXJ0IC8NCg0KICAgICBTdGFydCBleHRlbmRlZCBhdHRyaWJ1dGVzIG9uIHRo ZSByb290IGZpbGUgc3lzdGVtLg0KDQoJICAgZXh0YXR0cmN0bCBpbml0YXR0 ciAxNyAvLmF0dHJpYnV0ZS9tZDUNCg0KICAgICBDcmVhdGUgYW4gYXR0cmli dXRlIGJhY2tpbmcgZmlsZSBpbiAvLmF0dHJpYnV0ZS9tZDUsIGFuZCBzZXQg dGhlIG1heGltdW0NCiAgICAgc2l6ZSBvZiBlYWNoIGF0dHJpYnV0ZSB0byAx NyBieXRlcy4gIFNwYXJzZSBmaWxlcyBhcmUgdXNlZCBmb3Igc3RvcmluZw0K ICAgICB0aGUgYXR0cmlidXRlcywgYW5kIHRoZSBkZWZhdWx0IHBlcm1pc3Np b25zIGxpbWl0aW5nIGFjY2VzcyB0byB0aGUgcm9vdA0KICAgICB1c2VyIGFy ZSBpbXBsaWVkLg0KDQoJICAgZXh0YXR0cmN0bCBlbmFibGUgLyBtZDUgLy5h dHRyaWJ1dGUvbWQ1DQoNCiAgICAgRW5hYmxlIGFuIGF0dHJpYnV0ZSBuYW1l ZCBtZDUgb24gdGhlIHJvb3QgZmlsZSBzeXN0ZW0sIGJhY2tlZCBmcm9tIHRo ZQ0KICAgICBmaWxlIC8uYXR0cmlidXRlL21kNS4NCg0KCSAgIGV4dGF0dHJj dGwgZGlzYWJsZSAvIG1kNQ0KDQogICAgIERpc2FibGUgdGhlIGF0dHJpYnV0 ZSBuYW1lZCBtZDUgb24gdGhlIHJvb3QgZmlsZSBzeXN0ZW0uDQoNCgkgICBl eHRhdHRyY3RsIHN0b3AgLw0KDQogICAgIFN0b3AgZXh0ZW5kZWQgYXR0cmli dXRlcyBvbiB0aGUgcm9vdCBmaWxlIHN5c3RlbS4NCg0KUwhTRQhFRQhFIEEI QUwITFMIU08ITw0KICAgICBnZXRleHRhdHRyKDgpLCAgc2V0ZXh0YXR0cig4 KSwgIGV4dGF0dHIoOSkNCg0KSAhISQhJUwhTVAhUTwhPUghSWQhZDQogICAg IEV4dGVuZGVkIGF0dHJpYnV0ZSBzdXBwb3J0IHdhcyBkZXZlbG9wZWQgYXMg cGFydCBvZiB0aGUgVHJ1c3RlZEJTRCBQcm8tDQogICAgIGplY3QsIGFuZCBp bnRyb2R1Y2VkIGluIEZyZWVCU0QgNS4wLiAgSXQgd2FzIGRldmVsb3BlZCB0 byBzdXBwb3J0IHNlY3VyaS0NCiAgICAgdHkgZXh0ZW5zaW9ucyByZXF1aXJp bmcgYWRkaXRpb25hbCBsYWJlbHMgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIGVh Y2ggZmlsZQ0KICAgICBvciBkaXJlY3RvcnkuDQoNCkEIQVUIVVQIVEgISE8I T1IIUlMIUw0KICAgICBSb2JlcnQgTiBNIFdhdHNvbg0KDQpCU0QJCQkJTWFy Y2ggMzAsIDIwMDAJCQkJICAgICAyDQo= --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="getextattr.8.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpHRVRFWFRBVFRSKDgpCQlGcmVlQlNEIFN5c3RlbSBNYW5hZ2VyJ3MgTWFu dWFsIAkgR0VURVhUQVRUUig4KQ0KDQpOCE5BCEFNCE1FCEUNCiAgICAgZwhn ZQhldAh0ZQhleAh4dAh0YQhhdAh0dAh0cghyIC0gcmV0cmlldmUgYSBuYW1l ZCBleHRlbmRlZCBhdHRyaWJ1dGUNCg0KUwhTWQhZTghOTwhPUAhQUwhTSQhJ UwhTDQogICAgIGcIZ2UIZXQIdGUIZXgIeHQIdGEIYXQIdHQIdHIIciBbLQgt bAhscwhzXSBfCGFfCHRfCHRfCHJfCG5fCGFfCG1fCGUgXwhmXwhpXwhsXwhl XwhuXwhhXwhtXwhlIF8ILl8ILl8ILg0KDQpECERFCEVTCFNDCENSCFJJCElQ CFBUCFRJCElPCE9OCE4NCiAgICAgZwhnZQhldAh0ZQhleAh4dAh0YQhhdAh0 dAh0cghyIGlzIGEgdXNlciB0b29sIHRvIHJldHJpZXZlIGEgbmFtZWQgZXh0 ZW5kZWQgYXR0cmlidXRlIG9uIGENCiAgICAgZmlsZSBvciBkaXJlY3Rvcnku ICBUaGUgXwhhXwh0Xwh0XwhyXwhuXwhhXwhtXwhlIGFyZ3VtZW50IHNob3Vs ZCBiZSB0aGUgbmFtZSBvZiB0aGUgYXQtDQogICAgIHRyaWJ1dGUsIGFuZCBf CGZfCGlfCGxfCGVfCG5fCGFfCG1fCGUgYSBsaXN0IG9mIGZpbGVzIGFuZCBk aXJlY3RvcmllcyBmcm9tIHdoaWNoIHRvIHJlLQ0KICAgICB0cmlldmUgYXR0 cmlidXRlIGRhdGEuDQoNCiAgICAgVGhlIGZvbGxvd2luZyBvcHRpb25zIGFy ZSBhdmFpbGFibGU6DQoNCiAgICAgLQgtbAhsICAgICAgUHJpbnQgYXR0cmli dXRlcyBpbiB0aGUgZmlyc3QgY29sdW1uIGFuZCBmaWxlIG5hbWVzIGluIHRo ZSBzZWMtDQoJICAgICBvbmQuICBDYW4gYmUgdXNlZCBvbmx5IGluIGNvbmp1 bmN0aW9uIHdpdGggdGhlIC0ILXMIcyBvcHRpb24uDQoNCiAgICAgLQgtcwhz ICAgICAgQXR0ZW1wdCB0byBkaXNwbGF5IHRoZSBhdHRyaWJ1dGUgZGF0YSBh cyBhIHN0cmluZywgYWx0aG91Z2ggdGhlDQoJICAgICByZXN1bHRzIG1heSBu b3QgbG9vayBwcmV0dHkgaWYgdGhlIGRhdGEgaXMgYmluYXJ5IGRhdGEuICBU aGUNCgkgICAgIHN0cnZpc3goMykgZnVuY3Rpb24gaXMgdXNlZCB0byBnZW5l cmF0ZSB0aGUgc3RyaW5nLCBzbyBjb250cm9sDQoJICAgICBzZXF1ZW5jZXMg c2hvdWxkIGJlIHNhZmVseSBlc2NhcGVkLiAgT3RoZXJ3aXNlLCB0aGUgYXR0 cmlidXRlIGRhLQ0KCSAgICAgdGEgd2lsbCBiZSByZXByZXNlbnRlZCBhcyBh IHNlcmllcyBvZiB0d28tZGlnaXQgaGV4IG51bWJlcnMuDQoNCkkISU0ITVAI UEwITEUIRU0ITUUIRU4ITlQIVEEIQVQIVEkISU8IT04ITiBOCE5PCE9UCFRF CEVTCFMNCiAgICAgSW4gb3JkZXIgZm9yIGcIZ2UIZXQIdGUIZXgIeHQIdGEI YXQIdHQIdHIIciB0byBzdWNjZWVkLCB0aGUgYXR0cmlidXRlIHNlcnZpY2Ug bXVzdCBiZSBhdmFpbC0NCiAgICAgYWJsZSBvbiB0aGUgZmlsZSBzeXN0ZW0s IGFuZCB0aGUgYXR0cmlidXRlIG11c3Qgb2YgZGVmaW5lZCBmb3IgdGhlIGZp bGUNCiAgICAgcXVlcmllZC4NCg0KRQhFWAhYQQhBTQhNUAhQTAhMRQhFUwhT DQoJICAgIyBnZXRleHRhdHRyIG1kNSAva2VybmVsDQoJICAgL2tlcm5lbDoN CgkgICAgIDYxIDYxIDMzIDYyIDM5IDM5IDY2IDY1CTMxIDM1IDM1IDMyIDMx IDYyIDY1IDMyDQoJICAgICA2MiAzNiAzOCAzNiA2MiAzMSA2NiAzOQk2MyA2 NCAzMyAzOSAzNSAzNiAzNiAzMQ0KCSAgICMgZ2V0ZXh0YXR0ciAtcyBtZDUg L2tlcm5lbA0KCSAgIC9rZXJuZWw6ICJhYTNiOTlmZTE1NTIxYmUyYjY4NmIx ZjljZDM5NTY2MSINCg0KICAgICBSZXRyaWV2ZSB0aGUgYGBtZDUnJyBleHRl bmRlZCBhdHRyaWJ1dGUgZm9yIHRoZSBmaWxlIF8IL18Ia18IZV8Icl8Ibl8I ZV8IbC4NCg0KUwhTRQhFRQhFIEEIQUwITFMIU08ITw0KICAgICBleHRhdHRy Y3RsKDgpLCAgc2V0ZXh0YXR0cig4KSwgIGV4dGF0dHIoOSkNCg0KSAhISQhJ UwhTVAhUTwhPUghSWQhZDQogICAgIEV4dGVuZGVkIGF0dHJpYnV0ZSBzdXBw b3J0IHdhcyBkZXZlbG9wZWQgYXMgcGFydCBvZiB0aGUgVHJ1c3RlZEJTRCBQ cm8tDQogICAgIGplY3QsIGFuZCBpbnRyb2R1Y2VkIGluIEZyZWVCU0QgNS4w LiAgSXQgd2FzIGRldmVsb3BlZCB0byBzdXBwb3J0IHNlY3VyaS0NCiAgICAg dHkgZXh0ZW5zaW9ucyByZXF1aXJpbmcgYWRkaXRpb25hbCBsYWJlbHMgdG8g YmUgYXNzb2NpYXRlZCB3aXRoIGVhY2ggZmlsZQ0KICAgICBvciBkaXJlY3Rv cnkuDQoNCkEIQVUIVVQIVEgISE8IT1IIUlMIUw0KICAgICBSb2JlcnQgTiBN IFdhdHNvbg0KDQpCCEJVCFVHCEdTCFMNCiAgICAgT25seSB0aGUgZmlyc3Qg MjA0OCBieXRlcyBvZiB0aGUgZXh0ZW5kZWQgYXR0cmlidXRlIHZhbHVlIGFy ZSBkaXNwbGF5ZWQNCiAgICAgZHVlIHRvIGEgaGFyZC1jb2RlZCBidWZmZXIg bGltaXQuDQoNCkJTRAkJCQlNYXJjaCAzMCwgMjAwMAkJCQkgICAgIDENCg== --0-2131519597-961348536=:6424 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="setextattr.8.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpTRVRFWFRBVFRSKDgpCQlGcmVlQlNEIFN5c3RlbSBNYW5hZ2VyJ3MgTWFu dWFsIAkgU0VURVhUQVRUUig4KQ0KDQpOCE5BCEFNCE1FCEUNCiAgICAgcwhz ZQhldAh0ZQhleAh4dAh0YQhhdAh0dAh0cghyIC0gc2V0IGEgbmFtZWQgZXh0 ZW5kZWQgYXR0cmlidXRlDQoNClMIU1kIWU4ITk8IT1AIUFMIU0kISVMIUw0K ICAgICBzCHNlCGV0CHRlCGV4CHh0CHRhCGF0CHR0CHRyCHIgXwhhXwh0Xwh0 XwhyXwhuXwhhXwhtXwhlIF8IZl8IaV8IbF8IZV8Ibl8IYV8IbV8IZSBfCGFf CHRfCHRfCHJfCHZfCGFfCGxfCHVfCGUNCg0KRAhERQhFUwhTQwhDUghSSQhJ UAhQVAhUSQhJTwhPTghODQogICAgIHMIc2UIZXQIdGUIZXgIeHQIdGEIYXQI dHQIdHIIciBpcyBhIHVzZXIgdG9vbCB0byBzZXQgYSBuYW1lZCBleHRlbmRl ZCBhdHRyaWJ1dGUgb24gYSBmaWxlIG9yDQogICAgIGRpcmVjdG9yeSB0byB0 aGUgcHJvdmlkZWQgc3RyaW5nLglUaGUgXwhhXwh0Xwh0XwhyXwhuXwhhXwht XwhlIGFyZ3VtZW50IHNob3VsZCBiZSB0aGUNCiAgICAgbmFtZSBvZiB0aGUg YXR0cmlidXRlLCBfCGZfCGlfCGxfCGVfCG5fCGFfCG1fCGUgdGhlIG5hbWUg b2YgdGhlIGZpbGUgb3IgZGlyZWN0b3J5IHRvIHNldA0KICAgICB0aGUgYXR0 cmlidXRlIGZvciwgYW5kIF8IYV8IdF8IdF8Icl8Idl8IYV8IbF8IdV8IZSBh IHN0cmluZyB0byBzdG9yZSBpbiB0aGUgYXR0cmlidXRlLiAgcwhzZQhlLQgt DQogICAgIHQIdGUIZXgIeHQIdGEIYXQIdHQIdHIIciB3aWxsIHN0b3JlIHRo ZSBzdHJpbmcgaW4gdGhlIGZpbGUncyBhdHRyaWJ1dGUuICBJbiBvcmRlciBm b3IgcwhzZQhlLQgtDQogICAgIHQIdGUIZXgIeHQIdGEIYXQIdHQIdHIIciB0 byBzdWNjZWVkLCB0aGUgYXR0cmlidXRlIHNlcnZpY2UgbXVzdCBiZSBhdmFp bGFibGUgb24gdGhlIGZpbGUNCiAgICAgc3lzdGVtLCBhbmQgYXBwcm9wcmlh dGUgcHJpdmlsZWdlIG1heSBiZSByZXF1aXJlZC4NCg0KRQhFWAhYQQhBTQhN UAhQTAhMRQhFUwhTDQoJICAgIyBzZXRleHRhdHRyIG1kNSAva2VybmVsIGBt ZDUgLXEgL2tlcm5lbGANCg0KICAgICBTZXQgdGhlIGBgbWQ1JycgZXh0ZW5k ZWQgYXR0cmlidXRlIG9uIHRoZSBmaWxlIC9rZXJuZWwgdG8gdGhlIHN0cmlu ZyBjb24tDQogICAgIHRhaW5pbmcgdGhlIG91dHB1dCBvZiBgYG1kNSAtcSAv a2VybmVsJycuDQoNClMIU0UIRUUIRSBBCEFMCExTCFNPCE8NCiAgICAgZXh0 YXR0cmN0bCg4KSwgIGdldGV4dGF0dHIoOCksICBleHRhdHRyKDkpDQoNCkgI SEkISVMIU1QIVE8IT1IIUlkIWQ0KICAgICBFeHRlbmRlZCBhdHRyaWJ1dGUg c3VwcG9ydCB3YXMgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIFRydXN0ZWRC U0QgUHJvLQ0KICAgICBqZWN0LCBhbmQgaW50cm9kdWNlZCBpbiBGcmVlQlNE IDUuMC4gIEl0IHdhcyBkZXZlbG9wZWQgdG8gc3VwcG9ydCBzZWN1cmktDQog ICAgIHR5IGV4dGVuc2lvbnMgcmVxdWlyaW5nIGFkZGl0aW9uYWwgbGFiZWxz IHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGZpbGUNCiAgICAgb3IgZGly ZWN0b3J5Lg0KDQpBCEFVCFVUCFRICEhPCE9SCFJTCFMNCiAgICAgUm9iZXJ0 IE4gTSBXYXRzb24NCg0KQghCVQhVRwhHUwhTDQogICAgIHMIc2UIZXQIdGUI ZXgIeHQIdGEIYXQIdHQIdHIIciBjYW4gb25seSBiZSB1c2VkIHRvIHNldCBh dHRyaWJ1dGVzIHRvIHN0cmluZ3MuDQoNCkJTRAkJCQlNYXJjaCAzMCwgMjAw MAkJCQkgICAgIDENCg== --0-2131519597-961348536=:6424-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 14: 4:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4C24637BA25 for ; Sun, 18 Jun 2000 14:04:13 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5IL4CO15268 for arch@freebsd.org; Sun, 18 Jun 2000 14:04:12 -0700 (PDT) Date: Sun, 18 Jun 2000 14:04:12 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: accept filters Message-ID: <20000618140412.F18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://people.freebsd.org/~alfred/accf.diff thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 14:20:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id F3D8F37BA52 for ; Sun, 18 Jun 2000 14:20:39 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id QAA01865; Sun, 18 Jun 2000 16:25:02 -0500 (CDT) (envelope-from jlemon) Date: Sun, 18 Jun 2000 16:25:02 -0500 From: Jonathan Lemon To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: accept filters Message-ID: <20000618162502.A619@prism.flugsvamp.com> References: <20000618140412.F18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000618140412.F18462@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 18, 2000 at 02:04:12PM -0700, Alfred Perlstein wrote: > http://people.freebsd.org/~alfred/accf.diff This part I somewhat dislike: struct socket { struct vm_zone *so_zone; /* zone we were allocated from */ short so_type; /* generic type, see socket.h */ @@ -112,6 +114,9 @@ /* NB: generation count must not be first; easiest to make it last. */ so_gen_t so_gencnt; /* generation count */ void *so_emuldata; /* private data for emulators */ + struct accept_filter *so_accept_filter; + void *so_accept_filter_arg; /* saved filter args */ + char *so_accept_filter_str; /* saved user args */ }; Isn't there a better way of doing this than adding more elements to every socket? Especially since this only applies to listen() sockets? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 14:28: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A7B6637B525 for ; Sun, 18 Jun 2000 14:28:04 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5ILRhM15877; Sun, 18 Jun 2000 14:27:43 -0700 (PDT) Date: Sun, 18 Jun 2000 14:27:43 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: accept filters Message-ID: <20000618142743.G18462@fw.wintelcom.net> References: <20000618140412.F18462@fw.wintelcom.net> <20000618162502.A619@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000618162502.A619@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Sun, Jun 18, 2000 at 04:25:02PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [000618 14:20] wrote: > On Sun, Jun 18, 2000 at 02:04:12PM -0700, Alfred Perlstein wrote: > > http://people.freebsd.org/~alfred/accf.diff > > This part I somewhat dislike: > > struct socket { > struct vm_zone *so_zone; /* zone we were allocated from */ > short so_type; /* generic type, see socket.h */ > @@ -112,6 +114,9 @@ > /* NB: generation count must not be first; easiest to make it last. */ > so_gen_t so_gencnt; /* generation count */ > void *so_emuldata; /* private data for emulators */ > + struct accept_filter *so_accept_filter; > + void *so_accept_filter_arg; /* saved filter args */ > + char *so_accept_filter_str; /* saved user args */ > }; > > Isn't there a better way of doing this than adding more elements > to every socket? Especially since this only applies to listen() > sockets? I could make it just one pointer to a struct that holds all three? Or I can take out the passing of arguments to accept filters, but I thought otherwise people would complain that it isn't bloated^H^H^H^H^H^H^Hmodular enough. And it would also annoy me because it was difficult to do... -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 14:43:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.bastard.co.uk (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 5B5EE37BA22 for ; Sun, 18 Jun 2000 14:43:54 -0700 (PDT) (envelope-from adrian@bastard.co.uk) Received: from adrian by mail.bastard.co.uk with local (Exim 3.14 #1) id 133mr4-0003TM-00; Sun, 18 Jun 2000 23:43:46 +0200 Date: Sun, 18 Jun 2000 23:43:46 +0200 From: Adrian Chadd To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: accept filters Message-ID: <20000618234346.I13112@zoe.bastard.co.uk> References: <20000618140412.F18462@fw.wintelcom.net> <20000618162502.A619@prism.flugsvamp.com> <20000618142743.G18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000618142743.G18462@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Jun 18, 2000 at 02:27:43PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 18, 2000, Alfred Perlstein wrote: > * Jonathan Lemon [000618 14:20] wrote: > > On Sun, Jun 18, 2000 at 02:04:12PM -0700, Alfred Perlstein wrote: > > > http://people.freebsd.org/~alfred/accf.diff > > > > This part I somewhat dislike: > > > > struct socket { > > struct vm_zone *so_zone; /* zone we were allocated from */ > > short so_type; /* generic type, see socket.h */ > > @@ -112,6 +114,9 @@ > > /* NB: generation count must not be first; easiest to make it last. */ > > so_gen_t so_gencnt; /* generation count */ > > void *so_emuldata; /* private data for emulators */ > > + struct accept_filter *so_accept_filter; > > + void *so_accept_filter_arg; /* saved filter args */ > > + char *so_accept_filter_str; /* saved user args */ > > }; > > > > Isn't there a better way of doing this than adding more elements > > to every socket? Especially since this only applies to listen() > > sockets? > > I could make it just one pointer to a struct that holds all three? > > Or I can take out the passing of arguments to accept filters, but > I thought otherwise people would complain that it isn't > bloated^H^H^H^H^H^H^Hmodular enough. And it would also annoy me > because it was difficult to do... I like the idea as a whole, and I like the idea of having it as one pointer to a struct where applicable. Neat one. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 15:35:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 6E05B37BAEF for ; Sun, 18 Jun 2000 15:35:32 -0700 (PDT) (envelope-from julian@elischer.org) Received: from mogadishu-54.budapest.interware.hu ([195.70.52.118] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 133ntc-0008BB-00; Mon, 19 Jun 2000 00:50:28 +0200 Message-ID: <394D4E88.167EB0E7@elischer.org> Date: Sun, 18 Jun 2000 15:34:48 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: accept filters References: <20000618140412.F18462@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > http://people.freebsd.org/~alfred/accf.diff Man page diffs would be an idea too. > > thanks, > -Alfred > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 15:37:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 216B837BA83 for ; Sun, 18 Jun 2000 15:37:44 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5IMbdA17583; Sun, 18 Jun 2000 15:37:39 -0700 (PDT) Date: Sun, 18 Jun 2000 15:37:38 -0700 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: accept filters Message-ID: <20000618153738.J18462@fw.wintelcom.net> References: <20000618140412.F18462@fw.wintelcom.net> <394D4E88.167EB0E7@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <394D4E88.167EB0E7@elischer.org>; from julian@elischer.org on Sun, Jun 18, 2000 at 03:34:48PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Julian Elischer [000618 15:35] wrote: > Alfred Perlstein wrote: > > > > http://people.freebsd.org/~alfred/accf.diff > > Man page diffs would be an idea too. Well since this trivial change has garnered so much attention there's no way I'm doing that until I have a bit more of a concensus if this is going to be the API or not. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 15:42:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 544C837B715 for ; Sun, 18 Jun 2000 15:42:42 -0700 (PDT) (envelope-from julian@elischer.org) Received: from mogadishu-54.budapest.interware.hu ([195.70.52.118] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 133o0e-00009w-00; Mon, 19 Jun 2000 00:57:44 +0200 Message-ID: <394D503C.2781E494@elischer.org> Date: Sun, 18 Jun 2000 15:42:04 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: accept filters References: <20000618140412.F18462@fw.wintelcom.net> <394D4E88.167EB0E7@elischer.org> <20000618153738.J18462@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > * Julian Elischer [000618 15:35] wrote: > > Alfred Perlstein wrote: > > > > > > http://people.freebsd.org/~alfred/accf.diff > > > > Man page diffs would be an idea too. > > Well since this trivial change has garnered so much attention there's > no way I'm doing that until I have a bit more of a concensus if this > is going to be the API or not. Actually I disagree. the documentation changes should be submitted for comment along with the code. > > -Alfred > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 16: 2:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sydney.worldwide.lemis.com (static224.conference.usenix.org [209.179.127.224]) by hub.freebsd.org (Postfix) with ESMTP id 544F537B715; Sun, 18 Jun 2000 16:02:30 -0700 (PDT) (envelope-from grog@sydney.worldwide.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id QAA02707; Sun, 18 Jun 2000 16:02:23 -0700 (PDT) (envelope-from grog) Date: Sun, 18 Jun 2000 16:02:23 -0700 From: Greg Lehey To: FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Subject: -e option to umount? Message-ID: <20000618160223.A2482@sydney.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What do people think about adding a -e option to umount(8) to eject a removable medium where possible? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 16:15:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 37FA637BAEB; Sun, 18 Jun 2000 16:15:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA74352; Sun, 18 Jun 2000 16:13:51 -0700 (PDT) (envelope-from dillon) Date: Sun, 18 Jun 2000 16:13:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200006182313.QAA74352@apollo.backplane.com> To: Greg Lehey Cc: FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? References: <20000618160223.A2482@sydney.worldwide.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :What do people think about adding a -e option to umount(8) to eject a :removable medium where possible? : :Greg :-- :Finger grog@lemis.com for PGP public key Sounds good! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 16:17: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 17B8437BAE8 for ; Sun, 18 Jun 2000 16:17:06 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA04634; Sun, 18 Jun 2000 16:13:56 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda04630; Sun Jun 18 16:13:43 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id QAA04797; Sun, 18 Jun 2000 16:13:43 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdiJ4795; Sun Jun 18 16:13:29 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5INDSb72886; Sun, 18 Jun 2000 16:13:28 -0700 (PDT) Message-Id: <200006182313.e5INDSb72886@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpde72875; Sun Jun 18 16:12:37 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Greg Lehey Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? In-reply-to: Your message of "Sun, 18 Jun 2000 16:02:23 PDT." <20000618160223.A2482@sydney.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Jun 2000 16:12:37 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000618160223.A2482@sydney.worldwide.lemis.com>, Greg Lehey writes : > What do people think about adding a -e option to umount(8) to eject a > removable medium where possible? I second the motion. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 17: 2:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id D2DB837B56E; Sun, 18 Jun 2000 17:02:09 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-250-77.netcologne.de [195.14.250.77]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id CAA25644; Mon, 19 Jun 2000 02:02:05 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id CAA03596; Mon, 19 Jun 2000 02:01:19 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Mon, 19 Jun 2000 02:01:19 +0200 (CEST) Message-Id: <200006190001.CAA03596@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: grog@sydney.worldwide.lemis.com Cc: FreeBSD-current@FreeBSD.ORG, FreeBSD-arch@FreeBSD.ORG In-reply-to: <20000618160223.A2482@sydney.worldwide.lemis.com> (message from Greg Lehey on Sun, 18 Jun 2000 16:02:23 -0700) Subject: Re: -e option to umount? Reply-To: van.woerkom@netcologne.de References: <20000618160223.A2482@sydney.worldwide.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What do people think about adding a -e option to umount(8) to eject a > removable medium where possible? SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Here are the manpages for comparison: Irix 6.5: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/eject.z&srch=eject Solaris 2.7: http://www.FreeBSD.org/cgi/man.cgi?query=eject&apropos=0&sektion=0&manpath=SunOS+5.7&format=html Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 17:13:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id C426637BAD1; Sun, 18 Jun 2000 17:13:54 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-250-77.netcologne.de [195.14.250.77]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id CAA25865; Mon, 19 Jun 2000 02:10:31 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id CAA03688; Mon, 19 Jun 2000 02:09:44 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Mon, 19 Jun 2000 02:09:44 +0200 (CEST) Message-Id: <200006190009.CAA03688@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: van.woerkom@netcologne.de Cc: grog@sydney.worldwide.lemis.com, FreeBSD-current@FreeBSD.ORG, FreeBSD-arch@FreeBSD.ORG In-reply-to: <200006190001.CAA03596@oranje.my.domain> (message from Marc van Woerkom on Mon, 19 Jun 2000 02:01:19 +0200 (CEST)) Subject: Re: -e option to umount? Reply-To: van.woerkom@netcologne.de References: <20000618160223.A2482@sydney.worldwide.lemis.com> <200006190001.CAA03596@oranje.my.domain> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. http://www.FreeBSD.org/cgi/man.cgi?query=eject&apropos=0&sektion=0&manpath=OpenBSD+2.6&format=html http://www.FreeBSD.org/cgi/man.cgi?query=eject&apropos=0&sektion=0&manpath=NetBSD+1.4&format=html Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 18: 6:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hurricane.columbus.rr.com (m5.columbus.rr.com [204.210.252.249]) by hub.freebsd.org (Postfix) with ESMTP id D455D37B6A2; Sun, 18 Jun 2000 18:06:38 -0700 (PDT) (envelope-from caa@columbus.rr.com) Received: from blizzard.columbus.rr.com ([204.210.252.252]) by hurricane.columbus.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-53939U80000L80000S0V35) with ESMTP id com; Sun, 18 Jun 2000 21:06:54 -0400 Received: from columbus.rr.com (wvl243179.columbus.rr.com [204.210.243.179]) by blizzard.columbus.rr.com (8.9.3/8.9.3) with ESMTP id VAA00354; Sun, 18 Jun 2000 21:05:47 -0400 (EDT) Received: (from caa@localhost) by columbus.rr.com (8.9.3/8.9.3) id VAA01813; Sun, 18 Jun 2000 21:06:57 GMT (envelope-from caa) Date: Sun, 18 Jun 2000 21:06:52 +0000 From: Charles Anderson To: Marc van Woerkom Cc: grog@sydney.worldwide.lemis.com, FreeBSD-current@FreeBSD.ORG, FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? Message-ID: <20000618210652.A917@midgard.dhs.org> References: <20000618160223.A2482@sydney.worldwide.lemis.com> <200006190001.CAA03596@oranje.my.domain> <200006190009.CAA03688@oranje.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006190009.CAA03688@oranje.my.domain>; from van.woerkom@netcologne.de on Mon, Jun 19, 2000 at 02:09:44AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /usr/ports/sysutils/eject On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: > > SGIs and SUNs use an 'eject' command for CDs and DAT tapes. > > OpenBSD 2.6 uses 'mt' and 'eject' > NetBSD 1.4 uses 'eject' as well. > > http://www.FreeBSD.org/cgi/man.cgi?query=eject&apropos=0&sektion=0&manpath=OpenBSD+2.6&format=html > http://www.FreeBSD.org/cgi/man.cgi?query=eject&apropos=0&sektion=0&manpath=NetBSD+1.4&format=html > > Regards, > Marc > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Charles Anderson caa@columbus.rr.com No quote, no nothin' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 21: 1: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sanson.reyes.somos.net (freyes.static.inch.com [216.223.199.224]) by hub.freebsd.org (Postfix) with ESMTP id CFAE637B6CD; Sun, 18 Jun 2000 21:00:57 -0700 (PDT) (envelope-from fran@reyes.somos.net) Received: from tomasa (tomasa.reyes.somos.net [10.0.0.11]) by sanson.reyes.somos.net (8.9.3/8.9.3) with SMTP id XAA22495; Sun, 18 Jun 2000 23:54:12 -0400 (EDT) (envelope-from fran@reyes.somos.net) Message-Id: <200006190354.XAA22495@sanson.reyes.somos.net> From: "Francisco Reyes" To: "Charles Anderson" , "Marc van Woerkom" Cc: "FreeBSD-arch@FreeBSD.ORG" , "FreeBSD-current@FreeBSD.ORG" , "grog@sydney.worldwide.lemis.com" Date: Sun, 18 Jun 2000 23:54:51 -0400 Reply-To: "Francisco Reyes" X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <20000618210652.A917@midgard.dhs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: -e option to umount? Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jun 2000 21:06:52 +0000, Charles Anderson wrote: >/usr/ports/sysutils/eject > >On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: >> > SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Whether as a separate command or as part of umount this is certainly something worth having by default. In particular new users may be a while before they find ports/packages or will just end up in the questions list. Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. Francisco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 21:45:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id CC9A037BB37 for ; Sun, 18 Jun 2000 21:45:16 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 8191 invoked from network); 19 Jun 2000 04:45:15 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 19 Jun 2000 04:45:15 -0000 Message-ID: <394DA55B.7D884B0C@cvzoom.net> Date: Mon, 19 Jun 2000 00:45:15 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Francisco Reyes Cc: Charles Anderson , Marc van Woerkom , "FreeBSD-arch@FreeBSD.ORG" , "FreeBSD-current@FreeBSD.ORG" , "grog@sydney.worldwide.lemis.com" Subject: Re: -e option to umount? References: <200006190354.XAA22495@sanson.reyes.somos.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Francisco Reyes wrote: > Whether as a separate command or as part of umount this is > certainly something worth having by default. > In particular new users may be a while before they find > ports/packages or will just end up in the questions list. Well, you could have both. For example, you could have the -e switch to umount which performs the eject function. In addition, you could have "eject" as a link to umount, and umount itself would check argv[0] to see if it is being executed as eject or umount. If it's eject instead of umount, then perform whatever action the -e flag does. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 18 23:37: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id C547A37BC0C; Sun, 18 Jun 2000 23:36:55 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id HAA76985; Mon, 19 Jun 2000 07:35:38 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id HAA20316; Mon, 19 Jun 2000 07:16:18 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <20000618160223.A2482@sydney.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Jun 2000 07:16:18 +0100 To: Greg Lehey From: Bob Bishop Subject: Re: -e option to umount? Cc: FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 16:02 -0700 18/6/00, Greg Lehey wrote: >What do people think about adding a -e option to umount(8) to eject a >removable medium where possible? What's special about mounted devices? I'd prefer to see an eject command which attempts to unmount the device if it's mounted. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 2:13:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3552737BC70 for ; Mon, 19 Jun 2000 02:13:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id TAA05030; Mon, 19 Jun 2000 19:13:29 +1000 Date: Mon, 19 Jun 2000 19:13:28 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kirk McKusick Cc: Gregory Neil Shapiro , sendmail-questions@Sendmail.ORG, Eric Allman , arch@FreeBSD.ORG Subject: Re: Broken FreeBSD setuid(2)? In-Reply-To: <200006171745.KAA08559@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jun 2000, Kirk McKusick wrote: > My answer is at the bottom. I am copying the FreeBSD arch group > so they can complain if I am misrepresenting how this came to be. > > > Date: Thu, 15 Jun 2000 12:05:27 -0700 (PDT) > > From: Gregory Neil Shapiro > > ... > > POSIX Part I, section 4.2.2.2 states: > > > > If {_POSIX_SAVED_IDS} is defined: > > ... > > (2) If the process does not have appropriate privileges, but uid is > > equal to the real user ID or the saved set-user-ID, the setuid() > > function sets the effective user ID to uid; the real user ID and > > saved set-user-ID remain unchanged by this function call. > > > > This is the case demonstrated above. It does not have appropriate privileges > > since it is not running as root. The uid is equal to the real UID. This doesn't follow. "appropriate privilege" is implementation-defined. See POSIX.1-1996 section 2.2.2.4. In FreeBSD, appropriate privilege for setuid() is defined as (newuid == geteuid() || geteuid() == 0). This "fixes": 1) Programs that depend on pure !_POSIX_SAVED_IDS behaviour. 4.4BSD(Lite) saved ids are surprising for such programs. 2) There was no "standard" was of dropping the extra privileges given by 4.4BSD(Lite) saved ids using 4.4BSD(Lite) syscalls withoud exec'ing, except for root. In FreeBSD, this can be done using either setreuid(uid, uid)) or the newer setresuid(uid, uid, uid), but depending on setreuid() to do it is dangerous because setreuid() is just a wrapper for seteuid() in 4.4BSD(Lite). > > However, the setuid() function is setting the saved set-user-ID and not > > leaving it unchanged. If it were unchanged, then the second setuid() > > should not fail, again because of this statement and the fact that the uid > > is equal to the saved set-user-ID. > > > > Looking at other implementations, we have found that the second setuid only > > fails on FreeBSD. It succeeds and the program works as expected on > > Solaris, Linux, and OpenBSD. I think 4.4BSDLite-[1-2], NetBSD(at east last year's version), and BSD/OS4.1 have the same behaviour as FreeBSD[3-5] here (some versions of FreeBSD-2 implemented _POSIX_SAVED_IDS so they gave the behaviour that you expected). FreeBSD's definition of "appropriate privilege" is irrelevant in your example. The 4.4BSD(Lite) saved id gives "unappropriate" privilege for setuid() to succeed, and when it succeeds it sets all the ids to the same values. > > I checked /usr/src/sys/kern/kern_prot.c and see comments about appendix B > > but I do not believe they apply to this case. The setuid() man page > > states: Indeed, they don't quite apply. > > It's arguable whether or not you can follow the rules of !_POSIX_SAVED_IDS > > while still using saved IDs as it creates a subtle difference between > > FreeBSD and other operating systems that more than likely goes unnoticed by > > application writers and has the potential of breaking some of these > > programs. This is a 4.4BSD(Lite) feature, not a FreeBSD one. > I agree that FreeBSD does not implement saved id's according > to the Posix spec. And indeed they do not claim to do so as > {_POSIX_SAVED_IDS} is defined as false (see `sysctl kern.saved_ids'). > As released, 4.4BSD defined {_POSIX_SAVED_IDS} as true and had the > behavior of NetBSD and OpenBSD. Posix argues that a non-priviledged Is it really different from 4.4BSD(Lite) here? From in Lite1: --- /* * Although we have saved user/group IDs, we do not use them in setuid * as described in POSIX 1003.1, because the feature does not work for * root. We use the saved IDs in seteuid/setegid, which are not currently * part of the POSIX 1003.1 specification. */ #ifdef _NOT_AVAILABLE #define _POSIX_SAVED_IDS /* saved set-user-ID and set-group-ID */ #endif --- The Lite2 code in kern/kern_prot.c matches this comment. FreeBSD hasn't changed a single byte here in , but has changed kern/kern_prot.c so implement _POSIX_SAVED_IDS if the unsupported option _POSIX_SAVED_IDS is defined at kernel compile time. BSD/OS4.1 has a better comment without a "dontdef" ifdef. BTW, note that _POSIX_SAVED_IDS doesn't mean that there are no saved ids. It means that there are no POSIX ones, and more importantly, that setuid() has the POSIX semantics for the !_POSIX_SAVED_IDS case in setuid(), etc. > ... > The FreeBSD folks decided to change the semantics of setuid to > overwrite the saved user-id so that programs could protect themselves > from stack overflows, debugger attaches, etc. They argue that > seteuid is available if you just want to set the effective user-id > and it is stupid to have a second system call (setuid) which does > exactly the same thing when you are not root. Since Posix never setuid() is still good for setting all the ids to the same value. It goes well with using seteuid() to manipulate the euid. > bought into adding seteuid, they had to overload setuid to get the > equivalent functionality. This is a good example of why Posix options > were a bad idea. By letting each system ship with different option > settings, you end up with very subtilely different semantics. > Each vendor is well meaning, but makes for a programming nightmare > among application developers that have to deal with all the > combinations. POSIX options like _POSIX_SAVED_IDS are simple compared with meta-options like "appropriate privlege". Correct handling of "appropriate privilege" seems to require programs to read and understand the system documentation for it when they start up ;-(. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 5:35: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 79F9B37B527; Mon, 19 Jun 2000 05:34:59 -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 OAA67453; Mon, 19 Jun 2000 14:34:51 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Dan Moschuk Cc: "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: <200006051720.TAA18713@gratis.grondar.za> <393BEE84.BBAD3E82@vangelderen.org> <20000606160118.C3351@spirit.jaded.net> From: Dag-Erling Smorgrav Date: 19 Jun 2000 14:34:50 +0200 In-Reply-To: Dan Moschuk's message of "Tue, 6 Jun 2000 16:01:18 -0400" Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Moschuk writes: > I have a driver for the i82802 chipset (Intel Thermal Noise RNG) that > needs to be newbus-ified before committing. Anyone that can help me > with this, it would be appreciated. The idea of built-in hardware RNGs bothers me a little. How can the manufacturer guarantee that all units are perfectly identical and indistinguishable? Is it conceivable that a hardware RNG might leave (be it by accident or by design) some kind of fingerprint in its output that might be detectable if you know what to look for? Reminds me of Sherlock Holmes comparing typewritten documents to see if they were produced on the same typewriter. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 6: 3:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 1CBF837B702; Mon, 19 Jun 2000 06:02:29 -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.3) with ESMTP id PAA44445; Mon, 19 Jun 2000 15:02:17 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: Dan Moschuk , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please In-reply-to: Your message of "19 Jun 2000 14:34:50 +0200." Date: Mon, 19 Jun 2000 15:02:17 +0200 Message-ID: <44443.961419737@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Dan Moschuk writes: >> I have a driver for the i82802 chipset (Intel Thermal Noise RNG) that >> needs to be newbus-ified before committing. Anyone that can help me >> with this, it would be appreciated. > >The idea of built-in hardware RNGs bothers me a little. How can the >manufacturer guarantee that all units are perfectly identical and >indistinguishable? Is it conceivable that a hardware RNG might leave >(be it by accident or by design) some kind of fingerprint in its >output that might be detectable if you know what to look for? Reminds >me of Sherlock Holmes comparing typewritten documents to see if they >were produced on the same typewriter. And just because you went out and bought your RNG separately, what difference would it make ? If an RNG has a fingerprint, you may be identified by it, no matter where you bought it or how. The trick is to not use too many of your bits too fast. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 7: 1:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id F0DCF37BC9C; Mon, 19 Jun 2000 07:01:10 -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 PAA67779; Mon, 19 Jun 2000 15:59:32 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Poul-Henning Kamp Cc: Dan Moschuk , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: <44443.961419737@critter.freebsd.dk> From: Dag-Erling Smorgrav Date: 19 Jun 2000 15:59:32 +0200 In-Reply-To: Poul-Henning Kamp's message of "Mon, 19 Jun 2000 15:02:17 +0200" Message-ID: Lines: 22 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > In message , Dag-Erling Smorgrav writes: > > The idea of built-in hardware RNGs bothers me a little. [...] > And just because you went out and bought your RNG separately, what > difference would it make ? If an RNG has a fingerprint, you may > be identified by it, no matter where you bought it or how. Hmm, yes, that wasn't quite what I meant. I was actually thinking about purpose-made RNGs vs. custom-made (e.g. lava lamp + webcam), the idea being that with the latter, a) you know it doesn't contain an intentional steganographic fingerprint and b) you have complete control over the RNG and can vary its output in unpredictable ways (moving the camera, changing the background...) which hopefully defeat recognition without affecting randomness. But this is all guesses and gut feelings, and experience teaches us that guesses and gut feelings are often - if not always - wrong when it comes to crypto and randomness, so feel free to ignore me. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 7: 4:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 5966437B7FA; Mon, 19 Jun 2000 07:04:35 -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.3) with ESMTP id QAA44780; Mon, 19 Jun 2000 16:04:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: Dan Moschuk , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please In-reply-to: Your message of "19 Jun 2000 15:59:32 +0200." Date: Mon, 19 Jun 2000 16:04:22 +0200 Message-ID: <44778.961423462@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Poul-Henning Kamp writes: >> In message , Dag-Erling Smorgrav writes: >> > The idea of built-in hardware RNGs bothers me a little. [...] >> And just because you went out and bought your RNG separately, what >> difference would it make ? If an RNG has a fingerprint, you may >> be identified by it, no matter where you bought it or how. > >Hmm, yes, that wasn't quite what I meant. I was actually thinking >about purpose-made RNGs vs. custom-made (e.g. lava lamp + webcam), the >idea being that with the latter, a) you know it doesn't contain an >intentional steganographic fingerprint and b) you have complete >control over the RNG and can vary its output in unpredictable ways >(moving the camera, changing the background...) which hopefully defeat >recognition without affecting randomness. Run your Intel built RNG through a cryptographic quality hash ? If you frustrate the output by running it though MD5 and feed a few random bits from your keyboard interrupt in there as well ? I wouldn't worry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 8:51:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id C944837BB92 for ; Mon, 19 Jun 2000 08:51:11 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA08463; Mon, 19 Jun 2000 08:55:54 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006191555.IAA08463@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please In-reply-to: Your message of "19 Jun 2000 14:34:50 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 08:55:54 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dan Moschuk writes: > > I have a driver for the i82802 chipset (Intel Thermal Noise RNG) that > > needs to be newbus-ified before committing. Anyone that can help me > > with this, it would be appreciated. > > The idea of built-in hardware RNGs bothers me a little. How can the > manufacturer guarantee that all units are perfectly identical and > indistinguishable? Is it conceivable that a hardware RNG might leave > (be it by accident or by design) some kind of fingerprint in its > output that might be detectable if you know what to look for? Reminds > me of Sherlock Holmes comparing typewritten documents to see if they > were produced on the same typewriter. A thermal noise source bases its output on quantum events. The art of producing well-balanced output from these devices has been long established (they're traditionally used as noise sources), and short of using eg. a cosmic-noise detector you're not going to get much more random in a box. You're welcome to perform your own analysis, of course, or go read the literature. Personally, I'm pretty happy to see this animal, and will remain so until someone tells me it's not as good as it should be. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 8:52: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.bezeqint.net (mail-a.bezeqint.net [192.115.106.23]) by hub.freebsd.org (Postfix) with ESMTP id 7632237B952 for ; Mon, 19 Jun 2000 08:52:02 -0700 (PDT) (envelope-from nimrodme@bezeqint.net) Received: from bezeqint.net (PT712031.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0FWE00BJDS1CAJ@mail.bezeqint.net> for freebsd-arch@freebsd.org; Mon, 19 Jun 2000 18:51:13 +0300 (IDT) Date: Mon, 19 Jun 2000 18:49:11 +0300 From: Nimrod Mesika Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please To: Dag-Erling Smorgrav , freebsd-arch@freebsd.org Reply-To: nimrodm@email.com Message-id: <394E40F7.E39EDD6A@bezeqint.net> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200006051720.TAA18713@gratis.grondar.za> <393BEE84.BBAD3E82@vangelderen.org> <20000606160118.C3351@spirit.jaded.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > The idea of built-in hardware RNGs bothers me a little. How can the > manufacturer guarantee that all units are perfectly identical and > indistinguishable? Is it conceivable that a hardware RNG might leave > (be it by accident or by design) some kind of fingerprint in its You *always* run the output of any random number generator through some statistics tests (how many? depending on the level of security you want). If it fails - shut down the system. This is necessary even if you trust the device, as it may become biased (temperature?) or just plain broke (and all your security goes down with it...) -- Nimrod. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 9:48:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id 1C44737BCC2; Mon, 19 Jun 2000 09:48:27 -0700 (PDT) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id MAA02315; Mon, 19 Jun 2000 12:45:47 -0400 (EDT) (envelope-from dan) Date: Mon, 19 Jun 2000 12:45:46 -0400 From: Dan Moschuk To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , Dan Moschuk , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please Message-ID: <20000619124546.A2268@spirit.jaded.net> References: <44778.961423462@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <44778.961423462@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Jun 19, 2000 at 04:04:22PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | >Hmm, yes, that wasn't quite what I meant. I was actually thinking | >about purpose-made RNGs vs. custom-made (e.g. lava lamp + webcam), the | >idea being that with the latter, a) you know it doesn't contain an | >intentional steganographic fingerprint and b) you have complete | >control over the RNG and can vary its output in unpredictable ways | >(moving the camera, changing the background...) which hopefully defeat | >recognition without affecting randomness. | | Run your Intel built RNG through a cryptographic quality hash ? | | If you frustrate the output by running it though MD5 and feed a few | random bits from your keyboard interrupt in there as well ? | | I wouldn't worry. Not to worry. The i82802 isn't meant to replace our current random number generator, but rather as a source of entropy for The Bigger Picture (Yarrow). We will still harvest entropy from various interrupts and other system sources. Which brings up another interesting point. Mark, I believe there are still some architectual issues with the Yarrow design. Can you comment on this status? -- Dan Moschuk (TFreak!dan@freebsd.org) "Don't get even -- get odd!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 9:50:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6162437B855; Mon, 19 Jun 2000 09:50:53 -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.3) with ESMTP id SAA45669; Mon, 19 Jun 2000 18:50:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dan Moschuk Cc: Dag-Erling Smorgrav , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please In-reply-to: Your message of "Mon, 19 Jun 2000 12:45:46 EDT." <20000619124546.A2268@spirit.jaded.net> Date: Mon, 19 Jun 2000 18:50:44 +0200 Message-ID: <45667.961433444@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000619124546.A2268@spirit.jaded.net>, Dan Moschuk writes: >We will still harvest entropy from various interrupts and other system >sources. We really need to add the random harverster to the PPS-API so that people can just hook up their geiger counter to their parallel port... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 10: 2:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id CF73037BD43 for ; Mon, 19 Jun 2000 10:02:41 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA68687; Mon, 19 Jun 2000 10:02:28 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200006191702.KAA68687@gndrsh.dnsmgr.net> Subject: Re: accept filters In-Reply-To: <394D503C.2781E494@elischer.org> from Julian Elischer at "Jun 18, 2000 03:42:04 pm" To: julian@elischer.org (Julian Elischer) Date: Mon, 19 Jun 2000 10:02:27 -0700 (PDT) Cc: bright@wintelcom.net (Alfred Perlstein), arch@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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Alfred Perlstein wrote: > > > > * Julian Elischer [000618 15:35] wrote: > > > Alfred Perlstein wrote: > > > > > > > > http://people.freebsd.org/~alfred/accf.diff > > > > > > Man page diffs would be an idea too. > > > > Well since this trivial change has garnered so much attention there's > > no way I'm doing that until I have a bit more of a concensus if this > > is going to be the API or not. > > Actually I disagree. the documentation changes should be submitted > for comment along with the code. Technically, in good project management/developement, the documentation changes should be done before any code is layed down :-) :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 10:24:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id C02EB37BD1B; Mon, 19 Jun 2000 10:23:58 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id QAA00697; Mon, 19 Jun 2000 16:16:29 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006191416.QAA00697@grimreaper.grondar.za> To: Dag-Erling Smorgrav Cc: Dan Moschuk , arch@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: In-Reply-To: ; from Dag-Erling Smorgrav "19 Jun 2000 14:34:50 +0200." Date: Mon, 19 Jun 2000 16:16:29 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The idea of built-in hardware RNGs bothers me a little. How can the > manufacturer guarantee that all units are perfectly identical and > indistinguishable? Is it conceivable that a hardware RNG might leave > (be it by accident or by design) some kind of fingerprint in its > output that might be detectable if you know what to look for? Reminds > me of Sherlock Holmes comparing typewritten documents to see if they > were produced on the same typewriter. This can be dealt with - hash the output into a "pool of entropy" and serve the randomness out of that. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 10:25:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id D8FF537BD06; Mon, 19 Jun 2000 10:25:35 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id TAA01363; Mon, 19 Jun 2000 19:26:07 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006191726.TAA01363@grimreaper.grondar.za> To: Dan Moschuk Cc: arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: <20000619124546.A2268@spirit.jaded.net> In-Reply-To: <20000619124546.A2268@spirit.jaded.net> ; from Dan Moschuk "Mon, 19 Jun 2000 12:45:46 -0400." Date: Mon, 19 Jun 2000 19:26:07 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Not to worry. The i82802 isn't meant to replace our current random number > generator, but rather as a source of entropy for The Bigger Picture (Yarrow). Cool! May I have a look at what you have? > We will still harvest entropy from various interrupts and other system > sources. Great! > Which brings up another interesting point. Mark, I believe there are still > some architectual issues with the Yarrow design. Can you comment on this > status? The internals are pretty much there, the basic reseed/hash/encrypt stuff is written. I still need to write the harvesters and the entropy estimation stuff. What is there works in the sense that it generates random-looking junk, but is no good because there is no entropy addition, and it is thus entirely predictable. DFR is looking at it, and I'd like to commit it as-is, then work on the entropy collection stuff. If you'd like to see it (mixed in with the zooty new /dev/null driver) take a look at http://freefall.freebsd.org/~markm/sys.*.gz. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 10:30:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id D311337BD2F for ; Mon, 19 Jun 2000 10:30:24 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id TAA01377; Mon, 19 Jun 2000 19:28:44 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006191728.TAA01377@grimreaper.grondar.za> To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: <45667.961433444@critter.freebsd.dk> In-Reply-To: <45667.961433444@critter.freebsd.dk> ; from Poul-Henning Kamp "Mon, 19 Jun 2000 18:50:44 +0200." Date: Mon, 19 Jun 2000 19:28:43 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We really need to add the random harverster to the PPS-API so that > people can just hook up their geiger counter to their parallel port... I'm working on a kobj-based model that will allow the entropy-harvester to be liberally salted throughout the kernel. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 10:58:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C995737BD4E for ; Mon, 19 Jun 2000 10:58:51 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JHwjw13517 for arch@freebsd.org; Mon, 19 Jun 2000 10:58:45 -0700 (PDT) Date: Mon, 19 Jun 2000 10:58:45 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: HEADS UP: accept filters II Message-ID: <20000619105844.B26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://people.freebsd.org/~alfred/accf.diff The extra fields in the socket have been moved into a malloc'd chunk to save 8 bytes per socket. (jlemon) The filters files location have been moved from sys/net to sys/netinet. (peter) I haven't seen any arguments against them besideds these two nits and the documentation aspect which I will address soon. I'm waiting to commit this now. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11: 1:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7C77137C03B for ; Mon, 19 Jun 2000 11:01:00 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JI0xi13656 for arch@freebsd.org; Mon, 19 Jun 2000 11:00:59 -0700 (PDT) Date: Mon, 19 Jun 2000 11:00:59 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: HEADS UP: kblob discussion? Message-ID: <20000619110059.C26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A whole bunch of people were a bit upset about kblob but haven't brought anything up that makes me not want to commit it. Now would be a good time to offer suggestions and critism before I bring it in. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11:13:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8B94C37BD4E for ; Mon, 19 Jun 2000 11:13:10 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JIDAn14008 for arch@freebsd.org; Mon, 19 Jun 2000 11:13:10 -0700 (PDT) Date: Mon, 19 Jun 2000 11:13:09 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: kblob discussion. Message-ID: <20000619111309.E26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oops, you can find the preliminary kblob diffs over here: http://people.freebsd.org/~alfred/kblob/kblob-final.diff It's a new syscall, less overhead than sendfile and useful for serving small chunks of data very quickly. /* * returns an fd to be used with kblobsend, preloads len of *addr into * the kernel to be sent out */ int kblob __P((int len, void *addr)); /* * see sendfile(2), but instead of the fd referencing a vnode it * references a fd returned from kblob */ int kblobsend __P((int, int, off_t, size_t, struct sf_hdtr *, off_t *, int)); questions comments flames? For the bike shed angle, I'm not particularly fond of the name 'kblob', any suggestions? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11:30: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 235E337B5DE for ; Mon, 19 Jun 2000 11:30:03 -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.3) with ESMTP id UAA46593; Mon, 19 Jun 2000 20:29:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 11:13:09 PDT." <20000619111309.E26801@fw.wintelcom.net> Date: Mon, 19 Jun 2000 20:29:49 +0200 Message-ID: <46591.961439389@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000619111309.E26801@fw.wintelcom.net>, Alfred Perlstein writes: >oops, you can find the preliminary kblob diffs over here: > >http://people.freebsd.org/~alfred/kblob/kblob-final.diff > >It's a new syscall, less overhead than sendfile and useful for >serving small chunks of data very quickly. Can't we combine it with sendfile and call it "sendobject" instead ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11:49:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 57C6237BD76 for ; Mon, 19 Jun 2000 11:49:18 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JIlFI14912; Mon, 19 Jun 2000 11:47:15 -0700 (PDT) Date: Mon, 19 Jun 2000 11:47:15 -0700 From: Alfred Perlstein To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619114715.G26801@fw.wintelcom.net> References: <20000619111309.E26801@fw.wintelcom.net> <46591.961439389@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <46591.961439389@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Jun 19, 2000 at 08:29:49PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [000619 11:30] wrote: > In message <20000619111309.E26801@fw.wintelcom.net>, Alfred Perlstein writes: > >oops, you can find the preliminary kblob diffs over here: > > > >http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > > >It's a new syscall, less overhead than sendfile and useful for > >serving small chunks of data very quickly. > > Can't we combine it with sendfile and call it "sendobject" instead ? Hmm, that's certainly possible, I can wrap the kblobsend syscall and not export it to userland and provide a sendobject facility that would automagically call the private kblobsend or sendfile depending on the descriptor passed in. I'll look into it. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11:52:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 9495137B5DE for ; Mon, 19 Jun 2000 11:52:13 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id UAA02412 for ; Mon, 19 Jun 2000 20:52:45 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006191852.UAA02412@grimreaper.grondar.za> To: arch@freebsd.org Subject: AOUT support for "make world"? Date: Mon, 19 Jun 2000 20:52:45 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I have a new PERL in the wings that I'd like to commit RSN. Question: do we still support a.out make worlds? I have _no_ way of testing them at the moment, and little inclination to even try. Perl has (had) a special case for a.out builds, and I'd like to remove this in favour of ELF-only. May I do this? M To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 11:55:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0A7E837BE3C for ; Mon, 19 Jun 2000 11:55:34 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id OAA39977; Mon, 19 Jun 2000 14:00:29 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 14:00:29 -0500 From: Jonathan Lemon To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619140029.D37084@prism.flugsvamp.com> References: <20000619111309.E26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000619111309.E26801@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 11:13:09AM -0700, Alfred Perlstein wrote: > A whole bunch of people were a bit upset about kblob but haven't > brought anything up that makes me not want to commit it. > > Now would be a good time to offer suggestions and critism before > I bring it in. I think that this is a bad attitude, it sounds more like "I've written this code, and want to bring it in no matter what other people think". Before you even consider bringing the code in, I think you need to address the points that have been brought up. The objections that I've seen (and agree with) are that the API is not flexible enough to cope with different usage scenarios. Creating a new API is not a small thing, and if we do that, then it would be nice to make sure that it is flexible enough to handle various things that we throw at it. The kblob API as proposed below appears to be too special purpose. IIRC, Ken pointed you to some papers that address this issue. I recall that the IOLite API was previously rejected for inclusion for various reasons. I have also pointed you to an alternate API, which is more flexible, while still providing the same functionality, and can repost that here if need be. I think that any notion of committing this should be held off until we have a chance to come to some kind of consensus on the issue. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 12:40: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1E13137B641 for ; Mon, 19 Jun 2000 12:39:57 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA79727; Mon, 19 Jun 2000 13:39:31 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Jun 2000 13:39:31 -0600 From: "Kenneth D. Merry" To: Jonathan Lemon Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619133931.A79532@panzer.kdm.org> References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619140029.D37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 02:00:29PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 14:00:29 -0500, Jonathan Lemon wrote: > On Mon, Jun 19, 2000 at 11:13:09AM -0700, Alfred Perlstein wrote: > > A whole bunch of people were a bit upset about kblob but haven't > > brought anything up that makes me not want to commit it. > > > > Now would be a good time to offer suggestions and critism before > > I bring it in. > > I think that this is a bad attitude, it sounds more like "I've > written this code, and want to bring it in no matter what other > people think". Before you even consider bringing the code in, > I think you need to address the points that have been brought up. > > The objections that I've seen (and agree with) are that the API > is not flexible enough to cope with different usage scenarios. > Creating a new API is not a small thing, and if we do that, then > it would be nice to make sure that it is flexible enough to > handle various things that we throw at it. The kblob API as > proposed below appears to be too special purpose. > > IIRC, Ken pointed you to some papers that address this issue. I > recall that the IOLite API was previously rejected for inclusion > for various reasons. I have also pointed you to an alternate API, > which is more flexible, while still providing the same functionality, > and can repost that here if need be. I would like to see something more generic as well, especially something that could work for both sending and receiving. Another thing that I would like to see is the ability to get notification of when the I/O is done, like async I/O. I think Jonathan's API is a little more generic than kblob, although I share some of Jonathan's reservations about using that much kva. I'd almost like the ability to allocate the buffers in userland, and then map them into the kernel and revoke the userland mapping, so the user process can't get to it while you're doing a send. You could do similar things on receive. A receive side API could work well with something like RDMA. (Here's a URL: ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt ) One problem is that allocating buffers in userland would work well for sends, but not as well for receives. So maybe both should be allowed? Anyway, those are just some ideas, I think there's some room for discussion here. > I think that any notion of committing this should be held off > until we have a chance to come to some kind of consensus on the > issue. Another point about the timeframe for deciding and committing both this and the accept filters -- a lot of people are away at Usenix, and last week a number of key developers were at the SMP gathering. (Some are going from one to the other, and therefore will have been away for more than a week.) I think we should hold off on this stuff until people have a chance to get back from Usenix and comment on it. I'll be heading to Usenix tomorrow, and if anyone would like to talk about this stuff in person, just let me know. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 12:47: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 5901137BBB6; Mon, 19 Jun 2000 12:47:06 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id A6FA449; Mon, 19 Jun 2000 15:46:56 -0400 (AST) Message-ID: <394E78B0.9B3C427A@vangelderen.org> Date: Mon, 19 Jun 2000 15:46:56 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , Dan Moschuk , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please References: <44778.961423462@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message , Dag-Erling Smorgrav writes: > >Poul-Henning Kamp writes: > >> In message , Dag-Erling Smorgrav writes: > >> > The idea of built-in hardware RNGs bothers me a little. [...] > >> And just because you went out and bought your RNG separately, what > >> difference would it make ? If an RNG has a fingerprint, you may > >> be identified by it, no matter where you bought it or how. > > > >Hmm, yes, that wasn't quite what I meant. I was actually thinking > >about purpose-made RNGs vs. custom-made (e.g. lava lamp + webcam), the > >idea being that with the latter, a) you know it doesn't contain an > >intentional steganographic fingerprint and b) you have complete > >control over the RNG and can vary its output in unpredictable ways > >(moving the camera, changing the background...) which hopefully defeat > >recognition without affecting randomness. > > Run your Intel built RNG through a cryptographic quality hash ? > > If you frustrate the output by running it though MD5 and feed a few > random bits from your keyboard interrupt in there as well ? It's not that simple but the problem can be dealt with. This is what constructions like Yarrow and Gutmann-PRNG are designed for and hence what MarkM is taking care of. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 12:54:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F2DE437BD89 for ; Mon, 19 Jun 2000 12:54:06 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JJrjI16650; Mon, 19 Jun 2000 12:53:45 -0700 (PDT) Date: Mon, 19 Jun 2000 12:53:45 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619125345.H26801@fw.wintelcom.net> References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619140029.D37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 02:00:29PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [000619 11:55] wrote: > On Mon, Jun 19, 2000 at 11:13:09AM -0700, Alfred Perlstein wrote: > > A whole bunch of people were a bit upset about kblob but haven't > > brought anything up that makes me not want to commit it. > > > > Now would be a good time to offer suggestions and critism before > > I bring it in. > > I think that this is a bad attitude, it sounds more like "I've > written this code, and want to bring it in no matter what other > people think". Before you even consider bringing the code in, > I think you need to address the points that have been brought up. If my email seemed a bit impatient and harsh, that was my intention. I have no desire deal with another accept filter mess because I can't provoke a repsonse until I actually commit the code. > The objections that I've seen (and agree with) are that the API > is not flexible enough to cope with different usage scenarios. > Creating a new API is not a small thing, and if we do that, then > it would be nice to make sure that it is flexible enough to > handle various things that we throw at it. The kblob API as > proposed below appears to be too special purpose. I don't want the overhead of a complex API, I want something simple, if someone later wants to expand on kblob and not break its performance I won't stand in the way. I'd like to see a way to "recycle" and chain kblobs together in the future, but that's not going to happen today. There's nothing wrong with the current kblob implementation that makes it unflexible, it's just that the flexible hooks aren't in place yet because I can't think of any. In fact, I'd happily take someone else's kblob implementation, the only problem is that I've been waiting nearly 9 months for one and nothing has popped up. > IIRC, Ken pointed you to some papers that address this issue. I > recall that the IOLite API was previously rejected for inclusion > for various reasons. I have also pointed you to an alternate API, > which is more flexible, while still providing the same functionality, > and can repost that here if need be. Yes, please do. > I think that any notion of committing this should be held off > until we have a chance to come to some kind of consensus on the > issue. I really would rather stay away from something so complex that the overhead of usage causes problems, the whole idea behind kblob is _just_ pre-loading data into the kernel so you can send it. If i wanted to do IO-lite I'd be using sendfile(). I don't want to propose some giant api, and I have no desire to work on one and put it up for scrutinty so it can be knit-picked to death, I just don't have the time. If something as complex as IO-Lite was rejected then it just goes to show you how you can't please all of the people all of the time. I'm also really getting annoyed that people are complaining about performance "hacks", we _need_ "hacks" like sendfile and kblob to do zero copy. I'm getting so discouraged over here that just keeping my changes private would really be a lot simpler. The only unfortunate effect is that the users never get the same advantages I will, then again I could just commit it because it's what we need. It doesn't bother you at all that cdrom.com can push 100mbit and support 6000 users on FreeBSD but Joe Average FreeBSD User can't because the hacks used aren't available? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 13: 8: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sydney.worldwide.lemis.com (static224.conference.usenix.org [209.179.127.224]) by hub.freebsd.org (Postfix) with ESMTP id A5F3137BD6B for ; Mon, 19 Jun 2000 13:07:53 -0700 (PDT) (envelope-from grog@sydney.worldwide.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id NAA66003; Mon, 19 Jun 2000 13:07:21 -0700 (PDT) (envelope-from grog) Date: Mon, 19 Jun 2000 13:07:21 -0700 From: Greg Lehey To: Matthew Jacob Cc: Jason Evans , Chia-liang Kao , freebsd-arch@FreeBSD.ORG Subject: Explaining intentions (was: kernel thread support) Message-ID: <20000619130721.A65971@sydney.worldwide.lemis.com> References: <20000616144259.Q47268@blitz.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 16 June 2000 at 16:41:34 -0700, Matt Jacob wrote: > > > On 16 Jun 2000, Jason Evans wrote: > >> On Fri, Jun 16, 2000 at 03:19:56AM +0800, Chia-liang Kao wrote: >>> o Is the model for the scenario described in >>> >>> http://www.freebsd.org/~julian/threads/ >>> >>> the final design decision? (then I think it shall be well documented.) >> >> We have made some refinements to the model, but in general, it is the same >> idea. Daniel Eischen and I are working on a paper that gives a reasonable >> overview of the current design. Hopefully we can get it to a postable form >> in the near future. However, we're probably going to concern ourselves >> primarily with actually doing the work, rather than telling everybody >> beforehand exactly how we're doing it. > > Can please spend some effort into saying what the intents and architecture is > in the paper? > > The current newbus stuff and CAM stuff horribly suffer from the fact that > there aren't such documents. I'm currently tearing my hair out trying to > intuit what should have been written down. Agreed entirely. We're now frequently seeing patches and even design documents, but we seldom hear about *why* people want to make specific changes or design decisions. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 13: 9:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 18C7E37BD6B for ; Mon, 19 Jun 2000 13:09:35 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JK9B317095; Mon, 19 Jun 2000 13:09:11 -0700 (PDT) Date: Mon, 19 Jun 2000 13:09:11 -0700 From: Alfred Perlstein To: "Kenneth D. Merry" Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619130911.I26801@fw.wintelcom.net> References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com> <20000619133931.A79532@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619133931.A79532@panzer.kdm.org>; from ken@kdm.org on Mon, Jun 19, 2000 at 01:39:31PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kenneth D. Merry [000619 12:40] wrote: > On Mon, Jun 19, 2000 at 14:00:29 -0500, Jonathan Lemon wrote: > > On Mon, Jun 19, 2000 at 11:13:09AM -0700, Alfred Perlstein wrote: > > > A whole bunch of people were a bit upset about kblob but haven't > > > brought anything up that makes me not want to commit it. > > > > > > Now would be a good time to offer suggestions and critism before > > > I bring it in. > > > > I think that this is a bad attitude, it sounds more like "I've > > written this code, and want to bring it in no matter what other > > people think". Before you even consider bringing the code in, > > I think you need to address the points that have been brought up. > > > > The objections that I've seen (and agree with) are that the API > > is not flexible enough to cope with different usage scenarios. > > Creating a new API is not a small thing, and if we do that, then > > it would be nice to make sure that it is flexible enough to > > handle various things that we throw at it. The kblob API as > > proposed below appears to be too special purpose. > > > > IIRC, Ken pointed you to some papers that address this issue. I > > recall that the IOLite API was previously rejected for inclusion > > for various reasons. I have also pointed you to an alternate API, > > which is more flexible, while still providing the same functionality, > > and can repost that here if need be. > > I would like to see something more generic as well, especially something > that could work for both sending and receiving. As would I. > Another thing that I would like to see is the ability to get notification > of when the I/O is done, like async I/O. That can be easily put into kblob at the expense of some performance, however it would require a side allocation per send which negates the whole purpose of it as a low overhead extremely fast way to send data. > I think Jonathan's API is a little more generic than kblob, although I > share some of Jonathan's reservations about using that much kva. I haven't seen Johnathan's API. > I'd almost like the ability to allocate the buffers in userland, and then > map them into the kernel and revoke the userland mapping, so the user > process can't get to it while you're doing a send. So use sendfile. :) > You could do similar things on receive. A receive side API could work well > with something like RDMA. (Here's a URL: > ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt > ) You've got to be kidding if you think I'm going to draft an RFC to add bits to the TCP header. > One problem is that allocating buffers in userland would work well for > sends, but not as well for receives. So maybe both should be allowed? Er.. What's the point of a many to one mapping for a recieve buffer? The only way to do this would be to allow the kernel's mbuf map to be map'd in by a user process, which doesn't make much sense. > Anyway, those are just some ideas, I think there's some room for > discussion here. I'd rather not, I've already discussed it a lot and many people want this functionality. The people that want more flexibility don't realize that the interface is easily extendable (or don't want to extend it themselves), and the people that don't like it on principle don't see the need for changes to get real world performance increases. > > I think that any notion of committing this should be held off > > until we have a chance to come to some kind of consensus on the > > issue. > > Another point about the timeframe for deciding and committing both this and > the accept filters -- a lot of people are away at Usenix, and last week a > number of key developers were at the SMP gathering. (Some are going from > one to the other, and therefore will have been away for more than a week.) I was there, many people liked the ideas I'm presenting. > I think we should hold off on this stuff until people have a chance to get > back from Usenix and comment on it. > > I'll be heading to Usenix tomorrow, and if anyone would like to talk about > this stuff in person, just let me know. I'll be there as well. Have some code handy that implememnts this and we'll discuss it, if not just grabbing a beer would be fun. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 13:35: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1E26C37B5E4 for ; Mon, 19 Jun 2000 13:35:02 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA80296; Mon, 19 Jun 2000 14:34:37 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Jun 2000 14:34:37 -0600 From: "Kenneth D. Merry" To: Alfred Perlstein Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619143437.A80133@panzer.kdm.org> References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com> <20000619133931.A79532@panzer.kdm.org> <20000619130911.I26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619130911.I26801@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jun 19, 2000 at 01:09:11PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > * Kenneth D. Merry [000619 12:40] wrote: > > I would like to see something more generic as well, especially something > > that could work for both sending and receiving. > > As would I. > > > Another thing that I would like to see is the ability to get notification > > of when the I/O is done, like async I/O. > > That can be easily put into kblob at the expense of some performance, > however it would require a side allocation per send which negates > the whole purpose of it as a low overhead extremely fast way to send > data. This gets into the generic API versus specific API issue. > > I think Jonathan's API is a little more generic than kblob, although I > > share some of Jonathan's reservations about using that much kva. > > I haven't seen Johnathan's API. I think he posted the gist of it to committers, I'm sure he'll repost it to -arch. > > I'd almost like the ability to allocate the buffers in userland, and then > > map them into the kernel and revoke the userland mapping, so the user > > process can't get to it while you're doing a send. > > So use sendfile. :) That only works for files. :) > > You could do similar things on receive. A receive side API could work well > > with something like RDMA. (Here's a URL: > > ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt > > ) > > You've got to be kidding if you think I'm going to draft an RFC to add > bits to the TCP header. That wasn't the point. There's already a draft spec, and therefore no need to write another, unless the draft isn't going to work. (I'm not saying that RDMA is perfect, I haven't studied it enough to be able to give it a conclusive thumbs up. The idea is a good one, though.) Anyway, what I'm getting at is you could use something like RDMA to DMA data from the NIC directly into user-supplied buffers. Another possibility for a buffer-type receive interface is to receive it into generic kernel memory, and then pass those buffers out in a nice "package". That would be similar in effect to the page flipping code in the zero copy code I posted, except that there wouldn't be a user page to throw away, and there would be no size and alignment constraints. > > One problem is that allocating buffers in userland would work well for > > sends, but not as well for receives. So maybe both should be allowed? > > Er.. > > What's the point of a many to one mapping for a recieve buffer? I'm not talking about a one to many mapping. Again, I'd rather see a generic API, and kblob is a rather specific API. > The only way to do this would be to allow the kernel's mbuf map to > be map'd in by a user process, which doesn't make much sense. Actually, the zero copy receive code that Drew Gallatin wrote (and I posted on Friday) page flips kernel pages into userland, and recycles the userland pages. > > Anyway, those are just some ideas, I think there's some room for > > discussion here. > > I'd rather not, I've already discussed it a lot and many people > want this functionality. The people that want more flexibility > don't realize that the interface is easily extendable (or don't > want to extend it themselves), and the people that don't like it > on principle don't see the need for changes to get real world > performance increases. I'd be more in favor of doing it right the first time, rather than continually revising and extending the interface. It won't be trivial to do, but I think it should be possible to get great performance gains without having the limited API that would have to be later expanded. > > > I think that any notion of committing this should be held off > > > until we have a chance to come to some kind of consensus on the > > > issue. > > > > Another point about the timeframe for deciding and committing both this and > > the accept filters -- a lot of people are away at Usenix, and last week a > > number of key developers were at the SMP gathering. (Some are going from > > one to the other, and therefore will have been away for more than a week.) > > I was there, many people liked the ideas I'm presenting. > > > I think we should hold off on this stuff until people have a chance to get > > back from Usenix and comment on it. > > > > I'll be heading to Usenix tomorrow, and if anyone would like to talk about > > this stuff in person, just let me know. > > I'll be there as well. Have some code handy that implememnts this > and we'll discuss it, if not just grabbing a beer would be fun. :) Believe it or not, I've got code that behaves in more or less the manner I'm describing. That's part of the reason I'm interested in this subject at all. It is effectively a zero copy receive and send system with async I/O semantics. The problem is that it was implemented for a custom hardware and software environment, and the interface is expedient, not elegant. Anyway, for those reasons, it will never be released. The parts of that work that are generally useful are included in the code I posted on Friday. But yeah, I'd like to get together and yak about this stuff. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 13:40:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id A5C8A37B5B9; Mon, 19 Jun 2000 13:40:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA42720; Mon, 19 Jun 2000 13:40:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 19 Jun 2000 13:40:29 -0700 (PDT) From: Kris Kennaway To: Dag-Erling Smorgrav Cc: Poul-Henning Kamp , Dan Moschuk , "Jeroen C. van Gelderen" , Mark Murray , arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19 Jun 2000, Dag-Erling Smorgrav wrote: > But this is all guesses and gut feelings, and experience teaches us > that guesses and gut feelings are often - if not always - wrong when > it comes to crypto and randomness, so feel free to ignore me. In this usage it won't matter, as long as the thermal generator is "mostly" random (i.e. the entropy estimate of how much random data it actually contains is approximately correct), because the bytes aren't used directly but fed into the /dev/random entropy pool and hashed up, which would tend to remove any signature. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 13:58:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 8B42537B748 for ; Mon, 19 Jun 2000 13:58:16 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA09596; Mon, 19 Jun 2000 14:03:07 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192103.OAA09596@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 14:34:37 MDT." <20000619143437.A80133@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 14:03:07 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think this entire discussion has gone just a little bit too far. The basic kblob architecture is sound, and does what most people are looking for in this context. IMO, it should probably be called socketblob, or something else equally boring, but that's neither here nor there. Some comments: > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > * Kenneth D. Merry [000619 12:40] wrote: > > > I would like to see something more generic as well, especially something > > > that could work for both sending and receiving. > > > > As would I. Receiving into a kernel-side buffer is somewhat pointless, really. You want stuff to go into userspace. This is an output accelerator, not a new I/O method. > > > Another thing that I would like to see is the ability to get notification > > > of when the I/O is done, like async I/O. > > > > That can be easily put into kblob at the expense of some performance, > > however it would require a side allocation per send which negates > > the whole purpose of it as a low overhead extremely fast way to send > > data. > > This gets into the generic API versus specific API issue. It would be fairly trivial to add a mechanism for generating kevents when points in the socket transmit buffer are reached, which would then allow you to do this. I don't think that it should be added to the kblob code as a specific hack, however. > > > I'd almost like the ability to allocate the buffers in userland, and then > > > map them into the kernel and revoke the userland mapping, so the user > > > process can't get to it while you're doing a send. > > > > So use sendfile. :) > > That only works for files. :) Since the goal here is to copy the object once into the kernel, and then never move it across the userspace:kernel boundary again, the map/unmap proposal seems just a little bit silly, really. It's a complex optimisation entirely off the critical path, and fails to consider the problems that kblob is actually trying to address. > Anyway, what I'm getting at is you could use something like RDMA to DMA > data from the NIC directly into user-supplied buffers. This has little or nothing to do with kblob. > > > Anyway, those are just some ideas, I think there's some room for > > > discussion here. > > > > I'd rather not, I've already discussed it a lot and many people > > want this functionality. The people that want more flexibility > > don't realize that the interface is easily extendable (or don't > > want to extend it themselves), and the people that don't like it > > on principle don't see the need for changes to get real world > > performance increases. > > I'd be more in favor of doing it right the first time, rather than > continually revising and extending the interface. As it stands, kblob is "right". It's lean and to-the-point. I'd rather not see it undergo second-system syndrome before it's even made it to first base. If you plan to implement an efficient zero-copy network I/O interface, then it should be done from scratch, not as a wart on the side of what is really fairly specific feature. One point that Alfred may have overlooked is that apart from the resource limit issues, kblob could be implemented entirely as a loadable syscall. (Then you could just compile the limit in, for slightly reduced flexibility.) This would address the "don't commit to a restricted API" issues while still getting the code out and used where it's needed. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 14:15:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 661DF37B509; Mon, 19 Jun 2000 14:15:18 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA80938; Mon, 19 Jun 2000 15:15:17 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Jun 2000 15:15:17 -0600 From: "Kenneth D. Merry" To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619151517.A80732@panzer.kdm.org> References: <20000619143437.A80133@panzer.kdm.org> <200006192103.OAA09596@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006192103.OAA09596@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Jun 19, 2000 at 02:03:07PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 14:03:07 -0700, Mike Smith wrote: > > I think this entire discussion has gone just a little bit too far. I don't think so. You and Alfred seem to be convinced of the merits of doing this in a specific (versus generic) manner, but Jonathan and I obviously haven't been convinced. > The basic kblob architecture is sound, and does what most people are > looking for in this context. IMO, it should probably be called > socketblob, or something else equally boring, but that's neither here nor > there. What are people planning on doing with this API? Is this intended as a web server speedup of some sort? You could have the same effect as kblob with a generic API. > Some comments: > > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > I would like to see something more generic as well, especially something > > > > that could work for both sending and receiving. > > > > > > As would I. > > Receiving into a kernel-side buffer is somewhat pointless, really. You > want stuff to go into userspace. This is an output accelerator, not a > new I/O method. It isn't pointless at all. Again, you want a specific API, I'd rather see a generic API that could do what kblob can, > > > > I'd almost like the ability to allocate the buffers in userland, and then > > > > map them into the kernel and revoke the userland mapping, so the user > > > > process can't get to it while you're doing a send. > > > > > > So use sendfile. :) > > > > That only works for files. :) > > Since the goal here is to copy the object once into the kernel, and then > never move it across the userspace:kernel boundary again, the map/unmap > proposal seems just a little bit silly, really. It's a complex > optimisation entirely off the critical path, and fails to consider the > problems that kblob is actually trying to address. > > > Anyway, what I'm getting at is you could use something like RDMA to DMA > > data from the NIC directly into user-supplied buffers. > > This has little or nothing to do with kblob. Of course not, it has to do with a more generic API for doing zero copy with packaged message blocks. > > > > Anyway, those are just some ideas, I think there's some room for > > > > discussion here. > > > > > > I'd rather not, I've already discussed it a lot and many people > > > want this functionality. The people that want more flexibility > > > don't realize that the interface is easily extendable (or don't > > > want to extend it themselves), and the people that don't like it > > > on principle don't see the need for changes to get real world > > > performance increases. > > > > I'd be more in favor of doing it right the first time, rather than > > continually revising and extending the interface. > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > not see it undergo second-system syndrome before it's even made it to > first base. If you plan to implement an efficient zero-copy network I/O > interface, then it should be done from scratch, not as a wart on the side > of what is really fairly specific feature. I agree that a zero copy API should be done right from scratch. What I'm not sure of, though, is why we're proposing something that's quite pointedly a narrow interface, when we could get much the same performance out of a generic API, along with wider usability. It might help a bit if y'all would explain the intended use for kblob, and why it has to go into the tree ASAP. > One point that Alfred may have overlooked is that apart from the resource > limit issues, kblob could be implemented entirely as a loadable syscall. > (Then you could just compile the limit in, for slightly reduced > flexibility.) This would address the "don't commit to a restricted API" > issues while still getting the code out and used where it's needed. Again, can you elaborate on the uses of kblob? Is there code that uses it? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 14:38:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6FAD137B6C3; Mon, 19 Jun 2000 14:38:31 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id QAA44901; Mon, 19 Jun 2000 16:43:29 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 16:43:29 -0500 From: Jonathan Lemon To: Mike Smith Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619164329.F37084@prism.flugsvamp.com> References: <20000619143437.A80133@panzer.kdm.org> <200006192103.OAA09596@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006192103.OAA09596@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 02:03:07PM -0700, Mike Smith wrote: > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > I would like to see something more generic as well, especially something > > > > that could work for both sending and receiving. > > > > > > As would I. > > Receiving into a kernel-side buffer is somewhat pointless, really. You > want stuff to go into userspace. This is an output accelerator, not a > new I/O method. *cough*. Are you sure about that? An output accelerator is a new I/O method regardless of what you want to call it. And for a lot of cases you don't need stuff to actually go to user space. In many situations, you will receive data, perform operations on a very small part of it, and then send the data elsewhere, whether to disk or network. In this case, why bother sending things to user space if you're just going to end up sending them back out again? I can assure you that receiving into a kernel-side buffer is a win in this case. Kblob only addresses part of the problem. Also, if I want to send data from disk -> network, with the kblob API, I essentially have the following sequence of calls: read(fd, address, length) kblob(address, length) kblobsend(...) which is to say, the data is copied from disk -> userspace (assuming direct I/O) userspace -> kernel, kernel -> network. Why shouldn't I be able to bypass second copy entirely and do: disk -> kernel (data now in kernel 'blob') kernel -> network Again, this is not addressed in the kblob API. Don't throw sendfile() up as an example, because I want the data to be kept in the kernel after being read from disk. > > > > Another thing that I would like to see is the ability to get notification > > > > of when the I/O is done, like async I/O. > > > > > > That can be easily put into kblob at the expense of some performance, > > > however it would require a side allocation per send which negates > > > the whole purpose of it as a low overhead extremely fast way to send > > > data. > > > > This gets into the generic API versus specific API issue. > > It would be fairly trivial to add a mechanism for generating kevents when > points in the socket transmit buffer are reached, which would then allow > you to do this. I don't think that it should be added to the kblob code > as a specific hack, however. Actually, I would prefer that you register a kevent on the send() or recv() call, so that an event can be generated which contains the entire state of the transfer. But that's kind of orthogonal to the issue. > > > > Anyway, those are just some ideas, I think there's some room for > > > > discussion here. > > > > > > I'd rather not, I've already discussed it a lot and many people > > > want this functionality. The people that want more flexibility > > > don't realize that the interface is easily extendable (or don't > > > want to extend it themselves), and the people that don't like it > > > on principle don't see the need for changes to get real world > > > performance increases. > > > > I'd be more in favor of doing it right the first time, rather than > > continually revising and extending the interface. > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > not see it undergo second-system syndrome before it's even made it to > first base. If you plan to implement an efficient zero-copy network I/O > interface, then it should be done from scratch, not as a wart on the side > of what is really fairly specific feature. I disagree on your definition of "right". I would argue that if we're going to implement an I/O accelerator of any form, it should not be so specific purpose that it precludes any other possible applications. - How do I receive data _into_ a kblob (either from a network or a disk?) - Once data is in a kblob, is there any possibility of editing it? Do I have to throw it all away and reload if I want to make a minor change to the data? - Can I retrieve data from a kblob? - Can kblobs be transferred to disk? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 14:45: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id EE5D337B807; Mon, 19 Jun 2000 14:44:55 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA09723; Mon, 19 Jun 2000 14:49:46 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192149.OAA09723@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:15:17 MDT." <20000619151517.A80732@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 14:49:46 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 19, 2000 at 14:03:07 -0700, Mike Smith wrote: > > > > I think this entire discussion has gone just a little bit too far. > > I don't think so. You and Alfred seem to be convinced of the merits of > doing this in a specific (versus generic) manner, but Jonathan and I > obviously haven't been convinced. I didn't say "you think this conversation has gone too far" - your position is pretty obvious. I was simply stating mine, ok? > > The basic kblob architecture is sound, and does what most people are > > looking for in this context. IMO, it should probably be called > > socketblob, or something else equally boring, but that's neither here nor > > there. > > What are people planning on doing with this API? Is this intended as a web > server speedup of some sort? Yes. There's a niche for webservers that serve a relatively small quantity of static content, very rapidly. Think "small images". > You could have the same effect as kblob with a generic API. The kblob interface *is* a "generic API". It is in no way "specific" to this application. > > Some comments: > > > > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > > I would like to see something more generic as well, especially something > > > > > that could work for both sending and receiving. > > > > > > > > As would I. > > > > Receiving into a kernel-side buffer is somewhat pointless, really. You > > want stuff to go into userspace. This is an output accelerator, not a > > new I/O method. > > It isn't pointless at all. > > Again, you want a specific API, I'd rather see a generic API that could do > what kblob can, You haven't described any such generic API. Zero-copy user-space network I/O doesn't even begin to consider the issues that kblob addresses. > What I'm not sure of, though, is why we're proposing something that's quite > pointedly a narrow interface, when we could get much the same performance > out of a generic API, along with wider usability. Actually, in the target application, I wouldn't expect anything like the same sort of performance. With all the VM operations involved in the zero-copy API, it's well-suited to applications that generate dynamic content, but still rather more expensive for static content. > > One point that Alfred may have overlooked is that apart from the resource > > limit issues, kblob could be implemented entirely as a loadable syscall. > > (Then you could just compile the limit in, for slightly reduced > > flexibility.) This would address the "don't commit to a restricted API" > > issues while still getting the code out and used where it's needed. > > Again, can you elaborate on the uses of kblob? Is there code that uses it? Any service that, in response to a query, needs to send from a small collection of static data down a network socket. The common use is static content serving for http. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 14:52:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id BE6A037B682 for ; Mon, 19 Jun 2000 14:52:50 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA09767; Mon, 19 Jun 2000 14:56:47 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192156.OAA09767@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 16:43:29 CDT." <20000619164329.F37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 14:56:47 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 19, 2000 at 02:03:07PM -0700, Mike Smith wrote: > > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > > I would like to see something more generic as well, especially something > > > > > that could work for both sending and receiving. > > > > > > > > As would I. > > > > Receiving into a kernel-side buffer is somewhat pointless, really. You > > want stuff to go into userspace. This is an output accelerator, not a > > new I/O method. > > *cough*. Are you sure about that? An output accelerator is a new I/O > method regardless of what you want to call it. *sigh* Kblob is not a new output method. It's a bolt-on to the 'write' interface, as opposed to, say, zero-copy I/O. > And for a lot of cases > you don't need stuff to actually go to user space. In many situations, > you will receive data, perform operations on a very small part of it, > and then send the data elsewhere, whether to disk or network. However, for a user-space application to do this, you want it to come out to user-space, right? Irregardless, this is irrelevant in this context. > Kblob only addresses part of the problem. Kblob addresses exactly one problem, and does it in an expedient fashion. > Also, if I want to send data from disk -> network, with the kblob > API, I essentially have the following sequence of calls: > > read(fd, address, length) > kblob(address, length) > kblobsend(...) > > which is to say, the data is copied from > disk -> userspace (assuming direct I/O) > userspace -> kernel, > kernel -> network. > > Why shouldn't I be able to bypass second copy entirely and do: > disk -> kernel (data now in kernel 'blob') > kernel -> network Because this isn't what you use kblob for. That's what you use sendfile for. The entire use of the kblob API is: user -> kernel kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network etc., > Again, this is not addressed in the kblob API. Don't throw sendfile() > up as an example, because I want the data to be kept in the kernel > after being read from disk. It is. You remember that thing called the buffer cache? > > > I'd be more in favor of doing it right the first time, rather than > > > continually revising and extending the interface. > > > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > > not see it undergo second-system syndrome before it's even made it to > > first base. If you plan to implement an efficient zero-copy network I/O > > interface, then it should be done from scratch, not as a wart on the side > > of what is really fairly specific feature. > > I disagree on your definition of "right". I would argue that if we're > going to implement an I/O accelerator of any form, it should not be so > specific purpose that it precludes any other possible applications. > > - How do I receive data _into_ a kblob (either from a network or a disk?) You don't. It's not relevant to this application. > - Once data is in a kblob, is there any possibility of editing it? > Do I have to throw it all away and reload if I want to make a minor > change to the data? It's static content. > - Can I retrieve data from a kblob? No. The kblob is a send-only acceleration buffer. > - Can kblobs be transferred to disk? No. Since the data in a kblob came from userspace, and can't be modified in the kernel, this would be pointless. Again, folks; kblob is an optimisation for a very common performance case, not a network engineer's wet dream. It's meant to address a real-world problem in an efficient fashion. If you have a Grand Plan for something else, that's great - I'd recommend you keep working on it. In the meantime, there are a lot of people that can do a lot of useful things with kblob as-is, and knocking it down just because it's not _your_ idea of the Perfect In-Kernel Network Container Object is kinda silly. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15: 9:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id 141EC37B6C4 for ; Mon, 19 Jun 2000 15:09:44 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id PAA15403; Mon, 19 Jun 2000 15:09:41 -0700 (PDT) (envelope-from sef) Date: Mon, 19 Jun 2000 15:09:41 -0700 (PDT) From: Sean Eric Fagan Message-Id: <200006192209.PAA15403@kithrup.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Subject: Re: kblob discussion. In-Reply-To: <200006192156.OAA09767.kithrup.freebsd.freebsd-arch@mass.osd.bsdi.com> References: Your message of "Mon, 19 Jun 2000 16:43:29 CDT." <20000619164329.F37084@prism.flugsvamp.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200006192156.OAA09767.kithrup.freebsd.freebsd-arch@mass.osd.bsdi.com> you write: >Again, folks; kblob is an optimisation for a very common performance >case, not a network engineer's wet dream. It's meant to address a >real-world problem in an efficient fashion. Larry McVoy did this kind of thing for SGI, and wrote a very nice paper or two about it for UseNIX. Has anyone checked those out? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:10:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 0429937B735 for ; Mon, 19 Jun 2000 15:10:33 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id PAA03252; Mon, 19 Jun 2000 15:10:27 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Alfred Perlstein Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 12:53:45 PDT." <20000619125345.H26801@fw.wintelcom.net> Date: Mon, 19 Jun 2000 15:10:27 -0700 Message-ID: <3249.961452627@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It doesn't bother you at all that cdrom.com can push 100mbit > and support 6000 users on FreeBSD but Joe Average FreeBSD User > can't because the hacks used aren't available? Huh? What makes you think that cdrom.com uses "special hacks" to get its performance? Have you actually talked to David Greenman about this lately? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:15:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0CBBA37B7BE; Mon, 19 Jun 2000 15:15:43 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id RAA46236; Mon, 19 Jun 2000 17:20:41 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 17:20:41 -0500 From: Jonathan Lemon To: Mike Smith Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619172041.G37084@prism.flugsvamp.com> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006192156.OAA09767@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 02:56:47PM -0700, Mike Smith wrote: > > On Mon, Jun 19, 2000 at 02:03:07PM -0700, Mike Smith wrote: > > > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > > > I would like to see something more generic as well, especially something > > > > > > that could work for both sending and receiving. > > > > > > > > > > As would I. > > > > > > Receiving into a kernel-side buffer is somewhat pointless, really. You > > > want stuff to go into userspace. This is an output accelerator, not a > > > new I/O method. > > > > *cough*. Are you sure about that? An output accelerator is a new I/O > > method regardless of what you want to call it. > > *sigh* > > Kblob is not a new output method. It's a bolt-on to the 'write' > interface, as opposed to, say, zero-copy I/O. Yes, it is a "bolt-on" thing, not a well designed item. And as far as "zero-copy" goes, I would consider that a fairly overloaded term. Here, I'm applying it to anything that saves copies, not just a magical method of getting data between user and kernel spaces. > > And for a lot of cases > > you don't need stuff to actually go to user space. In many situations, > > you will receive data, perform operations on a very small part of it, > > and then send the data elsewhere, whether to disk or network. > > However, for a user-space application to do this, you want it to come out > to user-space, right? No. You cut out what I wrote - you may only need a very small part of the data to actually go to user space. > Irregardless, this is irrelevant in this context. Not irrelevant; you're not looking at the big picture here. > > Kblob only addresses part of the problem. > > Kblob addresses exactly one problem, and does it in an expedient fashion. Exactly, so my statement stands: it only addresses a small part of the problem. > > Also, if I want to send data from disk -> network, with the kblob > > API, I essentially have the following sequence of calls: > > > > read(fd, address, length) > > kblob(address, length) > > kblobsend(...) > > > > which is to say, the data is copied from > > disk -> userspace (assuming direct I/O) > > userspace -> kernel, > > kernel -> network. > > > > Why shouldn't I be able to bypass second copy entirely and do: > > disk -> kernel (data now in kernel 'blob') > > kernel -> network > > Because this isn't what you use kblob for. That's what you use sendfile > for. But sendfile doesn't leave the data cached in kernel space for reuse, so it isn't suitable for this. > The entire use of the kblob API is: > > user -> kernel > > kernel -> network > kernel -> network > kernel -> network > kernel -> network > kernel -> network > kernel -> network > kernel -> network > etc., And you have to get the data into user space first, when the data may be coming from disk. Thus you incur one copy into userspace first, when a better API might avoid it altogether. I *know* what kblob is designed for, and I'm telling you that the API is limiting, and will not be suitable for what I have. > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > up as an example, because I want the data to be kept in the kernel > > after being read from disk. > > It is. You remember that thing called the buffer cache? Not applicable here. If it was, why the heck aren't you using sendfile in the first place and relying on the kernel to keep the file cached? Hmm? If that was the way things worked, why isn't sendfile() good enough? > > > > I'd be more in favor of doing it right the first time, rather than > > > > continually revising and extending the interface. > > > > > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > > > not see it undergo second-system syndrome before it's even made it to > > > first base. If you plan to implement an efficient zero-copy network I/O > > > interface, then it should be done from scratch, not as a wart on the side > > > of what is really fairly specific feature. > > > > I disagree on your definition of "right". I would argue that if we're > > going to implement an I/O accelerator of any form, it should not be so > > specific purpose that it precludes any other possible applications. > > > > - How do I receive data _into_ a kblob (either from a network or a disk?) > > You don't. It's not relevant to this application. > > > - Once data is in a kblob, is there any possibility of editing it? > > Do I have to throw it all away and reload if I want to make a minor > > change to the data? > > It's static content. > > > - Can I retrieve data from a kblob? > > No. The kblob is a send-only acceleration buffer. > > > - Can kblobs be transferred to disk? > > No. Since the data in a kblob came from userspace, and can't be modified > in the kernel, this would be pointless. Exactly. You're looking at kblob as a "static send-only buffer which comes from user space". I'm looking at kblob as an "in-kernel object cache". The two views are _NOT_ that far apart, and with a little API help, the current code can be made much more flexible. Why are you opposed to that? > Again, folks; kblob is an optimisation for a very common performance > case, not a network engineer's wet dream. It's meant to address a > real-world problem in an efficient fashion. It is a narrow optimization for a specific problem. > If you have a Grand Plan for something else, that's great - I'd recommend > you keep working on it. In the meantime, there are a lot of people that > can do a lot of useful things with kblob as-is, and knocking it down just > because it's not _your_ idea of the Perfect In-Kernel Network Container > Object is kinda silly. Well, with a little more work, we can get something that is more applicable to a wider audience, rather than focusing on your single specific performance problem. Putting on blinders to the wider problem simply because your current code doesn't address it strikes me as kind of foolish. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:18:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6961737B74D for ; Mon, 19 Jun 2000 15:18:33 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JMIA720759; Mon, 19 Jun 2000 15:18:10 -0700 (PDT) Date: Mon, 19 Jun 2000 15:18:10 -0700 From: Alfred Perlstein To: "Jordan K. Hubbard" Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619151809.C17420@fw.wintelcom.net> References: <20000619125345.H26801@fw.wintelcom.net> <3249.961452627@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3249.961452627@localhost>; from jkh@zippy.osd.bsdi.com on Mon, Jun 19, 2000 at 03:10:27PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan K. Hubbard [000619 15:10] wrote: > > It doesn't bother you at all that cdrom.com can push 100mbit > > and support 6000 users on FreeBSD but Joe Average FreeBSD User > > can't because the hacks used aren't available? > > Huh? What makes you think that cdrom.com uses "special hacks" to get > its performance? Have you actually talked to David Greenman about > this lately? I'm quite sure cdrom.com has at least a kernel address space hack. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:25:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id AC81737B653; Mon, 19 Jun 2000 15:25:24 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA81702; Mon, 19 Jun 2000 16:25:22 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Jun 2000 16:25:22 -0600 From: "Kenneth D. Merry" To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619162522.A81338@panzer.kdm.org> References: <20000619151517.A80732@panzer.kdm.org> <200006192149.OAA09723@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006192149.OAA09723@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Jun 19, 2000 at 02:49:46PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 14:49:46 -0700, Mike Smith wrote: > > On Mon, Jun 19, 2000 at 14:03:07 -0700, Mike Smith wrote: > > > > > > I think this entire discussion has gone just a little bit too far. > > > > I don't think so. You and Alfred seem to be convinced of the merits of > > doing this in a specific (versus generic) manner, but Jonathan and I > > obviously haven't been convinced. > > I didn't say "you think this conversation has gone too far" - your > position is pretty obvious. I was simply stating mine, ok? Okay. > > > The basic kblob architecture is sound, and does what most people are > > > looking for in this context. IMO, it should probably be called > > > socketblob, or something else equally boring, but that's neither here nor > > > there. > > > > What are people planning on doing with this API? Is this intended as a web > > server speedup of some sort? > > Yes. There's a niche for webservers that serve a relatively small > quantity of static content, very rapidly. Think "small images". Okay. > > You could have the same effect as kblob with a generic API. > > The kblob interface *is* a "generic API". It is in no way "specific" to > this application. We're using two different definitions of generic here. What you mean by "generic" is that more than one application can use the API. That is certainly true. What I mean by "generic" is that the API is useful for more than sending a small set of static content over and over again. > > > Receiving into a kernel-side buffer is somewhat pointless, really. You > > > want stuff to go into userspace. This is an output accelerator, not a > > > new I/O method. > > > > It isn't pointless at all. > > > > Again, you want a specific API, I'd rather see a generic API that could do > > what kblob can, > > You haven't described any such generic API. Zero-copy user-space network > I/O doesn't even begin to consider the issues that kblob addresses. Do I have to come up with a complete competing implementation in order for my comments to be considered? In any case, I have done just that, but as I mentioned in my mail to Alfred, it won't be released, since it was specific to a software and hardware environment. If you want a description of it, I'll be glad to provide one. The concept, however, isn't specific to a particular platform, and in fact similar things have been proposed and implemented. Sun's fbufs proposal, IO-Lite, and Jonathan's "zbuf" API that he posted to committers are all more in the range of the type of API I think would work. All three of those interfaces are probably superior to mine in terms of the elegance of the interface. Why not just use those as examples of a zero copy API? The only difference performance-wise between any of those APIs and kblob would be mapping the data from the user's virtual address space to the kernel's virtual address space. Even that isn't strictly necessary, see my comments below. > > What I'm not sure of, though, is why we're proposing something that's quite > > pointedly a narrow interface, when we could get much the same performance > > out of a generic API, along with wider usability. > > Actually, in the target application, I wouldn't expect anything like the > same sort of performance. With all the VM operations involved in the > zero-copy API, it's well-suited to applications that generate dynamic > content, but still rather more expensive for static content. The only VM operation I can see on the sending side of any one of the APIs above would be mapping it into the kernel's KVA. No COW mapping would be involved. If you've got an adapter that does checksum offloading, you don't even need to do that. You can just go straight to physical addresses for the payload, since the checksumming routines are the only routines in the kernel that generally need to touch the payload on the sending side. The only place where you would want to access the payload in that case is for bpf, and you can get around that by either mapping things into kva for bpf long enough to copy the data out, or by having bpf skip over the physically addressed segments of the mbuf chain. > > > One point that Alfred may have overlooked is that apart from the resource > > > limit issues, kblob could be implemented entirely as a loadable syscall. > > > (Then you could just compile the limit in, for slightly reduced > > > flexibility.) This would address the "don't commit to a restricted API" > > > issues while still getting the code out and used where it's needed. > > > > Again, can you elaborate on the uses of kblob? Is there code that uses it? > > Any service that, in response to a query, needs to send from a small > collection of static data down a network socket. The common use is static > content serving for http. I think it would be interesting to see data on the performance penalty of the user->kernel virtual address mapping. i.e. how big of a penalty is it? Are there some hard numbers? One way to do this would be to do the user->kernel mapping every time someone does a kblobsend(), and compare that to the stock kblob code. This seems to be the only major sticking point that I see in this whole discussion. If y'all can show that there is a major performance penalty to doing the mapping, then the need for something like kblob becomes more evident. If the mapping overhead just gets lost in the noise, then the need for kblob isn't as clear. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:32:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3867437B6C3; Mon, 19 Jun 2000 15:32:46 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id RAA46654; Mon, 19 Jun 2000 17:37:43 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 17:37:43 -0500 From: Jonathan Lemon To: "Kenneth D. Merry" Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619173743.H37084@prism.flugsvamp.com> References: <20000619151517.A80732@panzer.kdm.org> <200006192149.OAA09723@mass.osd.bsdi.com> <20000619162522.A81338@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000619162522.A81338@panzer.kdm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 04:25:22PM -0600, Kenneth D. Merry wrote: > The concept, however, isn't specific to a particular platform, and in fact > similar things have been proposed and implemented. Sun's fbufs proposal, > IO-Lite, and Jonathan's "zbuf" API that he posted to committers are all > more in the range of the type of API I think would work. > > All three of those interfaces are probably superior to mine in terms of the > elegance of the interface. Why not just use those as examples of a zero > copy API? > > The only difference performance-wise between any of those APIs and kblob > would be mapping the data from the user's virtual address space to the > kernel's virtual address space. Even that isn't strictly necessary, see my > comments below. Right -- the `zbuf' API I sent to -committers doesn't even use VM mappings, although that could be added; right now it simply keeps all content in kernel space. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:34: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5E05737B7D8; Mon, 19 Jun 2000 15:33:48 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JMXPt21191; Mon, 19 Jun 2000 15:33:25 -0700 (PDT) Date: Mon, 19 Jun 2000 15:33:25 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619153325.D17420@fw.wintelcom.net> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619172041.G37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 05:20:41PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [000619 15:17] wrote: > On Mon, Jun 19, 2000 at 02:56:47PM -0700, Mike Smith wrote: > > > > Kblob is not a new output method. It's a bolt-on to the 'write' > > interface, as opposed to, say, zero-copy I/O. > > Yes, it is a "bolt-on" thing, not a well designed item. Yes it is, it serves the purpose for which it was created. > And as far as "zero-copy" goes, I would consider that a fairly overloaded > term. Here, I'm applying it to anything that saves copies, not just > a magical method of getting data between user and kernel spaces. I'm sorry, I'm unable to code "anything that saves copies". > > > And for a lot of cases > > > you don't need stuff to actually go to user space. In many situations, > > > you will receive data, perform operations on a very small part of it, > > > and then send the data elsewhere, whether to disk or network. > > > > However, for a user-space application to do this, you want it to come out > > to user-space, right? > > No. You cut out what I wrote - you may only need a very small part > of the data to actually go to user space. So then use my soon to be committed accept filters to accomplish this. > > Irregardless, this is irrelevant in this context. > > Not irrelevant; you're not looking at the big picture here. There is no big picture, there are a lot of connections and the data I want to send down them. > > > Also, if I want to send data from disk -> network, with the kblob > > > API, I essentially have the following sequence of calls: > > > > > > read(fd, address, length) > > > kblob(address, length) > > > kblobsend(...) > > > > > > which is to say, the data is copied from > > > disk -> userspace (assuming direct I/O) > > > userspace -> kernel, > > > kernel -> network. > > > > > > Why shouldn't I be able to bypass second copy entirely and do: > > > disk -> kernel (data now in kernel 'blob') > > > kernel -> network > > > > Because this isn't what you use kblob for. That's what you use sendfile > > for. > > But sendfile doesn't leave the data cached in kernel space for reuse, > so it isn't suitable for this. Yes it does. > > The entire use of the kblob API is: > > > > user -> kernel > > > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > etc., > > And you have to get the data into user space first, when the data > may be coming from disk. Thus you incur one copy into userspace > first, when a better API might avoid it altogether. I *know* what > kblob is designed for, and I'm telling you that the API is limiting, > and will not be suitable for what I have. Use sendfile and mlock. > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > up as an example, because I want the data to be kept in the kernel > > > after being read from disk. > > > > It is. You remember that thing called the buffer cache? > > Not applicable here. If it was, why the heck aren't you using sendfile > in the first place and relying on the kernel to keep the file cached? > Hmm? If that was the way things worked, why isn't sendfile() good enough? Because of all the damn overhead of vm operations that you won't be satisfied about until I bog down kblob with them. It's not going to happen. > > > > > I'd be more in favor of doing it right the first time, rather than > > > > > continually revising and extending the interface. > > > > > > > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > > > > not see it undergo second-system syndrome before it's even made it to > > > > first base. If you plan to implement an efficient zero-copy network I/O > > > > interface, then it should be done from scratch, not as a wart on the side > > > > of what is really fairly specific feature. > > > > > > I disagree on your definition of "right". I would argue that if we're > > > going to implement an I/O accelerator of any form, it should not be so > > > specific purpose that it precludes any other possible applications. > > > > > > - How do I receive data _into_ a kblob (either from a network or a disk?) > > > > You don't. It's not relevant to this application. > > > > > - Once data is in a kblob, is there any possibility of editing it? > > > Do I have to throw it all away and reload if I want to make a minor > > > change to the data? > > > > It's static content. > > > > > - Can I retrieve data from a kblob? > > > > No. The kblob is a send-only acceleration buffer. > > > > > - Can kblobs be transferred to disk? > > > > No. Since the data in a kblob came from userspace, and can't be modified > > in the kernel, this would be pointless. > > Exactly. You're looking at kblob as a "static send-only buffer which > comes from user space". I'm looking at kblob as an "in-kernel object > cache". The two views are _NOT_ that far apart, and with a little API > help, the current code can be made much more flexible. Why are you > opposed to that? I'm not opposed to it at all, feel free to work on the code as much as you want as long as you don't kill the fastpath it offers. > > Again, folks; kblob is an optimisation for a very common performance > > case, not a network engineer's wet dream. It's meant to address a > > real-world problem in an efficient fashion. > > It is a narrow optimization for a specific problem. Sending data fast is a pretty large problem to solve. > > If you have a Grand Plan for something else, that's great - I'd recommend > > you keep working on it. In the meantime, there are a lot of people that > > can do a lot of useful things with kblob as-is, and knocking it down just > > because it's not _your_ idea of the Perfect In-Kernel Network Container > > Object is kinda silly. > > Well, with a little more work, we can get something that is more > applicable to a wider audience, rather than focusing on your single > specific performance problem. Putting on blinders to the wider > problem simply because your current code doesn't address it strikes > me as kind of foolish. The only problem I see is that there's just no pleasing some people. :) I'm not writing this code for your application Johnathan, I'm writing it for myself and for the other people that need this functionality. I've never been pain about 'MAINTAINER' so I don't see adding to the interface in the future as much of a problem. Perhaps you can give me a TODO list that I can include at the top of kern_blob.c? thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:36:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from funkthat.com (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id 8804737B537 for ; Mon, 19 Jun 2000 15:36:36 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by funkthat.com (8.9.3/8.8.7) id PAA23192; Mon, 19 Jun 2000 15:36:34 -0700 (PDT) Message-ID: <20000619153634.24385@hydrogen.funkthat.com> Date: Mon, 19 Jun 2000 15:36:34 -0700 From: John-Mark Gurney To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. References: <20000619125345.H26801@fw.wintelcom.net> <3249.961452627@localhost> <20000619151809.C17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <20000619151809.C17420@fw.wintelcom.net>; from Alfred Perlstein on Mon, Jun 19, 2000 at 03:18:10PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.4-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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein scribbled this message on Jun 19: > * Jordan K. Hubbard [000619 15:10] wrote: > > > It doesn't bother you at all that cdrom.com can push 100mbit > > > and support 6000 users on FreeBSD but Joe Average FreeBSD User > > > can't because the hacks used aren't available? > > > > Huh? What makes you think that cdrom.com uses "special hacks" to get > > its performance? Have you actually talked to David Greenman about > > this lately? > > I'm quite sure cdrom.com has at least a kernel address space hack. didn't dg already commit these fixes to the source tree: dg 1999/03/11 10:28:47 PST Modified files: sys/i386/conf Makefile.i386 kernel.script sys/i386/include pmap.h Log: Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed bootblocks in order to boot the kernel after this! Also note that this change breaks BSDI BSD/OS compatibility. Also increased default NKPT to 17 so that FreeBSD can boot on machines with >=2GB of RAM. Booting on machines with exactly 4GB requires other patches, not included. Revision Changes Path 1.141 +2 -2 src/sys/i386/conf/Makefile.i386 1.2 +1 -1 src/sys/i386/conf/kernel.script 1.59 +4 -4 src/sys/i386/include/pmap.h -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "Thank God I'm an atheist, that'd just be confusing." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:53:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 9D24537B5DF; Mon, 19 Jun 2000 15:53:08 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id RAA47280; Mon, 19 Jun 2000 17:58:05 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 17:58:05 -0500 From: Jonathan Lemon To: Alfred Perlstein Cc: Jonathan Lemon , Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619175805.J37084@prism.flugsvamp.com> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000619153325.D17420@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 03:33:25PM -0700, Alfred Perlstein wrote: > * Jonathan Lemon [000619 15:17] wrote: > > On Mon, Jun 19, 2000 at 02:56:47PM -0700, Mike Smith wrote: > > > > > > Kblob is not a new output method. It's a bolt-on to the 'write' > > > interface, as opposed to, say, zero-copy I/O. > > > > Yes, it is a "bolt-on" thing, not a well designed item. > > Yes it is, it serves the purpose for which it was created. For which it is a very specific problem, and I'm trying to expand it a little bit so it can be used for other things as well. > > > > And for a lot of cases > > > > you don't need stuff to actually go to user space. In many situations, > > > > you will receive data, perform operations on a very small part of it, > > > > and then send the data elsewhere, whether to disk or network. > > > > > > However, for a user-space application to do this, you want it to come out > > > to user-space, right? > > > > No. You cut out what I wrote - you may only need a very small part > > of the data to actually go to user space. > > So then use my soon to be committed accept filters to accomplish this. How is this applicable? The accept filters just delay telling the user when data is available, not redirect the data. > > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > > up as an example, because I want the data to be kept in the kernel > > > > after being read from disk. > > > > > > It is. You remember that thing called the buffer cache? > > > > Not applicable here. If it was, why the heck aren't you using sendfile > > in the first place and relying on the kernel to keep the file cached? > > Hmm? If that was the way things worked, why isn't sendfile() good enough? > > Because of all the damn overhead of vm operations that you won't > be satisfied about until I bog down kblob with them. It's not > going to happen. I'm not advocating that. I'm simply trying to get a better API to start out with. Heck, you were standing right next to me at the SMP meeting when I was discussing this with Jeffrey Hsu at length, I thought you were also listening. What I was proposing does not use any VM operations. > > Exactly. You're looking at kblob as a "static send-only buffer which > > comes from user space". I'm looking at kblob as an "in-kernel object > > cache". The two views are _NOT_ that far apart, and with a little API > > help, the current code can be made much more flexible. Why are you > > opposed to that? > > I'm not opposed to it at all, feel free to work on the code as much > as you want as long as you don't kill the fastpath it offers. Sure, as long as you don't mind me ripping out your API later, and replacing it with something which accomplishes the same thing but is more flexible. > > > If you have a Grand Plan for something else, that's great - I'd recommend > > > you keep working on it. In the meantime, there are a lot of people that > > > can do a lot of useful things with kblob as-is, and knocking it down just > > > because it's not _your_ idea of the Perfect In-Kernel Network Container > > > Object is kinda silly. > > > > Well, with a little more work, we can get something that is more > > applicable to a wider audience, rather than focusing on your single > > specific performance problem. Putting on blinders to the wider > > problem simply because your current code doesn't address it strikes > > me as kind of foolish. > > The only problem I see is that there's just no pleasing some people. > :) > > I'm not writing this code for your application Johnathan, I'm > writing it for myself and for the other people that need this > functionality. Fine. I'm not complaining about your functionality, I'm complaining about your API. In one of my last messages, I presented a list of things I wanted to accomplish with in-kernel buffers. Now, I don't explect you to implement the code for it, but I also don't expect you to stick with such a narrow API that makes those aims impossible to accomplish in the future. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:54:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C8ECE37B759 for ; Mon, 19 Jun 2000 15:54:09 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JMs8g21753; Mon, 19 Jun 2000 15:54:08 -0700 (PDT) Date: Mon, 19 Jun 2000 15:54:08 -0700 From: Alfred Perlstein To: John-Mark Gurney Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619155408.E17420@fw.wintelcom.net> References: <20000619125345.H26801@fw.wintelcom.net> <3249.961452627@localhost> <20000619151809.C17420@fw.wintelcom.net> <20000619153634.24385@hydrogen.funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619153634.24385@hydrogen.funkthat.com>; from gurney_j@efn.org on Mon, Jun 19, 2000 at 03:36:34PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John-Mark Gurney [000619 15:36] wrote: > Alfred Perlstein scribbled this message on Jun 19: > > * Jordan K. Hubbard [000619 15:10] wrote: > > > > It doesn't bother you at all that cdrom.com can push 100mbit > > > > and support 6000 users on FreeBSD but Joe Average FreeBSD User > > > > can't because the hacks used aren't available? > > > > > > Huh? What makes you think that cdrom.com uses "special hacks" to get > > > its performance? Have you actually talked to David Greenman about > > > this lately? > > > > I'm quite sure cdrom.com has at least a kernel address space hack. > > didn't dg already commit these fixes to the source tree: > dg 1999/03/11 10:28:47 PST > > Modified files: > sys/i386/conf Makefile.i386 kernel.script > sys/i386/include pmap.h > Log: > Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed > bootblocks in order to boot the kernel after this! Also note that this > change breaks BSDI BSD/OS compatibility. > Also increased default NKPT to 17 so that FreeBSD can boot on machines > with >=2GB of RAM. Booting on machines with exactly 4GB requires other > patches, not included. Last I heard, cdrom.com uses 2gigs of kernel virtual address space. And what part of: "Booting on machines with exactly 4GB requires other patches, not included" didn't you understand? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 15:58:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 490D537B7BC for ; Mon, 19 Jun 2000 15:58:37 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA10008; Mon, 19 Jun 2000 16:03:19 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192303.QAA10008@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:54:08 PDT." <20000619155408.E17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 16:03:19 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * John-Mark Gurney [000619 15:36] wrote: > > Alfred Perlstein scribbled this message on Jun 19: > > > * Jordan K. Hubbard [000619 15:10] wrote: > > > > > It doesn't bother you at all that cdrom.com can push 100mbit > > > > > and support 6000 users on FreeBSD but Joe Average FreeBSD User > > > > > can't because the hacks used aren't available? > > > > > > > > Huh? What makes you think that cdrom.com uses "special hacks" to get > > > > its performance? Have you actually talked to David Greenman about > > > > this lately? ... > And what part of: > > "Booting on machines with exactly 4GB requires other patches, not included" > > didn't you understand? > Actually, it doesn't anymore, now that we correctly probe memory. The "special hacks" that wcarchive relies on are sendfile (yes, a very special hack) and dg-ftpd. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16: 2: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id C8FF037B7BE; Mon, 19 Jun 2000 16:01:54 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA18923; Mon, 19 Jun 2000 15:51:58 -0700 (PDT) Message-Id: <200006192251.PAA18923@implode.root.com> To: Jonathan Lemon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 17:20:41 CDT." <20000619172041.G37084@prism.flugsvamp.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 19 Jun 2000 15:51:58 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > Also, if I want to send data from disk -> network, with the kblob >> > API, I essentially have the following sequence of calls: >> > >> > read(fd, address, length) >> > kblob(address, length) >> > kblobsend(...) >> > >> > which is to say, the data is copied from >> > disk -> userspace (assuming direct I/O) >> > userspace -> kernel, >> > kernel -> network. >> > >> > Why shouldn't I be able to bypass second copy entirely and do: >> > disk -> kernel (data now in kernel 'blob') >> > kernel -> network >> >> Because this isn't what you use kblob for. That's what you use sendfile >> for. > >But sendfile doesn't leave the data cached in kernel space for reuse, >so it isn't suitable for this. I think you need to review the code a bit more closely. sendfile() definately leaves the pages cached, and definately uses any cached pages that it finds, thus avoiding I/O when possible. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16: 5:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 22CC337B7E0 for ; Mon, 19 Jun 2000 16:05:26 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA18955; Mon, 19 Jun 2000 15:54:42 -0700 (PDT) Message-Id: <200006192254.PAA18955@implode.root.com> To: Alfred Perlstein Cc: "Jordan K. Hubbard" , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:18:10 PDT." <20000619151809.C17420@fw.wintelcom.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 19 Jun 2000 15:54:42 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >* Jordan K. Hubbard [000619 15:10] wrote: >> > It doesn't bother you at all that cdrom.com can push 100mbit >> > and support 6000 users on FreeBSD but Joe Average FreeBSD User >> > can't because the hacks used aren't available? >> >> Huh? What makes you think that cdrom.com uses "special hacks" to get >> its performance? Have you actually talked to David Greenman about >> this lately? > >I'm quite sure cdrom.com has at least a kernel address space hack. Yes, the kernel virtual address space is greatly increased. This doesn't involve any special code, however. Otherwise the kernel is stock with only kernel config file and sysctl tuning. Most of the ability to handle that many users comes from a pain-stakenly optimized ftp server that I call 'dg-ftpd'. It's true that I have not made that available as freeware, but that's my perogative since I wrote it. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16: 5:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 77D9237B7CC; Mon, 19 Jun 2000 16:05:44 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5JN5JI22145; Mon, 19 Jun 2000 16:05:19 -0700 (PDT) Date: Mon, 19 Jun 2000 16:05:19 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619160518.F17420@fw.wintelcom.net> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> <20000619175805.J37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619175805.J37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 05:58:05PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [000619 15:53] wrote: > On Mon, Jun 19, 2000 at 03:33:25PM -0700, Alfred Perlstein wrote: > > For which it is a very specific problem, and I'm trying to expand > it a little bit so it can be used for other things as well. Ok, here's what I'll do, I'll also provide for a way to create a kblob and tell the kernel to read the data from an already open file. > > So then use my soon to be committed accept filters to accomplish this. > > How is this applicable? The accept filters just delay telling the > user when data is available, not redirect the data. None of the patches you've present do either. > > > Exactly. You're looking at kblob as a "static send-only buffer which > > > comes from user space". I'm looking at kblob as an "in-kernel object > > > cache". The two views are _NOT_ that far apart, and with a little API > > > help, the current code can be made much more flexible. Why are you > > > opposed to that? > > > > I'm not opposed to it at all, feel free to work on the code as much > > as you want as long as you don't kill the fastpath it offers. > > Sure, as long as you don't mind me ripping out your API later, and > replacing it with something which accomplishes the same thing but > is more flexible. If it's flexible enough then you won't need to rip out my API, you'll find it obnoxiously easy to create compatibility shims for it. > > > > If you have a Grand Plan for something else, that's great - I'd recommend > > > > you keep working on it. In the meantime, there are a lot of people that > > > > can do a lot of useful things with kblob as-is, and knocking it down just > > > > because it's not _your_ idea of the Perfect In-Kernel Network Container > > > > Object is kinda silly. > > > > > > Well, with a little more work, we can get something that is more > > > applicable to a wider audience, rather than focusing on your single > > > specific performance problem. Putting on blinders to the wider > > > problem simply because your current code doesn't address it strikes > > > me as kind of foolish. > > > > The only problem I see is that there's just no pleasing some people. > > :) > > > > I'm not writing this code for your application Johnathan, I'm > > writing it for myself and for the other people that need this > > functionality. > > Fine. I'm not complaining about your functionality, I'm complaining > about your API. In one of my last messages, I presented a list of > things I wanted to accomplish with in-kernel buffers. Now, I don't > explect you to implement the code for it, but I also don't expect > you to stick with such a narrow API that makes those aims impossible to > accomplish in the future. I never said that the code will be set in stone. I won't stand in the way of your enhancements. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16: 7:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id A141C37BA0A for ; Mon, 19 Jun 2000 16:07:32 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA10064; Mon, 19 Jun 2000 16:11:59 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192311.QAA10064@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 17:20:41 CDT." <20000619172041.G37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 16:11:59 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > *cough*. Are you sure about that? An output accelerator is a new I/O > > > method regardless of what you want to call it. > > > > *sigh* > > > > Kblob is not a new output method. It's a bolt-on to the 'write' > > interface, as opposed to, say, zero-copy I/O. > > Yes, it is a "bolt-on" thing, not a well designed item. That's debatable. > And as far as "zero-copy" goes, I would consider that a fairly overloaded > term. Here, I'm applying it to anything that saves copies, not just > a magical method of getting data between user and kernel spaces. Correct. Note that kblob doesn't involve any more copies than absolutely necessary. > > > And for a lot of cases > > > you don't need stuff to actually go to user space. In many situations, > > > you will receive data, perform operations on a very small part of it, > > > and then send the data elsewhere, whether to disk or network. > > > > However, for a user-space application to do this, you want it to come out > > to user-space, right? > > No. You cut out what I wrote - you may only need a very small part > of the data to actually go to user space. However, it still has to go there, right? That being the actual point. > > Irregardless, this is irrelevant in this context. > > Not irrelevant; you're not looking at the big picture here. Actually, I think I'm looking at a *bigger* picture - what can we do to make FreeBSD a better platform for real-world applications? The ability to send static content in the most efficient manner possible is a key "big picture" item. You're so tied up in what would be the most wonderful engineering solution that you're completely ignoring this. > > > Kblob only addresses part of the problem. > > > > Kblob addresses exactly one problem, and does it in an expedient fashion. > > Exactly, so my statement stands: it only addresses a small part of > the problem. No, it addresses _one_ problem, comfortably, in its entirety, in a fashion which can be (and has been) rapidly implemented and deployed. > > > Also, if I want to send data from disk -> network, with the kblob > > > API, I essentially have the following sequence of calls: > > > > > > read(fd, address, length) > > > kblob(address, length) > > > kblobsend(...) > > > > > > which is to say, the data is copied from > > > disk -> userspace (assuming direct I/O) > > > userspace -> kernel, > > > kernel -> network. > > > > > > Why shouldn't I be able to bypass second copy entirely and do: > > > disk -> kernel (data now in kernel 'blob') > > > kernel -> network > > > > Because this isn't what you use kblob for. That's what you use sendfile > > for. > > But sendfile doesn't leave the data cached in kernel space for reuse, > so it isn't suitable for this. It does. > > The entire use of the kblob API is: > > > > user -> kernel > > > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > kernel -> network > > etc., > > And you have to get the data into user space first, when the data > may be coming from disk. Thus you incur one copy into userspace > first, when a better API might avoid it altogether. I *know* what > kblob is designed for, and I'm telling you that the API is limiting, > and will not be suitable for what I have. I don't think that anyone *cares* about what you have at this juncture. What you're threatening will have so many complex options and implementation issues that it will entirely fail to address the actual, real-world problems that the big-picture people are looking at. > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > up as an example, because I want the data to be kept in the kernel > > > after being read from disk. > > > > It is. You remember that thing called the buffer cache? > > Not applicable here. If it was, why the heck aren't you using sendfile > in the first place and relying on the kernel to keep the file cached? > Hmm? If that was the way things worked, why isn't sendfile() good enough? Because it's _still_too_expensive_. Kblob is about _performance_, not "technical elegance". > > No. Since the data in a kblob came from userspace, and can't be modified > > in the kernel, this would be pointless. > > Exactly. You're looking at kblob as a "static send-only buffer which > comes from user space". I'm looking at kblob as an "in-kernel object > cache". The two views are _NOT_ that far apart, and with a little API > help, the current code can be made much more flexible. Why are you > opposed to that? Why would anyone be opposed to putting a Perl interpreter in the kernel? > > Again, folks; kblob is an optimisation for a very common performance > > case, not a network engineer's wet dream. It's meant to address a > > real-world problem in an efficient fashion. > > It is a narrow optimization for a specific problem. Correct. It just happens to be a specific problem that comes up _very_ often. As I've already proposed, kblob should be implemented as a loadable system call. It'll do what it's meant to do, for the people that want it to do it, and the rest of you can ignore it in happiness. You're welcome to your API, but you need to face the fact that it's just as irrelevant to kblob's target audience as kblob is to you. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16: 9:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id C13A637B7E0; Mon, 19 Jun 2000 16:09:38 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id SAA47983; Mon, 19 Jun 2000 18:14:15 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 18:14:15 -0500 From: Jonathan Lemon To: David Greenman Cc: Jonathan Lemon , Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619181415.K37084@prism.flugsvamp.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192251.PAA18923@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006192251.PAA18923@implode.root.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 03:51:58PM -0700, David Greenman wrote: > >> > Also, if I want to send data from disk -> network, with the kblob > >> > API, I essentially have the following sequence of calls: > >> > > >> > read(fd, address, length) > >> > kblob(address, length) > >> > kblobsend(...) > >> > > >> > which is to say, the data is copied from > >> > disk -> userspace (assuming direct I/O) > >> > userspace -> kernel, > >> > kernel -> network. > >> > > >> > Why shouldn't I be able to bypass second copy entirely and do: > >> > disk -> kernel (data now in kernel 'blob') > >> > kernel -> network > >> > >> Because this isn't what you use kblob for. That's what you use sendfile > >> for. > > > >But sendfile doesn't leave the data cached in kernel space for reuse, > >so it isn't suitable for this. > > I think you need to review the code a bit more closely. sendfile() > definately leaves the pages cached, and definately uses any cached pages > that it finds, thus avoiding I/O when possible. Um, even in the case for "direct I/O" above? Note that I'm not actually using a filesystem at all, just raw devices. I didn't think that the vm system caches this data, but I don't claim extensive knowlege about the vm subsystem. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:22:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 58BA737B9AA; Mon, 19 Jun 2000 16:22:32 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id SAA48379; Mon, 19 Jun 2000 18:27:30 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 18:27:30 -0500 From: Jonathan Lemon To: Mike Smith Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619182730.L37084@prism.flugsvamp.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006192311.QAA10064@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 04:11:59PM -0700, Mike Smith wrote: > > And as far as "zero-copy" goes, I would consider that a fairly overloaded > > term. Here, I'm applying it to anything that saves copies, not just > > a magical method of getting data between user and kernel spaces. > > Correct. Note that kblob doesn't involve any more copies than absolutely > necessary. Not quite true. You can't load your "static image" into the kernel directly from disk. You have to go through userspace. That counts as an extra copy in my book. Now it may be true that you may not need to do this for _YOUR_ application, but that may not be applicable for mine. > > > > And for a lot of cases > > > > you don't need stuff to actually go to user space. In many situations, > > > > you will receive data, perform operations on a very small part of it, > > > > and then send the data elsewhere, whether to disk or network. > > > > > > However, for a user-space application to do this, you want it to come out > > > to user-space, right? > > > > No. You cut out what I wrote - you may only need a very small part > > of the data to actually go to user space. > > However, it still has to go there, right? That being the actual point. No, it does not. What part of that do you not understand? The bulk of the data _NEVER_REACHES_USER_SPACE_. Ever. > > > Irregardless, this is irrelevant in this context. > > > > Not irrelevant; you're not looking at the big picture here. > > Actually, I think I'm looking at a *bigger* picture - what can we do to > make FreeBSD a better platform for real-world applications? > > The ability to send static content in the most efficient manner possible > is a key "big picture" item. You're so tied up in what would be the most > wonderful engineering solution that you're completely ignoring this. Gee, really? Please explain to me in small words how what I'm trying to accomplish is contrary to what you're saying above. Please explain how the rough API I posted is at all at odds to above. Please explain to me how "static content" is the end-all and be-all "big picture". Until you do so, I will keep going and solving some real-world applications that are larger than just serving static content. > I don't think that anyone *cares* about what you have at this juncture. > What you're threatening will have so many complex options and > implementation issues that it will entirely fail to address the actual, > real-world problems that the big-picture people are looking at. It does? Do you actually know that I'm aiming for? > > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > > up as an example, because I want the data to be kept in the kernel > > > > after being read from disk. > > > > > > It is. You remember that thing called the buffer cache? > > > > Not applicable here. If it was, why the heck aren't you using sendfile > > in the first place and relying on the kernel to keep the file cached? > > Hmm? If that was the way things worked, why isn't sendfile() good enough? > > Because it's _still_too_expensive_. Kblob is about _performance_, not > "technical elegance". I happen to agree with that. See the part above that says "not applicable"? > > > No. Since the data in a kblob came from userspace, and can't be modified > > > in the kernel, this would be pointless. > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > comes from user space". I'm looking at kblob as an "in-kernel object > > cache". The two views are _NOT_ that far apart, and with a little API > > help, the current code can be made much more flexible. Why are you > > opposed to that? > > Why would anyone be opposed to putting a Perl interpreter in the kernel? And I thought that -arch was supposed to be a technical list, not the place for ad homenium attacks. > > > Again, folks; kblob is an optimisation for a very common performance > > > case, not a network engineer's wet dream. It's meant to address a > > > real-world problem in an efficient fashion. > > > > It is a narrow optimization for a specific problem. > > Correct. It just happens to be a specific problem that comes up _very_ > often. > > As I've already proposed, kblob should be implemented as a loadable > system call. It'll do what it's meant to do, for the people that want it > to do it, and the rest of you can ignore it in happiness. > > You're welcome to your API, but you need to face the fact that it's just > as irrelevant to kblob's target audience as kblob is to you. Methinks that you haven't actually read what I posted, otherwise you wouldn't be saying that. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:30:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 1F70037B81B; Mon, 19 Jun 2000 16:30:06 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id SAA48654; Mon, 19 Jun 2000 18:35:01 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 18:35:01 -0500 From: Jonathan Lemon To: Alfred Perlstein Cc: Jonathan Lemon , Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619183501.M37084@prism.flugsvamp.com> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> <20000619175805.J37084@prism.flugsvamp.com> <20000619160518.F17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000619160518.F17420@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 04:05:19PM -0700, Alfred Perlstein wrote: > * Jonathan Lemon [000619 15:53] wrote: > > On Mon, Jun 19, 2000 at 03:33:25PM -0700, Alfred Perlstein wrote: > > > > For which it is a very specific problem, and I'm trying to expand > > it a little bit so it can be used for other things as well. > > Ok, here's what I'll do, I'll also provide for a way to create a kblob > and tell the kernel to read the data from an already open file. Okay. > > > So then use my soon to be committed accept filters to accomplish this. > > > > How is this applicable? The accept filters just delay telling the > > user when data is available, not redirect the data. > > None of the patches you've present do either. I didn't know that you had to write the code in advance in order to have an architectural discussion. But as a matter of fact, I *DO* have working code, but I don't feel that it's in any form to be released at the moment, as its still evolving a bit. Put another way, I'm not waving my hands here and talking theory, I'm speaking from my own experience. > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > > > comes from user space". I'm looking at kblob as an "in-kernel object > > > > cache". The two views are _NOT_ that far apart, and with a little API > > > > help, the current code can be made much more flexible. Why are you > > > > opposed to that? > > > > > > I'm not opposed to it at all, feel free to work on the code as much > > > as you want as long as you don't kill the fastpath it offers. > > > > Sure, as long as you don't mind me ripping out your API later, and > > replacing it with something which accomplishes the same thing but > > is more flexible. > > If it's flexible enough then you won't need to rip out my API, you'll > find it obnoxiously easy to create compatibility shims for it. True. But if the syscalls change, the app needs to be recompiled. > > > I'm not writing this code for your application Johnathan, I'm > > > writing it for myself and for the other people that need this > > > functionality. > > > > Fine. I'm not complaining about your functionality, I'm complaining > > about your API. In one of my last messages, I presented a list of > > things I wanted to accomplish with in-kernel buffers. Now, I don't > > explect you to implement the code for it, but I also don't expect > > you to stick with such a narrow API that makes those aims impossible to > > accomplish in the future. > > I never said that the code will be set in stone. I won't stand in the > way of your enhancements. Fair enough. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:40:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 4F0F737B7E0 for ; Mon, 19 Jun 2000 16:40:44 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA10193; Mon, 19 Jun 2000 16:45:15 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192345.QAA10193@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 18:27:30 CDT." <20000619182730.L37084@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 16:45:15 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 19, 2000 at 04:11:59PM -0700, Mike Smith wrote: > > > And as far as "zero-copy" goes, I would consider that a fairly overloaded > > > term. Here, I'm applying it to anything that saves copies, not just > > > a magical method of getting data between user and kernel spaces. > > > > Correct. Note that kblob doesn't involve any more copies than absolutely > > necessary. > > Not quite true. You can't load your "static image" into the > kernel directly from disk. You have to go through userspace. > That counts as an extra copy in my book. Now it may be true > that you may not need to do this for _YOUR_ application, but > that may not be applicable for mine. I think I've tried hard enough to make it clear that your application requires your solution, but that kblob is a solution to a rather different problem. > > > > Irregardless, this is irrelevant in this context. > > > > > > Not irrelevant; you're not looking at the big picture here. > > > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > make FreeBSD a better platform for real-world applications? > > > > The ability to send static content in the most efficient manner possible > > is a key "big picture" item. You're so tied up in what would be the most > > wonderful engineering solution that you're completely ignoring this. > > Gee, really? Please explain to me in small words how what I'm > trying to accomplish is contrary to what you're saying above. Please > explain how the rough API I posted is at all at odds to above. Please > explain to me how "static content" is the end-all and be-all "big picture". I've never claimed that it's the "be-all and end-all" big picture. That's your claim, about your proposal. As I've said time and time again, kblob is a specific solution to a specific problem. > Until you do so, I will keep going and solving some real-world > applications that are larger than just serving static content. That's sheer arrogance. 8( > > > > No. Since the data in a kblob came from userspace, and can't be modified > > > > in the kernel, this would be pointless. > > > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > > comes from user space". I'm looking at kblob as an "in-kernel object > > > cache". The two views are _NOT_ that far apart, and with a little API > > > help, the current code can be made much more flexible. Why are you > > > opposed to that? > > > > Why would anyone be opposed to putting a Perl interpreter in the kernel? > > And I thought that -arch was supposed to be a technical list, not the > place for ad homenium attacks. That's pretty lame. Especially since the question was rhetorical and quite applicable to the point I was trying to make. > > You're welcome to your API, but you need to face the fact that it's just > > as irrelevant to kblob's target audience as kblob is to you. > > Methinks that you haven't actually read what I posted, otherwise > you wouldn't be saying that. One could draw the same conclusion in reflex. Why not simply accept the fact that right now you're competing against functional code, and come up with a competitive alternative? Right now, all we've got from your corner is vapourware - nobody is going to dispute that if you can make your code do what kblob does at a comparable cost, and it's more versatile, it'll be the winner. The issue right now is that all of the proposals so far have been too expensive, and entirely lacking in implementation. Under those circumstances you're better off coding than bitching while someone else deploys something that solves their problems. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:45:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 7570237B65A for ; Mon, 19 Jun 2000 16:45:43 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA19147; Mon, 19 Jun 2000 16:36:25 -0700 (PDT) Message-Id: <200006192336.QAA19147@implode.root.com> To: John-Mark Gurney Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:36:34 PDT." <20000619153634.24385@hydrogen.funkthat.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 19 Jun 2000 16:36:25 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Alfred Perlstein scribbled this message on Jun 19: >> * Jordan K. Hubbard [000619 15:10] wrote: >> > > It doesn't bother you at all that cdrom.com can push 100mbit >> > > and support 6000 users on FreeBSD but Joe Average FreeBSD User >> > > can't because the hacks used aren't available? >> > >> > Huh? What makes you think that cdrom.com uses "special hacks" to get >> > its performance? Have you actually talked to David Greenman about >> > this lately? >> >> I'm quite sure cdrom.com has at least a kernel address space hack. > >didn't dg already commit these fixes to the source tree: >dg 1999/03/11 10:28:47 PST > > Modified files: > sys/i386/conf Makefile.i386 kernel.script > sys/i386/include pmap.h > Log: > Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed Wcarchive needs even more than that, however. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:52:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from funkthat.com (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id C730C37B84E; Mon, 19 Jun 2000 16:52:28 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by funkthat.com (8.9.3/8.8.7) id QAA24799; Mon, 19 Jun 2000 16:52:24 -0700 (PDT) Message-ID: <20000619165224.08906@hydrogen.funkthat.com> Date: Mon, 19 Jun 2000 16:52:24 -0700 From: John-Mark Gurney To: Alfred Perlstein Cc: Jonathan Lemon , Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <20000619153325.D17420@fw.wintelcom.net>; from Alfred Perlstein on Mon, Jun 19, 2000 at 03:33:25PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.4-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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein scribbled this message on Jun 19: > I've never been pain about 'MAINTAINER' so I don't see adding to > the interface in the future as much of a problem. Perhaps you > can give me a TODO list that I can include at the top of kern_blob.c? oh, I can add a couple that will help what jlemon wants: fd <-> kblob (so you can read from disk directly into your kblob) userland <-> kblob (so you can read parts of the data into userland) all of these need to support offsets so you can read/write to any place in the kblob... then I think everyone would be happy, no? (unless they decide that I can't say anything useful and immediately attack me for saying something) -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "Thank God I'm an atheist, that'd just be confusing." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 16:53:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B674137B806 for ; Mon, 19 Jun 2000 16:53:12 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id QAA02359 for ; Mon, 19 Jun 2000 16:52:29 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpdAAA5LaGIe; Mon Jun 19 16:52:19 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA03874 for arch@FreeBSD.ORG; Mon, 19 Jun 2000 16:52:58 -0700 (MST) From: Terry Lambert Message-Id: <200006192352.QAA03874@usr06.primenet.com> Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please To: arch@FreeBSD.ORG Date: Mon, 19 Jun 2000 23:52:57 +0000 (GMT) In-Reply-To: from "Dag-Erling Smorgrav" at Jun 19, 2000 03:59:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I ran into a use for being able to tell from software whether the link integrity on an ethernet card was valid or not. My question is, I know my hardware can report it, but is this a general feature of most ethernet cards? I know that Intel 82558 and 82559 cards can tell you by you looking at bit 2 of MDI register #1 (if the bit is lit, so is the blinky light hidden at the back of your rack). Would this be a useful thing to build into ifconfig? I don't know how many of you find yourself crawling behind stacks of hardware to look for the blinky lights... 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-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 17:24: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 91A9F37B509 for ; Mon, 19 Jun 2000 17:24:05 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA469620; Mon, 19 Jun 2000 20:24:02 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200006192352.QAA03874@usr06.primenet.com> References: <200006192352.QAA03874@usr06.primenet.com> Date: Mon, 19 Jun 2000 20:24:42 -0400 To: Terry Lambert , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:52 PM +0000 6/19/00, Terry Lambert wrote: >FWIW, I ran into a use for being able to tell from software >whether the link integrity on an ethernet card was valid or not. > >My question is, I know my hardware can report it, but is this >a general feature of most ethernet cards? I know that Intel >82558 and 82559 cards can tell you by you looking at bit 2 >of MDI register #1 (if the bit is lit, so is the blinky light >hidden at the back of your rack). > >Would this be a useful thing to build into ifconfig? I think it would be great. I have no idea if other ethernet cards will support it. For those that don't, ifconfig could just report nothing (if you're thinking of the link-status as being part of the default output from ifconfig). >I don't know how many of you find yourself crawling behind >stacks of hardware to look for the blinky lights... I run into this too, and at times it can be a real pain to get in a position to see that light. [though I'm not sure what this has to do with /dev/random, or has that thread wandered pretty far off topic by now?] --- 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-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 17:37:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9E37237B708; Mon, 19 Jun 2000 17:37:23 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5K0axw24663; Mon, 19 Jun 2000 17:36:59 -0700 (PDT) Date: Mon, 19 Jun 2000 17:36:59 -0700 From: Alfred Perlstein To: John-Mark Gurney Cc: Jonathan Lemon , Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619173659.G17420@fw.wintelcom.net> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> <20000619165224.08906@hydrogen.funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619165224.08906@hydrogen.funkthat.com>; from gurney_j@efn.org on Mon, Jun 19, 2000 at 04:52:24PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John-Mark Gurney [000619 16:52] wrote: > Alfred Perlstein scribbled this message on Jun 19: > > I've never been pain about 'MAINTAINER' so I don't see adding to > > the interface in the future as much of a problem. Perhaps you > > can give me a TODO list that I can include at the top of kern_blob.c? > > oh, I can add a couple that will help what jlemon wants: > fd <-> kblob (so you can read from disk directly into your kblob) > userland <-> kblob (so you can read parts of the data into userland) > > all of these need to support offsets so you can read/write to any place > in the kblob... > > then I think everyone would be happy, no? (unless they decide that I > can't say anything useful and immediately attack me for saying something) I can do that, but the buffers have to be only referenced from the user's fd table and not 'in-flight' -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 17:41:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id EE15037B6C7; Mon, 19 Jun 2000 17:41:10 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id TAA50945; Mon, 19 Jun 2000 19:46:09 -0500 (CDT) (envelope-from jlemon) Date: Mon, 19 Jun 2000 19:46:09 -0500 From: Jonathan Lemon To: Mike Smith Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619194609.N37084@prism.flugsvamp.com> References: <20000619182730.L37084@prism.flugsvamp.com> <200006192345.QAA10193@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006192345.QAA10193@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 04:45:15PM -0700, Mike Smith wrote: > > Not quite true. You can't load your "static image" into the > > kernel directly from disk. You have to go through userspace. > > That counts as an extra copy in my book. Now it may be true > > that you may not need to do this for _YOUR_ application, but > > that may not be applicable for mine. > > I think I've tried hard enough to make it clear that your application > requires your solution, but that kblob is a solution to a rather > different problem. I must not be trying hard enough. What I have is a *superset* of kblob. It solves the *same* problem, but can also do additional things. It does roughly exactly what kblob does, in the same fashion. (no vm mapping games). > > > > > Irregardless, this is irrelevant in this context. > > > > > > > > Not irrelevant; you're not looking at the big picture here. > > > > > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > > make FreeBSD a better platform for real-world applications? > > > > > > The ability to send static content in the most efficient manner possible > > > is a key "big picture" item. You're so tied up in what would be the most > > > wonderful engineering solution that you're completely ignoring this. > > > > Gee, really? Please explain to me in small words how what I'm > > trying to accomplish is contrary to what you're saying above. Please > > explain how the rough API I posted is at all at odds to above. Please > > explain to me how "static content" is the end-all and be-all "big picture". > > I've never claimed that it's the "be-all and end-all" big picture. > That's your claim, about your proposal. As I've said time and time > again, kblob is a specific solution to a specific problem. I'm not claiming that about what I have. If I thought it was perfect, I would have submitted it for inclusion. All I'm trying to do is expand the API so it can handle other uses as well. > > Until you do so, I will keep going and solving some real-world > > applications that are larger than just serving static content. > > That's sheer arrogance. 8( No, it just happens to be my *job* at the moment. > > > > > No. Since the data in a kblob came from userspace, and can't be modified > > > > > in the kernel, this would be pointless. > > > > > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > > > comes from user space". I'm looking at kblob as an "in-kernel object > > > > cache". The two views are _NOT_ that far apart, and with a little API > > > > help, the current code can be made much more flexible. Why are you > > > > opposed to that? > > > > > > Why would anyone be opposed to putting a Perl interpreter in the kernel? > > > > And I thought that -arch was supposed to be a technical list, not the > > place for ad homenium attacks. > > That's pretty lame. Especially since the question was rhetorical and > quite applicable to the point I was trying to make. I think we must be talking at cross purposes. My question wasn't rhetorical, and I must be missing your point. > > > You're welcome to your API, but you need to face the fact that it's just > > > as irrelevant to kblob's target audience as kblob is to you. > > > > Methinks that you haven't actually read what I posted, otherwise > > you wouldn't be saying that. > > One could draw the same conclusion in reflex. Why not simply accept the > fact that right now you're competing against functional code, and come up > with a competitive alternative? Right now, all we've got from your > corner is vapourware - nobody is going to dispute that if you can make > your code do what kblob does at a comparable cost, and it's more > versatile, it'll be the winner. The issue right now is that all of the > proposals so far have been too expensive, and entirely lacking in > implementation. > > Under those circumstances you're better off coding than bitching while > someone else deploys something that solves their problems. I'm not objecting to the code, nor the concept, I'm just trying to make the api flexible enough to handle things which I would like to add later. Yes, I have code that will do the above, but no, I don't feel that it is quite polished enough to put in the public release kernel. It is my understanding now that this will be done as a loadable syscall, so with that in mind, I guess getting the API correct is not paramount any more, so I'll shut up for a bit. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 19:59: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 271E837B82A for ; Mon, 19 Jun 2000 19:58:58 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id UAA16564; Mon, 19 Jun 2000 20:58:57 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id UAA15915; Mon, 19 Jun 2000 20:58:56 -0600 (MDT) (envelope-from nate) Date: Mon, 19 Jun 2000 20:58:56 -0600 (MDT) Message-Id: <200006200258.UAA15915@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: HEADS UP: accept filters II In-Reply-To: <20000619105844.B26801@fw.wintelcom.net> References: <20000619105844.B26801@fw.wintelcom.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > http://people.freebsd.org/~alfred/accf.diff > > The extra fields in the socket have been moved into a malloc'd > chunk to save 8 bytes per socket. (jlemon) > > The filters files location have been moved from sys/net to sys/netinet. > (peter) > > I haven't seen any arguments against them besideds these two nits > and the documentation aspect which I will address soon. > > I'm waiting to commit this now. Can you give those of us who are busy a teeny bit more time to review this? Thanks! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 20:10:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F036137B56B for ; Mon, 19 Jun 2000 20:10:46 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5K3Air28546; Mon, 19 Jun 2000 20:10:44 -0700 (PDT) Date: Mon, 19 Jun 2000 20:10:44 -0700 From: Alfred Perlstein To: Nate Williams Cc: arch@FreeBSD.ORG Subject: Re: HEADS UP: accept filters II Message-ID: <20000619201044.K17420@fw.wintelcom.net> References: <20000619105844.B26801@fw.wintelcom.net> <200006200258.UAA15915@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006200258.UAA15915@nomad.yogotech.com>; from nate@yogotech.com on Mon, Jun 19, 2000 at 08:58:56PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nate Williams [000619 19:59] wrote: > > http://people.freebsd.org/~alfred/accf.diff > > > > The extra fields in the socket have been moved into a malloc'd > > chunk to save 8 bytes per socket. (jlemon) > > > > The filters files location have been moved from sys/net to sys/netinet. > > (peter) > > > > I haven't seen any arguments against them besideds these two nits > > and the documentation aspect which I will address soon. > > > > I'm waiting to commit this now. > > Can you give those of us who are busy a teeny bit more time to review this? > > Thanks! I'm sorry but John-Mark Gurney and a couple of others gave me the thumbs up a couple of hours ago and it's already in, if you have an issues with it please let me know and we'll see what we can fix. sorry, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 20:12: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 3254337B52E for ; Mon, 19 Jun 2000 20:11:59 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id UAA04099; Mon, 19 Jun 2000 20:12:22 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Alfred Perlstein Cc: John-Mark Gurney , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:54:08 PDT." <20000619155408.E17420@fw.wintelcom.net> Date: Mon, 19 Jun 2000 20:12:22 -0700 Message-ID: <4096.961470742@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Last I heard, cdrom.com uses 2gigs of kernel virtual address space. > > And what part of: > > "Booting on machines with exactly 4GB requires other patches, not included" > > didn't you understand? Why don't you ask DG about the current state of play rather than piling assumption on top of assumption, Albert? Or would that be too easy? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 20:18:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EA69C37B52E; Mon, 19 Jun 2000 20:18:49 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA16734; Mon, 19 Jun 2000 21:18:16 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id VAA15996; Mon, 19 Jun 2000 21:18:16 -0600 (MDT) (envelope-from nate) Date: Mon, 19 Jun 2000 21:18:16 -0600 (MDT) Message-Id: <200006200318.VAA15996@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-Reply-To: <200006192311.QAA10064@mass.osd.bsdi.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, I think I'm looking at a *bigger* picture - what can we do to > make FreeBSD a better platform for real-world applications? For a very common application, yes. WWW serving is not FreeBSD's strong point, IMO. As a matter of fact, I'd venture to guess that FreeBSD is used in more embedded systems as a 'network' platform than it's ever used as a WWW server. However, it just so happens that recently it seems that Yahoo has been pushing *HARD* for alot of WWW-server specific changes, that have little usefulness outside of that specific application. > The ability to send static content in the most efficient manner possible > is a key "big picture" item. You're so tied up in what would be the most > wonderful engineering solution that you're completely ignoring this. You're so wrapped up with building WWW server that you've completely ignored the rest of the developer community, who actually have needs for something *more generic* that you're incapable of seeing the forest since you've gotta cut down that one tree fast, and who gives a rip what anyone else needs to do in the forest... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 20:29:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id DC42B37BA59 for ; Mon, 19 Jun 2000 20:29:29 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id UAA10984; Mon, 19 Jun 2000 20:34:07 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006200334.UAA10984@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: nate@yogotech.com (Nate Williams) Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 21:18:16 MDT." <200006200318.VAA15996@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 20:34:07 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > make FreeBSD a better platform for real-world applications? > > For a very common application, yes. WWW serving is not FreeBSD's strong > point, IMO. In more or less complete defiance of this, a lot of people use it for just this very application, and will probably continue to do so. > As a matter of fact, I'd venture to guess that FreeBSD is used in more > embedded systems as a 'network' platform than it's ever used as a WWW > server. That doesn't change the fact that it is, despite your perhaps hard-held beliefs otherwise, used very extensively for web service, and particularly for bulk static content delivery. > However, it just so happens that recently it seems that Yahoo has been > pushing *HARD* for alot of WWW-server specific changes, that have little > usefulness outside of that specific application. They have? Would you care to name one? > > The ability to send static content in the most efficient manner possible > > is a key "big picture" item. You're so tied up in what would be the most > > wonderful engineering solution that you're completely ignoring this. > > You're so wrapped up with building WWW server that you've completely > ignored the rest of the developer community, who actually have needs for > something *more generic* that you're incapable of seeing the forest > since you've gotta cut down that one tree fast, and who gives a rip what > anyone else needs to do in the forest... Hyperbole. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 20:33:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1B7FB37B544; Mon, 19 Jun 2000 20:33:40 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5K3Xbg29084; Mon, 19 Jun 2000 20:33:37 -0700 (PDT) Date: Mon, 19 Jun 2000 20:33:37 -0700 From: Alfred Perlstein To: Nate Williams Cc: Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619203337.L17420@fw.wintelcom.net> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> <200006200318.VAA15996@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006200318.VAA15996@nomad.yogotech.com>; from nate@yogotech.com on Mon, Jun 19, 2000 at 09:18:16PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nate Williams [000619 20:19] wrote: > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > make FreeBSD a better platform for real-world applications? > > For a very common application, yes. WWW serving is not FreeBSD's strong > point, IMO. Nate, i don't think "out of touch" even begins to describe what your statement implies about your perceptions of FreeBSD's current userbase. > As a matter of fact, I'd venture to guess that FreeBSD is used in more > embedded systems as a 'network' platform than it's ever used as a WWW > server. Without hard proof I'd be pressed to see it either way. > However, it just so happens that recently it seems that Yahoo has been > pushing *HARD* for alot of WWW-server specific changes, that have little > usefulness outside of that specific application. I don't work for Yahoo. Don't blame Yahoo, blame me, I'm the one looking to make FreeBSD faster for network operations. Yahoo was perfectly happy keeping these changes private until I begged them for some tricks that would make us be able to serve that much content with so little CPU utilization. The accept filters are Yahoo's, kblob is mine. And I'd really appreciate you not 'blaming' a strong backer of FreeBSD for my actions. > > The ability to send static content in the most efficient manner possible > > is a key "big picture" item. You're so tied up in what would be the most > > wonderful engineering solution that you're completely ignoring this. > > You're so wrapped up with building WWW server that you've completely > ignored the rest of the developer community, who actually have needs for > something *more generic* that you're incapable of seeing the forest > since you've gotta cut down that one tree fast, and who gives a rip what > anyone else needs to do in the forest... Actually at this point I'm going to make kblob more modular even though nothing about it's current state prevents the expansion from happening at a later point. I'll have it up for review in a day or so. pfft. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 19 21: 5:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 074F937BA0A; Mon, 19 Jun 2000 21:05:38 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 780D21C4D; Tue, 20 Jun 2000 00:05:37 -0400 (EDT) Date: Tue, 20 Jun 2000 00:05:37 -0400 From: Bill Fumerola To: Nate Williams Cc: Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000620000537.A8523@jade.chc-chimes.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> <200006200318.VAA15996@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006200318.VAA15996@nomad.yogotech.com>; from nate@yogotech.com on Mon, Jun 19, 2000 at 09:18:16PM -0600 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 09:18:16PM -0600, Nate Williams wrote: > However, it just so happens that recently it seems that Yahoo has been > pushing *HARD* for alot of WWW-server specific changes, that have little > usefulness outside of that specific application. I'll note that when this was discussed in October it was for another company that had a very large number of FreeBSD servers in production, and it wasn't yahoo. Two seperate large implementations needed this performance ability, my company will benefit from it as well. The power to serve, remember? -- Bill Fumerola - Network Architect / Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 1:23:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id B57E237BCED; Tue, 20 Jun 2000 01:23:52 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 035E32B206; Tue, 20 Jun 2000 03:23:51 -0500 (CDT) Date: Tue, 20 Jun 2000 01:23:51 -0700 From: Paul Saab To: Nate Williams Cc: Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000620012351.A48168@elvis.mu.org> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> <200006200318.VAA15996@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006200318.VAA15996@nomad.yogotech.com>; from nate@yogotech.com on Mon, Jun 19, 2000 at 09:18:16PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams (nate@yogotech.com) wrote: > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > make FreeBSD a better platform for real-world applications? > > For a very common application, yes. WWW serving is not FreeBSD's strong > point, IMO. > > As a matter of fact, I'd venture to guess that FreeBSD is used in more > embedded systems as a 'network' platform than it's ever used as a WWW > server. > > However, it just so happens that recently it seems that Yahoo has been > pushing *HARD* for alot of WWW-server specific changes, that have little > usefulness outside of that specific application. Umm.. I've stayed out of this until now. Yahoo is no way is trying to influence the direction of FreeBSD.. Alfred asked for some of our local hacks and we gave them to him. I dont see how we are pushing specific changes. We believe the changes are good, and even better that is now generic, but dont say we are pushing *HARD*, when that isn't happening. I think you may be confusing the fact that there are people from Yahoo who are also committers. I think the fact that we bring our knowledge (mostly filo's) to FreeBSD is a good thing. We need to know what really happens in the real-world, not in the theoretical world and that is what Yahoo can bring to FreeBSD. -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 4: 2:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6295E37B618 for ; Tue, 20 Jun 2000 04:02:15 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id VAA26961; Tue, 20 Jun 2000 21:02:01 +1000 Date: Tue, 20 Jun 2000 21:01:59 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. In-Reply-To: <20000619111309.E26801@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Jun 2000, Alfred Perlstein wrote: > /* > * returns an fd to be used with kblobsend, preloads len of *addr into > * the kernel to be sent out > */ > int kblob __P((int len, void *addr)); This should be: int kblob __P((const void *addr, size_t len)); (like write(2)). > /* > * see sendfile(2), but instead of the fd referencing a vnode it > * references a fd returned from kblob > */ > int kblobsend __P((int, int, off_t, size_t, struct sf_hdtr *, ^ const? (same for sendfile(2)) > off_t *, int)); Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 5:22:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1C59C37BE85; Tue, 20 Jun 2000 05:22:25 -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 OAA72721; Tue, 20 Jun 2000 14:22:14 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: van.woerkom@netcologne.de Cc: grog@sydney.worldwide.lemis.com, FreeBSD-current@FreeBSD.ORG, FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? References: <20000618160223.A2482@sydney.worldwide.lemis.com> <200006190001.CAA03596@oranje.my.domain> <200006190009.CAA03688@oranje.my.domain> From: Dag-Erling Smorgrav Date: 20 Jun 2000 14:22:13 +0200 In-Reply-To: Marc van Woerkom's message of "Mon, 19 Jun 2000 02:09:44 +0200 (CEST)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marc van Woerkom writes: > > SGIs and SUNs use an 'eject' command for CDs and DAT tapes. > OpenBSD 2.6 uses 'mt' and 'eject' > NetBSD 1.4 uses 'eject' as well. # mt -f /dev/rsa0 offline # camcontrol eject cd0 DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 5:28:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 643BD37B6FD for ; Tue, 20 Jun 2000 05:28:43 -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 OAA72744; Tue, 20 Jun 2000 14:28:39 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. References: <20000619111309.E26801@fw.wintelcom.net> From: Dag-Erling Smorgrav Date: 20 Jun 2000 14:28:38 +0200 In-Reply-To: Alfred Perlstein's message of "Mon, 19 Jun 2000 11:13:09 -0700" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > oops, you can find the preliminary kblob diffs over here: > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > It's a new syscall, less overhead than sendfile and useful for > serving small chunks of data very quickly. Do kblobs do anything that can't be easily done with sendfile() by mmapping suitably large chunks of /dev/null? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 5:32:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7969137B5F0 for ; Tue, 20 Jun 2000 05:32:18 -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 OAA72764; Tue, 20 Jun 2000 14:32:14 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Alfred Perlstein Cc: John-Mark Gurney , arch@FreeBSD.ORG Subject: Re: kblob discussion. References: <20000619125345.H26801@fw.wintelcom.net> <3249.961452627@localhost> <20000619151809.C17420@fw.wintelcom.net> <20000619153634.24385@hydrogen.funkthat.com> <20000619155408.E17420@fw.wintelcom.net> From: Dag-Erling Smorgrav Date: 20 Jun 2000 14:32:13 +0200 In-Reply-To: Alfred Perlstein's message of "Mon, 19 Jun 2000 15:54:08 -0700" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > It doesn't bother you at all that cdrom.com can push 100mbit > and support 6000 users on FreeBSD but Joe Average FreeBSD User > can't because the hacks used aren't available? > [...] > Last I heard, cdrom.com uses 2gigs of kernel virtual address space. There's a FAQ entry that describes how to do this (last entry in section 13). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 5:59:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0DA6937B7FB for ; Tue, 20 Jun 2000 05:59:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA03152; Tue, 20 Jun 2000 22:59:11 +1000 Date: Tue, 20 Jun 2000 22:59:09 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: AOUT support for "make world"? In-Reply-To: <200006191852.UAA02412@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 6: 0:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 0B4C737B7FB for ; Tue, 20 Jun 2000 06:00:36 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 12144 invoked from network); 20 Jun 2000 13:00:32 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 20 Jun 2000 13:00:32 -0000 Date: Tue, 20 Jun 2000 23:00:30 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: AOUT support for "make world"? In-Reply-To: <200006191852.UAA02412@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Jun 2000, Mark Murray wrote: > Question: do we still support a.out make worlds? I have _no_ way Not in practice. In theory, something like "TARGETOBJFORMAT=aout make world" should build an aout world, but we don't have TARGETOBJFORMAT. "OBJFORMAT=aout make world" isn't quite the same, but it should work on systems that have aout libraries. Running it showed the following bugs: - linking of the gperf tool failed, apparently due to bitrot in the aout C++ libraries (I'm using ones built locally a year or two ago). - linking of the objdump tool failed, due to bitrot in the aout libc (missing mkstemps()). Several other tools have the same bug, so I stopped attempting to build here. Commit mail has shown the following bugs: - libc now uses weak symbols, but aout doesn't support weak symbols. This may only break libc_r. > Perl has (had) a special case for a.out builds, and I'd like to > remove this in favour of ELF-only. > > May I do this? I don't see any reason to support building the whole world in aout format. Only building of libraries in aout format, and bootstrapping from aout systems should be supported. The latter is a special case of cross-building. Bootstrapping from systems without perl has been unsupported for a year now, for both aout and elf host systems. Fixing it might involve making perl a build-tool, but that would be too hard to do right. Instead, makeworld should be changed to not use perl, or to use only miniperl, or to have postinstall stage(s) which run the target perl. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 8:47:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id CE45837BB5A; Tue, 20 Jun 2000 08:47:00 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA22540; Tue, 20 Jun 2000 09:46:56 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id JAA18608; Tue, 20 Jun 2000 09:46:55 -0600 (MDT) (envelope-from nate) Date: Tue, 20 Jun 2000 09:46:55 -0600 (MDT) Message-Id: <200006201546.JAA18608@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Saab Cc: Nate Williams , Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-Reply-To: <20000620012351.A48168@elvis.mu.org> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com> <200006200318.VAA15996@nomad.yogotech.com> <20000620012351.A48168@elvis.mu.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think you may be confusing the fact that there are people from Yahoo > who are also committers. I think the fact that we bring our knowledge > (mostly filo's) to FreeBSD is a good thing. My apologies. It just seems that recent commits have been WWW-centric, and my knee-jerk reaction was to assume that somehow Yahoo was pushing for them. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 9:35:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3BFF537BBBF; Tue, 20 Jun 2000 09:35:31 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5KGZQa16639; Tue, 20 Jun 2000 09:35:26 -0700 (PDT) Date: Tue, 20 Jun 2000 09:35:26 -0700 From: Alfred Perlstein To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, jlemon@FreeBSD.ORG, msmith@FreeBSD.ORG, nate@FreeBSD.ORG Subject: MORE: Re: kblob discussion. Message-ID: <20000620093526.Q17420@fw.wintelcom.net> References: <20000619111309.E26801@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from des@flood.ping.uio.no on Tue, Jun 20, 2000 at 02:28:38PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dag-Erling Smorgrav [000620 05:28] wrote: > Alfred Perlstein writes: > > oops, you can find the preliminary kblob diffs over here: > > > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > > > It's a new syscall, less overhead than sendfile and useful for > > serving small chunks of data very quickly. > > Do kblobs do anything that can't be easily done with sendfile() by > mmapping suitably large chunks of /dev/null? Sendfile's vm tricks and additional overhead per-page sized chunks make it unsuitable for sending smaller chunks of data. Paul Saab noticed that for some workloads it was actually slower than just copying the data while working at Hotmail. Kblob would have given FreeBSD the edge to stomp win2k without actually putting the webserver in the kernel. Last night I started thinking about making kblob more flexible, here's the problem I came across: All the papers that have been given to me make sure that once a 0 copy buffer is shared across subsystems it is immutable until the data it's loaned has gone back to no references except by the user process. Not following the above system is _wrong_. There's the problem, it's entirely possible that a connection that has had a an mbuf referencing a kblob has been shut down improperly forcing the kblob to be held for much longer than needed. If we do have an API that allows for modifying kblobs once they are constituted it can only be done when no other systems are referencing the data. This becomes a tracking nightmare if we want to allow the user program to figure out exactly which socket they have open is causing a kblob to stay "stuck". My intention is to leave this up to the system, one can set a kblob non-blocking to return EAGAIN if it's in use, or block on it until the refcount goes back to one? Perhaps we can attach kevents to them to notify the user when they are "free" again. Now it seems that it's not as lightweight anymore. *sigh* -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 9:36:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6820237BEA7; Tue, 20 Jun 2000 09:36:18 -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.3) with ESMTP id SAA53947; Tue, 20 Jun 2000 18:36:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: nate@yogotech.com (Nate Williams) Cc: Paul Saab , Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Tue, 20 Jun 2000 09:46:55 MDT." <200006201546.JAA18608@nomad.yogotech.com> Date: Tue, 20 Jun 2000 18:36:01 +0200 Message-ID: <53945.961518961@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006201546.JAA18608@nomad.yogotech.com>, Nate Williams writes: >> I think you may be confusing the fact that there are people from Yahoo >> who are also committers. I think the fact that we bring our knowledge >> (mostly filo's) to FreeBSD is a good thing. > >My apologies. It just seems that recent commits have been WWW-centric, >and my knee-jerk reaction was to assume that somehow Yahoo was pushing >for them. In general it would be nice if you would not reply with any knee-jerk reactions, no matter what. In most cases I find your second email on topics to be much more usable than the first. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 9:37:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9C8B237B787; Tue, 20 Jun 2000 09:37:40 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA22997; Tue, 20 Jun 2000 10:37:31 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA19210; Tue, 20 Jun 2000 10:37:31 -0600 (MDT) (envelope-from nate) Date: Tue, 20 Jun 2000 10:37:31 -0600 (MDT) Message-Id: <200006201637.KAA19210@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: nate@yogotech.com (Nate Williams), Paul Saab , Mike Smith , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-Reply-To: <53945.961518961@critter.freebsd.dk> References: <200006201546.JAA18608@nomad.yogotech.com> <53945.961518961@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> I think you may be confusing the fact that there are people from Yahoo > >> who are also committers. I think the fact that we bring our knowledge > >> (mostly filo's) to FreeBSD is a good thing. > > > >My apologies. It just seems that recent commits have been WWW-centric, > >and my knee-jerk reaction was to assume that somehow Yahoo was pushing > >for them. > > In general it would be nice if you would not reply with any knee-jerk > reactions, no matter what. In most cases I find your second email > on topics to be much more usable than the first. You can't have a second email until the first is already out. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 9:43:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id DD65937BBBD for ; Tue, 20 Jun 2000 09:43:53 -0700 (PDT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id MAA04125; Tue, 20 Jun 2000 12:43:50 -0400 (EDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 12:43:45 -0400 Message-ID: From: Christopher Sedore To: "'Alfred Perlstein'" , "'arch@freebsd.org'" Subject: RE: MORE: Re: kblob discussion. Date: Tue, 20 Jun 2000 12:43:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [...] >Last night I started thinking about making kblob more flexible, >here's the problem I came across: > >All the papers that have been given to me make sure that once a >0 copy buffer is shared across subsystems it is immutable until >the data it's loaned has gone back to no references except by >the user process. > >Not following the above system is _wrong_. I'm not sure I would put that level of emphasis on _wrong_. It deserves that level of emphasis if it can cause kernel state (or other system) corruption (which should be reason for _wrong_, though I'd call this a problem with implementation more than anything else). If the user/application can only screw up its own data/connections (in the sense of undefined, possibly random data being sent/written), then why not state that modifying the data causes undefined results (including TCP checksum errors, whatever else) and let the programmer beware. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 9:49:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5DC2937BBBF for ; Tue, 20 Jun 2000 09:49:55 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5KGnrF17108; Tue, 20 Jun 2000 09:49:53 -0700 (PDT) Date: Tue, 20 Jun 2000 09:49:53 -0700 From: "'Alfred Perlstein'" To: Christopher Sedore Cc: "'arch@freebsd.org'" Subject: Re: MORE: Re: kblob discussion. Message-ID: <20000620094953.R17420@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from cmsedore@maxwell.syr.edu on Tue, Jun 20, 2000 at 12:43:34PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Christopher Sedore [000620 09:43] wrote: > > [...] > > >Last night I started thinking about making kblob more flexible, > >here's the problem I came across: > > > >All the papers that have been given to me make sure that once a > >0 copy buffer is shared across subsystems it is immutable until > >the data it's loaned has gone back to no references except by > >the user process. > > > >Not following the above system is _wrong_. > > I'm not sure I would put that level of emphasis on _wrong_. It deserves > that level of emphasis if it can cause kernel state (or other system) > corruption (which should be reason for _wrong_, though I'd call this a > problem with implementation more than anything else). If the > user/application can only screw up its own data/connections (in the sense of > undefined, possibly random data being sent/written), then why not state that > modifying the data causes undefined results (including TCP checksum errors, > whatever else) and let the programmer beware. Because it puts undue burden on the rest of the kernel to cope with a user's access to internals. What happens if we are using some sort of checksum offloading chipset or encryption/compression system that can't stand the data being ripped out from under it. What's the point of recalculating the checksum of a packet when we know it shouldn't have changed? It's wrong. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:22:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C265E37B5E5 for ; Tue, 20 Jun 2000 10:22:14 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA25343 for ; Tue, 20 Jun 2000 10:21:29 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAAPnaWCX; Tue Jun 20 10:21:25 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA19309 for arch@freebsd.org; Tue, 20 Jun 2000 10:22:04 -0700 (MST) From: Terry Lambert Message-Id: <200006201722.KAA19309@usr01.primenet.com> Subject: Software detection of link integrity To: arch@freebsd.org Date: Tue, 20 Jun 2000 17:22:04 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... as some have noted, I blew the subject line on this ... ] FWIW, I ran into a use for being able to tell from software whether the link integrity on an ethernet card was valid or not. My question is, I know my hardware can report it, but is this a general feature of most ethernet cards? I know that Intel 82558 and 82559 cards can tell you by you looking at bit 2 of MDI register #1 (if the bit is lit, so is the blinky light hidden at the back of your rack). Would this be a useful thing to build into ifconfig? I don't know how many of you find yourself crawling behind stacks of hardware to look for the blinky lights... 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:26:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 364C837BF77 for ; Tue, 20 Jun 2000 10:26:45 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id KAA27041 for ; Tue, 20 Jun 2000 10:26:57 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAA6baaW0; Tue Jun 20 10:26:48 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA19419 for arch@freebsd.org; Tue, 20 Jun 2000 10:26:33 -0700 (MST) From: Terry Lambert Message-Id: <200006201726.KAA19419@usr01.primenet.com> Subject: Suggested change to BSD sockets API To: arch@freebsd.org Date: Tue, 20 Jun 2000 17:26:32 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One common problem I run into is that of cached state. In particular, if I have a dial-on-demand device that uses a dynamic IP address assignment negotiated with the remote side of the link, then all of my servers currently bound and listening for incoming connections have to be clobbered over the head for them to notice the IP address change. It seems to me that this could be better handled. The problem appears to be cached state information (I have been meaning to write a white paper on "cached state considered harmful"). For example, an inetd, a DNS server, or a sendmail bound to a network address on an interface must be rebound when the IP address changes. I'd like to suggest that a new socket binding type be used; one that binds not to an IP addres, but to an interface. The changes to support this don't seem that difficult; what do others think about this? 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:29:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 2857537BFAC for ; Tue, 20 Jun 2000 10:29:23 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA27550; Tue, 20 Jun 2000 10:28:41 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAA4UaOW1; Tue Jun 20 10:28:37 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA19533; Tue, 20 Jun 2000 10:29:15 -0700 (MST) From: Terry Lambert Message-Id: <200006201729.KAA19533@usr01.primenet.com> Subject: Re: kblob discussion. To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Tue, 20 Jun 2000 17:29:15 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Jun 20, 2000 02:28:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > oops, you can find the preliminary kblob diffs over here: > > > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > > > It's a new syscall, less overhead than sendfile and useful for > > serving small chunks of data very quickly. > > Do kblobs do anything that can't be easily done with sendfile() by > mmapping suitably large chunks of /dev/null? Don't dirty chunks of /dev/zero (I think you meant /dev/zero?) get written to swap? This would seem to be not very useful overhead. Alfred already pointed out the mlock/sendfile approach, and why it was not recisely the same as what he intended by "kblob". I think this interface is, to a large extent, an unfortunate victim of its current name. 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:40:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E08BF37B5A5 for ; Tue, 20 Jun 2000 10:40:37 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id KAA01055; Tue, 20 Jun 2000 10:40:49 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAgYa48b; Tue Jun 20 10:40:38 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA20126; Tue, 20 Jun 2000 10:40:22 -0700 (MST) From: Terry Lambert Message-Id: <200006201740.KAA20126@usr01.primenet.com> Subject: Re: kernel thread support To: jasone@canonware.com (Jason Evans) Date: Tue, 20 Jun 2000 17:40:22 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20000616144259.Q47268@blitz.canonware.com> from "Jason Evans" at Jun 16, 2000 02:42:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know if this has been reported yet. The send-pr system hates my machine because it uses unpublished DNS information. This is posted to arch, since an architectural decision on what the correct behaviour of signal(3) should be: no matter which way the decision goes, it appears to me that libc and libc_r should behave the same way. --- FYI, after I helped someone track down a hanging problem in OpenLDAP, it was pointed out that the libc_r "signal" symbol is omitted in the list of weak exports, and so even if you link with libc_r, you get the libc version. The libc and libc_r versions differ, in that the libc_r version does not restart system calls, while the libc version does. This is apparently a BSD legacy issue with using the non-POSIX signals interface, and getting variant behaviour. It is probably more correct to explicitly use the POSIX interface, and call the sigaction() call directly, with sa_flags = 0, but OpenLDAP and other code is unliekly to change in this regard. Using siginterrupt() didn't help; it is apparently not threads-aware, or there is an order of operations bug in its libc_r implementation. For OpenLDAP, the libc_r version is correct; it permits users to send SIGTERM to the LDAP server to shut it down. This can be fixed by adding "signal.o" to the "HIDDEN_SYSCALLS" variable in the libc_r Makefile. 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:50: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id 5054D37C1CB for ; Tue, 20 Jun 2000 10:48:15 -0700 (PDT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id NAA05912 for ; Tue, 20 Jun 2000 13:48:18 -0400 (EDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 13:48:14 -0400 Message-ID: From: Christopher Sedore To: "'arch@freebsd.org'" Subject: RE: MORE: Re: kblob discussion. Date: Tue, 20 Jun 2000 13:48:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >* Christopher Sedore [000620 09:43] wrote: >> >> [...] >> >> >Last night I started thinking about making kblob more flexible, >> >here's the problem I came across: >> > >> >All the papers that have been given to me make sure that once a >> >0 copy buffer is shared across subsystems it is immutable until >> >the data it's loaned has gone back to no references except by >> >the user process. >> > >> >Not following the above system is _wrong_. >> >> I'm not sure I would put that level of emphasis on _wrong_. > It deserves >> that level of emphasis if it can cause kernel state (or other system) >> corruption (which should be reason for _wrong_, though I'd >call this a >> problem with implementation more than anything else). If the >> user/application can only screw up its own data/connections >(in the sense of >> undefined, possibly random data being sent/written), then >why not state that >> modifying the data causes undefined results (including TCP >checksum errors, >> whatever else) and let the programmer beware. > >Because it puts undue burden on the rest of the kernel to cope with >a user's access to internals. What happens if we are using some >sort of checksum offloading chipset or encryption/compression system >that can't stand the data being ripped out from under it. What's >the point of recalculating the checksum of a packet when we know >it shouldn't have changed? > >It's wrong. :) The only access is to data that the user passed in already, so harm should be limited to incorrect checksums. I guess I have to agree that ultimately it would be harder to make sure the kernel could deal with changes in this area than just to prevent them in the first place. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 10:56:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 56EB837BFAE for ; Tue, 20 Jun 2000 10:56:32 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA10474; Tue, 20 Jun 2000 18:52:31 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA64474; Tue, 20 Jun 2000 18:52:29 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006201752.SAA64474@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: Suggested change to BSD sockets API In-Reply-To: Message from Terry Lambert of "Tue, 20 Jun 2000 17:26:32 -0000." <200006201726.KAA19419@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 18:52:29 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I believe Julian E did some work on this at one point but never finished it. The real problem is that once you've sent that first packet, your local IP number is cast in stone. You only have a chance of doing something prior to that - ie, at the point where data arrives at the interface and the interface decides it has to do something to establish an IP number. This is already done in ppp(8) if you use -nat and -auto. Ppp will retain the old IP number, assign the just-negotiated IP number with SIOCAIFADDR and NAT the outgoing packet just-in-time so that the initial connection succeeds. This isn't the most elegant way (it would be better to be able to bind to an interface that has no IP number and then retrospectively resolve the binding when an IP number is assigned), but it works. > One common problem I run into is that of cached state. > > In particular, if I have a dial-on-demand device that uses > a dynamic IP address assignment negotiated with the remote > side of the link, then all of my servers currently bound > and listening for incoming connections have to be clobbered > over the head for them to notice the IP address change. > > It seems to me that this could be better handled. > > The problem appears to be cached state information (I have > been meaning to write a white paper on "cached state considered > harmful"). > > For example, an inetd, a DNS server, or a sendmail bound to a > network address on an interface must be rebound when the IP > address changes. > > > I'd like to suggest that a new socket binding type be used; one > that binds not to an IP addres, but to an interface. > > The changes to support this don't seem that difficult; what do > others think about this? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 11:53:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 58B6F37BFCE for ; Tue, 20 Jun 2000 11:53:51 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.1.105]) by gw.nectar.com (Postfix) with ESMTP id C112E9B2F; Tue, 20 Jun 2000 13:53:48 -0500 (CDT) Received: by bone.nectar.com (Postfix, from userid 1001) id 0B4201DC6; Tue, 20 Jun 2000 13:53:43 -0500 (CDT) Date: Tue, 20 Jun 2000 13:53:42 -0500 From: "Jacques A . Vidrine" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please Message-ID: <20000620135342.C29773@bone.nectar.com> References: <200006192352.QAA03874@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006192352.QAA03874@usr06.primenet.com>; from tlambert@primenet.com on Mon, Jun 19, 2000 at 11:52:57PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 11:52:57PM +0000, Terry Lambert wrote: > FWIW, I ran into a use for being able to tell from software > whether the link integrity on an ethernet card was valid or > not. [snip] > Would this be a useful thing to build into ifconfig? Is this different from the `status: active' that ifconfig currently reports based on the ifm_status field of the structure filled by the SIOCGIFMEDIA ioctl? That's what I currently use to decide whether to run DHCP on my laptop's interface. I don't know where that ioctl is documented. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 12:21:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 0ACF737BDB6 for ; Tue, 20 Jun 2000 12:21:05 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id PAA28278; Tue, 20 Jun 2000 15:21:00 -0400 (EDT) Date: Tue, 20 Jun 2000 15:21:00 -0400 (EDT) From: "Matthew N. Dodd" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Software detection of link integrity In-Reply-To: <200006201722.KAA19309@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jun 2000, Terry Lambert wrote: > Would this be a useful thing to build into ifconfig? Ideally, network drivers shouldn't set the IFF_UP flag until the link is actually up. -- | 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 12:32:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 34B3637BC78; Tue, 20 Jun 2000 12:32:07 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 964302B245; Tue, 20 Jun 2000 14:32:06 -0500 (CDT) Date: Tue, 20 Jun 2000 12:32:06 -0700 From: Paul Saab To: Alfred Perlstein Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, jlemon@FreeBSD.ORG, msmith@FreeBSD.ORG, nate@FreeBSD.ORG Subject: Re: MORE: Re: kblob discussion. Message-ID: <20000620123206.A56823@elvis.mu.org> References: <20000619111309.E26801@fw.wintelcom.net> <20000620093526.Q17420@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000620093526.Q17420@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jun 20, 2000 at 09:35:26AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein (bright@wintelcom.net) wrote: > * Dag-Erling Smorgrav [000620 05:28] wrote: > > Alfred Perlstein writes: > > > oops, you can find the preliminary kblob diffs over here: > > > > > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > > > > > It's a new syscall, less overhead than sendfile and useful for > > > serving small chunks of data very quickly. > > > > Do kblobs do anything that can't be easily done with sendfile() by > > mmapping suitably large chunks of /dev/null? > > Sendfile's vm tricks and additional overhead per-page sized chunks > make it unsuitable for sending smaller chunks of data. Paul Saab > noticed that for some workloads it was actually slower than just > copying the data while working at Hotmail. I was talking with dg last week and we may have found a flaw in the way that I measured the speed. I am fairly convinced now that sendfile is the prefered way to send data from a file. -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 12:56:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 82B4737BFA9 for ; Tue, 20 Jun 2000 12:56:27 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id UAA11185; Tue, 20 Jun 2000 20:50:36 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id UAA65946; Tue, 20 Jun 2000 20:50:34 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006201950.UAA65946@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matthew N. Dodd" Cc: Terry Lambert , arch@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: Software detection of link integrity In-Reply-To: Message from "Matthew N. Dodd" of "Tue, 20 Jun 2000 15:21:00 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 20:50:34 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 20 Jun 2000, Terry Lambert wrote: > > Would this be a useful thing to build into ifconfig? > > Ideally, network drivers shouldn't set the IFF_UP flag until the link is > actually up. Unless of course the driver (or something behind it) wants to bring the link up on demand. > -- > | 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 | -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13: 2:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 82AED37BFFF for ; Tue, 20 Jun 2000 13:02:48 -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.3) with ESMTP id WAA55572; Tue, 20 Jun 2000 22:02:32 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: "Matthew N. Dodd" , Terry Lambert , arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: Software detection of link integrity In-reply-to: Your message of "Tue, 20 Jun 2000 20:50:34 BST." <200006201950.UAA65946@hak.lan.Awfulhak.org> Date: Tue, 20 Jun 2000 22:02:32 +0200 Message-ID: <55570.961531352@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006201950.UAA65946@hak.lan.Awfulhak.org>, Brian Somers writes: >> On Tue, 20 Jun 2000, Terry Lambert wrote: >> > Would this be a useful thing to build into ifconfig? >> >> Ideally, network drivers shouldn't set the IFF_UP flag until the link is >> actually up. > >Unless of course the driver (or something behind it) wants to bring >the link up on demand. We actually have major suckage in this corner. I have tried to edge towards more intelligent behaviour: Look at if_up(), if_route() and IFF_SMART. Basically the idea is that an "IFF_SMART" interface will fiddle the up/down-ness of individual protocols as makes sense. I did this entirely for sppp, but it applies fully to any other interface: an ethernet should remain configured but remove the routes if the cable is unplugged. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13:25:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D45037C0D4 for ; Tue, 20 Jun 2000 13:25:37 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115222>; Wed, 21 Jun 2000 06:25:22 +1000 Date: Tue, 20 Jun 2000 19:58:52 +1000 From: Peter Jeremy Subject: Re: Preemptive kernel on older X86 hardware In-reply-to: <20000601223101.A17391@sharmas.dhs.org>; from adsharma@sharmas.dhs.org on Fri, Jun 02, 2000 at 03:31:46PM +1000 To: Arun Sharma Cc: arch@FreeBSD.ORG Message-Id: <00Jun21.062522est.115222@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200005250208.TAA78220@apollo.backplane.com> <82645.959243483@localhost> <20000601223101.A17391@sharmas.dhs.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Digging up some old e-mail... On Fri, Jun 02, 2000 at 03:31:46PM +1000, Arun Sharma wrote: >And self modifying code also isn't exactly cheap either on that >architecture. My understanding of the proposal is that the lock reference would be compiled as a function call and some padding. The first time that the code is executed, it will be updated in-place with the optimum code for the UP/SMP/processor configuration. This first execution _is_ quite expensive - function call, code update and various cache flushes - but subsequent executions are optimal inline code. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13:25:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EC6F737C0D9 for ; Tue, 20 Jun 2000 13:25:50 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115228>; Wed, 21 Jun 2000 06:25:26 +1000 Date: Tue, 20 Jun 2000 18:23:49 +1000 From: Peter Jeremy Subject: Re: Plans to change our debugging format to DWARF2 In-reply-to: <20000608091507.E1587@daemon.ninth-circle.org>; from asmodai@wxs.nl on Thu, Jun 08, 2000 at 05:19:31PM +1000 To: Jeroen Ruigrok/Asmodai Cc: arch@FreeBSD.ORG Message-Id: <00Jun21.062526est.115228@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <20000606124116.A16993@cons.org> <20000606080031.F78380@dragon.nuxi.com> <20000608091507.E1587@daemon.ninth-circle.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 08, 2000 at 05:19:31PM +1000, Jeroen Ruigrok/Asmodai wrote: >I'd say go for it. But of course we want to MFC this to 4.x as well >some point in the future. Along with all the other compiler changes. Why? This strikes me as a major change to a critical part of the system - well beyond what I would expect to see in -stable. Somewhat over a year ago (from memory) there was an extended debate about upgrading from gcc2.7.2.2 to gcc2.8.1 or ECGS. At that time there was substantial resistance to the change - on the basis that the behaviour of gcc2.7.2.2 was well understood. Whilst ECGS (and later gcc2.95) were merged into 4-current, it was never MFC'd back to 3.x. If the recent changes to gcc and binutils were merged back into -stable, there would seem to be seem to be a high probability that -stable would break. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13:26:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 8436337C149 for ; Tue, 20 Jun 2000 13:26:36 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA11350; Tue, 20 Jun 2000 21:24:28 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA66394; Tue, 20 Jun 2000 21:24:25 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006202024.VAA66394@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Brian Somers , "Matthew N. Dodd" , Terry Lambert , arch@FreeBSD.ORG, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity In-Reply-To: Message from Poul-Henning Kamp of "Tue, 20 Jun 2000 22:02:32 +0200." <55570.961531352@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 21:24:25 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200006201950.UAA65946@hak.lan.Awfulhak.org>, Brian Somers writes: > >> On Tue, 20 Jun 2000, Terry Lambert wrote: > >> > Would this be a useful thing to build into ifconfig? > >> > >> Ideally, network drivers shouldn't set the IFF_UP flag until the link is > >> actually up. > > > >Unless of course the driver (or something behind it) wants to bring > >the link up on demand. > > We actually have major suckage in this corner. I have tried to > edge towards more intelligent behaviour: > > Look at if_up(), if_route() and IFF_SMART. > > Basically the idea is that an "IFF_SMART" interface will fiddle > the up/down-ness of individual protocols as makes sense. > > I did this entirely for sppp, but it applies fully to any other > interface: an ethernet should remain configured but remove the > routes if the cable is unplugged. No, I think the aim here is to keep the routes but to adjust them so that they're via an interface rather than an IP number, something like: default tun0 UGSc 11 503 tun0 127.0.0.1 127.0.0.1 UH 0 12837 lo0 172.16/24 link#1 UC 0 0 de0 => 172.16.0.1 0:0:c0:ff:e9:ce UHLW 5 7360 lo0 172.16.0.5 0:0:c0:b5:ca:ae UHLW 8 587157 de0 895 172.16.0.6 0:a0:24:4b:1f:51 UHLW 0 7840 de0 862 tun0 172.16.0.1 UH 11 63 tun0 172.16.0.9 0:0:c0:ff:e9:ce UHLS2 0 0 de0 172.16.0.10 link#1 UHLW 2 184 de0 => 172.16.0.12 0:0:f4:5e:60:a9 UHLW 2 92225 de0 424 172.16.0.13 8:0:20:b:bf:72 UHLW 1 12455 de0 344 172.16.0.255 ff:ff:ff:ff:ff:ff UHLWb 2 711 de0 172.17/24 172.16.0.12 UGSc 0 3290 de0 194.242.139.171/32 212.140.212.135 UGSc 1 0 tun1 194.242.139.172/32 212.140.212.135 UGSc 0 0 tun1 212.140.212.135 62.7.116.163 UH 3 0 tun1 Where tun0's transport has disappeared, we want to be able to do a connect() to say freefall, resulting in a sort of loose binding to the tun0 interface rather than an IP number, and a packet going out to the tun0 interface saying "please fix my source address quickly". I haven't looked at the SMART stuff, but I guess that'll find some way to assign numbers to the interface and adjust the outgoing packet(s) along with any semi-bound socket(s). Deleting routes would defeat the functionality IMHO. I *think* Julian introduced code that will do this - so that you can creating route entries that contain sockaddr_dl's rather than sockaddr_in's, but I also *think* that's as far as it went. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13:26:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from funkthat.com (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id C870737C148 for ; Tue, 20 Jun 2000 13:26:39 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by funkthat.com (8.9.3/8.8.7) id NAA40729; Tue, 20 Jun 2000 13:26:26 -0700 (PDT) Message-ID: <20000620132626.09206@hydrogen.funkthat.com> Date: Tue, 20 Jun 2000 13:26:26 -0700 From: John-Mark Gurney To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Suggested change to BSD sockets API References: <200006201726.KAA19419@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <200006201726.KAA19419@usr01.primenet.com>; from Terry Lambert on Tue, Jun 20, 2000 at 05:26:32PM +0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.4-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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert scribbled this message on Jun 20: > I'd like to suggest that a new socket binding type be used; one > that binds not to an IP addres, but to an interface. how do you handle outbound ip's.. which ip address do you use on an interface that has 512+ ip's? > The changes to support this don't seem that difficult; what do > others think about this? so, each time a conenction comes in, it gets compared against the list of sockaddr's attached to the interface? personally, why not teach the deamons to use kq, and extend the kq filters to include a network filter that allows you to notice when sockaddrs on an interface change? Seems like this would work fine w/o having to change much kernel code... also, doesn't gated already get these changes through the routing socket? If anything, the userland apps should be smarter, not the kernel... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "Thank God I'm an atheist, that'd just be confusing." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 13:39:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0F69D37C2E5 for ; Tue, 20 Jun 2000 13:39: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.3) with ESMTP id WAA55788; Tue, 20 Jun 2000 22:39:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: "Matthew N. Dodd" , Terry Lambert , arch@FreeBSD.ORG, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity In-reply-to: Your message of "Tue, 20 Jun 2000 21:24:25 BST." <200006202024.VAA66394@hak.lan.Awfulhak.org> Date: Tue, 20 Jun 2000 22:39:05 +0200 Message-ID: <55786.961533545@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006202024.VAA66394@hak.lan.Awfulhak.org>, Brian Somers writes: >> I did this entirely for sppp, but it applies fully to any other >> interface: an ethernet should remain configured but remove the >> routes if the cable is unplugged. > >No, I think the aim here is to keep the routes but to adjust them so >that they're via an interface rather than an IP number, something >like: We should not keep an route to a net which is down, that is just wrong, and defeats the pupose of routing daemons like gated/zebra etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 14:12:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D06437B5D7 for ; Tue, 20 Jun 2000 14:12:36 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e5KLCOO12691; Tue, 20 Jun 2000 15:12:24 -0600 (MDT) Message-Id: <200006202112.e5KLCOO12691@orthanc.ab.ca> To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Software detection of link integrity In-reply-to: Your message of "Tue, 20 Jun 2000 17:22:04 -0000." <200006201722.KAA19309@usr01.primenet.com> Date: Tue, 20 Jun 2000 15:12:19 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Terry" == Terry Lambert writes: Terry> Would this be a useful thing to build into ifconfig? More useful would be a library call that returns the info. Lots more than ifconfig can make use of this information. E.g., this really wants to be exposed through SNMP as well. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 14:25:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A7B5A37BE0D for ; Tue, 20 Jun 2000 14:25:35 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115222>; Wed, 21 Jun 2000 07:25:27 +1000 Content-return: prohibited Date: Wed, 21 Jun 2000 07:25:19 +1000 From: Peter Jeremy Subject: Re: kblob discussion. In-reply-to: <20000619111309.E26801@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jun 20, 2000 at 04:15:17AM +1000 To: Alfred Perlstein Cc: arch@FreeBSD.ORG Message-Id: <00Jun21.072527est.115222@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <20000619111309.E26801@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-Jun-20 04:15:17 +1000, Alfred Perlstein wrote: >It's a new syscall, less overhead than sendfile and useful for >serving small chunks of data very quickly. What is the behaviour of kblobs across fork() and exec()? Can that be controlled (along the lines of fcntl(...,F_[SG]ETFD,...))? How do you destroy a kblob when it's no longer needed? >/* > * see sendfile(2), but instead of the fd referencing a vnode it > * references a fd returned from kblob > */ >int kblobsend __P((int, int, off_t, size_t, struct sf_hdtr *, > off_t *, int)); Wouldn't it be easier for kblob(2) to return an fd from the same pool as files/sockets - in which case it could just be passed to sendfile(2) which would internally distiguish between a file and a kblob. Also it seems that the current API (for both sendfile(2) and kblobsend(2)) contains an unnecessarily arbitrary restriction that you want to send an optional header, a single object, then an optional trailer. Using writev(2) as a model, how about the following: struct io_obj { enum { OBJ_FILE, OBJ_KBLOB, OBJ_DATA } obj_type; union { const void *obj_data; /* OBJ_DATA */ int obj_fd; /* OBJ_FILE, OBJ_KBLOB */ } u; size_t obj_size; /* 0 for entire file/kblob */ off_t obj_offset; /* start offset in object */ }; ssize_t writeobj(int sock, const struct io_obj *objp, int nobj); This would allow an arbitrary assortment of objects to be written in a single syscall. It also offers a possible path to readobj(2) (which would be able to read directly into a file, user memory, or create a kblob()). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 16: 1:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2603837B5DA for ; Tue, 20 Jun 2000 16:01:29 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA72785; Tue, 20 Jun 2000 15:59:08 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200006202259.PAA72785@gndrsh.dnsmgr.net> Subject: Re: Software detection of link integrity In-Reply-To: <55786.961533545@critter.freebsd.dk> from Poul-Henning Kamp at "Jun 20, 2000 10:39:05 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 20 Jun 2000 15:59:08 -0700 (PDT) Cc: brian@Awfulhak.org (Brian Somers), winter@jurai.net (Matthew N. Dodd), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, brian@hak.lan.awfulhak.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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200006202024.VAA66394@hak.lan.Awfulhak.org>, Brian Somers writes: > > >> I did this entirely for sppp, but it applies fully to any other > >> interface: an ethernet should remain configured but remove the > >> routes if the cable is unplugged. > > > >No, I think the aim here is to keep the routes but to adjust them so > >that they're via an interface rather than an IP number, something > >like: > > We should not keep an route to a net which is down, that is just wrong, > and defeats the pupose of routing daemons like gated/zebra etc. Actually gated doesn't like it much when the kernel removes routes do to an ``ifconfig ifX down'' command. It deals with it, but it doesn't much like it, spewing forth lots and lots of messages about routes messages from the KRT socket :-) Doing this on an ethernet interface with a full bgp4 feed on it will yeild you 70K+ lines of syslog, and a router that is rather busy trying to deal with both a boat load of route socket messages, and a rib rebuild. I've never much liked the fact that the kernel does any form of automatic route addition or removal, it makes userland routing daemons more complex as they have to understand all the things the kernel may do, and not all kernels behave the same. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 18:35:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 346E937B868 for ; Tue, 20 Jun 2000 18:35:39 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA01766; Tue, 20 Jun 2000 18:35:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpdAAAuRaiBd; Tue Jun 20 18:35:21 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA09792; Tue, 20 Jun 2000 18:35:22 -0700 (MST) From: Terry Lambert Message-Id: <200006210135.SAA09792@usr01.primenet.com> Subject: Re: Plans to change our debugging format to DWARF2 To: peter.jeremy@alcatel.com.au (Peter Jeremy) Date: Wed, 21 Jun 2000 01:35:22 +0000 (GMT) Cc: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai), arch@FreeBSD.ORG In-Reply-To: <00Jun21.062526est.115228@border.alcanet.com.au> from "Peter Jeremy" at Jun 20, 2000 06:23:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I'd say go for it. But of course we want to MFC this to 4.x as well > >some point in the future. Along with all the other compiler changes. > > Why? This strikes me as a major change to a critical part of the > system - well beyond what I would expect to see in -stable. > > Somewhat over a year ago (from memory) there was an extended debate > about upgrading from gcc2.7.2.2 to gcc2.8.1 or ECGS. At that time > there was substantial resistance to the change - on the basis that > the behaviour of gcc2.7.2.2 was well understood. Whilst ECGS (and > later gcc2.95) were merged into 4-current, it was never MFC'd back > to 3.x. Actually, my reasoning had to do with templates and the additional overhead for non-threaded programs, if threaded programs were ever to be supported vs. the inability to support threaded programs if the overhead was removed. The GCC code had a dynamic mechanism for per thread exception stacks, which did not have the additional overhead, unles one was actually using threads in C++. The reason the current ACAP code can not be compiled on FreeBSD, and the reason the STL threads primitive classes do not work as expected, as well as the recent linker problems involving the FreeBSD "ld", in combination with template class errors, are all attributable to the move to EGCS. Too bad EGCS has not caught up with GCC + the patches by Jeremy Allison and myself from over a year ago... 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-arch" in the body of the message From owner-freebsd-arch Tue Jun 20 18:42: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 87DAC37B754 for ; Tue, 20 Jun 2000 18:42:01 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id SAA15399; Tue, 20 Jun 2000 18:41:24 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAAyFaWdE; Tue Jun 20 18:41:17 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA09970; Tue, 20 Jun 2000 18:41:52 -0700 (MST) From: Terry Lambert Message-Id: <200006210141.SAA09970@usr01.primenet.com> Subject: Re: Software detection of link integrity To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 21 Jun 2000 01:41:52 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: from "Matthew N. Dodd" at Jun 20, 2000 03:21:00 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 20 Jun 2000, Terry Lambert wrote: > > Would this be a useful thing to build into ifconfig? > > Ideally, network drivers shouldn't set the IFF_UP flag until the link is > actually up. What do they do if the link goes down? This status needs to be seperate. There appears to be an ioctl(0 which might or might not already expose this, according to another poster. Time to investigate... 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-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 12:18:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 899FB37B951 for ; Wed, 21 Jun 2000 12:18:55 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5LJIsO25288; Wed, 21 Jun 2000 12:18:54 -0700 (PDT) Date: Wed, 21 Jun 2000 12:18:54 -0700 From: Alfred Perlstein To: Paul Saab Cc: arch@FreeBSD.ORG Subject: Re: MORE: Re: kblob discussion. Message-ID: <20000621121854.W17420@fw.wintelcom.net> References: <20000619111309.E26801@fw.wintelcom.net> <20000620093526.Q17420@fw.wintelcom.net> <20000620123206.A56823@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000620123206.A56823@elvis.mu.org>; from paul@mu.org on Tue, Jun 20, 2000 at 12:32:06PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Paul Saab [000620 12:34] wrote: > > > > Sendfile's vm tricks and additional overhead per-page sized chunks > > make it unsuitable for sending smaller chunks of data. Paul Saab > > noticed that for some workloads it was actually slower than just > > copying the data while working at Hotmail. > > I was talking with dg last week and we may have found a flaw in the way > that I measured the speed. I am fairly convinced now that sendfile is > the prefered way to send data from a file. Can you elaborate on that? You're saying kblob is not necessary? How was the sendfile testing flawed? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 14:25:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3902937B788 for ; Wed, 21 Jun 2000 14:25:35 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id OAA03650; Wed, 21 Jun 2000 14:17:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAAWCay6g; Wed Jun 21 14:17:39 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA11432; Wed, 21 Jun 2000 14:17:38 -0700 (MST) From: Terry Lambert Message-Id: <200006212117.OAA11432@usr02.primenet.com> Subject: Re: Software detection of link integrity To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 21 Jun 2000 21:17:38 +0000 (GMT) Cc: brian@Awfulhak.org (Brian Somers), winter@jurai.net (Matthew N. Dodd), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, brian@hak.lan.awfulhak.org In-Reply-To: <55786.961533545@critter.freebsd.dk> from "Poul-Henning Kamp" at Jun 20, 2000 10:39:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> I did this entirely for sppp, but it applies fully to any other > >> interface: an ethernet should remain configured but remove the > >> routes if the cable is unplugged. > > > >No, I think the aim here is to keep the routes but to adjust them so > >that they're via an interface rather than an IP number, something > >like: > > We should not keep an route to a net which is down, that is just wrong, > and defeats the pupose of routing daemons like gated/zebra etc. What about a dial on demand device that is transiently connected to the Internet, either through an integrated Analog or ISDN modem? If the route is down, then the link traffic can not be monitored, and if link traffic can not be monitored, then the idea of "demand" can not be implemented. One must be able to have a default route to a "tun0" device for a downed PPP dameon. 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-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 14:28:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 56BDC37B788 for ; Wed, 21 Jun 2000 14:28:41 -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.3) with ESMTP id XAA62879; Wed, 21 Jun 2000 23:28:23 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: brian@Awfulhak.org (Brian Somers), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.ORG, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity In-reply-to: Your message of "Wed, 21 Jun 2000 21:17:38 -0000." <200006212117.OAA11432@usr02.primenet.com> Date: Wed, 21 Jun 2000 23:28:23 +0200 Message-ID: <62877.961622903@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006212117.OAA11432@usr02.primenet.com>, Terry Lambert writes: >> >> I did this entirely for sppp, but it applies fully to any other >> >> interface: an ethernet should remain configured but remove the >> >> routes if the cable is unplugged. >> > >> >No, I think the aim here is to keep the routes but to adjust them so >> >that they're via an interface rather than an IP number, something >> >like: >> >> We should not keep an route to a net which is down, that is just wrong, >> and defeats the pupose of routing daemons like gated/zebra etc. > >What about a dial on demand device that is transiently connected >to the Internet, either through an integrated Analog or ISDN modem? But a dial on demand line is a layered concept. You have a transient physical line with a layer on top of it which pretends to be a permanent line. In this case we obviously talk about the toplayer, not the bottom layer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 14:46:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 2F77037C098 for ; Wed, 21 Jun 2000 14:46:53 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA25391; Wed, 21 Jun 2000 22:43:03 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA02255; Wed, 21 Jun 2000 22:43:00 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006212143.WAA02255@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Terry Lambert , brian@Awfulhak.org (Brian Somers), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: Software detection of link integrity In-Reply-To: Message from Poul-Henning Kamp of "Wed, 21 Jun 2000 23:28:23 +0200." <62877.961622903@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 2000 22:43:00 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200006212117.OAA11432@usr02.primenet.com>, Terry Lambert writes: > >> >> I did this entirely for sppp, but it applies fully to any other > >> >> interface: an ethernet should remain configured but remove the > >> >> routes if the cable is unplugged. > >> > > >> >No, I think the aim here is to keep the routes but to adjust them so > >> >that they're via an interface rather than an IP number, something > >> >like: > >> > >> We should not keep an route to a net which is down, that is just wrong, > >> and defeats the pupose of routing daemons like gated/zebra etc. > > > >What about a dial on demand device that is transiently connected > >to the Internet, either through an integrated Analog or ISDN modem? > > But a dial on demand line is a layered concept. You have a transient > physical line with a layer on top of it which pretends to be a > permanent line. Which unfortunately doesn't work with a dynamically assigned IP number. > In this case we obviously talk about the toplayer, not the bottom layer. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 14:48:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DE00137C0FB for ; Wed, 21 Jun 2000 14:48:15 -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.3) with ESMTP id XAA62969; Wed, 21 Jun 2000 23:47:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Terry Lambert , winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: Software detection of link integrity In-reply-to: Your message of "Wed, 21 Jun 2000 22:43:00 BST." <200006212143.WAA02255@hak.lan.Awfulhak.org> Date: Wed, 21 Jun 2000 23:47:59 +0200 Message-ID: <62967.961624079@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006212143.WAA02255@hak.lan.Awfulhak.org>, Brian Somers writes: >> But a dial on demand line is a layered concept. You have a transient >> physical line with a layer on top of it which pretends to be a >> permanent line. > >Which unfortunately doesn't work with a dynamically assigned IP >number. That is a different story alltogether... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 15:33:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (dhcp120.conference.usenix.org [209.179.127.120]) by hub.freebsd.org (Postfix) with ESMTP id 1823837B9B6 for ; Wed, 21 Jun 2000 15:33:21 -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 WAA04293; Wed, 21 Jun 2000 22:16:41 GMT (envelope-from nik) Date: Wed, 21 Jun 2000 22:16:38 +0000 From: Nik Clayton To: arch@freebsd.org Cc: papowell@astart.com Subject: Bringing LPRng into FreeBSD? Message-ID: <20000621221636.A4137@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi guys, I've just met up with Patrick Powell, author of LPRng, at Usenix. This message is cc'd to him, as he's not on the list, so please keep the cc: intact. LPRng is a replacement for the BSD spooling system. To quote from http://www.lprng.com/ LPRng [...] is an enhanced, extended, and portable implementation of the Berkeley LPR print spooler [...] providing the same interface and meeting RFC1179 requirements the implementation [...] provides support for the following features: lightweight lpr, lpc, and lprm; dynamic redirection of print queues; automatic job holding; verbose diagnostics; multiple printers serving a single queue; client programs do not need to be SUID root; enhanced security checks; improved permissions and authorization mechanism. LPRng is distributed under the GNU and Artistic licenses. Patrick wants feedback on whether or not FreeBSD would be interested in adopting LPRng as our official LPR implementation, (src/contrib/lprng, presumably). I said I'd raise the issue on -arch, and then, not being much of a printer maven, step back while everyone talks the issue back and forth. Over to you. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 15:40: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 3FEBC37C093; Wed, 21 Jun 2000 15:40:00 -0700 (PDT) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id SAA49635; Wed, 21 Jun 2000 18:39:55 -0400 (EDT) Date: Wed, 21 Jun 2000 18:39:55 -0400 (EDT) From: To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD In-Reply-To: <20000621221636.A4137@kilt.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If it can be brought in under a BSDL. I think chances would be greater. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 15:51:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 57B4037B94C; Wed, 21 Jun 2000 15:51:22 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA25726; Wed, 21 Jun 2000 23:46:36 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA03101; Wed, 21 Jun 2000 23:46:34 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006212246.XAA03101@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: scanner@jurai.net Cc: Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com, brian@hak.lan.awfulhak.org Subject: Re: Bringing LPRng into FreeBSD In-Reply-To: Message from of "Wed, 21 Jun 2000 18:39:55 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 2000 23:46:34 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If it can be brought in under a BSDL. I think chances would be greater. Ditto. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 18:12:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id E42DC37C0A9; Wed, 21 Jun 2000 18:12:48 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from slave (doug@slave [10.0.0.1]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id SAA99685; Wed, 21 Jun 2000 18:12:47 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 21 Jun 2000 18:12:47 -0700 (PDT) From: Doug Barton X-Sender: doug@dt051n0b.san.rr.com To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? In-Reply-To: <20000621221636.A4137@kilt.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Jun 2000, Nik Clayton wrote: > LPRng is distributed under the GNU and Artistic licenses. My knee-jerk reaction is not to import any new software into the tree that is under the GPL. This is not to say that I don't appreciate the offer, but I think this would be a move in the wrong direction. Speaking just for me, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 18:42:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 6029137B6E9; Wed, 21 Jun 2000 18:42:07 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id DAA04710; Thu, 22 Jun 2000 03:42:24 +0200 (CEST) (envelope-from assar) To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? References: <20000621221636.A4137@kilt.nothing-going-on.org> From: Assar Westerlund Date: 22 Jun 2000 03:42:23 +0200 In-Reply-To: Nik Clayton's message of "Wed, 21 Jun 2000 22:16:38 +0000" Message-ID: <5laegesd8g.fsf@assaris.sics.se> Lines: 12 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton writes: > Patrick wants feedback on whether or not FreeBSD would be interested in > adopting LPRng as our official LPR implementation, (src/contrib/lprng, > presumably). I said I'd raise the issue on -arch, and then, not being much > of a printer maven, step back while everyone talks the issue back and forth. I think this would be a good thing. And I can't see why anyone should object to adding code distributed under the Artistic license to FreeBSD either. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 21 22:15: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from server1.mich.com (server1.mich.com [198.108.16.2]) by hub.freebsd.org (Postfix) with ESMTP id B409937B635; Wed, 21 Jun 2000 22:15:00 -0700 (PDT) (envelope-from will@almanac.yi.org) Received: from argon.gryphonsoft.com (pm003-024.dialup.bignet.net [64.79.80.120]) by server1.mich.com (8.9.3/8.9.3) with ESMTP id BAA18730; Thu, 22 Jun 2000 01:14:47 -0400 Received: by argon.gryphonsoft.com (Postfix, from userid 1000) id A4621188D; Thu, 22 Jun 2000 01:13:09 -0400 (EDT) Date: Thu, 22 Jun 2000 01:13:09 -0400 From: Will Andrews To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? Message-ID: <20000622011309.K47446@argon.gryphonsoft.com> References: <20000621221636.A4137@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000621221636.A4137@kilt.nothing-going-on.org>; from nik@FreeBSD.ORG on Wed, Jun 21, 2000 at 10:16:38PM +0000 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 21, 2000 at 10:16:38PM +0000, Nik Clayton wrote: > LPRng is distributed under the GNU and Artistic licenses. If the Artistic license is close enough to the BSD license, I'd be happy having Patrick maintain the source code directly in our repository. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 8: 1: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3302337B9A0; Thu, 22 Jun 2000 08:01:01 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA20026; Thu, 22 Jun 2000 08:01:00 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda20024; Thu Jun 22 08:00:49 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id IAA33235; Thu, 22 Jun 2000 08:00:48 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdi33226; Thu Jun 22 08:00:15 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5MF0Ec06028; Thu, 22 Jun 2000 08:00:14 -0700 (PDT) Message-Id: <200006221500.e5MF0Ec06028@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdma6015; Thu Jun 22 07:59:36 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: packages (was: Bringing LPRng into FreeBSD?) In-reply-to: Your message of "Wed, 21 Jun 2000 22:16:38 -0000." <20000621221636.A4137@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 07:59:36 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000621221636.A4137@kilt.nothing-going-on.org>, Nik Clayton writes : > Hi guys, > > I've just met up with Patrick Powell, author of LPRng, at Usenix. This > message is cc'd to him, as he's not on the list, so please keep the cc: > intact. > > LPRng is a replacement for the BSD spooling system. To quote from > http://www.lprng.com/ > > LPRng [...] is an enhanced, extended, and portable implementation of > the Berkeley LPR print spooler [...] providing the same interface and > meeting RFC1179 requirements the implementation [...] provides support > for the following features: lightweight lpr, lpc, and lprm; dynamic > redirection of print queues; automatic job holding; verbose diagnostics; > multiple printers serving a single queue; client programs do not need > to be SUID root; enhanced security checks; improved permissions and > authorization mechanism. > > LPRng is distributed under the GNU and Artistic licenses. If Patrick drops the GNU license in favour of a BSD license it should be O.K. Are the LPRng printcap and the LPD printcap exactly the same? An application to convert printcap files will need to be built and supported -- I suspect they're not exactly the same. Replacing lpr/lpd with an application similar to FreeBSD's sendmail, which calls the real MTA, would be nice. This way one can plug any print spooler into FreeBSD and it should work. Of course this raises the whole issue of packages. If the various components of the O/S were packages, we wouldn't need this discussion. In my former life as an MVS Systems Programmer, sites I had worked for had a choice of spoolers: JES2 or JES3; a choice of security packages: RACF, ACF/2, or Top Secret; a choice of serialisation software: GRS or MIM; and the list goes on. If FreeBSD used packages to install applications like RedHat, Solaris, and IBM's MVS for example, the choice would be the sysadmin's. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 12:15:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 9680637B6AE; Thu, 22 Jun 2000 12:15:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (ip83.salt-lake-city9.ut.pub-ip.psi.net [38.31.167.83]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id NAA11587; Thu, 22 Jun 2000 13:14:00 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <395265AA.AEC5EB8@softweyr.com> Date: Thu, 22 Jun 2000 13:14:50 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? References: <20000618160223.A2482@sydney.worldwide.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > What do people think about adding a -e option to umount(8) to eject a > removable medium where possible? Yes! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 13:18:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 231C037B52D; Thu, 22 Jun 2000 13:18:32 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id NAA17256; Thu, 22 Jun 2000 13:18:43 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Cy Schubert - ITSD Open Systems Group Cc: Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: packages (was: Bringing LPRng into FreeBSD?) In-reply-to: Your message of "Thu, 22 Jun 2000 07:59:36 PDT." <200006221500.e5MF0Ec06028@cwsys.cwsent.com> Date: Thu, 22 Jun 2000 13:18:43 -0700 Message-ID: <17253.961705123@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > LPRng is distributed under the GNU and Artistic licenses. > > If Patrick drops the GNU license in favour of a BSD license it should > be O.K. I'll repeat what Nik said above: "LPRng is distributed under the GNU and Artistic licenses." Those are the two you get to choose from and that's just the breaks. Note that one of them is not the GPL. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 13:42:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from builder.FreeBSD.ORG (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id D6BC337BE0A; Thu, 22 Jun 2000 13:42:40 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Thu, 22 Jun 2000 13:44:47 -0700 (PDT) From: Brian Fundakowski Feldman To: Wes Peters Cc: Greg Lehey , FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? In-Reply-To: <395265AA.AEC5EB8@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Jun 2000, Wes Peters wrote: > Greg Lehey wrote: > > > > What do people think about adding a -e option to umount(8) to eject a > > removable medium where possible? > > Yes! For what it's worth, there's a port, ports/sysutils/eject, which is made to do this. I'm not one to deny a simple feature in the base system, though, even if this feature is not /really/ that simple. -- 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-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 13:47:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3544237B7D1; Thu, 22 Jun 2000 13:47:24 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id NAA21110; Thu, 22 Jun 2000 13:46:49 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda21108; Thu Jun 22 13:46:34 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id NAA35432; Thu, 22 Jun 2000 13:46:34 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdg35430; Thu Jun 22 13:46:21 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5MKkKn07168; Thu, 22 Jun 2000 13:46:20 -0700 (PDT) Message-Id: <200006222046.e5MKkKn07168@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdVH7153; Thu Jun 22 13:45:52 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: "Jordan K. Hubbard" Cc: Cy Schubert - ITSD Open Systems Group , Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Thu, 22 Jun 2000 13:18:43 PDT." <17253.961705123@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 13:45:52 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <17253.961705123@localhost>, "Jordan K. Hubbard" writes: > > > LPRng is distributed under the GNU and Artistic licenses. > > > > If Patrick drops the GNU license in favour of a BSD license it should > > be O.K. > > I'll repeat what Nik said above: "LPRng is distributed under the GNU > and Artistic licenses." Those are the two you get to choose from and > that's just the breaks. Note that one of them is not the GPL. He said GNU and Artistic licences. ^^^ I took that to mean no choice. Having read the copyright, it is not GPL. LPRng uses GNU gettext, which is GPL, for NLS support. In other words it is distributed under GNU and Artistic licenses, meaning no choice. Would that be problematic (either omitting NLS support or requiring the gettext for any builds that require NLS support) for anyone? Otherwise to keep life simple, it should stay in ports. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 15: 8:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id B241A37C03D for ; Thu, 22 Jun 2000 15:08:08 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id PAA94336; Thu, 22 Jun 2000 15:04:25 -0700 (PDT) From: Archie Cobbs Message-Id: <200006222204.PAA94336@bubba.whistle.com> Subject: Re: Software detection of link integrity In-Reply-To: <62967.961624079@critter.freebsd.dk> from Poul-Henning Kamp at "Jun 21, 2000 11:47:59 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 22 Jun 2000 15:04:25 -0700 (PDT) Cc: brian@Awfulhak.org (Brian Somers), tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > >> But a dial on demand line is a layered concept. You have a transient > >> physical line with a layer on top of it which pretends to be a > >> permanent line. > > > >Which unfortunately doesn't work with a dynamically assigned IP > >number. > > That is a different story alltogether... On the InterJet, if it's dynamic IP and there is no other IP address to use, we actually make one up! Once connected, we renumber the interface of course. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 15:21:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id D7CDF37BF55 for ; Thu, 22 Jun 2000 15:21:18 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA37787; Thu, 22 Jun 2000 23:20:02 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA02751; Thu, 22 Jun 2000 23:20:00 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006222220.XAA02751@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Archie Cobbs Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), brian@Awfulhak.org (Brian Somers), tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.org, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity In-Reply-To: Message from Archie Cobbs of "Thu, 22 Jun 2000 15:04:25 PDT." <200006222204.PAA94336@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 23:20:00 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Poul-Henning Kamp writes: > > >> But a dial on demand line is a layered concept. You have a transient > > >> physical line with a layer on top of it which pretends to be a > > >> permanent line. > > > > > >Which unfortunately doesn't work with a dynamically assigned IP > > >number. > > > > That is a different story alltogether... > > On the InterJet, if it's dynamic IP and there is no other IP address > to use, we actually make one up! Once connected, we renumber the > interface of course. How do you deal with the first connection problem - where that first packet that causes the dial ends up with an incorrect src address ? ppp(8) does it when NAT is enabled by keeping the old interface address as an alias and just NATing the first connection. > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 15:27:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 22FFF37C2EB for ; Thu, 22 Jun 2000 15:27:26 -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.3) with ESMTP id AAA01596; Fri, 23 Jun 2000 00:26:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Archie Cobbs , tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.org, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity In-reply-to: Your message of "Thu, 22 Jun 2000 23:20:00 BST." <200006222220.XAA02751@hak.lan.Awfulhak.org> Date: Fri, 23 Jun 2000 00:26:47 +0200 Message-ID: <1594.961712807@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006222220.XAA02751@hak.lan.Awfulhak.org>, Brian Somers writes: >> On the InterJet, if it's dynamic IP and there is no other IP address >> to use, we actually make one up! Once connected, we renumber the >> interface of course. > >How do you deal with the first connection problem - where that first >packet that causes the dial ends up with an incorrect src address ? > >ppp(8) does it when NAT is enabled by keeping the old interface >address as an alias and just NATing the first connection. If you want to get dirty, you can actually reach backwards and poke the actual IP# into the pcb (unless it's a ping packet). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 15:43:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D178B37B752 for ; Thu, 22 Jun 2000 15:43:13 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id PAA94706; Thu, 22 Jun 2000 15:39:36 -0700 (PDT) From: Archie Cobbs Message-Id: <200006222239.PAA94706@bubba.whistle.com> Subject: Re: Software detection of link integrity In-Reply-To: <200006222220.XAA02751@hak.lan.Awfulhak.org> from Brian Somers at "Jun 22, 2000 11:20:00 pm" To: brian@Awfulhak.org (Brian Somers) Date: Thu, 22 Jun 2000 15:39:36 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), phk@critter.freebsd.dk (Poul-Henning Kamp), tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.org, brian@hak.lan.awfulhak.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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: > > > >> But a dial on demand line is a layered concept. You have a transient > > > >> physical line with a layer on top of it which pretends to be a > > > >> permanent line. > > > > > > > >Which unfortunately doesn't work with a dynamically assigned IP > > > >number. > > > > > > That is a different story alltogether... > > > > On the InterJet, if it's dynamic IP and there is no other IP address > > to use, we actually make one up! Once connected, we renumber the > > interface of course. > > How do you deal with the first connection problem - where that first > packet that causes the dial ends up with an incorrect src address ? > > ppp(8) does it when NAT is enabled by keeping the old interface > address as an alias and just NATing the first connection. That packet eventually gets dropped/ignored, and subsequent packets will be correct, because when/if the interface gets renumbered we restart whatever proceses need to be restarted. We can do this because we "know" what's running and what needs a restart in this case. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 17: 1:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (static98.conference.usenix.org [209.179.127.98]) by hub.freebsd.org (Postfix) with ESMTP id 0D0D837B784; Thu, 22 Jun 2000 17:01:11 -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 XAA01222; Thu, 22 Jun 2000 23:56:12 GMT (envelope-from nik) Date: Thu, 22 Jun 2000 23:56:05 +0000 From: Nik Clayton To: Cy Schubert - ITSD Open Systems Group Cc: "Jordan K. Hubbard" , Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? Message-ID: <20000622235602.A1088@kilt.nothing-going-on.org> References: <17253.961705123@localhost> <200006222046.e5MKkKn07168@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006222046.e5MKkKn07168@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Thu, Jun 22, 2000 at 01:45:52PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 22, 2000 at 01:45:52PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > In message <17253.961705123@localhost>, "Jordan K. Hubbard" writes: > > > > LPRng is distributed under the GNU and Artistic licenses. > > > > > > If Patrick drops the GNU license in favour of a BSD license it should > > > be O.K. > > > > I'll repeat what Nik said above: "LPRng is distributed under the GNU > > and Artistic licenses." Those are the two you get to choose from and > > that's just the breaks. Note that one of them is not the GPL. > > He said GNU and Artistic licences. > ^^^ > I took that to mean no choice. > > Having read the copyright, it is not GPL. LPRng uses GNU gettext, > which is GPL, for NLS support. In other words it is distributed under > GNU and Artistic licenses, meaning no choice. Would that be > problematic (either omitting NLS support or requiring the gettext for > any builds that require NLS support) for anyone? Otherwise to keep > life simple, it should stay in ports. Just for reference, does this mean that http://www.astart.com/lprng/license.txt is wrong? It says You may use "LPRng" or "IFHP" under either the terms of the GNU GPL License or the Artistic License. These licenses are included below. which contradicts you. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 22 17:31:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 6871E37C106; Thu, 22 Jun 2000 17:31:28 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id UAA15680; Thu, 22 Jun 2000 20:31:25 -0400 (EDT) Message-ID: <20000622203125.A14631@netmonger.net> Date: Thu, 22 Jun 2000 20:31:25 -0400 From: Christopher Masto To: Nik Clayton , arch@FreeBSD.ORG Cc: papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? References: <20000621221636.A4137@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <20000621221636.A4137@kilt.nothing-going-on.org>; from Nik Clayton on Wed, Jun 21, 2000 at 10:16:38PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 21, 2000 at 10:16:38PM +0000, Nik Clayton wrote: > Patrick wants feedback on whether or not FreeBSD would be interested in > adopting LPRng as our official LPR implementation, (src/contrib/lprng, > presumably). I said I'd raise the issue on -arch, and then, not being much > of a printer maven, step back while everyone talks the issue back and forth. > > Over to you. FWIW, LPRng is one of the first ports I add after installing FreeBSD. I discovered long ago that LPRng does the job considerably better and easier (on client machines, no printcap is needed at all - just set $PRINTER to queue@server). Especially when dealing with filters. From a purely selfish perspective, it would be easier for me to have it in the base install, but it's also pretty darn easy to install from ports. Aside from the license issue, it probably depends on how much value the current lpd has. I personally find it a bit mysterious. -- 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-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 0:23:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9190237B895; Fri, 23 Jun 2000 00:23:16 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p19-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.148]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id QAA03421; Fri, 23 Jun 2000 16:23:13 +0900 (JST) Message-ID: <3953082E.6803A007@newsguy.com> Date: Fri, 23 Jun 2000 15:48:14 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Nik Clayton Cc: arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? References: <20000621221636.A4137@kilt.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We have had a number of features brought into or LPR with the years. If we bring in LPRng, which seems like a good idea to me, we would have to make sure that compatibility can be ensured. It would be better, IMHO, to first seek the addition of these features to LPRng. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org Windows works, for sufficently small values of "works". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 2:52:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 247FF37B8D6; Fri, 23 Jun 2000 02:52:18 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id CAA19533; Fri, 23 Jun 2000 02:52:25 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Cy Schubert - ITSD Open Systems Group Cc: "Jordan K. Hubbard" , Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Thu, 22 Jun 2000 13:45:52 PDT." <200006222046.e5MKkKn07168@cwsys.cwsent.com> Date: Fri, 23 Jun 2000 02:52:25 -0700 Message-ID: <19530.961753945@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > He said GNU and Artistic licences. > ^^^ > I took that to mean no choice. No, you have a choice of either one. You can take LPRng under the GPL or you can take it under the Artistic license. It is dual-licensed. We would, of course, choose the artistic license. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 3:13:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 913A337B8DE; Fri, 23 Jun 2000 03:13:42 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id DAA19702; Fri, 23 Jun 2000 03:13:51 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: "Daniel C. Sobral" Cc: Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Fri, 23 Jun 2000 15:48:14 +0900." <3953082E.6803A007@newsguy.com> Date: Fri, 23 Jun 2000 03:13:51 -0700 Message-ID: <19699.961755231@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We have had a number of features brought into or LPR with the years. If > we bring in LPRng, which seems like a good idea to me, we would have to > make sure that compatibility can be ensured. The author of LPRng, whom I talked to for awhile today, assures me that this has already happened. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 8:21:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id BB10437B721; Fri, 23 Jun 2000 08:21:11 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.1.105]) by gw.nectar.com (Postfix) with ESMTP id 173259B36; Fri, 23 Jun 2000 10:21:11 -0500 (CDT) Received: by bone.nectar.com (Postfix, from userid 1001) id B2C041DC6; Fri, 23 Jun 2000 10:21:08 -0500 (CDT) Date: Fri, 23 Jun 2000 10:21:08 -0500 From: "Jacques A . Vidrine" To: Brian Fundakowski Feldman Cc: Wes Peters , Greg Lehey , FreeBSD current users , FreeBSD-arch@FreeBSD.ORG Subject: Re: -e option to umount? Message-ID: <20000623102108.H76049@bone.nectar.com> Reply-To: freebsd-current@freebsd.org Mail-Followup-To: "Jacques A . Vidrine" , Brian Fundakowski Feldman , Wes Peters , Greg Lehey , FreeBSD current users , FreeBSD-arch@FreeBSD.ORG References: <395265AA.AEC5EB8@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from green@FreeBSD.org on Thu, Jun 22, 2000 at 01:44:47PM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I think this thread belongs only on -current for the moment. Please followup there.] On Thu, Jun 22, 2000 at 01:44:47PM -0700, Brian Fundakowski Feldman wrote: > For what it's worth, there's a port, ports/sysutils/eject, which is made > to do this. I'm not one to deny a simple feature in the base system, > though, even if this feature is not /really/ that simple. There are two problems with ports/sysutils/eject: = It uses only CDIOCEJECT, which will not work for all removable media (e.g. SCSI disks, tapes). = It tries to unmount the device after ejecting it. This doesn't make since for all devices. Even for those that it _does_ make sense, it can be hard to correctly determine how (by what name) the device is mounted. So I wrote a simple utility that ejects media as follows: = Check to see if the given device is known to cam, and if so use camlib to eject it. = If that doesn't work, try the CDIOCEJECT ioctl. = If that didn't work, give up. It is available as a port at: http://www.nectar.com/freebsd/neject.tar Included in the port distfile is a patch (umount.patch) that adds a `-e' option to umount. If you use it, then umount will run eject for each local filesystem that is unmounted. I figure umount should call eject, rather than the other way around, since umount already knows the device name and mount point. I actually think that there should be load/eject media ioctls defined that are not specific to CDs. I'll post a separate message to that effect on -current. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 10:21:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id A3DE037B5C0; Fri, 23 Jun 2000 10:21:31 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id KAA15596; Fri, 23 Jun 2000 10:20:58 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAA9oaWyE; Fri Jun 23 10:20:51 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA25921; Fri, 23 Jun 2000 10:21:08 -0700 (MST) From: Terry Lambert Message-Id: <200006231721.KAA25921@usr01.primenet.com> Subject: Re: was: Bringing LPRng into FreeBSD? To: jkh@zippy.osd.bsdi.com (Jordan K. Hubbard) Date: Fri, 23 Jun 2000 17:21:08 +0000 (GMT) Cc: Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group), jkh@zippy.osd.bsdi.com (Jordan K. Hubbard), nik@FreeBSD.ORG (Nik Clayton), arch@FreeBSD.ORG, papowell@astart.com In-Reply-To: <19530.961753945@localhost> from "Jordan K. Hubbard" at Jun 23, 2000 02:52:25 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > He said GNU and Artistic licences. > > ^^^ > > I took that to mean no choice. > > No, you have a choice of either one. You can take LPRng under > the GPL or you can take it under the Artistic license. It is > dual-licensed. We would, of course, choose the artistic license. So you would be OK with this, if the purely GPL NLS code (gettext) was removed from LPRng, right? I think the GPL-only portions of the code are what he's objecting to, not the Artistic Licensed code. 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-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 10:24:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id E958837C3A0 for ; Fri, 23 Jun 2000 10:24:45 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA05729; Fri, 23 Jun 2000 10:16:28 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAAMOaail; Fri Jun 23 10:16:23 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA25727; Fri, 23 Jun 2000 10:17:03 -0700 (MST) From: Terry Lambert Message-Id: <200006231717.KAA25727@usr01.primenet.com> Subject: Re: Software detection of link integrity To: archie@whistle.com (Archie Cobbs) Date: Fri, 23 Jun 2000 17:17:03 +0000 (GMT) Cc: brian@Awfulhak.org (Brian Somers), archie@whistle.com (Archie Cobbs), phk@critter.freebsd.dk (Poul-Henning Kamp), tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.org, brian@hak.lan.awfulhak.org In-Reply-To: <200006222239.PAA94706@bubba.whistle.com> from "Archie Cobbs" at Jun 22, 2000 03:39:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > >> But a dial on demand line is a layered concept. You have a transient > > > > >> physical line with a layer on top of it which pretends to be a > > > > >> permanent line. > > > > > > > > > >Which unfortunately doesn't work with a dynamically assigned IP > > > > >number. > > > > > > > > That is a different story alltogether... > > > > > > On the InterJet, if it's dynamic IP and there is no other IP address > > > to use, we actually make one up! Once connected, we renumber the > > > interface of course. > > > > How do you deal with the first connection problem - where that first > > packet that causes the dial ends up with an incorrect src address ? > > > > ppp(8) does it when NAT is enabled by keeping the old interface > > address as an alias and just NATing the first connection. > > That packet eventually gets dropped/ignored, and subsequent packets > will be correct, because when/if the interface gets renumbered we > restart whatever proceses need to be restarted. We can do this > because we "know" what's running and what needs a restart in this > case. Whacking helpless processes over the head with a billy club is precisely the reason I sugested a "bind-to-interface-not-IP" socket type in the first place: it removes the cached data, and the need to beat innocent processes to death is based not on the cached data of the process, but on the cached data of the kernel in the IP address socket bind. It is the job of the system, not of the daemons, to reconcile the problem. Otherwise you repeat a huge amount of code in each and every daemon to handle the same situation, or, as you note, you have to stop and restart the daemons. I know that this can be worked around by using a TUN device, and establishing a point to point link using a link.local (IPv4 stateless autoconfiguration) or other non-routable address, and then NATing the PPP link on the other end to the real interface address, when available. This would work evn for ping packets. I was looking for something a bit more elegant, however, since if you do it using a TUN interace, and the TUN interface is up all the time from the point of view of the processes bound to the other end of it, then you don't get the normal resource track cleanup that you would get when a link went down. I guess you could propogate the link down event to the TUN interface to make this work, but that's a real kludge, and I don't think that anyone has implemented that yet. Without a propagation of the link down, you'd gett errors, like, say, an "ETRN.pl" run that is currently in progress hanging forever in a read from the TUN socket, should the real link go away in the middle of an operation, since there would be no TCP disconnect notification. This isn't a problem for UDP and ICMP, since they would presumably be retransmitted (unless there was a restriction on who could send them based on layering an exterior retransmission protocol on top of them), but for TCP, it's a killer. 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-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 10:31:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 643D037C3BE; Fri, 23 Jun 2000 10:31:28 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA346766; Fri, 23 Jun 2000 13:31:24 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20000621221636.A4137@kilt.nothing-going-on.org> References: <20000621221636.A4137@kilt.nothing-going-on.org> Date: Fri, 23 Jun 2000 13:31:57 -0400 To: Nik Clayton , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Bringing LPRng into FreeBSD? Cc: papowell@astart.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:16 PM +0000 6/21/00, Nik Clayton wrote: >Patrick wants feedback on whether or not FreeBSD would be >interested in adopting LPRng as our official LPR implementation, >(src/contrib/lprng, presumably). I said I'd raise the issue >on -arch, and then, not being much of a printer maven, step >back while everyone talks the issue back and forth. Given that it is like pulling teeth to get anyone to add an update to our current version of lpr, I suppose this is a good thing. I have written multiple updates to freebsd's lpr over the past year and a half, and I think I am averaging about six months between the time I send in a patch and the time it is applied. In general, it takes me five times more work to get someone to apply a patch than it takes me to write the damn patch in the first place. Mind you, I did have one patch that was applied within about 24 hours of writing it, so the average is even more amazing. Presumably Patrick will be given direct access to supporting lprNG in the base system, because god knows he won't have the patience to deal with the current lack of interest. Having followed the lprNG mailing list for a year or so, it's clear that lprNG is a much busier project than FreeBSD's lpr has been. (even though Freebsd's lpr has improved a lot in the last few years). I guess another question comes to mind. If freebsd users do have updates they need in lprNG, how easy will it be to feed those back into the base system? --- 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-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 10:51: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 7986737B913; Fri, 23 Jun 2000 10:51:00 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA24520; Fri, 23 Jun 2000 10:50:23 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda24518; Fri Jun 23 10:50:09 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id KAA62462; Fri, 23 Jun 2000 10:50:08 -0700 (PDT) Message-Id: <200006231750.KAA62462@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdq59938; Fri Jun 23 10:49:37 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cschuber To: Terry Lambert Cc: jkh@zippy.osd.bsdi.com (Jordan K. Hubbard), Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group), nik@FreeBSD.ORG (Nik Clayton), arch@FreeBSD.ORG, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Fri, 23 Jun 2000 17:21:08 -0000." <200006231721.KAA25921@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 10:49:37 -0700 From: Cy Schubert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006231721.KAA25921@usr01.primenet.com>, Terry Lambert writes: > > > He said GNU and Artistic licences. > > > ^^^ > > > I took that to mean no choice. > > > > No, you have a choice of either one. You can take LPRng under > > the GPL or you can take it under the Artistic license. It is > > dual-licensed. We would, of course, choose the artistic license. > > So you would be OK with this, if the purely GPL NLS code (gettext) > was removed from LPRng, right? > > I think the GPL-only portions of the code are what he's objecting to, > not the Artistic Licensed code. Exactly. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 13:24:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 3456E37B89C; Fri, 23 Jun 2000 13:24:27 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA562618; Fri, 23 Jun 2000 16:24:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20000621221636.A4137@kilt.nothing-going-on.org> Date: Fri, 23 Jun 2000 16:24:57 -0400 To: Nik Clayton , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Bringing LPRng into FreeBSD? Cc: papowell@astart.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:31 PM -0400 6/23/00, Garance A Drosihn wrote: >At 10:16 PM +0000 6/21/00, Nik Clayton wrote: >>Patrick wants feedback on whether or not FreeBSD would be >>interested in adopting LPRng as our official LPR implementation, >>(src/contrib/lprng, presumably). I said I'd raise the issue >>on -arch, and then, not being much of a printer maven, step >>back while everyone talks the issue back and forth. > >Given that it is like pulling teeth to get anyone to add an >update to our current version of lpr, I suppose this is a >good thing. My obvious frustration probably clouds my last message too much. Here's a somewhat more helpful suggestion. First, I assume that whatever GNU-licensed code in lprNG can be replaced by BSD/artistic-licensed code, so I won't talk about licensing issues. Second, my guess is that lprNG will not be a perfectly compatible drop-in replacement for freebsd's current lpr. I do expect it would work fine for most people, but that some people will find that they will have to futz around with their printcap/printing setup to get the behavior they are used to (whatever that may be...). That might be an annoying extra step in upgrading to whatever release of freebsd that this happens on. This suggests to me that MAYBE we don't want to bring lprNG into the base system, so much as MOVE the current lpr from the base system into a port. Wherever it is that someone selects that they want 'printing' on their freebsd config, they could select either this new port or the lprNG-based port. Does this seem reasonable/practical/useful? --- 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-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 17:11: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 0533137BAD3; Fri, 23 Jun 2000 17:10:49 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 135dWG-00026m-00; Sat, 24 Jun 2000 07:09:56 +0700 Date: Sat, 24 Jun 2000 07:09:56 +0700 (ALMST) From: Boris Popov To: Alexander Langer Cc: "Dmitry S. Sivachenko" , freebsd-i18n@FreeBSD.ORG, freebsd-arch@freebsd.org Subject: Re: gettext In-Reply-To: <20000623195641.C16231@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [CC'ed to arch due to src- suggestion below] On Fri, 23 Jun 2000, Alexander Langer wrote: > > What do people think about including gettext into base distribution? > > Many programs have their messages translated (tar, flex, grep, sed, texinfo). > > It would be very nice to use this in the base system. > > I hate translated messages. > Use AIX if you want translated crap :) This is not correct. Not everybody knows English well, these are mostly newbies and having translated docs and program messages is a real help for them. However I'm not sure where language specific resources should be placed. The library definitely goes into base system, but the rest (IMO) shouldn't because it will cause unnecessary growth of the source tree and, in very rare cases one need more than two language packs. So, may be having src- repository will help ? For example, I can put 'src-ru' line in my cvsup file and get all info/man/program translations in Russian or download and install a port which will be just a tarball of src-ru directory. In addition, the above scheme will reserve place where all country/language specific resources (such as character sets for the iconv interface) can be placed. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 19:18:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id A208837B73A; Fri, 23 Jun 2000 19:18:26 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id TAA25791; Fri, 23 Jun 2000 19:16:58 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda25789; Fri Jun 23 19:16:46 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id TAA05310; Fri, 23 Jun 2000 19:16:45 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdAN5300; Fri Jun 23 19:16:33 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5O2GWZ13757; Fri, 23 Jun 2000 19:16:32 -0700 (PDT) Message-Id: <200006240216.e5O2GWZ13757@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdG13753; Fri Jun 23 19:16:29 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Boris Popov Cc: Alexander Langer , "Dmitry S. Sivachenko" , freebsd-i18n@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: gettext In-reply-to: Your message of "Sat, 24 Jun 2000 07:09:56 +0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 19:16:29 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Boris Popo v writes: > [CC'ed to arch due to src- suggestion below] > > On Fri, 23 Jun 2000, Alexander Langer wrote: > > > > What do people think about including gettext into base distribution? > > > Many programs have their messages translated (tar, flex, grep, sed, texin > fo). > > > It would be very nice to use this in the base system. > > > > I hate translated messages. > > Use AIX if you want translated crap :) > > This is not correct. Not everybody knows English well, these are > mostly newbies and having translated docs and program messages is a real > help for them. > > However I'm not sure where language specific resources should be > placed. The library definitely goes into base system, but the rest (IMO) > shouldn't because it will cause unnecessary growth of the source tree and, > in very rare cases one need more than two language packs. So, may be > having src- repository will help ? For example, I can put 'src-ru' > line in my cvsup file and get all info/man/program translations in Russian > or download and install a port which will be just a tarball of src-ru > directory. > > In addition, the above scheme will reserve place where all > country/language specific resources (such as character sets for the iconv > interface) can be placed. Let's keep the amount of GNU software in the base system to a minimum. If you need it, why not install the gettext port? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 23:12:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id E9BDD37BC9D; Fri, 23 Jun 2000 23:12:13 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA15119; Sat, 24 Jun 2000 00:11:25 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <39545167.AE635015@softweyr.com> Date: Sat, 24 Jun 2000 00:12:55 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Cy Schubert - ITSD Open Systems Group , "Jordan K. Hubbard" , arch@FreeBSD.ORG, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? References: <17253.961705123@localhost> <200006222046.e5MKkKn07168@cwsys.cwsent.com> <20000622235602.A1088@kilt.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > > On Thu, Jun 22, 2000 at 01:45:52PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > > In message <17253.961705123@localhost>, "Jordan K. Hubbard" writes: > > > > > LPRng is distributed under the GNU and Artistic licenses. > > > > > > > > If Patrick drops the GNU license in favour of a BSD license it should > > > > be O.K. > > > > > > I'll repeat what Nik said above: "LPRng is distributed under the GNU > > > and Artistic licenses." Those are the two you get to choose from and > > > that's just the breaks. Note that one of them is not the GPL. > > > > He said GNU and Artistic licences. > > ^^^ > > I took that to mean no choice. > > > > Having read the copyright, it is not GPL. LPRng uses GNU gettext, > > which is GPL, for NLS support. In other words it is distributed under > > GNU and Artistic licenses, meaning no choice. Would that be > > problematic (either omitting NLS support or requiring the gettext for > > any builds that require NLS support) for anyone? Otherwise to keep > > life simple, it should stay in ports. > > Just for reference, does this mean that > > http://www.astart.com/lprng/license.txt > > is wrong? It says > > You may use "LPRng" or "IFHP" under either the terms of the GNU > GPL License or the Artistic License. These licenses are included > below. > > which contradicts you. Yes, it is wrong. If it must be linked with GNU gettext, no matter what their license is, the resulting executable has been infected with the GPL virus. So much for choice. Has anyone looked at hacking out or replacing GNU gettext? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 23 23:55: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C7C6937BB69; Fri, 23 Jun 2000 23:55: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 AAA58174; Sat, 24 Jun 2000 00:54:54 -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 AAA02110; Sat, 24 Jun 2000 00:53:13 -0600 (MDT) Message-Id: <200006240653.AAA02110@harmony.village.org> To: Garance A Drosihn Subject: Re: Bringing LPRng into FreeBSD? Cc: Nik Clayton , arch@FreeBSD.ORG, papowell@astart.com In-reply-to: Your message of "Fri, 23 Jun 2000 13:31:57 EDT." References: <20000621221636.A4137@kilt.nothing-going-on.org> Date: Sat, 24 Jun 2000 00:53:13 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Garance A Drosihn writes: : Given that it is like pulling teeth to get anyone to add an : update to our current version of lpr, I suppose this is a : good thing. I have written multiple updates to freebsd's : lpr over the past year and a half, and I think I am averaging : about six months between the time I send in a patch and the : time it is applied. In general, it takes me five times more : work to get someone to apply a patch than it takes me to write : the damn patch in the first place. Mind you, I did have one : patch that was applied within about 24 hours of writing it, so : the average is even more amazing. I'm partially to blame for that. I find lpr/lpd hard to audit and changes to it hard to ensure verify. This is more a reflection of lpr/lpd and not on Garance. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 24 1:40:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from chg.ru (netserv1.chg.ru [193.233.46.3]) by hub.freebsd.org (Postfix) with ESMTP id 9944037BB53; Sat, 24 Jun 2000 01:40:00 -0700 (PDT) (envelope-from dima@chg.ru) Received: (from dima@localhost) by chg.ru (8.9.3/8.9.3) id MAA79473; Sat, 24 Jun 2000 12:38:24 +0400 (MSD) (envelope-from dima) Date: Sat, 24 Jun 2000 12:38:24 +0400 (MSD) From: "Dmitry S. Sivachenko" Message-Id: <200006240838.MAA79473@chg.ru> To: alex@big.endian.de, bp@butya.kz Subject: Re: gettext Cc: dima@Chg.RU, freebsd-arch@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is not correct. Not everybody knows English well, these are > mostly newbies and having translated docs and program messages is a real > help for them. > > However I'm not sure where language specific resources should be > placed. The library definitely goes into base system, but the rest (IMO) > shouldn't because it will cause unnecessary growth of the source tree and, > in very rare cases one need more than two language packs. So, may be > having src- repository will help ? For example, I can put 'src-ru' > line in my cvsup file and get all info/man/program translations in Russian > or download and install a port which will be just a tarball of src-ru > directory. > Several programs (e.g., vi(1)) already have localized messages in the base system. I see no reason to create a separate repository for them. BTW, they should go into /usr/share/locale, not info/man and will consume not so much space you expect. --dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 24 9:39:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.surf1.de (mail.surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 1683137BC1C; Sat, 24 Jun 2000 09:39:17 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from neutron.cichlids.com (p3E9C1121.dip0.t-ipconnect.de [62.156.17.33]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id SAA15716; Sat, 24 Jun 2000 18:38:30 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 67CAEAC27; Sat, 24 Jun 2000 18:39:21 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id B6C5914AB2; Sat, 24 Jun 2000 18:39:06 +0200 (CEST) Date: Sat, 24 Jun 2000 18:39:06 +0200 From: Alexander Langer To: Boris Popov Cc: "Dmitry S. Sivachenko" , freebsd-i18n@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: gettext Message-ID: <20000624183906.B2843@cichlids.cichlids.com> References: <20000623195641.C16231@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bp@butya.kz on Sat, Jun 24, 2000 at 07:09:56AM +0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Boris Popov (bp@butya.kz): > This is not correct. Not everybody knows English well, these are > mostly newbies and having translated docs and program messages is a real > help for them. Yes. But while I prefer German menus in GUI-programs, for example, I really dislike, that the same LANG var affects those stuff. Imagine a bug-report: How do _you_ want to understand an error message in German?? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 24 11:44:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id E0BAE37BA91; Sat, 24 Jun 2000 11:44:04 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 2ee4e7c625482f2f2a1950a80f6c8d58) with ESMTP id <20000624184458.XSQJ159.relay01@chello.nl>; Sat, 24 Jun 2000 20:44:58 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id UAA00740; Sat, 24 Jun 2000 20:44:02 +0200 (CEST) (envelope-from wkb) Date: Sat, 24 Jun 2000 20:44:02 +0200 From: Wilko Bulte To: Alexander Langer Cc: Boris Popov , "Dmitry S. Sivachenko" , freebsd-i18n@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: gettext Message-ID: <20000624204402.A704@freebie.wbnet> Reply-To: wilko@FreeBSD.ORG References: <20000623195641.C16231@cichlids.cichlids.com> <20000624183906.B2843@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000624183906.B2843@cichlids.cichlids.com>; from alex@big.endian.de on Sat, Jun 24, 2000 at 06:39:06PM +0200 X-OS: FreeBSD 4.0-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jun 24, 2000 at 06:39:06PM +0200, Alexander Langer wrote: > Thus spake Boris Popov (bp@butya.kz): > > > This is not correct. Not everybody knows English well, these are > > mostly newbies and having translated docs and program messages is a real > > help for them. > > Yes. But while I prefer German menus in GUI-programs, for example, I > really dislike, that the same LANG var affects those stuff. > > Imagine a bug-report: How do _you_ want to understand an error message > in German?? I can live with German. But Korean/Russian/Japanese etc will be much more difficult for Joe/Jane-average-committer. An idea like VMS uses comes to mind: IOERR-F-NOSUCHDEV: . The IOERR-thingy (I just invented this example) will be the same regardless of any i18n translated error text. Just an idea.. -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" wilko@freebsd.org http://www.nlfug.nl Yoda - The Empire Strikes Back To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 24 14:54: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 53E2037B5C3; Sat, 24 Jun 2000 14:53:53 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id PAA09335; Sat, 24 Jun 2000 15:01:04 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id OAA01110; Sat, 24 Jun 2000 14:53:27 -0700 (PDT) Date: Sat, 24 Jun 2000 14:53:27 -0700 (PDT) From: papowell@astart.com Message-Id: <200006242153.OAA01110@h4.private> To: Doug@gorean.org, nik@FreeBSD.ORG Subject: Re: Bringing LPRng into FreeBSD? Cc: arch@FreeBSD.ORG, papowell@astart.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here is a copy of the LPRng license. I think that the Artistic License is much more suitable for the FreeBSD distribution than the GNU License, and I would expect it to be the one that is used. *LPRng and IFHP LICENSE* GNU GPL and Artistic License (Version 4, Jan 24, 2000) Copyright Patrick Powell, Astart Technologies All rights reserved. You may use "LPRng" or "IFHP" under either the terms of the GNU GPL License or the Artistic License. These licenses are included below. These Licenses apply to the computer software packages known as "LPRng", "IFHP", and associated files. The "Package" or "Program" below refers to the programs, files, and associated software which are distributed as the package. The "LPRng" Software Package is a copyrighted work whose copyright is held by Patrick Powell. The "IFHP" Software Package is a copyrighted work whose copyright is held by Patrick Powell. BY MODIFYING OR DISTRIBUTING THE PROGRAM (OR ANY WORK BASED ON THE PROGRAM), YOU INDICATE YOUR ACCEPTANCE OF THIS LICENSE TO DO SO, AND ALL ITS TERMS AND CONDITIONS FOR COPYING, DISTRIBUTING OR MODIFYING THE PROGRAM OR WORKS BASED ON IT. NOTHING OTHER THAN THIS LICENSE GRANTS YOU PERMISSION TO MODIFY OR DISTRIBUTE THE PROGRAM OR ITS DERIVATIVE WORKS. THESE ACTIONS ARE PROHIBITED BY LAW. IF YOU DO NOT ACCEPT THESE TERMS AND CONDITIONS, DO NOT MODIFY OR DISTRIBUTE THE PROGRAM. ----------------------------------------------------------------------- Artistic License The "Artistic License" Preamble The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications. Definitions: "Package" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. "Standard Version" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder. "Copyright Holder" is whoever is named in the copyright or copyrights for the package. "You" is you, if you're thinking about copying or distributing this Package. "Reasonable copying fee" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) "Freely Available" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. 1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. b) use the modified Package only within your corporation or organization. c) rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version. d) make other distribution arrangements with the Copyright Holder. 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. b) accompany the distribution with the machine-readable source of the Package with your modifications. c) accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) make other distribution arrangements with the Copyright Holder. 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package. 7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package. 8. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission. 9. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. This license is based on the Open Source License available from http://www.opensource.org/artistic-license.html ------------------------------------------------------------------ GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS Appendix: How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message