From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 02:09:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDEB91065674 for ; Sun, 8 May 2011 02:09:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89AA58FC16 for ; Sun, 8 May 2011 02:09:04 +0000 (UTC) Received: by vxc34 with SMTP id 34so6317198vxc.13 for ; Sat, 07 May 2011 19:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KoQEG9+VqYv+ljdqDkCw5ZcLoUvriBjf2j/Ao/a90Nk=; b=l4sgdFjOmrmJ5eF7D8jNQ2tkdXm3eJZM1iFuyUmdJMGTeShk+2G4UQQH2CFCpGyg2M By9SWhqMEp3C14ksC1Y1tbYhYfe36HpxPjd+Q8MoK/kEvrG9BBBjOSoplOax4SHCYwhS 5ji6FNfaP6THJqXHI+zGJaLdQ/o+iQywHld68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZIiOb2W0Tghyfdvsk2tW++yyIkCCoDTQPhKVDSGCk+wxUBBigdYRf4RQRAInC1cT/D 5tqM1kGAYgs8vES5QLSivzc2U/MlzQv+YK6WwBrMP4oKaGaJal2B+Jgly3KYatuKQZZu 1zZ1CXmQjCYDQa37fi3uWwa4FBY3uvZNIhVtU= MIME-Version: 1.0 Received: by 10.220.247.139 with SMTP id mc11mr70728vcb.107.1304820543459; Sat, 07 May 2011 19:09:03 -0700 (PDT) Received: by 10.220.202.134 with HTTP; Sat, 7 May 2011 19:09:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 May 2011 19:09:03 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=bcaec54a37aefd129604a2ba34ae Subject: Re: [PATCH] draft patch to make usr.bin/kdump WARNS?= 6 clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 02:09:05 -0000 --bcaec54a37aefd129604a2ba34ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2011 at 9:40 AM, Garrett Cooper wrote: > On Mon, May 2, 2011 at 9:24 AM, Garrett Cooper wrote= : >> ---------- Forwarded message ---------- >> From: Garrett Cooper >> Date: Mon, May 2, 2011 at 9:24 AM >> Subject: Re: [PATCH] draft patch to make usr.bin/kdump WARNS?=3D 6 clean >> To: Arnaud Lacombe >> >> >> On Mon, May 2, 2011 at 9:21 AM, Arnaud Lacombe wrot= e: >>> Hi, >>> >>> On Mon, May 2, 2011 at 12:10 PM, Garrett Cooper wr= ote: >>>> =A0 =A0I wanted to do something different this weekend, and I picked >>>> usr.bin/kdump as a likely 'victim' for converting from WARNS?=3D 0 to >>>> WARNS?=3D 6. I'm curious as to whether or not this is on the right >>>> track, but here's the reasoning I used: >>>> >>>> 1. Conditionally include diskmbr.h or diskpc98.h based on whether or >>>> not an architecture was non-pc98 or pc98 to avoid duplicate >>>> definitions, because the beforementioned headers are mutually >>>> exclusive. >>>> 2. Move the sockfamilyname declaration to kdump_subr.h as it's used in >>>> the generated ioctl.c file. >>>> 3. Fix a signed vs unsigned comparison with a simple cast because the >>>> size_t value will be sufficiently small that it can be converted to a >>>> signed comparison. >>>> 4. Fix a cast assignment type source//dest value alignment issue on >>>> ia64 assigning a struct sockaddr value to either struct sockaddr_in or >>>> struct sockaddr_in6 by using calloc and memcpy. >>>> 5. Fix structure alignment issues on arm by marking some structures as= __packed. >>>> 6. Fix a shadowed declaration for flags by renaming a locally scoped >>>> variable to _flags; add appropriate type to field. >>>> 7. Remove unused argument to ktruser_malloc. >>>> 8. Add missing declarations for ktruser_malloc and ktruser_rtld. >>>> >>>> =A0 =A0I've run some basic tests and things seem sane (in particular >>>> ktrace'ing ktrace :)... ktrace'ing 'ssh ::1' and ktrace'ing 'ssh >>>> localhost', but I was wondering if there was anything I was missing or >>>> if someone else who ran arm or ia64 could test this patch out for me. >>>> =A0 =A0I've run make universe on amd64, i386, ia64, mips, and pc98, an= d >>>> things seem sane, but I can't play around with those machines to >>>> determine whether or not they're functional at runtime with the above >>>> changes. >>>> Thanks! >>>> -Garrett >>>> >>> I do not see any patch, either inline or attached. >>> >>> =A0- Arnaud >>> >>>> PS Oh yeah... no commit bit means that I can't commit this either, but >>>> I was curious if my approach was correct before getting to that step >>>> :). >> >> Yeah... I'm stupid for not attaching it. Need to get more sleep. > > Note to self: should be freeing socket structures after use, and I > should apply similar logic to the rest of the socket inspection code. > I'll attach another version after I do some more testing. Here's an updated patch that was run through make universe a couple of times. Thanks! -Garrett --bcaec54a37aefd129604a2ba34ae Content-Type: text/x-patch; charset=US-ASCII; name="usr-bin-kdump-WARNS-6-clean.patch" Content-Disposition: attachment; filename="usr-bin-kdump-WARNS-6-clean.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gnfc8j201 SW5kZXg6IHVzci5iaW4va2R1bXAva2R1bXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL2tkdW1w L2tkdW1wLmMJKHJldmlzaW9uIDIyMTIxOSkKKysrIHVzci5iaW4va2R1bXAva2R1bXAuYwkod29y a2luZyBjb3B5KQpAQCAtOTksOCArOTksOSBAQAogdm9pZCBrdHJzb2NrYWRkcihzdHJ1Y3Qgc29j a2FkZHIgKik7CiB2b2lkIGt0cnN0YXQoc3RydWN0IHN0YXQgKik7CiB2b2lkIGt0cnN0cnVjdChj aGFyICosIHNpemVfdCk7Cit2b2lkIGt0cnVzZXJfbWFsbG9jKHVuc2lnbmVkIGNoYXIgKiBwKTsK K3ZvaWQga3RydXNlcl9ydGxkKGludCBsZW4sIHVuc2lnbmVkIGNoYXIgKiBwKTsKIHZvaWQgdXNh Z2Uodm9pZCk7Ci12b2lkIHNvY2tmYW1pbHluYW1lKGludCk7CiBjb25zdCBjaGFyICppb2N0bG5h bWUodV9sb25nKTsKIAogaW50IHRpbWVzdGFtcCwgZGVjaW1hbCwgZmFuY3kgPSAxLCBzdXBwcmVz c2RhdGEsIHRhaWwsIHRocmVhZHMsIG1heGRhdGEsCkBAIC01MjgsMTMgKzUyOSwxMyBAQAogCQkJ CWlwKys7CiAJCQkJbmFyZy0tOwogCQkJfSBlbHNlIGlmIChrdHItPmt0cl9jb2RlID09IFNZU19v cGVuKSB7Ci0JCQkJaW50CWZsYWdzOworCQkJCWludAlvcGVuX2ZsYWdzOwogCQkJCWludAltb2Rl OwogCQkJCXByaW50X251bWJlcihpcCxuYXJnLGMpOwotCQkJCWZsYWdzID0gKmlwOworCQkJCW9w ZW5fZmxhZ3MgPSAqaXA7CiAJCQkJbW9kZSA9ICorK2lwOwogCQkJCSh2b2lkKXB1dGNoYXIoJywn KTsKLQkJCQlmbGFnc2FuZG1vZGVuYW1lIChmbGFncywgbW9kZSwgZGVjaW1hbCk7CisJCQkJZmxh Z3NhbmRtb2RlbmFtZSAob3Blbl9mbGFncywgbW9kZSwgZGVjaW1hbCk7CiAJCQkJaXArKzsKIAkJ CQluYXJnLT0yOwogCQkJfSBlbHNlIGlmIChrdHItPmt0cl9jb2RlID09IFNZU193YWl0NCkgewpA QCAtMTE2Nyw3ICsxMTY4LDcgQEAKIAlzaXplX3QgbWFwc2l6ZTsKIAlpbnQgcmVmY250OwogCWNo YXIgbmFtZVtNQVhQQVRITEVOXTsKLX07Cit9IF9fcGFja2VkOwogCiB2b2lkCiBrdHJ1c2VyX3J0 bGQoaW50IGxlbiwgdW5zaWduZWQgY2hhciAqcCkKQEAgLTEyNTMsMTAgKzEyNTQsMTAgQEAKIAl2 b2lkICpwOwogCXNpemVfdCBzOwogCXZvaWQgKnI7Ci19OworfSBfX3BhY2tlZDsKIAogdm9pZAot a3RydXNlcl9tYWxsb2MoaW50IGxlbiwgdW5zaWduZWQgY2hhciAqcCkKK2t0cnVzZXJfbWFsbG9j KHVuc2lnbmVkIGNoYXIgKnApCiB7CiAJc3RydWN0IHV0cmFjZV9tYWxsb2MgKnV0ID0gKHN0cnVj dCB1dHJhY2VfbWFsbG9jICopcDsKIApAQCAtMTI4MCw3ICsxMjgxLDcgQEAKIAl9CiAKIAlpZiAo bGVuID09IHNpemVvZihzdHJ1Y3QgdXRyYWNlX21hbGxvYykpIHsKLQkJa3RydXNlcl9tYWxsb2Mo bGVuLCBwKTsKKwkJa3RydXNlcl9tYWxsb2MocCk7CiAJCXJldHVybjsKIAl9CiAKQEAgLTEzMTUs NjEgKzEzMTYsNjcgQEAKIAlwcmludGYoIiwgIik7CiAKICNkZWZpbmUgY2hlY2tfc29ja2FkZHJf bGVuKG4pCQkJCQlcCi0JaWYgKHNhXyMjbi0+cyMjbiMjX2xlbiA8IHNpemVvZihzdHJ1Y3Qgc29j a2FkZHJfIyNuKSkgewlcCisJaWYgKHNhXyMjbi5zIyNuIyNfbGVuIDwgc2l6ZW9mKHN0cnVjdCBz b2NrYWRkcl8jI24pKSB7CVwKIAkJcHJpbnRmKCJpbnZhbGlkIik7CQkJCVwKIAkJYnJlYWs7CQkJ CQkJXAogCX0KIAogCXN3aXRjaChzYS0+c2FfZmFtaWx5KSB7CiAJY2FzZSBBRl9JTkVUOiB7Ci0J CXN0cnVjdCBzb2NrYWRkcl9pbgkqc2FfaW47CisJCXN0cnVjdCBzb2NrYWRkcl9pbiBzYV9pbjsK IAotCQlzYV9pbiA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4gKilzYTsKKwkJbWVtc2V0KCZzYV9pbiwg MCwgc2l6ZW9mKHNhX2luKSk7CisJCW1lbWNweSgmc2FfaW4sIHNhLCBzaXplb2Yoc2EpKTsKIAkJ Y2hlY2tfc29ja2FkZHJfbGVuKGluKTsKLQkJaW5ldF9udG9wKEFGX0lORVQsICZzYV9pbi0+c2lu X2FkZHIsIGFkZHIsIHNpemVvZiBhZGRyKTsKLQkJcHJpbnRmKCIlczoldSIsIGFkZHIsIG50b2hz KHNhX2luLT5zaW5fcG9ydCkpOworCQlpbmV0X250b3AoQUZfSU5FVCwgJnNhX2luLnNpbl9hZGRy LCBhZGRyLCBzaXplb2YgYWRkcik7CisJCXByaW50ZigiJXM6JXUiLCBhZGRyLCBudG9ocyhzYV9p bi5zaW5fcG9ydCkpOwogCQlicmVhazsKIAl9CiAjaWZkZWYgTkVUQVRBTEsKIAljYXNlIEFGX0FQ UExFVEFMSzogewotCQlzdHJ1Y3Qgc29ja2FkZHJfYXQJKnNhX2F0OworCQlzdHJ1Y3Qgc29ja2Fk ZHJfYXQJc2FfYXQ7CiAJCXN0cnVjdCBuZXRyYW5nZQkJKm5yOwogCi0JCXNhX2F0ID0gKHN0cnVj dCBzb2NrYWRkcl9hdCAqKXNhOworCQltZW1zZXQoJnNhX2F0LCAwLCBzaXplb2Yoc2FfYXQpKTsK KwkJbWVtY3B5KCZzYV9hdCwgc2EsIHNpemVvZihzYSkpOwogCQljaGVja19zb2NrYWRkcl9sZW4o YXQpOwotCQluciA9ICZzYV9hdC0+c2F0X3JhbmdlLnJfbmV0cmFuZ2U7Ci0JCXByaW50ZigiJWQu JWQsICVkLSVkLCAlZCIsIG50b2hzKHNhX2F0LT5zYXRfYWRkci5zX25ldCksCi0JCQlzYV9hdC0+ c2F0X2FkZHIuc19ub2RlLCBudG9ocyhuci0+bnJfZmlyc3RuZXQpLAorCQluciA9ICZzYV9hdC5z YXRfcmFuZ2Uucl9uZXRyYW5nZTsKKwkJcHJpbnRmKCIlZC4lZCwgJWQtJWQsICVkIiwgbnRvaHMo c2FfYXQuc2F0X2FkZHIuc19uZXQpLAorCQkJc2FfYXQuc2F0X2FkZHIuc19ub2RlLCBudG9ocyhu ci0+bnJfZmlyc3RuZXQpLAogCQkJbnRvaHMobnItPm5yX2xhc3RuZXQpLCBuci0+bnJfcGhhc2Up OwogCQlicmVhazsKIAl9CiAjZW5kaWYKIAljYXNlIEFGX0lORVQ2OiB7Ci0JCXN0cnVjdCBzb2Nr YWRkcl9pbjYJKnNhX2luNjsKKwkJc3RydWN0IHNvY2thZGRyX2luNiBzYV9pbjY7CiAKLQkJc2Ff aW42ID0gKHN0cnVjdCBzb2NrYWRkcl9pbjYgKilzYTsKKwkJbWVtc2V0KCZzYV9pbjYsIDAsIHNp emVvZihzYV9pbjYpKTsKKwkJbWVtY3B5KCZzYV9pbjYsIHNhLCBzaXplb2Yoc2EpKTsKIAkJY2hl Y2tfc29ja2FkZHJfbGVuKGluNik7Ci0JCWluZXRfbnRvcChBRl9JTkVUNiwgJnNhX2luNi0+c2lu Nl9hZGRyLCBhZGRyLCBzaXplb2YgYWRkcik7Ci0JCXByaW50ZigiWyVzXToldSIsIGFkZHIsIGh0 b25zKHNhX2luNi0+c2luNl9wb3J0KSk7CisJCWluZXRfbnRvcChBRl9JTkVUNiwgJnNhX2luNi5z aW42X2FkZHIsIGFkZHIsIHNpemVvZiBhZGRyKTsKKwkJcHJpbnRmKCJbJXNdOiV1IiwgYWRkciwg aHRvbnMoc2FfaW42LnNpbjZfcG9ydCkpOwogCQlicmVhazsKIAl9CiAjaWZkZWYgSVBYCiAJY2Fz ZSBBRl9JUFg6IHsKLQkJc3RydWN0IHNvY2thZGRyX2lweAkqc2FfaXB4OworCQlzdHJ1Y3Qgc29j a2FkZHJfaXB4IHNhX2lweDsKIAotCQlzYV9pcHggPSAoc3RydWN0IHNvY2thZGRyX2lweCAqKXNh OworCQltZW1zZXQoJnNhX2lweCwgMCwgc2l6ZW9mKHNhX2lweCkpOworCQltZW1jcHkoJnNhX2lw eCwgc2EsIHNpemVvZihzYSkpOwogCQljaGVja19zb2NrYWRkcl9sZW4oaXB4KTsKIAkJLyogWFhY IHdpc2ggd2UgaGFkIGlweF9udG9wICovCi0JCXByaW50ZigiJXMiLCBpcHhfbnRvYShzYV9pcHgt PnNpcHhfYWRkcikpOworCQlwcmludGYoIiVzIiwgaXB4X250b2Eoc2FfaXB4LnNpcHhfYWRkcikp OworCQlmcmVlKHNhX2lweCk7CiAJCWJyZWFrOwogCX0KICNlbmRpZgogCWNhc2UgQUZfVU5JWDog ewotCQlzdHJ1Y3Qgc29ja2FkZHJfdW4gKnNhX3VuOworCQlzdHJ1Y3Qgc29ja2FkZHJfdW4gc2Ff dW47CiAKLQkJc2FfdW4gPSAoc3RydWN0IHNvY2thZGRyX3VuICopc2E7CisJCW1lbXNldCgmc2Ff dW4sIDAsIHNpemVvZihzYV91bikpOworCQltZW1jcHkoJnNhX3VuLCBzYSwgc2l6ZW9mKHNhKSk7 CiAJCWNoZWNrX3NvY2thZGRyX2xlbih1bik7Ci0JCXByaW50ZigiJS4qcyIsIChpbnQpc2l6ZW9m KHNhX3VuLT5zdW5fcGF0aCksIHNhX3VuLT5zdW5fcGF0aCk7CisJCXByaW50ZigiJS4qcyIsIChp bnQpc2l6ZW9mKHNhX3VuLnN1bl9wYXRoKSwgc2FfdW4uc3VuX3BhdGgpOwogCQlicmVhazsKIAl9 CiAJZGVmYXVsdDoKQEAgLTE0ODAsOCArMTQ4Nyw4IEBACiAJaWYgKGRhdGFsZW4gPT0gMCkKIAkJ Z290byBpbnZhbGlkOwogCS8qIHNhbml0eSBjaGVjayAqLwotCWZvciAoaSA9IDA7IGkgPCBuYW1l bGVuOyArK2kpCi0JCWlmICghaXNhbHBoYSgodW5zaWduZWQgY2hhciluYW1lW2ldKSkKKwlmb3Ig KGkgPSAwOyBpIDwgKGludCluYW1lbGVuOyArK2kpCisJCWlmICghaXNhbHBoYShuYW1lW2ldKSkK IAkJCWdvdG8gaW52YWxpZDsKIAlpZiAoc3RyY21wKG5hbWUsICJzdGF0IikgPT0gMCkgewogCQlp ZiAoZGF0YWxlbiAhPSBzaXplb2Yoc3RydWN0IHN0YXQpKQpJbmRleDogdXNyLmJpbi9rZHVtcC9r ZHVtcF9zdWJyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLmJpbi9rZHVtcC9rZHVtcF9zdWJyLmgJKHJl dmlzaW9uIDIyMTIxOSkKKysrIHVzci5iaW4va2R1bXAva2R1bXBfc3Vici5oCSh3b3JraW5nIGNv cHkpCkBAIC00NSwzICs0NSw0IEBACiB2b2lkIG1pbmhlcml0bmFtZSAoaW50KTsKIHZvaWQgcXVv dGFjdGxuYW1lIChpbnQpOwogdm9pZCBwdHJhY2VvcG5hbWUgKGludCk7Cit2b2lkIHNvY2tmYW1p bHluYW1lKGludCk7CkluZGV4OiB1c3IuYmluL2tkdW1wL21raW9jdGxzCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHVzci5iaW4va2R1bXAvbWtpb2N0bHMJKHJldmlzaW9uIDIyMTIxOSkKKysrIHVzci5iaW4va2R1 bXAvbWtpb2N0bHMJKHdvcmtpbmcgY29weSkKQEAgLTIyLDEyICsyMiwyMSBAQAogIyBYWFggc2hv dWxkIHdlIHVzZSBhbiBBTlNJIGNwcD8KIGlvY3RsX2luY2x1ZGVzPWAKIAljZCAkMQotCWZpbmQg LUggLXMgKiAtbmFtZSAnKi5oJyB8CisJZmluZCAtSCAtcyAqIC1uYW1lICcqLmgnIHwgZ3JlcCAt diAnLipkaXNrLipcLmgnIHwgXAogCQl4YXJncyBlZ3JlcCAtbCBcCiAnXiNbIAldKmRlZmluZVsg CV0rW0EtWmEtel9dW0EtWmEtejAtOV9dKlsgCV0rX0lPW15hLXowLTlfXScgfAogCQlhd2sgJ3tw cmludGYoIiNpbmNsdWRlIDwlcz5cXFxcbiIsICQxKX0nCiBgCiAKK2Nhc2UgImB1bmFtZSAtbWAi IGluCisqcGM5OCopCisJaW9jdGxfaW5jbHVkZXM9IiRpb2N0bF9pbmNsdWRlcyNpbmNsdWRlIDxz eXMvZGlza3BjOTguaD5cXG4iCisJOzsKKyopCisJaW9jdGxfaW5jbHVkZXM9IiRpb2N0bF9pbmNs dWRlcyNpbmNsdWRlIDxzeXMvZGlza21ici5oPlxcbiIKKwk7OworZXNhYworCiBhd2sgLXYgeD0i JGlvY3RsX2luY2x1ZGVzIiAnQkVHSU4ge3ByaW50IHh9JyB8CiAJZ2NjIC1FIC1JJDEgLWRNIC1E Q09NUEFUXzQzVFRZIC0gfAogCWF3ayAtdiBpb2N0bF9pbmNsdWRlcz0iJGlvY3RsX2luY2x1ZGVz IiAtdiB1c2Vfc3dpdGNoPSIkdXNlX3N3aXRjaCIgJwpJbmRleDogdXNyLmJpbi9rZHVtcC9NYWtl ZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL2tkdW1wL01ha2VmaWxlCShyZXZpc2lvbiAyMjEy MTkpCisrKyB1c3IuYmluL2tkdW1wL01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xNSw3ICsx NSw3IEBACiBTUkNTKz0JCWxpbnV4X3N5c2NhbGxzLmMKIC5lbmRpZgogCi1XQVJOUz89CQkwCitX QVJOUz89CQk2CiAKIENMRUFORklMRVM9CWlvY3RsLmMga2R1bXBfc3Vici5jIGxpbnV4X3N5c2Nh bGxzLmMKIAo= --bcaec54a37aefd129604a2ba34ae-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 03:25:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78923106566B for ; Sun, 8 May 2011 03:25:26 +0000 (UTC) (envelope-from while1@163.com) Received: from m13-8.163.com (m13-8.163.com [220.181.13.8]) by mx1.freebsd.org (Postfix) with ESMTP id 19F868FC18 for ; Sun, 8 May 2011 03:25:23 +0000 (UTC) Received: from while1 ( [119.33.74.51] ) by ajax-webmail-wmsvr8 (Coremail) ; Sun, 8 May 2011 11:24:20 +0800 (CST) Date: Sun, 8 May 2011 11:24:20 +0800 (CST) From: =?GBK?B?wLzH5Q==?= To: "Devin Teske" Message-ID: <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> In-Reply-To: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> MIME-Version: 1.0 X-Originating-IP: [119.33.74.51] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 110420(13372.3725.3724) Copyright (c) 2002-2011 www.mailtech.cn 163com X-CM-CTRLDATA: dIfcCGZvb3Rlcl9odG09NzIyMjo4MQ== X-CM-TRANSID: CMGowKDraLEfDcZN0xgNAA--.10783W X-CM-SenderInfo: xzklzvqr6rljoofrz/1tbiGAw5gT-6YNss2gABsl X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Mailman-Approved-At: Sun, 08 May 2011 03:57:08 +0000 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re:[UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 03:25:26 -0000 SGkgRGV2aW4sCiAgIFRoaXMgbG9hZGVyIG1lbnUgaXMgYXdlc29tZSEgQnV0IGFzIEkgb3Bpbmlv biwgaXRlbXMgKDEsNiw3KSBhbmQgKDIsMyw0LDUpIGFyZSB0d28gZGlmZmVyZW50IHRoaW5nLgox LkJvb3RbRW50ZXJdCjYuRXNjYXBlIHRvIGxvYWRlciBwcm9tcHQgCjcuUmVib290CiAgVGhlc2Ug b3B0aW9ucyBhcmUgYm9vdGluZyBhY3Rpb24uCjIuQUNQSSBTdXBwb3J0CjMuQm9vdCBTYWZlIE1v ZGUKNC5Cb290IFNpbmdsZSBVc2VyCjUuQm9vdCBWZXJib3NlCiAgVGhlc2Ugb3B0aW9ucyBhcmUg Ym9vdGluZyBjb25maWd1cmVzLiBTZXBhcmF0ZSB0aGVtIHdpbGwgYmUgYmV0dGVyLCBsaWtlIHRo aXMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KfDEuQm9vdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAp8Mi5Qcm9tcHQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp8My5SZWJvb3QgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp8ICAgICAg ICAgICAgfAp8Q29uZmlndXJhdGlvbjogfAp8MS5BQ1BJIFN1cHBvcnR8CnwyLlNhZmUgTW9kZXwK fDMuU2luZ2xlIFVzZXIgTW9kZXwKfDQuVmVyYm9zZSBCb290IE1vZGV8Cgp8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogIERv IHlvdSB0aGluayBzbz8KCkF0IDIwMTEtMDUtMDUgMTY6MjA6NDOjrCJEZXZpbiBUZXNrZSIgPGR0 ZXNrZUB2aWNvci5jb20+IHdyb3RlOgoKPkhlbGxvIGZlbGxvdyAtaGFja2VycywKPgo+SSdtIHNv IHZlcnkgcHJvdWQgdG8gb2ZmZXIgdGhlIGxhdGVzdCB1cGRhdGUgdG8gbXkgbmV3IGJvb3QgbG9h ZGVyIG1lbnUgLS0gdmVyc2lvbiAxLjQgLS0gYWRkcmVzc2luZyBBQ1BJIGRldGVjdGlvbiwgYnJp bmdpbmcgaXQgaW4tbGluZSB3aXRoIEhFQUQuCj4KPkl0IHRvb2sgc29tZSB3b3JrIGFuZCBhIGZl dyBkYXlzLCBidXQgSSBnb3QgaXQhIEhhdmUgYSBsb29rIGJlbG93IGZvciBzaXggZGlmZmVyZW50 IGRpc3BsYXlzICh0aHJlZSBkaWZmZXJlbnQgc2NlbmFyaW9zIC0tIGkzODYgdy8gQUNQSSwgaTM4 NiB3L28gQUNQSSwgYW5kIG5vbi1pMzg2IC0tIGVhY2ggaW4gYm90aCBCJlcgYW5kIENvbG9yKS4K Pgo+UnVubmluZyBvbiBpMzg2LWNvbXBhdGlibGUgaGFyZHdhcmUgc3VwcG9ydGluZyBBQ1BJOgo+ QiZXIChzdGFuZGFyZCk6IGh0dHA6Ly90d2l0cGljLmNvbS80dGxzaW4KPkNvbG9yIChsb2FkZXJf Y29sb3I9WUVTKTogaHR0cDovL3R3aXRwaWMuY29tLzR0bHQ2bAo+Cj5SdW5uaW5nIG9uIGkzODYt Y29tcGF0aWJsZSBoYXJkd2FyZSBsYWNraW5nIEFDUEkgc3VwcG9ydDoKPkImVyAoc3RhbmRhcmQp OiBodHRwOi8vdHdpdHBpYy5jb20vNHRsdHAwCj5Db2xvciAobG9hZGVyX2NvbG9yPVlFUyk6IGh0 dHA6Ly90d2l0cGljLmNvbS80dGx1NXcKPgo+UnVubmluZyBvbiBub24taTM4NiBoYXJkd2FyZToK PkImVyAoc3RhbmRhcmQpOiBodHRwOi8vdHdpdHBpYy5jb20vNHRsdWlvCj5Db2xvciAobG9hZGVy X2NvbG9yPVlFUyk6IGh0dHA6Ly90d2l0cGljLmNvbS80dGx1dXkKPgo+VGhpcyB2ZXJzaW9uIGlz IGZlYXR1cmUgY29tcGxldGUgd2l0aCBIRUFEIGFuZCBiYWNrd2FyZCBjb21wYXRpYmxlIHRvIDcu MC1SRUxFQVNFLgo+Cj5JIGRvIGhvcGUgeW91IGxpa2UgdGhpcyBsYXRlc3QgdmVyc2lvbi4gWW91 IGNhbiBnZXQgeW91ciB1cGRhdGUgYXQ6Cj4KPmh0dHA6Ly9kcnVpZGJzZC5zb3VyY2Vmb3JnZS5u ZXQvCj4Jb3IKPmh0dHA6Ly9kcnVpZGJzZC5zb3VyY2Vmb3JnZS5uZXQvZG93bmxvYWQvbG9hZGVy X21lbnUtMS40LnRnego+LS0gCj5DaGVlcnMsCj5EZXZpbiBUZXNrZQo+Cj4tPiBGVU4gU1RVRkYg PC0KPi0tLS0tQkVHSU4gR0VFSyBDT0RFIEJMT0NLLS0tLS0KPlZlcnNpb24gMy4xMgo+R0FUL0NT L0IvQ0MvRS9JVC9NQy9NL01VL1AvUy9UVyBkKygrKykgczogYS0gQysrK0AkIFVCKysrKyQgUCsr KytAJCBMKysrKyQgRS0KPlcrKysgTj8gbz8gSz8gd0AgTyBNKyskIFYtIFBTKz4rKyBQRUAgWSsg UEdQLT4gdCgrKSA1PyBYKCspIFIoLSkgdHYrIGIrPisrIERJKwo+RCsoKyspIEcrKyBlPisrKysg aCByKysrIHorKysKPi0tLS0tLUVORCBHRUVLIENPREUgQkxPQ0stLS0tLS0KPmh0dHA6Ly93d3cu Z2Vla2NvZGUuY29tLwo+Cj4tPiBMRUdBTCBESVNDTEFJTUVSIDwtCj5UaGlzIG1lc3NhZ2UgIGNv bnRhaW5zIGNvbmZpZGVudGlhbCAgYW5kIHByb3ByaWV0YXJ5ICBpbmZvcm1hdGlvbgo+b2YgdGhl IHNlbmRlciwgIGFuZCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uKHMpIHRvIHdob20g aXQKPmlzIGFkZHJlc3NlZC4gQW55IHVzZSwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nIG9yIGRpc2Ns b3N1cmUgYnkgYW55Cj5vdGhlciBwZXJzb24gIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5 b3UgaGF2ZSAgcmVjZWl2ZWQgdGhpcwo+bWVzc2FnZSBpbiBlcnJvciwgIHBsZWFzZSBub3RpZnkg IHRoZSBlLW1haWwgc2VuZGVyICBpbW1lZGlhdGVseSwKPmFuZCBkZWxldGUgdGhlIG9yaWdpbmFs IG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYSBjb3B5Lgo+Cj4tPiBFTkQgVFJBTlNNSVNTSU9OIDwt Cj4KPl9fX19fX19fX19fX18KPgo+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2UgaXMgcHJvcHJpZXRhcnkgYW5kL29yIGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlOiAoaSkgZGVsZXRlIHRoZSBtZXNzYWdlIGFu ZCBhbGwgY29waWVzOyAoaWkpIGRvIG5vdCBkaXNjbG9zZSwgZGlzdHJpYnV0ZSBvciB1c2UgdGhl IG1lc3NhZ2UgaW4gYW55IG1hbm5lcjsgYW5kIChpaWkpIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5LiBJbiBhZGRpdGlvbiwgcGxlYXNlIGJlIGF3YXJlIHRoYXQgYW55IG1lc3NhZ2UgYWRk cmVzc2VkIHRvIG91ciBkb21haW4gaXMgc3ViamVjdCB0byBhcmNoaXZpbmcgYW5kIHJldmlldyBi eSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhhbmsgeW91Lgo+ X19fX19fX19fX19fXwo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPmZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPmh0dHA6Ly9s aXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtaGFja2Vycwo+VG8gdW5z dWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtaGFja2Vycy11bnN1YnNjcmliZUBm cmVlYnNkLm9yZyIK From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 08:25:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23167106564A for ; Sun, 8 May 2011 08:25:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id D53B68FC0A for ; Sun, 8 May 2011 08:25:17 +0000 (UTC) Received: by yie12 with SMTP id 12so1951582yie.13 for ; Sun, 08 May 2011 01:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c+H0KUWm6NGJ2sBH1CoVSxqzQyB6gEstDpwzmkzRjH0=; b=B/QT4b6kUOgUvkF1qHNCos6Dyo/1KVg+dCeCChPQju6OSNlTRA9ofnfo4MuS4ClCib nTTNJZgSxZO6i5scl1raF6f4HD/mx0Y63cyEtcSNhfX3wTWa1scxRSRpKGT636/KjdZi 81At3v43A7MujG7eX+cEf6/JySPTcJ5/HHs4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YoTAZXUwQqLjxvUdSCGgTTc8k5PM5hw6NNppQq0BeafpKYl+afP5lwue1JLRf2GRJf DaXfNBXBcQLZlNDvGnma2GIBwihrKegBYZ7fCqeDz16YQOdeRR7BLjT9bw9DkFtZLPG8 g8M4WU5yI6hLy26H8uTKFQL7C+t9ahYhFcxQM= MIME-Version: 1.0 Received: by 10.150.66.1 with SMTP id o1mr361589yba.125.1304841489654; Sun, 08 May 2011 00:58:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Sun, 8 May 2011 00:58:09 -0700 (PDT) In-Reply-To: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> Date: Sun, 8 May 2011 15:58:09 +0800 X-Google-Sender-Auth: x28lPY4D612i9UK2PYp3JdMN2HA Message-ID: From: Adrian Chadd To: Damjan Marion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 08:25:18 -0000 On 8 May 2011 01:22, Damjan Marion wrote: > I would like to implement support for embedded switch on WRT350Nv2 router= which is based on 88F5181L SoC (ARM). FreeBSD already have support for emb= edded gigabit card (if_mge) but in case if this router MAC is connected dir= ectly to 8-port ethernet chip (88E6131). If I use MII_PHY_ANY scan founds f= ollowing PHYs on miibus: There's been some discussions in the past about how to implement a switch PHY API for use by the variety of embedded switch devices out there. There's been a few attempts at it too. What I think may just be a good first step is to port over the Linux driver for it and instead of trying to make it appear as a multi-PHY device, just export a programming and status interface via sysctl. That at least gets the thing in the tree and functioning. Once we have a few devices in the tree and functioning, we'll be in a better position to have a discussion about how to represent it. There's a couple of dissenting views about how it should be implemented. I'd like to see some working code in the tree so some discussion can occur, rather than lots of dissent and no discussion. :) (The switch phy is the last remaining bit of the board support for a handful of boards too, so I'd really like to see it completed. :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 09:36:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEEA4106564A for ; Sun, 8 May 2011 09:36:33 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6BB8FC0C for ; Sun, 8 May 2011 09:36:32 +0000 (UTC) Received: by wwc33 with SMTP id 33so4471871wwc.31 for ; Sun, 08 May 2011 02:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=P3qxd0otR5OG6Kk7mErRSuXUQpeygTkGJ69321gdi3Y=; b=jujNZNzQw5lVHl6Q7+pXrNTVa2ljfDybRsWJmCu/KJbiEhMpt/43R0XbU479Qz3lXa Z4M559LsN7ygkzxxpzjSpAa/zhcFgHN+Ec52VqflczC/TAlyjEYvY9ocrR4Bu+K9gZ4T 9mFPnsBEYkwa8+0kzvmpr5ck1Kx9YrDprnUwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qG0sHX5XADG+me05M4o9zHZTNVkIiU/my3NVAbwzPTzGMGxJ7tVh+Gce5A6RoNCttx uDbANyH8i2ErMujtzRzY2TNF3dCOjpiNYnWP6vFvSnmn59DqpIJqbfsfCTXLf7gi1lpB F4FC4lZLUBrCVYv1tf1giqjhKJV5nfoxUlmzc= Received: by 10.216.82.77 with SMTP id n55mr5778512wee.52.1304847391772; Sun, 08 May 2011 02:36:31 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id f52sm2445672wes.35.2011.05.08.02.36.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 02:36:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: Date: Sun, 8 May 2011 11:36:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84255DD0-2593-4F24-8536-2C015CE11DC4@gmail.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 09:36:34 -0000 On May 8, 2011, at 9:58 AM, Adrian Chadd wrote: > On 8 May 2011 01:22, Damjan Marion wrote: >=20 >> I would like to implement support for embedded switch on WRT350Nv2 = router which is based on 88F5181L SoC (ARM). FreeBSD already have = support for embedded gigabit card (if_mge) but in case if this router = MAC is connected directly to 8-port ethernet chip (88E6131). If I use = MII_PHY_ANY scan founds following PHYs on miibus: >=20 > There's been some discussions in the past about how to implement a > switch PHY API for use by the variety of embedded switch devices out > there. >=20 > There's been a few attempts at it too. >=20 > What I think may just be a good first step is to port over the Linux > driver for it and instead of trying to make it appear as a multi-PHY > device, just export a programming and status interface via sysctl. > That at least gets the thing in the tree and functioning. Once we have > a few devices in the tree and functioning, we'll be in a better > position to have a discussion about how to represent it. >=20 > There's a couple of dissenting views about how it should be > implemented. I'd like to see some working code in the tree so some > discussion can occur, rather than lots of dissent and no discussion. > :) >=20 > (The switch phy is the last remaining bit of the board support for a > handful of boards too, so I'd really like to see it completed. :) Hi Adrian, I agree with your approach. At this point my concern is how to change = existing code to support switch PHY. In my case problem is that = mii_attach as it is today cannot be used detect this device as device is = not using standard registers. I can see 2 possible options: 1. Modifying eth driver in the way that if switch phy is detected then = it avoids calling mii_attach. Drawback of this approach is that it will = need applying same code for each pair of MAC-switch PHY 2. Modifying mii_attach in the way that it is more flexible in detecting = such devices. This looks challenging to me to do this in flexible way. What do you think? Damjan= From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 13:27:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A82B106566C for ; Sun, 8 May 2011 13:27:56 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id AA3E78FC1A for ; Sun, 8 May 2011 13:27:55 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p48DGhNU023707; Sun, 8 May 2011 15:16:43 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p48DGh07023706; Sun, 8 May 2011 15:16:43 +0200 (CEST) (envelope-from marius) Date: Sun, 8 May 2011 15:16:43 +0200 From: Marius Strobl To: Damjan Marion Message-ID: <20110508131643.GA23650@alchemy.franken.de> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 13:27:56 -0000 On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: > > Hi, > > > I would like to implement support for embedded switch on WRT350Nv2 router which is based on 88F5181L SoC (ARM). FreeBSD already have support for embedded gigabit card (if_mge) but in case if this router MAC is connected directly to 8-port ethernet chip (88E6131). If I use MII_PHY_ANY scan founds following PHYs on miibus: > > mge0: mem 0xf1072000-0xf1073fff irq 18,19,20,21,22 on simplebus0 > miibus0: on mge0 > e1000phy0: PHY 12 on miibus0 > e1000phy0: id1=0x0141, id2=0x0c00 > e1000phy1: PHY 13 on miibus0 > e1000phy1: id1=0x0141, id2=0x0c00 > e1000phy2: PHY 14 on miibus0 > e1000phy2: id1=0x0141, id2=0x0c00 > e1000phy3: PHY 15 on miibus0 > e1000phy3: id1=0x0141, id2=0x0c00 > ukphy0: PHY 20 on miibus0 > ukphy0: > ukphy1: PHY 21 on miibus0 > ukphy1: > ukphy2: PHY 22 on miibus0 > ukphy2: > ukphy3: PHY 23 on miibus0 > > if_mge MAC is connected to port 3 of E6131 and port 3 acts in reverse-GMII mode to simulate PHY side. > > Reason for output above is that E6131 uses non-standard registers on multiple device addresses and on some of them mii_attach fails, and on another it false detects PHY (20-23 above). Well, if the switch responds on these addresses then from a MII point of view there's nothing wrong about this when using MII_PHY_ANY. If you want only one of these to attach than use that address instead of MII_PHY_ANY. By calling mii_attach() multiple times with different addresses you can also attach a subset. > > I would like to hear form more experienced people how to implement this properly, as it is obvious that it cannot be addressed with existing routines. Depends on what you understand by properly. One idea I particularly like is to handle switch ports as pseudo-interfaces hanging off of the the MAC driver parent roughly similar to vlan(4). That way you'd have per port link status and could configure the media. What you can do now without changing mii(4) is to just attach the the PHY side, i.e. port 3, and configure/handle the ports in a special PHY driver, either by hardcoding their configuration like rlswitch(4) does or by providing SYSCTLs as Adrian already said. If we had a way to access the PHY registers from userland similar to what pci(4)/pciconf(8) allows, which is another thing I'd like to see in order to provide miitool-like functionality, one could also easily handle the port configuration from userland instead of putting everything into the kernel. That probably also would have its merits as in reality there are probably a lot of quirks like unconnected ports etc. Marius From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 13:52:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6802C106564A for ; Sun, 8 May 2011 13:52:34 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ED5978FC08 for ; Sun, 8 May 2011 13:52:33 +0000 (UTC) Received: by wwc33 with SMTP id 33so4573512wwc.31 for ; Sun, 08 May 2011 06:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=fXu9E7Gqdp0eOA9XPiUKH6S6pWkAjpe2tXmbAvLGTAo=; b=SifSsF8gLC/Dl+QfJz1yF6+MD7BwCOy8uQeeVYgjyoItlf90uf8GtRNfdTrNHHFOFI +ZTbVMhax0zDOfU0DDdzQNWzrbwBz6B3hUem2ioU8dHF66SFlrEJ3ByADwlG0aSaRhjn Dqoqt4oOsuAWkftf7UHnr0/iOSCm18kW5QGUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=g0di/7p34EZ+wnQcIpLfjYb01A310R5IZLDaVEGeMurSVLtckUft18ljR0DeZq5hdi 8TFzME4YscQ61bZoeVhbkOxYZarXAN+krkS3aO7Vhe8r3tXPywpl1Vl4fpsLMuUJY6LD hrGdp8uGmyh8sYTqLjTEoKmvKEENi4sQ/rLfY= Received: by 10.227.42.130 with SMTP id s2mr6151848wbe.103.1304862752723; Sun, 08 May 2011 06:52:32 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id w25sm1853350wbd.22.2011.05.08.06.52.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 06:52:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <20110508131643.GA23650@alchemy.franken.de> Date: Sun, 8 May 2011 15:52:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 13:52:34 -0000 On May 8, 2011, at 3:16 PM, Marius Strobl wrote: > On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: >>=20 >> Hi, >>=20 >>=20 >> I would like to implement support for embedded switch on WRT350Nv2 = router which is based on 88F5181L SoC (ARM). FreeBSD already have = support for embedded gigabit card (if_mge) but in case if this router = MAC is connected directly to 8-port ethernet chip (88E6131). If I use = MII_PHY_ANY scan founds following PHYs on miibus: >>=20 >> mge0: mem 0xf1072000-0xf1073fff = irq 18,19,20,21,22 on simplebus0 >> miibus0: on mge0 >> e1000phy0: PHY 12 on miibus0 >> e1000phy0: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy1: PHY 13 on miibus0 >> e1000phy1: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy2: PHY 14 on miibus0 >> e1000phy2: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy3: PHY 15 on miibus0 >> e1000phy3: id1=3D0x0141, id2=3D0x0c00=20 >> ukphy0: PHY 20 on miibus0 >> ukphy0: =20 >> ukphy1: PHY 21 on miibus0 >> ukphy1: =20 >> ukphy2: PHY 22 on miibus0 >> ukphy2: =20 >> ukphy3: PHY 23 on miibus0 >>=20 >> if_mge MAC is connected to port 3 of E6131 and port 3 acts in = reverse-GMII mode to simulate PHY side. >>=20 >> Reason for output above is that E6131 uses non-standard registers on = multiple device addresses and on some of them mii_attach fails, and on = another it false detects PHY (20-23 above). >=20 > Well, if the switch responds on these addresses then from a MII point > of view there's nothing wrong about this when using MII_PHY_ANY. If > you want only one of these to attach than use that address instead of > MII_PHY_ANY. By calling mii_attach() multiple times with different > addresses you can also attach a subset. Yes, my initial idea is to attach manually only to one PHY, but problem=20= is that either i can attach to PHY12-15 which is reporting wrong ID2=20 belonging to different PHY driver or to attach on PHY20-23 where ID1 and = ID2=20 registers doesn't exist, but luckily some values are at that address and=20= they are recognized as unknown PHY. In both cases it sounds like a workaround more than a proper solution, = so=20 I was wondering if there is some better way to detect PHY, not only by=20= ID1 and ID2 values. In case of this device there is another register = which=20 contains product identifier, and that is what linux driver probes. >=20 >>=20 >> I would like to hear form more experienced people how to implement = this properly, as it is obvious that it cannot be addressed with = existing routines. >=20 > Depends on what you understand by properly. One idea I particularly > like is to handle switch ports as pseudo-interfaces hanging off of the > the MAC driver parent roughly similar to vlan(4). That way you'd have > per port link status and could configure the media. >=20 > What you can do now without changing mii(4) is to just attach the > the PHY side, i.e. port 3, and configure/handle the ports in a > special PHY driver, either by hardcoding their configuration like > rlswitch(4) does or by providing SYSCTLs as Adrian already said. > If we had a way to access the PHY registers from userland similar > to what pci(4)/pciconf(8) allows, which is another thing I'd like > to see in order to provide miitool-like functionality, one could > also easily handle the port configuration from userland instead > of putting everything into the kernel. That probably also would > have its merits as in reality there are probably a lot of quirks > like unconnected ports etc. Agree, I will try to code something and then I will ask wider audience = to comment on. From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 14:14:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC831065673 for ; Sun, 8 May 2011 14:14:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8EF8FC08 for ; Sun, 8 May 2011 14:14:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p48EEult023922; Sun, 8 May 2011 16:14:56 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p48EEur3023921; Sun, 8 May 2011 16:14:56 +0200 (CEST) (envelope-from marius) Date: Sun, 8 May 2011 16:14:56 +0200 From: Marius Strobl To: Damjan Marion Message-ID: <20110508141456.GD92688@alchemy.franken.de> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 14:14:58 -0000 On Sun, May 08, 2011 at 03:52:29PM +0200, Damjan Marion wrote: > > On May 8, 2011, at 3:16 PM, Marius Strobl wrote: > > > On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: > >> > >> Hi, > >> > >> > >> I would like to implement support for embedded switch on WRT350Nv2 router which is based on 88F5181L SoC (ARM). FreeBSD already have support for embedded gigabit card (if_mge) but in case if this router MAC is connected directly to 8-port ethernet chip (88E6131). If I use MII_PHY_ANY scan founds following PHYs on miibus: > >> > >> mge0: mem 0xf1072000-0xf1073fff irq 18,19,20,21,22 on simplebus0 > >> miibus0: on mge0 > >> e1000phy0: PHY 12 on miibus0 > >> e1000phy0: id1=0x0141, id2=0x0c00 > >> e1000phy1: PHY 13 on miibus0 > >> e1000phy1: id1=0x0141, id2=0x0c00 > >> e1000phy2: PHY 14 on miibus0 > >> e1000phy2: id1=0x0141, id2=0x0c00 > >> e1000phy3: PHY 15 on miibus0 > >> e1000phy3: id1=0x0141, id2=0x0c00 > >> ukphy0: PHY 20 on miibus0 > >> ukphy0: > >> ukphy1: PHY 21 on miibus0 > >> ukphy1: > >> ukphy2: PHY 22 on miibus0 > >> ukphy2: > >> ukphy3: PHY 23 on miibus0 > >> > >> if_mge MAC is connected to port 3 of E6131 and port 3 acts in reverse-GMII mode to simulate PHY side. > >> > >> Reason for output above is that E6131 uses non-standard registers on multiple device addresses and on some of them mii_attach fails, and on another it false detects PHY (20-23 above). > > > > Well, if the switch responds on these addresses then from a MII point > > of view there's nothing wrong about this when using MII_PHY_ANY. If > > you want only one of these to attach than use that address instead of > > MII_PHY_ANY. By calling mii_attach() multiple times with different > > addresses you can also attach a subset. > > Yes, my initial idea is to attach manually only to one PHY, but problem > is that either i can attach to PHY12-15 which is reporting wrong ID2 > belonging to different PHY driver or to attach on PHY20-23 where ID1 and ID2 > registers doesn't exist, but luckily some values are at that address and > they are recognized as unknown PHY. > > In both cases it sounds like a workaround more than a proper solution, so > I was wondering if there is some better way to detect PHY, not only by > ID1 and ID2 values. In case of this device there is another register which > contains product identifier, and that is what linux driver probes. Well, if ID1 and ID2 don't exist it's not 802.3 compliant, in which case I'd think it shouldn't be handled by mii(4) but some other layer in the first place :) That that said methods used to deal with broken PHYs reporting invalid values for ID{1,2} is to either additionally take the parent driver into consideration (see f.e. rlphy(4) or to fake these registers in the MAC driver (see f.e. dc(4), which actually fakes a whole MII bus in !DC_PMODE_MII mode). > > > > > >> > >> I would like to hear form more experienced people how to implement this properly, as it is obvious that it cannot be addressed with existing routines. > > > > Depends on what you understand by properly. One idea I particularly > > like is to handle switch ports as pseudo-interfaces hanging off of the > > the MAC driver parent roughly similar to vlan(4). That way you'd have > > per port link status and could configure the media. > > > > What you can do now without changing mii(4) is to just attach the > > the PHY side, i.e. port 3, and configure/handle the ports in a > > special PHY driver, either by hardcoding their configuration like > > rlswitch(4) does or by providing SYSCTLs as Adrian already said. > > If we had a way to access the PHY registers from userland similar > > to what pci(4)/pciconf(8) allows, which is another thing I'd like > > to see in order to provide miitool-like functionality, one could > > also easily handle the port configuration from userland instead > > of putting everything into the kernel. That probably also would > > have its merits as in reality there are probably a lot of quirks > > like unconnected ports etc. > > Agree, I will try to code something and then I will ask wider audience to comment on. > > Marius From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 17:49:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0029B1065673 for ; Sun, 8 May 2011 17:49:11 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id BC2F28FC23 for ; Sun, 8 May 2011 17:49:11 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p48HmwuI021670; Sun, 8 May 2011 12:48:58 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 12:49:06 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 12:48:58 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 12:48:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske X-Priority: 3 In-Reply-To: <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> Date: Sun, 8 May 2011 10:48:55 -0700 Message-Id: <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> To: =?utf-8?B?5YWw5riF?= X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 17:48:57.0427 (UTC) FILETIME=[348DB230:01CC0DA8] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 17:49:12 -0000 On May 7, 2011, at 8:24 PM, =E5=85=B0=E6=B8=85 wrote: > Hi Devin, Hi Lan, > This loader menu is awesome! Thank you. > But as I opinion, items (1,6,7) and (2,3,4,5) are two different thing. Hmmm. You're right. > 1.Boot[Enter] > 6.Escape to loader prompt=20 > 7.Reboot > These options are booting action. Interesting idea to group them that way. > 2.ACPI Support > 3.Boot Safe Mode > 4.Boot Single User > 5.Boot Verbose > These options are booting configures. I follow you so far. > Separate them will be better, like this > ----------------------------------------------------------------- > | 1.Boot | > | 2.Prompt | > | 3.Reboot | > | | > |Configuration: | > | 1.ACPI Support | > | 2.Safe Mode | > | 3.Single User Mode | > | 4.Verbose Boot Mode | > |---------------------------------------------------------------| > Do you think so? That's an interesting idea, and I gave it some good thought... until... I realized that if you pressed "1" on the keyboard, would it boot or would = it toggle "ACPI Support". To implement a dual-menu system, either the numbers would have to go entire= ly, or the numbers would have to not overlap. The code is not currently situated to do any of the following which would b= e required to implement what you're recommending above (either as a single-= menu or as a dual-menu with non-overlapping menuitem keycodes): 1. Not currently possible to display two menus simultaneously (only one "ge= tkey" function can be waiting for keyboard input at once, so [a] either the= "menu-init" or "menu-create" function would need to be rewritten to dynami= cally allocate variables rather than using static identifiers, [b] the "men= u-create" function would need to change scope to allow multiple menus to be= defined each with their own unique properties including captions and posit= ion, and [c] the "menu-display" function would need to test keycodes for mu= ltiple menus that were generated by "menu-create" -- all of which are conta= ined within /boot/menu.4th). 2. Not currently possible (with a single menu) to display a gap. Even defin= ing a NULL caption will still cause the number to be printed to the left of= the menuitem. Though I'm sure with a trivial tweak to "printmenuitem" (in = /boot/menu.4th), checking the length identifier of the C-Addr couplet to be= non-zero on the stack prior to dropping the dup'd menuidx to screen should= suffice. However, even if you do that, you would then come to your next ch= allenge... 3. The menu does not support tiered captions. In your example above, you've= got "Configuration:" as a header for the remaining four options. That head= er would have to be printed manually in fourth (e.g., ``: cap ( X Y -- ) at= -xy ." Configuration:" ; 4 17 cap'') Numbers 2 and 3 are easy enough to overcome, but there's currently strong m= otivation to keep the menu recognizable and "in the same order" for long-ti= me users. Given said motivation in-addition to the only two major short-com= ings of your proposal: - The two menus have overlapping numbers - The menu system does not support multiple (separate/simultaneous) menus I would like to see general consensus from the community for separating the= items before moving ahead with such a non-trivial change. I thank you for your suggestion and appreciate the effort you put into it. --=20 Cheers, Devin >=20 > At 2011-05-05 16:20:43=EF=BC=8C"Devin Teske" wrote: >=20 > >Hello fellow -hackers, > > > >I'm so very proud to offer the latest update to my new boot loader menu = -- version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. > > > >It took some work and a few days, but I got it! Have a look below for si= x different displays (three different scenarios -- i386 w/ ACPI, i386 w/o A= CPI, and non-i386 -- each in both B&W and Color). > > > >Running on i386-compatible hardware supporting ACPI: > >B&W (standard): http://twitpic.com/4tlsin > >Color (loader_color=3DYES): http://twitpic.com/4tlt6l > > > >Running on i386-compatible hardware lacking ACPI support: > >B&W (standard): http://twitpic.com/4tltp0 > >Color (loader_color=3DYES): http://twitpic.com/4tlu5w > > > >Running on non-i386 hardware: > >B&W (standard): http://twitpic.com/4tluio > >Color (loader_color=3DYES): http://twitpic.com/4tluuy > > > >This version is feature complete with HEAD and backward compatible to 7.= 0-RELEASE. > > > >I do hope you like this latest version. You can get your update at: > > > >http://druidbsd.sourceforge.net/ > > or > >http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz > >--=20 > >Cheers, > >Devin Teske > > > >-> FUN STUFF <- > >-----BEGIN GEEK CODE BLOCK----- > >Version 3.12 > >GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW 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+++ z+++ > >------END GEEK CODE BLOCK------ > >http://www.geekcode.com/ > > > >-> LEGAL DISCLAIMER <- > >This message contains confidential and proprietary information > >of the sender, and is intended only for the person(s) to whom it > >is addressed. Any use, distribution, copying or disclosure by any > >other person is strictly prohibited. If you have received this > >message in error, please notify the e-mail sender immediately, > >and delete the original message without making a copy. > > > >-> END TRANSMISSION <- > > > >_____________ > > > >The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. > >_____________ > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >=20 >=20 _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 18:17:02 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D951106564A for ; Sun, 8 May 2011 18:17:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F249A8FC19 for ; Sun, 8 May 2011 18:17:01 +0000 (UTC) Received: by iwn33 with SMTP id 33so5403332iwn.13 for ; Sun, 08 May 2011 11:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :mime-version:content-type:content-disposition:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; bh=UX7Av2+YYP+QQf17pqOew04hdNVgcBk0glhbmXNY/fE=; b=lzlj0CfUis6eqmkWZ1hrLT74PudrHBu/g/NnN//EayEccKYoJ3SdX35OpCH00B1u94 TVGJOtfeJrs0yOYcbNNJ/HcBN6goKl2n2JeDl9wc2HJRS78YbCiiAYQTLKW1erPNTRqY szp7GukX1pAHzZIEGu5NIG3b7jifDcVUsZxfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; b=uRnME7Bx4iGHSDriYXStfH8fTRbqzF60jOR3zXNHwd/zRT3bzLeV2arGO/SeQg2wmM K/7mo1/V+f4Krope9xsMgYaEQmuaa20lgG9cFNp2LdpVC0MIm9WoDcsRgbPDbB0Tgnjs 4eqW62xaSAVJwmQdNJC2olHPj16xYgWYKRHXA= Received: by 10.42.1.74 with SMTP id 10mr5328649icf.86.1304877267270; Sun, 08 May 2011 10:54:27 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2268125iby.57.2011.05.08.10.54.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 10:54:22 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48HsJSO003540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 13:54:19 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48HsIIq003539; Sun, 8 May 2011 13:54:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 13:54:18 -0400 From: Jason Hellenthal To: hackers@FreeBSD.org, stable@FreeBSD.org, Rick Macklem Message-ID: <20110508175418.GA3527@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Subject: test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 18:17:02 -0000 hackers, Test -- Regards, (jhell) Jason Hellenthal From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 18:19:14 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F81106566C for ; Sun, 8 May 2011 18:19:14 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC338FC15 for ; Sun, 8 May 2011 18:19:14 +0000 (UTC) Received: by iwn33 with SMTP id 33so5404434iwn.13 for ; Sun, 08 May 2011 11:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=tRMMb5oiMD9lDNIi0keVoAcV82bPPns5Izhjk3FYaQE=; b=cw2ZIF6f1dFkMfrcnVVGtFMtB629spsY4+f1S323WAtoEmMhPQUqjHHgHoTHkAcb/P 5zYHfaTCUhDdbmBUffkFtFNUvCdXuOTMKzzcB+oO5iMQ/kbmRV6jdpyYnn6Sqfsv3Ed3 nSc/tJk6ySDCHZCnJEGumFlgypXmbxVpGfsFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=g0BEWxRfEWZGbCa/BY0ppbkPPbuLuk9JcCVj468OKApVihAONTgkho4KypH2Jb3xSA XsZTRmT3aP3+84GoFEWTPXoiasS2585sHxAZnyEv6B1hqZJEMqxAJI3xp4TojTy75cKi soMig2BYhQSx1C1Im572lhJ7sF+ACOx4vKmWc= Received: by 10.42.223.4 with SMTP id ii4mr1658912icb.132.1304877392486; Sun, 08 May 2011 10:56:32 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id xe5sm2076852icb.10.2011.05.08.10.56.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 10:56:31 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48HuSiv003716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 13:56:28 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48HuRZh003715; Sun, 8 May 2011 13:56:27 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 13:56:26 -0400 From: Jason Hellenthal To: hackers@FreeBSD.org, stable@FreeBSD.org, Rick Macklem Message-ID: <20110508175626.GB3527@DataIX.net> References: <20110508175418.GA3527@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110508175418.GA3527@DataIX.net> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Subject: Re: test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 18:19:14 -0000 hackers, On Sun, May 08, 2011 at 01:54:18PM -0400, Jason Hellenthal wrote: > > hackers, > > Test > My appologies. this message was never supposed to leave the outbox. Instead of hitting one key I hit another. Please disregard. Thanks. -- Regards, (jhell) Jason Hellenthal From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 19:13:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D5D106564A; Sun, 8 May 2011 19:13:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA2AD8FC0A; Sun, 8 May 2011 19:13:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so5480542iyj.13 for ; Sun, 08 May 2011 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :reply-to:mime-version:content-type:content-disposition :x-openpgp-key-id:x-openpgp-key-fingerprint:x-openpgp-key-url; bh=oCS9kbjB84EwxUSOi2uPIJRMOVm/u+Tom1oJo5h3ZwU=; b=B8WQH+jSLbuewH0zcxA7FZGpx+SQ2cTk/xQI4vum+MxGzR3B/97f76cmhugimVK7Fm AqJCom5i/cE9mbT0oAuK3kcnOvfAA5p8PrXybMl2VOIFv3bU9uFGsrERPj3yNnSKrldF Ud+pGWhAjzKycvWd9L04baTt4DciM+yPlxMmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=rh7ZMV1S4wV/a6VCvVzD3SvCx/BpeV6fth0srGhLO+N9m3gs25+It69RQMXsRBvVPj YwCPHRRTjQXgR/RAZ6s+iwAVpi5gvtJ0aSP7B5RzxUohCfO9N76c/+A3UX17geMHKWJF qpJKlmdfqRadTrpFT8TEYoPT01GACC4MZIiW4= Received: by 10.42.134.70 with SMTP id k6mr5286097ict.488.1304882021199; Sun, 08 May 2011 12:13:41 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2297255iby.6.2011.05.08.12.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 12:13:40 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48JDb5F006840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 15:13:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48JDagU006839; Sun, 8 May 2011 15:13:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 15:13:36 -0400 From: Jason Hellenthal To: freebsd-rc@freebsd.org Message-ID: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-rc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 19:13:42 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable List, - Please reply-to freebsd-rc@freebsd.org Recently I have been going over some changes in the configurations that=20 are possible with the rc subsystem and to my dismay I have found some=20 inconsistencies with in particular the way rc.conf.d directory is=20 processed and the arguments that are supplied to load_rc_config so I have= =20 patched it up... Let me explain: As determined by rc.subr load_rc_config, config's from=20 rc.conf.d are loaded by the scripts $name as an argument to load_rc_config= =20 and thus only the name being parsed is is available to be used in the=20 rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as= =20 the user has no direct way to know that a variable used by nfsd is also=20 needed by mountd or the same for various other scripts in the rc.d=20 directory. At this time these config's are explained to be available for=20 the user to utilize by rc.conf(5) but yet without much knowledge of the=20 inner workings of the rc subsystem it would be quite the feat to do. The attachment[1] keeps this functionality the same while introducing a=20 more convenient approach for the user to modularize their configuration=20 however they see fit within a couple constraints that work very well.=20 What does it do ?: As stated above, current functionality is undisturbed=20 while allowing the user to create config's by any name they so desire as=20 long as it has an extension of ".conf", also introducing the ability to=20 turn a configuration file off by using chmod(1). You can turn nfsc1.conf off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf Why ? Simple. How many times have you been bitten by disabling something=20 in the rc.conf file and left to discover what you just disabled was also=20 used by another daemon but that daemon is now not starting ? This is a way= =20 to virtualize your configuration allowing you to add multiple _enable=3D=20 lines to different configurations for different roles. For instance=20 rpcbind is used by both samba and nfs*. With this you can add=20 rpcbind_enable to both a configuration for samba and nfs and when you=20 disable one service you know that you have not disabled a dependent for=20 another. This is a small addition that fixes currently broken undesirable aspects=20 of the configuration system that deals with the rc.conf.d directory with a= =20 SysV style init approach that is just as flexible. This should apply=20 cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback= =20 has been received Ill update the manual page with any suggestions=20 regenerate the patch to accommodate and file a PR. 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Thanks --=20 Regards, (jhell) Jason Hellenthal --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxutfAAoJEJBXh4mJ2FR+anYH/jwyA3ifRH5QAivOkYcj3bSD 4jQCZB8FLDT1U7jE9hBk+YprFdkjBi+bDSPrbNYL3cOohvrVuAziB9VG811IhaRE //A9krdIy7QxXdkDFhkmP5F+z0wcmKoriFcO7onsDKVAqGjgyv+YyW+EohLjy283 rUAAmlgmlUSqcdAFNh8mJzNFDtcO9rqcXC1GVIGMY5wqoDLVQdkLwXrlmvPZc9eA Fz3++ZBPq0orRCjQDeP2h+rnAtssgBTXxaZhIM6tyS8aMBbOgl2XSaT5i5w7Soa5 8OButlT1RQ5TinqMt7ebXB07ycabgmFFLIK2JYPKS6Vp+zYOSYKlf9bO2B0dmMk= =zfmQ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 20:46:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5B7106566B for ; Sun, 8 May 2011 20:46:11 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 124ED8FC12 for ; Sun, 8 May 2011 20:46:10 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p48Kjwhc002118; Sun, 8 May 2011 15:45:58 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 15:45:59 -0500 Received: from SBHFISLTCGW07.FNFIS.COM ([10.132.248.135]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 15:45:58 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW07.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 15:45:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: <20110508211344.00006754@unknown> Date: Sun, 8 May 2011 13:45:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD48B80-1280-4DF0-B383-B4134E6EF2DA@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> <20110508211344.00006754@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 20:45:57.0996 (UTC) FILETIME=[EEE7EAC0:01CC0DC0] Cc: FreeBSD Hackers , =?iso-8859-1?B?5YWw5riF?= Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 20:46:11 -0000 On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: > On Sun, 8 May 2011 10:48:55 -0700 Devin Teske wrote: >=20 >> I would like to see general consensus from the community for >> separating the items before moving ahead with such a non-trivial >> change. >=20 > IMO: > - I agree that there are two different types of actions > - having 2 distinct blocks looks like a good idea to me > (I didn't had a look at the code, if you only have the text > in the variables and the numbers get added automatically, > maybe you can add variables for inbetween items which > are pure text and do not get a number, and they are not > displayed if the variable is empty) > - I do not think that we need two different namespaces here > -> reorder the items, use incrementing numbers no matter > which type it is (ACPI would be number 4 in the example then) All-in-all, I love the suggestion. A few notes: - I also agree that there are two different types of actions - Significant changes would need to be made. - I'd like to take the gradual approach - You're right, it could be done without two different namespaces However, there's one very important fact... The current menu is "numbers only" which means that people that use the men= u often will be impacted in a non-trivial way if we re-order the numbers. The gradual approach would have us accept a new menu (such as loader_menu-1= .4) that enables the use of hotkeys. Get people used to using the hotkeys f= or awhile before re-ording (or perhaps even taking-away) the numbers. What do you think of the gradual approach? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 19:14:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D105610658BE for ; Sun, 8 May 2011 19:14:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8E05D8FC08 for ; Sun, 8 May 2011 19:14:00 +0000 (UTC) Received: from outgoing.leidinger.net (p5B157F01.dip.t-dialin.net [91.21.127.1]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CC2BB844015; Sun, 8 May 2011 21:13:47 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 2CADE1246; Sun, 8 May 2011 21:13:45 +0200 (CEST) Date: Sun, 8 May 2011 21:13:44 +0200 From: Alexander Leidinger To: Devin Teske Message-ID: <20110508211344.00006754@unknown> In-Reply-To: <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CC2BB844015.A0972 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1305486828.17442@3+m+guqs84P/nWUqXaMk4Q X-EBL-Spam-Status: No X-Mailman-Approved-At: Mon, 09 May 2011 00:04:09 +0000 Cc: FreeBSD Hackers , =?ISO-8859-1?Q?=E5=85=B0=E6=B8=85?= Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 19:14:00 -0000 On Sun, 8 May 2011 10:48:55 -0700 Devin Teske wrote: > I would like to see general consensus from the community for > separating the items before moving ahead with such a non-trivial > change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here -> reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 00:16:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 684D3106564A for ; Mon, 9 May 2011 00:16:28 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 121698FC19 for ; Mon, 9 May 2011 00:16:28 +0000 (UTC) Received: (qmail 8333 invoked by uid 0); 9 May 2011 00:16:26 -0000 Received: from 67.206.163.119 by rms-us004.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 09 May 2011 00:16:24 +0000 From: "Dieter BSD" Message-ID: <20110509001626.50270@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: DVe1bcdy3zOlNR3dAHAhfAl+IGRvb4Dd Subject: Re: [RELEASE] New Boot-Loader Menu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 00:16:28 -0000 > There's really only room for one or two more menu items. Perhaps some items could be moved to a 2nd level menu? 1) boot multiuser mode ( default ) 2) boot single user mode 3) menu to set boot options 4) help >>>> Would be nice: a fix for having to lean on a key autorepeating >>>> for a couple seconds. >>> >>> Could you explain? I don't follow. >> >> On my Tyan Tomcat k8e 2865, just entering the number rarely if >> ever works. I have to either repeatedly bang away at the key or >> hold it down, letting the RS-232 terminal do the autorepeat thing, >> while hoping that it notices before the timer runs out. > > Is that with the current code that's in CVS? I'd love for you to > try my code on that hardware. One of the things that I worked on > in the very beginning was the responsiveness. That's with 6.x, 7,x and 8.x, currently running 8.2.  I haven't looked to see if anything has changed in CVS since 8.2.  I'll try your code, but I can't promise when.  I'm swamped at the moment and windows when the machine is free keep getting smaller and less frequent. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 00:47:23 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D700C106566C; Mon, 9 May 2011 00:47:23 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 63BA68FC13; Mon, 9 May 2011 00:47:23 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 64FCA14E53FD; Mon, 9 May 2011 02:29:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4MrBgZFPcIzp; Mon, 9 May 2011 02:29:12 +0200 (CEST) Received: from [193.137.158.228] (unknown [193.137.158.228]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id C66D514E53EF; Mon, 9 May 2011 02:29:11 +0200 (CEST) Message-ID: <4DC7356C.20905@kovesdan.org> Date: Mon, 09 May 2011 01:29:32 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 May 2011 00:50:42 +0000 Cc: "Pedro F. Giffuni" , Brooks Davis Subject: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 00:47:24 -0000 Hi Folks, I've been given the opportunity to work in GSoC 2011 to replace our base regex library with a more modern one and given that the regex code is something essential probably there are lots of interested parties so I decided to open a thread here about my plans and the approach that I propose. My wiki page is here, you can also take a look at it: http://wiki.freebsd.org/G%C3%A1borSoC2011 So let's see what this project is about... First some background information. Why to replace? - it is not efficient - it does not support wide characters - it comes from old and unmaintained vendor code What to use instead? There are some free implementations around but not all of the suit our needs. - PCRE is not POSIX regex, it only has a POSIX interface but actually the regex syntax is not the same - Oniguruma is slooooooooooooow - The Plan9 implementation doesn't support full POSIX regexes - TRE is BSD-licensed, fast, supports wchar, well-documented and still actively maintained, so it is the best candidate Tasks to complete (in priority order) 1, Replace the libc code with TRE code. Should be quite straightforward given that TRE is quite mature and has good POSIX-compliance. At the moment I'm already working on this. So far, I've discovered two differences from our current implementation - It accepts leaving at the minimum repetition count in curly brackets and inferres 0 instead of them. E.g. {,8} is equivalent to {0,8} and {,} is equivalent to {0,}. I think it won't be a problem because it is more permissive than our current implementation so the supported expressions are a superset of the current ones not a subset. - It doesn't provide the REG_STARTEND macro, which is our non-POSIX extension. Still, it is useful and easy to implement so it is not a problem either. Now I'm working on this little feature and on building a libc with TRE. After that I'll publish a patch for testing and will also ask portmgr to run it on the cluster. 2, Optimizations for matching with a fixed pattern heuristic Fixed string matching is algorithmically much cheaper than regex. Some time ago the GNU grep author was so kind to me that he provided lots of valuable comments while GNU grep is fast and one of those was this heuristical matching. You can see that mail here: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019358.html Although TRE has some alternative interfaces to match with an explicitly specified length instead of using NUL-terminated strings, the performance has to be measured and if it's not efficient enough, I plan to implement such optimizations. I don't want to put them in BSD grep directly because I find such optiizations valuable for other regex users. First, I was thinking of putting it into TRE but now I consider a better solution building a small library, libregexutils or such. It would decouple this optimization from the vendor code, making it easier to deal with future updates and in case for some reason in the far future we decide again to replace our regex library, this would still work on top of another one. 3, Adding support for GNU-specific permissive regex syntax GNU grep accepts regexes that are invalid in POSIX, like [a|]. This is necessary for grep and diff in the base system. If we don't have them we can never trow out the GNU regex implementation. However, we should not make them default, so I'm thinking of implementing them somewhere else, e.g. in the previously mentioned library. So far, these are the plans, please comments if you have something in your mind about it. Gabor From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 01:12:45 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD2D106566B for ; Mon, 9 May 2011 01:12:45 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm7-vm0.bullet.mail.sp2.yahoo.com (nm7-vm0.bullet.mail.sp2.yahoo.com [98.139.91.192]) by mx1.freebsd.org (Postfix) with SMTP id E20E18FC14 for ; Mon, 9 May 2011 01:12:44 +0000 (UTC) Received: from [98.139.91.66] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 01:12:44 -0000 Received: from [98.139.91.48] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 01:12:44 -0000 Received: from [127.0.0.1] by omp1048.mail.sp2.yahoo.com with NNFMP; 09 May 2011 01:12:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 545069.84692.bm@omp1048.mail.sp2.yahoo.com Received: (qmail 33013 invoked by uid 60001); 9 May 2011 01:12:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304903564; bh=/oKJJpgUjaqdXsGx+JU/Dhe3RDveBwvGKHtEr2wbmhM=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ubhe4nesRL+/M/7VIwc/3HFKFm/Qh7lvaR6szxA3+e/WWGUGTX9GLSfy7sa1YZqOkmB6HjBImNfbhXW8Bsg3ly9L2iIs2N7melXNdZvxVdF3M7pYIPL0Fl89YpxV4m5lFTJT+ydktRalqXfaefO2Q/FKB24YkAIifUr9sEUbltI= Message-ID: <219007.22756.qm@web113513.mail.gq1.yahoo.com> X-YMail-OSG: 8GZS2yYVM1mQnlYzV2VsxdlydW8UzKDjnQ7IcgESYuFaV66 v6gAFTErFH9wDGBOGMi5S56AaDm5m7mEwCMscf52Wt57jTAMYlmquJAw3rc7 vygirAEuO2aXAsCe8VODcmRY7PHf3ELYp9xKIosUhCKSOcHvEXXw0j7XaQNf Jokj2cvPmum.PPCMdkdZqAXL4AcxNMIJJMfcbcgylPzoZi_N8aaY96Tr.uJq Im5H3CvHpqOmDTAxab0bnwqjZMrYndixszOOkYBhfjTzDtnq3dw5JUB6Mlla lWi6Einpajy1oo9DnazxzrdA8MlIhAMZaFO_LCpkhmek7sGYwY8XPtfCxZMZ K0VPYdIOu0UCg.9.d3O0zMO.SHHaBzHYenXAyA9OtQueqOwhGkIWXqmfIvKi w5GwEQiYRBtEBAng- Received: from [200.118.158.177] by web113513.mail.gq1.yahoo.com via HTTP; Sun, 08 May 2011 18:12:44 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.110.299900 Date: Sun, 8 May 2011 18:12:44 -0700 (PDT) From: "Pedro F. Giffuni" To: hackers@FreeBSD.org, Gabor Kovesdan In-Reply-To: <4DC7356C.20905@kovesdan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 09 May 2011 01:19:42 +0000 Cc: Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:12:45 -0000 Hello; Thanks Gabor for this cool project! --- On Sun, 5/8/11, Gabor Kovesdan wrote: ... > - It doesn't provide the REG_STARTEND macro, which is our > non-POSIX extension. Still, it is useful and easy to > implement so it is not a problem either. Our sed requires REG_STARTEND (the illumos guys noted so when they ported our sed). While on this you should also look at bin/153257 and check if TRE supports the sysv legacy delimiters. FWIW, the now defunct lang/gpc used those delimiters to distinguish between our sed and GNU sed. There are still more than 20 ports that depend on gsed. > Now I'm working on this little feature and on building a > libc with TRE. After that I'll publish a patch for testing > and will also ask portmgr to run it on the cluster. > It may be interesting, although unnecessarily risky, to see if diff can also use libtre (it uses GNU regex now), but you will probably want to see this as a future step. (NEVERMIND.. you explained this right ahead ;) ) > > 3, Adding support for GNU-specific permissive regex syntax > GNU grep accepts regexes that are invalid in POSIX, like > [a|]. This is necessary for grep and diff in the base > system. If we don't have them we can never trow out the GNU > regex implementation. However, we should not make them > default, so I'm thinking of implementing them somewhere > else, e.g. in the previously mentioned library. > > So far, these are the plans, please comments if you have > something in your mind about it. > Sounds good! Pedro. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 01:32:25 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB0C1065670; Mon, 9 May 2011 01:32:25 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 07C9B8FC08; Mon, 9 May 2011 01:32:20 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 5455CB827; Sun, 8 May 2011 18:17:09 -0700 (PDT) To: Gabor Kovesdan In-reply-to: Your message of "Mon, 09 May 2011 01:29:32 BST." <4DC7356C.20905@kovesdan.org> References: <4DC7356C.20905@kovesdan.org> Comments: In-reply-to Gabor Kovesdan message dated "Mon, 09 May 2011 01:29:32 +0100." Date: Sun, 08 May 2011 18:17:09 -0700 From: Bakul Shah Message-Id: <20110509011709.5455CB827@mail.bitblocks.com> Cc: "Pedro F. Giffuni" , hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:32:25 -0000 As per the following URLs re2 is much faster than TRE (on the benchmarks they ran): http://lh3lh3.users.sourceforge.net/reb.shtml http://sljit.sourceforge.net/regex_perf.html re2 is in C++ & has a PCRE API, while TRE is in C & has a POSIX API. Both have BSD copyright. Is it worth considering making re2 posix compliant? From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 01:36:53 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57A50106564A; Mon, 9 May 2011 01:36:53 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 141E68FC0A; Mon, 9 May 2011 01:36:52 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id A531714E53FB; Mon, 9 May 2011 03:36:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cy773qUKgwlb; Mon, 9 May 2011 03:36:49 +0200 (CEST) Received: from [193.137.158.228] (unknown [193.137.158.228]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AE40014E53EF; Mon, 9 May 2011 03:36:48 +0200 (CEST) Message-ID: <4DC74546.1060902@kovesdan.org> Date: Mon, 09 May 2011 02:37:10 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bakul Shah References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> In-Reply-To: <20110509011709.5455CB827@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 May 2011 01:48:59 +0000 Cc: "Pedro F. Giffuni" , hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:36:53 -0000 Em 09-05-2011 02:17, Bakul Shah escreveu: > As per the following URLs re2 is much faster than TRE (on the > benchmarks they ran): > > http://lh3lh3.users.sourceforge.net/reb.shtml > http://sljit.sourceforge.net/regex_perf.html > > re2 is in C++& has a PCRE API, while TRE is in C& has a > POSIX API. Both have BSD copyright. Is it worth considering > making re2 posix compliant? Is it wchar-clean and is it actively maintained? C++ is quite anticipated for the base system and I'm not very skilled in it so atm I couldn't promise to use re2 instead of TRE. And anyway, can C++ go into libc? According to POSIX, the regex code has to be there. But let's see what others say... If we happen to use re2 later, my extensions that I talked about in points 2, and 3, would still be useful. Anyway, according to some earlier vague measures, TRE seems to be slower in small matching tasks but scales well. These tests seem to compare only short runs with the same regex. It should be seem how they compare e.g. if you grep the whole ports tree with the same pattern. If the matching scales well once the pattern is compiled, that's more important than the overall result for such short tasks, imho. Gabor From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 01:49:39 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E60B1065701; Mon, 9 May 2011 01:49:39 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8356E8FC17; Mon, 9 May 2011 01:49:39 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id EE292B827; Sun, 8 May 2011 18:49:38 -0700 (PDT) To: Gabor Kovesdan In-reply-to: Your message of "Mon, 09 May 2011 02:37:10 BST." <4DC74546.1060902@kovesdan.org> References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> Comments: In-reply-to Gabor Kovesdan message dated "Mon, 09 May 2011 02:37:10 +0100." Date: Sun, 08 May 2011 18:49:38 -0700 From: Bakul Shah Message-Id: <20110509014938.EE292B827@mail.bitblocks.com> Cc: "Pedro F. Giffuni" , hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:49:39 -0000 On Mon, 09 May 2011 02:37:10 BST Gabor Kovesdan wrote: > Em 09-05-2011 02:17, Bakul Shah escreveu: > > As per the following URLs re2 is much faster than TRE (on the > > benchmarks they ran): > > > > http://lh3lh3.users.sourceforge.net/reb.shtml > > http://sljit.sourceforge.net/regex_perf.html > > > > re2 is in C++& has a PCRE API, while TRE is in C& has a > > POSIX API. Both have BSD copyright. Is it worth considering > > making re2 posix compliant? > Is it wchar-clean and is it actively maintained? C++ is quite > anticipated for the base system and I'm not very skilled in it so atm I > couldn't promise to use re2 instead of TRE. And anyway, can C++ go into > libc? According to POSIX, the regex code has to be there. But let's see > what others say... If we happen to use re2 later, my extensions that I > talked about in points 2, and 3, would still be useful. > > Anyway, according to some earlier vague measures, TRE seems to be slower > in small matching tasks but scales well. These tests seem to compare > only short runs with the same regex. It should be seem how they compare > e.g. if you grep the whole ports tree with the same pattern. If the > matching scales well once the pattern is compiled, that's more important > than the overall result for such short tasks, imho. re2 is certainly maintained. Don't know about whcar cleanliness. See http://code.google.com/p/re2/ Also check out Russ Cox's excellent articles on implementing it http://swtch.com/~rsc/regexp/ and this: http://google-opensource.blogspot.com/2010/03/re2-principled-approach-to-regular.html C++ may be an impediment for it to go into libc but one can certainly put a C interface on a C++ library. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 03:03:17 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935F1106566B; Mon, 9 May 2011 03:03:17 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E33038FC15; Mon, 9 May 2011 03:03:16 +0000 (UTC) Received: by fxm11 with SMTP id 11so4710676fxm.13 for ; Sun, 08 May 2011 20:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jaUvqWT+LTs9ZdYRRSACSn0zTicMglDmu1E1kqC5psE=; b=iKpJ4Wg5xAYLrRZKFiRfCQN9l8vTVpoYyv2F5n2/MLKZUN7PaR1srUPRjBGWVBLlTX mwW+AVMDjuoKMnm1Z68n/nWewL2azFdpQ8pNgP2Gle4amHC6n/u6nN2o05NzkjcSJ78Z GeHPnbcBi0BIH5Xc394LD8h70l1TRTnIAxWck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M4X2Lbw7CU2o7e9n6R7tXcZR1bAKF201Ubs1NdlaoI/jF/Ft3sDdPn+xCTZh3hrbJj xnWTFfxkAYebaxsvD/PiBVrAh7MNbs7MOXVdqhidtM65ck4QCr3RH5SmEiUg4vbn6syG mjqmljXse15b2bR9SOLNFDG4f3AFeavft+/tw= MIME-Version: 1.0 Received: by 10.223.27.18 with SMTP id g18mr2662121fac.52.1304908504246; Sun, 08 May 2011 19:35:04 -0700 (PDT) Received: by 10.223.96.142 with HTTP; Sun, 8 May 2011 19:35:04 -0700 (PDT) In-Reply-To: <20110509014938.EE292B827@mail.bitblocks.com> References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> <20110509014938.EE292B827@mail.bitblocks.com> Date: Sun, 8 May 2011 21:35:04 -0500 Message-ID: From: Zhihao Yuan To: Bakul Shah Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@freebsd.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 03:03:17 -0000 On Sun, May 8, 2011 at 8:49 PM, Bakul Shah wrote: > On Mon, 09 May 2011 02:37:10 BST Gabor Kovesdan =C2= =A0wrote: >> Em 09-05-2011 02:17, Bakul Shah escreveu: >> > As per the following URLs re2 is much faster than TRE (on the >> > benchmarks they ran): >> > >> > http://lh3lh3.users.sourceforge.net/reb.shtml >> > http://sljit.sourceforge.net/regex_perf.html >> > >> > re2 is in C++& =C2=A0has a PCRE API, while TRE is in C& =C2=A0has a >> > POSIX API. =C2=A0Both have BSD copyright. Is it worth considering >> > making re2 posix compliant? >> Is it wchar-clean and is it actively maintained? C++ is quite >> anticipated for the base system and I'm not very skilled in it so atm I >> couldn't promise to use re2 instead of TRE. And anyway, can C++ go into >> libc? According to POSIX, the regex code has to be there. But let's see >> what others say... If we happen to use re2 later, my extensions that I >> talked about in points 2, and 3, would still be useful. >> >> Anyway, according to some earlier vague measures, TRE seems to be slower >> in small matching tasks but scales well. These tests seem to compare >> only short runs with the same regex. It should be seem how they compare >> e.g. if you grep the whole ports tree with the same pattern. If the >> matching scales well once the pattern is compiled, that's more important >> than the overall result for such short tasks, imho. > > re2 is certainly maintained. Don't know about whcar cleanliness. > See > =C2=A0 =C2=A0http://code.google.com/p/re2/ > Also check out Russ Cox's excellent articles on implementing it > =C2=A0 =C2=A0http://swtch.com/~rsc/regexp/ > and this: > =C2=A0 =C2=A0http://google-opensource.blogspot.com/2010/03/re2-principled= -approach-to-regular.html > > C++ may be an impediment for it to go into libc but one can > certainly put a C interface on a C++ library. 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), but it does not allow you to change the mode. http://code.google.com/p/re2/source/browse/re2/re2.h 2. It focuses on speed and features, not stability and standardization. 3. It uses C++. We seldom accepts C++ code in base system, and does not accept it in libc. So, as far as I concerned, re2 is good as a re engine in some applications, but may not fit the requirements for a regex in libc. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 04:31:01 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FFEC106564A; Mon, 9 May 2011 04:31:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E2F928FC16; Mon, 9 May 2011 04:31:00 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:90f9:35f2:eafc:f15c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 7A4E84AC1C; Mon, 9 May 2011 08:30:58 +0400 (MSD) Date: Mon, 9 May 2011 08:30:57 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1164564191.20110509083057@serebryakov.spb.ru> To: Bakul Shah In-Reply-To: <20110509011709.5455CB827@mail.bitblocks.com> References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 04:31:01 -0000 Hello, Bakul. You wrote 9 =EC=E0=FF 2011 =E3., 5:17:09: > As per the following URLs re2 is much faster than TRE (on the > benchmarks they ran): > http://lh3lh3.users.sourceforge.net/reb.shtml > http://sljit.sourceforge.net/regex_perf.html re2 is much faster at price of memory. I don't remember details now, but I've found (simple) situations when re2 consumes a HUGE amount of memory (read: hundreds of megabytes). It work faster than tre, yes. If you have this memory to RE engine alone. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 05:21:45 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F1311065670; Mon, 9 May 2011 05:21:45 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 10B5C8FC0C; Mon, 9 May 2011 05:21:44 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 65DD7B827; Sun, 8 May 2011 22:21:44 -0700 (PDT) To: lev@FreeBSD.org In-reply-to: Your message of "Mon, 09 May 2011 08:30:57 +0400." <1164564191.20110509083057@serebryakov.spb.ru> References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <1164564191.20110509083057@serebryakov.spb.ru> Comments: In-reply-to Lev Serebryakov message dated "Mon, 09 May 2011 08:30:57 +0400." Date: Sun, 08 May 2011 22:21:44 -0700 From: Bakul Shah Message-Id: <20110509052144.65DD7B827@mail.bitblocks.com> Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 05:21:45 -0000 On Mon, 09 May 2011 08:30:57 +0400 Lev Serebryakov wrote: > Hello, Bakul. > You wrote 9 =EC=E0=FF 2011 =E3., 5:17:09: > > > As per the following URLs re2 is much faster than TRE (on the > > benchmarks they ran): > > > http://lh3lh3.users.sourceforge.net/reb.shtml > > http://sljit.sourceforge.net/regex_perf.html > re2 is much faster at price of memory. I don't remember details now, > but I've found (simple) situations when re2 consumes a HUGE amount of > memory (read: hundreds of megabytes). It work faster than tre, yes. If > you have this memory to RE engine alone. As per http://swtch.com/~rsc/regexp/regexp3.html RE2 requires about 10 KB per regexp, in contrast to PCRE's half a KB. This is not excessive in this day and age. But 100s of megabytes sounds very strange.... I'd appreciate a reference to an actual example (and I am sure so would the author of re2). But I do not want to defend re2 here. My intent was to just make sure re2 was at least considered. Mainly because it was actually quite surprising to see TRE is 10 to 45 times slower than re2! From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 06:12:00 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95BF7106564A; Mon, 9 May 2011 06:12:00 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1E58FC13; Mon, 9 May 2011 06:12:00 +0000 (UTC) Received: by pxi11 with SMTP id 11so4090193pxi.7 for ; Sun, 08 May 2011 23:12:00 -0700 (PDT) Received: by 10.142.121.41 with SMTP id t41mr3747496wfc.358.1304919888547; Sun, 08 May 2011 22:44:48 -0700 (PDT) Received: from [192.168.2.119] (99-74-169-43.lightspeed.sntcca.sbcglobal.net [99.74.169.43]) by mx.google.com with ESMTPS id x11sm7690158wfd.1.2011.05.08.22.44.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 22:44:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <4DC7356C.20905@kovesdan.org> Date: Sun, 8 May 2011 22:44:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC7356C.20905@kovesdan.org> To: Gabor Kovesdan X-Mailer: Apple Mail (2.1084) Cc: "Pedro F. Giffuni" , hackers@freebsd.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 06:12:00 -0000 On May 8, 2011, at 5:29 PM, Gabor Kovesdan wrote: > 2, Optimizations for matching with a fixed pattern heuristic > ... First, I was thinking of putting it into TRE but now I consider a = better solution building a small library, libregexutils or such. It = would decouple this optimization from the vendor code, ... Have you asked the TRE maintainers if they would accept this change? If they would, then getting this change into TRE would benefit a lot = more people than just FreeBSD's libc. (BTW, I agree that C++ in libc is a bad idea.) Tim From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 06:13:35 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C531065672; Mon, 9 May 2011 06:13:35 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 160178FC17; Mon, 9 May 2011 06:13:34 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A62EAB827; Sun, 8 May 2011 23:13:34 -0700 (PDT) To: Zhihao Yuan In-reply-to: Your message of "Sun, 08 May 2011 21:35:04 CDT." References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> <20110509014938.EE292B827@mail.bitblocks.com> Comments: In-reply-to Zhihao Yuan message dated "Sun, 08 May 2011 21:35:04 -0500." Date: Sun, 08 May 2011 23:13:34 -0700 From: Bakul Shah Message-Id: <20110509061334.A62EAB827@mail.bitblocks.com> Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@freebsd.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 06:13:35 -0000 On Sun, 08 May 2011 21:35:04 CDT Zhihao Yuan wrote: > 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), > but it does not allow you to change the mode. > http://code.google.com/p/re2/source/browse/re2/re2.h The mode is decided when an RE2 object is instantiated so this is ok. You can certainly instantiate multiple objects with different options if so desired. > 2. It focuses on speed and features, not stability and standardization. Look at the open issues. Seems stable enough to me. re2 has a posix only mode. It also does unicode. > 3. It uses C++. We seldom accepts C++ code in base system, and does > not accept it in libc. This is the show stopper. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 06:30:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB19106564A for ; Mon, 9 May 2011 06:30:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C85E8FC0C for ; Mon, 9 May 2011 06:30:23 +0000 (UTC) Received: by yxl31 with SMTP id 31so2128709yxl.13 for ; Sun, 08 May 2011 23:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fLIH5hp2/HtG4m22V7Y+rIUafiOIpKE0OoQ6gA6T51o=; b=NdequTnw8OosD4fKal1G3UmLHsuwAhOLrilvHYn6sPao/zEIcfLILAjfZFuyf2qlwE NWyvK4INd+/ZtvJs717RGsmxsGSduHRzkjNSDeVL+fBIJveP6DU6XmO2LHphc6gw3/QG hsacRW6SI9d2zkk1aho1gk0oEMHxXTotjvoeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QMkW+s8whCm7ll4qZR7iWl+aAJyR68kOKxZvLfDGs0h5lr+9VsnnGXkiTNoEfN+Kc0 zY+mxXJWraVxszBI0mmyANxZqeSRj+9IIXkuEQjY3V9+fRXT/gOe/Tdebe6YemMANikr ArHciZfHGSVe21oLEC/nBpyOwQ6bT68n/+Zck= MIME-Version: 1.0 Received: by 10.151.5.14 with SMTP id h14mr5350928ybi.182.1304922622665; Sun, 08 May 2011 23:30:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Sun, 8 May 2011 23:30:22 -0700 (PDT) In-Reply-To: <20110508131643.GA23650@alchemy.franken.de> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> Date: Mon, 9 May 2011 14:30:22 +0800 X-Google-Sender-Auth: 88tCoBu6kFoPMUWzwnVWWpEemj4 Message-ID: From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Damjan Marion Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 06:30:23 -0000 On 8 May 2011 21:16, Marius Strobl wrote: [snip] > Depends on what you understand by properly. One idea I particularly > like is to handle switch ports as pseudo-interfaces hanging off of the > the MAC driver parent roughly similar to vlan(4). That way you'd have > per port link status and could configure the media. The reason I like this is because I realise that these switch PHYs tend to have quite a bit of varying but useful functionality, that isn't just "multi-port single-VLAN switch PHY." Besides there being per-port status, there can also be per-port error/packet/byte counts, VLAN setups (tagged/untagged), QoS configuration, sometimes some L2 filtering and (even more creepy) sometimes L3 filtering/routing. They can sometimes hang off the MII bus, but ISTR datasheets which show they can hang off an SPI bus too. So although they can look like PHYs complete with the register layouts, there's extended commands to implement other features as well. There may even be more than one CPU ethernet port hooked up - I think the Routerstation Pro has both CPU GigE ports wired to the switch PHY and defaults to mapping port 1 -> arge0 and Port 2,3,4,5 -> arge1. I'd really appreciate it if someone were able to sit down, take the existing work done by Luiz and others and flesh out a bare minimum set of switch PHY drivers that configure them with some sensible defaults (rather than leaving it up to the boot firmware to do it for you) and have all of the interface/configuration glue in the kernel. As I said earlier, figuring out how to expose all the functionality - including per-port error counts and such - can come later. Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 09:36:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7011065674 for ; Mon, 9 May 2011 09:36:07 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id A9D588FC08 for ; Mon, 9 May 2011 09:36:07 +0000 (UTC) Received: from e-new.0x20.net (localhost [217.69.76.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 36C296A604B; Mon, 9 May 2011 11:19:03 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id p499J2Y9004528; Mon, 9 May 2011 11:19:02 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id p499J2A6003243; Mon, 9 May 2011 11:19:02 +0200 (CEST) (envelope-from lars) Date: Mon, 9 May 2011 11:19:02 +0200 From: Lars Engels To: Devin Teske Message-ID: <20110509091902.GR47109@e-new.0x20.net> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xJjS+Ds6jmpBvWv0" Content-Disposition: inline In-Reply-To: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 09 May 2011 11:05:06 +0000 Cc: FreeBSD Hackers Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 09:36:08 -0000 --xJjS+Ds6jmpBvWv0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: > Hello fellow -hackers, >=20 > I'm so very proud to offer the latest update to my new boot loader > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line > with HEAD. >=20 > It took some work and a few days, but I got it! Have a look below for > six different displays (three different scenarios -- i386 w/ ACPI, > i386 w/o ACPI, and non-i386 -- each in both B&W and Color). >=20 Hi Devin, PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD version. I.E. you can also set unset verbose mode and ACPI with it. Some days ago there was a proposal on a PC-BSD list to add an option to boot a different kernel if one is found in /boot. Would it be possible to addi this function to your boot menu? Or even better work together with Kris Moore so we don't have two solutions for the same task? Lars --xJjS+Ds6jmpBvWv0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3HsYYACgkQKc512sD3afhp6wCdE6Lum3ozQEp9Bi9XIjthUqQA RFMAoJ64dk0Sw0vZld255FGZ+SAwRVOu =9Bd7 -----END PGP SIGNATURE----- --xJjS+Ds6jmpBvWv0-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 17:42:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923EC1065670 for ; Mon, 9 May 2011 17:42:26 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5C27B8FC18 for ; Mon, 9 May 2011 17:42:26 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p49HgMYW007179; Mon, 9 May 2011 12:42:22 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 12:42:32 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:42:22 -0500 Received: from dtwin ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:42:20 -0500 From: "Devin Teske" To: "'Lars Engels'" References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <20110509091902.GR47109@e-new.0x20.net> In-Reply-To: <20110509091902.GR47109@e-new.0x20.net> Date: Mon, 9 May 2011 10:41:40 -0700 Organization: Vicor, Inc. Message-ID: <000601cc0e70$5e960dc0$1bc22940$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDz/r0NBVB67BiLX0QruoJxa2/nHQMRrLZrlhxOTYA= Content-Language: en-us X-OriginalArrivalTime: 09 May 2011 17:42:21.0901 (UTC) FILETIME=[7336F7D0:01CC0E70] Cc: 'FreeBSD Hackers' Subject: RE: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:42:26 -0000 > -----Original Message----- > From: Lars Engels [mailto:lars.engels@0x20.net] > Sent: Monday, May 09, 2011 2:19 AM > To: Devin Teske > Cc: FreeBSD Hackers > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 >=20 > On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: > > Hello fellow -hackers, > > > > I'm so very proud to offer the latest update to my new boot loader > > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line > > with HEAD. > > > > It took some work and a few days, but I got it! Have a look below for > > six different displays (three different scenarios -- i386 w/ ACPI, > > i386 w/o ACPI, and non-i386 -- each in both B&W and Color). > > >=20 > Hi Devin, >=20 > PC-BSD also has a slightly patched loader menu compared to the stock Free= BSD > version. Does PC-BSD have CVSweb that I can browse? Link? > I.E. you can also set unset verbose mode and ACPI with it. > Some days ago there was a proposal on a PC-BSD list to add an option to b= oot a > different kernel if one is found in /boot. > Would it be possible to addi this function to your boot menu? No need. The basic constructs are there already, we just need to expand on = them. Here's how I've implemented a hard-coded list of kernels to choose from for= our systems (to be implemented in /boot/menu.rc): \ Set kernel paths (see menu_caption[2] below) set kernel_prefix=3D"/kernels/" \ NOTE: We like to keep our kernels in `/kernels' set kernel[0]=3D"FIS-i386-8.1p1" set kernel[1]=3D"GENERIC-i386-8.1p1" set kernel_suffix=3D".kgz" \ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d \ Set default boot kernel set kernel=3D"${kernel_prefix}${kernel[0]}${kernel_suffix}" \ Initialize main menu constructs (variables are read by `menu.4th') set menu_caption[1]=3D"Boot [ENTER]" set menu_command[1]=3D"boot" set menu_caption[2][0]=3D"Kernel: ${kernel[0]} (1of2)" set menu_caption[2][1]=3D"Kernel: ${kernel[1]} (2of2)" set menu_caption[2]=3D"${menu_caption[2][0]}" set menu_command[2]=3D"cycle_kernel" \ ... rest of menu ... The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The `cycle_= kernel' command is a wrapper to the `cycle_menuitem' command (similar to ho= w `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers to = the `toggle_menuitem' command). Like the `toggle_menuitem' command, the `cy= cle_menuitem' command uses a system of internal state variables to track wh= ich menuitem text is to be displayed for that individual menuitem. Whereas = the `toggle_menuitem' command automatically toggles the text of a menuitem = between the `menu_caption[x]' and `toggled_text[x]' variables, the `cycle_m= enuitem' command automatically cycles through the `menu_caption[x][y]' vari= ables, cycling back to y=3D0 when it gets to an undefined `y' value. However, hard-coding an alternate kernel choice is something that I wouldn'= t condone for an actual release. Instead, what I would recommend is to dyna= mically allocate the kernel menu if/when multiple kernels are discovered/co= nfigured. That's something that is currently not coded (dynamic detection o= f kernels in /boot). > Or even better > work together with Kris Moore so we don't have two solutions for the same= task? I'd like to open a discussion with Kris Moore on how we could go about dete= cting additional kernels. Off the top of my head, here's a couple thoughts: a. We could test a battery of different kernel names (kernel, kernel.bak, k= ernel.orig, etc.) b. We could allow the user to set kernel1, kernel2, kernel3, etc. in loader= .conf(5) c. We could allow the user to set kernel=3D"kernel1;kernel2;kernel3;..." in= loader.conf(5) d. Some combination of the above. --=20 Devin P.S. I think it'd also be nice to someday offer the user a choice of bootin= g into a memory filesystem for rescue purposes. We've offered this to our u= sers for years with the following configuration: set root[0]=3D"" set root[1]=3D"rescue_mfsroot" set menu_caption[7][0]=3D"Root Image: Default (1of2)" set menu_caption[7][1]=3D"Root Image: Rescue (2of2)" set menu_caption[7]=3D"${menu_caption[7][0]}" set menu_command[7]=3D"cycle_root" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 19:27:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C59D6106566B for ; Mon, 9 May 2011 19:27:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4BC8FC0C for ; Mon, 9 May 2011 19:27:05 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155D47.dip.t-dialin.net [91.21.93.71]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 11A0F844015; Mon, 9 May 2011 21:26:49 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 2194F1256; Mon, 9 May 2011 21:26:46 +0200 (CEST) Date: Mon, 9 May 2011 21:26:44 +0200 From: Alexander Leidinger To: Devin Teske Message-ID: <20110509212644.000066ad@unknown> In-Reply-To: <7CD48B80-1280-4DF0-B383-B4134E6EF2DA@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> <20110508211344.00006754@unknown> <7CD48B80-1280-4DF0-B383-B4134E6EF2DA@vicor.com> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 11A0F844015.A3DE4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1305574011.62998@4wEcBzFk6WY5yNp0xfcDqA X-EBL-Spam-Status: No X-Mailman-Approved-At: Mon, 09 May 2011 19:30:58 +0000 Cc: FreeBSD Hackers , =?ISO-8859-1?Q?=E5=85=B0=E6=B8=85?= Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:27:05 -0000 On Sun, 8 May 2011 13:45:55 -0700 Devin Teske wrote: > On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: > > > On Sun, 8 May 2011 10:48:55 -0700 Devin Teske > > wrote: > > > >> I would like to see general consensus from the community for > >> separating the items before moving ahead with such a non-trivial > >> change. > > > > IMO: > > - I agree that there are two different types of actions > > - having 2 distinct blocks looks like a good idea to me > > (I didn't had a look at the code, if you only have the text > > in the variables and the numbers get added automatically, > > maybe you can add variables for inbetween items which > > are pure text and do not get a number, and they are not > > displayed if the variable is empty) > > - I do not think that we need two different namespaces here > > -> reorder the items, use incrementing numbers no matter > > which type it is (ACPI would be number 4 in the example then) > > > All-in-all, I love the suggestion. > > A few notes: > - I also agree that there are two different types of actions > - Significant changes would need to be made. > - I'd like to take the gradual approach > - You're right, it could be done without two different namespaces > > However, there's one very important fact... > > The current menu is "numbers only" which means that people that use > the menu often will be impacted in a non-trivial way if we re-order > the numbers. > > The gradual approach would have us accept a new menu (such as > loader_menu-1.4) that enables the use of hotkeys. Get people used to > using the hotkeys for awhile before re-ording (or perhaps even > taking-away) the numbers. > > What do you think of the gradual approach? If you want to spend some years... IMO it's either - change now or - no change, never ever or - change if special variable is set I do not think it is really an option to change it only for new installs but keep the numbers for installed ones as they are (if there is a way to do this). I also think that there will always be some people which never switch to hotkeys. FYI: I never got the numbers into my brain, I always use SPACE to pause and then read which number to press. This could be because I do not (re)boot systems much, but I expect/hope that there are more people which do the same. With the hotkeys this may change, as they are easy to associate with the English word for the action. I'm all for gradual improvements, but there are things which can not be done gradually. This usability improvement is one of the later ones IMO. If nobody complains that such a separation is very hard to get and that it is too hard to press SPACE and that the ordering of the new entries can only be provided by someone with a twisted brain, I would do it, as it looks like very good and better understandable usability improvement which should get new users (to FreeBSD but maybe not to the Unix way) to better get suited with FreeBSD. Maybe an explicit variable to set to go back to the old order if there are too much voices which tell it would violate POLA? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 22:04:52 2011 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16FE01065670; Mon, 9 May 2011 22:04:52 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id CDFA58FC1A; Mon, 9 May 2011 22:04:51 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p49LplTj018276; Mon, 9 May 2011 17:51:47 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p49Lpk9k018275; Mon, 9 May 2011 17:51:46 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 9 May 2011 17:51:46 -0400 From: David Schultz To: Bakul Shah Message-ID: <20110509215146.GA18135@zim.MIT.EDU> Mail-Followup-To: Bakul Shah , Zhihao Yuan , Gabor Kovesdan , "Pedro F. Giffuni" , hackers@freebsd.org, Brooks Davis References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> <20110509014938.EE292B827@mail.bitblocks.com> <20110509061334.A62EAB827@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110509061334.A62EAB827@mail.bitblocks.com> Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@FreeBSD.ORG, Brooks Davis , Zhihao Yuan Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 22:04:52 -0000 On Sun, May 08, 2011, Bakul Shah wrote: > On Sun, 08 May 2011 21:35:04 CDT Zhihao Yuan wrote: > > 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), > > but it does not allow you to change the mode. > > http://code.google.com/p/re2/source/browse/re2/re2.h > > The mode is decided when an RE2 object is instantiated so this > is ok. You can certainly instantiate multiple objects with > different options if so desired. > > > 2. It focuses on speed and features, not stability and standardization. > > Look at the open issues. Seems stable enough to me. re2 has a > posix only mode. It also does unicode. > > > 3. It uses C++. We seldom accepts C++ code in base system, and does > > not accept it in libc. > > This is the show stopper. Use of C++ is a clear show-stopper if it introduces new runtime requirements, e.g., dependencies on STL or exceptions. Aside from that, however, I can't think of any fundamental, technical reasons why a component of libc couldn't be written in C++. (Perhaps the toolchain maintainers could name some, and they'd be the best authority on the matter.) You can expect some resistance regardless, however, so make sure the technical merits of RE2 are worth the trouble. IIRC, some of the prior discussions on using more C++ in the base system got derailed by tangents on multiple inheritance, operator overloading, misfeatures of STL, and what subset of C++ ought to be considered kosher in FreeBSD. You don't have to get involved in any of that because you'd only be proposing to import a self-contained third-party library. From owner-freebsd-hackers@FreeBSD.ORG Mon May 9 22:28:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30DB1065670 for ; Mon, 9 May 2011 22:28:50 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B27798FC1D for ; Mon, 9 May 2011 22:28:50 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id p49MSdhB046662; Mon, 9 May 2011 16:28:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id p49MSdSl046659; Mon, 9 May 2011 16:28:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 9 May 2011 16:28:39 -0600 (MDT) From: Warren Block To: Alexander Leidinger In-Reply-To: <20110509212644.000066ad@unknown> Message-ID: References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <57a102e1.9eab.12fcda25c3a.Coremail.while1@163.com> <313C949D-643A-422F-98A4-72C9F3AE3181@vicor.com> <20110508211344.00006754@unknown> <7CD48B80-1280-4DF0-B383-B4134E6EF2DA@vicor.com> <20110509212644.000066ad@unknown> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 09 May 2011 16:28:39 -0600 (MDT) Cc: FreeBSD Hackers , Devin Teske , =?ISO-8859-1?B?5YWw5riF?= Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 22:28:51 -0000 On Mon, 9 May 2011, Alexander Leidinger wrote: > IMO it's either > - change now > or > - no change, never ever > or > - change if special variable is set In case it hasn't already been suggested... Just make the loader read a template file that defines the menu. The port or base system can include a standard menu file, and everyone else can set it up however they want. As an example, see syslinux or grub or any number of similar boot menus. From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 00:15:19 2011 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5886B106564A; Tue, 10 May 2011 00:15:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 30DD38FC17; Tue, 10 May 2011 00:15:18 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 2C855B827; Mon, 9 May 2011 17:15:18 -0700 (PDT) To: David Schultz In-reply-to: Your message of "Mon, 09 May 2011 17:51:46 EDT." <20110509215146.GA18135@zim.MIT.EDU> References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> <20110509014938.EE292B827@mail.bitblocks.com> <20110509061334.A62EAB827@mail.bitblocks.com> <20110509215146.GA18135@zim.MIT.EDU> Comments: In-reply-to David Schultz message dated "Mon, 09 May 2011 17:51:46 -0400." Date: Mon, 09 May 2011 17:15:18 -0700 From: Bakul Shah Message-Id: <20110510001518.2C855B827@mail.bitblocks.com> Cc: Gabor Kovesdan , "Pedro F. Giffuni" , hackers@FreeBSD.ORG, Brooks Davis , Zhihao Yuan Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 00:15:19 -0000 On Mon, 09 May 2011 17:51:46 EDT David Schultz wrote: > On Sun, May 08, 2011, Bakul Shah wrote: > > On Sun, 08 May 2011 21:35:04 CDT Zhihao Yuan wrote: > > > 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), > > > but it does not allow you to change the mode. > > > http://code.google.com/p/re2/source/browse/re2/re2.h > > > > The mode is decided when an RE2 object is instantiated so this > > is ok. You can certainly instantiate multiple objects with > > different options if so desired. > > > > > 2. It focuses on speed and features, not stability and standardization. > > > > Look at the open issues. Seems stable enough to me. re2 has a > > posix only mode. It also does unicode. s/posix only mode/posix only mode as well/ > > > > > 3. It uses C++. We seldom accepts C++ code in base system, and does > > > not accept it in libc. > > > > This is the show stopper. > > Use of C++ is a clear show-stopper if it introduces new runtime > requirements, e.g., dependencies on STL or exceptions. Aside from > that, however, I can't think of any fundamental, technical reasons > why a component of libc couldn't be written in C++. (Perhaps the > toolchain maintainers could name some, and they'd be the best > authority on the matter.) You can expect some resistance > regardless, however, so make sure the technical merits of RE2 are > worth the trouble. Ok, I just verified there are no additional runtime requirements by running a simple test, where I added a C wrapper around an RE2 C++ call, compiled it with c++, then compiled the client C code with cc, and linked everything with cc. This works (tested on on x86_64, under 8.1). I do think RE2 is very well done (see swtch.com/~rsc/regexp articles) and it is actively maintained, has a battery of pretty exhaustive tests. Seems TRE's author also likes re2: http://hackerboss.com/is-your-regex-matcher-up-to-snuff/ So if we want to consider this, it is a real possibility. > IIRC, some of the prior discussions on using more C++ in the base > system got derailed by tangents on multiple inheritance, operator > overloading, misfeatures of STL, and what subset of C++ ought to > be considered kosher in FreeBSD. You don't have to get involved > in any of that because you'd only be proposing to import a > self-contained third-party library. Indeed; we would just use it via a C wrapper API. But I can see someone thinking this is the camel's nose in the tent :-) From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 01:24:42 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276201065670 for ; Tue, 10 May 2011 01:24:42 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) by mx1.freebsd.org (Postfix) with SMTP id CB72D8FC16 for ; Tue, 10 May 2011 01:24:41 +0000 (UTC) Received: from [98.138.90.48] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2011 01:12:28 -0000 Received: from [98.138.89.249] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2011 01:12:28 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 10 May 2011 01:12:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 554090.66790.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 54756 invoked by uid 60001); 10 May 2011 01:12:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304989948; bh=15YiEzjQ5zdywD59ONCraIcyNqnfjpvS33s72jmDPFU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ch+s/3s9X6PxOshXeSggOUTvzpKSBn3/CIMd16mZw4NrBbi7r+gMjlKPe5zQDmoL2MP4+sNoyxdGwjBaBxo+7fgeiDmcEsEnLqoQWATXc5rEk/2rIdCblx7D2a7r6RPAGQOd8RL8ynvriqXHRi7c6MzN701csZFgua2OTls3JrY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aV5Te1mP3LsMxGW8oplFc6Xc3gS3W1UVyiGB4xu7afaj+h/zJEfA3bSHIDqdsZQ9PFVZ6JTMMupAbVriIfoDD/nmIRw1YtZMjeb+OaunwJyIGIYRXPR5Nor9hy2h9JbJySelRpODgy2Q0Hjbdl3WoLixepJAqY0ToBiJw/B10ZY=; Message-ID: <84842.36474.qm@web113506.mail.gq1.yahoo.com> X-YMail-OSG: RqM7jeQVM1kXvxpjmJXdIwz6tWZBANvUmob8QKbYvTHk_cb 31n.F2MhN_7njw7ujO70vTUipTj4qPFqMQ7t4Ji7zq4q5N_O4KdSQwWQbIZE Q1CYy49rkYrQ8XsEiT7sbiVlObCn_j1Tl3m0CwoOvCmoITgwzSevzR19tZwD .qveHQTP36J8bQI9tbDjuPExpGQnFTAbIqFTH7Nz6rJhRWAaYfeia0c1HnY. OLR4LltL1Q8f_R08GGZYLw5xYTo8OZCQc0pw7_1ZzeO755Q7MQS5PAL97VgT OMcMO9t9dNkwEU_JpE76bqrkls.fXdVH.fqM5dc7W3IwILT3imxLkUY1EmHF pZLzU5q43DY4HCCOw0pyxoiOuFBizA_s..NlTjgion5O2nrtlrcYhYTWJLaT OuUJSt9Pf1HeM Received: from [200.118.158.177] by web113506.mail.gq1.yahoo.com via HTTP; Mon, 09 May 2011 18:12:27 PDT X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.110.299900 Date: Mon, 9 May 2011 18:12:27 -0700 (PDT) From: "Pedro F. Giffuni" To: Gabor Kovesdan In-Reply-To: <20110509014938.EE292B827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 10 May 2011 02:18:36 +0000 Cc: hackers@FreeBSD.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:24:42 -0000 --- On Sun, 5/8/11, Bakul Shah wrote: ... > > C++ may be an impediment for it to go into libc but one > can certainly put a C interface on a C++ library. > I wouldn't think it's very consistent to use C++ in libc. Perhaps we could have the best of both worlds by using libtre as the libc regex replacement and re2 for grep and diff? As an extra benefit using Re2 would make it easier to support --perl-regex in grep. cheers, Pedro. From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 11:35:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E69106564A for ; Tue, 10 May 2011 11:35:29 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id B46778FC1D for ; Tue, 10 May 2011 11:35:28 +0000 (UTC) Received: from e-new.0x20.net (localhost [217.69.76.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id C24416A6049; Tue, 10 May 2011 13:35:26 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id p4ABZQoB075110; Tue, 10 May 2011 13:35:26 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id p4ABZPTa074412; Tue, 10 May 2011 13:35:25 +0200 (CEST) (envelope-from lars) Date: Tue, 10 May 2011 13:35:25 +0200 From: Lars Engels To: Devin Teske Message-ID: <20110510113525.GA71959@e-new.0x20.net> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <20110509091902.GR47109@e-new.0x20.net> <000601cc0e70$5e960dc0$1bc22940$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <000601cc0e70$5e960dc0$1bc22940$@vicor.com> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 10 May 2011 11:42:19 +0000 Cc: 'FreeBSD Hackers' , kmoore@pcbsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 11:35:29 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kris Moore CC'ed On Mon, May 09, 2011 at 10:41:40AM -0700, Devin Teske wrote: > > -----Original Message----- > > From: Lars Engels [mailto:lars.engels@0x20.net] > > Sent: Monday, May 09, 2011 2:19 AM > > To: Devin Teske > > Cc: FreeBSD Hackers > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 > >=20 > > On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: > > > Hello fellow -hackers, > > > > > > I'm so very proud to offer the latest update to my new boot loader > > > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line > > > with HEAD. > > > > > > It took some work and a few days, but I got it! Have a look below for > > > six different displays (three different scenarios -- i386 w/ ACPI, > > > i386 w/o ACPI, and non-i386 -- each in both B&W and Color). > > > > >=20 > > Hi Devin, > >=20 > > PC-BSD also has a slightly patched loader menu compared to the stock Fr= eeBSD > > version. >=20 > Does PC-BSD have CVSweb that I can browse? Link? http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot >=20 > > I.E. you can also set unset verbose mode and ACPI with it. > > Some days ago there was a proposal on a PC-BSD list to add an option to= boot a > > different kernel if one is found in /boot. > > Would it be possible to addi this function to your boot menu? >=20 > No need. The basic constructs are there already, we just need to expand o= n them. >=20 > Here's how I've implemented a hard-coded list of kernels to choose from f= or our systems (to be implemented in /boot/menu.rc): >=20 > \ Set kernel paths (see menu_caption[2] below) > set kernel_prefix=3D"/kernels/" > \ NOTE: We like to keep our kernels in `/kernels' > set kernel[0]=3D"FIS-i386-8.1p1" > set kernel[1]=3D"GENERIC-i386-8.1p1" > set kernel_suffix=3D".kgz" > \ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d >=20 > \ Set default boot kernel > set kernel=3D"${kernel_prefix}${kernel[0]}${kernel_suffix}" >=20 > \ Initialize main menu constructs (variables are read by `menu.4th') >=20 > set menu_caption[1]=3D"Boot [ENTER]" > set menu_command[1]=3D"boot" >=20 > set menu_caption[2][0]=3D"Kernel: ${kernel[0]} (1of2)" > set menu_caption[2][1]=3D"Kernel: ${kernel[1]} (2of2)" > set menu_caption[2]=3D"${menu_caption[2][0]}" > set menu_command[2]=3D"cycle_kernel" >=20 > \ ... rest of menu ... >=20 > The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The `cycl= e_kernel' command is a wrapper to the `cycle_menuitem' command (similar to = how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers t= o the `toggle_menuitem' command). Like the `toggle_menuitem' command, the `= cycle_menuitem' command uses a system of internal state variables to track = which menuitem text is to be displayed for that individual menuitem. Wherea= s the `toggle_menuitem' command automatically toggles the text of a menuite= m between the `menu_caption[x]' and `toggled_text[x]' variables, the `cycle= _menuitem' command automatically cycles through the `menu_caption[x][y]' va= riables, cycling back to y=3D0 when it gets to an undefined `y' value. >=20 > However, hard-coding an alternate kernel choice is something that I would= n't condone for an actual release. Instead, what I would recommend is to dy= namically allocate the kernel menu if/when multiple kernels are discovered/= configured. That's something that is currently not coded (dynamic detection= of kernels in /boot). >=20 > > Or even better > > work together with Kris Moore so we don't have two solutions for the sa= me task? >=20 > I'd like to open a discussion with Kris Moore on how we could go about de= tecting additional kernels. >=20 > Off the top of my head, here's a couple thoughts: >=20 > a. We could test a battery of different kernel names (kernel, kernel.bak,= kernel.orig, etc.) > b. We could allow the user to set kernel1, kernel2, kernel3, etc. in load= er.conf(5) > c. We could allow the user to set kernel=3D"kernel1;kernel2;kernel3;..." = in loader.conf(5) > d. Some combination of the above. > --=20 > Devin >=20 > P.S. I think it'd also be nice to someday offer the user a choice of boot= ing into a memory filesystem for rescue purposes. We've offered this to our= users for years with the following configuration: >=20 > set root[0]=3D"" > set root[1]=3D"rescue_mfsroot" > set menu_caption[7][0]=3D"Root Image: Default (1of2)" > set menu_caption[7][1]=3D"Root Image: Rescue (2of2)" > set menu_caption[7]=3D"${menu_caption[7][0]}" > set menu_command[7]=3D"cycle_root" >=20 Good idea! :-) --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3JIv0ACgkQKc512sD3afgsfgCglYcx/GeumkOv3PQRZIuQbXFD whIAoMZRb8ToOT2NCkx0jgO35k0a4y2o =ipog -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 13:34:33 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F3D106566B; Tue, 10 May 2011 13:34:33 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEA48FC14; Tue, 10 May 2011 13:34:33 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 44F7314E5461; Tue, 10 May 2011 15:34:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3DCG9wGaSfcF; Tue, 10 May 2011 15:34:26 +0200 (CEST) Received: from [193.137.158.225] (unknown [193.137.158.225]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 1779D14E533D; Tue, 10 May 2011 15:34:26 +0200 (CEST) Message-ID: <4DC93EDF.6000908@kovesdan.org> Date: Tue, 10 May 2011 14:34:23 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tim Kientzle References: <4DC7356C.20905@kovesdan.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 May 2011 15:21:25 +0000 Cc: "Pedro F. Giffuni" , hackers@freebsd.org, Brooks Davis Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:34:33 -0000 Em 09-05-2011 06:44, Tim Kientzle escreveu: > Have you asked the TRE maintainers if they would accept this change? > > If they would, then getting this change into TRE would benefit a lot more people than just FreeBSD's libc. This is a longer term goal. First, I prefer having something to talk about with the maintainer and then I can work out the patches to integrate it if he accepts it. For now, I prefer keeping them separate and if he is open to those ideas then I can easily refactor the code to fit the vendor code. Gabor From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 13:39:27 2011 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D72B1065676; Tue, 10 May 2011 13:39:27 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 29C0B8FC17; Tue, 10 May 2011 13:39:27 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 7327C14E5462; Tue, 10 May 2011 15:39:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2Oxknnx1Kbcd; Tue, 10 May 2011 15:39:24 +0200 (CEST) Received: from [193.137.158.225] (unknown [193.137.158.225]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 166CC14E533D; Tue, 10 May 2011 15:39:24 +0200 (CEST) Message-ID: <4DC9400A.8080304@kovesdan.org> Date: Tue, 10 May 2011 14:39:22 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bakul Shah References: <4DC7356C.20905@kovesdan.org> <20110509011709.5455CB827@mail.bitblocks.com> <4DC74546.1060902@kovesdan.org> <20110509014938.EE292B827@mail.bitblocks.com> <20110509061334.A62EAB827@mail.bitblocks.com> <20110509215146.GA18135@zim.MIT.EDU> <20110510001518.2C855B827@mail.bitblocks.com> In-Reply-To: <20110510001518.2C855B827@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 May 2011 15:21:37 +0000 Cc: "Pedro F. Giffuni" , David Schultz , hackers@FreeBSD.ORG, Brooks Davis , Zhihao Yuan Subject: Re: [RFC] Replacing our regex implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:39:27 -0000 Thanks to all for the valuable comments. I've decided to continue the work with TRE because - Many people don't like the idea of adding C++ code into libc - I'm not very skilled in C++ However, in a later phase of development, I think re2 may be a good source of ideas in optimizing the performance. For now, I think if the new code without optimizations is at least as fast as the old regex code, that's fine. Imho, the motivation of replacing it is not just the performance but also the fact it is outdated code and not maintained any more and also the lack of wide character support. Once it is feature-complete to replace the old code, we can start thinking of optimizations. And as proposed, I'll separate those from libc for now and later I can propose some changes to the TRE maintainer. Gabor From owner-freebsd-hackers@FreeBSD.ORG Wed May 11 00:42:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65A8106564A for ; Wed, 11 May 2011 00:42:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6A05D8FC08 for ; Wed, 11 May 2011 00:42:19 +0000 (UTC) Received: from [192.168.14.163] ([24.114.252.233]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4B0bg7g034687 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 10 May 2011 18:37:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 10 May 2011 11:01:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9B3FEB02-B71C-412B-BB7E-31A236021CDD@bsdimp.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> To: Damjan Marion X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 10 May 2011 18:37:46 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Marius Strobl Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 00:42:19 -0000 On May 8, 2011, at 7:52 AM, Damjan Marion wrote > On May 8, 2011, at 3:16 PM, Marius Strobl wrote: >> On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: > Yes, my initial idea is to attach manually only to one PHY, but = problem=20 > is that either i can attach to PHY12-15 which is reporting wrong ID2=20= > belonging to different PHY driver or to attach on PHY20-23 where ID1 = and ID2=20 > registers doesn't exist, but luckily some values are at that address = and=20 > they are recognized as unknown PHY. There's supposed to be 'wiring' information for the switches/PHYs in the = DTS. Maybe you can key off that to determine which ones to attach to. =20= > In both cases it sounds like a workaround more than a proper solution, = so=20 > I was wondering if there is some better way to detect PHY, not only by=20= > ID1 and ID2 values. In case of this device there is another register = which=20 > contains product identifier, and that is what linux driver probes. Usually detection by ID1/ID2 is the better way. However, some devices, = like this switch, respond on multiply PHY addresses (sometimes bogusly, = sometimes not). >>> I would like to hear form more experienced people how to implement = this properly, as it is obvious that it cannot be addressed with = existing routines. >>=20 >> Depends on what you understand by properly. One idea I particularly >> like is to handle switch ports as pseudo-interfaces hanging off of = the >> the MAC driver parent roughly similar to vlan(4). That way you'd have >> per port link status and could configure the media. >>=20 >> What you can do now without changing mii(4) is to just attach the >> the PHY side, i.e. port 3, and configure/handle the ports in a >> special PHY driver, either by hardcoding their configuration like >> rlswitch(4) does or by providing SYSCTLs as Adrian already said. >> If we had a way to access the PHY registers from userland similar >> to what pci(4)/pciconf(8) allows, which is another thing I'd like >> to see in order to provide miitool-like functionality, one could >> also easily handle the port configuration from userland instead >> of putting everything into the kernel. That probably also would >> have its merits as in reality there are probably a lot of quirks >> like unconnected ports etc. >=20 > Agree, I will try to code something and then I will ask wider audience = to comment on. That would be cool. Most switches are on the PHY bus, so you can program their registers. = Many are on the PHY bus multiple times. Once for the real(ish) PHY they = provide and once for the switch registers they expose (for some, "twice" = means up to 4 times). Some are just nuts. It would be nice if there was a way for a device's MII routine to = control enumeration of the PHY bus. This would allow us to convert the = rlswitch device in the tree to one of these. That way, it could = 'filter' out the PHYs addresses that are intended to be like traditional = PHYs from the addresses that are intended to be used for switch = management. We likely should also have a switch interface that one can tweak via = ifconfig. I'd like that to be an explicit goal of this work, even if = others do it. However, that's a big ticket item. I kinda like the 'let us put a few = of these in the tree with kludges then refactor' model, but worry we end = up without the refactoring... Warner= From owner-freebsd-hackers@FreeBSD.ORG Wed May 11 00:42:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1521065670; Wed, 11 May 2011 00:42:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2954B8FC0A; Wed, 11 May 2011 00:42:25 +0000 (UTC) Received: from [192.168.14.163] ([24.114.252.233]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4B0bg7h034687 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 10 May 2011 18:37:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 10 May 2011 11:06:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 10 May 2011 18:37:47 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Damjan Marion , Marius Strobl Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 00:42:25 -0000 On May 9, 2011, at 12:30 AM, Adrian Chadd wrote: > On 8 May 2011 21:16, Marius Strobl wrote: >=20 > [snip] >=20 >> Depends on what you understand by properly. One idea I particularly >> like is to handle switch ports as pseudo-interfaces hanging off of = the >> the MAC driver parent roughly similar to vlan(4). That way you'd have >> per port link status and could configure the media. >=20 > The reason I like this is because I realise that these switch PHYs > tend to have quite a bit of varying but useful functionality, that > isn't just "multi-port single-VLAN switch PHY." >=20 > Besides there being per-port status, there can also be per-port > error/packet/byte counts, VLAN setups (tagged/untagged), QoS > configuration, sometimes some L2 filtering and (even more creepy) > sometimes L3 filtering/routing. >=20 > They can sometimes hang off the MII bus, but ISTR datasheets which > show they can hang off an SPI bus too. So although they can look like > PHYs complete with the register layouts, there's extended commands to > implement other features as well. There may even be more than one CPU > ethernet port hooked up - I think the Routerstation Pro has both CPU > GigE ports wired to the switch PHY and defaults to mapping port 1 -> > arge0 and Port 2,3,4,5 -> arge1. >=20 > I'd really appreciate it if someone were able to sit down, take the > existing work done by Luiz and others and flesh out a bare minimum set > of switch PHY drivers that configure them with some sensible defaults > (rather than leaving it up to the boot firmware to do it for you) and > have all of the interface/configuration glue in the kernel. As I said > earlier, figuring out how to expose all the functionality - including > per-port error counts and such - can come later. Yes. Agreed. Stated a bit more elegantly than I just did... Handling = non-localized connections is critical here. The embedded world has a = lot of funky interconnects that map poorly into our device model. = Having the association handled at a higher level will help us connect = these things. In the designs I've seen, this can happen both for the = switches we're talking about, as well as PHYs. I believe there are some = CPUs where talking to the PHY doesn't go through the MAC.... Warner= From owner-freebsd-hackers@FreeBSD.ORG Wed May 11 05:18:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD7B1065672 for ; Wed, 11 May 2011 05:18:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6A8E8FC08 for ; Wed, 11 May 2011 05:18:28 +0000 (UTC) Received: by gwb15 with SMTP id 15so71760gwb.13 for ; Tue, 10 May 2011 22:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=32gvbCxn8ymn4ZFjvJjUCBMsLsiU/L2Tmolp9V4Pepc=; b=XEbjcDPMUeC2pvNAbNyNpTq4s0G6eDgbnC9jWBpPVFDw2yMexdzUrWbinhVn+Mzu4h NiTF3pI528TFXcar30oYaqh0ILluqNJ4tYvbjVRk4dvhfIJ3VkmezYWpS+DkyqHwJSlE 8G1AdwOR5TlMxMGHqsdAAVarO7gJN05yDoGHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TiNSkjvuhl47wfYZjCQBjeMijesmUiU6s0Oa/XkNP5u4QVso3N5F4dND3YVvdXPDmW YbhwqXtsmsOFZnrMVarBCxVRCUz8EX+2yftUP/CVpL9M3Cv6h0rRqQnbwJT6Yonx/YSR 8MICIsGir9bT8/s8SpS1WRjjbXIc9RjnXmZf4= MIME-Version: 1.0 Received: by 10.150.66.14 with SMTP id o14mr3339877yba.353.1305091108151; Tue, 10 May 2011 22:18:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Tue, 10 May 2011 22:18:28 -0700 (PDT) In-Reply-To: <9B3FEB02-B71C-412B-BB7E-31A236021CDD@bsdimp.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> <9B3FEB02-B71C-412B-BB7E-31A236021CDD@bsdimp.com> Date: Wed, 11 May 2011 13:18:28 +0800 X-Google-Sender-Auth: 4I_wUuFnF8yOYG4e8vBNQjIeZH0 Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Marius Strobl , Luiz Otavio O Souzau , Damjan Marion Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 05:18:29 -0000 On 11 May 2011 01:01, Warner Losh wrote: > Most switches are on the PHY bus, so you can program their registers. =A0= Many are on the PHY bus multiple times. =A0Once for the real(ish) PHY they = provide and once for the switch registers they expose (for some, "twice" me= ans up to 4 times). =A0Some are just nuts. This is unfortunately why we need to have real drivers for the switch PHY chips, rather than treating them as generic PHYs. :/ > It would be nice if there was a way for a device's MII routine to control= enumeration of the PHY bus. =A0This would allow us to convert the rlswitch= device in the tree to one of these. =A0That way, it could 'filter' out the= PHYs addresses that are intended to be like traditional PHYs from the addr= esses that are intended to be used for switch management. > > We likely should also have a switch interface that one can tweak via ifco= nfig. =A0I'd like that to be an explicit goal of this work, even if others = do it. > > However, that's a big ticket item. =A0 I kinda like the 'let us put a few= of these in the tree with kludges then refactor' model, but worry we end u= p without the refactoring... If others commit to shoehorning in the PHY driver work and expose the basic guts via sysctl, I'll commit to doing a review and tidyup in a few months. This includes looking at how to take the set of switch PHYs and L3 routing/filtering that we support and figure out how to expose it in a sensible manner. So who's willing to step up and do that? Luiz? Would you be willing to take your existing switch PHY code and just expose the state via sysctl? Let's get something into -HEAD. Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed May 11 20:41:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E5A4106564A; Wed, 11 May 2011 20:41:58 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 1A68E8FC18; Wed, 11 May 2011 20:41:57 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 8EC0DC3834; Wed, 11 May 2011 22:26:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id pQhEH6hCJBIC; Wed, 11 May 2011 22:26:20 +0200 (CEST) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 99358C3832; Wed, 11 May 2011 22:26:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <84255DD0-2593-4F24-8536-2C015CE11DC4@gmail.com> Date: Wed, 11 May 2011 22:26:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65747DF5-AAE5-446C-A162-7AE167D992A0@semihalf.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <84255DD0-2593-4F24-8536-2C015CE11DC4@gmail.com> To: Damjan Marion X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, Adrian Chadd Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 20:41:58 -0000 On 2011-05-08, at 11:36, Damjan Marion wrote: >=20 > On May 8, 2011, at 9:58 AM, Adrian Chadd wrote: >=20 >> On 8 May 2011 01:22, Damjan Marion wrote: >>=20 >>> I would like to implement support for embedded switch on WRT350Nv2 = router which is based on 88F5181L SoC (ARM). FreeBSD already have = support for embedded gigabit card (if_mge) but in case if this router = MAC is connected directly to 8-port ethernet chip (88E6131). If I use = MII_PHY_ANY scan founds following PHYs on miibus: >>=20 >> There's been some discussions in the past about how to implement a >> switch PHY API for use by the variety of embedded switch devices out >> there. >>=20 >> There's been a few attempts at it too. >>=20 >> What I think may just be a good first step is to port over the Linux >> driver for it and instead of trying to make it appear as a multi-PHY >> device, just export a programming and status interface via sysctl. >> That at least gets the thing in the tree and functioning. Once we = have >> a few devices in the tree and functioning, we'll be in a better >> position to have a discussion about how to represent it. >>=20 >> There's a couple of dissenting views about how it should be >> implemented. I'd like to see some working code in the tree so some >> discussion can occur, rather than lots of dissent and no discussion. >> :) >>=20 >> (The switch phy is the last remaining bit of the board support for a >> handful of boards too, so I'd really like to see it completed. :) >=20 > Hi Adrian, >=20 > I agree with your approach. At this point my concern is how to change = existing code to support switch PHY. In my case problem is that = mii_attach as it is today cannot be used detect this device as device is = not using standard registers. >=20 > I can see 2 possible options: > 1. Modifying eth driver in the way that if switch phy is detected then = it avoids calling mii_attach. Drawback of this approach is that it will = need applying same code for each pair of MAC-switch PHY >=20 > 2. Modifying mii_attach in the way that it is more flexible in = detecting such devices. This looks challenging to me to do this in = flexible way. >=20 > What do you think? FWIW, there's a couple of items already available for the 88E6xxx switch = support, which you can try to use as a base for further work: * Juli Mallet's driver, which is currently in HEAD (used by Cavium = MIPS): - http://fxr.watson.org/fxr/source/mips/cavium/octe/mv88e61xxphy.c - http://fxr.watson.org/fxr/source/mips/cavium/octe/mv88e61xxphyreg.h * My team's early experimental work: - http://people.freebsd.org/~raj/misc/e6000sw.c - http://people.freebsd.org/~raj/misc/e6000swreg.h Rafal From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 01:30:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 030B5106564A for ; Thu, 12 May 2011 01:30:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF9348FC13 for ; Thu, 12 May 2011 01:30:32 +0000 (UTC) Received: by yxl31 with SMTP id 31so475527yxl.13 for ; Wed, 11 May 2011 18:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qlvj6JfZvvbc+ih50po5XMwJMCzsZWFsV9UXtXs8nXY=; b=UUlq8403D/XrP0j1inE/NF1IdakaYAxx6vgcF9+waihyx+ujVmyz3wR7riK2RES3CG 2JPWvFHUDC00l9DxY4VE1FQwWJJtc7yokKD/02M9PLgf3bc9SnJx3cDK7ovTbn2sfVog q2H3FrYnbz4AbupLTsSOpbRcJsNuQL0acu+iU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QXTnJik0Nirxv0YaxtbFgTDLcWsdk3iZBUI6f6FaoEhNl3rx2fthe1+PJ3OovtkNQf fxrp43on4SClqFKw69BfAkhDAvgVzdLi2GqWRYpiNyBSqARkheE9Emti7DcKjdPzwc7r kyUupi9Lt4vYcJaTSkwsQOH7umC9YOljbg2Mc= MIME-Version: 1.0 Received: by 10.150.66.14 with SMTP id o14mr4194002yba.353.1305163831793; Wed, 11 May 2011 18:30:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Wed, 11 May 2011 18:30:31 -0700 (PDT) In-Reply-To: <65747DF5-AAE5-446C-A162-7AE167D992A0@semihalf.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <84255DD0-2593-4F24-8536-2C015CE11DC4@gmail.com> <65747DF5-AAE5-446C-A162-7AE167D992A0@semihalf.com> Date: Thu, 12 May 2011 09:30:31 +0800 X-Google-Sender-Auth: yhr2Usb1rD0cp6E91KpRMF9IAZo Message-ID: From: Adrian Chadd To: Rafal Jaworowski Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Damjan Marion Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 01:30:33 -0000 What I'm trying to figure out (and gave up because I have other things to do :-) is whether it's feasible to stick a device on the MII bus but not have it actually be a PHY. Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 07:38:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C76D81065670 for ; Thu, 12 May 2011 07:38:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8518FC17 for ; Thu, 12 May 2011 07:38:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2d19:d22d:b020:7e1b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 41DD94AC2D for ; Thu, 12 May 2011 11:38:18 +0400 (MSD) Date: Thu, 12 May 2011 11:38:12 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1649118429.20110512113812@serebryakov.spb.ru> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 07:38:19 -0000 Hello, Freebsd-hackers. Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 11:17:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 964CA1065692; Thu, 12 May 2011 11:17:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 087688FC1B; Thu, 12 May 2011 11:17:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p4CBHqus095961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 14:17:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p4CBHqhD045023; Thu, 12 May 2011 14:17:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p4CBHqSo045022; Thu, 12 May 2011 14:17:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 May 2011 14:17:52 +0300 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20110512111752.GP48734@deviant.kiev.zoral.com.ua> References: <1649118429.20110512113812@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BbNl1xIdp9HsSiAD" Content-Disposition: inline In-Reply-To: <1649118429.20110512113812@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, mdf@freebsd.org Subject: Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 11:17:57 -0000 --BbNl1xIdp9HsSiAD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: > Hello, Freebsd-hackers. >=20 > Does FreeBSD have some custom call, which can be used where Linux > programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? >=20 > It is like madvise(2) but for file descriptors. No, it does not (and I think the function is spelled posix_fadvise()). mdf reserved the syscall slot for posix_fadvise in his recent work on posix_fallocate(). Might be, he could comment more. --BbNl1xIdp9HsSiAD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3LweAACgkQC3+MBN1Mb4hQ+gCfZsO5NwkxDriKJwYM7J/4oPCX TjYAniDcRhG4Y+ERWedR0ldPy87mVg1e =4ufF -----END PGP SIGNATURE----- --BbNl1xIdp9HsSiAD-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 11:40:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C88B1065688; Thu, 12 May 2011 11:40:27 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9BBA8FC1C; Thu, 12 May 2011 11:40:26 +0000 (UTC) Received: by wyf23 with SMTP id 23so1460180wyf.13 for ; Thu, 12 May 2011 04:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AcekFGTmbYXb14AC2K3zMNpKTJAGOHfK1eUXO+j9Wz4=; b=QpRwbnsVchPuJSzIWxYTp4ad9KsRTcr3SkCB99Cnl2oOjel95o69yiLK5NBHkI/+eQ CLTFc0WOYnl1QsXRGDWQu8+ou18zqVVk63adGUW/zFr7d/wwUiwqt4HuQYcnDk9WTa51 kwzMSff+2/CYvRtL6GV68hMHtSQdeWV7tMPs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Z1b8wIRoqUqduo0+3pc/oE0qCp0uJZD/ChU6YUXk69wh+AWUT/fGAeXXoRAyF/zNCO EedeT3kpfILUWdpQtoZbToInk8V0SaLD8ojTXZNKxj08Vq3ZNaAl7A9fyAVwmbVDZk7I i0JC9vhx1FF54bxKFsGx21RLC0a580Dpaq0AE= MIME-Version: 1.0 Received: by 10.216.30.206 with SMTP id k56mr1655416wea.29.1305200425588; Thu, 12 May 2011 04:40:25 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.172.196 with HTTP; Thu, 12 May 2011 04:40:25 -0700 (PDT) In-Reply-To: <20110512111752.GP48734@deviant.kiev.zoral.com.ua> References: <1649118429.20110512113812@serebryakov.spb.ru> <20110512111752.GP48734@deviant.kiev.zoral.com.ua> Date: Thu, 12 May 2011 04:40:25 -0700 X-Google-Sender-Auth: 5a2Ru3M1ND4GnqMzG62cCoMI254 Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Lev Serebryakov Subject: Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 11:40:27 -0000 On Thu, May 12, 2011 at 4:17 AM, Kostik Belousov wrot= e: > On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: >> Hello, Freebsd-hackers. >> >> =A0 =A0Does FreeBSD have some custom call, which can be used where Linux >> =A0programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? >> >> =A0 =A0It is like madvise(2) but for file descriptors. > No, it does not (and I think the function is spelled posix_fadvise()). > > mdf reserved the syscall slot for posix_fadvise in his recent work > on posix_fallocate(). Might be, he could comment more. Whoops, I replied bot forgot to reply-all. Adding a stub for posix_fadvise() is on my list of things to do, since we use it at $WORK in our custom filesystem, but the list is long and spare time is short. Nominally a technically correct implementation can do error checking and then nothing. Even after a stub is added to the OS, each filesystem must implement a VOP to do the work. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 18:15:21 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08DA8106566B for ; Thu, 12 May 2011 18:15:21 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id C35E58FC14 for ; Thu, 12 May 2011 18:15:20 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p4CIFJAn018048; Thu, 12 May 2011 13:15:19 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Thu, 12 May 2011 13:15:35 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 13:15:19 -0500 Received: from dtwin ([10.132.254.135]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 13:15:19 -0500 From: "Devin Teske" To: "'Teske, Devin'" , "'Emanuel Haupt'" References: <6955841F-C3C1-4C7D-8BA4-F8EBBF60F69B@vicor.com> <20110504103743.8d9f19d5.ehaupt@FreeBSD.org> <2F3440C0-6EDB-4CD5-A269-4791AB89AA96@vicor.com> In-Reply-To: <2F3440C0-6EDB-4CD5-A269-4791AB89AA96@vicor.com> Date: Thu, 12 May 2011 11:14:20 -0700 Organization: Vicor, Inc. Message-ID: <004501cc10d0$6aaa2800$3ffe7800$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQKPNfqPwiN85qRejt5EIdCpB7hjlAH45w/uAp+fLpqS3m/sgA== Content-Language: en-us X-OriginalArrivalTime: 12 May 2011 18:15:19.0149 (UTC) FILETIME=[8CFC51D0:01CC10D0] Cc: 'Olivier SMEDTS' , 'FreeBSD Hackers' Subject: RE: [UPDATE] New Boot-Loader Menu -- version 1.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 18:15:21 -0000 > On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: > >> Devin Teske wrote: >> >> Hey all, >> >> Proud to bring you version 1.3 which completes the followup >> suggestions made by Olivier Smedts (use autoboot_delay instead of >> loader_menu_timeout and change dc_seconds to loader_delay) and a >> couple other minor enhancements/fixes. >> >> I think that brings everything up to speed with the phenomenal >> feedback provided so far. Really, thank you all very much. >> >> Get your update at http://druidbsd.sf.net/ or >> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz > > Devin, have you thought about writing a port [1]? I'd be happy to > review it: > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html > I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 19:21:26 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FE1D106566B; Thu, 12 May 2011 19:21:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 08CEC8FC13; Thu, 12 May 2011 19:21:25 +0000 (UTC) Received: from [172.24.96.151] ([192.75.139.251]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4CJCXDw057143 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 12 May 2011 13:12:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <004501cc10d0$6aaa2800$3ffe7800$@vicor.com> Date: Thu, 12 May 2011 15:12:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65723122-FD36-4BB5-8E0C-4973E6644251@bsdimp.com> References: <6955841F-C3C1-4C7D-8BA4-F8EBBF60F69B@vicor.com> <20110504103743.8d9f19d5.ehaupt@FreeBSD.org> <2F3440C0-6EDB-4CD5-A269-4791AB89AA96@vicor.com> <004501cc10d0$6aaa2800$3ffe7800$@vicor.com> To: Devin Teske X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 12 May 2011 13:12:37 -0600 (MDT) Cc: 'Olivier SMEDTS' , 'FreeBSD Hackers' , "'Teske, Devin'" , 'Emanuel Haupt' Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 19:21:26 -0000 On May 12, 2011, at 2:14 PM, Devin Teske wrote: >> On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: >>=20 >>> Devin Teske wrote: >>>=20 >>> Hey all, >>>=20 >>> Proud to bring you version 1.3 which completes the followup >>> suggestions made by Olivier Smedts (use autoboot_delay instead of >>> loader_menu_timeout and change dc_seconds to loader_delay) and a >>> couple other minor enhancements/fixes. >>>=20 >>> I think that brings everything up to speed with the phenomenal >>> feedback provided so far. Really, thank you all very much. >>>=20 >>> Get your update at http://druidbsd.sf.net/ or >>> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz >>=20 >> Devin, have you thought about writing a port [1]? I'd be happy to >> review it: >>=20 >> [1] > = http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port= .html >>=20 >=20 > I'm going to see if I can't make it perfectly acceptable for base = first. If the > final version gets rejected for submission to base, I'll turn to = ports. >=20 > On a side-note, it'd be a pretty interesting port... considering the = fact that > I'm already distributing it as a FreeBSD package (what would the = Makefile for > that port look like... a call to fetch followed by a call to pkg_add = ?? lol -- > are there other ports that already work like that?). In the FreeBSD developer's summit today, there was broad support for = bringing it into base for 9.0. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 19:13:04 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08FF106566C for ; Thu, 12 May 2011 19:13:04 +0000 (UTC) (envelope-from jelischer@fusionio.com) Received: from mx1.fusionio.com (mx1.fusionio.com [66.114.96.30]) by mx1.freebsd.org (Postfix) with ESMTP id 795BB8FC1D for ; Thu, 12 May 2011 19:13:04 +0000 (UTC) X-ASG-Debug-ID: 1305226667-03d6a50f3070280001-HFAwnd Received: from zim.fusionio.com ([10.101.1.182]) by mx1.fusionio.com with ESMTP id biD9Tp0kcgR25aj2; Thu, 12 May 2011 12:57:47 -0600 (MDT) X-Barracuda-Envelope-From: jelischer@fusionio.com Received: from localhost (localhost.localdomain [127.0.0.1]) by zim.fusionio.com (Postfix) with ESMTP id 69EBD4500002; Thu, 12 May 2011 12:57:48 -0600 (MDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_DATE_PAST_20XX=3.188, RDNS_NONE=0.1] Received: from zim.fusionio.com ([127.0.0.1]) by localhost (zim.fusionio.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC1xkm1ihVQC; Thu, 12 May 2011 12:57:48 -0600 (MDT) Received: from julian-mac.elischer.org (unknown [10.50.30.115]) by zim.fusionio.com (Postfix) with ESMTP id D64F54500001; Thu, 12 May 2011 12:57:47 -0600 (MDT) Message-ID: <4DCC2D95.8090503@fusionio.com> Date: Thu, 12 May 2011 14:57:25 -0400 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Devin Teske , "hackers@freebsd.org" References: <6955841F-C3C1-4C7D-8BA4-F8EBBF60F69B@vicor.com> <20110504103743.8d9f19d5.ehaupt@FreeBSD.org> <2F3440C0-6EDB-4CD5-A269-4791AB89AA96@vicor.com> <004501cc10d0$6aaa2800$3ffe7800$@vicor.com> X-ASG-Orig-Subj: Re: [UPDATE] New Boot-Loader Menu -- version 1.3 In-Reply-To: <004501cc10d0$6aaa2800$3ffe7800$@vicor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: UNKNOWN[10.101.1.182] X-Barracuda-Start-Time: 1305226667 X-Barracuda-URL: http://10.101.1.180:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at fusionio.com X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.63543 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 X-Mailman-Approved-At: Thu, 12 May 2011 19:32:54 +0000 Cc: Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 19:13:05 -0000 On 5/12/11 2:14 PM, Devin Teske wrote: >> On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: >> >>> Devin Teske wrote: >>> >>> Hey all, >>> >>> Proud to bring you version 1.3 which completes the followup >>> suggestions made by Olivier Smedts (use autoboot_delay instead of >>> loader_menu_timeout and change dc_seconds to loader_delay) and a >>> couple other minor enhancements/fixes. >>> >>> I think that brings everything up to speed with the phenomenal >>> feedback provided so far. Really, thank you all very much. >>> >>> Get your update at http://druidbsd.sf.net/ or >>> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz >> Devin, have you thought about writing a port [1]? I'd be happy to >> review it: port would be good for 8 it'll be in 9 by default (we just decided a the devsummit) (if there are no roadblocks) >> [1] > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html > I'm going to see if I can't make it perfectly acceptable for base first. If the > final version gets rejected for submission to base, I'll turn to ports. > > On a side-note, it'd be a pretty interesting port... considering the fact that > I'm already distributing it as a FreeBSD package (what would the Makefile for > that port look like... a call to fetch followed by a call to pkg_add ?? lol -- > are there other ports that already work like that?). Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 20:05:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FA61065673; Thu, 12 May 2011 20:05:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 649A88FC08; Thu, 12 May 2011 20:05:02 +0000 (UTC) Received: by wyf23 with SMTP id 23so1956286wyf.13 for ; Thu, 12 May 2011 13:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l6QziDMGEwtKQVCshdNDK6CRgsfv2CHRAkXUj7Y+R2o=; b=RK/fsQcO4IXjDsFdSUdaLXB7X9HdkWQTAtclw+1t5X2qZONxeLfSStONeRWJpQTiW4 Z/9vaxhbQTvUNIEG4ILUCXwxwjRtrbXTWHdFFf+mS6zgs3Cxp4lEh6/NtYKH8dcCGntZ XwFa9RGsjONJx/XVMkh2lonwOLgbu4XYrgO3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mUMm5j6TvYyo5xYSC6//HGzhqPA9GyxzVVut1lX+imah4prx3BOZKy16QkYvKPkjF6 E4NYQYYXcPqnO9w+bBF6yb13YmciSy1K08/eN5fvU/oSa+lonr2AWUgbQh6PzH2+Rnhb d3s7/+msQdnnmv6qGMsm+ET3KxgnD/dWgAbck= MIME-Version: 1.0 Received: by 10.216.220.150 with SMTP id o22mr621333wep.59.1305230701035; Thu, 12 May 2011 13:05:01 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.172.196 with HTTP; Thu, 12 May 2011 13:05:00 -0700 (PDT) In-Reply-To: <1367664809.20110512235200@serebryakov.spb.ru> References: <1649118429.20110512113812@serebryakov.spb.ru> <20110512111752.GP48734@deviant.kiev.zoral.com.ua> <1367664809.20110512235200@serebryakov.spb.ru> Date: Thu, 12 May 2011 13:05:00 -0700 X-Google-Sender-Auth: pPdB4Fzybp36iQCCqFkzJQ-mrr0 Message-ID: From: mdf@FreeBSD.org To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Lev Serebryakov Subject: Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 20:05:03 -0000 2011/5/12 Lev Serebryakov : > Hello, Mdf. > You wrote 12 =D0=BC=D0=B0=D1=8F 2011 =D0=B3., 15:40:25: > >>>> =C2=A0 =C2=A0Does FreeBSD have some custom call, which can be used whe= re Linux >>>> =C2=A0programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? >>>> >>>> =C2=A0 =C2=A0It is like madvise(2) but for file descriptors. >>> No, it does not (and I think the function is spelled posix_fadvise()). >>> >>> mdf reserved the syscall slot for posix_fadvise in his recent work >>> on posix_fallocate(). Might be, he could comment more. >> Whoops, I replied bot forgot to reply-all. > >> Adding a stub for posix_fadvise() is on my list of things to do, since >> we use it at $WORK in our custom filesystem, but the list is long and >> spare time is short. > >> Nominally a technically correct implementation can do error checking >> and then nothing. =C2=A0Even after a stub is added to the OS, each >> filesystem must implement a VOP to do the work. > =C2=A0transmission Torrents client rely on this syscall. It could be beui= lt > without it, of course (it is in our ports!), but it seems, that it > produce much more sane disk load on Linux, because uses pre-fetch via > posix_fadvise(). My profiling shows that pread() could take about 40% > of it CPU time (8 seconds out of 20 with turned on ktrace, for > example), even if throughput is very modest (700KiB/s, for example). > Authors say, that they didn't observe such behavior on Linux (which > has posix_fadvise()) or MacOS X (with fcntl(F_RDADVISE))... > > =C2=A0May be, we should go to fs@ with this thread now? Probably; the interface and a few unit tests are a start but the common filesystems (presumably ufs and zfs and perhaps others) will need support and I do not have any knowledge of the internals of those filesystems. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 21:14:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6911065670 for ; Thu, 12 May 2011 21:14:12 +0000 (UTC) (envelope-from zafer@aydogan.de) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD5268FC15 for ; Thu, 12 May 2011 21:14:11 +0000 (UTC) Received: by qwc9 with SMTP id 9so1334458qwc.13 for ; Thu, 12 May 2011 14:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.3.137 with SMTP id 9mr562940qcn.260.1305233106559; Thu, 12 May 2011 13:45:06 -0700 (PDT) Received: by 10.229.75.76 with HTTP; Thu, 12 May 2011 13:45:06 -0700 (PDT) Date: Thu, 12 May 2011 22:45:06 +0200 Message-ID: From: =?UTF-8?Q?Zafer_Aydo=C4=9Fan?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: OpenGrok for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 21:14:12 -0000 Hello List, I've set up an OpenGrok service for the FreeBSD sources (current). OpenGrok is a source code search engine and cross reference. I'm updating the sources once a day. I'm a NetBSD developer and I'm also maintaining http://nxr.netbsd.org Feel free to use it: http://fxr.aydogan.net Cheers, Zafer. From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 22:25:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEEC5106564A for ; Thu, 12 May 2011 22:25:06 +0000 (UTC) (envelope-from amitkulz@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42B028FC08 for ; Thu, 12 May 2011 22:25:06 +0000 (UTC) Received: by ewy1 with SMTP id 1so776613ewy.13 for ; Thu, 12 May 2011 15:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7v8KFcbpxXkwCWnS36cdFeAzroLBruzgWXKYgOF25N0=; b=ip57vPREGduvPpdQpuv9I8OECDWQIKrEIlnNaox5CfBMnX1eXxqa+zajU4U8juAOrL P/4DIbVYg6UOvL1uLAhu+ku1PxGy+cr7bor1bE7U5l0h2z8RxIYRq2cTGPi/aH+d/AM4 3b8MM1e7sgSc1RFvAG8sx8rYi3+WzzV15o5VA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=KJORiDTLKCcuVGORgPUybUFOh0CkAT93uPw7xkFzV9s5BIWh96V1nsxJ+/I+nj4vP4 ORt8+r6ApCQrUYGEeoGwe2jTHZCTLTKOTkjaIQ8JOaHoMO0eSP1X6aZ5XGZAYf2+7nFy q8Cqvl2Dv+KezXkUcyogYHkxCXOgsuAOSgQBE= MIME-Version: 1.0 Received: by 10.14.42.195 with SMTP id j43mr352788eeb.176.1305237628755; Thu, 12 May 2011 15:00:28 -0700 (PDT) Received: by 10.14.53.65 with HTTP; Thu, 12 May 2011 15:00:28 -0700 (PDT) Date: Thu, 12 May 2011 17:00:28 -0500 Message-ID: From: Amit Kulkarni To: lldb-dev@cs.uiuc.edu Content-Type: multipart/mixed; boundary=000e0cd5d0ae35a14204a31b5198 Cc: freebsd-hackers@freebsd.org, matthew@openbsd.org Subject: lldb patches for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 22:25:07 -0000 --000e0cd5d0ae35a14204a31b5198 Content-Type: text/plain; charset=ISO-8859-1 Hi, I installed FreeBSD 8.2 amd64 and trying to see how far lldb compiles, seeing as OpenBSD lacks shm_open/shm_unlink and some posix shared memory functionality right now. Note: FreeBSD 8.2 amd64 has system gcc of 4.2.1, the last GPLv2 gcc with some patches before the switch to GPLv3, if I am not mistaken. It seems FreeBSD is also affected like OpenBSD about the thread id issue discussed a month before in this thread. I am cc'ing matthew@ just to keep him in the loop. http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000444.html and it was resolved to fix it like so http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000452.html I don't know what should be the replacement for FreeBSD, as that particular piece of code in lldb/source/Host/common/Host.cpp is a dirty hack to allow compile to proceed. This is not okay to include otherwise. http://svnweb.FreeBSD.org/base/head/lib/libc/include/namespace.h?r1=214093&r2=218414 Can somebody from freebsd-hackers speak up? Or just give the correct diff for FreeBSD? I am stuck in this for now. I will take it up later. /stuff/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:1471: error: ISO C++ forbids variable-size array 'params' Here's what I got so far, small things all related to compile. Thanks, amit Index: include/lldb/Host/Host.h =================================================================== --- include/lldb/Host/Host.h (revision 131240) +++ include/lldb/Host/Host.h (working copy) @@ -352,6 +352,15 @@ static lldb::pid_t LaunchApplication (const FileSpec &app_file_spec); + static lldb::pid_t + LaunchInNewTerminal (const char *tty_name, + const char **argv, + const char **envp, + const char *working_dir, + const ArchSpec *arch_spec, + bool stop_at_entry, + bool disable_aslr); + static Error LaunchProcess (ProcessLaunchInfo &launch_info); Index: source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h =================================================================== --- source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h (revision 131240) +++ source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h (working copy) @@ -11,6 +11,9 @@ #define liblldb_PlatformRemoteGDBServer_h_ // C Includes +#if defined (__OpenBSD__) + #include +#endif // C++ Includes #include Index: source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h =================================================================== --- source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h (revision 131240) +++ source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h (working copy) @@ -72,7 +72,7 @@ dwarf_ymm4 = dwarf_xmm4, dwarf_ymm5 = dwarf_xmm5, dwarf_ymm6 = dwarf_xmm6, - dwarf_ymm7 = dwarf_xmm7, + dwarf_ymm7 = dwarf_xmm7 }; enum Index: source/Interpreter/OptionGroupFormat.cpp =================================================================== --- source/Interpreter/OptionGroupFormat.cpp (revision 131240) +++ source/Interpreter/OptionGroupFormat.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupFormat.h" +#include "lldb/Interpreter/OptionGroupFormat.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupValueObjectDisplay.cpp =================================================================== --- source/Interpreter/OptionGroupValueObjectDisplay.cpp (revision 131240) +++ source/Interpreter/OptionGroupValueObjectDisplay.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupValueObjectDisplay.h" +#include "lldb/Interpreter/OptionGroupValueObjectDisplay.h" // C Includes // C++ Includes @@ -123,4 +123,4 @@ // If we don't have any targets, then dynamic values won't do us much good. use_dynamic = lldb::eNoDynamicValues; } -} \ No newline at end of file +} Index: source/Interpreter/OptionGroupUInt64.cpp =================================================================== --- source/Interpreter/OptionGroupUInt64.cpp (revision 131240) +++ source/Interpreter/OptionGroupUInt64.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupUInt64.h" +#include "lldb/Interpreter/OptionGroupUInt64.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupOutputFile.cpp =================================================================== --- source/Interpreter/OptionGroupOutputFile.cpp (revision 131240) +++ source/Interpreter/OptionGroupOutputFile.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupOutputFile.h" +#include "lldb/Interpreter/OptionGroupOutputFile.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupUUID.cpp =================================================================== --- source/Interpreter/OptionGroupUUID.cpp (revision 131240) +++ source/Interpreter/OptionGroupUUID.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupUUID.h" +#include "lldb/Interpreter/OptionGroupUUID.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupBoolean.cpp =================================================================== --- source/Interpreter/OptionGroupBoolean.cpp (revision 131240) +++ source/Interpreter/OptionGroupBoolean.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupBoolean.h" +#include "lldb/Interpreter/OptionGroupBoolean.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupFile.cpp =================================================================== --- source/Interpreter/OptionGroupFile.cpp (revision 131240) +++ source/Interpreter/OptionGroupFile.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupFile.h" +#include "lldb/Interpreter/OptionGroupFile.h" // C Includes // C++ Includes Index: source/Interpreter/OptionGroupArchitecture.cpp =================================================================== --- source/Interpreter/OptionGroupArchitecture.cpp (revision 131240) +++ source/Interpreter/OptionGroupArchitecture.cpp (working copy) @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// -#include "OptionGroupArchitecture.h" +#include "lldb/Interpreter/OptionGroupArchitecture.h" // C Includes // C++ Includes Index: source/Host/common/Host.cpp =================================================================== --- source/Host/common/Host.cpp (revision 131240) +++ source/Host/common/Host.cpp (working copy) @@ -39,9 +39,10 @@ #include -#elif defined (__linux__) +#elif defined (__linux__) || defined (__OpenBSD__) || defined (__FreeBSD__) #include +#include #endif @@ -410,6 +411,8 @@ { #if defined (__APPLE__) return ::mach_thread_self(); +#elif defined (__OpenBSD__) || defined (__FreeBSD__) + return (uint64_t) (pthread_self()); #else return lldb::tid_t(pthread_self()); #endif Index: source/lldb.cpp =================================================================== --- source/lldb.cpp (revision 131240) +++ source/lldb.cpp (working copy) @@ -85,14 +85,14 @@ UnwindAssemblyInstEmulation::Initialize(); UnwindAssembly_x86::Initialize(); EmulateInstructionARM::Initialize (); - ABIMacOSX_i386::Initialize(); - ABIMacOSX_arm::Initialize(); - ABISysV_x86_64::Initialize(); #if defined (__APPLE__) //---------------------------------------------------------------------- // Apple/Darwin hosted plugins //---------------------------------------------------------------------- + ABIMacOSX_i386::Initialize(); + ABIMacOSX_arm::Initialize(); + ABISysV_x86_64::Initialize(); DynamicLoaderMacOSXDYLD::Initialize(); SymbolFileDWARFDebugMap::Initialize(); ItaniumABILanguageRuntime::Initialize(); @@ -152,11 +152,11 @@ UnwindAssembly_x86::Terminate(); UnwindAssemblyInstEmulation::Terminate(); EmulateInstructionARM::Terminate (); + +#if defined (__APPLE__) ABIMacOSX_i386::Terminate(); ABIMacOSX_arm::Terminate(); ABISysV_x86_64::Terminate(); - -#if defined (__APPLE__) DynamicLoaderMacOSXDYLD::Terminate(); SymbolFileDWARFDebugMap::Terminate(); ItaniumABILanguageRuntime::Terminate(); --000e0cd5d0ae35a14204a31b5198 Content-Type: application/octet-stream; name="lldb.diff" Content-Disposition: attachment; filename="lldb.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gnmj6p2u0 SW5kZXg6IGluY2x1ZGUvbGxkYi9Ib3N0L0hvc3QuaAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBpbmNsdWRlL2xs ZGIvSG9zdC9Ib3N0LmgJKHJldmlzaW9uIDEzMTI0MCkKKysrIGluY2x1ZGUvbGxkYi9Ib3N0L0hv c3QuaAkod29ya2luZyBjb3B5KQpAQCAtMzUyLDYgKzM1MiwxNSBAQAogICAgIHN0YXRpYyBsbGRi OjpwaWRfdAogICAgIExhdW5jaEFwcGxpY2F0aW9uIChjb25zdCBGaWxlU3BlYyAmYXBwX2ZpbGVf c3BlYyk7CiAKKyAgICBzdGF0aWMgbGxkYjo6cGlkX3QKKyAgICBMYXVuY2hJbk5ld1Rlcm1pbmFs IChjb25zdCBjaGFyICp0dHlfbmFtZSwKKwkJIAljb25zdCBjaGFyICoqYXJndiwKKwkJIAljb25z dCBjaGFyICoqZW52cCwKKwkJIAljb25zdCBjaGFyICp3b3JraW5nX2RpciwKKwkJCWNvbnN0IEFy Y2hTcGVjICphcmNoX3NwZWMsCisJCQlib29sIHN0b3BfYXRfZW50cnksCisJCQlib29sIGRpc2Fi bGVfYXNscik7CisKICAgICBzdGF0aWMgRXJyb3IKICAgICBMYXVuY2hQcm9jZXNzIChQcm9jZXNz TGF1bmNoSW5mbyAmbGF1bmNoX2luZm8pOwogICAgIApJbmRleDogc291cmNlL1BsdWdpbnMvUGxh dGZvcm0vZ2RiLXNlcnZlci9QbGF0Zm9ybVJlbW90ZUdEQlNlcnZlci5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHNvdXJjZS9QbHVnaW5zL1BsYXRmb3JtL2dkYi1zZXJ2ZXIvUGxhdGZvcm1SZW1vdGVHREJTZXJ2 ZXIuaAkocmV2aXNpb24gMTMxMjQwKQorKysgc291cmNlL1BsdWdpbnMvUGxhdGZvcm0vZ2RiLXNl cnZlci9QbGF0Zm9ybVJlbW90ZUdEQlNlcnZlci5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMSw2ICsx MSw5IEBACiAjZGVmaW5lIGxpYmxsZGJfUGxhdGZvcm1SZW1vdGVHREJTZXJ2ZXJfaF8KIAogLy8g QyBJbmNsdWRlcworI2lmIGRlZmluZWQgKF9fT3BlbkJTRF9fKQorICAjaW5jbHVkZSA8c3lzL3Bh cmFtLmg+CisjZW5kaWYKIC8vIEMrKyBJbmNsdWRlcwogI2luY2x1ZGUgPHN0cmluZz4KIApJbmRl eDogc291cmNlL1BsdWdpbnMvQUJJL01hY09TWC1pMzg2L0FCSU1hY09TWF9pMzg2LmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc291cmNlL1BsdWdpbnMvQUJJL01hY09TWC1pMzg2L0FCSU1hY09TWF9pMzg2LmgJ KHJldmlzaW9uIDEzMTI0MCkKKysrIHNvdXJjZS9QbHVnaW5zL0FCSS9NYWNPU1gtaTM4Ni9BQklN YWNPU1hfaTM4Ni5oCSh3b3JraW5nIGNvcHkpCkBAIC03Miw3ICs3Miw3IEBACiAgICAgICAgIGR3 YXJmX3ltbTQgPSBkd2FyZl94bW00LAogICAgICAgICBkd2FyZl95bW01ID0gZHdhcmZfeG1tNSwK ICAgICAgICAgZHdhcmZfeW1tNiA9IGR3YXJmX3htbTYsCi0gICAgICAgIGR3YXJmX3ltbTcgPSBk d2FyZl94bW03LAorICAgICAgICBkd2FyZl95bW03ID0gZHdhcmZfeG1tNwogICAgIH07CiAgICAg CiAgICAgZW51bQpJbmRleDogc291cmNlL0ludGVycHJldGVyL09wdGlvbkdyb3VwRm9ybWF0LmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBGb3JtYXQuY3Bw CShyZXZpc2lvbiAxMzEyNDApCisrKyBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBGb3Jt YXQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC03LDcgKzcsNyBAQAogLy8KIC8vPT09LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLT09PS8vCiAKLSNpbmNsdWRlICJPcHRpb25Hcm91cEZvcm1hdC5oIgorI2luY2x1ZGUgImxs ZGIvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBGb3JtYXQuaCIKIAogLy8gQyBJbmNsdWRlcwogLy8g QysrIEluY2x1ZGVzCkluZGV4OiBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBWYWx1ZU9i amVjdERpc3BsYXkuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25H cm91cFZhbHVlT2JqZWN0RGlzcGxheS5jcHAJKHJldmlzaW9uIDEzMTI0MCkKKysrIHNvdXJjZS9J bnRlcnByZXRlci9PcHRpb25Hcm91cFZhbHVlT2JqZWN0RGlzcGxheS5jcHAJKHdvcmtpbmcgY29w eSkKQEAgLTcsNyArNyw3IEBACiAvLwogLy89PT0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPT09Ly8KIAotI2luY2x1 ZGUgIk9wdGlvbkdyb3VwVmFsdWVPYmplY3REaXNwbGF5LmgiCisjaW5jbHVkZSAibGxkYi9JbnRl cnByZXRlci9PcHRpb25Hcm91cFZhbHVlT2JqZWN0RGlzcGxheS5oIgogCiAvLyBDIEluY2x1ZGVz CiAvLyBDKysgSW5jbHVkZXMKQEAgLTEyMyw0ICsxMjMsNCBAQAogICAgICAgICAvLyBJZiB3ZSBk b24ndCBoYXZlIGFueSB0YXJnZXRzLCB0aGVuIGR5bmFtaWMgdmFsdWVzIHdvbid0IGRvIHVzIG11 Y2ggZ29vZC4KICAgICAgICAgdXNlX2R5bmFtaWMgPSBsbGRiOjplTm9EeW5hbWljVmFsdWVzOwog ICAgIH0KLX0KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCit9CkluZGV4OiBzb3VyY2UvSW50 ZXJwcmV0ZXIvT3B0aW9uR3JvdXBVSW50NjQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNvdXJjZS9JbnRl cnByZXRlci9PcHRpb25Hcm91cFVJbnQ2NC5jcHAJKHJldmlzaW9uIDEzMTI0MCkKKysrIHNvdXJj ZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cFVJbnQ2NC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTcs NyArNyw3IEBACiAvLwogLy89PT0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPT09Ly8KIAotI2luY2x1ZGUgIk9wdGlv bkdyb3VwVUludDY0LmgiCisjaW5jbHVkZSAibGxkYi9JbnRlcnByZXRlci9PcHRpb25Hcm91cFVJ bnQ2NC5oIgogCiAvLyBDIEluY2x1ZGVzCiAvLyBDKysgSW5jbHVkZXMKSW5kZXg6IHNvdXJjZS9J bnRlcnByZXRlci9PcHRpb25Hcm91cE91dHB1dEZpbGUuY3BwCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNvdXJj ZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cE91dHB1dEZpbGUuY3BwCShyZXZpc2lvbiAxMzEyNDAp CisrKyBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBPdXRwdXRGaWxlLmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtNyw3ICs3LDcgQEAKIC8vCiAvLz09PS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS09PT0vLwogCi0j aW5jbHVkZSAiT3B0aW9uR3JvdXBPdXRwdXRGaWxlLmgiCisjaW5jbHVkZSAibGxkYi9JbnRlcnBy ZXRlci9PcHRpb25Hcm91cE91dHB1dEZpbGUuaCIKIAogLy8gQyBJbmNsdWRlcwogLy8gQysrIElu Y2x1ZGVzCkluZGV4OiBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBVVUlELmNwcAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBVVUlELmNwcAkocmV2aXNp b24gMTMxMjQwKQorKysgc291cmNlL0ludGVycHJldGVyL09wdGlvbkdyb3VwVVVJRC5jcHAJKHdv cmtpbmcgY29weSkKQEAgLTcsNyArNyw3IEBACiAvLwogLy89PT0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPT09Ly8K IAotI2luY2x1ZGUgIk9wdGlvbkdyb3VwVVVJRC5oIgorI2luY2x1ZGUgImxsZGIvSW50ZXJwcmV0 ZXIvT3B0aW9uR3JvdXBVVUlELmgiCiAKIC8vIEMgSW5jbHVkZXMKIC8vIEMrKyBJbmNsdWRlcwpJ bmRleDogc291cmNlL0ludGVycHJldGVyL09wdGlvbkdyb3VwQm9vbGVhbi5jcHAKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gc291cmNlL0ludGVycHJldGVyL09wdGlvbkdyb3VwQm9vbGVhbi5jcHAJKHJldmlzaW9u IDEzMTI0MCkKKysrIHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cEJvb2xlYW4uY3BwCSh3 b3JraW5nIGNvcHkpCkBAIC03LDcgKzcsNyBAQAogLy8KIC8vPT09LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT09PS8v CiAKLSNpbmNsdWRlICJPcHRpb25Hcm91cEJvb2xlYW4uaCIKKyNpbmNsdWRlICJsbGRiL0ludGVy cHJldGVyL09wdGlvbkdyb3VwQm9vbGVhbi5oIgogCiAvLyBDIEluY2x1ZGVzCiAvLyBDKysgSW5j bHVkZXMKSW5kZXg6IHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cEZpbGUuY3BwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cEZpbGUuY3BwCShyZXZpc2lv biAxMzEyNDApCisrKyBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBGaWxlLmNwcAkod29y a2luZyBjb3B5KQpAQCAtNyw3ICs3LDcgQEAKIC8vCiAvLz09PS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS09PT0vLwog Ci0jaW5jbHVkZSAiT3B0aW9uR3JvdXBGaWxlLmgiCisjaW5jbHVkZSAibGxkYi9JbnRlcnByZXRl ci9PcHRpb25Hcm91cEZpbGUuaCIKIAogLy8gQyBJbmNsdWRlcwogLy8gQysrIEluY2x1ZGVzCklu ZGV4OiBzb3VyY2UvSW50ZXJwcmV0ZXIvT3B0aW9uR3JvdXBBcmNoaXRlY3R1cmUuY3BwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cEFyY2hpdGVjdHVyZS5jcHAJ KHJldmlzaW9uIDEzMTI0MCkKKysrIHNvdXJjZS9JbnRlcnByZXRlci9PcHRpb25Hcm91cEFyY2hp dGVjdHVyZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTcsNyArNyw3IEBACiAvLwogLy89PT0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPT09Ly8KIAotI2luY2x1ZGUgIk9wdGlvbkdyb3VwQXJjaGl0ZWN0dXJlLmgiCisj aW5jbHVkZSAibGxkYi9JbnRlcnByZXRlci9PcHRpb25Hcm91cEFyY2hpdGVjdHVyZS5oIgogCiAv LyBDIEluY2x1ZGVzCiAvLyBDKysgSW5jbHVkZXMKSW5kZXg6IHNvdXJjZS9Ib3N0L2NvbW1vbi9I b3N0LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzb3VyY2UvSG9zdC9jb21tb24vSG9zdC5jcHAJKHJldmlz aW9uIDEzMTI0MCkKKysrIHNvdXJjZS9Ib3N0L2NvbW1vbi9Ib3N0LmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMzksOSArMzksMTAgQEAKICNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiAKIAotI2VsaWYg ZGVmaW5lZCAoX19saW51eF9fKQorI2VsaWYgZGVmaW5lZCAoX19saW51eF9fKSB8fCBkZWZpbmVk IChfX09wZW5CU0RfXykgfHwgZGVmaW5lZCAoX19GcmVlQlNEX18pCiAKICNpbmNsdWRlIDxzeXMv d2FpdC5oPgorI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KIAogI2VuZGlmCiAKQEAgLTQxMCw2ICs0 MTEsOCBAQAogewogI2lmIGRlZmluZWQgKF9fQVBQTEVfXykKICAgICByZXR1cm4gOjptYWNoX3Ro cmVhZF9zZWxmKCk7CisjZWxpZiBkZWZpbmVkIChfX09wZW5CU0RfXykgfHwgZGVmaW5lZCAoX19G cmVlQlNEX18pCisgICAgcmV0dXJuICh1aW50NjRfdCkgKHB0aHJlYWRfc2VsZigpKTsKICNlbHNl CiAgICAgcmV0dXJuIGxsZGI6OnRpZF90KHB0aHJlYWRfc2VsZigpKTsKICNlbmRpZgpJbmRleDog c291cmNlL2xsZGIuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNvdXJjZS9sbGRiLmNwcAkocmV2aXNpb24g MTMxMjQwKQorKysgc291cmNlL2xsZGIuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC04NSwxNCArODUs MTQgQEAKICAgICAgICAgVW53aW5kQXNzZW1ibHlJbnN0RW11bGF0aW9uOjpJbml0aWFsaXplKCk7 CiAgICAgICAgIFVud2luZEFzc2VtYmx5X3g4Njo6SW5pdGlhbGl6ZSgpOwogICAgICAgICBFbXVs YXRlSW5zdHJ1Y3Rpb25BUk06OkluaXRpYWxpemUgKCk7Ci0gICAgICAgIEFCSU1hY09TWF9pMzg2 OjpJbml0aWFsaXplKCk7Ci0gICAgICAgIEFCSU1hY09TWF9hcm06OkluaXRpYWxpemUoKTsKLSAg ICAgICAgQUJJU3lzVl94ODZfNjQ6OkluaXRpYWxpemUoKTsKIAogI2lmIGRlZmluZWQgKF9fQVBQ TEVfXykKICAgICAgICAgLy8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgIC8vIEFwcGxlL0RhcndpbiBo b3N0ZWQgcGx1Z2lucwogICAgICAgICAvLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAgICAgICAgQUJJTWFjT1NY X2kzODY6OkluaXRpYWxpemUoKTsKKyAgICAgICAgQUJJTWFjT1NYX2FybTo6SW5pdGlhbGl6ZSgp OworICAgICAgICBBQklTeXNWX3g4Nl82NDo6SW5pdGlhbGl6ZSgpOwogICAgICAgICBEeW5hbWlj TG9hZGVyTWFjT1NYRFlMRDo6SW5pdGlhbGl6ZSgpOwogICAgICAgICBTeW1ib2xGaWxlRFdBUkZE ZWJ1Z01hcDo6SW5pdGlhbGl6ZSgpOwogICAgICAgICBJdGFuaXVtQUJJTGFuZ3VhZ2VSdW50aW1l OjpJbml0aWFsaXplKCk7CkBAIC0xNTIsMTEgKzE1MiwxMSBAQAogICAgIFVud2luZEFzc2VtYmx5 X3g4Njo6VGVybWluYXRlKCk7CiAgICAgVW53aW5kQXNzZW1ibHlJbnN0RW11bGF0aW9uOjpUZXJt aW5hdGUoKTsKICAgICBFbXVsYXRlSW5zdHJ1Y3Rpb25BUk06OlRlcm1pbmF0ZSAoKTsKKworI2lm IGRlZmluZWQgKF9fQVBQTEVfXykKICAgICBBQklNYWNPU1hfaTM4Njo6VGVybWluYXRlKCk7CiAg ICAgQUJJTWFjT1NYX2FybTo6VGVybWluYXRlKCk7CiAgICAgQUJJU3lzVl94ODZfNjQ6OlRlcm1p bmF0ZSgpOwotCi0jaWYgZGVmaW5lZCAoX19BUFBMRV9fKQogICAgIER5bmFtaWNMb2FkZXJNYWNP U1hEWUxEOjpUZXJtaW5hdGUoKTsKICAgICBTeW1ib2xGaWxlRFdBUkZEZWJ1Z01hcDo6VGVybWlu YXRlKCk7CiAgICAgSXRhbml1bUFCSUxhbmd1YWdlUnVudGltZTo6VGVybWluYXRlKCk7Cg== --000e0cd5d0ae35a14204a31b5198-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 12 23:03:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1AE4106566B; Thu, 12 May 2011 23:03:28 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 744508FC1A; Thu, 12 May 2011 23:03:28 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 7E0B9359398; Fri, 13 May 2011 01:03:27 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 6AEE91736B; Fri, 13 May 2011 01:03:27 +0200 (CEST) Date: Fri, 13 May 2011 01:03:27 +0200 From: Jilles Tjoelker To: Lev Serebryakov Message-ID: <20110512230327.GA82602@stack.nl> References: <1649118429.20110512113812@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1649118429.20110512113812@serebryakov.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 23:03:28 -0000 On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: > Does FreeBSD have some custom call, which can be used where Linux > programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? > It is like madvise(2) but for file descriptors. An effect like POSIX_FADV_SEQUENTIAL can be obtained with the F_READAHEAD or F_RDAHEAD fcntl(2) requests. The implementation is divided between the generic VFS layer and various filesystems (cd9660, ext2fs, msdosfs, nfs, xfs and ufs appear to use the information to some degree). Setting readahead to 0 with the fcntl requests has little effect: it resets the state of the sequential access detection heuristic but does not disable it. The O_DIRECT open(2) flag has an effect similar to what POSIX_FADV_NOREUSE should do, except that it changes semantics by adding alignment restrictions. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 00:51:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDB5F106566C for ; Fri, 13 May 2011 00:51:35 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2F19B8FC14 for ; Fri, 13 May 2011 00:51:34 +0000 (UTC) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.160.140]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p4D0F2P4008491; Fri, 13 May 2011 02:15:02 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Fri, 13 May 2011 02:15:02 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105130215.02568.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: lldb-dev@cs.uiuc.edu, Amit Kulkarni , matthew@openbsd.org Subject: Re: lldb patches for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 00:51:35 -0000 On Friday 13 May 2011 00:00:28 Amit Kulkarni wrote: > It seems FreeBSD is also affected like OpenBSD about the thread id > issue discussed a month before in this thread. I am cc'ing matthew@ > just to keep him in the loop. > http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000444.html Check out this code from FreeBSD's OpenJDK6 port: #if __FreeBSD_version > 900030 return pthread_getthreadid_np(); #else long tid; thr_self(&tid); return (pid_t)tid; #endif The underlying type of a tid (lwpid_t in kernel) is an int. -- Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 06:21:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 903EA106566B; Fri, 13 May 2011 06:21:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3B08FC0A; Fri, 13 May 2011 06:21:10 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2d19:d22d:b020:7e1b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0CA904AC1C; Fri, 13 May 2011 10:21:07 +0400 (MSD) Date: Fri, 13 May 2011 10:21:01 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <829202538.20110513102101@serebryakov.spb.ru> To: Jilles Tjoelker In-Reply-To: <20110512230327.GA82602@stack.nl> References: <1649118429.20110512113812@serebryakov.spb.ru> <20110512230327.GA82602@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Lev Serebryakov Subject: Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 06:21:10 -0000 Hello, Jilles. You wrote 13 =EC=E0=FF 2011 =E3., 3:03:27: >> It is like madvise(2) but for file descriptors. > An effect like POSIX_FADV_SEQUENTIAL can be obtained with the > F_READAHEAD or F_RDAHEAD fcntl(2) requests. The implementation is > divided between the generic VFS layer and various filesystems (cd9660, > ext2fs, msdosfs, nfs, xfs and ufs appear to use the information to some > degree). Does read ahead turned on by default (for UFS), as here is vfs.read_max? Or vfs.read_max is only "upper bound" for F_READAHEAD and it is turned off by default completely? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 07:58:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB83106566C for ; Fri, 13 May 2011 07:58:22 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DC8D28FC0A for ; Fri, 13 May 2011 07:58:21 +0000 (UTC) Received: by wwc33 with SMTP id 33so2530914wwc.31 for ; Fri, 13 May 2011 00:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=z7A0CK4VvhML/3e7OUcytDZizB8Ikwyl0Nj3ubDyg5c=; b=fM7oXllfg5dcPe21YHUqjyRL4PX562AXHYFP/Wcoe3ElrdJdXfeOfFhFTMLNJBLLdt T+llVpL0ZZXTr2Pnms+GNvj80vTV7MC2/rA92P0EJPcmH+kkEx3ZHlMTly75oyqNmxY5 xDL/kyfZHy6o/YOoo7PJzsg5R5uysTOYhvsJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=nXGhsQVCuMUTsXW/b7Uk9HTNBVAmjB0rrH9gc8jXboeMAV2G+O2BR4eo7tlWzXGmNu j4HdstO7PIRfe/XtwW6sRsm5UNLsD3UVph9CBSiujhT32UQCZovxzRTFhjg9N1LZ0XXY gmHe80D0Wbh7Vm4PDFl3jxGqoIYfAGOwCSwUc= Received: by 10.227.5.210 with SMTP id 18mr1138764wbw.18.1305272061471; Fri, 13 May 2011 00:34:21 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id ca12sm1197750wbb.36.2011.05.13.00.34.20 (version=SSLv3 cipher=OTHER); Fri, 13 May 2011 00:34:20 -0700 (PDT) Date: Fri, 13 May 2011 10:33:31 +0300 From: Gleb Kurtsou To: Zafer =?utf-8?Q?Aydo=C4=9Fan?= Message-ID: <20110513073331.GA2059@tops> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: OpenGrok for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 07:58:22 -0000 On (12/05/2011 22:45), Zafer Aydoğan wrote: > Hello List, > > I've set up an OpenGrok service for the FreeBSD sources (current). > OpenGrok is a source code search engine and cross reference. > I'm updating the sources once a day. I'm a NetBSD developer and I'm > also maintaining http://nxr.netbsd.org > > Feel free to use it: > http://fxr.aydogan.net Thanks! What do you think about having index for different kernels in one place like now defunct http://grok.x12.su/source/ or http://fxr.watson.org/fxr/source/?v=HEAD > > Cheers, Zafer. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 09:41:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C481C1065670 for ; Fri, 13 May 2011 09:41:46 +0000 (UTC) (envelope-from zafer@aydogan.de) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A30D8FC0C for ; Fri, 13 May 2011 09:41:45 +0000 (UTC) Received: by qwc9 with SMTP id 9so1593261qwc.13 for ; Fri, 13 May 2011 02:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.69.213 with SMTP id a21mr958317qcj.222.1305279704778; Fri, 13 May 2011 02:41:44 -0700 (PDT) Received: by 10.229.75.76 with HTTP; Fri, 13 May 2011 02:41:44 -0700 (PDT) In-Reply-To: <20110513073331.GA2059@tops> References: <20110513073331.GA2059@tops> Date: Fri, 13 May 2011 11:41:44 +0200 Message-ID: From: =?UTF-8?Q?Zafer_Aydo=C4=9Fan?= To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: OpenGrok for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:41:46 -0000 2011/5/13 Gleb Kurtsou : > On (12/05/2011 22:45), Zafer Aydo=C4=9Fan wrote: >> Hello List, >> >> I've set up an OpenGrok service for the FreeBSD sources (current). >> OpenGrok is a source code search engine and cross reference. >> I'm updating the sources once a day. I'm a NetBSD developer and I'm >> also maintaining http://nxr.netbsd.org >> >> Feel free to use it: >> http://fxr.aydogan.net > Thanks! > > What do you think about having index for different kernels in one place > like now defunct http://grok.x12.su/source/ or > http://fxr.watson.org/fxr/source/?v=3DHEAD > That's possible, but OpenGrok contains the whole source tree and not only the kernel. Therefore I would group it with ports/, projects/, www/. etc. I didn't know about grok.x12.su, but I see its broken anyway. Zafer. From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 10:34:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880CC106566B; Fri, 13 May 2011 10:34:22 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03A5B8FC19; Fri, 13 May 2011 10:34:21 +0000 (UTC) Received: by qwc9 with SMTP id 9so1618034qwc.13 for ; Fri, 13 May 2011 03:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4RrG6JR8DyOl1hB5I1Tk17zLteYgUvUDLkmCk1xRRyc=; b=hAEUZcRBicWDn5S+v+RSZQTgkXI4z3i5NCrIyVrqVGuu0PrF5GTDPZ8vohn9BxBRWN qdrBT9eeWZASBnSzq9cg3fIU1VUx2S0rdWzAGY60HxzyUynr/P5sJclvA3mcYkGSFnlX OKk1YdrPE/IJPUKQYkFy2fIXab/ThRqD3dhTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IhE/A+bzy0kCid8+JOmh5i6rXmitNwOZTCBjQrFFYcDAqXDe3GPJ6ICdWrPvpsvEst 0+P1zIoueGFIGH4mrL8/ek2oSigih4xTg1I2eNwfR9Ngfnq92PM6LO4B5e39T2FhqeBD 3DakFBV6wIuXq+OGt6YIp1WKdOLH6ZmtvyPhU= MIME-Version: 1.0 Received: by 10.229.127.81 with SMTP id f17mr1009062qcs.138.1305281525100; Fri, 13 May 2011 03:12:05 -0700 (PDT) Received: by 10.229.217.69 with HTTP; Fri, 13 May 2011 03:12:05 -0700 (PDT) In-Reply-To: <20110508191336.GC3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> Date: Fri, 13 May 2011 12:12:05 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:34:22 -0000 Hi, 2011/5/8 Jason Hellenthal > > List, - Please reply-to freebsd-rc@freebsd.org > > What does it do ?: As stated above, current functionality is undisturbed > while allowing the user to create config's by any name they so desire as > long as it has an extension of ".conf", also introducing the ability to > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > seams not to be included in your patch, unless you change the line (or i'm wrong): if [ -f "$_modular_conf" ]; then by if [ -x "$_modular_conf" ]; then > > > Why ? Simple. How many times have you been bitten by disabling something > in the rc.conf file and left to discover what you just disabled was also > used by another daemon but that daemon is now not starting ? This is a way > to virtualize your configuration allowing you to add multiple _enable= > lines to different configurations for different roles. For instance > rpcbind is used by both samba and nfs*. With this you can add > rpcbind_enable to both a configuration for samba and nfs and when you > disable one service you know that you have not disabled a dependent for > another. > i resolved that by making multiple files source the same conf file. today my biggest problem is bad rc.d script like apache22, postfix, clamd or haproxy who load_rc_config and after overwrite extra_commands variable. this prevent me to add extra commands from a /etc/rc.conf.d/$name file. From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 11:27:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E70106566B; Fri, 13 May 2011 11:27:44 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC528FC14; Fri, 13 May 2011 11:27:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so2808957iyj.13 for ; Fri, 13 May 2011 04:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=7/LGFur01hlcyl97RqTGdE4WDo0qRTosBXigD5mkL1w=; b=T+xFJUKvCQxQSdxkmjO/YGgGR+yWgwFI684w2IUj9en3smhSFopHLg+kiOdyxoRYcj PF5V9BlnMp8Dsf4deSrajaGKLtXqqhmV0yco1VA7tP6iNBt3M2KQ97k0lkkG+yawnRRu QT249b/GZ6opZ+kj1WwHjMZf/JIaX2rL4QyJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=R7wlpZByJehQ/de+eZ2PbmUEhslBSldC7keU1QESksIW8leo0zQaoANLGUDoo9OdhJ Yk+nS1OBkYu3pl/IXXiGgmNvlfYz76q6ARpGREU/UIsIwWAi3JGCTef9Z40bGzggedXw EMUxUoYtOhCZdL7QeqT0yNblLwzWl0W+A/NP8= Received: by 10.42.157.67 with SMTP id c3mr1528648icx.95.1305286063703; Fri, 13 May 2011 04:27:43 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net [99.190.81.196]) by mx.google.com with ESMTPS id t1sm931523ibm.38.2011.05.13.04.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 04:27:42 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4DBRd9i004608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 07:27:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4DBRcPA004607; Fri, 13 May 2011 07:27:38 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 13 May 2011 07:27:38 -0400 From: Jason Hellenthal To: =?iso-8859-1?Q?Micka=EBl?= Maillot Message-ID: <20110513112738.GA2720@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-rc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 11:27:45 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Micka=EBl, On Fri, May 13, 2011 at 12:12:05PM +0200, Micka=EBl Maillot wrote: > Hi, >=20 > 2011/5/8 Jason Hellenthal >=20 > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > What does it do ?: As stated above, current functionality is undisturbed > > while allowing the user to create config's by any name they so desire as > > long as it has an extension of ".conf", also introducing the ability to > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > >=20 > seams not to be included in your patch, unless you change the line (or i'm > wrong): > if [ -f "$_modular_conf" ]; then > by > if [ -x "$_modular_conf" ]; then >=20 The one you downloaded here used to be this one: http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch?r=3Dbf83c= 231337642f925d6c732ba8c8b070480631e But since alot of slack was coming back on the use of the -x bit it was removed. >=20 > > > > > > Why ? Simple. How many times have you been bitten by disabling something > > in the rc.conf file and left to discover what you just disabled was also > > used by another daemon but that daemon is now not starting ? This is a = way > > to virtualize your configuration allowing you to add multiple _enable=3D > > lines to different configurations for different roles. For instance > > rpcbind is used by both samba and nfs*. With this you can add > > rpcbind_enable to both a configuration for samba and nfs and when you > > disable one service you know that you have not disabled a dependent for > > another. > > >=20 > i resolved that by making multiple files source the same conf file. >=20 > today my biggest problem is bad rc.d script > like apache22, postfix, clamd or haproxy who load_rc_config and after > overwrite extra_commands variable. > this prevent me to add extra commands from a /etc/rc.conf.d/$name file. --=20 Regards, (jhell) Jason Hellenthal --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNzRWpAAoJEJBXh4mJ2FR+dbEH/jCyY0qY5Mh2lke9bxeGrRPy qul0Bjy3RhSuREYNZnW3VgOxpzEatV6S1sz3USYutHIN0V6mOxRHxnBRe9D1Ri2k FCRXh9ZcIlRuAKgQeDit+RscwV9PIH8MFNuox4T1eRunNa/lOKb7jZqJkbe7mK+v J6egWqZL/QwEHt2mC1MrhnGpfWpGZYgRA+xTka5StRVgi16doAg7Bu15ncrBvUI0 UXc4VIuVO3Gl/cO59FRU4DxSp7MQ2wnIA96cRsJmnJC46k4EhyfKQWwBoPqUwUsi 3VKRtobNnrDMPHB1f8Oq/KNKPFokQhkD4qQKbJz56S3X3x9o+mlelOMQQtUQwWA= =Ztl4 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 13 22:04:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D051065670 for ; Fri, 13 May 2011 22:04:25 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id E95488FC1B for ; Fri, 13 May 2011 22:04:24 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p4DM4LjT002508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 13 May 2011 15:04:24 -0700 (PDT) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 May 2011 15:04:24 -0700 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Fri, 13 May 2011 22:18:07 +0000 Subject: 2011 USENIX Annual Technical Conference Program Now Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 22:04:25 -0000 We're pleased to invite you to attend the 2011 USENIX Annual Technical Conference (USENIX ATC '11): http://www.usenix.org/atc11/proga USENIX ATC '11 is again part of the USENIX Federated Conferences Week. Not only do you get a 3-day conference program filled with the latest systems research, but you'll also have increased opportunities to network with peers across multiple disciplines. The technical program begins on Wednesday, June 15, and includes refereed papers, invited talks, and a poster session. http://www.usenix.org/events/atc11/tech/ The impressive slate of invited speakers includes: - Keynote Address: "An Agenda for Empirical Cyber Crime Research," by Stefan Savage, UCSD - Plenary Talk: "Dead Media: What the Obsolete, Unsuccessful, Experimental, and Avant-Garde Can Teach Us About the Future of Media," by Finn Brunton, NYU - "Helping Humanity with Phones and Clouds," by Matthew Faulkner and Michael Olson, Caltech - "Linux PC Robot," by Mark Woodward, Mohawksoft The USENIX ATC '11 Refereed Papers present the latest in groundbreaking systems research. Be among the first to check out the latest innovative work in the systems field. A joint Poster Session and Happy Hour between USENIX ATC '11 and WebApps '11 will be held on the evening of Wednesday, June 15. The poster session is an excellent forum to discuss new ideas and get useful feedback from the community. Poster submissions are due May 13, 2011. http://www.usenix.org/events/atc11/poster.html Finally, don't miss the opportunity to mingle with colleagues and leading experts in the combined Birds-of-a-Feather sessions and at the various evening social events, including the joint poster session, vendor BoFs, and receptions. http://www.usenix.org/events/fcw11/activities.html The full program is available at: http://www.usenix.org/events/atc11/tech/ Register by May 23, 2011, for the greatest savings. http://www.usenix.org/events/fcw11/registration/ USENIX ATC '11 promises to be an exciting showcase for the latest in innovative research and cutting-edge practices in technology. We look forward to seeing you in Portland. On behalf of the USENIX ATC '11 Program Committee, Jason Nieh, Columbia University Carl Waldspurger USENIX ATC '11 Program Chairs atc11chairs@usenix.org P.S. Connect with other attendees, check out additional discounts, and help spread the word! Facebook: http://www.facebook.com/event.php?eid=176554335729285 Twitter: http://twitter.com/usenix #ATC11 Additional Discounts: http://www.usenix.org/events/fcw11/discounts.html Help Promote: http://www.usenix.org/events/atc11/promote.html ---------------------------------------------- 2011 USENIX Annual Technical Conference June 15-17, 2011, Portland, OR http://www.usenix.org/atc11/proga Early Bird Registration Deadline: May 23, 2011 Part of USENIX Federated Conferences Week http://www.usenix.org/fcw11 ----------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 01:23:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28123106564A for ; Sat, 14 May 2011 01:23:29 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id E26BB8FC16 for ; Sat, 14 May 2011 01:23:28 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4E1NBf0003363; Fri, 13 May 2011 20:23:11 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Fri, 13 May 2011 20:23:29 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 20:23:11 -0500 Received: from dtwin ([10.132.254.135]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 20:23:10 -0500 From: "Devin Teske" To: Date: Fri, 13 May 2011 18:22:15 -0700 Organization: Vicor, Inc. Message-ID: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AcwRtqQ1+OFGy+9xTqiRZ703u7lq+A== Content-Language: en-us X-OriginalArrivalTime: 14 May 2011 01:23:10.0713 (UTC) FILETIME=[7CD7DE90:01CC11D5] Cc: Julian Elischer , "Teske, Devin" , 'Dieter BSD' , =?gb2312?B?J8C8x+Un?= , 'Alexander Leidinger' Subject: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 01:23:29 -0000 Happy to bring to you version 1.5 of my loader_menu package. This version incorporates the suggestions first made by Lan Qing and then re-affirmed by (in-order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings word from the devsummit as well as Warner Losh): you guys want to separate the boot "actions" from the boot "options", and now it's accomplished. Here's how the re-arrangement looks for each of the different loader environments... i386-compatible hardware with ACPI support: http://twitpic.com/4wvls8 http://twitpic.com/4wvn0f (color) i386-compatible hardware without ACPI support: http://twitpic.com/4wvmod http://twitpic.com/4wvn0f (color) non-i386 hardware (such as IA64, PPC, etc.): http://twitpic.com/4wvne3 http://twitpic.com/4wvod5 (color) Here's the links: http://druidbsd.sourceforge.net/download/loader_menu-1.5.tgz or http://druidbsd.sourceforge.net/ Here's a diff of the changes: diff -rNup loader_menu-1.4/+CONTENTS loader_menu-1.5/+CONTENTS --- loader_menu-1.4/+CONTENTS 2011-05-05 00:47:31.000000000 -0700 +++ loader_menu-1.5/+CONTENTS 2011-05-12 16:07:11.000000000 -0700 @@ -1,5 +1,5 @@ @comment PKG_FORMAT_REVISION:1.1 -@name loader_menu-1.4 +@name loader_menu-1.5 @comment ORIGIN:sysutils/loader_menu @cwd /boot beastie.4th @@ -17,9 +17,9 @@ loader.rc menu-commands.4th @comment MD5:0999bd50b8395098bd6bcf9165db4d7b menu.4th -@comment MD5:26a61c0ea268334687a63e07b0d708d8 +@comment MD5:3b97638b4a5608fab425e2751d386c14 menu.rc -@comment MD5:dcf2993118b991f57b4ab0659d2712ae +@comment MD5:f682160708bcf5a537421ab09ce51660 shortcuts.4th @comment MD5:9a5ed52548bbbaf67ad613e37d0e4b58 version.4th @@ -30,7 +30,7 @@ version.4th @comment MD5:69903862d8df34df77522792172b0999 @ignore +DESC -@comment MD5:d18419e5babe54b7cc195da7f7f5ac86 +@comment MD5:597ef7a6779d9e083140eaa985fc1ee1 @ignore +INSTALL @comment MD5:76c98eb5e084871d9fe5d4fa4511d8c5 diff -rNup loader_menu-1.4/+DESC loader_menu-1.5/+DESC --- loader_menu-1.4/+DESC 2011-05-04 12:11:31.000000000 -0700 +++ loader_menu-1.5/+DESC 2011-05-12 13:50:40.000000000 -0700 @@ -91,6 +91,11 @@ loader_delay="N" until booting the loaded kernel). During the autoboot sequence, any key pressed except for ENTER will allow escaping to the loader prompt. +loader_menu_title="..." + + Overrides the default title ("Welcome to FreeBSD") displayed above the + dynamic menu. + WWW: http://druidbsd.sourceforge.net/ diff -rNup loader_menu-1.4/menu.4th loader_menu-1.5/menu.4th --- loader_menu-1.4/menu.4th 2011-05-05 00:33:13.000000000 -0700 +++ loader_menu-1.5/menu.4th 2011-05-12 16:07:06.000000000 -0700 @@ -75,7 +75,9 @@ variable menukey6 variable menukey7 variable menukey8 variable menureboot +variable menurebootadded variable menuacpi +variable menuoptions \ Menu timer [count-down] variables variable menu_timeout_enabled \ timeout state (internal use only) @@ -439,7 +441,10 @@ create init_text8 255 allot : menu-create ( -- ) \ Print the frame caption at (x,y) - 11 9 at-xy ." FreeBSD Kernel Options" + s" loader_menu_title" getenv dup -1 = if + drop s" Welcome to FreeBSD" + then + 24 over 2 / - 9 at-xy type \ Print our menu options with respective key/variable associations. \ `printmenuitem' ends by adding the decimal ASCII value for the @@ -478,8 +483,39 @@ create init_text8 255 allot then then + \ + \ Initialize the menu_options visual separator. + \ + 0 menuoptions ! + s" menu_options" getenv -1 <> if + c@ dup 48 > over 57 < and if ( '1' <= c1 <= '8' ) + menuoptions ! + else + drop + then + then + + \ Initialize "Reboot" menu state variable (prevents double-entry) + false menurebootadded ! + 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin + \ If the "Options:" separator, print it. + dup menuoptions @ = if + \ Optionally add a reboot option to the menu + s" menu_reboot" getenv -1 <> if + drop + s" Reboot" printmenuitem menureboot ! + true menurebootadded ! + then + + menuX @ + menurow @ 2 + menurow ! + menurow @ menuY @ + + at-xy + ." Options:" + then + \ If this is the ACPI menu option, act accordingly. dup menuacpi @ = if acpimenuitem ( -- C-Addr | -1 ) @@ -520,14 +556,16 @@ create init_text8 255 allot drop \ iterator \ Optionally add a reboot option to the menu - s" menu_reboot" getenv -1 <> if - drop \ no need for the value - s" Reboot" \ menu caption (required by printmenuitem) + menurebootadded @ true <> if + s" menu_reboot" getenv -1 <> if + drop \ no need for the value + s" Reboot" \ menu caption (required by printmenuitem) - printmenuitem - menureboot ! - else - 0 menureboot ! + printmenuitem + menureboot ! + else + 0 menureboot ! + then then ; @@ -787,7 +825,7 @@ create init_text8 255 allot evaluate rot tuck = if \ Adjust for missing ACPI menuitem on non-i386 - arch-i386? negate 1- menuacpi @ 0<> and if + arch-i386? true <> menuacpi @ 0<> and if menuacpi @ over 2dup < -rot = or over 58 < and if ( key >= menuacpi && key < 58: N -- N ) @@ -821,7 +859,7 @@ create init_text8 255 allot then \ Re-adjust for missing ACPI menuitem - arch-i386? negate 1- menuacpi @ 0<> and if + arch-i386? true <> menuacpi @ 0<> and if swap menuacpi @ 1+ over 2dup < -rot = or over 59 < and if diff -rNup loader_menu-1.4/menu.rc loader_menu-1.5/menu.rc --- loader_menu-1.4/menu.rc 2011-05-04 22:53:26.000000000 -0700 +++ loader_menu-1.5/menu.rc 2011-05-12 13:45:00.000000000 -0700 @@ -23,43 +23,50 @@ set menu_command[1]="boot" set ansi_caption[1]="Boot [ENTER]" set menu_keycode[1]="98" -set menu_caption[2]="[A]CPI Support: Disabled" -set toggled_text[2]="[A]CPI Support: Enabled" -set menu_command[2]="toggle_acpi" -set menu_keycode[2]="97" -set menu_acpi=2 -set ansi_caption[2]="ACPI Support: Disabled" -set toggled_ansi[2]="ACPI Support: Enabled" - -set menu_caption[3]="Boot Safe [M]ode: NO" -set toggled_text[3]="Boot Safe [M]ode: YES" -set menu_command[3]="toggle_safemode" -set menu_keycode[3]="109" -set ansi_caption[3]="Boot Safe Mode: NO" -set toggled_ansi[3]="Boot Safe Mode: YES" - -set menu_caption[4]="Boot [S]ingle User: NO" -set toggled_text[4]="Boot [S]ingle User: YES" -set menu_command[4]="toggle_singleuser" -set menu_keycode[4]="115" -set ansi_caption[4]="Boot Single User: NO" -set toggled_ansi[4]="Boot Single User: YES" - -set menu_caption[5]="Boot [V]erbose: NO" -set toggled_text[5]="Boot [V]erbose: YES" -set menu_command[5]="toggle_verbose" -set menu_keycode[5]="118" -set ansi_caption[5]="Boot Verbose: NO" -set toggled_ansi[5]="Boot Verbose: YES" - -set menu_caption[6]="[Esc]ape to loader prompt" -set menu_command[6]="goto_prompt" -set menu_keycode[6]="27" -set ansi_caption[6]="Escape to loader prompt" +set menu_caption[2]="[Esc]ape to loader prompt" +set menu_command[2]="goto_prompt" +set menu_keycode[2]="27" +set ansi_caption[2]="Escape to loader prompt" \ Enable built-in "Reboot" trailing menuitem +\ NOTE: appears before menu_options if configured +\ set menu_reboot +\ Enable "Options:" separator. When set to a numerical value (1-8), a visual +\ separator is inserted before that menuitem number. +\ +set menu_options=4 + +set menu_caption[4]="[A]CPI Support: Disabled" +set toggled_text[4]="[A]CPI Support: Enabled" +set menu_command[4]="toggle_acpi" +set menu_keycode[4]="97" +set menu_acpi=4 +set ansi_caption[4]="ACPI Support: Disabled" +set toggled_ansi[4]="ACPI Support: Enabled" + +set menu_caption[5]="Boot Safe [M]ode: NO" +set toggled_text[5]="Boot Safe [M]ode: YES" +set menu_command[5]="toggle_safemode" +set menu_keycode[5]="109" +set ansi_caption[5]="Boot Safe Mode: NO" +set toggled_ansi[5]="Boot Safe Mode: YES" + +set menu_caption[6]="Boot [S]ingle User: NO" +set toggled_text[6]="Boot [S]ingle User: YES" +set menu_command[6]="toggle_singleuser" +set menu_keycode[6]="115" +set ansi_caption[6]="Boot Single User: NO" +set toggled_ansi[6]="Boot Single User: YES" + +set menu_caption[7]="Boot [V]erbose: NO" +set toggled_text[7]="Boot [V]erbose: YES" +set menu_command[7]="toggle_verbose" +set menu_keycode[7]="118" +set ansi_caption[7]="Boot Verbose: NO" +set toggled_ansi[7]="Boot Verbose: YES" + \ Enable automatic booting (add ``autoboot_delay=N'' to loader.conf(5) to \ customize the timeout; default is 10-seconds) \ -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 01:34:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58055106564A for ; Sat, 14 May 2011 01:34:39 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAE28FC0A for ; Sat, 14 May 2011 01:34:37 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4E1YRtF018121; Fri, 13 May 2011 20:34:27 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Fri, 13 May 2011 20:34:30 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 20:34:27 -0500 Received: from dtwin ([10.132.254.135]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 20:34:26 -0500 From: "Devin Teske" To: References: In-Reply-To: Date: Fri, 13 May 2011 18:33:30 -0700 Organization: Vicor, Inc. Message-ID: <00c101cc11d6$ef3dcca0$cdb965e0$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJITk2XGns8cSzkkbWrBzzYl9zhw5OTD+DQ Content-Language: en-us X-OriginalArrivalTime: 14 May 2011 01:34:26.0269 (UTC) FILETIME=[0F8188D0:01CC11D7] Cc: Julian Elischer , "Teske, Devin" , 'Dieter BSD' , =?gb2312?B?J8C8x+Un?= , 'Alexander Leidinger' Subject: RE: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 01:34:39 -0000 > -----Original Message----- > From: Devin Teske [mailto:dteske@vicor.com] > Sent: Friday, May 13, 2011 6:22 PM > To: freebsd-hackers@freebsd.org > Cc: '=C0=BC=C7=E5'; 'Alexander Leidinger'; 'Dieter BSD'; Teske, Devin > (Devin.Teske@fisglobal.com); Julian Elischer (jelischer@fusionio.com); 'W= arner > Losh' > Subject: [RELEASE] New Boot-Loader Menu -- version 1.5 >=20 > Happy to bring to you version 1.5 of my loader_menu package. This version > incorporates the suggestions first made by Lan Qing and then re-affirmed = by (in- > order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings = word > from the devsummit as well as Warner Losh): you guys want to separate the= boot > "actions" from the boot "options", and now it's accomplished. >=20 > Here's how the re-arrangement looks for each of the different loader > environments... i386-compatible hardware with ACPI support: http://twitpic.com/4wvls8 http://twitpic.com/4wvm73 (color) i386-compatible hardware without ACPI support: http://twitpic.com/4wvmod http://twitpic.com/4wvn0f non-i386 (such as IA64, PPC, etc.): http://twitpic.com/4wvne3 http://twitpic.com/4wvod5 (color) NOTE: Previous links were incorrect. Above are the correct links to the cor= rect images. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 07:30:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38A9106564A for ; Sat, 14 May 2011 07:30:27 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6A64C8FC0C for ; Sat, 14 May 2011 07:30:27 +0000 (UTC) Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 0A09C1C08DE7; Sat, 14 May 2011 09:15:05 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id EE25A1C000EC; Sat, 14 May 2011 09:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id EnMhyv0WvE16; Sat, 14 May 2011 09:15:05 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-35-76.dynamic.mnet-online.de [93.104.35.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Sat, 14 May 2011 09:15:05 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 080A331209; Sat, 14 May 2011 09:15:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id E4D9331206; Sat, 14 May 2011 09:15:02 +0200 (CEST) Date: Sat, 14 May 2011 09:15:02 +0200 (CEST) From: Michael Reifenberger To: Devin Teske In-Reply-To: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> Message-ID: References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 07:30:27 -0000 Hi, this looks very promising! While you are working on the loader front currently, would it be possible to implement a "Boot kernel.old" menue item that unloads all current loaded modules and re-loads everithing from /boot/kernel.old? Its difficult to handle manually in the loader (esp. handling the zpool.cache file ) and I got bitten by this issue recently in a ZFS only environment. Thanks in advance! Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 15:43:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34578106564A for ; Sat, 14 May 2011 15:43:23 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DA7B88FC19 for ; Sat, 14 May 2011 15:43:22 +0000 (UTC) Received: by qwc9 with SMTP id 9so2238201qwc.13 for ; Sat, 14 May 2011 08:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zp6rMYF19dXmTTPEa2UaXPalrNZ2b/vR3Zs7ttcG6Qg=; b=eRCHw812fMJPk8eOVgYf5lmybbETrm/Apuh7vUzjLZ9M9aewBx6DbzI4nWJljGKtkr jfljULfiVbPs5lP6vdnY5Y7n1OGj5pFBpQ67mA4GbzCkFgkPWAkfExV6nNfm0MEckwNk sa00XCY3vVbgZC6VuodvaN3bBKE5+njmk9O4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uoslpGOKo4tQ1bdrL5h5UHx5TSJB5R9MRmd8U+C9ylubPBz1h/VGZXl/AsU6mY0gQU X5XHktLnaQXf+db5bZZgmjJyuW5L+hF9CiYpYPWxevLlFe8vSElTkBBvsc4sW++LimNl v5wsmAhaXNBvIIG2JxCFD1Al8KKNdQyBUOibU= MIME-Version: 1.0 Received: by 10.224.189.78 with SMTP id dd14mr2101244qab.136.1305386064862; Sat, 14 May 2011 08:14:24 -0700 (PDT) Received: by 10.224.20.3 with HTTP; Sat, 14 May 2011 08:14:24 -0700 (PDT) In-Reply-To: References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> Date: Sat, 14 May 2011 11:14:24 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Michael Reifenberger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Devin Teske Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 15:43:23 -0000 On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger wrote: > Hi, > this looks very promising! > > While you are working on the loader front currently, > would it be possible to implement a "Boot kernel.old" > menue item that unloads all current loaded modules and re-loads > everithing from /boot/kernel.old? > > Its difficult to handle manually in the loader (esp. handling the > zpool.cache file ) and I got bitten by this issue recently in a ZFS only > environment. > > Thanks in advance! > > Bye/2 > --- > Michael Reifenberger > Michael@Reifenberger.com > http://www.Reifenberger.com > > Many of the Unix/Linux operating systems are utilizing a Kernel Selection ( let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or , in FreeBSD , when Kernel Selection menu is selected instead of booting directly from boot sector . Actually , a Kernel Selection menu in front of the Boot Loader menu is a more flexible method : First select kernel , then select its booting structure with the above described Boot Loader menu . My opinion is that , they should NOT be COMBINED into one single menu , because , in the same system , even there may be other kernels to be booted . Some operating systems , such as OpenSolaris and Mandriva Linux , after updating the kernel , they are keeping previous kernel in the Kernel Selection menu , under the new kernel name item . Such a system may be employed for the FreeBSD : If a kernel.old is generated , it may be inserted into Kernel Selection menu automatically . If , at present , there is no kernel selection menu but boot sector is used directly , kernel build system may modify that structure also to utilize a Kernel Selection menu . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 18:53:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B67106566B for ; Sat, 14 May 2011 18:53:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EFB388FC0A for ; Sat, 14 May 2011 18:53:27 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4EIrQIW030705; Sat, 14 May 2011 13:53:26 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Sat, 14 May 2011 13:53:45 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 May 2011 13:53:26 -0500 Received: from [10.0.0.105] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 May 2011 13:53:25 -0500 References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8H7) Message-Id: <24057187-9777-4CFF-92D1-1D6103B35280@vicor.com> X-Mailer: iPad Mail (8H7) From: Devin Teske Date: Sat, 14 May 2011 11:53:56 -0700 To: Mehmet Erol Sanliturk X-OriginalArrivalTime: 14 May 2011 18:53:25.0831 (UTC) FILETIME=[34C7CD70:01CC1268] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 18:53:28 -0000 On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk wrote: > On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger wrote: > Hi, > this looks very promising! >=20 > While you are working on the loader front currently, > would it be possible to implement a "Boot kernel.old" > menue item that unloads all current loaded modules and re-loads > everithing from /boot/kernel.old? >=20 > Its difficult to handle manually in the loader (esp. handling the zpool.c= ache file ) and I got bitten by this issue recently in a ZFS only environme= nt. >=20 > Thanks in advance! >=20 > Bye/2 > --- > Michael Reifenberger > Michael@Reifenberger.com > http://www.Reifenberger.com >=20 >=20 There have been suggestions from many regarding "kernel selection" and even= "root selection" options. I've responded in earnest on at least one such s= uggestion (stating that there are plans to incorporate these features at so= me later date), though I have been short on details (compared to my normal = verbosity). These suggestions will have to be slated for a different commit and cannot = make it into the initial one. A subset of the technical reasons are enumera= ted below: 1. Currently, the "start" FICL word provided by /usr/src/sys/boot/forth/loa= der.4th -- which reads in /boot/defaults/loader.conf and later /boot/loader= .conf (if it exists), among other things -- pre-loads the configured kernel. This would need to change. We still want to call "start" from the onset of = /boot/loader.rc to pick up any variables configured in loader.conf(5), but = we don't want to load the kernel yet (though modules may be OK). I would ch= ange the overloaded "boot" word to load the kernel prior to calling the bui= lt-in boot ( N -- ) construct. 2. A non-trivial amount of Forth will need to be written to probe for a lis= t of kernels to be presented. Again, that is just a subset of the technical affronts we'll face. I'd like= to see this functionality pushed to a later SVN rev -- perhaps after MFC o= f the current rev planned for the current state. > Many of the Unix/Linux operating systems are utilizing a Kernel Selection= ( let's call it Selection instead of Loader ) menu , such as GRUB or LILO = , or , > in FreeBSD , when Kernel Selection menu is selected instead of booting di= rectly from boot sector . >=20 > Actually , a Kernel Selection menu in front of the Boot Loader menu is a = more flexible method : > First select kernel , then select its booting structure with the above de= scribed Boot Loader menu . >=20 > My opinion is that , they should NOT be COMBINED into one single menu , b= ecause , in the same system , even there may be other kernels to be booted . This would be technically simple to achieve but I'm wondering if the commun= ity would tolerate having a 2x 10-second timeout (one for kernel selection = menu, and another for the boot/option menu). Then, if later a root-selectio= n is provided, would that go into the kernel selection menu or a new menu (= now requiring 30-seconds to boot without a human present). I want the menu with the "Boot" option to be front-and-center, continuing t= o allow the user to boot immediately with a single key ('1', 'b', or ENTER)= if present (and desired), or if not present boot after a single 10-second = timeout. ASIDE: There are more boot toggles/variables mentioned in loader(8) than ar= e knobs in the boot menu (both old and new -- and more than can fit on a si= ngle screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute, b= oot_pause, boot_serial, and comconsole_speed. That's 7 additional options t= hat would likely be a good candidate for a "side menu" (perhaps a "More Opt= ions" menuitem off the main menu). ASIDE: A root-selection menuitem could potentially present the normal root = in addition to "ask", "cdrom" and "embedded". Each of which would set (resp= ectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See loader(8) f= or additional details. > Some operating systems , such as OpenSolaris and Mandriva Linux , after u= pdating the kernel , they are keeping previous kernel in the Kernel Selecti= on menu , under the new kernel name item . I've often felt that this could be improved upon by the Linux community. IM= HO neither Grub nor LiLo present a user-friendly way of setting options for= the selected kernel and concurrently leaves many Linux desktop-users befud= dled and uninterested. The use-case is taking a box into single-user mode: = FreeBSD achieves this with either one keystroke (current loader menu) or tw= o (code being committed to HEAD; e.g., s, ENTER); compare that with the ste= ps required to boot Linux into single-user mode from either LiLo or Grub (d= isclaimer: this might have been updated in some of the later Linux distros). NOTE: If you have a pre-configured Grub or LiLo entry for easily entering i= nto single-user mode, note that not everybody is so fortunate (either becau= se of their distro or due to lack of manual configuration). Even still, a v= ariable amount of cursor/arrow keys must be depressed which unless you've o= rdered your single-user entry at the top of the list, is still likely to ex= ceed the amount of keystrokes required by FreeBSD to achieve the same feat. > Such a system may be employed for the FreeBSD : If a kernel.old is genera= ted , it may be inserted into Kernel Selection menu automatically . I'm more interested in perhaps crawling the "bootfile" environment variable= customizable by loader.conf(5) (a semi-colon delimited list of bootable ke= rnels). By default, $bootfile is simply set to "kernel" (see /boot/defaults/loader.= conf). However, if a user desires, they could add something like: bootfile=3D"kernel;kernel.old;kernel.sav" to /boot/loader.conf and the menu would then test for the existence of each= of those (note: not implemented yet for technical reasons stated above). I= f more than one kernel exists, the menuitem would be present (allowing them= to cycle through each of the existing kernels). Once boot is invoked, the = desired kernel is loaded and then executed. The functionality for all this is (as previously mentioned) is already in m= enu.4th (see "cycle_menuitem", "cycle_kernel", and "cycle_root"). The part = that's not done yet is to dynamically build the menu construct based off th= e existence of those files. Though, currently you can manually configure a = menuitem for kernels/roots so-long as you modify the overloaded "boot" func= tionality to load the kernel prior to execution (opposed to having loader.4= th's "start" load the kernel which preempts any user selection event; as me= ntioned above). > If , at present , there is no kernel selection menu but boot sector is us= ed directly , > kernel build system may modify that structure also to utilize a Kernel Se= lection menu . Can you clarify on "boot sector is used directly?" I'm unaware of any loade= r(8) scenario in FreeBSD would do this. The normal behavior is to load the = kernel and then execute said kernel. Not selecting a kernel is not an optio= n, if I recall correctly. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 20:36:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF07E106564A for ; Sat, 14 May 2011 20:36:50 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCBA8FC12 for ; Sat, 14 May 2011 20:36:50 +0000 (UTC) Received: by qwc9 with SMTP id 9so2311472qwc.13 for ; Sat, 14 May 2011 13:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5s5oEIazmo7QGCxJJhjxgnHcZNNvyFGrcURrBoVvR+Y=; b=Ur5jiqpw/xKbCiOSs4OYJRpcJZN9OaPTQhAEeVm0srUV6UTaVJMyVABFAbeteGnw5f ugjmv9+j6zTSuGPPss7SjHCiI5HcR3OgBfmhVXwsarYeVjKQ1D5vmz4qTsdbdlkkwwrN GUZlbPUTg6diefbNalfZPJpeeAVL0fekRdIno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uHiJwT9rdtDo7ba7ke74DHZQmg3I+meVpBOKD3wD/3d0HALCnkRiU71jDiRYnpmC/O JU008Y9YyeyWtRAoku9tkxjltZszPAXK/SmRsr0gzCWe6uzgme1dp92f2LF/mIho480e Yydil+llOVIBCCFO1O4fHbITXISoGeRxOOzLw= MIME-Version: 1.0 Received: by 10.224.27.145 with SMTP id i17mr2313012qac.286.1305405407956; Sat, 14 May 2011 13:36:47 -0700 (PDT) Received: by 10.224.20.3 with HTTP; Sat, 14 May 2011 13:36:47 -0700 (PDT) In-Reply-To: <24057187-9777-4CFF-92D1-1D6103B35280@vicor.com> References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> <24057187-9777-4CFF-92D1-1D6103B35280@vicor.com> Date: Sat, 14 May 2011 16:36:47 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Devin Teske Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 20:36:51 -0000 On Sat, May 14, 2011 at 2:53 PM, Devin Teske wrote: > On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > > On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger < > mike@reifenberger.com> wrote: > >> Hi, >> this looks very promising! >> >> While you are working on the loader front currently, >> would it be possible to implement a "Boot kernel.old" >> menue item that unloads all current loaded modules and re-loads >> everithing from /boot/kernel.old? >> >> Its difficult to handle manually in the loader (esp. handling the >> zpool.cache file ) and I got bitten by this issue recently in a ZFS only >> environment. >> >> Thanks in advance! >> >> Bye/2 >> --- >> Michael Reifenberger >> Michael@Reifenberger.com >> http://www.Reifenberger.com >> >> > > There have been suggestions from many regarding "kernel selection" and even > "root selection" options. I've responded in earnest on at least one such > suggestion (stating that there are plans to incorporate these features at > some later date), though I have been short on details (compared to my normal > verbosity). > > These suggestions will have to be slated for a different commit and cannot > make it into the initial one. A subset of the technical reasons are > enumerated below: > > 1. Currently, the "start" FICL word provided by > /usr/src/sys/boot/forth/loader.4th -- which reads in > /boot/defaults/loader.conf and later /boot/loader.conf (if it exists), among > other things -- pre-loads the configured kernel. > > This would need to change. We still want to call "start" from the onset of > /boot/loader.rc to pick up any variables configured in loader.conf(5), but > we don't want to load the kernel yet (though modules may be OK). I would > change the overloaded "boot" word to load the kernel prior to calling the > built-in boot ( N -- ) construct. > > 2. A non-trivial amount of Forth will need to be written to probe for a > list of kernels to be presented. > > Again, that is just a subset of the technical affronts we'll face. I'd like > to see this functionality pushed to a later SVN rev -- perhaps after MFC of > the current rev planned for the current state. > > > Many of the Unix/Linux operating systems are utilizing a Kernel Selection ( > let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or > , > in FreeBSD , when Kernel Selection menu is selected instead of booting > directly from boot sector . > > Actually , a Kernel Selection menu in front of the Boot Loader menu is a > more flexible method : > First select kernel , then select its booting structure with the above > described Boot Loader menu . > > > My opinion is that , they should NOT be COMBINED into one single menu , > because , in the same system , even there may be other kernels to be booted > . > > > This would be technically simple to achieve but I'm wondering if the > community would tolerate having a 2x 10-second timeout (one for kernel > selection menu, and another for the boot/option menu). Then, if later a > root-selection is provided, would that go into the kernel selection menu or > a new menu (now requiring 30-seconds to boot without a human present). > > I want the menu with the "Boot" option to be front-and-center, continuing > to allow the user to boot immediately with a single key ('1', 'b', or > ENTER) if present (and desired), or if not present boot after a single > 10-second timeout. > > ASIDE: There are more boot toggles/variables mentioned in loader(8) than > are knobs in the boot menu (both old and new -- and more than can fit on a > single screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute, > boot_pause, boot_serial, and comconsole_speed. That's 7 additional options > that would likely be a good candidate for a "side menu" (perhaps a "More > Options" menuitem off the main menu). > > ASIDE: A root-selection menuitem could potentially present the normal root > in addition to "ask", "cdrom" and "embedded". Each of which would set > (respectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See > loader(8) for additional details. > > > Some operating systems , such as OpenSolaris and Mandriva Linux , after > updating the kernel , they are keeping previous kernel in the Kernel > Selection menu , under the new kernel name item . > > > I've often felt that this could be improved upon by the Linux community. > IMHO neither Grub nor LiLo present a user-friendly way of setting options > for the selected kernel and concurrently leaves many Linux desktop-users > befuddled and uninterested. The use-case is taking a box into single-user > mode: FreeBSD achieves this with either one keystroke (current loader menu) > or two (code being committed to HEAD; e.g., s, ENTER); compare that with > the steps required to boot Linux into single-user mode from either LiLo or > Grub (disclaimer: this might have been updated in some of the later Linux > distros). > > NOTE: If you have a pre-configured Grub or LiLo entry for easily entering > into single-user mode, note that not everybody is so fortunate (either > because of their distro or due to lack of manual configuration). Even still, > a variable amount of cursor/arrow keys must be depressed which unless you've > ordered your single-user entry at the top of the list, is still likely to > exceed the amount of keystrokes required by FreeBSD to achieve the same > feat. > > > Such a system may be employed for the FreeBSD : If a kernel.old is > generated , it may be inserted into Kernel Selection menu automatically . > > > I'm more interested in perhaps crawling the "bootfile" environment variable > customizable by loader.conf(5) (a semi-colon delimited list of bootable > kernels). > > By default, $bootfile is simply set to "kernel" (see > /boot/defaults/loader.conf). However, if a user desires, they could add > something like: > > bootfile="kernel;kernel.old;kernel.sav" > > to /boot/loader.conf and the menu would then test for the existence of each > of those (note: not implemented yet for technical reasons stated above). If > more than one kernel exists, the menuitem would be present (allowing them to > cycle through each of the existing kernels). Once boot is invoked, the > desired kernel is loaded and then executed. > > The functionality for all this is (as previously mentioned) is already in > menu.4th (see "cycle_menuitem", "cycle_kernel", and "cycle_root"). The part > that's not done yet is to dynamically build the menu construct based off the > existence of those files. Though, currently you can manually configure a > menuitem for kernels/roots so-long as you modify the overloaded "boot" > functionality to load the kernel prior to execution (opposed to having > loader.4th's "start" load the kernel which preempts any user selection > event; as mentioned above). > > > If , at present , there is no kernel selection menu but boot sector is used > directly , > > kernel build system may modify that structure also to utilize a Kernel > Selection menu . > > > Can you clarify on "boot sector is used directly?" I'm unaware of any > loader(8) scenario in FreeBSD would do this. The normal behavior is to load > the kernel and then execute said kernel. Not selecting a kernel is not an > option, if I recall correctly. > -- > Devin > _____________ > > During writing my messages , I am assuming that newcomers to the FreeBSD may read them , and I am trying to use sufficiently detailed sentences as much as suitable ( Such explanations are unnecessary for the experienced users , but I think we should care beginners ) . In the FreeBSD Handbook : http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html in *Figure 2-16. Sysinstall Boot Manager Menu* there are three options : (1) Use FreeBSD Boot Manager ( <------- I have called this Kernel Selection menu ) (2) Install a standard MBR ( no boot manager ) ( <------ I have called this "boot sector is used directly" ) (2) Leave Master Boot Record as it is . When (1) is selected , two menus are displayed : First selection of kernel , Second , Boot-Loader menu , which its a new version is described above . When (2) is selected , only the second menu is displayed . Please do not consider my other operating systems examples as an indication of that "the others are good" . They are only given to make comparisons . My main idea is that the present Boot-Loader Menu -- version 1.5 is a very good menu . Instead of destroying its elegant structure , the already available FreeBSD Boot Loader ( actually Kernel selection ) menu could be improved and may be used IF IT IS SUITABLE for the USER ( otherwise the user may not select it during installation ) . Therefore , the present structure is already existent for the needs and it is also good . Their combinations may create important problems : Assume a kernel is compiled with ACPI , old one was WITHOUT ACPI . Such a case will introduce incompatible menu structures . Then , it will be necessary . to generate Boot-Loader menus for EACH kernel or . options should be specified by the kernel : First select kernel , then , with respect to kernel structure , display options , and allow selection . Actually , in some personal computers ( i386 , amd64 ) ACPI setting during boot is an important problem . In some main boards , if ACPI is disabled , it is NOT possible to boot the FreeBSD ( also some other operating systems ) . My idea is that it should be set during installation and its selection should be removed from the Boot-Loader menu ( or with respect to boot configuration options it may be made hidden ) . This means that , whatever is decided , ACPI settings are an important problem ( up to the time when ALL of the main boards require ACPI set as default ) . Thank you very much . Mehmet Erol Sanliturk