From owner-freebsd-hackers@freebsd.org Mon Aug 17 14:00:30 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26FAF9BBAA7 for ; Mon, 17 Aug 2015 14:00:30 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 067B91BA3 for ; Mon, 17 Aug 2015 14:00:30 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 060CC9BBAA6; Mon, 17 Aug 2015 14:00:30 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFC079BBAA5 for ; Mon, 17 Aug 2015 14:00:29 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8B11BA1 for ; Mon, 17 Aug 2015 14:00:29 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by lahi9 with SMTP id i9so79350835lah.2 for ; Mon, 17 Aug 2015 07:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F4jd6IulmclXxwvNRjpitDbitYDzxhMAJhOHjDzZUuE=; b=Hhh0GOe359r0fRMCA8LIIyqUjqcwBWu7wWzVOeQ5KzTbzLDV4dTS1Nn4ShS+Dl7PKx OeERu7sPfvUKYHiagJ5yq3zQgC8pBcqULy36bVK9qo7F0c6TsxLakoHntuxcVpn6C/6L 6ocfxsfpcB75qEYtID6+3Hx7xQAh3aK/p5tOaxNCVXiqsScmtSynpJ6rMSVQLDj5OiLQ BcxdhuuwLu/vWm3MJ0NslV9rFunARRBqhisJ0WlPNpAuiic9egQnh83xHS+/dWIq7IgN WmRMLdqMqSWY0GKoQKIdh3JJqkUXegQe6jByCRapVPbhmSg26uh80nSAk2c2tAPiicvS dPYw== MIME-Version: 1.0 X-Received: by 10.152.20.196 with SMTP id p4mr1234299lae.121.1439820027185; Mon, 17 Aug 2015 07:00:27 -0700 (PDT) Received: by 10.25.126.2 with HTTP; Mon, 17 Aug 2015 07:00:26 -0700 (PDT) Date: Mon, 17 Aug 2015 10:00:26 -0400 Message-ID: Subject: spigen(4) SPI Generic IO interface -- need comments From: Brian Fundakowski Feldman To: hackers@freebsd.org Content-Type: multipart/mixed; boundary=089e013d203c42ea93051d823955 X-Mailman-Approved-At: Mon, 17 Aug 2015 14:55:59 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:00:30 -0000 --089e013d203c42ea93051d823955 Content-Type: text/plain; charset=UTF-8 I'm woefully out-of-practice with my kernel hackery (but still pretty proficient in jiggery-pokery) so I would like to get comments on a little driver I just made for interfacing arbitrarily in userland with SPI components. The only thing I'm exposing is a /dev/spigenN node with a single transfer ioctl and I put together a test circuit and program with an MCP3008 10-bit ADC IC to validate that it basically works, other than the limitation that the transfers must be octet-multiply-sized, but I haven't looked at the SoC's (I'm using a Raspberry Pi 2) data sheet to tell whether that's just a limit on the spibus(4) interface or the Broadcom SPI driver or the Broadcom SoC itself. I hit one snag in development where I simply called the ioctl wrong and found copyin(9) to page fault HARD if given a bogus user address to copy from, and panic the kernel. I can post up the test program if anyone wants but it's very trivial: I just align the start bit and the command data into the least significant bits of the first octet, shift it up two positions so the NULs get clocked out as part of the command field, and provide two octets for the data field to retrieve back the 10-bit digital value. Good to be back in the FreeBSD hacking! Cheers, Brian Fundakowski Feldman --089e013d203c42ea93051d823955 Content-Type: application/octet-stream; name="spigen.patch" Content-Disposition: attachment; filename="spigen.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idfzo8lg0 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyODY3ODYpCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMjQ1MCw2 ICsyNDUwLDcgQEAKIGRldi9zcGlidXMvb2Z3X3NwaWJ1cy5jCQlvcHRpb25hbCBmZHQgc3BpYnVz CiBkZXYvc3BpYnVzL3NwaWJ1cy5jCQlvcHRpb25hbCBzcGlidXMJCQkJXAogCWRlcGVuZGVuY3kJ InNwaWJ1c19pZi5oIgorZGV2L3NwaWJ1cy9zcGlnZW4uYwkJb3B0aW9uYWwgc3BpYnVzCiBkZXYv c3BpYnVzL3NwaWJ1c19pZi5tCQlvcHRpb25hbCBzcGlidXMKIGRldi9zdGUvaWZfc3RlLmMJCW9w dGlvbmFsIHN0ZSBwY2kKIGRldi9zdGcvdG1jMThjMzAuYwkJb3B0aW9uYWwgc3RnCkluZGV4OiBz eXMvZGV2L3NwaWJ1cy9zcGlnZW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L3NwaWJ1cy9zcGln ZW4uYwkocmV2aXNpb24gMCkKKysrIHN5cy9kZXYvc3BpYnVzL3NwaWdlbi5jCSh3b3JraW5nIGNv cHkpCkBAIC0wLDAgKzEsMTgxIEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAxNSBCcmlhbiBG dW5kYWtvd3NraSBGZWxkbWFuLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3Ry aWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhv dXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xs b3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisg KiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFi b3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQg dGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQv b3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisg KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBB TlkgRVhQUkVTUyBPUgorICogSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElFUworICogT0YgTUVSQ0hBTlRBQklMSVRZ IEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKyAq IElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJ TkRJUkVDVCwKKyAqIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVO VElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVAorICogTk9UIExJTUlURUQgVE8sIFBST0NVUkVN RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLAorICogREFU QSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBB TkQgT04gQU5ZCisgKiBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBT VFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUCisgKiAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RI RVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YKKyAqIFRISVMgU09G VFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0Uu CisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOwor CisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisjaW5jbHVk ZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9jb25mLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5l bC5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+Cisj aW5jbHVkZSA8c3lzL3NwaWdlbmlvLmg+CisKKyNpbmNsdWRlIDxkZXYvc3BpYnVzL3NwaS5oPgor I2luY2x1ZGUgInNwaWJ1c19pZi5oIgorCitzdHJ1Y3Qgc3BpZ2VuX3NvZnRjIHsKKwlkZXZpY2Vf dCBzY19kZXY7CisJc3RydWN0IGNkZXYgKnNjX2NkZXY7Cit9OworCitzdGF0aWMgaW50CitzcGln ZW5fcHJvYmUoZGV2aWNlX3QgZGV2KQoreworCWRldmljZV9zZXRfZGVzYyhkZXYsICJTUEkgR2Vu ZXJpYyBJTyIpOworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQgc3BpZ2VuX29wZW4oc3Ry dWN0IGNkZXYgKiwgaW50LCBpbnQsIHN0cnVjdCB0aHJlYWQgKik7CitzdGF0aWMgaW50IHNwaWdl bl9pb2N0bChzdHJ1Y3QgY2RldiAqLCB1X2xvbmcsIGNhZGRyX3QsIGludCwgc3RydWN0IHRocmVh ZCAqKTsKK3N0YXRpYyBpbnQgc3BpZ2VuX2Nsb3NlKHN0cnVjdCBjZGV2ICosIGludCwgaW50LCBz dHJ1Y3QgdGhyZWFkICopOworCitzdGF0aWMgc3RydWN0IGNkZXZzdyBzcGlnZW5fY2RldnN3ID0g eworCS5kX3ZlcnNpb24gPSBEX1ZFUlNJT04sCisJLmRfbmFtZSA9ICJzcGlnZW4iLAorCS5kX29w ZW4gPSBzcGlnZW5fb3BlbiwKKwkuZF9pb2N0bCA9IHNwaWdlbl9pb2N0bCwKKwkuZF9jbG9zZSA9 IHNwaWdlbl9jbG9zZQorfTsKKworc3RhdGljIGludAorc3BpZ2VuX2F0dGFjaChkZXZpY2VfdCBk ZXYpCit7CisJc3RydWN0IHNwaWdlbl9zb2Z0YyAqc2M7CisJY29uc3QgaW50IHVuaXQgPSBkZXZp Y2VfZ2V0X3VuaXQoZGV2KTsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXNjLT5z Y19kZXYgPSBkZXY7CisJc2MtPnNjX2NkZXYgPSBtYWtlX2Rldigmc3BpZ2VuX2NkZXZzdywgdW5p dCwKKwkgICAgVUlEX1JPT1QsIEdJRF9PUEVSQVRPUiwgMDY2MCwgInNwaWdlbiVkIiwgdW5pdCk7 CisJc2MtPnNjX2NkZXYtPnNpX2RydjEgPSBkZXY7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0 aWMgaW50IAorc3BpZ2VuX29wZW4oc3RydWN0IGNkZXYgKmRldiwgaW50IG9mbGFncywgaW50IGRl dnR5cGUsIHN0cnVjdCB0aHJlYWQgKnRkKQoreworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGlj IGludAorc3BpZ2VuX3RyYW5zZmVyKHN0cnVjdCBjZGV2ICpjZGV2LCBzdHJ1Y3Qgc3BpZ2VuX3Ry YW5zZmVyICpzdCkKK3sKKwlzdHJ1Y3Qgc3BpX2NvbW1hbmQgdHJhbnNmZXI7CisJZGV2aWNlX3Qg ZGV2ID0gY2Rldi0+c2lfZHJ2MTsKKwlpbnQgZXJyb3I7CisKKwlpZiAoc3QtPnN0X2NvbW1hbmQu aW92X2xlbiA9PSAwIHx8IHN0LT5zdF9kYXRhLmlvdl9sZW4gPT0gMCkKKwkJcmV0dXJuIChFSU5W QUwpOworCWlmIChzdC0+c3RfY29tbWFuZC5pb3ZfbGVuID4gUEFHRV9TSVpFIHx8CisJICAgIHN0 LT5zdF9kYXRhLmlvdl9sZW4gPiBQQUdFX1NJWkUpCisJCXJldHVybiAoRU5PTUVNKTsKKyNpZiAw CisJZGV2aWNlX3ByaW50ZihkZXYsICJjbWQgJXAgJXUgZGF0YSAlcCAldVxuIiwgc3QtPnN0X2Nv bW1hbmQuaW92X2Jhc2UsCisJICAgIHN0LT5zdF9jb21tYW5kLmlvdl9sZW4sIHN0LT5zdF9kYXRh Lmlvdl9iYXNlLCBzdC0+c3RfZGF0YS5pb3ZfbGVuKTsKKyNlbmRpZgorCXRyYW5zZmVyLnR4X2Nt ZCA9IHRyYW5zZmVyLnJ4X2NtZCA9IG1hbGxvYyhzdC0+c3RfY29tbWFuZC5pb3ZfbGVuLAorCSAg ICBNX0RFVkJVRiwgTV9XQUlUT0spOworCWlmICh0cmFuc2Zlci50eF9jbWQgPT0gTlVMTCkKKwkJ cmV0dXJuIChFTk9NRU0pOworCXRyYW5zZmVyLnR4X2RhdGEgPSB0cmFuc2Zlci5yeF9kYXRhID0g bWFsbG9jKHN0LT5zdF9kYXRhLmlvdl9sZW4sCisJICAgIE1fREVWQlVGLCBNX1dBSVRPSyk7CisJ aWYgKHRyYW5zZmVyLnR4X2RhdGEgPT0gTlVMTCkgeworCQlmcmVlKHRyYW5zZmVyLnR4X2NtZCwg TV9ERVZCVUYpOworCQlyZXR1cm4gKEVOT01FTSk7CisJfQorCisJZXJyb3IgPSBjb3B5aW4oc3Qt PnN0X2NvbW1hbmQuaW92X2Jhc2UsIHRyYW5zZmVyLnR4X2NtZCwKKwkgICAgdHJhbnNmZXIudHhf Y21kX3N6ID0gdHJhbnNmZXIucnhfY21kX3N6ID0gc3QtPnN0X2NvbW1hbmQuaW92X2xlbik7CQor CWlmIChlcnJvciA9PSAwKQorCQllcnJvciA9IGNvcHlpbihzdC0+c3RfZGF0YS5pb3ZfYmFzZSwg dHJhbnNmZXIudHhfZGF0YSwKKwkJICAgIHRyYW5zZmVyLnR4X2RhdGFfc3ogPSB0cmFuc2Zlci5y eF9kYXRhX3N6ID0KKwkJICAgICAgICAgICAgICAgICAgICAgICAgICBzdC0+c3RfZGF0YS5pb3Zf bGVuKTsJCisJaWYgKGVycm9yID09IDApCisJCWVycm9yID0gU1BJQlVTX1RSQU5TRkVSKGRldmlj ZV9nZXRfcGFyZW50KGRldiksIGRldiwgJnRyYW5zZmVyKTsKKwlpZiAoZXJyb3IgPT0gMCkgewor CQllcnJvciA9IGNvcHlvdXQodHJhbnNmZXIucnhfY21kLCBzdC0+c3RfY29tbWFuZC5pb3ZfYmFz ZSwKKwkJICAgIHRyYW5zZmVyLnJ4X2NtZF9zeik7CisJCWlmIChlcnJvciA9PSAwKQorCQkJZXJy b3IgPSBjb3B5b3V0KHRyYW5zZmVyLnJ4X2RhdGEsIHN0LT5zdF9kYXRhLmlvdl9iYXNlLAorCQkJ ICAgIHRyYW5zZmVyLnJ4X2RhdGFfc3opOworCX0KKworCWZyZWUodHJhbnNmZXIudHhfY21kLCBN X0RFVkJVRik7CisJZnJlZSh0cmFuc2Zlci50eF9kYXRhLCBNX0RFVkJVRik7CisJcmV0dXJuIChl cnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK3NwaWdlbl9pb2N0bChzdHJ1Y3QgY2RldiAqZGV2LCB1 X2xvbmcgY21kLCBjYWRkcl90IGRhdGEsIGludCBmZmxhZywKKyAgICBzdHJ1Y3QgdGhyZWFkICp0 ZCkKK3sKKwlpbnQgZXJyb3I7CisKKwlzd2l0Y2ggKGNtZCkgeworCWNhc2UgU1BJR0VOSU9DX1RS QU5TRkVSOgorCQllcnJvciA9IHNwaWdlbl90cmFuc2ZlcihkZXYsIChzdHJ1Y3Qgc3BpZ2VuX3Ry YW5zZmVyICopZGF0YSk7CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCWVycm9yID0gRU9QTk9UU1VQ UDsKKwl9CisJcmV0dXJuIGVycm9yOworfQorCitzdGF0aWMgaW50IAorc3BpZ2VuX2Nsb3NlKHN0 cnVjdCBjZGV2ICpkZXYsIGludCBmZmxhZywgaW50IGRldnR5cGUsIHN0cnVjdCB0aHJlYWQgKnRk KQoreworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorc3BpZ2VuX2RldGFjaChkZXZp Y2VfdCBkZXYpCit7CisKKwlyZXR1cm4gKEVJTyk7Cit9CisKK3N0YXRpYyBkZXZjbGFzc190IHNw aWdlbl9kZXZjbGFzczsKKworc3RhdGljIGRldmljZV9tZXRob2RfdCBzcGlnZW5fbWV0aG9kc1td ID0geworCS8qIERldmljZSBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0QoZGV2aWNlX3Byb2JlLAkJ c3BpZ2VuX3Byb2JlKSwKKwlERVZNRVRIT0QoZGV2aWNlX2F0dGFjaCwJc3BpZ2VuX2F0dGFjaCks CisJREVWTUVUSE9EKGRldmljZV9kZXRhY2gsCXNwaWdlbl9kZXRhY2gpLAorCisJeyAwLCAwIH0K K307CisKK3N0YXRpYyBkcml2ZXJfdCBzcGlnZW5fZHJpdmVyID0geworCSJzcGlnZW4iLAorCXNw aWdlbl9tZXRob2RzLAorCXNpemVvZihzdHJ1Y3Qgc3BpZ2VuX3NvZnRjKSwKK307CisKK0RSSVZF Ul9NT0RVTEUoc3BpZ2VuLCBzcGlidXMsIHNwaWdlbl9kcml2ZXIsIHNwaWdlbl9kZXZjbGFzcywg MCwgMCk7CgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiBzeXMvZGV2L3NwaWJ1cy9zcGlnZW4uYwpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5l d2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAj IworRnJlZUJTRD0lSApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46 bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBv ZiBwcm9wZXJ0eQpJbmRleDogc3lzL3N5cy9zcGlnZW5pby5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9z eXMvc3BpZ2VuaW8uaAkocmV2aXNpb24gMCkKKysrIHN5cy9zeXMvc3BpZ2VuaW8uaAkod29ya2lu ZyBjb3B5KQpAQCAtMCwwICsxLDQyIEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAwMCBEb3Vn IFJhYnNvbgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBh bmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1v ZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29u ZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29k ZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlz dCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRp c3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHly aWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIg bWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNP RlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElT JycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElT Q0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJF IExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFM LCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBT RVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVS UlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElU WSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBP VVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKgkkRnJlZUJTRCQKKyAqLworCisj aWZuZGVmIF9TWVNfU1BJR0VOSU9fSF8KKyNkZWZpbmUgX1NZU19TUElHRU5JT19IXworCisjaW5j bHVkZSA8c3lzL19pb3ZlYy5oPgorCitzdHJ1Y3Qgc3BpZ2VuX3RyYW5zZmVyIHsKKwlzdHJ1Y3Qg aW92ZWMgc3RfY29tbWFuZDsgLyogbWFzdGVyIHRvIHNsYXZlICovCisJc3RydWN0IGlvdmVjIHN0 X2RhdGE7ICAgIC8qIHNsYXZlIHRvIG1hc3RlciAqLworfTsKKworI2RlZmluZSBTUElHRU5JT0Nf QkFTRSAgICAgJ1MnCisjZGVmaW5lIFNQSUdFTklPQ19UUkFOU0ZFUiBfSU9XKFNQSUdFTklPQ19C QVNFLCAwLCBzdHJ1Y3Qgc3BpZ2VuX3RyYW5zZmVyKQorCisjZW5kaWYgLyogIV9TWVNfU1BJR0VO SU9fSF8gKi8KClByb3BlcnR5IGNoYW5nZXMgb246IHN5cy9zeXMvc3BpZ2VuaW8uaApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAjIwor RnJlZUJTRD0lSApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWlt ZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBw cm9wZXJ0eQo= --089e013d203c42ea93051d823955-- From owner-freebsd-hackers@freebsd.org Mon Aug 17 16:04:28 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65DB19BB5C7 for ; Mon, 17 Aug 2015 16:04:28 +0000 (UTC) (envelope-from indiestory@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 441CD1238 for ; Mon, 17 Aug 2015 16:04:28 +0000 (UTC) (envelope-from indiestory@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 40B4B9BB5C6; Mon, 17 Aug 2015 16:04:28 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 263B99BB5C4 for ; Mon, 17 Aug 2015 16:04:28 +0000 (UTC) (envelope-from indiestory@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2E541237 for ; Mon, 17 Aug 2015 16:04:27 +0000 (UTC) (envelope-from indiestory@gmail.com) Received: by wicja10 with SMTP id ja10so85053716wic.1 for ; Mon, 17 Aug 2015 09:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:hackerspace:user-agent; bh=va2lcRiZLCbzR1G2P1hj+E/ZGQSinENNbpB4cDzdlTs=; b=o29wuZznLx7X2XYSUtffdd+XwGFnhMd2rlYLxWY+FU0uTzhHfBWt/qrQuX0yVLkIQW SYVGMpNb2bl8CUtGnhyIcmsgFJCoqP8xJCkC5brhvoAJx6Ytnfx61jlrkAq7dnIX5Qx7 d467oJqSGXywJW412D0jefN48wCp9KUL59uIcn6lWYELAJ84quD+VZo3yhdfn4n4uavh Ei7SfI7tUuxc7sfu+psaTWHDsgUBHgulESG660Gcvl8g/Jvk4TygASXTl7X5HZNbMhjR sw71lNvJVa/i5AbAq2zzNmEro3xIPI2wTCZurS03aCBzX3TRCGva0CmtwaxFgJvLtBO/ xc/A== X-Received: by 10.194.60.226 with SMTP id k2mr3900566wjr.10.1439827465991; Mon, 17 Aug 2015 09:04:25 -0700 (PDT) Received: from gmail.com ([151.217.48.39]) by smtp.gmail.com with ESMTPSA id im10sm18300889wjb.40.2015.08.17.09.04.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 09:04:25 -0700 (PDT) Sender: Tom Jones Date: Mon, 17 Aug 2015 17:04:23 +0100 From: Tom Jones To: Brian Fundakowski Feldman Cc: hackers@freebsd.org Subject: Re: spigen(4) SPI Generic IO interface -- need comments Message-ID: <20150817160423.GB3078@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hackerspace: 57North Hacklab User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:04:28 -0000 On Mon, Aug 17, 2015 at 10:00:26AM -0400, Brian Fundakowski Feldman wrote: > I'm woefully out-of-practice with my kernel hackery (but still pretty > proficient in jiggery-pokery) so I would like to get comments on a little > driver I just made for interfacing arbitrarily in userland with SPI > components. The only thing I'm exposing is a /dev/spigenN node with a > single transfer ioctl and I put together a test circuit and program with an > MCP3008 10-bit ADC IC to validate that it basically works, other than the > limitation that the transfers must be octet-multiply-sized, but I haven't > looked at the SoC's (I'm using a Raspberry Pi 2) data sheet to tell whether > that's just a limit on the spibus(4) interface or the Broadcom SPI driver > or the Broadcom SoC itself. > > I hit one snag in development where I simply called the ioctl wrong and > found copyin(9) to page fault HARD if given a bogus user address to copy > from, and panic the kernel. I can post up the test program if anyone wants > but it's very trivial: I just align the start bit and the command data into > the least significant bits of the first octet, shift it up two positions so > the NULs get clocked out as part of the command field, and provide two > octets for the data field to retrieve back the 10-bit digital value. Oh, cool. I did the same earlier this year, have you seen[1]?. The FreeBSD i2c api is the same/very similar the linux one[2][3]. Have you considered adding some of the ioctls[3] or the data structures to make it easier to port code? [1]: https://lists.freebsd.org/pipermail/freebsd-embedded/2015-April/002466.html [2]: https://www.kernel.org/doc/Documentation/i2c/dev-interface [3]: https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html [4]: https://www.kernel.org/doc/Documentation/spi/spidev - tj From owner-freebsd-hackers@freebsd.org Mon Aug 17 16:15:51 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5C019BB7BE for ; Mon, 17 Aug 2015 16:15:50 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B69791C35 for ; Mon, 17 Aug 2015 16:15:50 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by igbjg10 with SMTP id jg10so59446379igb.0 for ; Mon, 17 Aug 2015 09:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZuSkUPmLrEMXhziJbpWUQ178UMcurV3S85i4OmL5lF8=; b=lRWbly+9RSLgJaxx0BC+JzleuJZpImpJ9z0iCWgYHdPLcDGKa9wiuKUu+o5OOOuWWY IIadLgGvvuTgOf3ZaNu6xySwOmYMiDYlIfKK2jA8HqV/Rp+PoOdGr+WqliwNP7KnajJr ozne7NsBzzsUj1kcuFDBEk/EQ3cBGdJTuBxhp9gGLNHEZ6s7btT4tzI2NaJ86jiQQqoP jgBdmraOU9kcMmS1ov0Rv/FvyRfwPAwmgH+AMqAj8rUx/M+w2CucKgmsAi7HNnF+6gKI ApmKAo1gb+adJAidkU0P0kGrdjX/M0WNhgfNMZLilR0fOXXpfxHTuMtGHCGPNI59fYD3 B0kw== MIME-Version: 1.0 X-Received: by 10.50.66.197 with SMTP id h5mr16206310igt.82.1439828150103; Mon, 17 Aug 2015 09:15:50 -0700 (PDT) Received: by 10.64.2.132 with HTTP; Mon, 17 Aug 2015 09:15:50 -0700 (PDT) Date: Mon, 17 Aug 2015 09:15:50 -0700 Message-ID: Subject: Re: Sparc64 support From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:15:51 -0000 Jordan: > external toolchain Suggestion: can we get away from "internal" toolchain and "external" toolchain, and set things up to make it easy to have multiple equal toolchains? And an easy way for a user to select which one (and which version) they want to use. Much like setting $EDITOR. Each arch would have a default toolchain in case $TOOLCHAIN isn't set. Bonus points if power toolchain users can easily mix&match pieces from different toolchains. And an easy way to add options. (Example: Back when most code was written assuming all the world is ILP32, I wrote a wrapper that added some compiler warnings for prototypes and such, making it easier to port code to LP64.) Doesn't have to be environment variables, could be a toolchain config file, whatever. The NasaBSD story as it was told to me: 20 years ago, NASA employed many of the NetBSD engineers. NetBSD was very high quality, well thought out, and portable. Not perfect (NetBSD's FFS was never as good as FreeBSD's, (but FreeBSD isn't very useful if it doesn't run on your arch)), but pretty close. Did everything I needed at the time, and nearly no bugs. PRs actually got fixed!!! Hard to imagine these days. The packaging was great. Toolchain was a seperate tar file. Text processing was a seperate tar file, Several other lumps of stuff were seperate tar files. Want to build a minimal machine, like a firewall? Just install kernel, base, and etc. Want everything? Just unpack several tar files. Ether way it was very easy. And the package system for adding third party things worked great. Easy to build cross-arch and/or cross-OS, even if the host OS has no support for the target arch. (I've done it, it worked.) Then these engineers got jobs elsewhere, and NetBSD started going downhill. PRs started getting ignored, or closed for bogus reasons. Essential hardware not supported. More bugs. (FreeBSD has these same problems.) They are even ripping out essential features (for bogus reasons). So NasaBSD is a nickname for early NetBSD. > Even NetBSD, which has long had the motto [crap deleted] of course it > runs NetBSD [crap deleted] (as if the answer was so obvious as to be > unworth the question) NetBSD used to run on pretty much everything. > has been retiring architectures left and right Just part of their slide downhill. > your software will be a collection of burdensome conditionals > and weird constructs I've seen that in 3rd party software. I don't recall seeing it in NetBSD. But given what's been going on there, the recent stuff probably has some. BTW, Attempting to read text with non-ASCII crap sprinkled throughout for no obvious reason is burdensome as well. Extra characters for other languages are one thing, but that doesn't appear to be the case here. Pasting it into my editor results in a mangled mess, which is burdensome to unmangle. From owner-freebsd-hackers@freebsd.org Mon Aug 17 17:14:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D05209BB594 for ; Mon, 17 Aug 2015 17:14:03 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B10B61D86 for ; Mon, 17 Aug 2015 17:14:03 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id AF8E99BB593; Mon, 17 Aug 2015 17:14:03 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 953E89BB592 for ; Mon, 17 Aug 2015 17:14:03 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F7601D84 for ; Mon, 17 Aug 2015 17:14:03 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by lagz9 with SMTP id z9so83391759lag.3 for ; Mon, 17 Aug 2015 10:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=4cENo0CXslhFFET2Bhm/v3k2ucmkWSzm0MEU0bNdKI8=; b=NsxHiQKW5njxT0hKujq0gGlOFtXCk2r7O9TmScvs0ugjFhdhcVSNzARaHMcKqcMweJ 6WB/fcvkn30pepdtDb2plkXtj92D+HiG4HugVNiYuDZbVM+m0dzIVnCpCDqyWPdUqA+v Bhn2e9NK8K+j29RCK2Xg4gmt1KOs3ptYgc2VfVFHViTRpzj83GtCCgCaK7W3MW/KLgK3 ZZ919AJ+VZl9ZWs6fahEVM39ZIrykZdhanuz3JRp6yJ+b7Di7kYa2zTfN67orwn4zU7a oHkJt0hxqNfnZy2X+32mCmHKK4MveKXPKyrFJ+ZfaPthHatFZCDS+vzQKQgoRU1BDkHe 7Szg== X-Received: by 10.152.234.75 with SMTP id uc11mr1924438lac.20.1439831641228; Mon, 17 Aug 2015 10:14:01 -0700 (PDT) MIME-Version: 1.0 References: <20150817160423.GB3078@gmail.com> In-Reply-To: <20150817160423.GB3078@gmail.com> From: Brian Fundakowski Feldman Date: Mon, 17 Aug 2015 17:13:51 +0000 Message-ID: Subject: Re: spigen(4) SPI Generic IO interface -- need comments To: Tom Jones Cc: hackers@freebsd.org X-Mailman-Approved-At: Mon, 17 Aug 2015 18:25:32 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:14:03 -0000 Oh, no, I couldn't find that in the search but maybe I need to subscribe to -embedded now that I'm interested in circuit hacking with my Pi. I am interested in also doing an i2c interface so I can use an I/O multiplexer as well. I'll have to take a look at your code, maybe try and shape them up into something good enough to commit -- I think I want to have a root-owned sysctl dictating the maximum transfer lengths (and hence pinned memory). On Mon, Aug 17, 2015, 12:04 PM Tom Jones wrote: > On Mon, Aug 17, 2015 at 10:00:26AM -0400, Brian Fundakowski Feldman wrote: > > I'm woefully out-of-practice with my kernel hackery (but still pretty > > proficient in jiggery-pokery) so I would like to get comments on a little > > driver I just made for interfacing arbitrarily in userland with SPI > > components. The only thing I'm exposing is a /dev/spigenN node with a > > single transfer ioctl and I put together a test circuit and program with > an > > MCP3008 10-bit ADC IC to validate that it basically works, other than the > > limitation that the transfers must be octet-multiply-sized, but I haven't > > looked at the SoC's (I'm using a Raspberry Pi 2) data sheet to tell > whether > > that's just a limit on the spibus(4) interface or the Broadcom SPI driver > > or the Broadcom SoC itself. > > > > I hit one snag in development where I simply called the ioctl wrong and > > found copyin(9) to page fault HARD if given a bogus user address to copy > > from, and panic the kernel. I can post up the test program if anyone > wants > > but it's very trivial: I just align the start bit and the command data > into > > the least significant bits of the first octet, shift it up two positions > so > > the NULs get clocked out as part of the command field, and provide two > > octets for the data field to retrieve back the 10-bit digital value. > > Oh, cool. > > I did the same earlier this year, have you seen[1]?. > > The FreeBSD i2c api is the same/very similar the linux one[2][3]. Have you > considered adding some of the ioctls[3] or the data structures to make it > easier to port code? > > [1]: > https://lists.freebsd.org/pipermail/freebsd-embedded/2015-April/002466.html > [2]: https://www.kernel.org/doc/Documentation/i2c/dev-interface > [3]: > https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html > [4]: https://www.kernel.org/doc/Documentation/spi/spidev > > - tj > From owner-freebsd-hackers@freebsd.org Mon Aug 17 18:07:58 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28F569BB0F0 for ; Mon, 17 Aug 2015 18:07:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC88F16C6 for ; Mon, 17 Aug 2015 18:07:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbjg10 with SMTP id jg10so61972578igb.0 for ; Mon, 17 Aug 2015 11:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R3OpOB9yLkjhTMlpOMBHaop+wjvklEmQS1EYWxfQ+R4=; b=RGkEVNrlndQtOf2aJdav4awYKLPGJWuYE2f8rXD/CSfXWqp2AzWzOLGm2STu0fQAoP 9szM6bbbX0VfJ7tHRKpa3gPOdg8525t311g2UGPeJ7zBI88Q5PkLFSL7Qycqfr4qXgRb nK5zh+hyT9lFxHN6swq7eFaj5eH7bS5ayvzrP3K1oedPcOZkR81f2EPabxQQEx9PW03+ 06wL3we+B4Ub7HhYQFcuaWaHnKILCrCBosGi56gr0PwQ3I6/rex81se07Ta1a9H4s/XI gaP5bhMI7t2/oXVrs3rqq5hzutiZbu5AcWPG7PP5m6vXcO2V7Dom07Yi7zg0oWRpP2lb A3hg== MIME-Version: 1.0 X-Received: by 10.50.87.74 with SMTP id v10mr18419938igz.37.1439834877120; Mon, 17 Aug 2015 11:07:57 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Mon, 17 Aug 2015 11:07:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Aug 2015 11:07:56 -0700 Message-ID: Subject: Re: Sparc64 support From: Adrian Chadd To: Dieter BSD Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 17 Aug 2015 18:56:04 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 18:07:58 -0000 Hi, In my (linux) world, there is no toolchain - all toolchains are external. It keeps the bastards honest. -a From owner-freebsd-hackers@freebsd.org Mon Aug 17 18:58:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92A769BBC2E for ; Mon, 17 Aug 2015 18:58:39 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 632E11D5E for ; Mon, 17 Aug 2015 18:58:39 +0000 (UTC) (envelope-from jim@netgate.com) Received: by paccq16 with SMTP id cq16so70514001pac.1 for ; Mon, 17 Aug 2015 11:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JZej/AVNLgm4nZkKgNdbpbIsnP5Glrdvtcg/6R1g8so=; b=GyS/YcICyV2G/Hrzy01AJ7d0CRQRz7zIZYk59my9WPzA/WdhOZsXCcAj1YoW1EyRR4 HWqofvU7JdghToavKhxryf7AJKKEbVgcmbc/F0qfs9x7r0PNzLiMr7KAIy7rnB7o7l5v Nk69vW5PdmTUkZJUTFmoA1bYWITUmAfFHT0pI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JZej/AVNLgm4nZkKgNdbpbIsnP5Glrdvtcg/6R1g8so=; b=PAROY7EqsVmEPPMBzlZUMXTjINOQrFJ9WErmT2IscUASvAAso3K7lzxwo3q58cb+iT mNdFfIFfQBmztx7EDZhKapgK1roAMMDcdi8rJChv5St7nOfnxEGZqIcESBO9EAUS+Vyt lfF/+yNE/DjzjZ8ugFUrpGje1PNfIRTMFo9GBhbvS31+3UYTmFaaQXPpF75Gd1rur2ey KIwxvF++CR6Z/iRqHWFDgmKVrlk5ohxRn/8PoPTp6aXHRSwMwAYHLxgy/ACltauwal2W XbIdNKVIPqRViAtNYD7rE3+bRuJkcaFmwOvwSPZ56EvyrJ0wYmUW8yr63hNQhWQNF5DK nX7A== X-Gm-Message-State: ALoCoQmzM416icr+tqxLHg4FXiOU9mx5FWqThOHjuLT2KCFBDRETTpyl+zL5j7basyXd0tosVLG/ X-Received: by 10.68.133.68 with SMTP id pa4mr5351100pbb.71.1439837918894; Mon, 17 Aug 2015 11:58:38 -0700 (PDT) Received: from [10.90.11.167] (24-104-73-12-ip-static.hfc.comcastbusiness.net. [24.104.73.12]) by smtp.gmail.com with ESMTPSA id y2sm15512335pdp.0.2015.08.17.11.58.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Aug 2015 11:58:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Sparc64 support From: Jim Thompson In-Reply-To: Date: Mon, 17 Aug 2015 11:58:36 -0700 Cc: Dieter BSD , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 18:58:39 -0000 > On Aug 17, 2015, at 11:07 AM, Adrian Chadd wrote: > > Hi, > > In my (linux) world, there is no toolchain - all toolchains are > external. It keeps the bastards honest. It also keeps certain SoCs on a given version of gcc. From owner-freebsd-hackers@freebsd.org Tue Aug 18 19:42:40 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2255F9BCE22 for ; Tue, 18 Aug 2015 19:42:40 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE418AF for ; Tue, 18 Aug 2015 19:42:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id t7IJfX7p076134 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 18 Aug 2015 12:41:34 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com To: Freebsd hackers list From: Yuri Subject: System briefly freezes every time when a very large UFS directory is filled with files Message-ID: <55D38A75.6090508@rawbw.com> Date: Tue, 18 Aug 2015 12:41:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 19:42:40 -0000 I have one directory that has ~1.2M files on UFS system. Every time when the process that creates files there reaches a particular point (~0.9M files), system invariably freezes for ~10 seconds, after which it continues and process succeeds. I know that this is quite an extreme number of files but, other than this problem, it is usable in this setup. Maybe someone can think of some fix or the immediate reason of such freezes? This isn't a good problem to have, even in the view of an extremity of this situation. Yuri From owner-freebsd-hackers@freebsd.org Tue Aug 18 22:05:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D20009BBC59 for ; Tue, 18 Aug 2015 22:05:12 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACADF7F5 for ; Tue, 18 Aug 2015 22:05:12 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by pacgr6 with SMTP id gr6so141431430pac.2 for ; Tue, 18 Aug 2015 15:05:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rjb8lS9CteCMSZZ8kZkBXI9nMI0YI9GkfsOO2fnJrpw=; b=A+v0NrW0F87tbkj9zfdYXIWAkNGcL5Ycz+QZcZVGK3FjZBChd4mpCOCIiNSiMCzpmd /G8BnDHkmo+am6dvC8P6c8K2eiM9KhJCkMtKMcb6+/0YeKPem1FTV69mK6AHyIk79IQe 1KAzilSS1dq8o32AVNxac4GallvqyydEHCiqA1Nd+bD7vG6RC3KCf/liwPs9ZayNHunv s25R3h4pM8qSJgkQ8OHlse1sKCyVuYfdzHbx4m+RIIycIxY4fHZil6uw+FjJQTN7Tqpb KcDZn9XI7d77bXUF/rOu8THDKPKjullvwa+E/m/ZSzRFKvkgZP/KlNckMdmoJvTpvNN3 VMOg== X-Gm-Message-State: ALoCoQkCXzkaRWGHAWfchr2d90xS3OpeOvlUe3tlWtEcELbRZO0AXs9/4NQms4I4XtRPf24YYWUZ X-Received: by 10.66.241.130 with SMTP id wi2mr17816550pac.130.1439935506318; Tue, 18 Aug 2015 15:05:06 -0700 (PDT) Received: from [29.216.184.177] (66-87-118-177.pools.spcsdns.net. [66.87.118.177]) by smtp.gmail.com with ESMTPSA id qr5sm15622216pbb.26.2015.08.18.15.05.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Aug 2015 15:05:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: System briefly freezes every time when a very large UFS directory is filled with files From: Larry Maloney X-Mailer: iPhone Mail (12H321) In-Reply-To: <55D38A75.6090508@rawbw.com> Date: Tue, 18 Aug 2015 15:05:02 -0700 Cc: Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: References: <55D38A75.6090508@rawbw.com> To: Yuri X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 22:05:12 -0000 Could you organize the files into a hierarchy?=20 /Larry Sent from my iPhone > On Aug 18, 2015, at 12:41 PM, Yuri wrote: >=20 > I have one directory that has ~1.2M files on UFS system. > Every time when the process that creates files there reaches a particular p= oint (~0.9M files), system invariably freezes for ~10 seconds, after which i= t continues and process succeeds. >=20 > I know that this is quite an extreme number of files but, other than this p= roblem, it is usable in this setup. >=20 > Maybe someone can think of some fix or the immediate reason of such freeze= s? This isn't a good problem to have, even in the view of an extremity of th= is situation. >=20 > Yuri > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Tue Aug 18 22:48:05 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5DBD9BD504 for ; Tue, 18 Aug 2015 22:48:05 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9325A1C1D for ; Tue, 18 Aug 2015 22:48:05 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 923179BD501; Tue, 18 Aug 2015 22:48:05 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B389BD500 for ; Tue, 18 Aug 2015 22:48:05 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E91991C1A for ; Tue, 18 Aug 2015 22:48:04 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by lbbtg9 with SMTP id tg9so113373759lbb.1 for ; Tue, 18 Aug 2015 15:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=XgkL/VaxMGlpAtsyP5uYRuWQnscQeL9EiWWGLHjPMaM=; b=Z58JFPNVK5n/U+MRcXcHCk+ooXy3xZ+sJAbrvfiNHStTZVnGcOR23g4ZTO6zcogj+D WW5uNpunc6rsUpKkNtiivWcb8hmiDjE3OBkDpOcQmGjAzq2do9c6Em1tN+QZxzje7Eqv LsVxZYdsWox2JSDQN66gBKdTi3VJYKnUSGo3thQTSN/H7/aX+Og/QoCrPJYJaA2qD6C5 7cqMOLtolbwWx4GNgeYxPu7xMjGcjrm3e07frhIIWEA00GQfdXprS4kodlwgQm2LUp2A /Svl/KUuqfXd2yeAwn+UdGNlx6h08PnoP1sy/VjhhMhyypCt5hBXx13A0LJBUcF5e8dF DBLg== X-Received: by 10.112.137.164 with SMTP id qj4mr8311363lbb.105.1439938083046; Tue, 18 Aug 2015 15:48:03 -0700 (PDT) MIME-Version: 1.0 References: <20150817160423.GB3078@gmail.com> In-Reply-To: <20150817160423.GB3078@gmail.com> From: Brian Fundakowski Feldman Date: Tue, 18 Aug 2015 22:47:52 +0000 Message-ID: Subject: Re: spigen(4) SPI Generic IO interface -- need comments To: Tom Jones Cc: embedded@freebsd.org Content-Type: multipart/mixed; boundary=089e0115fd1cf06895051d9db585 X-Mailman-Approved-At: Tue, 18 Aug 2015 23:28:19 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 22:48:05 -0000 --089e0115fd1cf06895051d9db585 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 12:04 PM Tom Jones wrote: > On Mon, Aug 17, 2015 at 10:00:26AM -0400, Brian Fundakowski Feldman wrote: > > I'm woefully out-of-practice with my kernel hackery (but still pretty > > proficient in jiggery-pokery) so I would like to get comments on a little > > driver I just made for interfacing arbitrarily in userland with SPI > > components. The only thing I'm exposing is a /dev/spigenN node with a > > single transfer ioctl and I put together a test circuit and program with > an > > MCP3008 10-bit ADC IC to validate that it basically works, other than the > > limitation that the transfers must be octet-multiply-sized, but I haven't > > looked at the SoC's (I'm using a Raspberry Pi 2) data sheet to tell > whether > > that's just a limit on the spibus(4) interface or the Broadcom SPI driver > > or the Broadcom SoC itself. > > > > I hit one snag in development where I simply called the ioctl wrong and > > found copyin(9) to page fault HARD if given a bogus user address to copy > > from, and panic the kernel. I can post up the test program if anyone > wants > > but it's very trivial: I just align the start bit and the command data > into > > the least significant bits of the first octet, shift it up two positions > so > > the NULs get clocked out as part of the command field, and provide two > > octets for the data field to retrieve back the 10-bit digital value. > > Oh, cool. > > I did the same earlier this year, have you seen[1]?. > > The FreeBSD i2c api is the same/very similar the linux one[2][3]. Have you > considered adding some of the ioctls[3] or the data structures to make it > easier to port code? > > [1]: > https://lists.freebsd.org/pipermail/freebsd-embedded/2015-April/002466.html > [2]: https://www.kernel.org/doc/Documentation/i2c/dev-interface > [3]: > https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html > [4]: https://www.kernel.org/doc/Documentation/spi/spidev I've iterated a bit on this to try to make some more sensible API, behaving reasonably about being able to set the SPI clock speed. I'm going to implement an mmap handler so I can have my low-latency operation mode, as well. I don't like the Linux APIs one bit because it's just not safe to allow all those configuration changes on a per-transfer basis... Moving this to -embedded because it's more apt than -hackers. --089e0115fd1cf06895051d9db585 Content-Type: application/octet-stream; name="spigen.patch" Content-Disposition: attachment; filename="spigen.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: 14f42ff4ece7e1ec3fe1 SW5kZXg6IGFybS9icm9hZGNvbS9iY20yODM1L2JjbTI4MzVfc3BpLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g YXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9zcGkuYwkocmV2aXNpb24gMjg2ODkwKQorKysg YXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9zcGkuYwkod29ya2luZyBjb3B5KQpAQCAtMTA3 LDYgKzEwNywyNSBAQAogCUJDTV9TUElfV1JJVEUoc2MsIG9mZiwgcmVnKTsKIH0KIAorLyoKKyAq IFNldCB0aGUgY2xvY2sgc3BlZWQgcmVnaXN0ZXIgYW5kIHJldHVybiB0aGUgY2xvY2sgc3BlZWQg YWN0dWFsbHkgdXNlZCwKKyAqIGFmdGVyIGNvcnJlY3Rpb25zIHRvIGZpdCB3aXRoaW4gU1BJX0NP UkVfQ0xLLgorICovCitzdGF0aWMgdWludDMyX3QKK2JjbV9zcGlfc2V0X2Nsb2NrX3NwZWVkKHN0 cnVjdCBiY21fc3BpX3NvZnRjICpzYywgY29uc3QgdWludDMyX3QgY2xvY2tfc3BlZWQpCit7CisJ dWludDMyX3QgY2xrID0gU1BJX0NPUkVfQ0xLIC8gY2xvY2tfc3BlZWQ7CisKKwlpZiAoY2xrIDw9 IDEpCisJCWNsayA9IDI7CisJZWxzZSBpZiAoY2xrICUgMikKKwkJY2xrLS07CisJaWYgKGNsayA+ IDB4ZmZmZikKKwkJY2xrID0gMDsKKwlCQ01fU1BJX1dSSVRFKHNjLCBTUElfQ0xLLCBjbGspOwor CXJldHVybiAoY2xrID09IDAgPyAwIDogU1BJX0NPUkVfQ0xLIC8gY2xrKTsKK30KKwogc3RhdGlj IGludAogYmNtX3NwaV9jbG9ja19wcm9jKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CkBAIC0xMTcs MjYgKzEzNiwxOSBAQAogCXNjID0gKHN0cnVjdCBiY21fc3BpX3NvZnRjICopYXJnMTsKIAogCUJD TV9TUElfTE9DSyhzYyk7Ci0JY2xrID0gQkNNX1NQSV9SRUFEKHNjLCBTUElfQ0xLKTsKKwljbGsg PSBzYy0+c2NfY2xvY2tfc3BlZWQ7CiAJQkNNX1NQSV9VTkxPQ0soc2MpOwotCWNsayAmPSAweGZm ZmY7Ci0JaWYgKGNsayA9PSAwKQotCQljbGsgPSA2NTUzNjsKLQljbGsgPSBTUElfQ09SRV9DTEsg LyBjbGs7CiAKIAllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZjbGssIHNpemVvZihj bGspLCByZXEpOwogCWlmIChlcnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCiAJCXJl dHVybiAoZXJyb3IpOwogCi0JY2xrID0gU1BJX0NPUkVfQ0xLIC8gY2xrOwotCWlmIChjbGsgPD0g MSkKLQkJY2xrID0gMjsKLQllbHNlIGlmIChjbGsgJSAyKQotCQljbGstLTsKLQlpZiAoY2xrID4g MHhmZmZmKQotCQljbGsgPSAwOwogCUJDTV9TUElfTE9DSyhzYyk7Ci0JQkNNX1NQSV9XUklURShz YywgU1BJX0NMSywgY2xrKTsKKwlpZiAoc2MtPnNjX2ZsYWdzICYgQkNNX1NQSV9CVVNZKSB7CisJ CUJDTV9TUElfVU5MT0NLKHNjKTsKKwkJcmV0dXJuIChFQlVTWSk7CisJfQorCXNjLT5zY19jbG9j a19zcGVlZCA9IGJjbV9zcGlfc2V0X2Nsb2NrX3NwZWVkKHNjLCBjbGspOwogCUJDTV9TUElfVU5M T0NLKHNjKTsKIAogCXJldHVybiAoMCk7CkBAIC0zMTAsNyArMzIyLDggQEAKIAlCQ01fU1BJX1dS SVRFKHNjLCBTUElfQ1MsIFNQSV9DU19DTEVBUl9SWEZJRk8gfCBTUElfQ1NfQ0xFQVJfVFhGSUZP KTsKIAogCS8qIFNldCB0aGUgU1BJIGNsb2NrIHRvIDUwMEtoei4gKi8KLQlCQ01fU1BJX1dSSVRF KHNjLCBTUElfQ0xLLCBTUElfQ09SRV9DTEsgLyA1MDAwMDApOworCXNjLT5zY19jbG9ja19zcGVl ZCA9IDUwMDAwMDsKKwlCQ01fU1BJX1dSSVRFKHNjLCBTUElfQ0xLLCBTUElfQ09SRV9DTEsgLyBz Yy0+c2NfY2xvY2tfc3BlZWQpOwogCiAjaWZkZWYJQkNNX1NQSV9ERUJVRwogCWJjbV9zcGlfcHJp bnRyKGRldik7CkBAIC00MTgsNiArNDMxLDcgQEAKIGJjbV9zcGlfdHJhbnNmZXIoZGV2aWNlX3Qg ZGV2LCBkZXZpY2VfdCBjaGlsZCwgc3RydWN0IHNwaV9jb21tYW5kICpjbWQpCiB7CiAJc3RydWN0 IGJjbV9zcGlfc29mdGMgKnNjOworCWNvbnN0IHVpbnQzMl90IGNsb2NrX3NwZWVkX2h6ID0gY21k LT5jbG9ja19zcGVlZF9oejsKIAlpbnQgY3MsIGVycjsKIAogCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOwpAQCAtNDUwLDYgKzQ2NCwxMCBAQAogCSAgICBTUElfQ1NfQ0xFQVJfUlhGSUZPIHwg U1BJX0NTX0NMRUFSX1RYRklGTywKIAkgICAgU1BJX0NTX0NMRUFSX1JYRklGTyB8IFNQSV9DU19D TEVBUl9UWEZJRk8pOwogCisJLyogU3dpdGNoIGNsb2NrIHNwZWVkIGlmIG5lY2Vzc2FyeS4gKi8K KwlpZiAoY2xvY2tfc3BlZWRfaHogIT0gMCAmJiBjbG9ja19zcGVlZF9oeiAhPSBzYy0+c2NfY2xv Y2tfc3BlZWQpCisJCWJjbV9zcGlfc2V0X2Nsb2NrX3NwZWVkKHNjLCBjbG9ja19zcGVlZF9oeik7 CisKIAkvKiBTYXZlIGEgcG9pbnRlciB0byB0aGUgU1BJIGNvbW1hbmQuICovCiAJc2MtPnNjX2Nt ZCA9IGNtZDsKIAlzYy0+c2NfcmVhZCA9IDA7CkBAIC00NzAsNiArNDg4LDEwIEBACiAJLyogTWFr ZSBzdXJlIHRoZSBTUEkgZW5naW5lIGFuZCBpbnRlcnJ1cHRzIGFyZSBkaXNhYmxlZC4gKi8KIAli Y21fc3BpX21vZGlmeXJlZyhzYywgU1BJX0NTLCBTUElfQ1NfVEEgfCBTUElfQ1NfSU5UUiB8IFNQ SV9DU19JTlRELCAwKTsKIAorCS8qIFN3aXRjaCB0aGUgY2xvY2sgc3BlZWQgYmFjayBpZiBuZWNl c3NhcnkuICovCisJaWYgKGNsb2NrX3NwZWVkX2h6ICE9IDAgJiYgY2xvY2tfc3BlZWRfaHogIT0g c2MtPnNjX2Nsb2NrX3NwZWVkKQorCQliY21fc3BpX3NldF9jbG9ja19zcGVlZChzYywgc2MtPnNj X2Nsb2NrX3NwZWVkKTsKKwogCS8qIFJlbGVhc2UgdGhlIGNvbnRyb2xsZXIgYW5kIHdha2V1cCB0 aGUgbmV4dCB0aHJlYWQgd2FpdGluZyBmb3IgaXQuICovCiAJc2MtPnNjX2ZsYWdzID0gMDsKIAl3 YWtldXBfb25lKGRldik7CkBAIC00ODcsNiArNTA5LDcgQEAKIAlyZXR1cm4gKGVycik7CiB9CiAK Kwogc3RhdGljIHBoYW5kbGVfdAogYmNtX3NwaV9nZXRfbm9kZShkZXZpY2VfdCBidXMsIGRldmlj ZV90IGRldikKIHsKSW5kZXg6IGFybS9icm9hZGNvbS9iY20yODM1L2JjbTI4MzVfc3BpdmFyLmgK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9zcGl2YXIuaAkocmV2 aXNpb24gMjg2ODkwKQorKysgYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9zcGl2YXIuaAko d29ya2luZyBjb3B5KQpAQCAtNTQsNiArNTQsNyBAQAogCXVpbnQzMl90CQlzY19yZWFkOwogCXVp bnQzMl90CQlzY19mbGFnczsKIAl1aW50MzJfdAkJc2Nfd3JpdHRlbjsKKwl1aW50MzJfdAkJc2Nf Y2xvY2tfc3BlZWQ7CiAJdm9pZCAqCQkJc2NfaW50cmhhbmQ7CiB9OwogCkluZGV4OiBhcm0vY29u Zi9SUEkyCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIGFybS9jb25mL1JQSTIJKHJldmlzaW9uIDI4Njg5MCkKKysr IGFybS9jb25mL1JQSTIJKHdvcmtpbmcgY29weSkKQEAgLTI0LDcgKzI0LDcgQEAKIGluY2x1ZGUg CSIuLi9icm9hZGNvbS9iY20yODM1L3N0ZC5ycGkiCiBpbmNsdWRlIAkiLi4vYnJvYWRjb20vYmNt MjgzNS9zdGQuYmNtMjgzNiIKIAotb3B0aW9ucyAJSFo9MTAwCitvcHRpb25zIAlIWj0xMDAwCiBv cHRpb25zIAlTQ0hFRF9VTEUJCSMgVUxFIHNjaGVkdWxlcgogb3B0aW9ucyAJU01QCQkJIyBFbmFi bGUgbXVsdGlwbGUgY29yZXMKIG9wdGlvbnMgCVBMQVRGT1JNCkBAIC0zNSw3ICszNSw3IEBACiAj b3B0aW9ucyAJVkVSQk9TRV9TWVNJTklUCQkjIEVuYWJsZSB2ZXJib3NlIHN5c2luaXQgbWVzc2Fn ZXMKIG9wdGlvbnMgCUtEQgkJCSMgRW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0CiAjIEZv ciBtaW5pbXVtIGRlYnVnZ2VyIHN1cHBvcnQgKHN0YWJsZSBicmFuY2gpIHVzZToKLSNvcHRpb25z IAlLREJfVFJBQ0UJCSMgUHJpbnQgYSBzdGFjayB0cmFjZSBmb3IgYSBwYW5pYworb3B0aW9ucyAJ S0RCX1RSQUNFCQkjIFByaW50IGEgc3RhY2sgdHJhY2UgZm9yIGEgcGFuaWMKICMgRm9yIGZ1bGwg ZGVidWdnZXIgc3VwcG9ydCB1c2UgdGhpcyBpbnN0ZWFkOgogb3B0aW9ucyAJRERCCQkJIyBFbmFi bGUgdGhlIGtlcm5lbCBkZWJ1Z2dlcgogb3B0aW9ucyAJSU5WQVJJQU5UUwkJIyBFbmFibGUgY2Fs bHMgb2YgZXh0cmEgc2FuaXR5IGNoZWNraW5nCkluZGV4OiBhcm0vbHBjL3NzZDEyODkuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBhcm0vbHBjL3NzZDEyODkuYwkocmV2aXNpb24gMjg2ODkwKQorKysgYXJtL2xw Yy9zc2QxMjg5LmMJKHdvcmtpbmcgY29weSkKQEAgLTE1Nyw3ICsxNTcsOCBAQAogc3RhdGljIF9f aW5saW5lIHZvaWQKIHNzZDEyODlfc3BpX3NlbmQoc3RydWN0IHNzZDEyODlfc29mdGMgKnNjLCB1 aW50OF90ICpkYXRhLCBpbnQgbGVuKQogewotCXN0cnVjdCBzcGlfY29tbWFuZCBjbWQ7CisJc3Ry dWN0IHNwaV9jb21tYW5kIGNtZCA9IFNQSV9DT01NQU5EX0lOSVRJQUxJWkVSOworCiAJdWludDhf dCBidWZmZXJbOF07CiAJY21kLnR4X2NtZCA9IGRhdGE7CiAJY21kLnR4X2NtZF9zeiA9IGxlbjsK SW5kZXg6IGNvbmYvZmlsZXMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29uZi9maWxlcwkocmV2aXNpb24gMjg2 ODkwKQorKysgY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMjQ1Miw2ICsyNDUyLDcgQEAK IGRldi9zcGlidXMvb2Z3X3NwaWJ1cy5jCQlvcHRpb25hbCBmZHQgc3BpYnVzCiBkZXYvc3BpYnVz L3NwaWJ1cy5jCQlvcHRpb25hbCBzcGlidXMJCQkJXAogCWRlcGVuZGVuY3kJInNwaWJ1c19pZi5o IgorZGV2L3NwaWJ1cy9zcGlnZW4uYwkJb3B0aW9uYWwgc3BpYnVzCiBkZXYvc3BpYnVzL3NwaWJ1 c19pZi5tCQlvcHRpb25hbCBzcGlidXMKIGRldi9zdGUvaWZfc3RlLmMJCW9wdGlvbmFsIHN0ZSBw Y2kKIGRldi9zdGcvdG1jMThjMzAuYwkJb3B0aW9uYWwgc3RnCkluZGV4OiBkZXYvc3BpYnVzL3Nw aS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIGRldi9zcGlidXMvc3BpLmgJKHJldmlzaW9uIDI4Njg5MCkKKysr IGRldi9zcGlidXMvc3BpLmgJKHdvcmtpbmcgY29weSkKQEAgLTI3LDYgKzI3LDcgQEAKICAqLwog CiBzdHJ1Y3Qgc3BpX2NvbW1hbmQgeworCXVpbnQzMl90IGNsb2NrX3NwZWVkX2h6OwogCXZvaWQJ KnR4X2NtZDsKIAl1aW50MzJfdCB0eF9jbWRfc3o7CiAJdm9pZAkqcnhfY21kOwpAQCAtMzcsNCAr MzgsNiBAQAogCXVpbnQzMl90IHJ4X2RhdGFfc3o7CiB9OwogCisjZGVmaW5lCVNQSV9DT01NQU5E X0lOSVRJQUxJWkVSCXsgMCB9CisKICNkZWZpbmUJU1BJX0NISVBfU0VMRUNUX0hJR0gJMHgxCQkv KiBDaGlwIHNlbGVjdCBoaWdoIChlbHNlIGxvdykgKi8KSW5kZXg6IGRldi9zcGlidXMvc3BpZ2Vu LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gZGV2L3NwaWJ1cy9zcGlnZW4uYwkocmV2aXNpb24gMCkKKysrIGRl di9zcGlidXMvc3BpZ2VuLmMJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwyNzkgQEAKKy8qLQor ICogQ29weXJpZ2h0IChjKSAyMDE1IEJyaWFuIEZ1bmRha293c2tpIEZlbGRtYW4uICBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIEFVVEhPUiBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNTIE9SCisgKiBJTVBMSUVEIFdB UlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJS QU5USUVTCisgKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgorICogSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhP UiBCRSBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULAorICogSU5DSURFTlRBTCwgU1BF Q0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVU CisgKiBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBT RVJWSUNFUzsgTE9TUyBPRiBVU0UsCisgKiBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJ TlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkKKyAqIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQKKyAq IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBP VVQgT0YgVEhFIFVTRSBPRgorICogVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRI RSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZz Lmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNp bmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8c3lz L2NvbmYuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL2xvY2suaD4K KyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5jbHVk ZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9zcGlnZW5pby5oPgorI2luY2x1ZGUgPHN5 cy9zeXNjdGwuaD4KKworI2luY2x1ZGUgPGRldi9zcGlidXMvc3BpLmg+CisKKyNpbmNsdWRlICJz cGlidXNfaWYuaCIKKworc3RydWN0IHNwaWdlbl9zb2Z0YyB7CisJZGV2aWNlX3Qgc2NfZGV2Owor CXN0cnVjdCBjZGV2ICpzY19jZGV2OworCXN0cnVjdCBtdHggc2NfbXR4OworCXVpbnQzMl90IHNj X2Nsb2NrX3NwZWVkOworCXVpbnQzMl90IHNjX2NvbW1hbmRfbGVuZ3RoX21heDsKKwl1aW50MzJf dCBzY19kYXRhX2xlbmd0aF9tYXg7CisJdm9pZCAqc2NfY29tbWFuZF9kYXRhX2FyZWE7Cit9Owor CitzdGF0aWMgaW50CitzcGlnZW5fcHJvYmUoZGV2aWNlX3QgZGV2KQoreworCWRldmljZV9zZXRf ZGVzYyhkZXYsICJTUEkgR2VuZXJpYyBJTyIpOworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBp bnQgc3BpZ2VuX29wZW4oc3RydWN0IGNkZXYgKiwgaW50LCBpbnQsIHN0cnVjdCB0aHJlYWQgKik7 CitzdGF0aWMgaW50IHNwaWdlbl9pb2N0bChzdHJ1Y3QgY2RldiAqLCB1X2xvbmcsIGNhZGRyX3Qs IGludCwgc3RydWN0IHRocmVhZCAqKTsKK3N0YXRpYyBpbnQgc3BpZ2VuX2Nsb3NlKHN0cnVjdCBj ZGV2ICosIGludCwgaW50LCBzdHJ1Y3QgdGhyZWFkICopOworCitzdGF0aWMgc3RydWN0IGNkZXZz dyBzcGlnZW5fY2RldnN3ID0geworCS5kX3ZlcnNpb24gPSBEX1ZFUlNJT04sCisJLmRfbmFtZSA9 ICAgICJzcGlnZW4iLAorCS5kX29wZW4gPSAgICBzcGlnZW5fb3BlbiwKKwkuZF9pb2N0bCA9ICAg c3BpZ2VuX2lvY3RsLAorCS5kX2Nsb3NlID0gICBzcGlnZW5fY2xvc2UKK307CisKK3N0YXRpYyBp bnQKK3NwaWdlbl9jb21tYW5kX2xlbmd0aF9tYXhfcHJvYyhTWVNDVExfSEFORExFUl9BUkdTKQor eworCXN0cnVjdCBzcGlnZW5fc29mdGMgKnNjID0gKHN0cnVjdCBzcGlnZW5fc29mdGMgKilhcmcx OworCXVpbnQzMl90IGNvbW1hbmRfbGVuZ3RoX21heDsKKwlpbnQgZXJyb3I7CisKKwltdHhfbG9j aygmc2MtPnNjX210eCk7CisJY29tbWFuZF9sZW5ndGhfbWF4ID0gc2MtPnNjX2NvbW1hbmRfbGVu Z3RoX21heDsKKwltdHhfdW5sb2NrKCZzYy0+c2NfbXR4KTsKKwllcnJvciA9IHN5c2N0bF9oYW5k bGVfaW50KG9pZHAsICZjb21tYW5kX2xlbmd0aF9tYXgsCisJICAgIHNpemVvZihjb21tYW5kX2xl bmd0aF9tYXgpLCByZXEpOworCWlmIChlcnJvciA9PSAwICYmIHJlcS0+bmV3cHRyICE9IE5VTEwp IHsKKwkJbXR4X2xvY2soJnNjLT5zY19tdHgpOworCQkvKiBYWFggRUJVU1kgd2hlbiBtbWFwcGVk IHRlc3QgKi8KKwkJc2MtPnNjX2NvbW1hbmRfbGVuZ3RoX21heCA9IGNvbW1hbmRfbGVuZ3RoX21h eDsKKwkJbXR4X3VubG9jaygmc2MtPnNjX210eCk7CisJfQorCXJldHVybiAoZXJyb3IpOworfQor CitzdGF0aWMgaW50CitzcGlnZW5fZGF0YV9sZW5ndGhfbWF4X3Byb2MoU1lTQ1RMX0hBTkRMRVJf QVJHUykKK3sKKwlzdHJ1Y3Qgc3BpZ2VuX3NvZnRjICpzYyA9IChzdHJ1Y3Qgc3BpZ2VuX3NvZnRj ICopYXJnMTsKKwl1aW50MzJfdCBkYXRhX2xlbmd0aF9tYXg7CisJaW50IGVycm9yOworCisJbXR4 X2xvY2soJnNjLT5zY19tdHgpOworCWRhdGFfbGVuZ3RoX21heCA9IHNjLT5zY19kYXRhX2xlbmd0 aF9tYXg7CisJbXR4X3VubG9jaygmc2MtPnNjX210eCk7CisJZXJyb3IgPSBzeXNjdGxfaGFuZGxl X2ludChvaWRwLCAmZGF0YV9sZW5ndGhfbWF4LAorCSAgICBzaXplb2YoZGF0YV9sZW5ndGhfbWF4 KSwgcmVxKTsKKwlpZiAoZXJyb3IgPT0gMCAmJiByZXEtPm5ld3B0ciAhPSBOVUxMKSB7CisJCW10 eF9sb2NrKCZzYy0+c2NfbXR4KTsKKwkJLyogWFhYIEVCVVNZIHdoZW4gbW1hcHBlZCB0ZXN0ICov CisJCXNjLT5zY19kYXRhX2xlbmd0aF9tYXggPSBkYXRhX2xlbmd0aF9tYXg7CisJCW10eF91bmxv Y2soJnNjLT5zY19tdHgpOworCX0KKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGljIHZvaWQK K3NwaWdlbl9zeXNjdGxfaW5pdChzdHJ1Y3Qgc3BpZ2VuX3NvZnRjICpzYykKK3sKKwlzdHJ1Y3Qg c3lzY3RsX2N0eF9saXN0ICpjdHg7CisJc3RydWN0IHN5c2N0bF9vaWQgKnRyZWVfbm9kZTsKKwlz dHJ1Y3Qgc3lzY3RsX29pZF9saXN0ICp0cmVlOworCisJLyoKKwkgKiBBZGQgc3lzdGVtIHN5c2N0 bCB0cmVlL2hhbmRsZXJzLgorCSAqLworCWN0eCA9IGRldmljZV9nZXRfc3lzY3RsX2N0eChzYy0+ c2NfZGV2KTsKKwl0cmVlX25vZGUgPSBkZXZpY2VfZ2V0X3N5c2N0bF90cmVlKHNjLT5zY19kZXYp OworCXRyZWUgPSBTWVNDVExfQ0hJTERSRU4odHJlZV9ub2RlKTsKKwlTWVNDVExfQUREX1BST0Mo Y3R4LCB0cmVlLCBPSURfQVVUTywgImNvbW1hbmRfbGVuZ3RoX21heCIsCisJICAgIENUTEZMQUdf TVBTQUZFIHwgQ1RMRkxBR19SVyB8IENUTFRZUEVfVUlOVCwgc2MsIHNpemVvZigqc2MpLAorCSAg ICBzcGlnZW5fY29tbWFuZF9sZW5ndGhfbWF4X3Byb2MsICJJVSIsICJTUEkgY29tbWFuZCBoZWFk ZXIgcG9ydGlvbiAob2N0ZXRzKSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9B VVRPLCAiZGF0YV9sZW5ndGhfbWF4IiwKKwkgICAgQ1RMRkxBR19NUFNBRkUgfCBDVExGTEFHX1JX IHwgQ1RMVFlQRV9VSU5ULCBzYywgc2l6ZW9mKCpzYyksCisJICAgIHNwaWdlbl9kYXRhX2xlbmd0 aF9tYXhfcHJvYywgIklVIiwgIlNQSSBkYXRhIHRyYWlsZXIgcG9ydGlvbiAob2N0ZXRzKSIpOwor fQorCitzdGF0aWMgaW50CitzcGlnZW5fYXR0YWNoKGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3Qg c3BpZ2VuX3NvZnRjICpzYzsKKwljb25zdCBpbnQgdW5pdCA9IGRldmljZV9nZXRfdW5pdChkZXYp OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2RldiA9IGRldjsKKwlz Yy0+c2NfY2RldiA9IG1ha2VfZGV2KCZzcGlnZW5fY2RldnN3LCB1bml0LAorCSAgICBVSURfUk9P VCwgR0lEX09QRVJBVE9SLCAwNjYwLCAic3BpZ2VuJWQiLCB1bml0KTsKKwlzYy0+c2NfY2Rldi0+ c2lfZHJ2MSA9IGRldjsKKwlzYy0+c2NfY29tbWFuZF9sZW5ndGhfbWF4ID0gUEFHRV9TSVpFOwor CXNjLT5zY19kYXRhX2xlbmd0aF9tYXggPSBQQUdFX1NJWkU7CisJbXR4X2luaXQoJnNjLT5zY19t dHgsIGRldmljZV9nZXRfbmFtZXVuaXQoZGV2KSwgTlVMTCwgTVRYX0RFRik7CisJc3BpZ2VuX3N5 c2N0bF9pbml0KHNjKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQgCitzcGlnZW5f b3BlbihzdHJ1Y3QgY2RldiAqZGV2LCBpbnQgb2ZsYWdzLCBpbnQgZGV2dHlwZSwgc3RydWN0IHRo cmVhZCAqdGQpCit7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitzcGlnZW5fdHJh bnNmZXIoc3RydWN0IGNkZXYgKmNkZXYsIHN0cnVjdCBzcGlnZW5fdHJhbnNmZXIgKnN0KQorewor CXN0cnVjdCBzcGlfY29tbWFuZCB0cmFuc2ZlciA9IFNQSV9DT01NQU5EX0lOSVRJQUxJWkVSOwor CWRldmljZV90IGRldiA9IGNkZXYtPnNpX2RydjE7CisJc3RydWN0IHNwaWdlbl9zb2Z0YyAqc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJaW50IGVycm9yID0gMDsKKworCW10eF9sb2NrKCZz Yy0+c2NfbXR4KTsKKwlpZiAoc3QtPnN0X2NvbW1hbmQuaW92X2xlbiA9PSAwIHx8IHN0LT5zdF9k YXRhLmlvdl9sZW4gPT0gMCkKKwkJZXJyb3IgPSBFSU5WQUw7CisJZWxzZSBpZiAoc3QtPnN0X2Nv bW1hbmQuaW92X2xlbiA+IHNjLT5zY19jb21tYW5kX2xlbmd0aF9tYXggfHwKKwkgICAgc3QtPnN0 X2RhdGEuaW92X2xlbiA+IHNjLT5zY19kYXRhX2xlbmd0aF9tYXgpCisJCWVycm9yID0gRU5PTUVN OworCWVsc2UKKwkJdHJhbnNmZXIuY2xvY2tfc3BlZWRfaHogPSBzYy0+c2NfY2xvY2tfc3BlZWQ7 CisJbXR4X3VubG9jaygmc2MtPnNjX210eCk7CisJaWYgKGVycm9yKQorCQlyZXR1cm4gKGVycm9y KTsKKwkKKyNpZiAwCisJZGV2aWNlX3ByaW50ZihkZXYsICJjbWQgJXAgJXUgZGF0YSAlcCAldVxu Iiwgc3QtPnN0X2NvbW1hbmQuaW92X2Jhc2UsCisJICAgIHN0LT5zdF9jb21tYW5kLmlvdl9sZW4s IHN0LT5zdF9kYXRhLmlvdl9iYXNlLCBzdC0+c3RfZGF0YS5pb3ZfbGVuKTsKKyNlbmRpZgorCXRy YW5zZmVyLnR4X2NtZCA9IHRyYW5zZmVyLnJ4X2NtZCA9IG1hbGxvYyhzdC0+c3RfY29tbWFuZC5p b3ZfbGVuLAorCSAgICBNX0RFVkJVRiwgTV9XQUlUT0spOworCWlmICh0cmFuc2Zlci50eF9jbWQg PT0gTlVMTCkKKwkJcmV0dXJuIChFTk9NRU0pOworCXRyYW5zZmVyLnR4X2RhdGEgPSB0cmFuc2Zl ci5yeF9kYXRhID0gbWFsbG9jKHN0LT5zdF9kYXRhLmlvdl9sZW4sCisJICAgIE1fREVWQlVGLCBN X1dBSVRPSyk7CisJaWYgKHRyYW5zZmVyLnR4X2RhdGEgPT0gTlVMTCkgeworCQlmcmVlKHRyYW5z ZmVyLnR4X2NtZCwgTV9ERVZCVUYpOworCQlyZXR1cm4gKEVOT01FTSk7CisJfQorCisJZXJyb3Ig PSBjb3B5aW4oc3QtPnN0X2NvbW1hbmQuaW92X2Jhc2UsIHRyYW5zZmVyLnR4X2NtZCwKKwkgICAg dHJhbnNmZXIudHhfY21kX3N6ID0gdHJhbnNmZXIucnhfY21kX3N6ID0gc3QtPnN0X2NvbW1hbmQu aW92X2xlbik7CQorCWlmIChlcnJvciA9PSAwKQorCQllcnJvciA9IGNvcHlpbihzdC0+c3RfZGF0 YS5pb3ZfYmFzZSwgdHJhbnNmZXIudHhfZGF0YSwKKwkJICAgIHRyYW5zZmVyLnR4X2RhdGFfc3og PSB0cmFuc2Zlci5yeF9kYXRhX3N6ID0KKwkJICAgICAgICAgICAgICAgICAgICAgICAgICBzdC0+ c3RfZGF0YS5pb3ZfbGVuKTsJCisJaWYgKGVycm9yID09IDApCisJCWVycm9yID0gU1BJQlVTX1RS QU5TRkVSKGRldmljZV9nZXRfcGFyZW50KGRldiksIGRldiwgJnRyYW5zZmVyKTsKKwlpZiAoZXJy b3IgPT0gMCkgeworCQllcnJvciA9IGNvcHlvdXQodHJhbnNmZXIucnhfY21kLCBzdC0+c3RfY29t bWFuZC5pb3ZfYmFzZSwKKwkJICAgIHRyYW5zZmVyLnJ4X2NtZF9zeik7CisJCWlmIChlcnJvciA9 PSAwKQorCQkJZXJyb3IgPSBjb3B5b3V0KHRyYW5zZmVyLnJ4X2RhdGEsIHN0LT5zdF9kYXRhLmlv dl9iYXNlLAorCQkJICAgIHRyYW5zZmVyLnJ4X2RhdGFfc3opOworCX0KKworCWZyZWUodHJhbnNm ZXIudHhfY21kLCBNX0RFVkJVRik7CisJZnJlZSh0cmFuc2Zlci50eF9kYXRhLCBNX0RFVkJVRik7 CisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK3NwaWdlbl9pb2N0bChzdHJ1Y3Qg Y2RldiAqY2RldiwgdV9sb25nIGNtZCwgY2FkZHJfdCBkYXRhLCBpbnQgZmZsYWcsCisgICAgc3Ry dWN0IHRocmVhZCAqdGQpCit7CisJZGV2aWNlX3QgZGV2ID0gY2Rldi0+c2lfZHJ2MTsKKwlzdHJ1 Y3Qgc3BpZ2VuX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlpbnQgZXJyb3I7 CisKKwlzd2l0Y2ggKGNtZCkgeworCWNhc2UgU1BJR0VOSU9DX1RSQU5TRkVSOgorCQllcnJvciA9 IHNwaWdlbl90cmFuc2ZlcihjZGV2LCAoc3RydWN0IHNwaWdlbl90cmFuc2ZlciAqKWRhdGEpOwor CQlicmVhazsKKwljYXNlIFNQSUdFTklPQ19HRVRfQ0xPQ0tfU1BFRUQ6CisJCW10eF9sb2NrKCZz Yy0+c2NfbXR4KTsKKwkJKih1aW50MzJfdCAqKWRhdGEgPSBzYy0+c2NfY2xvY2tfc3BlZWQ7CisJ CW10eF91bmxvY2soJnNjLT5zY19tdHgpOworCQllcnJvciA9IDA7CisJCWJyZWFrOworCWNhc2Ug U1BJR0VOSU9DX1NFVF9DTE9DS19TUEVFRDoKKwkJbXR4X2xvY2soJnNjLT5zY19tdHgpOworCQlz Yy0+c2NfY2xvY2tfc3BlZWQgPSAqKHVpbnQzMl90ICopZGF0YTsKKwkJbXR4X3VubG9jaygmc2Mt PnNjX210eCk7CisJCWVycm9yID0gMDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJZXJyb3IgPSBF T1BOT1RTVVBQOworCX0KKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGljIGludCAKK3NwaWdl bl9jbG9zZShzdHJ1Y3QgY2RldiAqZGV2LCBpbnQgZmZsYWcsIGludCBkZXZ0eXBlLCBzdHJ1Y3Qg dGhyZWFkICp0ZCkKK3sKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK3NwaWdlbl9k ZXRhY2goZGV2aWNlX3QgZGV2KQoreworCisJcmV0dXJuIChFSU8pOworfQorCitzdGF0aWMgZGV2 Y2xhc3NfdCBzcGlnZW5fZGV2Y2xhc3M7CisKK3N0YXRpYyBkZXZpY2VfbWV0aG9kX3Qgc3BpZ2Vu X21ldGhvZHNbXSA9IHsKKwkvKiBEZXZpY2UgaW50ZXJmYWNlICovCisJREVWTUVUSE9EKGRldmlj ZV9wcm9iZSwJCXNwaWdlbl9wcm9iZSksCisJREVWTUVUSE9EKGRldmljZV9hdHRhY2gsCXNwaWdl bl9hdHRhY2gpLAorCURFVk1FVEhPRChkZXZpY2VfZGV0YWNoLAlzcGlnZW5fZGV0YWNoKSwKKwor CXsgMCwgMCB9Cit9OworCitzdGF0aWMgZHJpdmVyX3Qgc3BpZ2VuX2RyaXZlciA9IHsKKwkic3Bp Z2VuIiwKKwlzcGlnZW5fbWV0aG9kcywKKwlzaXplb2Yoc3RydWN0IHNwaWdlbl9zb2Z0YyksCit9 OworCitEUklWRVJfTU9EVUxFKHNwaWdlbiwgc3BpYnVzLCBzcGlnZW5fZHJpdmVyLCBzcGlnZW5f ZGV2Y2xhc3MsIDAsIDApOwoKUHJvcGVydHkgY2hhbmdlcyBvbjogZGV2L3NwaWJ1cy9zcGlnZW4u YwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpc IE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAs MCArMSAjIworRnJlZUJTRD0lSApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVk OiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0 IGVuZCBvZiBwcm9wZXJ0eQpJbmRleDogc3lzL3NwaWdlbmlvLmgKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L3NwaWdlbmlvLmgJKHJldmlzaW9uIDApCisrKyBzeXMvc3BpZ2VuaW8uaAkod29ya2luZyBjb3B5 KQpAQCAtMCwwICsxLDUyIEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAwMCBEb3VnIFJhYnNv bgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNl IGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNh dGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9u cworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0 IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJp YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJF IElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5E CisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5P VCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1F RC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM RQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVN UExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBM SU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNF UzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElP TikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hF VEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElO RyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0Yg VEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM SVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKgkkRnJlZUJTRCQKKyAqLworCisjaWZuZGVm IF9TWVNfU1BJR0VOSU9fSF8KKyNkZWZpbmUgX1NZU19TUElHRU5JT19IXworCisjaW5jbHVkZSA8 c3lzL19pb3ZlYy5oPgorCitzdHJ1Y3Qgc3BpZ2VuX3RyYW5zZmVyIHsKKwlzdHJ1Y3QgaW92ZWMg c3RfY29tbWFuZDsgLyogbWFzdGVyIHRvIHNsYXZlICovCisJc3RydWN0IGlvdmVjIHN0X2RhdGE7 ICAgIC8qIHNsYXZlIHRvIG1hc3RlciBhbmQvb3IgbWFzdGVyIHRvIHNsYXZlICovCit9OworCitz dHJ1Y3Qgc3BpZ2VuX3RyYW5zZmVyX21tYXBwZWQgeworCXNpemVfdCBzdG1fY29tbWFuZF9sZW5n dGg7IC8qIGF0IG9mZnNldCAwIGluIG1tYXAoMikgYXJlYSAqLworCXNpemVfdCBzdG1fZGF0YV9s ZW5ndGg7ICAgIC8qIGF0IG9mZnNldCBzdG1fY29tbWFuZF9sZW5ndGggKi8KK307CisKKyNkZWZp bmUgU1BJR0VOSU9DX0JBU0UgICAgICdTJworI2RlZmluZSBTUElHRU5JT0NfVFJBTlNGRVIgCSAg IF9JT1coU1BJR0VOSU9DX0JBU0UsIDAsIFwKKwkgICAgc3RydWN0IHNwaWdlbl90cmFuc2ZlcikK KyNkZWZpbmUgU1BJR0VOSU9DX1RSQU5TRkVSX01NQVBQRUQgX0lPVyhTUElHRU5JT0NfQkFTRSwg MSwgXAorCSAgICBzdHJ1Y3Qgc3BpZ2VuX3RyYW5zZmVyX21tYXBwZWQpCisjZGVmaW5lIFNQSUdF TklPQ19HRVRfQ0xPQ0tfU1BFRUQgIF9JT1IoU1BJR0VOSU9DX0JBU0UsIDIsIHVpbnQzMl90KQor I2RlZmluZSBTUElHRU5JT0NfU0VUX0NMT0NLX1NQRUVEICBfSU9XKFNQSUdFTklPQ19CQVNFLCAz LCB1aW50MzJfdCkKKworI2VuZGlmIC8qICFfU1lTX1NQSUdFTklPX0hfICovCgpQcm9wZXJ0eSBj aGFuZ2VzIG9uOiBzeXMvc3BpZ2VuaW8uaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxl CiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFk ZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAjIworRnJlZUJTRD0lSApcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQo= --089e0115fd1cf06895051d9db585-- From owner-freebsd-hackers@freebsd.org Wed Aug 19 03:03:10 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F1DD9BDB63 for ; Wed, 19 Aug 2015 03:03:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED85C860 for ; Wed, 19 Aug 2015 03:03:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-243-143.lns20.per4.internode.on.net [121.45.243.143]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t7J32wOo035011 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Aug 2015 20:03:01 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: System briefly freezes every time when a very large UFS directory is filled with files To: Yuri , Freebsd hackers list References: <55D38A75.6090508@rawbw.com> From: Julian Elischer Message-ID: <55D3F1DD.6090807@freebsd.org> Date: Wed, 19 Aug 2015 11:02:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D38A75.6090508@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 03:03:10 -0000 On 8/19/15 3:41 AM, Yuri wrote: > I have one directory that has ~1.2M files on UFS system. > Every time when the process that creates files there reaches a > particular point (~0.9M files), system invariably freezes for ~10 > seconds, after which it continues and process succeeds. Try increase the size of the directory hash/cache. > > I know that this is quite an extreme number of files but, other than > this problem, it is usable in this setup. > > Maybe someone can think of some fix or the immediate reason of such > freezes? This isn't a good problem to have, even in the view of an > extremity of this situation. > > Yuri > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Aug 19 09:02:07 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5CCF9BDCB1 for ; Wed, 19 Aug 2015 09:02:07 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4250FED7 for ; Wed, 19 Aug 2015 09:02:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t7J9218k036870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Aug 2015 11:02:02 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t7J91vAn005887; Wed, 19 Aug 2015 11:01:57 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t7J91qRV005884; Wed, 19 Aug 2015 11:01:52 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 19 Aug 2015 11:01:52 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Yuri cc: Freebsd hackers list Subject: Re: System briefly freezes every time when a very large UFS directory is filled with files In-Reply-To: <55D38A75.6090508@rawbw.com> Message-ID: References: <55D38A75.6090508@rawbw.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 19 Aug 2015 11:02:02 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:02:07 -0000 > I have one directory that has ~1.2M files on UFS system. > Every time when the process that creates files there reaches a particular > point (~0.9M files), system invariably freezes for ~10 seconds, after which > it continues and process succeeds. how large is your vfs.ufs.dirhash_maxmem > > I know that this is quite an extreme number of files but, other than this > problem, it is usable in this setup. > > Maybe someone can think of some fix or the immediate reason of such freezes? > This isn't a good problem to have, even in the view of an extremity of this > situation. > > Yuri > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Wed Aug 19 09:20:37 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A58619BDFAD for ; Wed, 19 Aug 2015 09:20:37 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 163D17FA; Wed, 19 Aug 2015 09:20:36 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t7J91SHJ036853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Aug 2015 11:01:29 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t7J91Or0005879; Wed, 19 Aug 2015 11:01:24 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t7J91HfZ005876; Wed, 19 Aug 2015 11:01:18 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 19 Aug 2015 11:01:17 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Julian Elischer cc: Yuri , Freebsd hackers list Subject: Re: System briefly freezes every time when a very large UFS directory is filled with files In-Reply-To: <55D3F1DD.6090807@freebsd.org> Message-ID: References: <55D38A75.6090508@rawbw.com> <55D3F1DD.6090807@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 19 Aug 2015 11:01:29 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:20:37 -0000 do you have UFS_DIRHASH enabled in kernel. without this you may expect huge slowdown and very low performance when accessing files from that directory. On Wed, 19 Aug 2015, Julian Elischer wrote: > On 8/19/15 3:41 AM, Yuri wrote: >> I have one directory that has ~1.2M files on UFS system. >> Every time when the process that creates files there reaches a particular >> point (~0.9M files), system invariably freezes for ~10 seconds, after which >> it continues and process succeeds. > Try increase the size of the directory hash/cache. >> >> I know that this is quite an extreme number of files but, other than this >> problem, it is usable in this setup. >> >> Maybe someone can think of some fix or the immediate reason of such >> freezes? This isn't a good problem to have, even in the view of an >> extremity of this situation. >> >> Yuri >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Thu Aug 20 13:02:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 059A39BDE77 for ; Thu, 20 Aug 2015 13:02:39 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-3.server.virginmedia.net (know-smtprelay-omc-3.server.virginmedia.net [80.0.253.67]) by mx1.freebsd.org (Postfix) with ESMTP id 516E09E8 for ; Thu, 20 Aug 2015 13:02:37 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-3-imp with bizsmtp id 711R1r00D0HtmFq0111R6H; Thu, 20 Aug 2015 14:01:25 +0100 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=TYVrzkkh c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=NLZqzBF-AAAA:8 a=n40ctHC_h8IA:10 a=N659UExz7-8A:10 a=6N1ahujPuNbNjhWrB9AA:9 a=pILNOxqGKmIA:10 a=XdyKOaxJwVsA:10 Subject: nosh version 1.18 To: debian-user@lists.debian.org, "supervision@list.skarnet.org" , FreeBSD Hackers References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> <556BA130.50708@NTLWorld.com> <55902328.8080602@NTLWorld.com> From: Jonathan de Boyne Pollard Message-ID: <55D5CFA2.5010402@NTLWorld.com> Date: Thu, 20 Aug 2015 14:01:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55902328.8080602@NTLWorld.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:02:39 -0000 nosh is now up to version 1.18 * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html The big news for this release is the nosh-run-system-manager Debian binary package. This, and the new additional service bundles in nosh-bundles, package up everything that is needed for running an entirely nosh-managed basic Debian system with the nosh system-manager program as process #1. And so the entry on the roadmap WWW page is crossed out. Some notes: * Don't forget that the Nosh Guide has a whole chapter on troubleshooting. * With that package alone, you get very little running. This is intentional. You'll have to install other nosh-run packages, or add presets, for the various other things that you want. To get an OpenSSH server running, for example, you'll need a local preset file (named, say, /etc/system-control/presets/20-sshd.preset) with "enable sshd" and "enable cyclog@sshd" before (re-)installing nosh-bundles. (Re-)Installing the nosh-bundles package (re-)applies all current presets, including your local ones, and auto-starts all enabled services. * If you are running the freedesktop services, read the notes hyperlinked-from the package download page. * You may have spotted that there's a choice between running udev and busybox mdev. (You pretty much must run one or the other for a fully functional system.) The nosh-run-busybox-mdev package is broken. I forgot to write the adapter tool. I've written it ready for version 1.19. There will be more said on the subject of busybox mdev in the 1.19 announcement, therefore. * It's also intentional that you don't get System 5 shim commands for the likes of "telinit" and "halt" unless you install the nosh-systemv-shims package. "system-control poweroff" works without the presence of the shims, of course. * For novices, I recommend starting with nosh-run-kernel-vt . nosh-run-user-vt still requires a manual step, after re-building the service configuration each time, of "system-control disable ttylogin@tty{1,2,3,4,5,6,7,8,9,10,11,12}". * The recovery mode misbehaviour is a known problem. I'm investigating. As a local fix, boot with init=/bin/sh on the kernel command line and then run "exec /sbin/init -s" or even "exec /sbin/init -b" from that shell prompt. This is not the only news, of course. The BSD crowd should not feel left out, moreover. There are four long-standing problems with the Linux libkqueue library. One of those problems causes svscan a.k.a. service-dt-scanner to be spuriously woken up. This doesn't affect Debian but does affect Linux operating systems such as Gentoo that have more recent versions of that library. This has been worked around in version 1.18. The pre-built mount@-, fsck@-, mount@-usr, fsck@-usr, mount@-var, and fsck@-var service bundles have been removed. Generation of the service bundles for mounting and checking volumes is now entirely based upon the auto-creation system in /etc/system-control/convert/ . If you are installing from scratch by hand, then you must remember to "redo all" in that directory. The nosh-bundles package does this for you as part of its post-install procedures. The problem with the local-syslog-read service on Linux providing the wrong socket (the BSD one) has been fixed. The tools now speak true TAI, rather than UTC-10. There's an explanation of the consequences of this in the manual pages for cyclog, tai64n, and tai64nlocal. The /etc/fstab conversion system now recognizes remote filesystem types and attaches the generated services to remote-fs.target . From owner-freebsd-hackers@freebsd.org Thu Aug 20 13:34:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8F0B9BE950 for ; Thu, 20 Aug 2015 13:34:04 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9705FAF1 for ; Thu, 20 Aug 2015 13:34:04 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (verizon.pix.net [71.178.232.3]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id t7KDY2hF013206; Thu, 20 Aug 2015 09:34:02 -0400 (EDT) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host verizon.pix.net [71.178.232.3] claimed to be torb.pix.net To: freebsd-hackers From: Kurt Lidl Subject: casperd default listen qlen Message-ID: <55D5D74A.9000809@pix.net> Date: Thu, 20 Aug 2015 09:34:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:34:04 -0000 Greetings all. A couple of months ago, we ran across a problem where the default socket listen queue length in casperd was causing issues with an application. I increased the qlen to 16, which addressed the immediate problem, and implemented a command line switch that allows the user to set the length. The problem report and patch are here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202147 Could someone please review the patch? I would like to see this get committed so everyone can benefit from the change. Thanks. -Kurt From owner-freebsd-hackers@freebsd.org Thu Aug 20 15:10:33 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9ACC9BFAF6 for ; Thu, 20 Aug 2015 15:10:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 933EC34C; Thu, 20 Aug 2015 15:10:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by igui7 with SMTP id i7so32792876igu.0; Thu, 20 Aug 2015 08:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B4oJLMWqjgC6UeG3nu7YkBdh60I5vKfg6lwfLY92yn0=; b=iPGwknIOYeBj6Vg5by/C9Z2SoOqw/aA+82BUNBI6E5/Jd1d7pCB5/0KNd6rTmJLc/X Q/j9bFqbXN+x7iIF1vLqm6c4T5VhM1OWqmRCYnWE2oLx8mBVgqLVFin8ghO4rLs/j43l MxVvOOU5UQEuedKgElMAi8BcCXzvpL0VjCHgwkS36vzN8aBWCiHZe3z3aYAH3jcY5f2D 7VkoR4IKAOXEi+UXuLU/EAD3dkegAPetFl+6IXDwaUzrfu9fWnCIjPILANHeIhLrfJ0s Big3nwbh8IzXs6FXdmgUAfzR6kgrax0VKCFV1ZlSTfcY2g7Q9uw4hyp/Qgvygf+hXYOz g0CQ== MIME-Version: 1.0 X-Received: by 10.50.83.65 with SMTP id o1mr8047159igy.69.1440083432870; Thu, 20 Aug 2015 08:10:32 -0700 (PDT) Received: by 10.107.169.94 with HTTP; Thu, 20 Aug 2015 08:10:32 -0700 (PDT) In-Reply-To: <1438819170.70393.227.camel@freebsd.org> References: <1438819170.70393.227.camel@freebsd.org> Date: Thu, 20 Aug 2015 11:10:32 -0400 Message-ID: Subject: Re: vm_lowmem is prevented every 2**31 ticks From: Ryan Stone To: Ian Lepore Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 15:10:33 -0000 On Wed, Aug 5, 2015 at 7:59 PM, Ian Lepore wrote: > If you're measuring elapsed time, please use getbinuptime() rather than > the time of day clock (which can be stepped arbitrarily). > > Hey wait a sec... if it's currently some_ticks/hz it's counting seconds, > right? So no need to mess with bintimes, if whole seconds are good > enough just use the global time_uptime. > i thought that there was such a variable, but a quick search didn't turn it up. Thanks. (And thanks for also catching my potential mistake in not using uptime -- that would have been embarrassing) I've put the potential fix up for review here: https://reviews.freebsd.org/D3439 From owner-freebsd-hackers@freebsd.org Sat Aug 22 18:04:51 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A47859BF823 for ; Sat, 22 Aug 2015 18:04:51 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-3.server.virginmedia.net (know-smtprelay-omc-3.server.virginmedia.net [80.0.253.67]) by mx1.freebsd.org (Postfix) with ESMTP id EFD0C191B for ; Sat, 22 Aug 2015 18:04:50 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-3-imp with bizsmtp id 7u4g1r00B0HtmFq01u4hsV; Sat, 22 Aug 2015 19:04:41 +0100 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=TYVrzkkh c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=NLZqzBF-AAAA:8 a=n40ctHC_h8IA:10 a=N659UExz7-8A:10 a=7mOBRU54AAAA:8 a=yashrJDmAAAA:8 a=6JoKIJvD939b3KE__7UA:9 a=pILNOxqGKmIA:10 a=XdyKOaxJwVsA:10 a=4dEWTFd_fAAA:10 Subject: nosh version 1.19 To: debian-user@lists.debian.org, "supervision@list.skarnet.org" , FreeBSD Hackers References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> <556BA130.50708@NTLWorld.com> <55902328.8080602@NTLWorld.com> <55D5CFA2.5010402@NTLWorld.com> From: Jonathan de Boyne Pollard Message-ID: <55D8B9AC.6010209@NTLWorld.com> Date: Sat, 22 Aug 2015 19:04:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D5CFA2.5010402@NTLWorld.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2015 18:04:51 -0000 nosh is now up to version 1.19 * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html The important news is that the embarrassment with the post-install setup script for the Linux nosh-run-kernel-vt package is fixed. It was a missing 1-line escape() shell function. I apologize. Other terminal management news is that there's now a console-clear command that does pretty much the same thing as the Bourne Again shell's clear_console command (also coming with that name as a symbolic link alias) but better. * The bash clear_console tries to open a lot of device files, as can be seen in Ubuntu bug #39068. This tool by comparison doesn't need anything more than its standard output, and doesn't attempt to open any terminal devices itself at all. * The bash tool is specific to the Linux kernel terminal emulator. It had to be turned off for Debian kFreeBSD in Debian bug #355336, patched to make it stop when run as the superuser in xterm in Debian bug #355815, and worked around again in Debian bug #793883. This tool, contrastingly, actually works with xterm and PuTTY and clears their own scrollback buffers. It uses a different mechanism that both they and (ironically) the Linux kernel terminal emulator since 2011, all support. * Debian bug #791342 would be fixed by it, because it doesn't use the bodge of attempting to switch virtual terminals away and back (using either tty1 or tty2 as the "other" terminal) to clear the scrollback buffer. On the gripping hand, this is something that one doesn't actually need if one is using the nosh-run-user-vt package. console-terminal-emulator supports the same extension to ECMA-48 Erase Display as xterm and PuTTY do, but the raison d'être for clear_console is the likes of Debian bug #331504. clear_console is in fact a ten-year-old bodge, addressing a security/privacy concern that's a lot older still. With user-space virtual terminals, one has the freedom to do things right, without the need for such bodges. (-: As the console-terminal-emulator manual page explains, when a login session terminates and the terminal is hung up, the terminal emulator erases the whole display buffer. In more other news: On Linux, fsck at bootstrap time is now monitored. What this means from a user standpoint is that if your system reaches its "maximum mounts before a forced full fsck" point, it doesn't just sit there with nothing visibly happening (if one cannot see the hard disc activity light) for ages. The fsck@* services now invoke "monitored-fsck" rather than fsck directly. This is an ordinary chain-loading tool that opens a client connection to a local (i.e. AF_LOCAL) socket and then chains to fsck adding in its (Linux-specific) -Cfd option. There's a new monitor-fsck-progress service that runs the server for that socket, and displays progress information on the console. This latter is intentionally replaceable by alternative services, of course. I'm intending to make its output somewhat prettier, rather than just dumping the raw information at you as it does in this release. But if you want to write your own ... You'll have to delete /etc/system-control/convert/volumes (or modify the contents of /etc/fstab) and run "redo all" to get your existing auto-created fsck@* service bundles regenerated with the new command. Or just edit the run files replacing fsck with monitored-fsck . The big news is that as promised in the 1.18 announcement the nosh-run-busybox-mdev package is now functional. Also as promised in that announcement, here's more on the subject. The nosh toolset doesn't come with a bunch of rules for your plug-and-play manager, be that (BSD) devd, (Linux) udev, or busybox mdev. Your plug-and-play manager does, or should do. As packaged up for Debian Linux, udev comes with a whole bunch of pre-supplied rules in /lib/udev/rules/ that gets one the "usual" device file tree in /dev/ . And it almost goes without saying that the BSDs come with devd rules in the box. The same is not true for the busybox Debian package. There's no /etc/mdev.conf supplied. You MUST write one before using busybox mdev. busybox mdev's default behaviour as packaged, in the absence of /etc/mdev.conf , may be logical and straightforward; but it does not result in a working Debian system. Some things that I've hit myself are /dev/null not being accessible to anyone except the superuser, which affects loads of things all over the shop, and event device files not being under /dev/input/ where other parts of the system expect them to be. There's plenty to read on this subject in the non-Debian world, starting with but not limited to: * https://wiki.gentoo.org/wiki/Mdev * http://linuxfromscratch.org/clfs/view/clfs-3.0/mips/bootscripts/mdev.html You'll have to adapt these for Debian. There are also the examples in /usr/share/doc/busybox/examples/ , of course, the larger of the two fixing both of the aforementioned problems. The positive news is that the busybox-mdev service implicitly serializes invocations of mdev, so that there's no need for mucking around with mdev's sequence number mechanism. The recovery mode problem mentioned in the 1.18 announcement turns out to have a simple local fix, which I'll incorporate into a more comprehensive service fix: # ln -s rescue /etc/service-bundles/targets/single