From owner-freebsd-hackers@freebsd.org Sun Dec 16 00:17:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DACB1333B96 for ; Sun, 16 Dec 2018 00:17:56 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from cloud-vps.localdomain (unknown [IPv6:2001:15e8:110:75a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 842968D728 for ; Sun, 16 Dec 2018 00:17:55 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from localhost (localhost [127.0.0.1]) by cloud-vps.localdomain (Postfix) with ESMTP id D80743FED4 for ; Sun, 16 Dec 2018 01:17:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.autisticstory.net Received: from cloud-vps.localdomain ([127.0.0.1]) by localhost (mail.autisticstory.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OhQJatzVgQJ for ; Sun, 16 Dec 2018 01:17:48 +0100 (CET) Received: from [192.168.1.105] (unknown [83.142.188.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: atypical@autisticstory.net) by cloud-vps.localdomain (Postfix) with ESMTPSA id 7C92D3F9C2 for ; Sun, 16 Dec 2018 01:17:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=autisticstory.net; s=201807; t=1544919467; bh=hYTMBbTDcjbFvBzh1XclZfphTwbL+gfnnLIMq7HUPpg=; h=To:From:Subject:Date:From; b=ra8K1Gh9wVTkk3EuEQw6qz73J13abZ/tx39mo+mRif8Y2qi+2eTWax32sk/+Fwc5Z 6yCcLcfWisRjWTddMwjT+zMiT3pKvAQORY9QZ7ytGv/5gGAI91LP9lyJFoJneIlGK/ +ukEK5M9AEM2FAWD45ePJzufiYqTMzTXNr5K0i8mnvgZY7hNB4Ys+EGbTpjW7LB7Aw 8nk73452GLNRNuQVkEbPwqKabMrjrJnjsaLIX4aZYgQVW8GtFOg7D1Mby+T9B9N93L RXlUoCuZ6IBlBccYv23Yl7kog9/W9mkB8aPwMTNJdLDentmPOgZDsxdRPB0xcrhdVU MarEWLwlPPG6RPIElGQgPq3rvFAyovT5Q3Y3ar+Df9dgOgG/h9sGk5pFiRKR04pasX +w/HX14hrsGXpbmDtumrzbyg5Cgd71yTmrpg0HH+XF4E/NlDer9zKiIkztiYD6gH27 k5rd2bz5oIlll/f7I1Wc7aVumQG7IV9AnRVNhzxNhjuIuiGQco59RUftctDxISqrGv GluP6tx+IkwxGDQdA4EzPRzwOTetsaHOsvJvmCJU0C4ROPFYbtQX8XTapcASrVEWHD mrP0US9AjlmukMwfnbVWd2uz0kRw0vZDX59G5crkYhUzbE3S9g5HNo7rmchtlsc0BW Cw7bQmMndY4iXe6zmsOgJ7rc= To: freebsd-hackers@freebsd.org From: Hubert Hauser Subject: Routing all traffic through Tor Openpgp: preference=signencrypt Autocrypt: addr=atypical@autisticstory.net; keydata= mQINBFvfH1cBEADMaaPj9N4y/pGIYrpYgkmabzCa+3AP/GZH3++d7DLGcVH7cePoCKKANa/F 9LXXACQDMmkdXBPXndUAN1sZmzYiQF+E15G9U9BEx1wBJxMmevGbJ28XGIu8ZTwOcNzIlO5G yhQVbKlfckuIEMFnPhqm863a91UyyQL19/JWnDBfq/DOTmPSc/tWPfWgpJdCsI6zRWreLXCb fwVg4L3prqkJbjVIuPsKS5YBF1eII6ABqcFvlGdZFQaN6Cy/4+pswVQUAaySWG/1tYq9XMbV 6zuBl15l8txRYu0aNdnV6A6900HmeKAWCthw1JMemOggMokxU5OR8dHez0CMPDvSJaXLJr0t wZeOlcK2Z8vSE1IRyvdSbtBKWM6YzfX+hOQzxRGy3qi4Z8Pk1yx9pjtrueM1Fhz3Ag7TQNuv tLMlfYx1PgZyWVNo8K7J/D2jS/Sk6uMkgMfq5D3Ef1sJb8lh2kIxU5mRrlQQof+g/HW9iIP2 qXuylJvwNGpqGX52Hrz17B6tZaRtBnRHV2ZX4dv3LI+msGzjePrYdKPUmjdkPf8ztUps0qMY F93zXL5PEyuv9UmNeJlr+5UCcWWB9w71vSbTCqIIxTzhlQ+09118b//XTYYnolAcFb3KE5iM eMYG67OkmvAjaKFh75TKlGcQNmvX45l4kzl9guyYsysH7knJQQARAQABtCpIdWJlcnQgSGF1 c2VyIDxhdHlwaWNhbEBhdXRpc3RpY3N0b3J5Lm5ldD6JAlQEEwEIAD4WIQRJqW9Zo0ULA/tV 5BgsJbHYs2XiPQUCW98fVwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAs JbHYs2XiPcuXEACsPUZvMEJ7wUfnRr0EEVF3jWCuTSW2cD/HJG2mgwmu0SHDQJTwn5TNUYfv Yt2fBnL6TxnJxz2gjnF7DLuk7Gpo5ABmIjuh41f4NaVIbiBdVhMjueQISSEaaMJTbg4lQpr5 kPR+SWN6om3gff7V2SJ9ZozsVl/wc1wl75ndwk87gxvZJsQxhwIB6JOWCrtnD6SbldDcrKy9 wYGTEKnZpHMQaE5BB/1BADrHICPe4V2GYVTNpV/o7cneVAPSUT/AlUJHvVq6PWEOg7ld/rWq CaW9YbR+/wSikiwY5X7F+yg33G3Ys0mHVuDnWIKhGr24C/n6g3PjWTAdpg3MTBDitYFxjucZ S1luTooCkgYIF04/weV2ghrVOvAYCbtr+oN5mvfR2BwIW6v6SChyHOUMAEYyA2SHOjlNEv7+ Ws9zEHYlYXeTYIc/KMxsSEaVSuXQfsVn5uxMHlbeJ5ypMBDdke9zh6XJ39npgkR2eFHQJIqd 4BTqQbuSJPZllhXYwaeHfMy4ZZf41JFdXLNBXeQqXvnjjugGG0IrsC72OORp9iE+/4zbO/yg BvMD0jWVO94DL/3amH4nMM0RUBXIlo0mBDeuDvB0PIAyw2/fqSuMAmykLI40JoaKIfgeMcyU bv4Ra06Lz8oLXC63T6ZKT655lLU/P1cbgJXiwGjPvjupir9nErkCDQRb3x9XARAAsz4qZEDX HpJ7s9AJS0YWjMkG2STodEV6XNaNum5BnXUF583vJUeAH9bEGqh0CY+MDXBhs4diLGVbacpe Vzac6UBQYKdwfYeZMuX5TFvPsVBv3XGvrNfhNWFnPlTUA7r9fah4QFNcDX0nRt/y1wtGknb1 JQW3vVRb/Z0q4oemPRw1cZ7yCsgBD1yD6ib13U8VYt6v+jxavS6EKh6hXjb/gUC/KOvsm2t7 UIBV5C0b8O98Dvy5csi5qQx3x0h7IAOvchpJ8i31Ke0s7xaJf2ghW2YqfNZOujtebqbc9/uf wuNOCQkL/yRirWpe7WXGAGUbM2rsqucWWpEKaHEEc5icYEeShJOyESOvRR1aEWeNBbntXMXK KMeUzLwYlqPptTxOWApIPbKJ37fHEG8QJi2H1jyn+NKLzB75GsyydUkmj/dLAuD00OF9Nn5B iJQPNFV58Q7VL99pTBhzXDj/2ZHxnYt0dVnyxE+FEOdklIcwX1PizUwHz01nUyFn+7bjgiFS LE2/5P8p7KDnpZAJgIy06sD2g8CsM4WUzRx4VHvHFkJhEWBA/E7AE+JVdEcyzjrhbM4xPR6i GbbxdvzLkUY5puM9srCnDmEN92k8joV3gFRffd2z7wIC+fYtZAhKqJiPHBaLZRQGDwmqO85x zbZBz8BPcP10JE7I4zjXvQmywgsAEQEAAYkCPAQYAQgAJhYhBEmpb1mjRQsD+1XkGCwlsdiz ZeI9BQJb3x9XAhsMBQkJZgGAAAoJECwlsdizZeI9B3kP/iBhveI7ov5IXgSMUmeMyc0MXrUB S8F4KE6kS4o82MGXPFpJunWM8WFtJwmOt6AmtE49RzuI0tH6RPfumiCFs8oaQxfQIfOw9q1I xKgF2nGRBf40OU69K7p9tKEFhqiJRyoqyTNmdunRbMTKUPobyxbH7RArobq+YaDiu4DKZ43Z W/0yR/Z0OBavE3aXeN2ePX6JM0sF2MWBIyha4lT7va1njcgLjUHzMi0l8XLAYH/YfuDHbi3S g5rDXGuvA/DfjHV3Yup1tdx+u3X65sKmSvQ1E8Ol8QCbxyfcHWResAdBdIrBBtQ6PjTw+bS4 29UCVyUJBP8oDWv3G4F9or+rUZjVxSyVdRIsFMe7+64gcPc8GFiT2ML2WhlK15b/F6qrT/bz eT/LATJUyBhYy5FEgaN1sR0YH6PPj1yOOiFS3shY1frasSZrtQS0uOv1tbR0kC40LRwIjodT CiqqoeocxvmCcSUmdS7sO5dwk5UxqHb0pggicR4FtAi9MsAFgqQLli32uAk3sKcoweuzurGe CRZQ3j54zXYQTXMc5l4ciZrwlt9l58VJvWqJzvBxa9XY7I8Y65FfA0dr+QaGtc85Ahq4LVF4 asP53ZlxwK4U7IQC0eg+LctuAxyoViMmGUu2G4arr4N8lGkiXyzzcP9QkWD0uCaH/Ig2JsC7 sCu5NBfl Message-ID: <950de376-fb1e-dbaf-208b-993ad8632df8@autisticstory.net> Date: Sun, 16 Dec 2018 01:16:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 00:17:56 -0000 How's a better way to route all outgoing traffic on my old PC which is purposed to darknet activities through Tor - use a transparent proxy or manually proxy every application and drop non-tor traffic in pf or use a transparent proxy? Can transparent proxy work together with manually proxying every application? From owner-freebsd-hackers@freebsd.org Sun Dec 16 00:24:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B0C21333F4B for ; Sun, 16 Dec 2018 00:24:58 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from cloud-vps.localdomain (unknown [IPv6:2001:15e8:110:75a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94AE88DB98 for ; Sun, 16 Dec 2018 00:24:57 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from localhost (localhost [127.0.0.1]) by cloud-vps.localdomain (Postfix) with ESMTP id 94E8B3FED4 for ; Sun, 16 Dec 2018 01:24:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.autisticstory.net Received: from cloud-vps.localdomain ([127.0.0.1]) by localhost (mail.autisticstory.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGfkiSA_zgfk for ; Sun, 16 Dec 2018 01:24:45 +0100 (CET) Received: from [192.168.1.105] (unknown [83.142.188.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: atypical@autisticstory.net) by cloud-vps.localdomain (Postfix) with ESMTPSA id 85DEC3F9C2 for ; Sun, 16 Dec 2018 01:24:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=autisticstory.net; s=201807; t=1544919885; bh=/7x6gvcmnzOdspC+SEGc43sb6Pp9e+qNcZSIhLPbDwA=; h=To:From:Subject:Date:From; b=RdPZsylurkRf8puEfBW9i79NMiJ9l404RGSHmJ0Oi0mS01fN0VcUkWOS/7p9F1RT5 pHuit8XaRS0JXbOKrZpYS9aVDeQTgicEHVwPxPVbhn/lOWMbMj+1sKyEwMgVBjG6QY f/Jw7/Mrqu8YLiPUMk5gauppgazyQraLOoBPz8T/2FoFt4x9swjPrnYPDhvF8ub+gt xtgUcHq9EkDQkacEw4Q+/5clDoj35j8NlP8Y1CjcV7M61IgY3iM9PSDxHVZZ+f1dyE 3eEC+PMJ0xNEqqL4V/X2Mdm7QKKqbA3nD72nWwEaZwFxlq1QyJrdJOsssyka1n+tnu bzY2qY2NIp/9mZdA1sUaMmk6d1xfEFgv9jLny7OHPzkBr9u8sMU12tarzN+Vz1UmQ5 /AWRgQW87FfCWPUuXDJbayKugmHz25N0CyMa/9SadSGYghzftxnrqXIPn+A4gNSczc X7qpBCKImE5EgzBqZ/uDbTFaYLplgH3U6YySjmZxY6JC7P3WcycMy0YzZTYAJtC0Wm EMtr3pbLDg55D99/gwAunUbf8Sz9aknCux3Pycea3Gfk7zO0ZvIKprzALD7+QEmslr jTsP0eVKX5S7259u7byCXZbeFfwudgHtBNUcHLBa73KqZCohf89/+rWzg1fWshHTdc WUnvkv/j9WP9LurmNoRfViMg= To: freebsd-hackers@freebsd.org From: Hubert Hauser Subject: Unable to open /dev/pf device inside the jail Openpgp: preference=signencrypt Autocrypt: addr=atypical@autisticstory.net; keydata= mQINBFvfH1cBEADMaaPj9N4y/pGIYrpYgkmabzCa+3AP/GZH3++d7DLGcVH7cePoCKKANa/F 9LXXACQDMmkdXBPXndUAN1sZmzYiQF+E15G9U9BEx1wBJxMmevGbJ28XGIu8ZTwOcNzIlO5G yhQVbKlfckuIEMFnPhqm863a91UyyQL19/JWnDBfq/DOTmPSc/tWPfWgpJdCsI6zRWreLXCb fwVg4L3prqkJbjVIuPsKS5YBF1eII6ABqcFvlGdZFQaN6Cy/4+pswVQUAaySWG/1tYq9XMbV 6zuBl15l8txRYu0aNdnV6A6900HmeKAWCthw1JMemOggMokxU5OR8dHez0CMPDvSJaXLJr0t wZeOlcK2Z8vSE1IRyvdSbtBKWM6YzfX+hOQzxRGy3qi4Z8Pk1yx9pjtrueM1Fhz3Ag7TQNuv tLMlfYx1PgZyWVNo8K7J/D2jS/Sk6uMkgMfq5D3Ef1sJb8lh2kIxU5mRrlQQof+g/HW9iIP2 qXuylJvwNGpqGX52Hrz17B6tZaRtBnRHV2ZX4dv3LI+msGzjePrYdKPUmjdkPf8ztUps0qMY F93zXL5PEyuv9UmNeJlr+5UCcWWB9w71vSbTCqIIxTzhlQ+09118b//XTYYnolAcFb3KE5iM eMYG67OkmvAjaKFh75TKlGcQNmvX45l4kzl9guyYsysH7knJQQARAQABtCpIdWJlcnQgSGF1 c2VyIDxhdHlwaWNhbEBhdXRpc3RpY3N0b3J5Lm5ldD6JAlQEEwEIAD4WIQRJqW9Zo0ULA/tV 5BgsJbHYs2XiPQUCW98fVwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAs JbHYs2XiPcuXEACsPUZvMEJ7wUfnRr0EEVF3jWCuTSW2cD/HJG2mgwmu0SHDQJTwn5TNUYfv Yt2fBnL6TxnJxz2gjnF7DLuk7Gpo5ABmIjuh41f4NaVIbiBdVhMjueQISSEaaMJTbg4lQpr5 kPR+SWN6om3gff7V2SJ9ZozsVl/wc1wl75ndwk87gxvZJsQxhwIB6JOWCrtnD6SbldDcrKy9 wYGTEKnZpHMQaE5BB/1BADrHICPe4V2GYVTNpV/o7cneVAPSUT/AlUJHvVq6PWEOg7ld/rWq CaW9YbR+/wSikiwY5X7F+yg33G3Ys0mHVuDnWIKhGr24C/n6g3PjWTAdpg3MTBDitYFxjucZ S1luTooCkgYIF04/weV2ghrVOvAYCbtr+oN5mvfR2BwIW6v6SChyHOUMAEYyA2SHOjlNEv7+ Ws9zEHYlYXeTYIc/KMxsSEaVSuXQfsVn5uxMHlbeJ5ypMBDdke9zh6XJ39npgkR2eFHQJIqd 4BTqQbuSJPZllhXYwaeHfMy4ZZf41JFdXLNBXeQqXvnjjugGG0IrsC72OORp9iE+/4zbO/yg BvMD0jWVO94DL/3amH4nMM0RUBXIlo0mBDeuDvB0PIAyw2/fqSuMAmykLI40JoaKIfgeMcyU bv4Ra06Lz8oLXC63T6ZKT655lLU/P1cbgJXiwGjPvjupir9nErkCDQRb3x9XARAAsz4qZEDX HpJ7s9AJS0YWjMkG2STodEV6XNaNum5BnXUF583vJUeAH9bEGqh0CY+MDXBhs4diLGVbacpe Vzac6UBQYKdwfYeZMuX5TFvPsVBv3XGvrNfhNWFnPlTUA7r9fah4QFNcDX0nRt/y1wtGknb1 JQW3vVRb/Z0q4oemPRw1cZ7yCsgBD1yD6ib13U8VYt6v+jxavS6EKh6hXjb/gUC/KOvsm2t7 UIBV5C0b8O98Dvy5csi5qQx3x0h7IAOvchpJ8i31Ke0s7xaJf2ghW2YqfNZOujtebqbc9/uf wuNOCQkL/yRirWpe7WXGAGUbM2rsqucWWpEKaHEEc5icYEeShJOyESOvRR1aEWeNBbntXMXK KMeUzLwYlqPptTxOWApIPbKJ37fHEG8QJi2H1jyn+NKLzB75GsyydUkmj/dLAuD00OF9Nn5B iJQPNFV58Q7VL99pTBhzXDj/2ZHxnYt0dVnyxE+FEOdklIcwX1PizUwHz01nUyFn+7bjgiFS LE2/5P8p7KDnpZAJgIy06sD2g8CsM4WUzRx4VHvHFkJhEWBA/E7AE+JVdEcyzjrhbM4xPR6i GbbxdvzLkUY5puM9srCnDmEN92k8joV3gFRffd2z7wIC+fYtZAhKqJiPHBaLZRQGDwmqO85x zbZBz8BPcP10JE7I4zjXvQmywgsAEQEAAYkCPAQYAQgAJhYhBEmpb1mjRQsD+1XkGCwlsdiz ZeI9BQJb3x9XAhsMBQkJZgGAAAoJECwlsdizZeI9B3kP/iBhveI7ov5IXgSMUmeMyc0MXrUB S8F4KE6kS4o82MGXPFpJunWM8WFtJwmOt6AmtE49RzuI0tH6RPfumiCFs8oaQxfQIfOw9q1I xKgF2nGRBf40OU69K7p9tKEFhqiJRyoqyTNmdunRbMTKUPobyxbH7RArobq+YaDiu4DKZ43Z W/0yR/Z0OBavE3aXeN2ePX6JM0sF2MWBIyha4lT7va1njcgLjUHzMi0l8XLAYH/YfuDHbi3S g5rDXGuvA/DfjHV3Yup1tdx+u3X65sKmSvQ1E8Ol8QCbxyfcHWResAdBdIrBBtQ6PjTw+bS4 29UCVyUJBP8oDWv3G4F9or+rUZjVxSyVdRIsFMe7+64gcPc8GFiT2ML2WhlK15b/F6qrT/bz eT/LATJUyBhYy5FEgaN1sR0YH6PPj1yOOiFS3shY1frasSZrtQS0uOv1tbR0kC40LRwIjodT CiqqoeocxvmCcSUmdS7sO5dwk5UxqHb0pggicR4FtAi9MsAFgqQLli32uAk3sKcoweuzurGe CRZQ3j54zXYQTXMc5l4ciZrwlt9l58VJvWqJzvBxa9XY7I8Y65FfA0dr+QaGtc85Ahq4LVF4 asP53ZlxwK4U7IQC0eg+LctuAxyoViMmGUu2G4arr4N8lGkiXyzzcP9QkWD0uCaH/Ig2JsC7 sCu5NBfl Message-ID: <17e9f383-95bd-37c2-6bfe-0dc17424624f@autisticstory.net> Date: Sun, 16 Dec 2018 01:23:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 00:24:58 -0000 I'm trying to set TransPort setting in the torproxy jail but when I try to start Tor inside the jail I'm giving errors: |root@torproxy:~ # service tor restart Stopping tor. Waiting for PIDS: 95355. Starting tor. Dec 16 00:23:07.760 [notice] Tor 0.3.4.9 (git-4ac3ccf2863b86e7) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2o-freebsd, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.5. Dec 16 00:23:07.760 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 16 00:23:07.760 [notice] Read configuration file "/usr/local/etc/tor/torrc". Dec 16 00:23:07.774 [notice] Scheduler type KISTLite has been enabled. Dec 16 00:23:07.774 [notice] Opening Socks listener on 127.0.1.1:9050 Dec 16 00:23:07.774 [notice] Opening DNS listener on 127.0.1.1:9053 Dec 16 00:23:07.774 [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040 Dec 16 00:23:07.774 [warn] open("/dev/pf") failed: No such file or directory Dec 16 00:23:07.774 [notice] Closing partially-constructed Socks listener on 127.0.1.1:9050 Dec 16 00:23:07.774 [notice] Closing partially-constructed DNS listener on 127.0.1.1:9053 Dec 16 00:23:07.774 [notice] Closing partially-constructed Transparent pf/netfilter listener on 127.0.0.1:9040 Dec 16 00:23:07.775 [warn] Failed to parse/validate config: Unable to open /dev/pf for transparent proxy. Dec 16 00:23:07.775 [err] Reading config failed--see warnings above. /usr/local/etc/rc.d/tor: WARNING: failed to start tor| I've created this jail using ezjail-admin tool. Could anyone tell me why I'm unable to change host pf settings and how can I do it inside the jail? From owner-freebsd-hackers@freebsd.org Sun Dec 16 02:19:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44D9513386BB for ; Sun, 16 Dec 2018 02:19:08 +0000 (UTC) (envelope-from waitman@waitman.net) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "QuoVadis Global SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C67AE6B7C6 for ; Sun, 16 Dec 2018 02:19:07 +0000 (UTC) (envelope-from waitman@waitman.net) Date: Sun, 16 Dec 2018 02:18:57 +0000 To: freebsd-hackers@freebsd.org From: Waitman Gobble Reply-To: Waitman Gobble Subject: Re: Routing all traffic through Tor Message-ID: In-Reply-To: <950de376-fb1e-dbaf-208b-993ad8632df8@autisticstory.net> References: <950de376-fb1e-dbaf-208b-993ad8632df8@autisticstory.net> Feedback-ID: a9EiCCViSiSHQ6Bx5OnM7zSE3j9mdPjjMltovBgA7v_vv_C4nKI9vbMXvmk_xW33cGmibh2zGAa2Co0Llrno4A==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: C67AE6B7C6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 02:19:08 -0000 LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQpPbiBEZWMgMTUsIDIwMTgsIDQ6MTYg UE0sIEh1YmVydCBIYXVzZXIgd3JvdGU6CgpIb3cncyBhIGJldHRlciB3YXkgdG8gcm91dGUgYWxs IG91dGdvaW5nIHRyYWZmaWMgb24gbXkgb2xkIFBDIHdoaWNoIGlzCnB1cnBvc2VkIHRvIGRhcmtu ZXQgYWN0aXZpdGllcyB0aHJvdWdoIFRvciAtIHVzZSBhIHRyYW5zcGFyZW50IHByb3h5IG9yCm1h bnVhbGx5IHByb3h5IGV2ZXJ5IGFwcGxpY2F0aW9uIGFuZCBkcm9wIG5vbi10b3IgdHJhZmZpYyBp biBwZiBvciB1c2UgYQp0cmFuc3BhcmVudCBwcm94eT8gQ2FuIHRyYW5zcGFyZW50IHByb3h5IHdv cmsgdG9nZXRoZXIgd2l0aCBtYW51YWxseQpwcm94eWluZyBldmVyeSBhcHBsaWNhdGlvbj8KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVic2QtaGFj a2Vyc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtaGFja2VycwpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkg bWFpbCB0byAiZnJlZWJzZC1oYWNrZXJzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgoKU29tZSB5 ZWFycyBhZ28gSSByYW4gc3F1aWQgY2FjaGUgdGhyb3VnaCB0b3Igb24gYSBkYXRhIHNjcmFwaW5n IGV4cGVkaXRpb24uIFNldHRpbmcgaXQgdXAgb24gcGZTZW5zZSBpcyBtYXliZSBhIGdvb2QgaWRl YT8gVmVyaWZ5IHRoYXQgdHJhbnNwYXJlbnQgcHJveHkgaXMgYWN0dWFsbHkgdHJhbnNwYXJlbnQu IEJhY2sgdGhlbiBJIGhhZCB0byBtb2RpZnkgdGhlIHNvdXJjZSB0byBkcm9wIHNvbWUgaGVhZGVy cy4gTWlnaHQgYmUgZGlmZmVyZW50IG5vdy4KCkkga25vdyBub3RoaW5nIG9mIHRoZSBkYXJrLCBo b3dldmVyIElmIHlvdSBhcmUgaGl0dGluZyBlbmRwb2ludHMsIGJlbGlldmUgeW91IGFyZSBhIG5h a2VkIG1hbiBydW5uaW5nIHRocm91Z2ggdGhlIG1pZGRsZSBvZiB0b3duIGluIGJyb2FkIGRheWxp Z2h0LgoKV2FpdG1hbg== From owner-freebsd-hackers@freebsd.org Sun Dec 16 11:15:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 448401322033 for ; Sun, 16 Dec 2018 11:15:55 +0000 (UTC) (envelope-from srs0=8zba=oz=vega.codepro.be=kp@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C246983346 for ; Sun, 16 Dec 2018 11:15:54 +0000 (UTC) (envelope-from srs0=8zba=oz=vega.codepro.be=kp@codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 8BE0012909; Sun, 16 Dec 2018 12:15:46 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 695523D1C2; Sun, 16 Dec 2018 12:15:46 +0100 (CET) Date: Sun, 16 Dec 2018 12:15:46 +0100 From: Kristof Provost To: Hubert Hauser Cc: freebsd-hackers@freebsd.org Subject: Re: Unable to open /dev/pf device inside the jail Message-ID: <20181216111545.GD49515@vega.codepro.be> References: <17e9f383-95bd-37c2-6bfe-0dc17424624f@autisticstory.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <17e9f383-95bd-37c2-6bfe-0dc17424624f@autisticstory.net> X-Checked-By-NSA: Probably User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: C246983346 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.977,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 11:15:55 -0000 On 2018-12-16 01:23:21 (+0100), Hubert Hauser wrote: > I'm trying to set TransPort setting in the torproxy jail but when I try > to start Tor inside the jail I'm giving errors: > > |root@torproxy:~ # service tor restart Stopping tor. Waiting for PIDS: > 95355. Starting tor. Dec 16 00:23:07.760 [notice] Tor 0.3.4.9 > (git-4ac3ccf2863b86e7) running on FreeBSD with Libevent 2.1.8-stable, > OpenSSL 1.0.2o-freebsd, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.5. > Dec 16 00:23:07.760 [notice] Tor can't help you if you use it wrong! > Learn how to be safe at > https://www.torproject.org/download/download#warning Dec 16 00:23:07.760 > [notice] Read configuration file "/usr/local/etc/tor/torrc". Dec 16 > 00:23:07.774 [notice] Scheduler type KISTLite has been enabled. Dec 16 > 00:23:07.774 [notice] Opening Socks listener on 127.0.1.1:9050 Dec 16 > 00:23:07.774 [notice] Opening DNS listener on 127.0.1.1:9053 Dec 16 > 00:23:07.774 [notice] Opening Transparent pf/netfilter listener on > 127.0.0.1:9040 Dec 16 00:23:07.774 [warn] open("/dev/pf") failed: No > such file or directory Dec 16 00:23:07.774 [notice] Closing > partially-constructed Socks listener on 127.0.1.1:9050 Dec 16 > 00:23:07.774 [notice] Closing partially-constructed DNS listener on > 127.0.1.1:9053 Dec 16 00:23:07.774 [notice] Closing > partially-constructed Transparent pf/netfilter listener on > 127.0.0.1:9040 Dec 16 00:23:07.775 [warn] Failed to parse/validate > config: Unable to open /dev/pf for transparent proxy. Dec 16 > 00:23:07.775 [err] Reading config failed--see warnings above. > /usr/local/etc/rc.d/tor: WARNING: failed to start tor| > > I've created this jail using ezjail-admin tool. Could anyone tell me why > I'm unable to change host pf settings and how can I do it inside the jail? > Assuming that you've got a vnet jail that is possible, but you'll need to tweak your devfs configuration to give the jail the pf device node. I edited /etc/defaults/devfs.rules to add 'add path pf unhide' to the '[devfsrules_jail=4]' section. It's probably cleaner to do that in /etc/devfs.rules though. Regards, Kristof From owner-freebsd-hackers@freebsd.org Mon Dec 17 11:24:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A45D133B369; Mon, 17 Dec 2018 11:24:47 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E7F58FFD3; Mon, 17 Dec 2018 11:24:44 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id n190so12000299wmd.0; Mon, 17 Dec 2018 03:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3FCx/ilHbCbH1PQeEV/LpvDplBkw2pi8TS/G2qT+n8=; b=luoc9Ie6ouvWM2LnX6AsQmojsvBzpoowC7wSoFIgsXx7tN61tkPQsCGbiCfjdVquCb 5clW1guLol7+oqPdQjjKXJUUBoQlcnP0VVepxUBiKCsZ3lULqMoeMcKArb0Qyi4x/bV6 Kj0kABSvEM6wOcWnr8IrXC8YFyjOnOq+ybIe03/eDfA+kZunk65Kpd+UH/LI7N3k7krd BRrVeSa4aACKCBaIuy7l2XmLHkxVgRS9Hxz2SjMO4C+RQpE2vVwdG5xZl1UMROxWkoML tuojdb4lISMS/BU69YAv4LTGpbQsJuzOHIm5WHimv0aR1OgFceVrO6wxEBz2ztkRiwrt EefA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3FCx/ilHbCbH1PQeEV/LpvDplBkw2pi8TS/G2qT+n8=; b=nOF0Yfzv3qF5KrFGD0U2HKjFidJc/VIGu+txc7p+oSD8LM/faYU5mVJ7hIdzUI5jW4 Be4oQsvUpid/NDNRd+m4Ru/oZRmv4AP8A+ku5Waegdq/NuDQkpaj/Cily9v3XierAWyn +KkHFrLd7zJX8wHed2PUcj8uw2XAf44+C2x8lnpE/8FhSnkI77qNMQhW2nVcB5HzQTAN TCZbJStpWALgyEdl4XxmBaqHtZknu0nhYD5WXS09DmTVaQPqT69dfc0DIu3cCyNVDi86 49uVn5LKaRoOJHJTZcKx+ruhmG3go5BiyF4Wq/Wxgoz1tDZi8GzGyOZ6LliFAiANnsEt 3E4w== X-Gm-Message-State: AA+aEWZu3YIaMUALycghSKvuy4VeGV/gMwWS40x34zLi3L+dIU6NkSYF BLJxj4AurJ9KknkCxnAF0tj9sJU4RY+CF3NGkXKBuQ== X-Google-Smtp-Source: AFSGD/UnHmeJxIxkobBaC8usa0EzLrOVxsbdysvZeG/1ed7oDu+f/Ck32xdBBcmZA6om5OcexrlRfVHzuh4HamQ5/kI= X-Received: by 2002:a1c:8d12:: with SMTP id p18mr12264927wmd.31.1545045882795; Mon, 17 Dec 2018 03:24:42 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> In-Reply-To: From: Rajesh Kumar Date: Mon, 17 Dec 2018 16:54:30 +0530 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: cem@freebsd.org Cc: asomers@freebsd.org, freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org X-Rspamd-Queue-Id: 6E7F58FFD3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=luoc9Ie6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-5.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[0.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.53)[ip: (-9.65), ipnet: 2a00:1450::/32(-1.55), asn: 15169(-1.35), country: US(-0.08)]; NEURAL_HAM_SHORT(-0.88)[-0.876,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 11:24:47 -0000 Hi, Thanks everyone for your inputs. I assume, "PCI busmaster"ing refers to a peripheral device being made as the owner of the bus by the DMA engine and do data transfer. Please correct me if I am wrong. But, will this bus_dma API uses the DMA engine in hardware (does it support PCI busmastering)? As I understand, DMA engine will expose DMA channels, which can be used by the client drivers to queue their DMA requests (without CPU intervention) and completions are given through the callback functions. If this is considered the real DMA operation, I don't see options to request DMA channels using bus_dma API's, and the callbacks in bus_dma API is meant to receive just the DMA map details (doesn't indicate a DMA completion). ioat(4) driver seems to be doing what I described above, but that seems to be Intel specific. Can it be used with any DMA controllers? So, I am wondering what needs to be done in FreeBSD to do the actual DMA involving DMA engine in a more generic way? Thanks, Rajesh. On Sat, Dec 15, 2018 at 6:30 AM Conrad Meyer wrote: > On Fri, Dec 14, 2018 at 8:17 AM Alan Somers wrote: > > > For some Intel based server hardware, there is the "ioat" driver, which > > > allows for user code to schedule DMA operations. See ioat(4) for > > > details, including a pointer to the test program. > > This isn't true (or at least, only for testing). It's only usable by > the kernel at the moment. > > > * In what context are callbacks called? Are they called from a signal > > handler, or in a separate thread, or something else? > > Directly from the ithread, mostly. Callers can't take sleep locks or > do very much besides set a flag and wakeup, or kick off a callout or > taskqueue. > > > * Why isn't ioat.h installed? > > Why would it be? It's a kernel interface. > > > * Are "interrupts" synonymous with callbacks? > > I don't understand the question. Interrupts are synonymous with > interrupts. Like, MSI-X. > > > * Do you have a rough idea for about the minimum buffer size that > > makes sense to use with ioat? > > What makes sense will depend on your use case. It's not necessarily > faster than CPU memcpy, but it may be worth some slowdown to offload > latency-insensitive bulk copies. (It may make a lot of sense for > asynchronous page zero, if someone wants to bring that back.) It's > worth benchmarking your specific model. > > We use it for >= 8kB copies on Broadwell, although that's largely an > artifact of our use case (write sizes are exactly 8 bytes, 512 bytes, > or multiples of 8kB). IIRC, it shows up as a gen3 PCIe device with > some small number of lanes on Broadwell, although I may be mistaken; > and it may not communicate with RAM over the PCIe bus anyway, given > the tight integration with the CPU. > > Best, > Conrad > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Dec 17 22:34:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14314134DF07 for ; Mon, 17 Dec 2018 22:34:07 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56CC98D644 for ; Mon, 17 Dec 2018 22:34:06 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: by mail-qk1-x742.google.com with SMTP id r71so8362977qkr.10 for ; Mon, 17 Dec 2018 14:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=aULCV7AmjhrdpVlVl7KyUldt6Vw046LrRzjFY+dXoaw=; b=KjW2dtEP1t9tx9YJcdK37Hj34oR9LmdDH72w9YkMyIr1C+v4HMB2d9W9A2cWrhFsa0 BJQz4NcNa+hUFawiAWIK7yE3e+U3vfML44WvYoywVuONP/BOFAQiwycELqiv3cFeWXaB RuzAAT0uUo94SpIjEEm0ea4NYe9iifbAC4HENC2nxlcV29L82aQmfL2U2QEeAVCIyzGZ ibBQhcch2FeK1D7AIYbzG+LaymMFTBuwjCwsMI9+EGmtAl8Rx6tPQs5jJQOWf3b5NEHz md9FcoDoRme9NOgTPw3bfRVQT94kMezNVcthoun1/Gq2/D4CbDhaFhMyA91QNUF3nE5W IrSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=aULCV7AmjhrdpVlVl7KyUldt6Vw046LrRzjFY+dXoaw=; b=FEUqVnYiVQeW/CXoAo6uxssQyF4GH+gzpEY8liHr8fF9zOxV+kdSD7AxH8uhHU5nXq 7P4uAE51UYAQqLOGxGAjgAEPvnjTR5YPfc1lhdi/WUrU51VXj/Gn/QDFFG4Qq9TmBAx/ qZM+/r1HAoGk7pNu8btD+pFeVFGcHf+wQe+2flrc+/bCF3yEizBtm//1nyoJkaLVvoLx y09SZJLW5pKFUf/sKhslDjMAfn1w1zSxHI6hQtdMrgMeBH5Ph0rUeqjRDjWmIIrZKlu5 p7mbsOUYRWvrijQOTsxrUetxoyU6NTuKRlUj7GxhXFpxfHF4DpCnWBFW7yb1lsq0J1Fo s3ow== X-Gm-Message-State: AA+aEWYdFq1AH+EQotuz84hr1n3VYuCoUWdhuNBE6tw0vbi88owwWskc gTqrF9Z3re9yU4z6Nw9Zf7PGJHvv X-Google-Smtp-Source: AFSGD/VypHuirSPr6cbv0MblfyWPdotB6b0oHiaXyfaMqPDLUapk5Z0yOzhuoo3jd37tt+kqFXFWwg== X-Received: by 2002:a37:5257:: with SMTP id g84mr14048509qkb.76.1545086045629; Mon, 17 Dec 2018 14:34:05 -0800 (PST) Received: from localhost ([178.128.156.9]) by smtp.gmail.com with ESMTPSA id 83sm8338142qkz.73.2018.12.17.14.34.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 14:34:05 -0800 (PST) From: Austin Shafer To: freebsd-hackers@freebsd.org Subject: ENOMEM when calling sysctl_handle_int from custom handler Date: Mon, 17 Dec 2018 17:34:05 -0500 Message-ID: <861s6fpyua.fsf@triplebuff.com> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 56CC98D644 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KjW2dtEP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of amshafer64@gmail.com designates 2607:f8b0:4864:20::742 as permitted sender) smtp.mailfrom=amshafer64@gmail.com X-Spamd-Result: default: False [-2.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.38)[ip: (5.02), ipnet: 2607:f8b0::/32(-1.69), asn: 15169(-1.37), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.53)[-0.533,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.036,0]; RCVD_IN_DNSWL_NONE(0.00)[2.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 22:34:07 -0000 Hi freebsd-hackers, I've had an issue with creating a custom sysctl handler that I can't seem to find an answer for. Using sysctl_handle_int as a handler in SYSCTL_ADD_PROC works fine, but calling sysctl_handle_int from a custom sysctl handler results in an error. (sorry for the long message, I tried to be verbose) Creating the nodes works fine, but SYSCTL_OUT or sysctl_handle_int return ENOMEM despite there being plenty of available memory. I based my approach on other areas of the source where those sysctls work without error. It seems to only happen to custom sysctls that I add. This happens on multiple machines, but the output in this email is from the bhyve VM I test in. Any insight as to where my implementation went wrong would be extremely helpful. Full Source: ("make" should compile on a bsd system) https://github.com/ashaferian/sysctls echo_modevent () { ... /* working sysctl using default handler sysctl_handle_int */ SYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(poid), OID_AUTO, "default", CTLTYPE_INT|CTLFLAG_RW, &ret, -1, sysctl_handle_int, "I", "working sysctl"); /* broken sysctl using my handler */ SYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(poid), OID_AUTO, "custom", CTLTYPE_INT|CTLFLAG_RW, &ret, -1, sysctl_handle, "I", "working sysctl"); } static int sysctl_handle(SYSCTL_HANDLER_ARGS) { int error; /* returns ENOMEM */ error = sysctl_handle_int(oidp, arg1, arg2, req); ... In the code above I use the "sysctl_handle" function to handle requests to the echo.* sysctls I have created. I create two nodes echo.default which uses the default handler "sysctl_handle_int", and echo.custom which uses my "sysctl_handle" function. What confuses me so greatly is that sysctl_handle is just a wrapper that calls sysctl_handle_int and passes its arguments without changing anything. There should be no difference because all I do is call the default handler. echo.default works, while echo.custom does not. Both functions operate on the same variables and have pretty much the same SYSCLT_ADD_PROC declaration. My best guess: I've tried to dig around in the debugger (using kgdb) but haven't been able to find anything. The only difference I noticed while tracing was that the "oldlenp" field in the sysctl_args struct passed in from userland was 0 when calling my handler and 8 when calling the default handler. I am not very familiar with the sysctl implementation, but this affected the valid length in the sysctl_req which ended up returning ENOMEM from sysctl_old_user. You can watch/confirm this change in sysctl_req using the following dtrace one-liner. Its unclear why changing the sysctl handler would affect the arguments passed to it. --------------------------- dtrace -n '*::sysctl_handle_int:entry /execname == "sysctl" / { print(*args[3]); }' // sysctl echo.default 0 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0x7fffffffd69c size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } 0 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0 size_t oldlen = 0 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0 int flags = 0 } 0 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0x800668000 size_t oldlen = 0x8 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x8 int flags = 0 } // sysctl echo.custom Custom Sysctl: Error 0 Custom Sysctl: Error 12 CPU ID FUNCTION:NAME 1 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0x7fffffffd69c size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } 1 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0 size_t oldlen = 0 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0 int flags = 0 } 1 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff8000392f580 int lock = 0x1 void *oldptr = 0x800667008 size_t oldlen = 0 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0 int flags = 0 } --------------------------- I'm really not sure what I've done wrong so any help is greatly appreciated. Most of the online resources/books that show sysctl creation seem to do the same thing I did. If there is tricky or non-obvious behavior that I have missed it would be helpful to note it for others trying to learn. If there is anything else I can provide or do please let me know. Thank you so much for your time! Austin Shafer _________________________________________________________________________ uname -a: FreeBSD punk-vm 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC-NODEBUG amd64 * uname doesn't list revision but it should be r342141 top memory usage: ... Mem: 20M Active, 2672K Inact, 143M Wired, 98M Buf, 1789M Free From owner-freebsd-hackers@freebsd.org Tue Dec 18 05:58:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 182B21341A3D for ; Tue, 18 Dec 2018 05:58:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBBD281503 for ; Tue, 18 Dec 2018 05:58:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wBI5wSLI094735 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Dec 2018 07:58:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wBI5wSLI094735 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wBI5wScs094734; Tue, 18 Dec 2018 07:58:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Dec 2018 07:58:28 +0200 From: Konstantin Belousov To: Austin Shafer Cc: freebsd-hackers@freebsd.org Subject: Re: ENOMEM when calling sysctl_handle_int from custom handler Message-ID: <20181218055828.GA60291@kib.kiev.ua> References: <861s6fpyua.fsf@triplebuff.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <861s6fpyua.fsf@triplebuff.com> User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 05:58:38 -0000 On Mon, Dec 17, 2018 at 05:34:05PM -0500, Austin Shafer wrote: > Hi freebsd-hackers, > > I've had an issue with creating a custom sysctl handler that I can't > seem to find an answer for. Using sysctl_handle_int as a handler in > SYSCTL_ADD_PROC works fine, but calling sysctl_handle_int from a custom > sysctl handler results in an error. > > (sorry for the long message, I tried to be verbose) > > Creating the nodes works fine, but SYSCTL_OUT or sysctl_handle_int > return ENOMEM despite there being plenty of available memory. I based my > approach on other areas of the source where those sysctls work without > error. It seems to only happen to custom sysctls that I add. This > happens on multiple machines, but the output in this email is from the > bhyve VM I test in. Any insight as to where my implementation went wrong > would be extremely helpful. > > Full Source: ("make" should compile on a bsd system) > https://github.com/ashaferian/sysctls > > echo_modevent () > { > ... > /* working sysctl using default handler sysctl_handle_int */ > SYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(poid), OID_AUTO, "default", CTLTYPE_INT|CTLFLAG_RW, &ret, -1, sysctl_handle_int, "I", "working sysctl"); > > /* broken sysctl using my handler */ > SYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(poid), OID_AUTO, "custom", > CTLTYPE_INT|CTLFLAG_RW, &ret, -1, sysctl_handle, "I", "working > sysctl"); > } > > static int > sysctl_handle(SYSCTL_HANDLER_ARGS) > { > int error; > > /* returns ENOMEM */ > error = sysctl_handle_int(oidp, arg1, arg2, req); > ... > > In the code above I use the "sysctl_handle" function to handle requests > to the echo.* sysctls I have created. I create two nodes echo.default > which uses the default handler "sysctl_handle_int", and echo.custom > which uses my "sysctl_handle" function. What confuses me so greatly is > that sysctl_handle is just a wrapper that calls sysctl_handle_int and > passes its arguments without changing anything. There should be no > difference because all I do is call the default handler. echo.default works, > while echo.custom does not. Both functions operate on the same > variables and have pretty much the same SYSCLT_ADD_PROC declaration. > > My best guess: > I've tried to dig around in the debugger (using kgdb) but haven't been > able to find anything. The only difference I noticed while tracing was > that the "oldlenp" field in the sysctl_args struct passed in from > userland was 0 when calling my handler and 8 when calling the default > handler. I am not very familiar with the sysctl implementation, but this > affected the valid length in the sysctl_req which ended up returning > ENOMEM from sysctl_old_user. You can watch/confirm this change in sysctl_req > using the following dtrace one-liner. Its unclear why changing the > sysctl handler would affect the arguments passed to it. Yes, this is most likely cause for your issue. ENOMEM does not have anything with the memory shortage, but with the fact that the oldlen is too short for int copyout. Note that for the int-typed oid, old and new len should be 4 (not 0 and not 8). Why your userspace code passed such length is the question to you. > > --------------------------- > dtrace -n '*::sysctl_handle_int:entry /execname == "sysctl" / { > print(*args[3]); }' > > > // sysctl echo.default > 0 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0x7fffffffd69c > size_t oldlen = 0x4 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0x4 > int flags = 0 > } > 0 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0 > size_t oldlen = 0 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0 > int flags = 0 > } > 0 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0x800668000 > size_t oldlen = 0x8 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0x8 > int flags = 0 > } > > // sysctl echo.custom > Custom Sysctl: Error 0 > Custom Sysctl: Error 12 > CPU ID FUNCTION:NAME > 1 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0x7fffffffd69c > size_t oldlen = 0x4 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0x4 > int flags = 0 > } > 1 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0 > size_t oldlen = 0 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0 > int flags = 0 > } > 1 27761 sysctl_handle_int:entry struct sysctl_req { > struct thread *td = 0xfffff8000392f580 > int lock = 0x1 > void *oldptr = 0x800667008 > size_t oldlen = 0 > size_t oldidx = 0 > int (*)() oldfunc = kernel`sysctl_old_user > void *newptr = 0 > size_t newlen = 0 > size_t newidx = 0 > int (*)() newfunc = kernel`sysctl_new_user > size_t validlen = 0 > int flags = 0 > } > --------------------------- > > I'm really not sure what I've done wrong so any help is greatly > appreciated. Most of the online resources/books that show sysctl > creation seem to do the same thing I did. If there is tricky or > non-obvious behavior that I have missed it would be helpful to note it > for others trying to learn. > > If there is anything else I can provide or do please let me know. > > Thank you so much for your time! > Austin Shafer > > _________________________________________________________________________ > uname -a: > FreeBSD punk-vm 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC-NODEBUG amd64 > * uname doesn't list revision but it should be r342141 > > top memory usage: > ... > Mem: 20M Active, 2672K Inact, 143M Wired, 98M Buf, 1789M Free > > _______________________________________________ > 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 Dec 18 08:29:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D8941345D3B; Tue, 18 Dec 2018 08:29:20 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DDCF861FC; Tue, 18 Dec 2018 08:29:19 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id v13so14912579wrw.5; Tue, 18 Dec 2018 00:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4sLUyBLDZ7Hfb8aUbN7j7izvHmcH+tWtdcpArhN0RwI=; b=J6y4HftqT16G/gMtfWvxn5qiRrRVJi/B9Nm5b49pwdXnULbfPPc7vNZCM6ds3jk5nX pJ/Zuea0+xHWJfhr/5gDjTOUq2rC68FhdVWKvylL3rB6DrVpQKwvtgdv7H82f94eHGG/ YqsngcjSMH+5Lb+BGdOwQ6byq5fyQtgd3NjtWFnlLsIhCL1sannqArTC8bMlftNPS08r c2fRY8VBRpG2bGNvN7i8MRhkLqsxeg9SWl+Uyb1GvujRIXIGtMvNoMzsd4ODBKMtnOx5 3eWjDseWbgDFeIr3F5oNnr4z0vNQvkxcxyR/lS02BnWw5tSpY8/GHnalm/gI/c5YEOg9 p6Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4sLUyBLDZ7Hfb8aUbN7j7izvHmcH+tWtdcpArhN0RwI=; b=Cr9bfngLa36Pmry6gtwu4UzBij77W5/lNteiFDN3MBMZ/Qu2YPFoST8ePVPC/gx6FT y2zx0oB/LQu0Ks3jI2VTsay8fr3OxZJncNGM9I4CUb6JeBCp74d3Kj599mp3vCqa4vVd qW3fBx81OfC5+E6qqROHg/cXldSAwYoPfxV60QqokXcdh5HLU89tbGswgqQgVD8c36Ae U3y+wmJVYN6XK7vyrq7riNg6SrEY1LKxEUNBOEL4m52KXKYScTo2iloOxBHdd/qUAixE NDVhZ2mccLUkcysyoXQi1vJooJtEKhxagCh4xVKMP+WKFtyzO2V3rtj/uk2GVm0Ia1fJ /dtw== X-Gm-Message-State: AA+aEWY3CMoqQ59wlFzQEll4EAzNSSHfDRIY1BJ/9AlNtaS6z0h3UDy4 JDMH5D1FLQK8pvDgCoTOtxT3aY4taArgyuPErhY/HA== X-Google-Smtp-Source: AFSGD/WeHNTvrAjIcXg4xGDDudzWSaMkcqKdauf18Bsit/LWL3lox1AIREoSWP6wKrzuXDTJpH0g1sqVcRZv/dMr8XA= X-Received: by 2002:adf:94e4:: with SMTP id 91mr14518743wrr.322.1545121757998; Tue, 18 Dec 2018 00:29:17 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> In-Reply-To: From: Rajesh Kumar Date: Tue, 18 Dec 2018 13:59:06 +0530 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: cem@freebsd.org Cc: asomers@freebsd.org, freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org X-Rspamd-Queue-Id: 7DDCF861FC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=J6y4Hftq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-5.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.902,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.47)[ip: (-9.29), ipnet: 2a00:1450::/32(-1.58), asn: 15169(-1.38), country: US(-0.08)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 08:29:20 -0000 Any thoughts (or) suggestions here? On Mon, Dec 17, 2018 at 4:54 PM Rajesh Kumar wrote: > Hi, > > Thanks everyone for your inputs. I assume, "PCI busmaster"ing refers to a > peripheral device being made as the owner of the bus by the DMA engine and > do data transfer. Please correct me if I am wrong. But, will this bus_dma > API uses the DMA engine in hardware (does it support PCI busmastering)? > > As I understand, DMA engine will expose DMA channels, which can be used by > the client drivers to queue their DMA requests (without CPU intervention) > and completions are given through the callback functions. If this is > considered the real DMA operation, I don't see options to request DMA > channels using bus_dma API's, and the callbacks in bus_dma API is meant to > receive just the DMA map details (doesn't indicate a DMA completion). > ioat(4) driver seems to be doing what I described above, but that seems to > be Intel specific. Can it be used with any DMA controllers? > > So, I am wondering what needs to be done in FreeBSD to do the actual DMA > involving DMA engine in a more generic way? > > Thanks, > Rajesh. > > > On Sat, Dec 15, 2018 at 6:30 AM Conrad Meyer wrote: > >> On Fri, Dec 14, 2018 at 8:17 AM Alan Somers wrote: >> > > For some Intel based server hardware, there is the "ioat" driver, >> which >> > > allows for user code to schedule DMA operations. See ioat(4) for >> > > details, including a pointer to the test program. >> >> This isn't true (or at least, only for testing). It's only usable by >> the kernel at the moment. >> >> > * In what context are callbacks called? Are they called from a signal >> > handler, or in a separate thread, or something else? >> >> Directly from the ithread, mostly. Callers can't take sleep locks or >> do very much besides set a flag and wakeup, or kick off a callout or >> taskqueue. >> >> > * Why isn't ioat.h installed? >> >> Why would it be? It's a kernel interface. >> >> > * Are "interrupts" synonymous with callbacks? >> >> I don't understand the question. Interrupts are synonymous with >> interrupts. Like, MSI-X. >> >> > * Do you have a rough idea for about the minimum buffer size that >> > makes sense to use with ioat? >> >> What makes sense will depend on your use case. It's not necessarily >> faster than CPU memcpy, but it may be worth some slowdown to offload >> latency-insensitive bulk copies. (It may make a lot of sense for >> asynchronous page zero, if someone wants to bring that back.) It's >> worth benchmarking your specific model. >> >> We use it for >= 8kB copies on Broadwell, although that's largely an >> artifact of our use case (write sizes are exactly 8 bytes, 512 bytes, >> or multiples of 8kB). IIRC, it shows up as a gen3 PCIe device with >> some small number of lanes on Broadwell, although I may be mistaken; >> and it may not communicate with RAM over the PCIe bus anyway, given >> the tight integration with the CPU. >> >> Best, >> Conrad >> _______________________________________________ >> freebsd-drivers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-drivers >> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org >> " >> > From owner-freebsd-hackers@freebsd.org Tue Dec 18 12:36:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 482691350554 for ; Tue, 18 Dec 2018 12:36:18 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4F66B07E for ; Tue, 18 Dec 2018 12:36:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp121-45-40-54.bras2.adl4.internode.on.net (HELO midget.dons.net.au) ([121.45.40.54]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Dec 2018 23:01:05 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id wBICUvp4040531 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Dec 2018 23:00:57 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id wBICET6f025217 for ; Tue, 18 Dec 2018 22:44:29 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [192.168.0.127] ([179.62.129.213]) by ppp121-45-40-54.bras2.adl4.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id wBICE2dg025069; Tue, 18 Dec 2018 22:44:29 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: How to use the DMA Engine in FreeBSD? From: "O'Connor, Daniel" In-Reply-To: Date: Tue, 18 Dec 2018 09:13:55 -0300 Cc: cem@freebsd.org, FreeBSD Hackers , freebsd-drivers@freebsd.org, asomers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DDD8ADE-4E34-4239-88EA-473B30FF8087@dons.net.au> References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> To: Rajesh Kumar X-Mailer: Apple Mail (2.3445.101.1) X-Spam-Score: 1.5 (*) No, score=1.5 required=5.0 tests=HELO_MISC_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 2A4F66B07E X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.17 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; MX_GOOD(-0.01)[cached: midget.dons.net.au]; NEURAL_HAM_SHORT(-0.39)[-0.391,0]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[145.137.101.150.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[54.40.45.121.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; IP_SCORE(0.29)[ipnet: 150.101.0.0/16(1.01), asn: 4739(0.46), country: AU(-0.03)]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.88)[0.883,0]; DMARC_NA(0.00)[dons.net.au]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.997,0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 12:36:18 -0000 > On 18 Dec 2018, at 05:29, Rajesh Kumar wrote: > Any thoughts (or) suggestions here? You don't need to "assign DMA channels" and a PCIe device doesn't = "master the bus" because it's all point to point. "DMA channels" are a legacy of ISA cards, although the terminology may = be reused for things like ioat. For PCI[e] devices which support bus mastering (ie virtually all of = them) the device itself issues the transfer. How that is actually done = depends on the device - usually you program registers with a = scatter/gather (SG) list, or with the physical address of an SG list in = system memory and then the device will do the job. The bus_dma* routines in the kernel are a tool box to let a driver tell = the kernel what kind of DMA a card is going to do and to help with = things like mapping it as necessary, cache coherency etc etc. Systems with ioat are pretty rare I believe, the vast majority of DMA in = a modern PC is done by PCI cards (or things which look like PCI cards to = the OS). > On Mon, Dec 17, 2018 at 4:54 PM Rajesh Kumar = wrote: >=20 >> Hi, >>=20 >> Thanks everyone for your inputs. I assume, "PCI busmaster"ing refers = to a >> peripheral device being made as the owner of the bus by the DMA = engine and >> do data transfer. Please correct me if I am wrong. But, will this = bus_dma >> API uses the DMA engine in hardware (does it support PCI = busmastering)? >>=20 >> As I understand, DMA engine will expose DMA channels, which can be = used by >> the client drivers to queue their DMA requests (without CPU = intervention) >> and completions are given through the callback functions. If this is >> considered the real DMA operation, I don't see options to request DMA >> channels using bus_dma API's, and the callbacks in bus_dma API is = meant to >> receive just the DMA map details (doesn't indicate a DMA completion). >> ioat(4) driver seems to be doing what I described above, but that = seems to >> be Intel specific. Can it be used with any DMA controllers? >>=20 >> So, I am wondering what needs to be done in FreeBSD to do the actual = DMA >> involving DMA engine in a more generic way? >>=20 >> Thanks, >> Rajesh. >>=20 >>=20 >> On Sat, Dec 15, 2018 at 6:30 AM Conrad Meyer wrote: >>=20 >>> On Fri, Dec 14, 2018 at 8:17 AM Alan Somers = wrote: >>>>> For some Intel based server hardware, there is the "ioat" driver, >>> which >>>>> allows for user code to schedule DMA operations. See ioat(4) for >>>>> details, including a pointer to the test program. >>>=20 >>> This isn't true (or at least, only for testing). It's only usable = by >>> the kernel at the moment. >>>=20 >>>> * In what context are callbacks called? Are they called from a = signal >>>> handler, or in a separate thread, or something else? >>>=20 >>> Directly from the ithread, mostly. Callers can't take sleep locks = or >>> do very much besides set a flag and wakeup, or kick off a callout or >>> taskqueue. >>>=20 >>>> * Why isn't ioat.h installed? >>>=20 >>> Why would it be? It's a kernel interface. >>>=20 >>>> * Are "interrupts" synonymous with callbacks? >>>=20 >>> I don't understand the question. Interrupts are synonymous with >>> interrupts. Like, MSI-X. >>>=20 >>>> * Do you have a rough idea for about the minimum buffer size that >>>> makes sense to use with ioat? >>>=20 >>> What makes sense will depend on your use case. It's not necessarily >>> faster than CPU memcpy, but it may be worth some slowdown to offload >>> latency-insensitive bulk copies. (It may make a lot of sense for >>> asynchronous page zero, if someone wants to bring that back.) It's >>> worth benchmarking your specific model. >>>=20 >>> We use it for >=3D 8kB copies on Broadwell, although that's largely = an >>> artifact of our use case (write sizes are exactly 8 bytes, 512 = bytes, >>> or multiples of 8kB). IIRC, it shows up as a gen3 PCIe device with >>> some small number of lanes on Broadwell, although I may be mistaken; >>> and it may not communicate with RAM over the PCIe bus anyway, given >>> the tight integration with the CPU. >>>=20 >>> Best, >>> Conrad >>> _______________________________________________ >>> freebsd-drivers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-drivers >>> To unsubscribe, send any mail to = "freebsd-drivers-unsubscribe@freebsd.org >>> " >>>=20 >>=20 > _______________________________________________ > 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" -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Tue Dec 18 17:06:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDE2413377B6 for ; Tue, 18 Dec 2018 17:06:51 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83436760DE for ; Tue, 18 Dec 2018 17:06:51 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: by mail-qt1-x843.google.com with SMTP id k12so18966894qtf.7 for ; Tue, 18 Dec 2018 09:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=XF0sy7bzh2p5i1t7TCgCQRr29np6d7o3utSdICogpQc=; b=qcyGLWktdgBztZYmxZm6so4UWZLA8A9KCGf7R8qvvSSErXdiU81KOpz//cO/MYM6j3 4MwIoSA7heoCWz5KHIVisqpAG4GlLhiECl9z4E1si5EpfpaXh8vydVdgveLWqEhINmgn jH4ee8RoSJJ0CWjlc5pWUcsxpGjNByAvw/4V0l17wdM0PNSufvVQmiKqHgo5Ec0GWERF uQm40RxmeiamrF0bI64qiBBVDn7RHpg1/pXaxWn5b/H3dVlvY4wU9C7JZTXDxbnXN7x7 j9ob8ZVDbWWlychD2ZESGXrdTLkwxb736YSF8DaxabjogLou0lVJZsIlxp0w3QFvvyHJ 7KmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=XF0sy7bzh2p5i1t7TCgCQRr29np6d7o3utSdICogpQc=; b=e05cWYFj5NMd2UTYFN6KyzsLC4/fDRhGAiMWLRIjHxcBQq/CknQr6usxINiF31TGfL CCPDOjjrnVgjKemVEZbj2z1s5q7spx91CdwrWSD8GT6up/g0kwKKhCLhmzxmLDSss9nk Pw1ihbH7X7G3CqO40NisF6hYT06QLy8s2UX5DNJlK9y0GciPKF6KVC0WWWzo1c1fDhz0 rhBDEfC3YvUkaWHZtRSFl+yFiIj1ycwGlc9JHuXhLySlKpbpE8bSF6UhhvnupmCVJ48b e4t63Cje4hfWVXPzKAeJCiuzkEeO+bbljCyq2+4lT1eg6ch9W87boKdc1XmbjexcqnXS iy+Q== X-Gm-Message-State: AA+aEWb0HIgoUtCaXdQsWiWWzl8ZacOSyIfJgnEt2653h8umS+coQNDe HA+uqpPZ+hV53IOajRxBCKKNPqiZ X-Google-Smtp-Source: AFSGD/XfKdXHkrV3KapAy56+wx3aMF8yaFtAg/GXT+2wsmkJ9kwSVADYI5rRR0RK7u6F9Vs4UcW1KQ== X-Received: by 2002:a0c:981b:: with SMTP id c27mr18584461qvd.184.1545152811030; Tue, 18 Dec 2018 09:06:51 -0800 (PST) Received: from localhost ([178.128.156.9]) by smtp.gmail.com with ESMTPSA id s9sm316723qta.35.2018.12.18.09.06.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 09:06:49 -0800 (PST) From: Austin Shafer To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: ENOMEM when calling sysctl_handle_int from custom handler In-Reply-To: <20181218055828.GA60291@kib.kiev.ua> References: <861s6fpyua.fsf@triplebuff.com> <20181218055828.GA60291@kib.kiev.ua> Date: Tue, 18 Dec 2018 12:06:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 83436760DE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 17:06:52 -0000 Konstantin Belousov writes: > On Mon, Dec 17, 2018 at 05:34:05PM -0500, Austin Shafer wrote: >> My best guess: >> I've tried to dig around in the debugger (using kgdb) but haven't been >> able to find anything. The only difference I noticed while tracing was >> that the "oldlenp" field in the sysctl_args struct passed in from >> userland was 0 when calling my handler and 8 when calling the default >> handler. I am not very familiar with the sysctl implementation, but this >> affected the valid length in the sysctl_req which ended up returning >> ENOMEM from sysctl_old_user. You can watch/confirm this change in sysctl_req >> using the following dtrace one-liner. Its unclear why changing the >> sysctl handler would affect the arguments passed to it. > Yes, this is most likely cause for your issue. ENOMEM does not have > anything with the memory shortage, but with the fact that the oldlen > is too short for int copyout. > > Note that for the int-typed oid, old and new len should be 4 (not 0 and > not 8). Why your userspace code passed such length is the question to > you. > Thanks for the reply! I'm just using the sysctl(8) utility in the examples above so the valid length passing from userspace is not done by me. Based on what you said it seems to me that sysctl(8) is not passing the correct values then? This would be strange since all other sysctls work using sysctl(8). I'm more than happy to dig deep and debug sysctl(8) to see if it is the culprit. I had assumed it was working fine and that the error was on my end in the kernel module. You are right about the userspace passed values being whats causing my problems though. I wrote a short program to call sysctlbyname (with the correct length as you specified above) and now I can set the value of the sysctl: // read_sysctl.c int main (int argc, char *argv[]) { int error, old, new = 3; size_t size; size = sizeof(int); ... error = sysctlbyname(argv[1], &old, &size, &new, size); ... } // dtrace -n '*::sysctl_handle_int:entry /execname == "read_sysctl" / { print(*args[3]); }' CPU ID FUNCTION:NAME 2 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff80003b38580 int lock = 0x1 void *oldptr = 0x7fffffffd71c size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } 2 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff80003b38580 int lock = 0x1 void *oldptr = 0x7fffffffeb28 size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0x7fffffffeb24 size_t newlen = 0x4 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } Also out of curiosity, the dtrace probes show multiple sysctl_handle_int evaluations. Is this for each root and sub-node in the sysctl tree? Thats what it looks like to me but I'd love to know for sure. Thanks for all the help! Austin Shafer From owner-freebsd-hackers@freebsd.org Tue Dec 18 19:14:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09146133BA15 for ; Tue, 18 Dec 2018 19:14:04 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E62E83481 for ; Tue, 18 Dec 2018 19:14:03 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-lj1-x22f.google.com with SMTP id q2-v6so4062270lji.10 for ; Tue, 18 Dec 2018 11:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9vQEPuYbisMfvbHxibgoaWHmagpRfLIafJ+18tE4IMg=; b=NZ9jIFlWpPYQrrkpVHo8gbedmxNemXTnuHs0rsIJ8otjbdjnsrb/n54zavtJV8X91v WpZEotBZLSY/DASNzNR/SUphutsnTLlS181IKyniKeG4ogzMYFU//TQmlUilm6bk/FoH TRMD87SPLKScZNnBoT1PT4jLTU2a2b50FKIqVhCWBIReXtTcLFt3pWDNxoCvFVUQOl0o kCaOn5Onusw+ZmyOh8CarcDRcLNJi9r1C/jKpXyzsH7fyRvbhRxChZNeauc6xG2L0r3x +fO+NLU/4hmlipaqjAbPIhHUwoq+/rqm8D8QRln2h/+iAOHgbtv1+P/oM2ukzKeo/kSv yZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9vQEPuYbisMfvbHxibgoaWHmagpRfLIafJ+18tE4IMg=; b=q02317OfJbWDIFwfVCUl5/rM9Z8NZVt6535W4SSe37raBQg0LYI84z3Uhd3vOJSgya 0XH09uIXRJZwnJxUVa1AKzgeQxaSbDJX3Ju39zv4tRwSQ8sMw4nCgepCC8kiHDuTFt7s XnEehFuDOnxMdy4ntbqunOlrk2Fn1gWx7gGpiV06vLZrnG+qLHjx/XU5crUJIXXxo7k1 N5mi3kfZpCpaBMMayrGXm6zowLhQJYnfJhy0NRB1nbuzTxVIGwmlZJS7L8P3ab5W2qCQ GRj2wiVntsj6vieMj4/BzCvhVwtjPXl51Gm/515K7w8Y3WZhzcX31EEw9ntPttRFOHLl MSDg== X-Gm-Message-State: AA+aEWYV8LpfagGyQLcZ+bv61f2awc1zaJaXNrX4a6NJiwqrvyFQbcAT nruOQ5usChSfuTD2PDXSymqxStaF4BrsYD/DZ2A= X-Google-Smtp-Source: AFSGD/XNYA3H1jUXS9vWYt9ym1njMBXnD92c0OQlpjLq/z4yVSeSxPatjQ4MrgSmZyNUhHi27BDiV6pDhDYkzQUrAYY= X-Received: by 2002:a2e:5555:: with SMTP id j82-v6mr12263089ljb.69.1545160441955; Tue, 18 Dec 2018 11:14:01 -0800 (PST) MIME-Version: 1.0 References: <861s6fpyua.fsf@triplebuff.com> In-Reply-To: <861s6fpyua.fsf@triplebuff.com> From: Ryan Stone Date: Tue, 18 Dec 2018 14:13:50 -0500 Message-ID: Subject: Re: ENOMEM when calling sysctl_handle_int from custom handler To: Austin Shafer Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5E62E83481 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=NZ9jIFlW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-6.36 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.84)[-0.840,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.51)[ip: (-9.51), ipnet: 2a00:1450::/32(-1.57), asn: 15169(-1.37), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 19:14:04 -0000 You should not pass arg1 and arg2 to sysctl_handle_int(). You instead need to pass a pointer to a local value containing the value you want to return to the sysctl caller. After sysctl_handle_int returns, if it returned 0 and req->newptr is non-NULL, then the integer value will contain the new value that was passed to you from userland. You want something that looks like this: int my_sysctl_handler(SYSCTL_HANDLER_ARGS) { int val, error; val = 5; /* Or whatever value you want to return from userland. */ error = sysctl_handle_int(oidp, &val, 0, req); if (error != 0 || req->newptr == NULL) return (error); /* val contains the value set by the caller, so do something interesting with it here. */ return (0); } From owner-freebsd-hackers@freebsd.org Tue Dec 18 20:10:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71D73133D9B2 for ; Tue, 18 Dec 2018 20:10:01 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A34A485968 for ; Tue, 18 Dec 2018 20:10:00 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: by mail-qt1-x82a.google.com with SMTP id v11so19715569qtc.2 for ; Tue, 18 Dec 2018 12:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=NfH1rB+5SfjGgc+6/WfvF3h0rF/tNkjFmzZmeerK+SA=; b=iUl+Ynqqp1SthHQrNyqjrrhuA3LmqQYOiJ+pdy064egOwtZonHyIiVu8aYIHIpwUSg 654jU2XbJFNd5f/2jWvthEL6c9xTcQD7HmWnWMLJct/AE4ah7+oOAsCU8aqj0otCcZq6 tkhloqLmQ3MP3cnkilxvs/Laa4UEZoH5UewvaJNjDkcEv3+1/Z0ZYa7+vPoCRF7oQ8DO vbPR4co7Bj7CpHpXOBypWds5/rjUP3i0vM1Fankw1sd4Io5cQEyTQgQkB0BwFLORYrlw 91daOfbcP2kXqIAQGBIWSk8mNketvr+6WS7VJMGur82kNNBjFLl59tBVVZbUMTrN/SZJ Au3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=NfH1rB+5SfjGgc+6/WfvF3h0rF/tNkjFmzZmeerK+SA=; b=DfJ3YeKn6AOWgF1Xz0QkiT4lOltuXykHlVmDmPHvoiq04oSM7lMzZCmWAHZX4ME3za t1IQEaOgRU/uFgEIelatyEJZew/piyq/E9dR1aAxs8sSPtF8ENzO1aoRfT3/6hKDA9cy AunLskvHmS0DITQmIri2X3EQdrIYqDBUK5Q/6wkorTQQrpSueyaSlPqFIgk09L8kywKe rhlcLhgSmcITOFWQF6WWnLNdvvbQ68qv82bO/m7Lw7V9gYyuSqhCwIuejbC1+RfXaOeD tXQXqTa51MVwIZmL2d70liCnG0FyMWlKcwrQgODTEqY2a76VJKs8bfiV1d6nQN2ekRRS HblQ== X-Gm-Message-State: AA+aEWZ9H+thuTD97FMBq+y6/rFOaoUZN3bf+CkxCbdOrXgIT1r7+Tx9 uH93OwIzdVLvPDJc6+xxCO8= X-Google-Smtp-Source: AFSGD/XXSTcUclgL/Xp43vFERFDjcgPdgRWZ1O0rLEc6Wh/BaVspj9jhkXAhkDhL8kds0Qzx0Y+K4Q== X-Received: by 2002:ac8:4141:: with SMTP id e1mr9231670qtm.96.1545163800108; Tue, 18 Dec 2018 12:10:00 -0800 (PST) Received: from localhost ([178.128.156.9]) by smtp.gmail.com with ESMTPSA id 86sm686790qky.92.2018.12.18.12.09.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 12:09:58 -0800 (PST) From: Austin Shafer To: Ryan Stone Cc: freebsd-hackers@freebsd.org Subject: Re: ENOMEM when calling sysctl_handle_int from custom handler In-Reply-To: References: <861s6fpyua.fsf@triplebuff.com> Date: Tue, 18 Dec 2018 15:08:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: A34A485968 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iUl+Ynqq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of amshafer64@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=amshafer64@gmail.com X-Spamd-Result: default: False [-6.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.06)[ip: (-7.11), ipnet: 2607:f8b0::/32(-1.73), asn: 15169(-1.37), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 20:10:01 -0000 Ryan Stone writes: > You should not pass arg1 and arg2 to sysctl_handle_int(). You instead > need to pass a pointer to a local value containing the value you want > to return to the sysctl caller. After sysctl_handle_int returns, if > it returned 0 and req->newptr is non-NULL, then the integer value will > contain the new value that was passed to you from userland. You want > something that looks like this: > > int > my_sysctl_handler(SYSCTL_HANDLER_ARGS) > { > int val, error; > > val = 5; /* Or whatever value you want to return from userland. */ > > error = sysctl_handle_int(oidp, &val, 0, req); > if (error != 0 || req->newptr == NULL) > return (error); > > /* val contains the value set by the caller, so do something > interesting with it here. */ > > return (0); > } Hmm yup this seems to be problem. I had originally tried to just pass the handler args directly through to sysctl_handle_int to make sure I was creating the nodes correctly, since I knew sysctl_handle_int worked. Thanks again for all the help on these beginner questions! Austin Shafer From owner-freebsd-hackers@freebsd.org Wed Dec 19 09:45:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D44731352274; Wed, 19 Dec 2018 09:45:58 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C57A672606; Wed, 19 Dec 2018 09:45:57 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wm1-x32c.google.com with SMTP id f188so4960938wmf.5; Wed, 19 Dec 2018 01:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GwomkPl3xq3IpnQyA1dZXsw2iVM32YY4qcVxeAgP4QY=; b=NLyyhedeAtPLKUPMqyX/Rjtv2sKXPvVafrPLcZzBXeJZlKGIiuo9Czx9/T4TE4AC/y oxUEqPrJk/YAYOfbRQ5YKTO3cVe0/9MBu8ALbcT4v/flH+k0/feEU3L5aM2cMf+LlmQC gjjr6jN29GavC/H47Vk/1vz9oQjTwx5m90S5jVrodQoKU0jTQ0nBoCLlaf6xxyGAO1++ X3o2OnUCNtkTMTNJCKciYjlRlLbi8VM8C2XKRvDQhNdpexHMpmsL194YIIg1azk2k3co LJYzkjSx+ifbF7WMVA0fRxB0tcW2Z0rAchlV4MrhvNN3OJMmgWQYzsvRnMfSDyITQUXf c9lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GwomkPl3xq3IpnQyA1dZXsw2iVM32YY4qcVxeAgP4QY=; b=b8bMv43NdW6bWs/ZoZmK5I0u5StzaLX8K8z7wEL73Wt4vWqRaD4Eit01YAygDmc1EY KR2vxy53oWveXyM6q8sI2ct8Nny+jYQzuu+eBZfO0GqydhnnvHEGou3xvQOG6f0jgx3V Z+l4aw39aatWM3HUzknHtePbI/wtXAgJtmQIjrfbtfc1/ik4Wg4oLoRfOaEgeivQl5Dt shI0JwsGVZUEOgraWjopl93wmyn7SfWFyoR5YYcMIOOOsJS6M1Ksbe3YGxMZWz3Jg+P3 4leK8Mzj88P0Hbv5AHdOubrT1pp44j+FEtTPlhV9yVgDQvS6pYz/oG4OrODp3JSuzzAL fFzw== X-Gm-Message-State: AA+aEWamtzKN9lBatBtadEL8+U9KFA309sc5FmlLOQJNJ6Lq/z2ogVwI U3p3UJdCckyOs5/FkHaSTfK7qjDHbGzGzCADZPLuui0q X-Google-Smtp-Source: AFSGD/U9uzBuGDpZtmm8lDeKOrf8OgHFUd1O0bNiAnrxl8dTEezii4kJ5TfH5R4bafxSfrbZX4JrQH1moTvIUPrHNW8= X-Received: by 2002:a1c:8d12:: with SMTP id p18mr6969993wmd.31.1545212756495; Wed, 19 Dec 2018 01:45:56 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> <2DDD8ADE-4E34-4239-88EA-473B30FF8087@dons.net.au> In-Reply-To: <2DDD8ADE-4E34-4239-88EA-473B30FF8087@dons.net.au> From: Rajesh Kumar Date: Wed, 19 Dec 2018 15:15:44 +0530 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: "O'Connor, Daniel" Cc: cem@freebsd.org, FreeBSD Hackers , freebsd-drivers@freebsd.org, asomers@freebsd.org X-Rspamd-Queue-Id: C57A672606 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=NLyyhede; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-5.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[c.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.885,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.51)[ip: (-9.51), ipnet: 2a00:1450::/32(-1.58), asn: 15169(-1.38), country: US(-0.08)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 09:45:59 -0000 Thanks for your explanation Daniel. I will see how to initiate the DMA transfer in my case after the bus_dma API's has done its part. On Tue, Dec 18, 2018 at 6:01 PM O'Connor, Daniel wrote: > > > > On 18 Dec 2018, at 05:29, Rajesh Kumar wrote: > > Any thoughts (or) suggestions here? > > You don't need to "assign DMA channels" and a PCIe device doesn't "master > the bus" because it's all point to point. > > "DMA channels" are a legacy of ISA cards, although the terminology may be > reused for things like ioat. > > For PCI[e] devices which support bus mastering (ie virtually all of them) > the device itself issues the transfer. How that is actually done depends on > the device - usually you program registers with a scatter/gather (SG) list, > or with the physical address of an SG list in system memory and then the > device will do the job. > > The bus_dma* routines in the kernel are a tool box to let a driver tell > the kernel what kind of DMA a card is going to do and to help with things > like mapping it as necessary, cache coherency etc etc. > > Systems with ioat are pretty rare I believe, the vast majority of DMA in a > modern PC is done by PCI cards (or things which look like PCI cards to the > OS). > > > On Mon, Dec 17, 2018 at 4:54 PM Rajesh Kumar wrote: > > > >> Hi, > >> > >> Thanks everyone for your inputs. I assume, "PCI busmaster"ing refers to > a > >> peripheral device being made as the owner of the bus by the DMA engine > and > >> do data transfer. Please correct me if I am wrong. But, will this > bus_dma > >> API uses the DMA engine in hardware (does it support PCI busmastering)? > >> > >> As I understand, DMA engine will expose DMA channels, which can be used > by > >> the client drivers to queue their DMA requests (without CPU > intervention) > >> and completions are given through the callback functions. If this is > >> considered the real DMA operation, I don't see options to request DMA > >> channels using bus_dma API's, and the callbacks in bus_dma API is meant > to > >> receive just the DMA map details (doesn't indicate a DMA completion). > >> ioat(4) driver seems to be doing what I described above, but that seems > to > >> be Intel specific. Can it be used with any DMA controllers? > >> > >> So, I am wondering what needs to be done in FreeBSD to do the actual DMA > >> involving DMA engine in a more generic way? > >> > >> Thanks, > >> Rajesh. > >> > >> > >> On Sat, Dec 15, 2018 at 6:30 AM Conrad Meyer wrote: > >> > >>> On Fri, Dec 14, 2018 at 8:17 AM Alan Somers > wrote: > >>>>> For some Intel based server hardware, there is the "ioat" driver, > >>> which > >>>>> allows for user code to schedule DMA operations. See ioat(4) for > >>>>> details, including a pointer to the test program. > >>> > >>> This isn't true (or at least, only for testing). It's only usable by > >>> the kernel at the moment. > >>> > >>>> * In what context are callbacks called? Are they called from a signal > >>>> handler, or in a separate thread, or something else? > >>> > >>> Directly from the ithread, mostly. Callers can't take sleep locks or > >>> do very much besides set a flag and wakeup, or kick off a callout or > >>> taskqueue. > >>> > >>>> * Why isn't ioat.h installed? > >>> > >>> Why would it be? It's a kernel interface. > >>> > >>>> * Are "interrupts" synonymous with callbacks? > >>> > >>> I don't understand the question. Interrupts are synonymous with > >>> interrupts. Like, MSI-X. > >>> > >>>> * Do you have a rough idea for about the minimum buffer size that > >>>> makes sense to use with ioat? > >>> > >>> What makes sense will depend on your use case. It's not necessarily > >>> faster than CPU memcpy, but it may be worth some slowdown to offload > >>> latency-insensitive bulk copies. (It may make a lot of sense for > >>> asynchronous page zero, if someone wants to bring that back.) It's > >>> worth benchmarking your specific model. > >>> > >>> We use it for >= 8kB copies on Broadwell, although that's largely an > >>> artifact of our use case (write sizes are exactly 8 bytes, 512 bytes, > >>> or multiples of 8kB). IIRC, it shows up as a gen3 PCIe device with > >>> some small number of lanes on Broadwell, although I may be mistaken; > >>> and it may not communicate with RAM over the PCIe bus anyway, given > >>> the tight integration with the CPU. > >>> > >>> Best, > >>> Conrad > >>> _______________________________________________ > >>> freebsd-drivers@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-drivers > >>> To unsubscribe, send any mail to " > freebsd-drivers-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" > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > From owner-freebsd-hackers@freebsd.org Wed Dec 19 12:07:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51A2413340B0 for ; Wed, 19 Dec 2018 12:07:05 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E157D7751E; Wed, 19 Dec 2018 12:06:57 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wm1-f53.google.com with SMTP id m1so5835973wml.2; Wed, 19 Dec 2018 04:06:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JLk93XMfdT3VqXvCaePF1fRoxUqow4lprJoW5P+7WFs=; b=eaJohxM7pAq4DIiz3hkYyx8mVAsJ6OHbLyDgOAvZcGNd9i9aqyYVaW6Nrj+RK/juxR GWSBNmWfRGj1BdBkU2nliIMjTEf5CGBgAZYEg6nvxEoz0CUqN+v/uyLBBC+Va71SebCO e9ycSpACC5lUopRRln5OAOK+9GG6j7gKBGH7qlHiJRStJ8+8pUa36wk5zUsZvqwQGuov QFGR0N+wfxrf3p/SGrao4yuGCrUeEGGINJ6x9xQmOcg4invWs02DrEWtXl2Ph4eWp/mm +R3vK0hkgw+btYNNsUaRJutuHj+I5wpZikp+5FT3S/4RcDLuKrD4zbFnqKnTmZGh+vjW WBeg== X-Gm-Message-State: AA+aEWY33E9S5V8rEVQWTJXosoEoLqH7FbNZ5P32Dc+hJ1QYL8pEwcm8 8Q4ajUslxdFYndCiF65jVH2OPD9ZlmhbFf4uyGwHMBGP X-Google-Smtp-Source: AFSGD/WOSk00bSZKrv5wAibHtVhW427acatelAFR1Pw9T2HSX2Iuv6a1e+uUjl08jQaDdSxbp4K305UVKf+IxCQSZeA= X-Received: by 2002:a1c:6a16:: with SMTP id f22mr6977705wmc.25.1545220755765; Wed, 19 Dec 2018 03:59:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Wed, 19 Dec 2018 19:59:04 +0800 Message-ID: Subject: Re: Cirrus-CI: Free FreeBSD CI testing for open-source projects To: Alan Somers Cc: FreeBSD Hackers X-Rspamd-Queue-Id: E157D7751E X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-3.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.98)[-0.977,0]; IP_SCORE(-1.01)[ipnet: 209.85.128.0/17(-3.60), asn: 15169(-1.39), country: US(-0.08)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[53.128.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.77)[-0.774,0]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; MIME_TRACE(0.00)[0:+,1:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 12:07:05 -0000 On Wed, Dec 5, 2018 at 03:03 Alan Somers wrote: > Cirrus Labs has just released support for FreeBSD on their CI service. And > they've made it free for OSS! Cirrus-CI is a cloud-based CI system for > cloud-hosted software, much like Travis-CI, Appveyor, Circle-CI, etc. But > it's the first* such system to support FreeBSD with no weird hacks > required. It also runs each test in a full VM, so you can mount > filesystems, create jails, etc. The free tier supports runs on a dual CPU > VM with 4GB of RAM. But if that's not enough, you can cheaply configure > Cirrus to use a custom VM in Google Cloud (gcp account required; cheap but > not free). > > https://cirrus-ci.org/guide/FreeBSD/ This is really an exciting news. Ed and I started a wiki page for tracking the efforts we put or wanted to add FreeBSD CI for the software widely used: https://wiki.freebsd.org/HostedCI Editing is welcomed. :-) Li-Wen From owner-freebsd-hackers@freebsd.org Wed Dec 19 14:36:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A98691336F19 for ; Wed, 19 Dec 2018 14:36:11 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2A24830A5; Wed, 19 Dec 2018 14:36:10 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: by mail-pl1-x62e.google.com with SMTP id y1so9541081plp.9; Wed, 19 Dec 2018 06:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:mime-version:subject:message-id:date:cc:to; bh=XHLRInXOZ5cInFtA1Dc+TYd7RBKCF41Sh7vQq9HXrdo=; b=rvO75Bi9WeskIY5uTUaJbpIRyoJMzsQgigvYAPK3mN1HARkmnVpPR2PQl1qdStRzbw rTPj+Gz9xCz2zh0g4tcC1mbGuJjt9RGRlx/4Fj9zMwoempJXIrx/v+QDim8auY4g8MR9 PLSWEPpY0muXr4jJJSdP1X6x1HB/AR8e2zOa5gkBUv/CiFL/F4zO6J+gBcY7fNJGK7HQ pI9B8yVd8apIrm+0BwFvwjMkfmk2/0XAxfZuyRthoykAPI+2P1guL1+7vQIWajnjrX67 Nz0Rm3V0M3BOsqh+iO5T89IUL3o2N++OJf+m9EnqXQQGGuswm8itpyJGQBBQJZ4jkp8d 7j5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:mime-version:subject:message-id:date :cc:to; bh=XHLRInXOZ5cInFtA1Dc+TYd7RBKCF41Sh7vQq9HXrdo=; b=m4BCjtqTOqmq8w0rRTPQY8UrAdzCi35dXkls3m1sD995Ti+TCH38Dz5eIBJUnJvD4Z hs60rNUfOOi0x589fiIG0cLH4n624j0nXMrdL1aZu7HSX/XRPFQmsZxSW/8vPjnZq4/Q X/lGtDI1CyoU064V5dQv3dG2GUNV5av/UXNL/SriT4Vf9HAMio7+j8HAh8qEsG8aLsGz lNo9xAg2kbfWDPgIFOaiDY7kr9f1EwKH0+D/BJPdS03SZ3yx3h3r8NAGNHfovsJSQ/5t o9FBdt9a4AwGiqPIrrIiZ5VZjPVPCmD90XzPNkgh5uOCipW0IRLpaVnNf6W8faB4057y STAA== X-Gm-Message-State: AA+aEWae2g3Rf9kxhmflpFOSSowcRUP7QYQXt1KN5tjixHcrAhMNFUMT y0EWCTrE2NsZaBJcB8Pba205cAbt X-Google-Smtp-Source: AFSGD/U+N8hhfkX5+JHwUSw7+6CnTLxhiMrN8Y/vFOedYu8QzjSNY7x2Dkg06s90JTd8hjJb+tvaKw== X-Received: by 2002:a17:902:8a8a:: with SMTP id p10mr20790107plo.50.1545230168859; Wed, 19 Dec 2018 06:36:08 -0800 (PST) Received: from [192.168.0.123] ([61.6.151.101]) by smtp.gmail.com with ESMTPSA id k14sm26614709pgs.52.2018.12.19.06.36.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 06:36:07 -0800 (PST) Sender: Martin Wilke From: Martin Wilke Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: OpenRC on FreeBSD Message-Id: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> Date: Wed, 19 Dec 2018 22:36:04 +0800 Cc: Joe Maloney , ken@ixsystems.com, wblock@FreeBSD.org, kmoore@FreeBSD.org, Marcelo Araujo To: freebsd-hackers@FreeBSD.org X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: A2A24830A5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rvO75Bi9; spf=pass (mx1.freebsd.org: domain of miwifbsd@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=miwifbsd@gmail.com X-Spamd-Result: default: False [-2.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[9]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.70)[-0.704,0]; FORGED_SENDER(0.30)[miwi@FreeBSD.org,miwifbsd@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[miwi@FreeBSD.org,miwifbsd@gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[e.2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.64)[ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 14:36:12 -0000 Hi I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this = is the second attempt to get it into FreeBSD. I've opened a review here with a working patch for CURRENT, https://reviews.freebsd.org/D18578 To recap the discussion * First attempt of RFC in March of 2018: = https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html= * Working group at BSDCan: = https://wiki.freebsd.org/DevSummit/201806/OpenRC Here some key points: OpenRC provides additional features for service management without = requiring kernel changes or replacing pid 1, unlike launchd and other = solutions. All rc.d scripts have been converted with a few changes, = typically changing the shebang and making sure the start function is = named start(). Most service scripts are simplified, usually needing only = name, command, and, if required, depends statements. History: OpenRC started out as an init system by Roy Marples, developed for the = Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into = Gentoo as baselayout v2, and was then split off as a separate = BSD-licensed project. It is under active development, portable, and = remains BSD licensed today. OpenRC and RC: Both can coexist and be chosen with a setting in /boot/loader.conf. OpenRC Features: Service supervision and service monitoring: any service can be = supervised. Supervised services that crash are automatically restarted. = The rc-status command shows how many times a service has restarted. Device hotplug support and event-driven service management: the hotplug = feature allows devd to take actions when devices are connected. For = example, a USB wifi adapter can create additional network services when = attached. The net-online service can, for example, detect when a network = connection is restored, and restart ntp. Network profiles: using stacked runlevels, different profiles can be = established for different networking settings. For instance, different = profiles can be used for wired or wireless networking, or for differing = wireless networks, as well as dependency caching and parallel startup = speed up booting. Interactive mode: The boot process can be run interactively for more effective debugging. OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the context = in which a script is running. There are only three at present: sysinit (the OpenRC system is starting), boot (start base services when = the computer is booting), and default (normal execution). OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, = using ANSI color sequences. This can be disabled. Ports: As of July 2017, iXsystems has created OpenRC versions of port service = scripts for the entire ports tree. These scripts coexist with the rc.d = versions. License: OpenRC is a BSD licensed RC init system written in C. =46rom a user = perspective, it is very similar to the FreeBSD rc.d init system, making = it easy to use and learn. Tested: OpenRC has been used as the init system for TrueOS since October = 2016. Ken Moore has an OpenRC vs RC.d comparison which can be found here: http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf = I look forward to discuss the features and capabilities of OpenRC. Regards, Martin From owner-freebsd-hackers@freebsd.org Wed Dec 19 14:51:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 039451337933 for ; Wed, 19 Dec 2018 14:51:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E36083AFA for ; Wed, 19 Dec 2018 14:51:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id q70so11802320qkh.6 for ; Wed, 19 Dec 2018 06:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w7J7NbE976HafzNQalknGw5f7O0P/uF2TDl4b/4JqXk=; b=FzLXtKGw0HPRyg6hqHrqObHQznJaWToJ4eEQJT+7rQ5RMTqbRU7EMVbby8dErahIIi /EILn4RchZO7gpREabrjRm5gX1kgpJW3YT3CGJL6cX58kUr4Fg/ZpuirTn24qbukz62i vFDUua1MgEp96arzmkqX+lqpwCyAHQeRar82fK/dEPic1t5T0Wi/TpjJau+YcPbU1vn5 HHzQGw4s0/B6snCkQMbqIVUiFGQqJtrdbz3Ufi42tC19B3BhOx+xuMqkjCOi8JwJ0wwu O4xj+IIC58ZdnABSv3vP77UWcen94FLbUjCLVzLWEBjt1T7sGoNJ4ra7ijtUB753Ie/5 1pWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w7J7NbE976HafzNQalknGw5f7O0P/uF2TDl4b/4JqXk=; b=gDRhSVo3iRsXsFNw5PvO3BKZ9d+3y6JTbfOA3ylAsP9EBUjOdKXiH4JDpoqaVyVhuB o3FPx0K8lduGhJrl2n0QI54AiqNVR4HcpTnGlurI+ooB4afq5OpZA5jHKycrfhABE4Da wThHtvQEnHy+YFkGBHXgWgiT08TNU5mlQtjXrcATpYq0swp5iKbQiTjTXFFevYBZJhv2 +yacPDfChfpF/HzFUFRLPYJyZrUBLODOFrk1lsGfnURfB82p3kq64K0a4iO7wv/NoFTA 3r7Xi0tZFTlCgxIzW7iv8dWFzvSUlG9QcvA69RWi9x2xuL3idkCzQ2J6AmzEC9RoXYBv MS0g== X-Gm-Message-State: AA+aEWZHyYiReFlxbcomOL47HTAjTK0NcdQvym8mFsuYM0//1YBY4efs rJFv+unS46VocAxPD85ejZEeYlVNQinwVTkf24n9jQ== X-Google-Smtp-Source: AFSGD/V5CPZXm0W/LPo9KarHhytfG6YsqlkAQmWA8tcpdvRBW0WnvHtk2zRGvNyKDqCe+sqPrJudi124pwlZddaQnig= X-Received: by 2002:a37:c653:: with SMTP id b80mr21723405qkj.245.1545231101843; Wed, 19 Dec 2018 06:51:41 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> In-Reply-To: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> From: Warner Losh Date: Wed, 19 Dec 2018 07:51:28 -0700 Message-ID: Subject: Re: OpenRC on FreeBSD To: Martin Wilke Cc: "freebsd-hackers@freebsd.org" , Joe Maloney , Marcelo Araujo , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: 7E36083AFA X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=FzLXtKGw X-Spamd-Result: default: False [-3.48 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.49)[-0.489,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[9.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-1.99)[ip: (-6.71), ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 14:51:44 -0000 On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: > Hi > > I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this i= s > the second attempt to get it into FreeBSD. > > I've opened a review here with a working patch for CURRENT, > https://reviews.freebsd.org/D18578 > > > To recap the discussion > * First attempt of RFC in March of 2018: > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > * Working group at BSDCan: > https://wiki.freebsd.org/DevSummit/201806/OpenRC > > Here some key points: > > OpenRC provides additional features for service management without > requiring kernel changes or replacing pid 1, unlike launchd and other > solutions. All rc.d scripts have been converted with a few changes, > typically changing the shebang and making sure the start function is name= d > start(). Most service scripts are simplified, usually needing only name, > command, and, if required, depends statements. > > History: > OpenRC started out as an init system by Roy Marples, developed for the > Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gento= o > as baselayout v2, and was then split off as a separate BSD-licensed > project. It is under active development, portable, and remains BSD licens= ed > today. > > OpenRC and RC: > Both can coexist and be chosen with a setting in /boot/loader.conf. > > OpenRC Features: > > Service supervision and service monitoring: any service can be supervised= . > Supervised services that crash are automatically restarted. The rc-status > command shows how many times a service has restarted. > > Device hotplug support and event-driven service management: the hotplug > feature allows devd to take actions when devices are connected. For > example, a USB wifi adapter can create additional network services when > attached. The net-online service can, for example, detect when a network > connection is restored, and restart ntp. > > Network profiles: using stacked runlevels, different profiles can be > established for different networking settings. For instance, different > profiles can be used for wired or wireless networking, or for differing > wireless networks, as well as dependency caching and parallel startup spe= ed > up booting. > > Interactive mode: > The boot process can be run interactively for more effective debugging. > > OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the context = in which a script > is running. There are only three at present: > sysinit (the OpenRC system is starting), boot (start base services when > the computer is booting), and default (normal execution). > > OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, usi= ng ANSI color > sequences. This can be disabled. > > Ports: > As of July 2017, iXsystems has created OpenRC versions of port service > scripts for the entire ports tree. These scripts coexist with the rc.d > versions. > > License: > OpenRC is a BSD licensed RC init system written in C. From a user > perspective, it is very similar to the FreeBSD rc.d init system, making i= t > easy to use and learn. > > Tested: OpenRC has been used as the init system for TrueOS since October > 2016. > > Ken Moore has an OpenRC vs RC.d comparison which can be found here: > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> > I look forward to discuss the features and capabilities of OpenRC. > This is cool technology. However, what was missing last time was a written plan that could be critiqued for fit with the project's needs. The result of the working group was that this was to be produced, and we'd iterate through it to ease the landing of openrc in the tree. I think there's wide agreement this is cool, and that we'd like tot have both it and rc.d in the tree for a transition period. Absent a plan, though, it's not really possible to say 'go do it' or 'that's insane'. So maybe start there? Warner From owner-freebsd-hackers@freebsd.org Wed Dec 19 14:57:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 250681337C0B for ; Wed, 19 Dec 2018 14:57:30 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0242D83F0D; Wed, 19 Dec 2018 14:57:29 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: by mail-pf1-x429.google.com with SMTP id c123so9954662pfb.0; Wed, 19 Dec 2018 06:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xlUyFZEIAnuy3D7EMD3szzOCL7TKZPoPGZCSDMlKNYM=; b=jZi8AAfblBJKTV+1TYs+ururhnl6kksE1XeTMAmmnotcCcQ2LleZmOCl77D2HCquE7 fzd6Wr7SB0Qd/8SvtTWL4CZy0boeejzEkOy8DaYVAGdSP9ni5a958RGaudxu/bw37Fhk 61Hu2IHj4oZ/SgaGkMkpF6gu22O1cCDqe/BzCzJMeE0ZgF0bXcH+XKfbAW4524LmC7H+ +bCRLAHvq0K2Un+6X+d5cVIfQzbwP4aG8UZ8NSRCCNCG571PDyjH0mY9193IVpkF52JR sOZ3pnTy/pvgNi2X/frFInTxYq5vt79Av9rmJKW/qvRvlHvkekCUqCWUCtE7P2YnLXT/ lWvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xlUyFZEIAnuy3D7EMD3szzOCL7TKZPoPGZCSDMlKNYM=; b=SalKw9bBioge+tyeCmQ/Y59SauJbRZ3CRTo0n/AUsbfyVrkCIV9cOTMf0dRef1SUet Enxc4+Q+x4BCbw4ra8iEzL7PELkFD0inNdb+bfjzKl/nOI8+mj0x2tu5fAahS6R8Bu1a T2WWrj4zhGJFDoq+FmB6yNnP38pD5+WVcBOcNtrRGGxqQbXWzeicWekpMIH10+6owRri JtA/0UwgobzGrzOLyWfFjZ/ZL4mqaEjWB+4qaTxennfvLuq1ZqAP50bNyU7Thftnxabl lvZ/BXHmRi+UyZ6C2eoX1mK+00hnnUAflrvSV8uZWrBQicFl8DPBAValnY2rg4zCsoEJ nAxw== X-Gm-Message-State: AA+aEWYQzeR90bjcyYLEY/+XUuiOoLJRrZe0OrX7n7J2ZTdBtB+KMCL4 0YtIU3jckrMkuC2Bz4SbPls= X-Google-Smtp-Source: AFSGD/WyJPPCxcjfzjL340bOoJx5IIzZSdb8R/5AgoM/WgwO0QB4H7IZDojFQPpHUAv3maK05oByvA== X-Received: by 2002:a63:1a4b:: with SMTP id a11mr19695688pgm.254.1545231447828; Wed, 19 Dec 2018 06:57:27 -0800 (PST) Received: from [192.168.0.123] ([61.6.151.101]) by smtp.gmail.com with ESMTPSA id 125sm22958102pfg.39.2018.12.19.06.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 06:57:26 -0800 (PST) Sender: Martin Wilke From: Martin Wilke Message-Id: <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: OpenRC on FreeBSD Date: Wed, 19 Dec 2018 22:57:23 +0800 In-Reply-To: Cc: "freebsd-hackers@freebsd.org" , Joe Maloney , Marcelo Araujo , ken@ixsystems.com, Kris Moore , Warren Block To: Warner Losh References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: 0242D83F0D X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jZi8AAfb; spf=pass (mx1.freebsd.org: domain of miwifbsd@gmail.com designates 2607:f8b0:4864:20::429 as permitted sender) smtp.mailfrom=miwifbsd@gmail.com X-Spamd-Result: default: False [-1.55 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[15]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.20)[-0.204,0]; FORGED_SENDER(0.30)[miwi@FreeBSD.org,miwifbsd@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[miwi@FreeBSD.org,miwifbsd@gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.64)[ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 14:57:30 -0000 Hi, The missing bit was actually the flag for switching the rc=E2=80=99s = which have been resolved.=20 - Martin > On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >=20 >=20 >=20 > On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke > wrote: > Hi >=20 > I'd like to reopen the discussion for OpenRC on FreeBSD. Basically = this is the second attempt to get it into FreeBSD. >=20 > I've opened a review here with a working patch for CURRENT, > https://reviews.freebsd.org/D18578 = >=20 >=20 > To recap the discussion > * First attempt of RFC in March of 2018: = https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html= = > * Working group at BSDCan: = https://wiki.freebsd.org/DevSummit/201806/OpenRC = >=20 > Here some key points: >=20 > OpenRC provides additional features for service management without = requiring kernel changes or replacing pid 1, unlike launchd and other = solutions. All rc.d scripts have been converted with a few changes, = typically changing the shebang and making sure the start function is = named start(). Most service scripts are simplified, usually needing only = name, command, and, if required, depends statements. >=20 > History: > OpenRC started out as an init system by Roy Marples, developed for the = Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into = Gentoo as baselayout v2, and was then split off as a separate = BSD-licensed project. It is under active development, portable, and = remains BSD licensed today. >=20 > OpenRC and RC: > Both can coexist and be chosen with a setting in /boot/loader.conf. >=20 > OpenRC Features: >=20 > Service supervision and service monitoring: any service can be = supervised. Supervised services that crash are automatically restarted. = The rc-status command shows how many times a service has restarted. >=20 > Device hotplug support and event-driven service management: the = hotplug feature allows devd to take actions when devices are connected. = For example, a USB wifi adapter can create additional network services = when attached. The net-online service can, for example, detect when a = network connection is restored, and restart ntp. >=20 > Network profiles: using stacked runlevels, different profiles can be = established for different networking settings. For instance, different = profiles can be used for wired or wireless networking, or for differing = wireless networks, as well as dependency caching and parallel startup = speed up booting. >=20 > Interactive mode: > The boot process can be run interactively for more effective = debugging. >=20 > OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the = context in which a script is running. There are only three at present: > sysinit (the OpenRC system is starting), boot (start base services = when the computer is booting), and default (normal execution). >=20 > OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, = using ANSI color sequences. This can be disabled. >=20 > Ports: > As of July 2017, iXsystems has created OpenRC versions of port service = scripts for the entire ports tree. These scripts coexist with the rc.d = versions. >=20 > License: > OpenRC is a BSD licensed RC init system written in C. =46rom a user = perspective, it is very similar to the FreeBSD rc.d init system, making = it easy to use and learn. >=20 > Tested: OpenRC has been used as the init system for TrueOS since = October 2016. >=20 > Ken Moore has an OpenRC vs RC.d comparison which can be found here: > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf = = > > I look forward to discuss the features and capabilities of OpenRC. >=20 > This is cool technology. >=20 > However, what was missing last time was a written plan that could be = critiqued for fit with the project's needs. The result of the working = group was that this was to be produced, and we'd iterate through it to = ease the landing of openrc in the tree. I think there's wide agreement = this is cool, and that we'd like tot have both it and rc.d in the tree = for a transition period. Absent a plan, though, it's not really possible = to say 'go do it' or 'that's insane'. >=20 > So maybe start there? >=20 > Warner From owner-freebsd-hackers@freebsd.org Wed Dec 19 14:57:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A63521337C84 for ; Wed, 19 Dec 2018 14:57:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A050B8402D for ; Wed, 19 Dec 2018 14:57:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id w204so11826244qka.2 for ; Wed, 19 Dec 2018 06:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6mooTz4DQ9KBsel+/I4mCLL8RI+DhVlvzegnXZ/g9nY=; b=ahi8pGGa4syrQ4BfUWrqc6TdGqP7Y5VpOoakDGf2qTpLEM5ossdRzXe9cwIfuHUu5t IRLkAxkBw23GsSkm5witK8NuNeo6AhHdPhsDTke2txHUj0PrstT/2zu0SAG8AVQDARlG C9Gpq7KHwCBqjMEXXGCjfEsDVf5RH/wQBZRO7J0O6LhiNIZQVoLJIDYplaZ6T4A8Iij2 x7WPU3cSUrt5ynxLfaoV62y21vr4Vex5kY49Uv97r39PK1NEpmNuxw1uBnVPfg74B5lO nxBY02IEvSBU2HLbZWEIl76mAeYYEHtAP2WrvWvVY69O8sScygzbSxbyKEwtWHGuwjKy bZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6mooTz4DQ9KBsel+/I4mCLL8RI+DhVlvzegnXZ/g9nY=; b=p47NeTXOviFPPSN3Eb2ILlno9gc7DJDCMqcMwKBYEuSOd5j/evpA5HRrwoX+k0Fxzy MnKJdTckvlWAoQJFyVM1X3bH39J5dALInTGV4raE3p2vvQVhV3lFTMSL3IOjYsuCy2uM KJlfos8wn04XfXl6R12YQQsXd7A32Jn1Nx3tixUcngKu1A2lUZ9lPjerM5I4PMWskrHy LmoFVuJ7/IW1nVGSzspO7PAjEy0oLbes5hOiJs0iM5yCzqyhOn/BrzXq6G5GTIu+5CzM wf+Ij8nNn97n2tAs8yT9+JdwJ6TVdwEJpkTubKJy2tMGMmxCiRguNtuGevAJYuNnbD4b 16Sw== X-Gm-Message-State: AA+aEWY4D/U1jtMjc1dLj4x2uWKMSxRbTTjCWGq1TfkdkjywgJhPi+xP hLsWqMZRiF6NX9rA1PfK6n68lvtDZTVaRlX+aNEq/w== X-Google-Smtp-Source: AFSGD/VuZKATk563s3PCFbEHch66zb/mPuxSZuTs+djwTMg+v0T4pRxa3hYnnsOaqThmt2zK5UO1UnNqJs27dn8U2qg= X-Received: by 2002:a37:9201:: with SMTP id u1mr21184234qkd.258.1545231467961; Wed, 19 Dec 2018 06:57:47 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> In-Reply-To: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> From: Warner Losh Date: Wed, 19 Dec 2018 07:57:35 -0700 Message-ID: Subject: Re: OpenRC on FreeBSD To: Martin Wilke Cc: "freebsd-hackers@freebsd.org" , Joe Maloney , Marcelo Araujo , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: A050B8402D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ahi8pGGa X-Spamd-Result: default: False [-4.83 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.69)[-0.687,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[d.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.14)[ip: (-7.47), ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 14:57:49 -0000 On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: > I've opened a review here with a working patch for CURRENT, > https://reviews.freebsd.org/D18578 Please break this review up into manageable sized chunks. There are too many things going on all at once. Warner From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:02:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4639B1337F94 for ; Wed, 19 Dec 2018 15:02:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51D4884431 for ; Wed, 19 Dec 2018 15:02:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id v11so22554047qtc.2 for ; Wed, 19 Dec 2018 07:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0kuUNjm8Mf7N99tLqlZlus8pICK9ud5p4HjPEyjv8Ds=; b=KiDLS97t82EUD3//6L96yLQLVLeO7Kjfl4ZDXhmRSwrnvq7z6dY6vp8KLDibWfD03L x2SDHlz1zYJp8m08K3QGaEddg/xfhwSIyzTi/23madlX+QvRLc+y9lgFyQ8K6LJeO983 ilvYtSP8SgrDF/1EpN0Pdm3CxkvooPw9mcCAWdIUYebvjPtUdj+bMSS0ZJQGhvQxPl1b d6iuysWBLa2xprtF4nqRwFoZMQBWJ1tFpw2Y8HfP8Y4xpZ20rYmVudxw4d2ODuAODbjv hDUrpdXYjcHo+HXy2U4ti+QPBFTobSeIIeGBs1vHOYTFq+1B/LPCH29EOK+jgkMTix6I gr3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0kuUNjm8Mf7N99tLqlZlus8pICK9ud5p4HjPEyjv8Ds=; b=rolmIszTkWyl5DudV1C+VgSKUFm5RUGdpyqXZvjpO2q2gTmdyBi83JeAgNxc2eTK37 o9CsjUUqBMaGpUuR+ZzLQKrTVsKJEP0Th9vpvZNnDYP5DlvKfzA9H13voCJm61tKBic7 X3XXPB/03gn63N5guIhUOyQRtNeuFcyIxPj7OtwtzCNe87r5ILeiTOlvMsPtDQmPuIZM 0AwD9V/A38krEPnYw6KQXWS0fWgU/eESh8uThDlSGHt1rGqTkxQrcpBuRCvRZoEE2Pfn flS1E6zWkw4p3HoAKsuZXWSodkqLMjir2n2RnNkYWLjMgCNiOtIIfeUh9k2GAqXCbNfs eHxg== X-Gm-Message-State: AA+aEWZoXVZfyIeGe+5hz23Tf7nbOI6AnMncLdhlt8EnSbluqd3sHz0M sRzweFQ12tJ5W5Q78dCBLWTet150XiM2QS6yRdQJkQ== X-Google-Smtp-Source: AFSGD/Uscb+QifF2zkF2YNce2fQnR4K3VNMnOAJgaHaYXbBEmmp5LWRO575q9VBjccp28auoipQO/RCzOQgxP+mIsUo= X-Received: by 2002:a0c:9c89:: with SMTP id i9mr21637565qvf.153.1545231730623; Wed, 19 Dec 2018 07:02:10 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> From: Warner Losh Date: Wed, 19 Dec 2018 08:01:56 -0700 Message-ID: Subject: Re: OpenRC on FreeBSD To: Martin Wilke Cc: "freebsd-hackers@freebsd.org" , Joe Maloney , Marcelo Araujo , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: 51D4884431 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=KiDLS97t X-Spamd-Result: default: False [-3.82 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.503,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[3.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.31)[ip: (-8.32), ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:02:12 -0000 On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: > Hi, > > The missing bit was actually the flag for switching the rc=E2=80=99s whic= h have > been resolved. > No. The missing bit is an articulated plan. While that minor sub-issue may be resolved, I see no plan for integration into the tree. Unless the plan is 'commit the review in one big push' which really isn't a viable plan. There are problems with the review (it's too large to be successful, and has issues that need to be discussed in a less massively huge environment). This isn't what the working group's conclusion would be the next steps. The FCP I provided feedback on died. It was a good start on a plan, but was just dropped with my feedback completely ignored. Warner > - Martin > > On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: > > > > On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: > >> Hi >> >> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this >> is the second attempt to get it into FreeBSD. >> >> I've opened a review here with a working patch for CURRENT, >> https://reviews.freebsd.org/D18578 >> >> >> To recap the discussion >> * First attempt of RFC in March of 2018: >> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.ht= ml >> * Working group at BSDCan: >> https://wiki.freebsd.org/DevSummit/201806/OpenRC >> >> Here some key points: >> >> OpenRC provides additional features for service management without >> requiring kernel changes or replacing pid 1, unlike launchd and other >> solutions. All rc.d scripts have been converted with a few changes, >> typically changing the shebang and making sure the start function is nam= ed >> start(). Most service scripts are simplified, usually needing only name, >> command, and, if required, depends statements. >> >> History: >> OpenRC started out as an init system by Roy Marples, developed for the >> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gent= oo >> as baselayout v2, and was then split off as a separate BSD-licensed >> project. It is under active development, portable, and remains BSD licen= sed >> today. >> >> OpenRC and RC: >> Both can coexist and be chosen with a setting in /boot/loader.conf. >> >> OpenRC Features: >> >> Service supervision and service monitoring: any service can be >> supervised. Supervised services that crash are automatically restarted. = The >> rc-status command shows how many times a service has restarted. >> >> Device hotplug support and event-driven service management: the hotplug >> feature allows devd to take actions when devices are connected. For >> example, a USB wifi adapter can create additional network services when >> attached. The net-online service can, for example, detect when a network >> connection is restored, and restart ntp. >> >> Network profiles: using stacked runlevels, different profiles can be >> established for different networking settings. For instance, different >> profiles can be used for wired or wireless networking, or for differing >> wireless networks, as well as dependency caching and parallel startup sp= eed >> up booting. >> >> Interactive mode: >> The boot process can be run interactively for more effective debugging. >> >> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the context= in which a >> script is running. There are only three at present: >> sysinit (the OpenRC system is starting), boot (start base services when >> the computer is booting), and default (normal execution). >> >> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, us= ing ANSI color >> sequences. This can be disabled. >> >> Ports: >> As of July 2017, iXsystems has created OpenRC versions of port service >> scripts for the entire ports tree. These scripts coexist with the rc.d >> versions. >> >> License: >> OpenRC is a BSD licensed RC init system written in C. From a user >> perspective, it is very similar to the FreeBSD rc.d init system, making = it >> easy to use and learn. >> >> Tested: OpenRC has been used as the init system for TrueOS since October >> 2016. >> >> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> >> I look forward to discuss the features and capabilities of OpenRC. >> > > This is cool technology. > > However, what was missing last time was a written plan that could be > critiqued for fit with the project's needs. The result of the working gro= up > was that this was to be produced, and we'd iterate through it to ease the > landing of openrc in the tree. I think there's wide agreement this is coo= l, > and that we'd like tot have both it and rc.d in the tree for a transition > period. Absent a plan, though, it's not really possible to say 'go do it' > or 'that's insane'. > > So maybe start there? > > Warner > > > From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:14:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4E6913386CF for ; Wed, 19 Dec 2018 15:14:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F99C84C37 for ; Wed, 19 Dec 2018 15:14:15 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [IPv6:2001:8b0:151:1:599a:791:35fa:4df2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id C335B1255 for ; Wed, 19 Dec 2018 15:14:07 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk/C335B1255; dkim=none; dkim-atps=neutral Subject: Re: OpenRC on FreeBSD To: freebsd-hackers@freebsd.org References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> From: Matthew Seaman Message-ID: <00f5cd92-05a0-f331-559f-22b1df333dbe@FreeBSD.org> Date: Wed, 19 Dec 2018 15:14:05 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 0F99C84C37 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.86 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.87)[-0.866,0]; ASN(0.00)[asn:20712, ipnet:81.2.64.0/18, country:GB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:14:16 -0000 On 19/12/2018 14:57, Martin Wilke wrote: > Hi, > > The missing bit was actually the flag for switching the rc’s which have been resolved. > > - Martin > >> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >> >> >> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke > wrote: >> Hi >> >> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is the second attempt to get it into FreeBSD. >> >> I've opened a review here with a working patch for CURRENT, >> https://reviews.freebsd.org/D18578 >> >> >> To recap the discussion >> * First attempt of RFC in March of 2018: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html >> * Working group at BSDCan: https://wiki.freebsd.org/DevSummit/201806/OpenRC >> >> Here some key points: >> >> OpenRC provides additional features for service management without requiring kernel changes or replacing pid 1, unlike launchd and other solutions. All rc.d scripts have been converted with a few changes, typically changing the shebang and making sure the start function is named start(). Most service scripts are simplified, usually needing only name, command, and, if required, depends statements. >> >> History: >> OpenRC started out as an init system by Roy Marples, developed for the Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo as baselayout v2, and was then split off as a separate BSD-licensed project. It is under active development, portable, and remains BSD licensed today. >> >> OpenRC and RC: >> Both can coexist and be chosen with a setting in /boot/loader.conf. >> >> OpenRC Features: >> >> Service supervision and service monitoring: any service can be supervised. Supervised services that crash are automatically restarted. The rc-status command shows how many times a service has restarted. >> >> Device hotplug support and event-driven service management: the hotplug feature allows devd to take actions when devices are connected. For example, a USB wifi adapter can create additional network services when attached. The net-online service can, for example, detect when a network connection is restored, and restart ntp. >> >> Network profiles: using stacked runlevels, different profiles can be established for different networking settings. For instance, different profiles can be used for wired or wireless networking, or for differing wireless networks, as well as dependency caching and parallel startup speed up booting. >> >> Interactive mode: >> The boot process can be run interactively for more effective debugging. >> >> OpenRC uses the term “runlevels” to refer to the context in which a script is running. There are only three at present: >> sysinit (the OpenRC system is starting), boot (start base services when the computer is booting), and default (normal execution). >> >> OpenRC, by default, provides a “colorized” text boot, using ANSI color sequences. This can be disabled. >> >> Ports: >> As of July 2017, iXsystems has created OpenRC versions of port service scripts for the entire ports tree. These scripts coexist with the rc.d versions. >> >> License: >> OpenRC is a BSD licensed RC init system written in C. From a user perspective, it is very similar to the FreeBSD rc.d init system, making it easy to use and learn. >> >> Tested: OpenRC has been used as the init system for TrueOS since October 2016. >> >> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf > >> I look forward to discuss the features and capabilities of OpenRC. >> >> This is cool technology. >> >> However, what was missing last time was a written plan that could be critiqued for fit with the project's needs. The result of the working group was that this was to be produced, and we'd iterate through it to ease the landing of openrc in the tree. I think there's wide agreement this is cool, and that we'd like tot have both it and rc.d in the tree for a transition period. Absent a plan, though, it's not really possible to say 'go do it' or 'that's insane'. >> >> So maybe start there? >> >> Warner This would mean that we're going to need both OpenRC and rc.d versions of init scripts in the ports for however long the transition period is. How do you plan on managing that? Will port maintainers be expected to develop and test both flavours of init script? Not all maintainers will have ready access to build/test systems running CURRENT if that's where OpenRC gets deployed initially. Will both types of init script be added to every pkg, or will there be a default per major version? Will this change be MFC'd to 11.x / 12.x ? Also, isn't this a prime candidate for the FCP treatment? Cheers, Matthew From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:46:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE85A1339BD6 for ; Wed, 19 Dec 2018 15:46:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12551865B3 for ; Wed, 19 Dec 2018 15:46:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id q1so11878929qkf.13 for ; Wed, 19 Dec 2018 07:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5eUuVmlYPgwnLXPbYhdRIvKtr6hRnBmYZnhv5IipywU=; b=zX8X6XkLJ4IFxVNHwnvJN8F934Yrm+PoD7Luhmz+WQHioHABJnKhA0XggEbSFFIR64 H3KU6t4cWVo70QqsDAuMGKpdH8GlhJSaYpReZrWLlIGbGlwydKwMFGpBRS57mujpP7bg YsfqZwnjmtnBvBIinrBES3RvNKIu76DPQFTlCQDCdIg6sIA2wwYqz/4od+R1Tn5YyB8h SBt4D+R81BbVVAueXcngmD7vrdK3gKqpFry9ZIvuHss/+slDsjQhxCFRACTMYElVEUpc 9qyrIOXnVAP3OxF8cki2BGcNTMpv1JqSQ1cETEavGvmNafF8W8DxuYJgioq6Ee/bTsuA TSuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5eUuVmlYPgwnLXPbYhdRIvKtr6hRnBmYZnhv5IipywU=; b=XLVEDtSTk4F2L+AmvZneDrqjrcqsJevv26YrMXOfxx4gf0vKClhMmjH2qDIVlDRtKV D7KNa7IKV4nUyvjR4Nlo9vARubsDi4ycOLzCjcDA79VpxatquIyFwRDey4zHQTlCEtej X1cbM7R4/Ih0Cy8sNipBsVSafNnQurnz20rjYw3sZLo+hdFCsQyeFEWhZzwO4jgQa/t4 42bc6fS8hYeMYj2OssWH9hs0Vyt+Vxr7QdL+XwCJmvK9fOPy8C8lxZT9+wVZ4gQwcri5 0//CxdY0grSRMWKezFNzRzLDBtfIqIhACgO0oem6Rj3clopjOw6eGy4x19qZuNfk4XND Yt8g== X-Gm-Message-State: AA+aEWZ13+0zh6f4WyiIj3KqFxYQ8iFVuKejYAzBZ95dXRYuQ+3IWdOS k4i6FGYiHYEN4zSlytxy1G9RJBeeiOnpwum26L3q8g== X-Google-Smtp-Source: AFSGD/W0mT4Vg4US0F4nEnVn44pqNy80FjQBtkwA1hIzaMOPpxqjO9wfeQOJfU8PIctQd471MQjBO+SNQHtYnzpogEI= X-Received: by 2002:a37:c653:: with SMTP id b80mr21953919qkj.245.1545234392502; Wed, 19 Dec 2018 07:46:32 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> <00f5cd92-05a0-f331-559f-22b1df333dbe@FreeBSD.org> In-Reply-To: <00f5cd92-05a0-f331-559f-22b1df333dbe@FreeBSD.org> From: Warner Losh Date: Wed, 19 Dec 2018 08:46:21 -0700 Message-ID: Subject: Re: OpenRC on FreeBSD To: Matthew Seaman Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 12551865B3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=zX8X6XkL X-Spamd-Result: default: False [-4.29 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.81)[-0.809,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[a.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.48)[ip: (-9.17), ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:46:34 -0000 On Wed, Dec 19, 2018 at 8:17 AM Matthew Seaman wrote: > On 19/12/2018 14:57, Martin Wilke wrote: > > Hi, > > > > The missing bit was actually the flag for switching the rc=E2=80=99s wh= ich have > been resolved. > > > > - Martin > > > >> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: > >> > >> > >> > >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke miwi@freebsd.org>> wrote: > >> Hi > >> > >> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically thi= s > is the second attempt to get it into FreeBSD. > >> > >> I've opened a review here with a working patch for CURRENT, > >> https://reviews.freebsd.org/D18578 > >> > >> > >> To recap the discussion > >> * First attempt of RFC in March of 2018: > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > < > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > > > >> * Working group at BSDCan: > https://wiki.freebsd.org/DevSummit/201806/OpenRC < > https://wiki.freebsd.org/DevSummit/201806/OpenRC> > >> > >> Here some key points: > >> > >> OpenRC provides additional features for service management without > requiring kernel changes or replacing pid 1, unlike launchd and other > solutions. All rc.d scripts have been converted with a few changes, > typically changing the shebang and making sure the start function is name= d > start(). Most service scripts are simplified, usually needing only name, > command, and, if required, depends statements. > >> > >> History: > >> OpenRC started out as an init system by Roy Marples, developed for the > Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gento= o > as baselayout v2, and was then split off as a separate BSD-licensed > project. It is under active development, portable, and remains BSD licens= ed > today. > >> > >> OpenRC and RC: > >> Both can coexist and be chosen with a setting in /boot/loader.conf. > >> > >> OpenRC Features: > >> > >> Service supervision and service monitoring: any service can be > supervised. Supervised services that crash are automatically restarted. T= he > rc-status command shows how many times a service has restarted. > >> > >> Device hotplug support and event-driven service management: the hotplu= g > feature allows devd to take actions when devices are connected. For > example, a USB wifi adapter can create additional network services when > attached. The net-online service can, for example, detect when a network > connection is restored, and restart ntp. > >> > >> Network profiles: using stacked runlevels, different profiles can be > established for different networking settings. For instance, different > profiles can be used for wired or wireless networking, or for differing > wireless networks, as well as dependency caching and parallel startup spe= ed > up booting. > >> > >> Interactive mode: > >> The boot process can be run interactively for more effective debugging= . > >> > >> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the conte= xt in which a > script is running. There are only three at present: > >> sysinit (the OpenRC system is starting), boot (start base services whe= n > the computer is booting), and default (normal execution). > >> > >> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, = using ANSI color > sequences. This can be disabled. > >> > >> Ports: > >> As of July 2017, iXsystems has created OpenRC versions of port service > scripts for the entire ports tree. These scripts coexist with the rc.d > versions. > >> > >> License: > >> OpenRC is a BSD licensed RC init system written in C. From a user > perspective, it is very similar to the FreeBSD rc.d init system, making i= t > easy to use and learn. > >> > >> Tested: OpenRC has been used as the init system for TrueOS since > October 2016. > >> > >> Ken Moore has an OpenRC vs RC.d comparison which can be found here: > >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>> > >> I look forward to discuss the features and capabilities of OpenRC. > >> > >> This is cool technology. > >> > >> However, what was missing last time was a written plan that could be > critiqued for fit with the project's needs. The result of the working gro= up > was that this was to be produced, and we'd iterate through it to ease the > landing of openrc in the tree. I think there's wide agreement this is coo= l, > and that we'd like tot have both it and rc.d in the tree for a transition > period. Absent a plan, though, it's not really possible to say 'go do it' > or 'that's insane'. > >> > >> So maybe start there? > >> > >> Warner > > This would mean that we're going to need both OpenRC and rc.d versions > of init scripts in the ports for however long the transition period is. > > How do you plan on managing that? Will port maintainers be expected to > develop and test both flavours of init script? Not all maintainers will > have ready access to build/test systems running CURRENT if that's where > OpenRC gets deployed initially. > > Will both types of init script be added to every pkg, or will there be a > default per major version? Will this change be MFC'd to 11.x / 12.x ? > > Also, isn't this a prime candidate for the FCP treatment? > There was a FCP that started to cover these things. I provided feedback, and then nothing happened. These are exactly the sorts of details that need too be covered somewhere, and the FCP is the logical place. It's why I am asking for there to be a plan. These sorts of policy and logistical details would be in there, and having an agreement in place up front will ease the transition as the project's expectations are clearly articulated. It needn't be perfect, but it has to be something substantially more than the nothing we have today. Warner From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:48:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE95B1339D1B for ; Wed, 19 Dec 2018 15:48:51 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCFD1866EF; Wed, 19 Dec 2018 15:48:50 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-lj1-x244.google.com with SMTP id c19-v6so17823804lja.5; Wed, 19 Dec 2018 07:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=vzdtAWQvoykstzAASQEdvqMQ1CKQmsA9EKIOlhqsgV4=; b=C54kaRnUnB8LSsGI3HFlI1uaiDmCy1HSZKXZZdmow9xeimeTraUwJWMU9lLVzW9K9d p+FZuLQKnS5R2adqTir894wO8v2KohXrixUr4vG8ZbsKSstw4UunDSZp6PWyX4QKZ5Jq C0QWBj0I6isiHj7AXHBi2h9eEv00aIEvewUwoLfgu+NVzLxzcjtkVhlyPu9ZHFoc8xzs i6UwFVUqLHMtGM1lCrdQFhkFoTDWGuEEJPNOmZfFH/gmVpNJMaPr+Ctv4AYaFTSyJ8X+ igex90qJQd1EYRua59Sf2PHlKjdAz61stAWAPxGmThE/xqayXjNUkkbRkuZjxkOks6aG AQiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=vzdtAWQvoykstzAASQEdvqMQ1CKQmsA9EKIOlhqsgV4=; b=s6jNzCXVhgd8DcL0UdQNsUDCXakwK19xmXKVRvgwayIBaPHvI9Ku1yXycg4JsPUW0y gmQYTp4qXsq4GXY9ayQ1jgEEBQ/fHH1jCX/zSqmkD9jv7VBAi7wL/bunS7wR/1GZXZ5a y3ZpRrFh0FzNseIBTnQwA7cooPufJdngeVxksyeNJDkcgfPcuqfJSaKXHG2Pp+Yzv1Q7 c43N3cQb3eWLfNz25yKTmFch62jWEoxh3zC/3WntD3JiCDNQ9Spnog76seGn6n/jVfLz qZq1uXRkL331yclTzy5lS8p87sLgh7lG/FWanb8TMFEZMJmQWFdmhlhbcpz2K3mtT4zy wDMA== X-Gm-Message-State: AA+aEWbxmV5Ifxm3rjn/UPHI5ZQkVgw6ta88tJNvBlj/eG+NC2KttNi2 C3WHRf6AHiPoiMXfSPNzW/6d16J0qOkQwnga0ssJ7Bg/ X-Google-Smtp-Source: AFSGD/XAIyt9gBnlMBrKiEEIURgT1Ig0AqR8si9mkDTmCQRNWj4YsaoiLPSGAOkmmcoyXP4zkKbx+vlbB2UQVM2v4CI= X-Received: by 2002:a2e:8605:: with SMTP id a5-v6mr12871533lji.145.1545234529492; Wed, 19 Dec 2018 07:48:49 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: Reply-To: araujo@freebsd.org From: Marcelo Araujo Date: Wed, 19 Dec 2018 23:48:37 +0800 Message-ID: Subject: Re: OpenRC on FreeBSD To: Warner Losh Cc: Martin Wilke , "freebsd-hackers@freebsd.org" , Joe Maloney , Marcelo Araujo , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: DCFD1866EF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=C54kaRnU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of araujobsdport@gmail.com designates 2a00:1450:4864:20::244 as permitted sender) smtp.mailfrom=araujobsdport@gmail.com X-Spamd-Result: default: False [-2.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[araujo@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_SHORT(-0.07)[-0.075,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.829,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.72)[-0.715,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.06)[ip: (3.36), ipnet: 2a00:1450::/32(-1.59), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:48:52 -0000 Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh escre= veu: > > > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: > >> Hi, >> >> The missing bit was actually the flag for switching the rc=E2=80=99s whi= ch have >> been resolved. >> > > No. The missing bit is an articulated plan. While that minor sub-issue ma= y > be resolved, I see no plan for integration into the tree. Unless the plan > is 'commit the review in one big push' which really isn't a viable plan. > There are problems with the review (it's too large to be successful, and > has issues that need to be discussed in a less massively huge environment= ). > This isn't what the working group's conclusion would be the next steps. T= he > FCP I provided feedback on died. It was a good start on a plan, but was > just dropped with my feedback completely ignored. > Hi Warner, I have asked miwi@ to keep that huge patch on the review because of the lack of coordination and discussion between different groups and also because there is not a clear plan how to bring OpenRC into FreeBSD. So in that way people could try the patch easily without chasing different open reviews, and to be honest, without further discussion regarding to how the transition would happens between rcd and OpenRC, there is nothing much to review there. IMHO, if we want to move forward with OpenRC on FreeBSD we would need a broad discussion, because it will impacts not only the base system but also ports, and also docs needs to get involved because we eventually would need to update our documentation. We have people that wants OpenRC also in other hands we have people that wants to keep things as it is. NOTE: I have updated the review with the same content of this email just to make it registered there. I agree for review purpose small chunks are better, however I don't see yet a plan for all this migration between rcd and OpenRC. Best, > > Warner > > >> - Martin >> >> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >> >> >> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: >> >>> Hi >>> >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this >>> is the second attempt to get it into FreeBSD. >>> >>> I've opened a review here with a working patch for CURRENT, >>> https://reviews.freebsd.org/D18578 >>> >>> >>> To recap the discussion >>> * First attempt of RFC in March of 2018: >>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.h= tml >>> * Working group at BSDCan: >>> https://wiki.freebsd.org/DevSummit/201806/OpenRC >>> >>> Here some key points: >>> >>> OpenRC provides additional features for service management without >>> requiring kernel changes or replacing pid 1, unlike launchd and other >>> solutions. All rc.d scripts have been converted with a few changes, >>> typically changing the shebang and making sure the start function is na= med >>> start(). Most service scripts are simplified, usually needing only name= , >>> command, and, if required, depends statements. >>> >>> History: >>> OpenRC started out as an init system by Roy Marples, developed for the >>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gen= too >>> as baselayout v2, and was then split off as a separate BSD-licensed >>> project. It is under active development, portable, and remains BSD lice= nsed >>> today. >>> >>> OpenRC and RC: >>> Both can coexist and be chosen with a setting in /boot/loader.conf. >>> >>> OpenRC Features: >>> >>> Service supervision and service monitoring: any service can be >>> supervised. Supervised services that crash are automatically restarted.= The >>> rc-status command shows how many times a service has restarted. >>> >>> Device hotplug support and event-driven service management: the hotplug >>> feature allows devd to take actions when devices are connected. For >>> example, a USB wifi adapter can create additional network services when >>> attached. The net-online service can, for example, detect when a networ= k >>> connection is restored, and restart ntp. >>> >>> Network profiles: using stacked runlevels, different profiles can be >>> established for different networking settings. For instance, different >>> profiles can be used for wired or wireless networking, or for differing >>> wireless networks, as well as dependency caching and parallel startup s= peed >>> up booting. >>> >>> Interactive mode: >>> The boot process can be run interactively for more effective debugging. >>> >>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the contex= t in which a >>> script is running. There are only three at present: >>> sysinit (the OpenRC system is starting), boot (start base services when >>> the computer is booting), and default (normal execution). >>> >>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, u= sing ANSI color >>> sequences. This can be disabled. >>> >>> Ports: >>> As of July 2017, iXsystems has created OpenRC versions of port service >>> scripts for the entire ports tree. These scripts coexist with the rc.d >>> versions. >>> >>> License: >>> OpenRC is a BSD licensed RC init system written in C. From a user >>> perspective, it is very similar to the FreeBSD rc.d init system, making= it >>> easy to use and learn. >>> >>> Tested: OpenRC has been used as the init system for TrueOS since Octobe= r >>> 2016. >>> >>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> >>> I look forward to discuss the features and capabilities of OpenRC. >>> >> >> This is cool technology. >> >> However, what was missing last time was a written plan that could be >> critiqued for fit with the project's needs. The result of the working gr= oup >> was that this was to be produced, and we'd iterate through it to ease th= e >> landing of openrc in the tree. I think there's wide agreement this is co= ol, >> and that we'd like tot have both it and rc.d in the tree for a transitio= n >> period. Absent a plan, though, it's not really possible to say 'go do it= ' >> or 'that's insane'. >> >> So maybe start there? >> >> Warner >> >> >> --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:55:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BCC6133A708 for ; Wed, 19 Dec 2018 15:55:53 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD5D886EF0; Wed, 19 Dec 2018 15:55:51 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-ed1-f51.google.com with SMTP id p6so17434418eds.0; Wed, 19 Dec 2018 07:55:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UgH2b+XtQ1b3UGLS9ifENXDp0hfVG3va3RDaG76+LCg=; b=I1xkzFuJLRdLMYTDUv82JNJ+BJCZQYp6nwpdUNxKqzw7UU30yNZ5IojueJsvh4VtZ9 Ijaue8RLZo1BL4s+TcsN0ymapcwWB3MO/y94iw6g13mHPSzqXRxZYenQx2mq/4YUZaQ1 aD2k+3Od+FEga0mtL/q3qUKOs9N+akedvaVGR/3T1XezEdFk4O8m4Aj2SV7zYoLKno7Z f/4yzqNWv2TzDVlXnC6nCwKVeU/eJRtlc0Klq/mhsCXm7PqgomscUeBhYOtRSi8PLUlR YpO0qPokNwUjf14JrhppuIIU3RDrKraqVOjczkrQbMivhsfktcNxvRaQSSOxsaCdUgxI OBPA== X-Gm-Message-State: AA+aEWa0eEESNC++sx+DXEmMUZx8wrurlNCcjzo3IP/DfQUcPsZycBpx 8nCsTIEMQYeuKAHNA6auZi7vC9QlnB4= X-Google-Smtp-Source: AFSGD/XwoBhpX3bF1KpjfRwSmwfUGw6JCn6A3n3Jo+kIF/mzS0Z4bnKtIRdzQaNCZt/PqjxucMw6Jg== X-Received: by 2002:a50:8bc9:: with SMTP id n9mr20552733edn.41.1545234950089; Wed, 19 Dec 2018 07:55:50 -0800 (PST) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id n3-v6sm2714614ejd.35.2018.12.19.07.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 07:55:49 -0800 (PST) Received: by mail-wr1-f47.google.com with SMTP id j2so20062638wrw.1; Wed, 19 Dec 2018 07:55:49 -0800 (PST) X-Received: by 2002:a5d:6b09:: with SMTP id v9mr20231393wrw.304.1545234949268; Wed, 19 Dec 2018 07:55:49 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: From: Matt Joras Date: Wed, 19 Dec 2018 09:55:37 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenRC on FreeBSD To: araujo@freebsd.org Cc: Warner Losh , Joe Maloney , ken@ixsystems.com, Martin Wilke , "freebsd-hackers@freebsd.org" , Warren Block , Kris Moore X-Rspamd-Queue-Id: DD5D886EF0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mattjoras@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=mattjoras@gmail.com X-Spamd-Result: default: False [-3.76 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; URI_COUNT_ODD(1.00)[15]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.93)[-0.927,0]; RCPT_COUNT_SEVEN(0.00)[8]; FORGED_SENDER(0.30)[mjoras@freebsd.org,mattjoras@gmail.com]; IP_SCORE(-1.82)[ip: (-4.05), ipnet: 209.85.128.0/17(-3.59), asn: 15169(-1.39), country: US(-0.08)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_NEQ_ENVFROM(0.00)[mjoras@freebsd.org,mattjoras@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[51.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[51.208.85.209.rep.mailspike.net : 127.0.0.17] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:55:53 -0000 On Wed, Dec 19, 2018, 9:49 AM Marcelo Araujo Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh esc= reveu: > > > > > > > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: > > > >> Hi, > >> > >> The missing bit was actually the flag for switching the rc=E2=80=99s w= hich have > >> been resolved. > >> > > > > No. The missing bit is an articulated plan. While that minor sub-issue > may > > be resolved, I see no plan for integration into the tree. Unless the pl= an > > is 'commit the review in one big push' which really isn't a viable plan= . > > There are problems with the review (it's too large to be successful, an= d > > has issues that need to be discussed in a less massively huge > environment). > > This isn't what the working group's conclusion would be the next steps. > The > > FCP I provided feedback on died. It was a good start on a plan, but was > > just dropped with my feedback completely ignored. > > > > Hi Warner, > > I have asked miwi@ to keep that huge patch on the review because of the > lack of coordination and discussion between different groups and also > because there is not a clear plan how to bring OpenRC into FreeBSD. So in > that way people could try the patch easily without chasing different open > reviews, and to be honest, without further discussion regarding to how th= e > transition would happens between rcd and OpenRC, there is nothing much to > review there. > Just making a small suggestion here, does our Phabricator support "stacked" diffs? That is the defacto way for a group of diffs on Phabricator to be logically grouped so they are easy to navigate and review separately. > IMHO, if we want to move forward with OpenRC on FreeBSD we would need a > broad discussion, because it will impacts not only the base system but al= so > ports, and also docs needs to get involved because we eventually would ne= ed > to update our documentation. We have people that wants OpenRC also in oth= er > hands we have people that wants to keep things as it is. > > NOTE: I have updated the review with the same content of this email just = to > make it registered there. > > I agree for review purpose small chunks are better, however I don't see y= et > a plan for all this migration between rcd and OpenRC. > Best, > > > > > > Warner > > > > > >> - Martin > >> > >> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: > >> > >> > >> > >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: > >> > >>> Hi > >>> > >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically th= is > >>> is the second attempt to get it into FreeBSD. > >>> > >>> I've opened a review here with a working patch for CURRENT, > >>> https://reviews.freebsd.org/D18578 > >>> > >>> > >>> To recap the discussion > >>> * First attempt of RFC in March of 2018: > >>> > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > >>> * Working group at BSDCan: > >>> https://wiki.freebsd.org/DevSummit/201806/OpenRC > >>> > >>> Here some key points: > >>> > >>> OpenRC provides additional features for service management without > >>> requiring kernel changes or replacing pid 1, unlike launchd and other > >>> solutions. All rc.d scripts have been converted with a few changes, > >>> typically changing the shebang and making sure the start function is > named > >>> start(). Most service scripts are simplified, usually needing only > name, > >>> command, and, if required, depends statements. > >>> > >>> History: > >>> OpenRC started out as an init system by Roy Marples, developed for th= e > >>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into > Gentoo > >>> as baselayout v2, and was then split off as a separate BSD-licensed > >>> project. It is under active development, portable, and remains BSD > licensed > >>> today. > >>> > >>> OpenRC and RC: > >>> Both can coexist and be chosen with a setting in /boot/loader.conf. > >>> > >>> OpenRC Features: > >>> > >>> Service supervision and service monitoring: any service can be > >>> supervised. Supervised services that crash are automatically > restarted. The > >>> rc-status command shows how many times a service has restarted. > >>> > >>> Device hotplug support and event-driven service management: the hotpl= ug > >>> feature allows devd to take actions when devices are connected. For > >>> example, a USB wifi adapter can create additional network services wh= en > >>> attached. The net-online service can, for example, detect when a > network > >>> connection is restored, and restart ntp. > >>> > >>> Network profiles: using stacked runlevels, different profiles can be > >>> established for different networking settings. For instance, differen= t > >>> profiles can be used for wired or wireless networking, or for differi= ng > >>> wireless networks, as well as dependency caching and parallel startup > speed > >>> up booting. > >>> > >>> Interactive mode: > >>> The boot process can be run interactively for more effective debuggin= g. > >>> > >>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the cont= ext in which a > >>> script is running. There are only three at present: > >>> sysinit (the OpenRC system is starting), boot (start base services wh= en > >>> the computer is booting), and default (normal execution). > >>> > >>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot,= using ANSI color > >>> sequences. This can be disabled. > >>> > >>> Ports: > >>> As of July 2017, iXsystems has created OpenRC versions of port servic= e > >>> scripts for the entire ports tree. These scripts coexist with the rc.= d > >>> versions. > >>> > >>> License: > >>> OpenRC is a BSD licensed RC init system written in C. From a user > >>> perspective, it is very similar to the FreeBSD rc.d init system, > making it > >>> easy to use and learn. > >>> > >>> Tested: OpenRC has been used as the init system for TrueOS since > October > >>> 2016. > >>> > >>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: > >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> > >>> I look forward to discuss the features and capabilities of OpenRC. > >>> > >> > >> This is cool technology. > >> > >> However, what was missing last time was a written plan that could be > >> critiqued for fit with the project's needs. The result of the working > group > >> was that this was to be produced, and we'd iterate through it to ease > the > >> landing of openrc in the tree. I think there's wide agreement this is > cool, > >> and that we'd like tot have both it and rc.d in the tree for a > transition > >> period. Absent a plan, though, it's not really possible to say 'go do > it' > >> or 'that's insane'. > >> > >> So maybe start there? > >> > >> Warner > >> > >> > >> > > -- > > -- > Marcelo Araujo (__)araujo@FreeBSD.org > \\\'',)http://www.FreeBSD.org \/ \ ^ > Power To Server. .\. /_) > _______________________________________________ > 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 Dec 19 15:58:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58FB6133A870 for ; Wed, 19 Dec 2018 15:58:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A74987055 for ; Wed, 19 Dec 2018 15:58:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lj1-x22f.google.com with SMTP id t18-v6so5837002ljd.4 for ; Wed, 19 Dec 2018 07:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LfiB1E7oXQZNg0VydQricVA6AmH9oltUPI9Rz4d8+1Y=; b=pqtTZu6gqS8dvGRa8BVpLo2a9kMTMjdfYwcsyT0HopsBlhqJI3cqNy9ZMOgBb1o+YJ siVA7O0tEvak57hz+iH6TWi62FR0gGzvG5v5EASxxJ10Amheu6Iz1y2jopewHtT4woyd gFzPOiaaxUnZZ+TPmM5k7pLqsgKQ2iaANSMAijWEQdj2p8jTZ4rNaBrSxrkq0iGu9BgW X7hop30qBeIPgXac6NUPTxkWcn9Grdq7wQ4Sv489BHejyuHO6A1WBIg91oQfKthClaGG YyouZde5FkqScAVm8DtsG4MQZP+rIIHTUdf6a0hnTA9PiTZI6/G5Uq/p8y/B83ZEuthj lc3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LfiB1E7oXQZNg0VydQricVA6AmH9oltUPI9Rz4d8+1Y=; b=fovCnXvEDrh6c8x4WxmHyERS9dprQm/jeEGs8L6CqKWQvROcaNXV6gPIcrIctCID4r tNSXW8lA8T252NajvNndc/So8MtMZxpZEwYNIDWFBBMHX3rSwzp+HCuggJIO5kz1JFma Lhs8MpHvhu+a1MgEhfY2Pcorodh6kWS1ac8wHDHyt/Jb8PwVUyywsWSJ2x9ZDuxY+spx 9s1M/msW/QbhyOdKMLmVVhNcFnM1IfBRsT+s+9SEcVaQQCqGZeXeTC5mM3cd+9Kra70x UrDQd7rYZq6/WRGaSWMdQTK939YGRbQctvN3ZxnYyZ5DB9T7JZPqjOc+uwAa+lVjDtGr Ns8Q== X-Gm-Message-State: AA+aEWYs6jOaelVM9/9qAxG1qyGGmLq4kLpMAcNnEzQgEecUfKV/814b AhSmCq5+y/7m+G3+xGGhxjaClajXE1yGFb5u5ITw3A== X-Google-Smtp-Source: AFSGD/VWvuDw4xXgrJTX094+MCMhxu7uDd8dUpc6/6f5lDYmqK54gR+5rc5jy12EzjvFQbiErAzMyL7S9i1qOzCITUs= X-Received: by 2002:a2e:449b:: with SMTP id b27-v6mr5651385ljf.47.1545235096369; Wed, 19 Dec 2018 07:58:16 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Wed, 19 Dec 2018 08:58:04 -0700 Message-ID: Subject: Re: OpenRC on FreeBSD To: Marcelo Araujo Cc: Martin Wilke , "freebsd-hackers@freebsd.org" , Joe Maloney , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: 3A74987055 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=pqtTZu6g X-Spamd-Result: default: False [-5.47 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[f.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.49)[ip: (-9.40), ipnet: 2a00:1450::/32(-1.59), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:58:19 -0000 On Wed, Dec 19, 2018 at 8:48 AM Marcelo Araujo wrote: > > > Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh esc= reveu: > >> >> >> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: >> >>> Hi, >>> >>> The missing bit was actually the flag for switching the rc=E2=80=99s wh= ich have >>> been resolved. >>> >> >> No. The missing bit is an articulated plan. While that minor sub-issue >> may be resolved, I see no plan for integration into the tree. Unless the >> plan is 'commit the review in one big push' which really isn't a viable >> plan. There are problems with the review (it's too large to be successfu= l, >> and has issues that need to be discussed in a less massively huge >> environment). This isn't what the working group's conclusion would be th= e >> next steps. The FCP I provided feedback on died. It was a good start on = a >> plan, but was just dropped with my feedback completely ignored. >> > > Hi Warner, > > I have asked miwi@ to keep that huge patch on the review because of the > lack of coordination and discussion between different groups and also > because there is not a clear plan how to bring OpenRC into FreeBSD. So in > that way people could try the patch easily without chasing different open > reviews, and to be honest, without further discussion regarding to how th= e > transition would happens between rcd and OpenRC, there is nothing much to > review there. > > IMHO, if we want to move forward with OpenRC on FreeBSD we would need a > broad discussion, because it will impacts not only the base system but al= so > ports, and also docs needs to get involved because we eventually would ne= ed > to update our documentation. We have people that wants OpenRC also in oth= er > hands we have people that wants to keep things as it is. > > NOTE: I have updated the review with the same content of this email just > to make it registered there. > > I agree for review purpose small chunks are better, however I don't see > yet a plan for all this migration between rcd and OpenRC. > Reviews aren't patch delivery devices. They are to review the code present. You can't do that with the super-monster review that's there. If you want to have one patch file, that's great! You can always link each review to that patch file or have a dummy master review to do that. Reviews this large in the past have failed to reach consensus and frustrated the authors. I'd kinda like to avoid that outcome here because I really want to see forward progress here. Maybe once we've hashed out the plan on integration, we can move to breaking up the patch into manageable pieces. So what's my next step for saying that the verbatim copy of devd.conf into devd-openrc.conf is not going to work, that problem needs to be solved properly without such copying. Eg, moving the openrc dependency out of devd.conf and into pccard-ether or its replacement to hide this detail. I don't know if this is emblematic of a poor design, or just a sloppy short-cut. Warner > Best, > > >> >> Warner >> >> >>> - Martin >>> >>> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >>> >>> >>> >>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: >>> >>>> Hi >>>> >>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically thi= s >>>> is the second attempt to get it into FreeBSD. >>>> >>>> I've opened a review here with a working patch for CURRENT, >>>> https://reviews.freebsd.org/D18578 >>>> >>>> >>>> To recap the discussion >>>> * First attempt of RFC in March of 2018: >>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.= html >>>> * Working group at BSDCan: >>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC >>>> >>>> Here some key points: >>>> >>>> OpenRC provides additional features for service management without >>>> requiring kernel changes or replacing pid 1, unlike launchd and other >>>> solutions. All rc.d scripts have been converted with a few changes, >>>> typically changing the shebang and making sure the start function is n= amed >>>> start(). Most service scripts are simplified, usually needing only nam= e, >>>> command, and, if required, depends statements. >>>> >>>> History: >>>> OpenRC started out as an init system by Roy Marples, developed for the >>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Ge= ntoo >>>> as baselayout v2, and was then split off as a separate BSD-licensed >>>> project. It is under active development, portable, and remains BSD lic= ensed >>>> today. >>>> >>>> OpenRC and RC: >>>> Both can coexist and be chosen with a setting in /boot/loader.conf. >>>> >>>> OpenRC Features: >>>> >>>> Service supervision and service monitoring: any service can be >>>> supervised. Supervised services that crash are automatically restarted= . The >>>> rc-status command shows how many times a service has restarted. >>>> >>>> Device hotplug support and event-driven service management: the hotplu= g >>>> feature allows devd to take actions when devices are connected. For >>>> example, a USB wifi adapter can create additional network services whe= n >>>> attached. The net-online service can, for example, detect when a netwo= rk >>>> connection is restored, and restart ntp. >>>> >>>> Network profiles: using stacked runlevels, different profiles can be >>>> established for different networking settings. For instance, different >>>> profiles can be used for wired or wireless networking, or for differin= g >>>> wireless networks, as well as dependency caching and parallel startup = speed >>>> up booting. >>>> >>>> Interactive mode: >>>> The boot process can be run interactively for more effective debugging= . >>>> >>>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the conte= xt in which a >>>> script is running. There are only three at present: >>>> sysinit (the OpenRC system is starting), boot (start base services whe= n >>>> the computer is booting), and default (normal execution). >>>> >>>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, = using ANSI color >>>> sequences. This can be disabled. >>>> >>>> Ports: >>>> As of July 2017, iXsystems has created OpenRC versions of port service >>>> scripts for the entire ports tree. These scripts coexist with the rc.d >>>> versions. >>>> >>>> License: >>>> OpenRC is a BSD licensed RC init system written in C. From a user >>>> perspective, it is very similar to the FreeBSD rc.d init system, makin= g it >>>> easy to use and learn. >>>> >>>> Tested: OpenRC has been used as the init system for TrueOS since >>>> October 2016. >>>> >>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> >>>> I look forward to discuss the features and capabilities of OpenRC. >>>> >>> >>> This is cool technology. >>> >>> However, what was missing last time was a written plan that could be >>> critiqued for fit with the project's needs. The result of the working g= roup >>> was that this was to be produced, and we'd iterate through it to ease t= he >>> landing of openrc in the tree. I think there's wide agreement this is c= ool, >>> and that we'd like tot have both it and rc.d in the tree for a transiti= on >>> period. Absent a plan, though, it's not really possible to say 'go do i= t' >>> or 'that's insane'. >>> >>> So maybe start there? >>> >>> Warner >>> >>> >>> > > -- > > -- > Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.Fr= eeBSD.org \/ \ ^ > Power To Server. .\. /_) > > From owner-freebsd-hackers@freebsd.org Wed Dec 19 15:58:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B5AC133A8A3 for ; Wed, 19 Dec 2018 15:58:39 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5620587077; Wed, 19 Dec 2018 15:58:38 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-lj1-x243.google.com with SMTP id k19-v6so17821898lji.11; Wed, 19 Dec 2018 07:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=YgzwF7UXKX740IkhO7MvIU2h/aLY6fO1EU9iwxdW4tA=; b=JZxFCE2ET8GUpQEIMeKWXeyFiLNovDQZjDiQafefOUDyA5N2U9oyfpS8YbU0r+qVIp /Tmv0taatiCxo6bLX1R/fHa9Kmo4fw51wyZZZEObMqgCnSeSJylEStj40kh3uXtlR6lX UhxtaqG0425qypKYz1dEMxZ4fOVBrH1KqInR8L5ByHrmPPSzUTDLpC4RCIaUoYhA11RW j2+Hg1Lm0p3lxUPPqzLymyALxKYwotio+mqbfPiHCfJ82QqAhq31s0huc5jItv4UB3Pu CrZo+mEkDcG4NRbocFRqhU6WvLU7pWAYWcHlv9Ddvp5+aL00CSSZ2Rei7K376990wXRt twXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=YgzwF7UXKX740IkhO7MvIU2h/aLY6fO1EU9iwxdW4tA=; b=Eyic7Hf85QYeA3TKXdq8iUfXLCTAIOKkWN2FzbWR2vsk6xky//Mo9O5bJ+orE0nIzQ mNTqIskTMqvOCP/3fgCUhjy+Cep0BBExCkYIWOUN87sY4DAwAICdO+dQuU7Vi1XSMNjl f0CfVihtHNr9D1weLIInE2LJFitJtknVndHfOqRQ2N6RidAPNjKqFZy9us+E0b3IK5it KOmoXlJZ9A1Z5FX7xgiQu0OQsLrSfkPQie/Z37xjRVE4bDRVYP0BBQSLZQS2F1S/x7sF ok/IWk23xk20cHn5DM4l8zpVrFtk9dp4R1mWKpavj/dpKoxWdIiz/nHzGdu9tJ/yMqD/ Hd5Q== X-Gm-Message-State: AA+aEWbgRjuRyd4QtBoRLwMv1v0rgfwDYnE45q5kXCRBmtR2+FiOQN2S lX6RD0eFYMIzixijmyZieOUNJIs0swDEeeTAN60mvQ== X-Google-Smtp-Source: AFSGD/VN7WxutfGXF7vMiMIa5avjCDfokwWAclRQC6VL+4ELdbDP1ywiv0VTjYscRMuz1gUvrpdVBswvxO57YWQq8/k= X-Received: by 2002:a2e:5303:: with SMTP id h3-v6mr5620897ljb.35.1545235116547; Wed, 19 Dec 2018 07:58:36 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: Reply-To: araujo@freebsd.org From: Marcelo Araujo Date: Wed, 19 Dec 2018 23:58:24 +0800 Message-ID: Subject: Re: OpenRC on FreeBSD To: Matt Joras Cc: Marcelo Araujo , Warner Losh , Joe Maloney , ken@ixsystems.com, Martin Wilke , "freebsd-hackers@freebsd.org" , Warren Block , Kris Moore X-Rspamd-Queue-Id: 5620587077 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JZxFCE2E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of araujobsdport@gmail.com designates 2a00:1450:4864:20::243 as permitted sender) smtp.mailfrom=araujobsdport@gmail.com X-Spamd-Result: default: False [-1.33 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[araujo@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[9]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.537,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.31)[0.309,0]; NEURAL_HAM_LONG(-0.29)[-0.285,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.20)[ip: (4.05), ipnet: 2a00:1450::/32(-1.59), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:58:39 -0000 Em qua, 19 de dez de 2018 =C3=A0s 23:55, Matt Joras escreveu: > > > On Wed, Dec 19, 2018, 9:49 AM Marcelo Araujo wrote: > >> Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh >> escreveu: >> >> > >> > >> > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: >> > >> >> Hi, >> >> >> >> The missing bit was actually the flag for switching the rc=E2=80=99s = which have >> >> been resolved. >> >> >> > >> > No. The missing bit is an articulated plan. While that minor sub-issue >> may >> > be resolved, I see no plan for integration into the tree. Unless the >> plan >> > is 'commit the review in one big push' which really isn't a viable pla= n. >> > There are problems with the review (it's too large to be successful, a= nd >> > has issues that need to be discussed in a less massively huge >> environment). >> > This isn't what the working group's conclusion would be the next steps= . >> The >> > FCP I provided feedback on died. It was a good start on a plan, but wa= s >> > just dropped with my feedback completely ignored. >> > >> >> Hi Warner, >> >> I have asked miwi@ to keep that huge patch on the review because of the >> lack of coordination and discussion between different groups and also >> because there is not a clear plan how to bring OpenRC into FreeBSD. So i= n >> that way people could try the patch easily without chasing different ope= n >> reviews, and to be honest, without further discussion regarding to how t= he >> transition would happens between rcd and OpenRC, there is nothing much t= o >> review there. >> > > Just making a small suggestion here, does our Phabricator support > "stacked" diffs? That is the defacto way for a group of diffs on > Phabricator to be logically grouped so they are easy to navigate and revi= ew > separately. > It does support Parent and Child reviews. > > >> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a >> broad discussion, because it will impacts not only the base system but >> also >> ports, and also docs needs to get involved because we eventually would >> need >> to update our documentation. We have people that wants OpenRC also in >> other >> hands we have people that wants to keep things as it is. >> >> NOTE: I have updated the review with the same content of this email just >> to >> make it registered there. >> >> I agree for review purpose small chunks are better, however I don't see >> yet >> a plan for all this migration between rcd and OpenRC. >> Best, >> >> >> > >> > Warner >> > >> > >> >> - Martin >> >> >> >> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >> >> >> >> >> >> >> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote= : >> >> >> >>> Hi >> >>> >> >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically >> this >> >>> is the second attempt to get it into FreeBSD. >> >>> >> >>> I've opened a review here with a working patch for CURRENT, >> >>> https://reviews.freebsd.org/D18578 >> >>> >> >>> >> >>> To recap the discussion >> >>> * First attempt of RFC in March of 2018: >> >>> >> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.ht= ml >> >>> * Working group at BSDCan: >> >>> https://wiki.freebsd.org/DevSummit/201806/OpenRC >> >>> >> >>> Here some key points: >> >>> >> >>> OpenRC provides additional features for service management without >> >>> requiring kernel changes or replacing pid 1, unlike launchd and othe= r >> >>> solutions. All rc.d scripts have been converted with a few changes, >> >>> typically changing the shebang and making sure the start function is >> named >> >>> start(). Most service scripts are simplified, usually needing only >> name, >> >>> command, and, if required, depends statements. >> >>> >> >>> History: >> >>> OpenRC started out as an init system by Roy Marples, developed for t= he >> >>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into >> Gentoo >> >>> as baselayout v2, and was then split off as a separate BSD-licensed >> >>> project. It is under active development, portable, and remains BSD >> licensed >> >>> today. >> >>> >> >>> OpenRC and RC: >> >>> Both can coexist and be chosen with a setting in /boot/loader.conf. >> >>> >> >>> OpenRC Features: >> >>> >> >>> Service supervision and service monitoring: any service can be >> >>> supervised. Supervised services that crash are automatically >> restarted. The >> >>> rc-status command shows how many times a service has restarted. >> >>> >> >>> Device hotplug support and event-driven service management: the >> hotplug >> >>> feature allows devd to take actions when devices are connected. For >> >>> example, a USB wifi adapter can create additional network services >> when >> >>> attached. The net-online service can, for example, detect when a >> network >> >>> connection is restored, and restart ntp. >> >>> >> >>> Network profiles: using stacked runlevels, different profiles can be >> >>> established for different networking settings. For instance, differe= nt >> >>> profiles can be used for wired or wireless networking, or for >> differing >> >>> wireless networks, as well as dependency caching and parallel startu= p >> speed >> >>> up booting. >> >>> >> >>> Interactive mode: >> >>> The boot process can be run interactively for more effective >> debugging. >> >>> >> >>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the con= text in which a >> >>> script is running. There are only three at present: >> >>> sysinit (the OpenRC system is starting), boot (start base services >> when >> >>> the computer is booting), and default (normal execution). >> >>> >> >>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot= , using ANSI color >> >>> sequences. This can be disabled. >> >>> >> >>> Ports: >> >>> As of July 2017, iXsystems has created OpenRC versions of port servi= ce >> >>> scripts for the entire ports tree. These scripts coexist with the rc= .d >> >>> versions. >> >>> >> >>> License: >> >>> OpenRC is a BSD licensed RC init system written in C. From a user >> >>> perspective, it is very similar to the FreeBSD rc.d init system, >> making it >> >>> easy to use and learn. >> >>> >> >>> Tested: OpenRC has been used as the init system for TrueOS since >> October >> >>> 2016. >> >>> >> >>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> >> >>> I look forward to discuss the features and capabilities of OpenRC. >> >>> >> >> >> >> This is cool technology. >> >> >> >> However, what was missing last time was a written plan that could be >> >> critiqued for fit with the project's needs. The result of the working >> group >> >> was that this was to be produced, and we'd iterate through it to ease >> the >> >> landing of openrc in the tree. I think there's wide agreement this is >> cool, >> >> and that we'd like tot have both it and rc.d in the tree for a >> transition >> >> period. Absent a plan, though, it's not really possible to say 'go do >> it' >> >> or 'that's insane'. >> >> >> >> So maybe start there? >> >> >> >> Warner >> >> >> >> >> >> >> >> -- >> >> -- >> Marcelo Araujo (__)araujo@FreeBSD.org >> \\\'',)http://www.FreeBSD.org \/ \ ^ >> Power To Server. .\. /_) >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g >> " >> > --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-hackers@freebsd.org Wed Dec 19 16:01:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3B54133AADF for ; Wed, 19 Dec 2018 16:01:35 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CF4F87501; Wed, 19 Dec 2018 16:01:34 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-lf1-x141.google.com with SMTP id b20so15404927lfa.12; Wed, 19 Dec 2018 08:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=nTtGw+qo81m+Or0fv3efs/VEmRRxULvSIRF47QasOEc=; b=Bh1Qc3dLKTNx1xoMj+nnj1bH1o9YLmvhEbcpjkZneMWi62sS51MwUknaShGgHBtyKg cyNzVvT2bq/x7IFe5lEb/HNTB95XGkrmRrcHbv6KbwYbMfOwYcoz0jWDmuSzRBcGDvrW JlyBRNqWCNOHoEafmEvRHedTAFQv503daHwc4mTQl8xYVI6mg0CvnZSFOtic+TaNYNT1 o1BDYzFhABjkKgBapk+ekcI3ej3hIn2ks/NXAn5ZNuNn5B4pe1zS1qAlUNij1mu4zL3C Cz4pS14zqbTu8sPtHA9qrZP2IR0qijVWOdYgEf/OhJL7Nj5BqrZ/BkKPw6GUAhDtrmsw lJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=nTtGw+qo81m+Or0fv3efs/VEmRRxULvSIRF47QasOEc=; b=jNuvLOBvoul0PUmxnrCmLPj4R1gtZqU7wymj7/daj55O6F0ZWYQjF90drfSgat4PSe 7S8oYavKgTiyEHa8ovhEfNfar/x2ojE/nL5sOHssUDChRZgwZW4KnlIx3LiPCbdzVgbK jbRT2yYbZ/lwCvLPEWlb73d5YtlFtfILNPTLfyckFxh6Sx3ks+YnUnZlmkxWjAdAw+no gnEk9UyE8TwY0GCkVdIHhqt0ISQvkEO+aMMd3jKRbDeGjhUBC5bhaSlXHHzB2Qp222Mp ITxv0ogVHnll3aBZLZ+ZO2OpFLUTQ1XJOct2giG8NDlMVwW/vOq0ot4F84kYYGj87p3V XJQg== X-Gm-Message-State: AA+aEWZm87f2P+LpP73uBo7S0KFoxlHxHWHmEioxPpINr5jHbAbmP0J5 QuQw+DuKkY2ejvBC5C3XhgwaEKwo4bjom6tImfM= X-Google-Smtp-Source: AFSGD/Vw3H1PVMw7wn7aUyEW4/Y/FlPG7xeUyTCl5jwXrIdaRjv30U2VmfhiSDGCNdubcjl9syRcd7fBPca+pzTnt78= X-Received: by 2002:a19:2755:: with SMTP id n82mr12128644lfn.94.1545235293107; Wed, 19 Dec 2018 08:01:33 -0800 (PST) MIME-Version: 1.0 References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> In-Reply-To: Reply-To: araujo@freebsd.org From: Marcelo Araujo Date: Thu, 20 Dec 2018 00:01:21 +0800 Message-ID: Subject: Re: OpenRC on FreeBSD To: Warner Losh Cc: Marcelo Araujo , Martin Wilke , "freebsd-hackers@freebsd.org" , Joe Maloney , ken@ixsystems.com, Kris Moore , Warren Block X-Rspamd-Queue-Id: 8CF4F87501 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Bh1Qc3dL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of araujobsdport@gmail.com designates 2a00:1450:4864:20::141 as permitted sender) smtp.mailfrom=araujobsdport@gmail.com X-Spamd-Result: default: False [0.05 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[araujo@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[15]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[8]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.42)[-0.415,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.60)[0.605,0]; NEURAL_HAM_LONG(-0.25)[-0.253,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.13)[ip: (3.70), ipnet: 2a00:1450::/32(-1.59), asn: 15169(-1.39), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 16:01:36 -0000 Em qua, 19 de dez de 2018 =C3=A0s 23:58, Warner Losh escre= veu: > > > On Wed, Dec 19, 2018 at 8:48 AM Marcelo Araujo > wrote: > >> >> >> Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh >> escreveu: >> >>> >>> >>> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke wrote: >>> >>>> Hi, >>>> >>>> The missing bit was actually the flag for switching the rc=E2=80=99s w= hich have >>>> been resolved. >>>> >>> >>> No. The missing bit is an articulated plan. While that minor sub-issue >>> may be resolved, I see no plan for integration into the tree. Unless th= e >>> plan is 'commit the review in one big push' which really isn't a viable >>> plan. There are problems with the review (it's too large to be successf= ul, >>> and has issues that need to be discussed in a less massively huge >>> environment). This isn't what the working group's conclusion would be t= he >>> next steps. The FCP I provided feedback on died. It was a good start on= a >>> plan, but was just dropped with my feedback completely ignored. >>> >> >> Hi Warner, >> >> I have asked miwi@ to keep that huge patch on the review because of the >> lack of coordination and discussion between different groups and also >> because there is not a clear plan how to bring OpenRC into FreeBSD. So i= n >> that way people could try the patch easily without chasing different ope= n >> reviews, and to be honest, without further discussion regarding to how t= he >> transition would happens between rcd and OpenRC, there is nothing much t= o >> review there. >> >> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a >> broad discussion, because it will impacts not only the base system but a= lso >> ports, and also docs needs to get involved because we eventually would n= eed >> to update our documentation. We have people that wants OpenRC also in ot= her >> hands we have people that wants to keep things as it is. >> >> NOTE: I have updated the review with the same content of this email just >> to make it registered there. >> >> I agree for review purpose small chunks are better, however I don't see >> yet a plan for all this migration between rcd and OpenRC. >> > > Reviews aren't patch delivery devices. They are to review the code > present. You can't do that with the super-monster review that's there. If > you want to have one patch file, that's great! You can always link each > review to that patch file or have a dummy master review to do that. Revie= ws > this large in the past have failed to reach consensus and frustrated the > authors. I'd kinda like to avoid that outcome here because I really want = to > see forward progress here. Maybe once we've hashed out the plan on > integration, we can move to breaking up the patch into manageable pieces. > Agree with that, as soon as there is a plan on integration, breaking up the patch will be easier for review! But without a plan, as I said, there is nothing to review to be honest. :( > > So what's my next step for saying that the verbatim copy of devd.conf int= o > devd-openrc.conf is not going to work, that problem needs to be solved > properly without such copying. Eg, moving the openrc dependency out of > devd.conf and into pccard-ether or its replacement to hide this detail. = I > don't know if this is emblematic of a poor design, or just a sloppy > short-cut. > > Warner > > >> Best, >> >> >>> >>> Warner >>> >>> >>>> - Martin >>>> >>>> On 19 Dec 2018, at 10:51 PM, Warner Losh wrote: >>>> >>>> >>>> >>>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke wrote: >>>> >>>>> Hi >>>>> >>>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically >>>>> this is the second attempt to get it into FreeBSD. >>>>> >>>>> I've opened a review here with a working patch for CURRENT, >>>>> https://reviews.freebsd.org/D18578 >>>>> >>>>> >>>>> To recap the discussion >>>>> * First attempt of RFC in March of 2018: >>>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358= .html >>>>> * Working group at BSDCan: >>>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC >>>>> >>>>> Here some key points: >>>>> >>>>> OpenRC provides additional features for service management without >>>>> requiring kernel changes or replacing pid 1, unlike launchd and other >>>>> solutions. All rc.d scripts have been converted with a few changes, >>>>> typically changing the shebang and making sure the start function is = named >>>>> start(). Most service scripts are simplified, usually needing only na= me, >>>>> command, and, if required, depends statements. >>>>> >>>>> History: >>>>> OpenRC started out as an init system by Roy Marples, developed for th= e >>>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into G= entoo >>>>> as baselayout v2, and was then split off as a separate BSD-licensed >>>>> project. It is under active development, portable, and remains BSD li= censed >>>>> today. >>>>> >>>>> OpenRC and RC: >>>>> Both can coexist and be chosen with a setting in /boot/loader.conf. >>>>> >>>>> OpenRC Features: >>>>> >>>>> Service supervision and service monitoring: any service can be >>>>> supervised. Supervised services that crash are automatically restarte= d. The >>>>> rc-status command shows how many times a service has restarted. >>>>> >>>>> Device hotplug support and event-driven service management: the >>>>> hotplug feature allows devd to take actions when devices are connecte= d. For >>>>> example, a USB wifi adapter can create additional network services wh= en >>>>> attached. The net-online service can, for example, detect when a netw= ork >>>>> connection is restored, and restart ntp. >>>>> >>>>> Network profiles: using stacked runlevels, different profiles can be >>>>> established for different networking settings. For instance, differen= t >>>>> profiles can be used for wired or wireless networking, or for differi= ng >>>>> wireless networks, as well as dependency caching and parallel startup= speed >>>>> up booting. >>>>> >>>>> Interactive mode: >>>>> The boot process can be run interactively for more effective debuggin= g. >>>>> >>>>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the cont= ext in which a >>>>> script is running. There are only three at present: >>>>> sysinit (the OpenRC system is starting), boot (start base services >>>>> when the computer is booting), and default (normal execution). >>>>> >>>>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot,= using ANSI color >>>>> sequences. This can be disabled. >>>>> >>>>> Ports: >>>>> As of July 2017, iXsystems has created OpenRC versions of port servic= e >>>>> scripts for the entire ports tree. These scripts coexist with the rc.= d >>>>> versions. >>>>> >>>>> License: >>>>> OpenRC is a BSD licensed RC init system written in C. From a user >>>>> perspective, it is very similar to the FreeBSD rc.d init system, maki= ng it >>>>> easy to use and learn. >>>>> >>>>> Tested: OpenRC has been used as the init system for TrueOS since >>>>> October 2016. >>>>> >>>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> >>>>> I look forward to discuss the features and capabilities of OpenRC. >>>>> >>>> >>>> This is cool technology. >>>> >>>> However, what was missing last time was a written plan that could be >>>> critiqued for fit with the project's needs. The result of the working = group >>>> was that this was to be produced, and we'd iterate through it to ease = the >>>> landing of openrc in the tree. I think there's wide agreement this is = cool, >>>> and that we'd like tot have both it and rc.d in the tree for a transit= ion >>>> period. Absent a plan, though, it's not really possible to say 'go do = it' >>>> or 'that's insane'. >>>> >>>> So maybe start there? >>>> >>>> Warner >>>> >>>> >>>> >> >> -- >> >> -- >> Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.F= reeBSD.org \/ \ ^ >> Power To Server. .\. /_) >> >> --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-hackers@freebsd.org Wed Dec 19 16:26:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7665133B7BB for ; Wed, 19 Dec 2018 16:26:14 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C43A88383 for ; Wed, 19 Dec 2018 16:26:13 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-lj1-x242.google.com with SMTP id s5-v6so17909315ljd.12 for ; Wed, 19 Dec 2018 08:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=ogNLeleXU11sT2d13VBHfTtqhXlBmcQxPIonJZime6A=; b=nienwFyfgSc5L3niWWQw+nw81hj9fMlAJSL1vB1AP6W45YHKks1BQpsZYcO+VTpI/X plnPYKrwT55e60dkq7z+01WgpThtKGdfRazcznJtReJO6ekE0dSeLKPuLOTaBG+wIpiH 95pF5sThN7B9Nwz8FKIOzS7Z9QfQrDi1hwW+IuI2UkBL1aNd9QETomCAoNUpgRTmMgff nR/3wv6UFDGm6IRjW/AsVx3sG9+kkmK4nqpm1hqCvmXgCWU8xaDrs6mwluMbQsDGs2W9 iH1lmhxSr6o3FPFP4tVDFkbmUA75/EzWSwEgWnKmUyzouFSvpjW+NGv58bCqVDQTaKxH peCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=ogNLeleXU11sT2d13VBHfTtqhXlBmcQxPIonJZime6A=; b=rnfF4MyxsKMrZwHqGTN3sg+LQnnDFozE5tkGo7tS0598M0GpY8B0a7oRAZXmrmieoz 6wlC2cjrnzPpLYDjJKElaKpr9FTEpi0BDrc/QMwnlp94pe2nxCF4pixhE74kuzB0Umke pTuZmpGZzUsPxfqsGcGHRdliKuxXb1UleeAg7fhvPG0FCOCgYFe5ny4iL9A+2WvFAM8B b3MeWPhRqIRYQoqi9jrR4BBC4KrAum8degyS3akdslCvkwWj6bv6LY+c5xnu7ai67Yhz o6ojQB1k6aCLoUUb5tU1lTgnx6sp6yXTk8huJVZCfnAP2Vy/AQGq8qkRg5gB1x2kUnf7 tVMA== X-Gm-Message-State: AA+aEWZZ98YeWWua9CmAsQiwc61rgErMAhOYrQn6Kc9y+V6/WusRkNTI JAfHgPcOCXnuJWxxQfclxZNZup/RJIHOm0H0zz58fA== X-Google-Smtp-Source: AFSGD/WITf4WKsTWMCt8z8/k8QkQeB+Ku3qvzUBlk6u7EorMN03zjRv8dVNZKM6b89bYhF32WmxkxjjP2aQVP6JTJQA= X-Received: by 2002:a2e:630a:: with SMTP id x10-v6mr12538071ljb.11.1545236771304; Wed, 19 Dec 2018 08:26:11 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a2e:165d:0:0:0:0:0 with HTTP; Wed, 19 Dec 2018 08:26:10 -0800 (PST) In-Reply-To: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> From: "D. Ebdrup" Date: Wed, 19 Dec 2018 17:26:10 +0100 Message-ID: Subject: Re: OpenRC on FreeBSD To: freebsd-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5C43A88383 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nienwFyf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of debdrup@gmail.com designates 2a00:1450:4864:20::242 as permitted sender) smtp.mailfrom=debdrup@gmail.com X-Spamd-Result: default: False [-3.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-0.90)[-0.904,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.04)[ip: (3.26), ipnet: 2a00:1450::/32(-1.59), asn: 15169(-1.39), country: US(-0.08)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.607,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 16:26:15 -0000 On 12/19/18, Martin Wilke wrote: > Hi > > I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this i= s > the second attempt to get it into FreeBSD. > > I've opened a review here with a working patch for CURRENT, > https://reviews.freebsd.org/D18578 > > > To recap the discussion > * First attempt of RFC in March of 2018: > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > * Working group at BSDCan: > https://wiki.freebsd.org/DevSummit/201806/OpenRC > > Here some key points: > > OpenRC provides additional features for service management without requir= ing > kernel changes or replacing pid 1, unlike launchd and other solutions. A= ll > rc.d scripts have been converted with a few changes, typically changing t= he > shebang and making sure the start function is named start(). Most service > scripts are simplified, usually needing only name, command, and, if > required, depends statements. > > History: > OpenRC started out as an init system by Roy Marples, developed for the > Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gento= o > as baselayout v2, and was then split off as a separate BSD-licensed proje= ct. > It is under active development, portable, and remains BSD licensed today. > > OpenRC and RC: > Both can coexist and be chosen with a setting in /boot/loader.conf. > > OpenRC Features: > > Service supervision and service monitoring: any service can be supervised= . > Supervised services that crash are automatically restarted. The rc-status > command shows how many times a service has restarted. > > Device hotplug support and event-driven service management: the hotplug > feature allows devd to take actions when devices are connected. For examp= le, > a USB wifi adapter can create additional network services when attached. = The > net-online service can, for example, detect when a network connection is > restored, and restart ntp. > > Network profiles: using stacked runlevels, different profiles can be > established for different networking settings. For instance, different > profiles can be used for wired or wireless networking, or for differing > wireless networks, as well as dependency caching and parallel startup spe= ed > up booting. > > Interactive mode: > The boot process can be run interactively for more effective debugging. > > OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the context = in which a script > is running. There are only three at present: > sysinit (the OpenRC system is starting), boot (start base services when t= he > computer is booting), and default (normal execution). > > OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, usi= ng ANSI color > sequences. This can be disabled. > > Ports: > As of July 2017, iXsystems has created OpenRC versions of port service > scripts for the entire ports tree. These scripts coexist with the rc.d > versions. > > License: > OpenRC is a BSD licensed RC init system written in C. From a user > perspective, it is very similar to the FreeBSD rc.d init system, making i= t > easy to use and learn. > > Tested: OpenRC has been used as the init system for TrueOS since October > 2016. > > Ken Moore has an OpenRC vs RC.d comparison which can be found here: > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf > > I look forward to discuss the features and capabilities of OpenRC. > > Regards, > Martin > > _______________________________________________ > 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= " > You mention parallel service startup as an advantage of OpenRC, but to the best of my knowledge it is turned off by default everywhere, and there's no actual guarentee that parallel service startup won't randomly break. Indeed, there are two outstanding bugs for this very issue, [1] has been open/connfirmed since 2011 and [2] has been open/with nobody assigned since 2014 - neither of them seem to be fixed, from what I can tell? It seems to me that if this is indeed a feature that people want (and I can see why, if you're starting a few hundred jails with only few inter-dependencies) - but I feel sure that people won't want it if it means that the system will no longer boot reliably. So what I'm really asking for, rather than not enabling parallel startup by default (despite this being what most projects apppear to have done), can the problem be fixed before OpenRC is in FreeBSD, such that FreeBSD can have parallel startup that reliably works? I wish I had the talent to contribute in any meaningful way, but I'm just a sysadmin and as a coder I'm a pretty poor florist. [1]: https://bugs.gentoo.org/391945 [2]: https://github.com/OpenRC/openrc/pull/12 --=20 Daniel Ebdrup aka. D. Ebdrup. From owner-freebsd-hackers@freebsd.org Wed Dec 19 22:52:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66012134C15C for ; Wed, 19 Dec 2018 22:52:49 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AFB374CAB; Wed, 19 Dec 2018 22:52:49 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id F0DB31C478; Wed, 19 Dec 2018 22:52:48 +0000 (UTC) From: Jan Beich To: Li-Wen Hsu Cc: Alan Somers , FreeBSD Hackers Subject: Re: Cirrus-CI: Free FreeBSD CI testing for open-source projects References: Date: Wed, 19 Dec 2018 23:52:45 +0100 In-Reply-To: (Li-Wen Hsu's message of "Wed, 19 Dec 2018 19:59:04 +0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 0AFB374CAB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.92 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; NEURAL_HAM_SHORT(-0.94)[-0.945,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-0.99)[-0.987,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 22:52:49 -0000 Li-Wen Hsu writes: > On Wed, Dec 5, 2018 at 03:03 Alan Somers wrote: > >> Cirrus Labs has just released support for FreeBSD on their CI service. And >> they've made it free for OSS! Cirrus-CI is a cloud-based CI system for >> cloud-hosted software, much like Travis-CI, Appveyor, Circle-CI, etc. But >> it's the first* such system to support FreeBSD with no weird hacks >> required. It also runs each test in a full VM, so you can mount >> filesystems, create jails, etc. The free tier supports runs on a dual CPU >> VM with 4GB of RAM. But if that's not enough, you can cheaply configure >> Cirrus to use a custom VM in Google Cloud (gcp account required; cheap but >> not free). >> >> https://cirrus-ci.org/guide/FreeBSD/ > > > This is really an exciting news. Ed and I started a wiki page for tracking > the efforts we put or wanted to add FreeBSD CI for the software widely used: > > https://wiki.freebsd.org/HostedCI Why Chromium? Before hooking CI for FreeBSD it needs to build without patches but there was no upstreaming activity for years. https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-reviews/freebsd|sort:date https://cs.chromium.org/search/?q=OS_FREEBSD From owner-freebsd-hackers@freebsd.org Wed Dec 19 23:07:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E3A134CA63 for ; Wed, 19 Dec 2018 23:07:46 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D51D175C94 for ; Wed, 19 Dec 2018 23:07:44 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-lf1-x134.google.com with SMTP id e26so16320420lfc.2 for ; Wed, 19 Dec 2018 15:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gxmPjn2zf5Hi2Laqmn/MP4R89sPTxQhZai92mFKETuk=; b=mLrHDnpn3jfAn2CQc2dytHRKGnlbaX+Ra5JEeNCODT4oVerbJZIh2NHIXjfrizuAX/ ib5oWsON2mHLRJlA95D8A/bNx9s8RwwED/IwIV41eYmuP9m7zeojrnEBd3EUnIJws1Eq yXd+KnZD/uA/2Jr4SCj8JWAX1f0OSX6FafHFp6q0qovkJSklJrEt76egkch8C8QG3cjL oKJrzO2vBDh0rG0LdsA7yw7O57if0BnFOU0xklYJsCBotA2Kr+s7LNmWDYc3n6+yjXL9 dYyXAGVoY43Li38WAQvafNCVebTO7aZfRMiLcrqFtqZen69ePouORZVnVk8H+IJ/sEdj GRDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gxmPjn2zf5Hi2Laqmn/MP4R89sPTxQhZai92mFKETuk=; b=tUCxvIJHekLIdQn9An/YSGTlT0VVjTeYnnHfpYUXW41qkXq3QTknC+ls+gGpd9nVmQ TBvfhhmeFqu4DB8Qr61ZYK9Uz+iZmWD7Rto4H2LhVurgNHaLLxuUUMmJBL0nRxDed9RW UQZKBDh38dgI0VUzlHFDMYwFde19h79Vw7C2LZBrE8BGDjmHDawe6CE4FdcKn2ZvPx+v u7IrXfu3xFobdwhdQqHnSpKx7qIRdU+4Q5R/Gnvqv3YFbbVW8LlN63q4JoVMT6+3d+sT 1rzBaKaAdEsH+fhTPogdeT5W467qWwtFRxfHjqTADCIC3RfT8fxod1fB594AkfMDJSt1 ltrw== X-Gm-Message-State: AA+aEWb04HnoXErAddlPyMWose/qGN16wYQb4+evckhfSXPr5JQZw/pl 7KH0xMNIijMAHh8GUOGWUP/VbdqXneBtWEjxNphfvg== X-Google-Smtp-Source: AFSGD/Xnbt0ge9Socpt2tEhu4VBvkYP/IW6qVGX8kEnzwM3MeC7J1E5WGUI9KzIL2Q5IbJxsoYKolWO3U9HE6LOWCJY= X-Received: by 2002:a19:3809:: with SMTP id f9mr3032906lfa.148.1545260862888; Wed, 19 Dec 2018 15:07:42 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a2e:165d:0:0:0:0:0 with HTTP; Wed, 19 Dec 2018 15:07:42 -0800 (PST) In-Reply-To: References: From: "D. Ebdrup" Date: Thu, 20 Dec 2018 00:07:42 +0100 Message-ID: Subject: Re: Cirrus-CI: Free FreeBSD CI testing for open-source projects To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D51D175C94 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mLrHDnpn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of debdrup@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=debdrup@gmail.com X-Spamd-Result: default: False [-4.39 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.62)[ipnet: 2a00:1450::/32(-1.60), asn: 15169(-1.40), country: US(-0.08)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[4.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.76)[-0.762,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 23:07:46 -0000 On 12/19/18, Jan Beich wrote: > Li-Wen Hsu writes: > >> On Wed, Dec 5, 2018 at 03:03 Alan Somers wrote: >> >>> Cirrus Labs has just released support for FreeBSD on their CI service. >>> And >>> they've made it free for OSS! Cirrus-CI is a cloud-based CI system for >>> cloud-hosted software, much like Travis-CI, Appveyor, Circle-CI, etc. >>> But >>> it's the first* such system to support FreeBSD with no weird hacks >>> required. It also runs each test in a full VM, so you can mount >>> filesystems, create jails, etc. The free tier supports runs on a dual >>> CPU >>> VM with 4GB of RAM. But if that's not enough, you can cheaply configure >>> Cirrus to use a custom VM in Google Cloud (gcp account required; cheap >>> but >>> not free). >>> >>> https://cirrus-ci.org/guide/FreeBSD/ >> >> >> This is really an exciting news. Ed and I started a wiki page for >> tracking >> the efforts we put or wanted to add FreeBSD CI for the software widely >> used: >> >> https://wiki.freebsd.org/HostedCI > > Why Chromium? Before hooking CI for FreeBSD it needs to build without > patches but there was no upstreaming activity for years. > > https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-reviews/freebsd|sort:date > https://cs.chromium.org/search/?q=OS_FREEBSD > _______________________________________________ > 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" > Another way to see the result of upstream making a practice out of not accepting patches is to look at the files directory of the Chromium port as seen on [1], especially when put up against an upstream project which does accept patches as seen on [2]. [1]: https://svnweb.freebsd.org/ports/head/www/chromium/files [2]: https://svnweb.freebsd.org/ports/head/www/firefox/files/ -- Daniel Ebdrup aka. D. Ebdrup. From owner-freebsd-hackers@freebsd.org Wed Dec 19 23:08:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CABA1134CAC7 for ; Wed, 19 Dec 2018 23:08:52 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4E9B75D47 for ; Wed, 19 Dec 2018 23:08:51 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from disco.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 6E58956468 for ; Wed, 19 Dec 2018 17:08:44 -0600 (CST) To: freebsd-hackers From: Eric van Gyzen Subject: msleep() -> EAGAIN ? Message-ID: <08b381fb-2918-879d-d3f7-c34c7ca9372b@vangyzen.net> Date: Wed, 19 Dec 2018 17:08:40 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C4E9B75D47 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-2.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; DMARC_NA(0.00)[vangyzen.net]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[hotblack.vangyzen.net]; NEURAL_HAM_SHORT(-0.60)[-0.599,0]; IP_SCORE(-0.80)[asn: 36236(-3.91), country: US(-0.08)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:36236, ipnet:2607:fc50:1000::/36, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 23:08:53 -0000 These functions check for msleep() returning EAGAIN, but I don't see how that can happen? uipc_mqueue.c _mqueue_send() uipc_mqueue.c _mqueue_recv() kern_sig.c kern_sigtimedwait() fuse_ipc.c fticket_wait_answer() Can msleep() really return EAGAIN and I just don't see it? Did msleep() return EAGAIN in the past, but no longer can? Thanks, Eric From owner-freebsd-hackers@freebsd.org Wed Dec 19 23:16:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4084F134CFBC for ; Wed, 19 Dec 2018 23:16:05 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A95DE7654C for ; Wed, 19 Dec 2018 23:16:04 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from disco.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id CC36A56468 for ; Wed, 19 Dec 2018 17:16:03 -0600 (CST) Subject: Re: msleep() -> EAGAIN ? From: Eric van Gyzen To: freebsd-hackers References: <08b381fb-2918-879d-d3f7-c34c7ca9372b@vangyzen.net> Message-ID: Date: Wed, 19 Dec 2018 17:16:03 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <08b381fb-2918-879d-d3f7-c34c7ca9372b@vangyzen.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: A95DE7654C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-2.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[vangyzen.net]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: hotblack.vangyzen.net]; NEURAL_HAM_SHORT(-0.83)[-0.826,0]; IP_SCORE(-0.80)[asn: 36236(-3.91), country: US(-0.08)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50:1000::/36, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 23:16:05 -0000 #define EWOULDBLOCK     EAGAIN          /* Operation would block */ Sigh.  Nevermind. Eric On 12/19/18 5:08 PM, Eric van Gyzen wrote: > These functions check for msleep() returning EAGAIN, but I don't see how > that can happen? > > uipc_mqueue.c _mqueue_send() > uipc_mqueue.c _mqueue_recv() > kern_sig.c kern_sigtimedwait() > fuse_ipc.c fticket_wait_answer() > > Can msleep() really return EAGAIN and I just don't see it? Did msleep() > return EAGAIN in the past, but no longer can? > > Thanks, > > Eric > _______________________________________________ > 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 Dec 20 08:59:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 437B9133CEAE for ; Thu, 20 Dec 2018 08:59:41 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E02826E53A for ; Thu, 20 Dec 2018 08:59:39 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf1-f169.google.com with SMTP id y126so604138pfb.4 for ; Thu, 20 Dec 2018 00:59:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NoWd0sDcwERDZ27Ztmh9tvTK8dfSLRNsafUSFlz0dp4=; b=aCfuSxuWV7TBQZHNbVPrzuDREXUflP/SjluKLG7kIrf4ZMJB7z9+0OE7LteM/oofA8 buEjvu4WbhsE4e+ekLz7bYK0Ug3ZGYhaDeLsK5hfZc8NSqVlvIzK0vkEvTDSaykbyTFo S4ZLhc0LGLQSIRXojTcVODL4QQ3i4i0gxTQ8TLywHgwC0fic6tvM2JjZ0eiOwXHbRSdU we0nec3de4S0V9MUImhKZHiLxLqMv1p6I+KZmyKNVuhZOPHV5ebMfzckSTlTbU6lE9CN fmpDIgQBtrYMyNSOB+Bdv4cbNN1sHj8UlzP4QUDF39igbd5sOig2hyzVxBtR4zKt6FWW Anmw== X-Gm-Message-State: AA+aEWZtGG94OylJz46NhiohoUG8AVgWhK0Ybr0MnaHT8HQhJ0HT7i1L Jm7nkyqHA419LILw844Alu+4h0/cEyk= X-Google-Smtp-Source: AFSGD/XI+vBScDY3xhPluImbqrbVQTQkCsxNAA8XzncaS4TffWc/mwDmFG6eXqAtESqXpBZ8N19c4Q== X-Received: by 2002:a63:193:: with SMTP id 141mr22371128pgb.136.1545296373489; Thu, 20 Dec 2018 00:59:33 -0800 (PST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id w136sm29522549pfd.169.2018.12.20.00.59.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 00:59:33 -0800 (PST) Received: by mail-pl1-f173.google.com with SMTP id t13so557308ply.13 for ; Thu, 20 Dec 2018 00:59:33 -0800 (PST) X-Received: by 2002:a17:902:d891:: with SMTP id b17mr23793941plz.80.1545296372985; Thu, 20 Dec 2018 00:59:32 -0800 (PST) MIME-Version: 1.0 From: Gleb Popov Date: Thu, 20 Dec 2018 12:59:06 +0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Calling a function from a SO breaks in libc To: freebsd-hackers X-Rspamd-Queue-Id: E02826E53A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; URI_COUNT_ODD(1.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.89)[-0.887,0]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; MIME_TRACE(0.00)[0:+,1:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.02)[ipnet: 209.85.128.0/17(-3.62), asn: 15169(-1.40), country: US(-0.08)]; RCVD_IN_DNSWL_NONE(0.00)[169.210.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 08:59:41 -0000 When debugging software with GDB on FreeBSD 12+ I often get into following situation: (gdb) next (anonymous namespace)::D13AsmPrinter::EmitInstruction (this=0x8056b4b80, MI=0x805765690) at /home/arr/projects/d13/lib/Target/D13/D13AsmPrinter.cpp:152 152 EmitToStreamer(*OutStreamer, TmpInst); (gdb) step Now instead of entering into EmitStreamer(), I see: _thr_rtld_set_flag (mask=1) at /usr/src/lib/libthr/thread/thr_rtld.c:171 171 { Trying to get out of there: (gdb) finish Run till exit from #0 _thr_rtld_set_flag (mask=1) at /usr/src/lib/libthr/thread/thr_rtld.c:171 0x000000080027669b in thread_mask_set (mask=) at /usr/src/libexec/rtld-elf/rtld_lock.c:177 177 return lockinfo.thread_set_flag(mask); Value returned is $3 = 0 (gdb) finish Run till exit from #0 0x000000080027669b in thread_mask_set (mask=) at /usr/src/libexec/rtld-elf/rtld_lock.c:177 rlock_acquire (lock=0x800287ba0 , lockstate=0x7fffffff9608) at /usr/src/libexec/rtld-elf/rtld_lock.c:203 203 if (thread_mask_set(lock->mask) & lock->mask) { (gdb) finish Run till exit from #0 rlock_acquire (lock=0x800287ba0 , lockstate=0x7fffffff9608) at /usr/src/libexec/rtld-elf/rtld_lock.c:203 _rtld_bind (obj=0x80028b400, reloff=625152) at /usr/src/libexec/rtld-elf/rtld.c:808 808 if (sigsetjmp(lockstate.env, 0) != 0) (gdb) finish Run till exit from #0 _rtld_bind (obj=0x80028b400, reloff=625152) at /usr/src/libexec/rtld-elf/rtld.c:808 _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:124 124 movq %rax,0x60(%rsp) # Store target over reloff argument Value returned is $4 = 34402603952 (gdb) finish Run till exit from #0 _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:124 Program received signal SIGTRAP, Trace/breakpoint trap. _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:155 155 ret # "Return" to target address (gdb) finish Run till exit from #0 _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:155 Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000008028e13b4 in llvm::AsmPrinter::EmitToStreamer (this=0x80028b400, S=..., Inst=...) at /home/arr/projects/d13/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:228 After this. the debugging is impossible, because every "cont/step/next" command yields "Program received signal SIGTRAP, Trace/breakpoint trap". Trying to "print" anything causes GDB to crash. It should be noted, that I'm linking to LLVM-7.so library. Using static linkage for the executable I'm debugging makes this bug go away. Anyone have an idea what's going on and how to fix that? From owner-freebsd-hackers@freebsd.org Thu Dec 20 15:52:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F587134B3A9 for ; Thu, 20 Dec 2018 15:52:35 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A04288621E for ; Thu, 20 Dec 2018 15:52:33 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-lj1-x242.google.com with SMTP id v1-v6so2022792ljd.0 for ; Thu, 20 Dec 2018 07:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bNW+QQLK/72Wd2a4tEi2o/wCl92L13/oKhbszHzZMMI=; b=eeeWH3MdgCqn2VOoo3NePx2EKwTqRW/CcJZisSyCIKGvlH+vF+ZePabHqd2RGJRas2 CABiEfne9GBGnEO/FR/XRfTDkKxUYaJxA8sNQawu3bu9YYbFlkMizZfhc5ef0/Nkzsm1 cUpJW3iaTA+jYDJkqFLP2IO5NqpfKMoHZhZyDXM4xm+bl/vS+p5j51uE/s/7+9gW5i8J ROZue0AhQYUVPdeELT+wZA9QiHtCCMdK/Qdhy4LkctG2Y96ugYCt+5CnzTlEtgXQn0JY Q3FCFY04XnjrVzze0naHpU8IVIB+UgHy3/5/kkSpk5jWLQ6aYnMg2blFkhcnbQ8gQugn 3qvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bNW+QQLK/72Wd2a4tEi2o/wCl92L13/oKhbszHzZMMI=; b=i8kk5hN0UBqal873xA5GTQFykr88DfadPkDJchyC3DfvLIQjoDtuqvHlOiK2v6YtMk IHyoEH/w/bP+wspCqaPYKdbv31Q3WDNrwIUxHYi2SlGDeDa1e+LnLB+NwodSazASxSnO Qb5MY16swxro/85rbHJ6nJ6pvytCJzAVRZI3nYZqTJAd2uvOEo6o3GrhVKEJUNSDV03r KYlsVukXXcms7kg32iximwbP2fqS3G5q257hBOsc1s15Zgz+xoEDWESLcoGY+jcnqmcW 30nD+F4og5FtmGYVGdHW1ifjrJPfLsJmFEQgptKJSqQoOHgjliW/crSRbUkEyXEjbrbd smZA== X-Gm-Message-State: AA+aEWb9CjHOaBm8eIqV/tdqRfQHAiKPubzW21/jo8qdjDrXzOlZngvY 6n93zNxRQxU6p8zUWbIVQhKe4A== X-Google-Smtp-Source: AFSGD/WadwpBOYvhu9tpEYRPlm/qgWNZ/0hRZKaDs7uX04HUjyX367YV8XxNRTNxRO1QRpmMa1zW9Q== X-Received: by 2002:a2e:4746:: with SMTP id u67-v6mr15422848lja.142.1545321152125; Thu, 20 Dec 2018 07:52:32 -0800 (PST) Received: from mutt-hbsd (tor-exit-node-ovh.analord.ml. [51.75.253.147]) by smtp.gmail.com with ESMTPSA id m63-v6sm4759618lje.81.2018.12.20.07.52.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 20 Dec 2018 07:52:31 -0800 (PST) Date: Thu, 20 Dec 2018 10:51:37 -0500 From: Shawn Webb To: Martin Wilke Cc: freebsd-hackers@FreeBSD.org, Joe Maloney , Marcelo Araujo , ken@ixsystems.com, kmoore@FreeBSD.org, wblock@FreeBSD.org Subject: Re: OpenRC on FreeBSD Message-ID: <20181220155137.4wze3ci4lypw47od@mutt-hbsd> References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dwar3i3dxczvy5wt" Content-Disposition: inline In-Reply-To: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT FreeBSD 13.0-CURRENT HARDENEDBSD-13-CURRENT amd64 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: A04288621E X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=eeeWH3Md; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2a00:1450:4864:20::242 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.58)[-0.584,0]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.01)[ip: (3.17), ipnet: 2a00:1450::/32(-1.61), asn: 15169(-1.41), country: US(-0.08)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:52:35 -0000 --dwar3i3dxczvy5wt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2018 at 10:36:04PM +0800, Martin Wilke wrote: > Service supervision and service monitoring: any service can be supervised= =2E Supervised services that crash are automatically restarted. The rc-stat= us command shows how many times a service has restarted. Can automatic restart be globally disabled? Automatic restart can cause security issues, especially in operating systems without modern exploit mitigations. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --dwar3i3dxczvy5wt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlwbuoQACgkQaoRlj1JF bu6ZZg//aAjrEstZxW7on8wHbgJYjnaf5pk5d561EqcLstAQ3R9kbTTCsvwVvupu whrdFDCUGvyJovCWKKvo1tqFM9vCgSYih1fq9FRqZqmq8XGWAgwfIgQyeuWoLyHD 2/+yuTx1K8ojzabBcBVFTB2Ltf2MIDkfTkxbZjIgkSJfl0N+Hhzx1xAkEF6PlO1w /DQJNWkgJLRpQQxreKdCGS4XVqgrtuVQdk3XqUloaOTTqxK6k2dUer9VvZUC6muq rM61pFZQGeIHLR4JXD5hAtneHVr/XrVc2pPjZFuSMb9+8yxH+LJUCgVBuZYIpomq MtdJZpat/lEqlU+0PdhGdCaCAdxWTCaMuGrE3xAyBQJ9WT7YV+fdXhHqc9RTQPla TC8zXsadLrDw/On2HLBg7QZIcuycEl5fVhJ8hxD6KXibPpAtk94t7VF1IlY7HjJJ 8ThgnxUhv+8piYxUrU0A2BJJU+KfXWm1jh4tNJfnTKtNGUPZafH8HQ64XMDzjs/i kijCJmY8J0MyjPeDO00mDNF1yYIxsCOCFFPfGP3I0TgfqSNEGyHxDhIUifUHowl6 434qNwcx/VBnbSnXf38jgb7RSurVXJBPwDhYwB7f7L/Zuw2DVQAg1LE1VBYlWJgo MPIid7LoGP96kPkb79KcJbtJc7Dl5QJF8VGVKwWXbZJMbTRbyYE= =o0k5 -----END PGP SIGNATURE----- --dwar3i3dxczvy5wt-- From owner-freebsd-hackers@freebsd.org Sat Dec 22 01:39:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C5D5133C9C7 for ; Sat, 22 Dec 2018 01:39:06 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1DC78E695 for ; Sat, 22 Dec 2018 01:39:04 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AC01321F93 for ; Fri, 21 Dec 2018 20:39:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 21 Dec 2018 20:39:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=to :from:subject:message-id:date:mime-version:content-type; s=fm3; bh=8u8U8p1Unp9SeUYU2Lgn8Dg0GKKvP2SyUost+bUv7Y4=; b=Y1hjuYnkWIul Ld5Qv77AZzTlXANelTC6P+AZvRyPkwJ7JqZhEffk46Z6ob7bhQVnmpNNmlHJju+z YGLU9a7en7dJ+cZPVrFx4bUtd+Wj2g5bG/M6YDozYACelRVY2Bm1w0pggARiY3cR u/8vrt+GEdHKuTzGNdFdKlnsuohOaTUxSJc8f+6g13+9Bl6e1T7Ep2Jx77zDJyUo /cf5bV6tKKl9/sHIKfsoCZLxd42vGc6AN0wtI8hIq/aDh9rlVVzTXGRenznmNCSX oSWC4XKygX89BReOnVGiqkxgJSfrHGXxSh1qH4S04ijITzjSOjKgZ/XybfSvLHgA BhVCWMXeew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=8u8U8p1Unp9SeUYU2Lgn8Dg0GKKvP 2SyUost+bUv7Y4=; b=EC9nS0O9dUx2DSfU/BlJf8beaFqmyNnRokzY+vFm3ESAa eynCFoBb2Xu+W8fCHRav9+OMfCcfzBELZ4isD6eS+9LGouYCkuioNsn5caFvd9AR 4Y8LuKyLnq9z4x2Q0ZXNKrGYykM5/iyDUAc8RJm6bQ2bzykDx+kTy8EIjHpzYYwT KYIH4CQ6f6abEeGJmgbOX9xZhVT8g3IKdX9HDQq7b/eRQ1uXKJjvv8L1UddDrfIT 3hNGUIffn1ez7XcYUfJlSIeoQaH2N4y7qiW/Rt3tSmVEquGfIyy4VpduQelNFuzo mC/IpaLpmrTUWAUm3z6kqW8rcJ2afNtWvzTVfhctQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepvffhuffkffgfgggtsehgtderofdtfeejnecuhfhrohhmpegjuh hrihcurfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdrnhgvtheqnecuffhomhgr ihhnpehfrhgvvggsshgurdhorhhgnecukfhppeelgedrvdeffedrvdefuddrudelheenuc frrghrrghmpehmrghilhhfrhhomhephihurhhiphhvseihuhhrihhpvhdrnhgvthenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.2] (unknown [94.233.231.195]) by mail.messagingengine.com (Postfix) with ESMTPA id 073A7E4535 for ; Fri, 21 Dec 2018 20:39:01 -0500 (EST) To: freebsd-hackers From: Yuri Pankov Subject: is adding new private symbols to libc frowned upon? Openpgp: preference=signencrypt Autocrypt: addr=yuripv@yuripv.net; keydata= mQENBFu8u6IBCADB11gP0QwnorrHjqAtKLHKHNHskhy0s7jqJKfx0YqXgVBKGLJ9/mjLAz0F CBNvemHSDDTs0mEZ9cBKKi6cmsav6+UQgr//yai6hvXLBJqKchSFO4MhmdvBtsGFq1yKz5Zi uhjmimKyIpgBgvMdbgGbGq6cnSB2uEPmZuJr419SVRODOkXukU+F5WHgaHzDdHAIu1asCt2B +6msxqIqlFWcXyZyTGicTGGvC/PFIsVRUtD1dIJANTC876g7DTb7LZXWiWwJpSJ4GKMXMHVX Ct9BoQ4i3nhKbOxb6Io1wsy+NFyWsTJ9KYrxKKPJP3oG8BWb/cqlFqnE4eNSsiq2q7krABEB AAG0H1l1cmkgUGFua292IDx5dXJpcHZAeXVyaXB2Lm5ldD6JAVQEEwEKAD4WIQT4arc+w94t Pi0v/3CTi+B/sSrhbAUCW7y7ogIbAwUJBaOagAULCQgHAwUVCgkICwUWAwIBAAIeAQIXgAAK CRCTi+B/sSrhbJ+ACACqOlkjZ+iP8K8hcwz/G6+c1lVkhuMWL+hxFeE149QuJAXQvkOj/UXO 7jY9HSqFbOYYY44/hujpQCu+/u2dsJ5MAA7TJspWK2zUxtFAzgDp1fRXmCvMlFLdI0yVkKOB JaK+HQP8rBT6yHzGw1KJ6VyOXuuD0Kx02Ou61qjG9/vPRR0jtaxog0rKxpf+yf0UvSM4vb7+ LdY2GQxgfcLcJ8hThR4ElWJAkDsG4CiXixGJuFJ+9dpMK6LHmP6M+NxV4NkzpNddn3Eii8XQ y5spxcLszp8csFBDtAC6BI9sHLhJ9Va1VKpuvSlDsBv4ZtsjnUCIaOiF5MDTYkddSPGGMBck uQENBFu8u6IBCADKih3Q933rDNj4ZA8FhBQ2RlmBgvwOLcDPIL3h0V7h38y3+HisgFScXACD sdrTlYZ1bRXkD9FHENynBcv0l/3uGJDk8jaGIDE0TP8OQBRp+IaU9/BHnAqrKxTJGIolDahy 2m+yx2yhdc6B4ujWMDqCF1rWOD+ymOWw+VLllOkrHcZa5PJtX9UOGbApZl8ZTM8El4CANN8F 1bg9MWzUi+8LYoGWGc+BwsFS1OUB1c4SPgMu5fD4Wfsr9yRl06fdpEA2YT7B/j5/5RSC0sE2 Zs/tmJ/JRflHJ12ycj59ma2xQMfEJF40hZDpMFQmZvbVqgEg3ocQcltjbxlIKZ/mjC4zABEB AAGJATwEGAEKACYWIQT4arc+w94tPi0v/3CTi+B/sSrhbAUCW7y7ogIbDAUJBaOagAAKCRCT i+B/sSrhbIDcCACqAZMcoxUBLZa40a5b24j5i1jplvCYYb3h+Q5lt5+BFJ87kCb4dJuUD3kh 2i29BrxWQWa9WNue9ozxeYkbkfXubQYXexVolRsnh64OdGsE8KvorBFBB3zdK/GRt2Jy+jsn TfUWuQllbzMP0MfhCDMk1Mo8WvDH2/cOEP/yLKf20a+cd6nLs7bidjmGXo9pyuBKAtV6Kv+V Ru54AL+A/UBYu/eB3Dtvzcnut+1Zq6KaP++kUwPwINLIk04OBDwN0zRNTiqMAFYYyz2vZHBB 6E1th/l//ZC5b9Dk0ZpFI1bYdL9ymnrZe1MqbGPnDCToQxu00T/pZCm6Z92YrZQYuNwl Message-ID: Date: Sat, 22 Dec 2018 04:38:52 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EhiOZGbFucnSj3LgI79UfCuSKsOhehwe5" X-Rspamd-Queue-Id: E1DC78E695 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.net header.s=fm3 header.b=Y1hjuYnk; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=EC9nS0O9; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=yuripv@yuripv.net X-Spamd-Result: default: False [-8.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yuripv.net:+,messagingengine.com:+]; MX_GOOD(-0.01)[cached: in2-smtp.messagingengine.com]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[25.4.111.66.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yuripv.net:s=fm3,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[yuripv.net]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.61)[ip: (-9.52), ipnet: 66.111.4.0/24(-4.67), asn: 11403(-3.78), country: US(-0.08)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 01:39:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EhiOZGbFucnSj3LgI79UfCuSKsOhehwe5 Content-Type: multipart/mixed; boundary="CoWJRoNTpJ1quOjP17OCk5IjGCqJB7m7E"; protected-headers="v1" From: Yuri Pankov To: freebsd-hackers Message-ID: Subject: is adding new private symbols to libc frowned upon? --CoWJRoNTpJ1quOjP17OCk5IjGCqJB7m7E Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Essentially, I need the __collate_equiv_value symbol to be visible to libregex for the changes in https://reviews.freebsd.org/D18531. Is the following change OK (it works, at least), or should try to avoid that? --- a/lib/libc/locale/Symbol.map +++ b/lib/libc/locale/Symbol.map @@ -212,6 +212,7 @@ FBSD_1.3 { FBSDprivate_1.0 { _PathLocale; __detect_path_locale; + __collate_equiv_value; __collate_load_error; __collate_range_cmp; }; --CoWJRoNTpJ1quOjP17OCk5IjGCqJB7m7E-- --EhiOZGbFucnSj3LgI79UfCuSKsOhehwe5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+Gq3PsPeLT4tL/9wk4vgf7Eq4WwFAlwdlawACgkQk4vgf7Eq 4Wz1UwgAutD4hpHvWLBiFnJdFPmhaZk7GpSQqPD6npFuogpnBFiW++hSsUbsI5CY 7dRovng87sGLLA8UFG4bUJE1xKThF2/jUdjWJZsdCkq8LcgRPpTajPekGJ1ozH20 ZFP6vhLBRFYi3myHNmCfbGJIsIuGJF5aIwfqkyTD88mUCUyDIOzsr2vfW7W0+JjP 8DooEXckHU9UNGN5qAQlxHd2ePfpHN/qTHNd8KfjclDDpQuHsT4JlUvp7gMuj5m5 BjPki0X1voaVZg11RwE8m5/Uz7a/ty2n2LoVOUbtc1N4Z1xM80ILJt5z97O+/9Yp ezbJpblIIZuQX2DGro16Dt0e2yWIFw== =1qid -----END PGP SIGNATURE----- --EhiOZGbFucnSj3LgI79UfCuSKsOhehwe5-- From owner-freebsd-hackers@freebsd.org Sat Dec 22 06:41:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A20C11347564 for ; Sat, 22 Dec 2018 06:41:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B141D731B7 for ; Sat, 22 Dec 2018 06:41:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wBM6fdT3045291 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 22 Dec 2018 08:41:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wBM6fdT3045291 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wBM6fc62045290; Sat, 22 Dec 2018 08:41:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2018 08:41:38 +0200 From: Konstantin Belousov To: Yuri Pankov Cc: freebsd-hackers Subject: Re: is adding new private symbols to libc frowned upon? Message-ID: <20181222064138.GM60291@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 06:41:48 -0000 On Sat, Dec 22, 2018 at 04:38:52AM +0300, Yuri Pankov wrote: > Essentially, I need the __collate_equiv_value symbol to be visible to > libregex for the changes in https://reviews.freebsd.org/D18531. Is the > following change OK (it works, at least), or should try to avoid that? > > --- a/lib/libc/locale/Symbol.map > +++ b/lib/libc/locale/Symbol.map > @@ -212,6 +212,7 @@ FBSD_1.3 { > FBSDprivate_1.0 { > _PathLocale; > __detect_path_locale; > + __collate_equiv_value; > __collate_load_error; > __collate_range_cmp; > }; > Then libregex must always match the installed libc. I looked at the the libregex/Makefile and my question is, what is the difference between exports from libc/regex vs. libregex. Can libregex become ELF filter for libc ? From owner-freebsd-hackers@freebsd.org Sat Dec 22 06:45:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34C2913477FB for ; Sat, 22 Dec 2018 06:45:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D070073376 for ; Sat, 22 Dec 2018 06:45:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 6CCF31CAC1 for ; Sat, 22 Dec 2018 06:45:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f178.google.com with SMTP id v1-v6so6613549ljd.0 for ; Fri, 21 Dec 2018 22:45:21 -0800 (PST) X-Gm-Message-State: AJcUukf6yuS67ZBP9wYx+oyj8GZ6KWjPLcpJbY6U8lM9dfPtyb/Ustr4 G0rV7R3z/SfyChDQ0+iabAYkyGqfkQFS7Z4WGto= X-Google-Smtp-Source: ALg8bN4kVFCUIjcL+LhX2o2+xViR/7f0wEieMD2kDGDPE6pXSYbEYcVDnjE+15qGPsRP9/kTN3YoaUdNkNAiNFS01JQ= X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr3245163ljm.72.1545461119647; Fri, 21 Dec 2018 22:45:19 -0800 (PST) MIME-Version: 1.0 References: <20181222064138.GM60291@kib.kiev.ua> In-Reply-To: <20181222064138.GM60291@kib.kiev.ua> From: Kyle Evans Date: Sat, 22 Dec 2018 00:45:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: is adding new private symbols to libc frowned upon? To: Konstantin Belousov Cc: Yuri Pankov , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D070073376 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 06:45:22 -0000 On Sat, Dec 22, 2018 at 12:42 AM Konstantin Belousov wrote: > > On Sat, Dec 22, 2018 at 04:38:52AM +0300, Yuri Pankov wrote: > > Essentially, I need the __collate_equiv_value symbol to be visible to > > libregex for the changes in https://reviews.freebsd.org/D18531. Is the > > following change OK (it works, at least), or should try to avoid that? > > > > --- a/lib/libc/locale/Symbol.map > > +++ b/lib/libc/locale/Symbol.map > > @@ -212,6 +212,7 @@ FBSD_1.3 { > > FBSDprivate_1.0 { > > _PathLocale; > > __detect_path_locale; > > + __collate_equiv_value; > > __collate_load_error; > > __collate_range_cmp; > > }; > > > Then libregex must always match the installed libc. > > I looked at the the libregex/Makefile and my question is, what is the > difference between exports from libc/regex vs. libregex. Can libregex > become ELF filter for libc ? > libregex is going to be getting more complicated [1] after a couple more exp-runs. I can possibly re-work it to make a filter work (perhaps?), but I'm not sure how badly that will impact the performance of libc regex. [1] https://reviews.freebsd.org/D12935 From owner-freebsd-hackers@freebsd.org Sat Dec 22 07:14:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 515621348298 for ; Sat, 22 Dec 2018 07:14:11 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE22743B5; Sat, 22 Dec 2018 07:14:09 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id E8A4B1223; Sat, 22 Dec 2018 02:14:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 22 Dec 2018 02:14:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=0GB3jw4CG2gr+oN35GsW15zDo10 uKkvOVxtbbBYULLI=; b=BFnfENEXxsbO/K3csZE+Y3oFUACITjDCoFYRPprdA5g zrUwDwImw84TlqxhrDDjUGdGlAMJEOv8W7J7Zec0Bnpy6DBV9+445m1jB/E8jY4y qWn4btKJLvjigbKBjo15x7pNtOl+1OsM/7g6WnHAPQYz/NsR2+JyJC9HwLmNHSK7 aLO1qsqH6QXFPYZh266TPNcxsS8zgb2oNUdrILjpTqlTj5O9YlZ9Ic3sUxG5O1bq H4Mm4aLJ4n8p2wJkET4tG0ukmWobnlpU036BoFl5NQbkid2w0f4o2OOXVg7KZLJD dxySVIjjYkfMacod8SuG2Obw+u9zyQqRAFslAWwI33Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0GB3jw 4CG2gr+oN35GsW15zDo10uKkvOVxtbbBYULLI=; b=epg3nJtYaQduGL4pfP4aeC mCc/KKRJGcCyIjLsjpmB9pWJb8rr2zwDf/cwyP9gXDYJQ3/eLWXEkWsV+Ejktw3e WuYx3qud3MoVqfDy4UYSd5/75BBjpJS2PUZqxHPGG2bqO3Fb7YkaeL9Jg0W1kaAk hHh/kyN4TpoSOnra4yspTfqW7sKO9C+IcQmlcP9SozwCLOj8GMHFdtWD9Qorkvhc Wk3nR5tGvyPAdDDxxhwtLKANLvbVClMBs2B2nyZHDHhGeMkrcSK/z5QkJ5X+Uz0w VPZEXDemBndvx1/9f4XlRbvdhGZusOv1YD6vl9Cz09ot3tGCTtcv08qZpcoJ2EEQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejiedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkf fffgggjggtsehgtderofdtfeejnecuhfhrohhmpegjuhhrihcurfgrnhhkohhvuceohihu rhhiphhvseihuhhrihhpvhdrnhgvtheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorh hgnecukfhppeelgedrvdeffedrvdefuddrudelheenucfrrghrrghmpehmrghilhhfrhho mhephihurhhiphhvseihuhhrihhpvhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.2] (unknown [94.233.231.195]) by mail.messagingengine.com (Postfix) with ESMTPA id A6ACFE40E1; Sat, 22 Dec 2018 02:13:59 -0500 (EST) Subject: Re: is adding new private symbols to libc frowned upon? To: Kyle Evans , Konstantin Belousov Cc: freebsd-hackers References: <20181222064138.GM60291@kib.kiev.ua> From: Yuri Pankov Openpgp: preference=signencrypt Autocrypt: addr=yuripv@yuripv.net; keydata= mQENBFu8u6IBCADB11gP0QwnorrHjqAtKLHKHNHskhy0s7jqJKfx0YqXgVBKGLJ9/mjLAz0F CBNvemHSDDTs0mEZ9cBKKi6cmsav6+UQgr//yai6hvXLBJqKchSFO4MhmdvBtsGFq1yKz5Zi uhjmimKyIpgBgvMdbgGbGq6cnSB2uEPmZuJr419SVRODOkXukU+F5WHgaHzDdHAIu1asCt2B +6msxqIqlFWcXyZyTGicTGGvC/PFIsVRUtD1dIJANTC876g7DTb7LZXWiWwJpSJ4GKMXMHVX Ct9BoQ4i3nhKbOxb6Io1wsy+NFyWsTJ9KYrxKKPJP3oG8BWb/cqlFqnE4eNSsiq2q7krABEB AAG0H1l1cmkgUGFua292IDx5dXJpcHZAeXVyaXB2Lm5ldD6JAVQEEwEKAD4WIQT4arc+w94t Pi0v/3CTi+B/sSrhbAUCW7y7ogIbAwUJBaOagAULCQgHAwUVCgkICwUWAwIBAAIeAQIXgAAK CRCTi+B/sSrhbJ+ACACqOlkjZ+iP8K8hcwz/G6+c1lVkhuMWL+hxFeE149QuJAXQvkOj/UXO 7jY9HSqFbOYYY44/hujpQCu+/u2dsJ5MAA7TJspWK2zUxtFAzgDp1fRXmCvMlFLdI0yVkKOB JaK+HQP8rBT6yHzGw1KJ6VyOXuuD0Kx02Ou61qjG9/vPRR0jtaxog0rKxpf+yf0UvSM4vb7+ LdY2GQxgfcLcJ8hThR4ElWJAkDsG4CiXixGJuFJ+9dpMK6LHmP6M+NxV4NkzpNddn3Eii8XQ y5spxcLszp8csFBDtAC6BI9sHLhJ9Va1VKpuvSlDsBv4ZtsjnUCIaOiF5MDTYkddSPGGMBck uQENBFu8u6IBCADKih3Q933rDNj4ZA8FhBQ2RlmBgvwOLcDPIL3h0V7h38y3+HisgFScXACD sdrTlYZ1bRXkD9FHENynBcv0l/3uGJDk8jaGIDE0TP8OQBRp+IaU9/BHnAqrKxTJGIolDahy 2m+yx2yhdc6B4ujWMDqCF1rWOD+ymOWw+VLllOkrHcZa5PJtX9UOGbApZl8ZTM8El4CANN8F 1bg9MWzUi+8LYoGWGc+BwsFS1OUB1c4SPgMu5fD4Wfsr9yRl06fdpEA2YT7B/j5/5RSC0sE2 Zs/tmJ/JRflHJ12ycj59ma2xQMfEJF40hZDpMFQmZvbVqgEg3ocQcltjbxlIKZ/mjC4zABEB AAGJATwEGAEKACYWIQT4arc+w94tPi0v/3CTi+B/sSrhbAUCW7y7ogIbDAUJBaOagAAKCRCT i+B/sSrhbIDcCACqAZMcoxUBLZa40a5b24j5i1jplvCYYb3h+Q5lt5+BFJ87kCb4dJuUD3kh 2i29BrxWQWa9WNue9ozxeYkbkfXubQYXexVolRsnh64OdGsE8KvorBFBB3zdK/GRt2Jy+jsn TfUWuQllbzMP0MfhCDMk1Mo8WvDH2/cOEP/yLKf20a+cd6nLs7bidjmGXo9pyuBKAtV6Kv+V Ru54AL+A/UBYu/eB3Dtvzcnut+1Zq6KaP++kUwPwINLIk04OBDwN0zRNTiqMAFYYyz2vZHBB 6E1th/l//ZC5b9Dk0ZpFI1bYdL9ymnrZe1MqbGPnDCToQxu00T/pZCm6Z92YrZQYuNwl Message-ID: <352cae97-2e25-3302-0e4e-e75d4b4b3225@yuripv.net> Date: Sat, 22 Dec 2018 10:13:41 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9RW5owgLvSLpQp7OD8PjwfiyBRvAHcYYN" X-Rspamd-Queue-Id: 0BE22743B5 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.net header.s=fm3 header.b=BFnfENEX; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=epg3nJtY; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=yuripv@yuripv.net X-Spamd-Result: default: False [-8.16 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yuripv.net:+,messagingengine.com:+]; MX_GOOD(-0.01)[cached: in2-smtp.messagingengine.com]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-3.47)[ip: (-9.00), ipnet: 64.147.123.0/24(-4.50), asn: 11403(-3.78), country: US(-0.08)]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[25.123.147.64.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yuripv.net:s=fm3,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[yuripv.net]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 07:14:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9RW5owgLvSLpQp7OD8PjwfiyBRvAHcYYN Content-Type: multipart/mixed; boundary="LYW4qOyL853LutqVKVOrNn92HCEK76Sb6"; protected-headers="v1" From: Yuri Pankov To: Kyle Evans , Konstantin Belousov Cc: freebsd-hackers Message-ID: <352cae97-2e25-3302-0e4e-e75d4b4b3225@yuripv.net> Subject: Re: is adding new private symbols to libc frowned upon? References: <20181222064138.GM60291@kib.kiev.ua> In-Reply-To: --LYW4qOyL853LutqVKVOrNn92HCEK76Sb6 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Kyle Evans wrote: > On Sat, Dec 22, 2018 at 12:42 AM Konstantin Belousov > wrote: >> >> On Sat, Dec 22, 2018 at 04:38:52AM +0300, Yuri Pankov wrote: >>> Essentially, I need the __collate_equiv_value symbol to be visible to= >>> libregex for the changes in https://reviews.freebsd.org/D18531. Is t= he >>> following change OK (it works, at least), or should try to avoid that= ? >>> >>> --- a/lib/libc/locale/Symbol.map >>> +++ b/lib/libc/locale/Symbol.map >>> @@ -212,6 +212,7 @@ FBSD_1.3 { >>> FBSDprivate_1.0 { >>> _PathLocale; >>> __detect_path_locale; >>> + __collate_equiv_value; >>> __collate_load_error; >>> __collate_range_cmp; >>> }; >>> >> Then libregex must always match the installed libc. >> >> I looked at the the libregex/Makefile and my question is, what is the >> difference between exports from libc/regex vs. libregex. Can libregex= >> become ELF filter for libc ? >> >=20 > libregex is going to be getting more complicated [1] after a couple > more exp-runs. I can possibly re-work it to make a filter work > (perhaps?), but I'm not sure how badly that will impact the > performance of libc regex. >=20 > [1] https://reviews.freebsd.org/D12935 I don't think making libregex a filter for libc will work here as you intend it to have different functionality, even if compiling the same source files. OTOH, the function isn't easily decoupled from libc (if at all) as it needs to know internal implementation details, hence my original question= =2E --LYW4qOyL853LutqVKVOrNn92HCEK76Sb6-- --9RW5owgLvSLpQp7OD8PjwfiyBRvAHcYYN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+Gq3PsPeLT4tL/9wk4vgf7Eq4WwFAlwd5CUACgkQk4vgf7Eq 4Wz7Rwf+PVHFP/S1MqTzY6tzexeIcOWwpz+nXDVYVbJ8OIUwjxy1Inv+o0Re6k0Y LRa7uSfbb0vLbLExcYodmQ7zFJ+LLqJU10xZHpkmLRSxKFecZUvg8hijyuNX6KLh F8D5jbT9BATmms9EwJnc/6BqVdY2DC+Dpx2BvXA2DDjoSfT0HuPR+bJILwyGp+Kd zx/ZIXdyeKjzav3WNuU7SzNsm40HXdz4GySAUiTxWCjb8SwmwEL5rRQZ0Ln5xB9n blhHEcmWOd6fBqCrHTqbCP80N3q4226PtoC6a2zpa9XrWUDqf5V6x1EQzUKPSBUD t4w29DhGYwZMgXSER3BP+xNsnhEitQ== =hOLE -----END PGP SIGNATURE----- --9RW5owgLvSLpQp7OD8PjwfiyBRvAHcYYN-- From owner-freebsd-hackers@freebsd.org Sat Dec 22 14:01:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D5861354AD5 for ; Sat, 22 Dec 2018 14:01:09 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 388AD896A6 for ; Sat, 22 Dec 2018 14:01:06 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FBB92120D for ; Sat, 22 Dec 2018 09:01:06 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Sat, 22 Dec 2018 09:01:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=fm1; bh=9E3F11gFEVEwq97UoFiueu/kYs 6ENi1pnB61zahj7ik=; b=oINC9hRtQQLdyShcD9tXBydYsNfM82KFxaojekih/G aL0K4Ar/Z50MbRqTW9KEfV/rM/j5CiNZkaLGFImUVwen+C2e7WQc6gzDceWrQ3uP kt6jPhsO7lLqjiD2Ebr/AfLsgiYWcFIsChldrf8zJhKoBS0wxks1enpXg8A0GQzo iZ9B+LtcE4Lji+KPcPZ0UU/Ho54Tn8oPfGPowWd1TZ9zW+4Y86C/8CwCK6+Hw/k/ XFSDGx1B0nvqXQX1/C2RleoJGqU60mzP/ae0sTR4V1QuCwQ/pUP5sulPnO07JNS6 AHZ0LJ3hDUgcC8eF2B+WQH2breADWOxdmW7QuLs+OO5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9E3F11 gFEVEwq97UoFiueu/kYs6ENi1pnB61zahj7ik=; b=KvY3XAiUBTxj2JHsReLJ3M pl6a9xYB4Rq/N9ujSgT8SWDGLVEuZykVN5AZ/Xn/iNx8I9bzPtn9WJG2pJC/nZKd n2Mfjv0ChBEE7Ap7vRCAKp5TDgqBo1GWq1gqc0lt8f5/I36W/bXb5V3tHDw7diUa ykpJ9hfd6LbP6dD73q9gXov6IljBu8s8+Jt2J75AAGC5yMoRy9EZcYxAYR1vBSD4 RwLePFjIgXvchFAhwSBA53JBBZOp57FJScML5SWLd64i0iWZUWIsuMnlBFFXEOGX CXqNTDUIuw6qRx7reNfRhIOHvcDsB7FgkVBj8yULOIJvwRsokdHzF8pNrHHV64LQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejjedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtoffuffesthejredtredtjeenucfhrhhomhepff grvhgvucevohhtthhlvghhuhgsvghruceouggthhesshhkuhhnkhifvghrkhhsrdgrtheq necuffhomhgrihhnpehfrhgvvggsshgurdhorhhgpdhfrhgvshhhphhorhhtshdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrthen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 864C14254; Sat, 22 Dec 2018 09:01:05 -0500 (EST) Message-Id: <1545487265.3497867.1616158504.69E513B4@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2f590f9a Subject: rcorder for vpn-like tunnels during early rc.d startup Date: Sat, 22 Dec 2018 15:01:05 +0100 X-Rspamd-Queue-Id: 388AD896A6 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=oINC9hRt; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=KvY3XAiU; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.25 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-7.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[skunkwerks.at]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; MX_GOOD(-0.01)[in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; IP_SCORE(-3.61)[ip: (-9.53), ipnet: 66.111.4.0/24(-4.67), asn: 11403(-3.78), country: US(-0.08)]; RCVD_IN_DNSWL_LOW(-0.10)[25.4.111.66.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 14:01:09 -0000 I have a port[1] net/zerotier that provides a p2p layer2+ vpn via tap(4) interfaces. Ideally zerotier/zt would be available early enough during boot that later daemons such as ssh and other network services would be able to bind to those interfaces. I've tried a variety of tricks to achieve the following outcomes: - start after netif - default route is available so that zt can initialise itself - started before firewalls and later network daemons I have this working for DHCP, but not for statically assigned IPs. Any suggestions on what else I could try? The patch[2] achieves this for DHCP systems, as the default route is made available during `netif`, but for statically assigned systems, it arrives later with `routing`. Trying to include routing in the REQUIRE section results in the expected circular dependency, and the startup daemon hangs in the check loop as the default route isn't available to it yet. # rcorder /usr/local/etc/rc.d/* /etc/rc.d/* |less rcorder: Circular dependency on provision `routing' in file `/usr/local/etc/rc.d/zerotier'. /etc/rc.d/netif /etc/rc.d/devd /etc/rc.d/zfsd /etc/rc.d/ipsec /etc/rc.d/stf /etc/rc.d/defaultroute /etc/rc.d/devfs /usr/local/etc/rc.d/zerotier /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ipfw /etc/rc.d/netwait /etc/rc.d/resolv [1]: https://freshports.org/net/zerotier [2]: https://reviews.freebsd.org/D18533 [3]: https://www.freebsd.org/cgi/man.cgi?query=if_tap A+ Dave From owner-freebsd-hackers@freebsd.org Sat Dec 22 15:19:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DA39135639D for ; Sat, 22 Dec 2018 15:19:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 07E9A8B7DA for ; Sat, 22 Dec 2018 15:18:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id wBMFImW0073326 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Dec 2018 16:18:49 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: dch@skunkwerks.at Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id wBMFIlA7053714 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 22 Dec 2018 22:18:47 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: rcorder for vpn-like tunnels during early rc.d startup To: Dave Cottlehuber , freebsd-hackers@freebsd.org References: <1545487265.3497867.1616158504.69E513B4@webmail.messagingengine.com> From: Eugene Grosbein Message-ID: Date: Sat, 22 Dec 2018 22:18:42 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1545487265.3497867.1616158504.69E513B4@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 07E9A8B7DA X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.875,0]; IP_SCORE(-1.71)[ip: (-3.02), ipnet: 2a01:4f8::/29(-3.01), asn: 24940(-2.49), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 15:19:08 -0000 22.12.2018 21:01, Dave Cottlehuber wrote: > I have a port[1] net/zerotier that provides a p2p layer2+ vpn via tap(4) interfaces. > Ideally zerotier/zt would be available early enough during boot that later daemons > such as ssh and other network services would be able to bind to those interfaces. You should not try to make it start before packet filters, that is wrong and may sometimes even partially defeat security goals of VPN networking. The whole system of FreeBSD rc.d system script dependencies assumes that packet filers initialize before network is fully operational. Take a look at base system's /etc/rc.d/ppp for an example of tunneling daemon that starts as early as possible. Another example is /etc/rc.d/local_unbound that needs fully operating networking but starts early enough to provide DNS services for ssh and others: in FreeBSD 12.0+ it REQUIREs "defaultroute" and "netwait" features. From owner-freebsd-hackers@freebsd.org Sat Dec 22 18:22:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C3681335F82 for ; Sat, 22 Dec 2018 18:22:46 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6133C6BFA0 for ; Sat, 22 Dec 2018 18:22:45 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id wBMIMdNe057792 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 22 Dec 2018 10:22:40 -0800 (PST) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com Subject: Re: rcorder for vpn-like tunnels during early rc.d startup To: Eugene Grosbein , Dave Cottlehuber , freebsd-hackers@freebsd.org References: <1545487265.3497867.1616158504.69E513B4@webmail.messagingengine.com> From: Craig Leres Message-ID: Date: Sat, 22 Dec 2018 10:22:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.2 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-1982-c X-Rspamd-Queue-Id: 6133C6BFA0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:25795, ipnet:2607:f2f8::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 18:22:46 -0000 On 12/22/18 7:18 AM, Eugene Grosbein wrote: > You should not try to make it start before packet filters, that is wrong How should I handle the case where I start several openvpn tunnels and have references to them in my pf.conf? My solution was to write a rc.d script that gives a configured list of tun devices up to a minute to come up and then do a "service pf reload". Craig From owner-freebsd-hackers@freebsd.org Sat Dec 22 18:29:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABB4C133723B for ; Sat, 22 Dec 2018 18:29:12 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D00DB6C32B; Sat, 22 Dec 2018 18:29:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id wBMISrTi074808 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Dec 2018 19:28:54 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: leres@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id wBMISqf0055368 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 23 Dec 2018 01:28:52 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: rcorder for vpn-like tunnels during early rc.d startup To: Craig Leres , Dave Cottlehuber , freebsd-hackers@freebsd.org References: <1545487265.3497867.1616158504.69E513B4@webmail.messagingengine.com> From: Eugene Grosbein Message-ID: <8a8c6e8e-4781-9e03-36cf-b7974cb719bc@grosbein.net> Date: Sun, 23 Dec 2018 01:28:47 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: D00DB6C32B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; IP_SCORE(-1.69)[ip: (-2.98), ipnet: 2a01:4f8::/29(-3.00), asn: 24940(-2.48), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 18:29:12 -0000 23.12.2018 1:22, Craig Leres wrote: > On 12/22/18 7:18 AM, Eugene Grosbein wrote: >> You should not try to make it start before packet filters, that is wrong > > How should I handle the case where I start several openvpn tunnels and have references to them in my pf.conf? My solution was to write a rc.d script that gives a configured list of tun devices up to a minute to come up and then do a "service pf reload". And this is right thing to do :-) I mean, if your filtering rules depend on ever-changing list of interfaces, just reconfigure the filter when the list changes or better teach the filter to catch up with changes automatically, if possible. From owner-freebsd-hackers@freebsd.org Sat Dec 22 19:22:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 448491338B74 for ; Sat, 22 Dec 2018 19:22:39 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 253616DDE2 for ; Sat, 22 Dec 2018 19:22:38 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id r10so8335780wrs.10 for ; Sat, 22 Dec 2018 11:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=exb5ONv+5GASw/5AYlJY3jzClA4RQuAdvPW3C+p7ZXg=; b=S0w6foFjp5ZdNKGkK/AkEej10NI9UddgZuSSZlB+Jaa2uIK1za8JuUELDIii2EB7aq PSmLQ3FA97hQ4RPREfrdOrE+I6VG2YWnfvxv0NxL/BDcbkBBV1Dc34TkSKxO0lv8iM+N qacaRiUZp87hZL3WJmKH97tX6nj3l7qItYNgKzMGFqZIMFdoPeKEpHQBIKjdD2sHNghU UZBuvdKZv+7xLYgoRDlgveSDz7K9jpB9SDgkkcwiDeEpEOGWimyCFTGnwY6pBy8RR6TB /bNOLp100XbJ/Q/ii+etaJapZ9YR6Q8ad6l3C/7HIyZy8oCiUP122VVrnOKzp1RRSdEk etNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=exb5ONv+5GASw/5AYlJY3jzClA4RQuAdvPW3C+p7ZXg=; b=RCwk/bYbU0I9j751tdAPU70K1zmNO70aNrF5OnkC1mdoVXuchn/rC4uevblCiobM/t gqYGp72ZEFs+4Y5kmYMDeJz3ZsBRDZ4UUCfepK954AdPdR9SmA1Z/bbR7zF/fbOeYRPm iN4ld3U229S/lkn5qEU5Asq8oJJx+23kteURR7qShPS1t3bT5YYxPiN+nEDvcbZ7kjm5 VZioOA+z9peK+MGaPwX23kg+UDZspntLQ5ICU3XrK4mqxiaW4iB2s0PwSMBau/2yC9jT 3Lrx2BzSiO/dkc4P7m0onGK+A9t/5zUsBjK4zjVt2D+o1kM6gzNF/UYMWO2sH+6Vab+m o5EA== X-Gm-Message-State: AJcUukeMnwemRksMxR0b/XACx5YImqe6biFo0Or79qFP4FXT8VA9IKuF rVJA4CKKLFhDiccSfEZUKkB8IiKU X-Google-Smtp-Source: ALg8bN7TH/QEr8FYJHmD2XOxtgIVnJO/8Ufoc2MqCcYA4fWUc+O7pQBzU+ixQUeTLZtRyJOkJjAKjA== X-Received: by 2002:a5d:538a:: with SMTP id d10mr6711196wrv.202.1545506555412; Sat, 22 Dec 2018 11:22:35 -0800 (PST) Received: from alffbsd ([95.238.231.159]) by smtp.gmail.com with ESMTPSA id k23sm10099548wmj.32.2018.12.22.11.22.34 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 22 Dec 2018 11:22:34 -0800 (PST) Date: Sat, 22 Dec 2018 20:22:28 +0100 From: Alfonso Siciliano To: freebsd-hackers@freebsd.org Subject: libsysctl: a C API for sysctl-mib-tree Message-Id: <20181222202228.95f48408c8e2ebe9c40d9d75@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 253616DDE2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=S0w6foFj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-5.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; RECEIVED_SPAMHAUS_PBL(0.00)[159.231.238.95.zen.spamhaus.org : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.47)[ip: (-9.14), ipnet: 2a00:1450::/32(-1.67), asn: 15169(-1.46), country: US(-0.08)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 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 Dec 2018 19:22:39 -0000 Hey! I' m currently working on a library called "libsysctl" which will provide a C API to wrap kern_sysctl.c undocumented interface, build mib-entry, entries-list and mib-tree in userspace and then to do the work that /sbin/sysctl currently does. This project started from a wish to write a "sysctl-table" tool (like "top" and "htop" for processes), examples below, so I need to have info about kernel sysctl-mib-tree. The advantages to have libsysctl are: an easy userspace API to the kernel sysctl-mib-tree, building quickly a custom sysctl(8) tool and changes to kern_sysctl.c interface won't upset userspace tools. I am coding on my pc: FreeBSD 13.0-CURRENT amd64 and src are in http://gitlab.com/alfix/libsysctl [0] I could submit a patch to reviews.freebsd.org to solicit feedback and write a wiki page. The README.md [2] shows every function and links to examples [1], anyway the following API overview has extras notes. -- API Overview -- Implementation note: the following functions call sysctl(2) for wrapping 0.[1-6] entries/'kernel state'. Kernel returns only next leaf, nextnode() needs extra computation /* 'undocumented kern_sysctl.c API' wrap functions * return: 0 for success, negative value for failure. */ libsysctl_nametoid(), libsysctl_name(), libsysctl_desc(), libsysctl_label(), libsysctl_info(), libsysctl_nextnode(), libsysctl_next() and libsysctl_nextleaf(); ... EXTRA MACROS ... Note: I prefer to use the following functions: /* "struct libsysctl_object" functions * return: NULL for failure, pointer to heap for success. */ Note: - The following functions use previous functions plus SLIST macros. - "struct libsysctl_object" is a mib-entry in userspace, it is handier than kernel sysctl_oid . - libsysctl_object() and libsysctl_tree() are "conceptually similar" to NetBSD sysctlgetmibinfo(). - libsysctl_grouplist() returns a "linear" tree. - libsysctl_tree() sets .childs so it builds an userspace mib-tree, it is useful to make a custom sysctl tool; I like it :-) . - libsysctl_free*() functions free the heap. SLIST_HEAD(libsysctl_object_list, libsysctl_object); struct libsysctl_object { ... int *id; size_t idlen; char *name; char *desc; char *label; uint8_t type; uint32_t flags; char *fmt; struct libsysctl_object_list *childs; ... }; Note: OR_FLAGS are just the object' s fields to set. struct libsysctl_object * libsysctl_object(id, idlen, OR_FLAGS); struct libsysctl_object_list * libsysctl_filterlist(libsysctl_filterfunc_t *, OR_FLAGS); struct libsysctl_object_list * libsysctl_grouplist(id, idlen, OR_FLAGS, max_depth); struct libsysctl_object * libsysctl_tree(id, idlen, OR_FLAGS, max_edges); libsysctl_freeobject(), libsysctl_freelist() and libsysctl_freetree(). --- Docs --- Files *.c in libsysctl/examples/ show every function. [1] Overview http://gitlab.com/alfix/libsysctl/blob/master/README.md [2] manuals *.3 in libsysctl/doc/ are 'work in progress'. --- Tools using libsysctl --- - "sysctlview 0.1", a sysctl gtk gui tool, http://gitlab.com/alfix/sysctlview [3] - "nsysctl 0.1", sysctl(8) + [-FIlMmSy] + [--libxo], http://gitlab.com/alfix/nsysctl [4] I appreciate any feedback that you can give me. Regards, Alfonso S. Siciliano wiki.freebsd.org/AlfonsoSiciliano LINKS [0] git repo: http://gitlab.com/alfix/libsysctl [1] examples: http://gitlab.com/alfix/libsysctl/examples [2] README.md: http://gitlab.com/alfix/libsysctl/blob/master/README.md [3] sysctlview http://gitlab.com/alfix/sysctlview [4] nsysctl: http://gitlab.com/alfix/nsysctl