Re: svn commit: r367566 - stable/12/sys/compat/linuxkpi/common/include/linux
On 2020-11-10 14:36, Hans Petter Selasky wrote: Author: hselasky Date: Tue Nov 10 13:36:07 2020 New Revision: 367566 URL: https://svnweb.freebsd.org/changeset/base/367566 Log: MFC r366751: Remove ifdefs around IS_ALIGNED() definition in the LinuxKPI. There are reports that this broke drm-fbsd12.0-kmod in stable. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251163 for details. Can you have a look? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r366372 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src conf
On 2020-10-22 15:22, Kyle Evans wrote: On Sat, Oct 17, 2020 at 11:40 AM Warner Losh wrote: On Sat, Oct 17, 2020, 10:11 AM Alexander V. Chernikov wrote: 17.10.2020, 14:07, "Hans Petter Selasky" : On 2020-10-17 14:34, Alexander V. Chernikov wrote: 17.10.2020, 12:32, "Hans Petter Selasky" : On 2020-10-17 13:27, Alexander V. Chernikov wrote: 02.10.2020, 19:26, "Emmanuel Vadot" mailto:m...@freebsd.org>>: Author: manu Date: Fri Oct 2 18:26:41 2020 New Revision: 366372 URL: https://svnweb.freebsd.org/changeset/base/366372 Log: linuxkpi: Add backlight support Add backlight function to linuxkpi. Graphics drivers expose the backlight of the panel directly so allow them to use the backlight subsystem so user can use backlight(8) to configure them. Reviewed by: hselasky Relnotes: yes Differential Revision: The FreeBSD Foundation Added: head/sys/compat/linuxkpi/common/include/linux/backlight.h (contents, props changed) Modified: head/sys/compat/linuxkpi/common/include/linux/device.h head/sys/compat/linuxkpi/common/src/linux_kmod.c head/sys/compat/linuxkpi/common/src/linux_pci.c head/sys/conf/kmod.mk It breaks the build for me with /usr/home/melifaro/free/head/sys/compat/linuxkpi/common/src/linux_pci.c:70:10: fatal error: 'backlight_if.h' file not found How do you build? Doesn't break over here. GENERIC + COMPAT_LINUXKPI. Try adding: options backlight To the kernel config. Yep, thank you! Maybe it's worth considering adding static assert with the message describing this dependency? Yes. It likely is worth doing something to highlight this issue. Warner I think we just need to slap the two core backlight files with an ` | compat_linux` so that they simply get pulled in if you specify COMPAT_LINUX. config(8) handles this terribly, configng must have a better provides/requires/implies/whatever functionality so we can specify that compat_linux implies backlight and not do crud like this where it becomes more complicated to see what any given option really entails. Thanks, COMPAT_LINUX can't be right. Isn't that the linuxolator? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r366263 - in releng/12.2/usr.sbin: bsdconfig/share/media bsdinstall/scripts
Author: zeising (doc,ports committer) Date: Tue Sep 29 17:22:14 2020 New Revision: 366263 URL: https://svnweb.freebsd.org/changeset/base/366263 Log: MF stable/12 r366258: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. Approved by: re (gjb), emaste Modified: releng/12.2/usr.sbin/bsdconfig/share/media/ftp.subr releng/12.2/usr.sbin/bsdinstall/scripts/mirrorselect Directory Properties: releng/12.2/ (props changed) Modified: releng/12.2/usr.sbin/bsdconfig/share/media/ftp.subr == --- releng/12.2/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 17:09:43 2020(r366262) +++ releng/12.2/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 17:22:14 2020(r366263) @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() ' IPv6 $msg_japan''ftp2.jp.freebsd.org' ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' '$msg_primary''ftp1.freebsd.org' ' $msg_primary #2''ftp2.freebsd.org' ' $msg_primary #3''ftp3.freebsd.org' @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() ' $msg_primary #12' 'ftp12.freebsd.org' ' $msg_primary #13' 'ftp13.freebsd.org' ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_armenia''ftp1.am.freebsd.org' '$msg_australia' 'ftp.au.freebsd.org' ' $msg_australia #2' 'ftp2.au.freebsd.org' ' $msg_australia #3' 'ftp3.au.freebsd.org' @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() '$msg_brazil' 'ftp2.br.freebsd.org' ' $msg_brazil #3' 'ftp3.br.freebsd.org' ' $msg_brazil #4' 'ftp4.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' '$msg_china' 'ftp.cn.freebsd.org' '$msg_czech_republic' 'ftp.cz.freebsd.org' '$msg_denmark''ftp.dk.freebsd.org' - '$msg_estonia''ftp.ee.freebsd.org' '$msg_finland''ftp.fi.freebsd.org' '$msg_france' 'ftp.fr.freebsd.org' ' $msg_france #3' 'ftp3.fr.freebsd.org' @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() ' $msg_germany #2''ftp2.de.freebsd.org' ' $msg_germany #4''ftp4.de.freebsd.org' ' $msg_germany #5''ftp5.de.freebsd.org' - ' $msg_germany #6''ftp6.de.freebsd.org' ' $msg_germany #7''ftp7.de.freebsd.org' ' $msg_germany #8''ftp8.de.freebsd.org' '$msg_greece' 'ftp.gr.freebsd.org' ' $msg_greece #2' 'ftp2.gr.freebsd.org' '$msg_ireland''ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' '$msg_japan' 'ftp.jp.freebsd.org' ' $msg_japan #2' 'ftp2.jp.freebsd.org' ' $msg_japan #3' 'ftp3.jp.freebsd.org' @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() '$msg_korea' 'ftp.kr.freebsd.org' ' $msg_korea #2' 'ftp2.kr.freebsd.org' '$msg_latvia' 'ftp.lv.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' '$msg_netherlands''ftp.nl.freebsd.org' ' $msg_netherlands #2''ftp2.nl.freebsd.org' '$msg_new_zealand''ftp.nz.freebsd.org' '$msg_norway' 'ftp.no.freebsd.org' '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' '$msg_russia' 'ftp.ru.freebsd.org' ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' ' $msg_russia #5' 'ftp5.ru.freebsd.org' ' $msg_russia #6' 'ftp6.ru.freebsd.org' '$msg_slovak_republic''ftp.sk.freebsd.org' @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() '$msg_south_africa' 'ftp.za.freebsd.org' ' $msg_south_africa #2' 'ftp2.za.freebsd.org' ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' '$msg_sweden' 'ftp.se.freebsd.org'
svn commit: r366259 - in stable/11/usr.sbin: bsdconfig/share/media bsdinstall/scripts
Author: zeising (doc,ports committer) Date: Tue Sep 29 15:37:57 2020 New Revision: 366259 URL: https://svnweb.freebsd.org/changeset/base/366259 Log: MFC r366186: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. Approved by: emaste Modified: stable/11/usr.sbin/bsdconfig/share/media/ftp.subr stable/11/usr.sbin/bsdinstall/scripts/mirrorselect Directory Properties: stable/11/ (props changed) Modified: stable/11/usr.sbin/bsdconfig/share/media/ftp.subr == --- stable/11/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 15:37:33 2020(r366258) +++ stable/11/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 15:37:57 2020(r366259) @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() ' IPv6 $msg_japan''ftp2.jp.freebsd.org' ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' '$msg_primary''ftp1.freebsd.org' ' $msg_primary #2''ftp2.freebsd.org' ' $msg_primary #3''ftp3.freebsd.org' @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() ' $msg_primary #12' 'ftp12.freebsd.org' ' $msg_primary #13' 'ftp13.freebsd.org' ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_armenia''ftp1.am.freebsd.org' '$msg_australia' 'ftp.au.freebsd.org' ' $msg_australia #2' 'ftp2.au.freebsd.org' ' $msg_australia #3' 'ftp3.au.freebsd.org' @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() '$msg_brazil' 'ftp2.br.freebsd.org' ' $msg_brazil #3' 'ftp3.br.freebsd.org' ' $msg_brazil #4' 'ftp4.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' '$msg_china' 'ftp.cn.freebsd.org' '$msg_czech_republic' 'ftp.cz.freebsd.org' '$msg_denmark''ftp.dk.freebsd.org' - '$msg_estonia''ftp.ee.freebsd.org' '$msg_finland''ftp.fi.freebsd.org' '$msg_france' 'ftp.fr.freebsd.org' ' $msg_france #3' 'ftp3.fr.freebsd.org' @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() ' $msg_germany #2''ftp2.de.freebsd.org' ' $msg_germany #4''ftp4.de.freebsd.org' ' $msg_germany #5''ftp5.de.freebsd.org' - ' $msg_germany #6''ftp6.de.freebsd.org' ' $msg_germany #7''ftp7.de.freebsd.org' ' $msg_germany #8''ftp8.de.freebsd.org' '$msg_greece' 'ftp.gr.freebsd.org' ' $msg_greece #2' 'ftp2.gr.freebsd.org' '$msg_ireland''ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' '$msg_japan' 'ftp.jp.freebsd.org' ' $msg_japan #2' 'ftp2.jp.freebsd.org' ' $msg_japan #3' 'ftp3.jp.freebsd.org' @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() '$msg_korea' 'ftp.kr.freebsd.org' ' $msg_korea #2' 'ftp2.kr.freebsd.org' '$msg_latvia' 'ftp.lv.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' '$msg_netherlands''ftp.nl.freebsd.org' ' $msg_netherlands #2''ftp2.nl.freebsd.org' '$msg_new_zealand''ftp.nz.freebsd.org' '$msg_norway' 'ftp.no.freebsd.org' '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' '$msg_russia' 'ftp.ru.freebsd.org' ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' ' $msg_russia #5' 'ftp5.ru.freebsd.org' ' $msg_russia #6' 'ftp6.ru.freebsd.org' '$msg_slovak_republic''ftp.sk.freebsd.org' @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() '$msg_south_africa' 'ftp.za.freebsd.org' ' $msg_south_africa #2' 'ftp2.za.freebsd.org' ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' '$msg_sweden' 'ftp.se.freebsd.org' ' $msg_sweden #2' 'f
svn commit: r366258 - in stable/12/usr.sbin: bsdconfig/share/media bsdinstall/scripts
Author: zeising (doc,ports committer) Date: Tue Sep 29 15:37:33 2020 New Revision: 366258 URL: https://svnweb.freebsd.org/changeset/base/366258 Log: MFC r366186: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. Approved by: emaste Modified: stable/12/usr.sbin/bsdconfig/share/media/ftp.subr stable/12/usr.sbin/bsdinstall/scripts/mirrorselect Directory Properties: stable/12/ (props changed) Modified: stable/12/usr.sbin/bsdconfig/share/media/ftp.subr == --- stable/12/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 15:10:56 2020(r366257) +++ stable/12/usr.sbin/bsdconfig/share/media/ftp.subr Tue Sep 29 15:37:33 2020(r366258) @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() ' IPv6 $msg_japan''ftp2.jp.freebsd.org' ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' '$msg_primary''ftp1.freebsd.org' ' $msg_primary #2''ftp2.freebsd.org' ' $msg_primary #3''ftp3.freebsd.org' @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() ' $msg_primary #12' 'ftp12.freebsd.org' ' $msg_primary #13' 'ftp13.freebsd.org' ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_armenia''ftp1.am.freebsd.org' '$msg_australia' 'ftp.au.freebsd.org' ' $msg_australia #2' 'ftp2.au.freebsd.org' ' $msg_australia #3' 'ftp3.au.freebsd.org' @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() '$msg_brazil' 'ftp2.br.freebsd.org' ' $msg_brazil #3' 'ftp3.br.freebsd.org' ' $msg_brazil #4' 'ftp4.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' '$msg_china' 'ftp.cn.freebsd.org' '$msg_czech_republic' 'ftp.cz.freebsd.org' '$msg_denmark''ftp.dk.freebsd.org' - '$msg_estonia''ftp.ee.freebsd.org' '$msg_finland''ftp.fi.freebsd.org' '$msg_france' 'ftp.fr.freebsd.org' ' $msg_france #3' 'ftp3.fr.freebsd.org' @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() ' $msg_germany #2''ftp2.de.freebsd.org' ' $msg_germany #4''ftp4.de.freebsd.org' ' $msg_germany #5''ftp5.de.freebsd.org' - ' $msg_germany #6''ftp6.de.freebsd.org' ' $msg_germany #7''ftp7.de.freebsd.org' ' $msg_germany #8''ftp8.de.freebsd.org' '$msg_greece' 'ftp.gr.freebsd.org' ' $msg_greece #2' 'ftp2.gr.freebsd.org' '$msg_ireland''ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' '$msg_japan' 'ftp.jp.freebsd.org' ' $msg_japan #2' 'ftp2.jp.freebsd.org' ' $msg_japan #3' 'ftp3.jp.freebsd.org' @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() '$msg_korea' 'ftp.kr.freebsd.org' ' $msg_korea #2' 'ftp2.kr.freebsd.org' '$msg_latvia' 'ftp.lv.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' '$msg_netherlands''ftp.nl.freebsd.org' ' $msg_netherlands #2''ftp2.nl.freebsd.org' '$msg_new_zealand''ftp.nz.freebsd.org' '$msg_norway' 'ftp.no.freebsd.org' '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' '$msg_russia' 'ftp.ru.freebsd.org' ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' ' $msg_russia #5' 'ftp5.ru.freebsd.org' ' $msg_russia #6' 'ftp6.ru.freebsd.org' '$msg_slovak_republic''ftp.sk.freebsd.org' @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() '$msg_south_africa' 'ftp.za.freebsd.org' ' $msg_south_africa #2' 'ftp2.za.freebsd.org' ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' '$msg_sweden' 'ftp.se.freebsd.org' ' $msg_sweden #2' 'f
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-29 17:26, Scott Long wrote: On Sep 27, 2020, at 2:41 AM, Niclas Zeising wrote: On 2020-09-27 03:38, Scott Long wrote: On Sep 26, 2020, at 5:24 PM, Rodney W. Grimes wrote: On Sep 26, 2020, at 1:22 PM, Warner Losh wrote: I am the wrong person to answer that question. In this case, things have not become lame. For instance, the names ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are removed. Same for ru.freebsd.org and ftp4.ru. I'm merely pointing out that changing ftp.CC.freebsd.org usually requires contacting the person(s) maintaining the CC.freebsd.org zone, which is usually not the project. It's usually people associated with the project in some way, but who might not be as responsive as cluster admin. These domains have been delegated, so we have to get the delegated admin to make the changes, which can take a bit of time to chase down and doesn't lend itself to easy / automated coping with this situation. Just a spitball idea here, but maybe we should consider not embedding these lists of mirror URLs into the binaries. It seems pretty straight-forward that the list evolves over time, and that evolution is not tightly coupled with the updating of the binaries. It sounds like the pkg and freebsd-update infrastructure use DNS TXT and/or SRV records to point to the metadata needed to construct a mirror URL list dynamically. Maybe something similar can be done for bsdconfig? If it?s not a crazy idea, is there anyone who would be interested in helping me write a proposal over at arch@? 100% behind that idea! Especially since it seems the project has lost (some) control over its DNS space, which IMHO, is still an issue, if the people whom DNS zones have been deligated to are not responsive that should also Words of agreement don’t help at the moment, though i appreciate your enthusiasm. Would you he able to help write a proposal for the arch@ mailing list? I think this is the wrong approach, and the better approach is to have the official installer use download.freebsd.org (which already is geo-located). I also feel like this is probably something that core and possibly clusteradm should weigh in on, since it affects how we distribute FreeBSD. My impression was that we were generally trying to move away from mirrors hosted by various people and organizations all over the world, where we have little control, to our own mirrors behind download.freebsd.org. If this is the case, perhaps we should do so in the installer as well. I’m totally fine with this. Also, I don’t speak for core on my own, but I am part of core. We’re trying to encourage public discussion and participation on these kinds of issues, so that’s why I’m suggesting that this conversation should move to an appropriate mailing list. I'll try to come up with something that uses download.freebsd.org, and send it out for discussion. I'm not sure I can make it in time for 12.2 though, so in the meantime I'll MFC this commit and ask re@ about getting it into 12.2. That way users won't stumble over the obviously dead mirrors while we discuss a better approach for the future. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-27 03:38, Scott Long wrote: On Sep 26, 2020, at 5:24 PM, Rodney W. Grimes wrote: On Sep 26, 2020, at 1:22 PM, Warner Losh wrote: I am the wrong person to answer that question. In this case, things have not become lame. For instance, the names ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are removed. Same for ru.freebsd.org and ftp4.ru. I'm merely pointing out that changing ftp.CC.freebsd.org usually requires contacting the person(s) maintaining the CC.freebsd.org zone, which is usually not the project. It's usually people associated with the project in some way, but who might not be as responsive as cluster admin. These domains have been delegated, so we have to get the delegated admin to make the changes, which can take a bit of time to chase down and doesn't lend itself to easy / automated coping with this situation. Just a spitball idea here, but maybe we should consider not embedding these lists of mirror URLs into the binaries. It seems pretty straight-forward that the list evolves over time, and that evolution is not tightly coupled with the updating of the binaries. It sounds like the pkg and freebsd-update infrastructure use DNS TXT and/or SRV records to point to the metadata needed to construct a mirror URL list dynamically. Maybe something similar can be done for bsdconfig? If it?s not a crazy idea, is there anyone who would be interested in helping me write a proposal over at arch@? 100% behind that idea! Especially since it seems the project has lost (some) control over its DNS space, which IMHO, is still an issue, if the people whom DNS zones have been deligated to are not responsive that should also Words of agreement don’t help at the moment, though i appreciate your enthusiasm. Would you he able to help write a proposal for the arch@ mailing list? I think this is the wrong approach, and the better approach is to have the official installer use download.freebsd.org (which already is geo-located). I also feel like this is probably something that core and possibly clusteradm should weigh in on, since it affects how we distribute FreeBSD. My impression was that we were generally trying to move away from mirrors hosted by various people and organizations all over the world, where we have little control, to our own mirrors behind download.freebsd.org. If this is the case, perhaps we should do so in the installer as well. That said, I'm not opposed to the idea of using DNS SRV/TXT records to construct mirror lists, especially if we want to keep on using those mirrors. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-26 20:28, Rodney W. Grimes wrote: On 2020-09-26 20:12, Rodney W. Grimes wrote: Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. This seems like the wrong place to fix it, as this does nothing for all the "shipped" releases that contain the old values. Shouldnt these all just be CNAMED in dns to a nearest replacement resource? Considering that we don't actually have control of the subdomans (CC.freebsd.org) ourselves, that is trickier than it might sound. How can freebsd.org NOT have ultimate control over deligations? If things have become "lame" in a deligated zone the deligation can and should be pulled and replaced with local data. This is cc.freebsd.org, not freebsd.org.cc! I am the wrong person to answer that question. In this case, things have not become lame. For instance, the names ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are removed. Same for ru.freebsd.org and ftp4.ru. I'm merely pointing out that changing ftp.CC.freebsd.org usually requires contacting the person(s) maintaining the CC.freebsd.org zone, which is usually not the project. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
On 2020-09-26 20:12, Rodney W. Grimes wrote: Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. This seems like the wrong place to fix it, as this does nothing for all the "shipped" releases that contain the old values. Shouldnt these all just be CNAMED in dns to a nearest replacement resource? Considering that we don't actually have control of the subdomans (CC.freebsd.org) ourselves, that is trickier than it might sound. I do not oppose that change, but I'm not doing the work to chase all the subdomain DNS admins down to try to fix it. This change cleans out some old mirrors for the 12.2 release, so that people installing 12.2 (and later stuff) won't have the installer complain when they accidentally pick a nonexistent mirror. I believe that the proper way to fix this is to just use the FreeBSD CDN even for these downloads (basically, go straight to download.freebsd.org, or at least have that as the preferred option), but I haven't gotten around to that. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts
Author: zeising (doc,ports committer) Date: Sat Sep 26 16:27:09 2020 New Revision: 366186 URL: https://svnweb.freebsd.org/changeset/base/366186 Log: bsdconfig, bsdinstall: Prune dead mirrors Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall. All these return NXDOMAIN when trying to resolve them. Reviewed by: emaste Approved by: emaste MFC after:3 days Differential Revision:https://reviews.freebsd.org/D26535 Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr head/usr.sbin/bsdinstall/scripts/mirrorselect Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr == --- head/usr.sbin/bsdconfig/share/media/ftp.subrSat Sep 26 14:44:58 2020(r366185) +++ head/usr.sbin/bsdconfig/share/media/ftp.subrSat Sep 26 16:27:09 2020(r366186) @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp() ' IPv6 $msg_japan''ftp2.jp.freebsd.org' ' IPv6 $msg_sweden' 'ftp4.se.freebsd.org' ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' '$msg_primary''ftp1.freebsd.org' ' $msg_primary #2''ftp2.freebsd.org' ' $msg_primary #3''ftp3.freebsd.org' @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp() ' $msg_primary #12' 'ftp12.freebsd.org' ' $msg_primary #13' 'ftp13.freebsd.org' ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_armenia''ftp1.am.freebsd.org' '$msg_australia' 'ftp.au.freebsd.org' ' $msg_australia #2' 'ftp2.au.freebsd.org' ' $msg_australia #3' 'ftp3.au.freebsd.org' @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp() '$msg_brazil' 'ftp2.br.freebsd.org' ' $msg_brazil #3' 'ftp3.br.freebsd.org' ' $msg_brazil #4' 'ftp4.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' '$msg_china' 'ftp.cn.freebsd.org' '$msg_czech_republic' 'ftp.cz.freebsd.org' '$msg_denmark''ftp.dk.freebsd.org' - '$msg_estonia''ftp.ee.freebsd.org' '$msg_finland''ftp.fi.freebsd.org' '$msg_france' 'ftp.fr.freebsd.org' ' $msg_france #3' 'ftp3.fr.freebsd.org' @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp() ' $msg_germany #2''ftp2.de.freebsd.org' ' $msg_germany #4''ftp4.de.freebsd.org' ' $msg_germany #5''ftp5.de.freebsd.org' - ' $msg_germany #6''ftp6.de.freebsd.org' ' $msg_germany #7''ftp7.de.freebsd.org' ' $msg_germany #8''ftp8.de.freebsd.org' '$msg_greece' 'ftp.gr.freebsd.org' ' $msg_greece #2' 'ftp2.gr.freebsd.org' '$msg_ireland''ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' '$msg_japan' 'ftp.jp.freebsd.org' ' $msg_japan #2' 'ftp2.jp.freebsd.org' ' $msg_japan #3' 'ftp3.jp.freebsd.org' @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp() '$msg_korea' 'ftp.kr.freebsd.org' ' $msg_korea #2' 'ftp2.kr.freebsd.org' '$msg_latvia' 'ftp.lv.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' '$msg_netherlands''ftp.nl.freebsd.org' ' $msg_netherlands #2''ftp2.nl.freebsd.org' '$msg_new_zealand''ftp.nz.freebsd.org' '$msg_norway' 'ftp.no.freebsd.org' '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' '$msg_russia' 'ftp.ru.freebsd.org' ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' ' $msg_russia #5' 'ftp5.ru.freebsd.org' ' $msg_russia #6' 'ftp6.ru.freebsd.org' '$msg_slovak_republic''ftp.sk.freebsd.org' @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp() '$msg_south_africa' 'ftp.za.freebsd.org' ' $msg_south_africa #2' 'ftp2.za.freebsd.org' ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' '$msg_sweden' 'ftp.se.freebsd.org'
Re: svn commit: r365640 - in head: share/man/man5 share/man/man7 tools/build/options
On 2020-09-13 07:57, Gordon Bergling wrote: Hi Niclas, On Sat, Sep 12, 2020 at 09:13:33PM +0200, Niclas Zeising wrote: On 2020-09-11 20:09, Gordon Bergling wrote: Author: gbe (doc committer) Date: Fri Sep 11 18:09:49 2020 New Revision: 365640 URL: https://svnweb.freebsd.org/changeset/base/365640 Log: Improvements for the src.conf(5) and build(7) man pages PR: 203863 (based on) Submitted by: Russell Haley Reviewed by:bcr, imp Approved by:imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D26343 Modified: head/share/man/man5/src.conf.5 head/share/man/man7/build.7 head/tools/build/options/makeman Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Fri Sep 11 17:05:09 2020 (r365639) +++ head/share/man/man5/src.conf.5 Fri Sep 11 18:09:49 2020 (r365640) @@ -1,6 +1,6 @@ .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman. As the comment above hints, this file is generated by a tool, and should not be edited directly. This will be overwritten the next time someone regenerates the manual page. You have to update the template in tools/build/options/makeman and regenerate the manual from there. I did updated 'tools/build/options/makeman' with this commit. I justed commited the newly generated src.conf.5 alongside and not with a separate commit. Sorry about that, I should have seen it in the commit log. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365640 - in head: share/man/man5 share/man/man7 tools/build/options
On 2020-09-11 20:09, Gordon Bergling wrote: Author: gbe (doc committer) Date: Fri Sep 11 18:09:49 2020 New Revision: 365640 URL: https://svnweb.freebsd.org/changeset/base/365640 Log: Improvements for the src.conf(5) and build(7) man pages PR: 203863 (based on) Submitted by:Russell Haley Reviewed by: bcr, imp Approved by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D26343 Modified: head/share/man/man5/src.conf.5 head/share/man/man7/build.7 head/tools/build/options/makeman Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Fri Sep 11 17:05:09 2020 (r365639) +++ head/share/man/man5/src.conf.5 Fri Sep 11 18:09:49 2020 (r365640) @@ -1,6 +1,6 @@ .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman. As the comment above hints, this file is generated by a tool, and should not be edited directly. This will be overwritten the next time someone regenerates the manual page. You have to update the template in tools/build/options/makeman and regenerate the manual from there. .\" $FreeBSD$ -.Dd September 8, 2020 +.Dd September 11, 2020 .Dt SRC.CONF 5 .Os .Sh NAME @@ -9,7 +9,8 @@ .Sh DESCRIPTION The .Nm -file contains settings that will apply to every build involving the +file contains variables that control what components will be generated during +the build process of the .Fx source tree; see .Xr build 7 . Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365377 - stable/12/sys/dev/drm2
Author: zeising (doc,ports committer)
Date: Sun Sep 6 11:29:06 2020
New Revision: 365377
URL: https://svnweb.freebsd.org/changeset/base/365377
Log:
MFC: r364737, r365264 and r365287
Together, these three revisions improve the drm2 (aka legacy drm or
drm-legacy) drivers to point towards graphics/drm-kmod where relevant, and
to remove references to graphics/drm-legacy-kmd as that is being deprecated.
Since part of the drm2 drivers are still used on arm, arm is currently
excluded from the deprecation message.
Approved by: imp, manu (implicit, MFC)
Modified:
stable/12/sys/dev/drm2/drm_os_freebsd.c
stable/12/sys/dev/drm2/drm_os_freebsd.h
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dev/drm2/drm_os_freebsd.c
==
--- stable/12/sys/dev/drm2/drm_os_freebsd.c Sun Sep 6 11:23:58 2020
(r365376)
+++ stable/12/sys/dev/drm2/drm_os_freebsd.c Sun Sep 6 11:29:06 2020
(r365377)
@@ -126,7 +126,9 @@ drm_probe_helper(device_t kdev, const drm_pci_id_list_
device_get_nameunit(kdev), id_entry->name);
device_set_desc(kdev, id_entry->name);
}
+#if !defined(__arm__)
DRM_OBSOLETE(kdev);
+#endif
return (-BUS_PROBE_GENERIC);
}
Modified: stable/12/sys/dev/drm2/drm_os_freebsd.h
==
--- stable/12/sys/dev/drm2/drm_os_freebsd.h Sun Sep 6 11:23:58 2020
(r365376)
+++ stable/12/sys/dev/drm2/drm_os_freebsd.h Sun Sep 6 11:29:06 2020
(r365377)
@@ -154,19 +154,21 @@ typedef void irqreturn_t;
*(volatile u_int64_t *)(((vm_offset_t)(map)->handle) + \
(vm_offset_t)(offset)) = htole64(val)
-#ifdef amd64
-#define DRM_PORT "graphics/drm-kmod"
+#if !defined(__arm__)
+#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__) ||
defined(__aarch64__)
+#define DRM_MSG "This code is deprecated. Install the graphics/drm-kmod pkg\n"
#else
-#define DRM_PORT "graphics/drm-legacy-kmod"
+#define DRM_MSG "This code is deprecated."
#endif
#define DRM_OBSOLETE(dev)
\
do {
\
device_printf(dev,
"===\n"); \
- device_printf(dev, "This code is obsolete abandonware. Install the "
DRM_PORT " pkg\n"); \
+ device_printf(dev, DRM_MSG);
\
device_printf(dev,
"===\n"); \
gone_in_dev(dev, 13, "drm2 drivers");
\
} while (0)
+#endif /* __arm__ */
/* DRM_READMEMORYBARRIER() prevents reordering of reads.
* DRM_WRITEMEMORYBARRIER() prevents reordering of writes.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365376 - stable/12/sys/dev/drm
Author: zeising (doc,ports committer)
Date: Sun Sep 6 11:23:58 2020
New Revision: 365376
URL: https://svnweb.freebsd.org/changeset/base/365376
Log:
drm: Update deprecation message
Update the deprecation message in the drm1 (aka legacy drm or drm-legacy)
drivers to not point towards the drm-legacy-kmod port, as that is being
deprecated.
This is a direct commit to stable/12 since the drm1 code has been removed
from 13 already.
Reviewed by: imp
Approved by: imp
Differential Revision:https://reviews.freebsd.org/D26175
Modified:
stable/12/sys/dev/drm/drm.h
Modified: stable/12/sys/dev/drm/drm.h
==
--- stable/12/sys/dev/drm/drm.h Sun Sep 6 10:23:13 2020(r365375)
+++ stable/12/sys/dev/drm/drm.h Sun Sep 6 11:23:58 2020(r365376)
@@ -1145,12 +1145,10 @@ typedef struct drm_mm_init_arg drm_mm_init_arg_t;
typedef enum drm_bo_type drm_bo_type_t;
#endif
-#define DRM_PORT "graphics/drm-legacy-kmod"
-
#define DRM_OBSOLETE(dev)
\
do {
\
device_printf(dev,
"===\n"); \
- device_printf(dev, "This code is obsolete abandonware. Install the "
DRM_PORT " pkg\n"); \
+ device_printf(dev, "This code is deprecated.\n"); \
device_printf(dev,
"===\n"); \
gone_in_dev(dev, 13, "drm drivers");
\
} while (0)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r365264 - head/sys/dev/drm2
On 2020-09-03 06:11, Ravi Pokala wrote:
This appears to have broken tinderbox:
[${SRCTOP}] rpokala% less _.arm.TEGRA124
...
${SRCTOP}/sys/dev/drm2/drm_os_freebsd.c:129:3: error: implicit declaration
of function 'DRM_OBSOLETE' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
DRM_OBSOLETE(kdev);
^
Yeah, sorry about that.
Should be fixed in 365287.
ponty_hat_collection++;
Regards
--
Niclas Zeising
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365287 - head/sys/dev/drm2
Author: zeising (doc,ports committer) Date: Thu Sep 3 05:25:39 2020 New Revision: 365287 URL: https://svnweb.freebsd.org/changeset/base/365287 Log: drm2: Fix build after r365264 Fix the build after r365264, I forgot to exclude arm in one more place. Reported by: rpokala Approved by: manu (implicit, build fix) MFC after:3 days X-MFC-With: 365264 Pointy-hat to:zeising Modified: head/sys/dev/drm2/drm_os_freebsd.c Modified: head/sys/dev/drm2/drm_os_freebsd.c == --- head/sys/dev/drm2/drm_os_freebsd.c Thu Sep 3 03:48:42 2020 (r365286) +++ head/sys/dev/drm2/drm_os_freebsd.c Thu Sep 3 05:25:39 2020 (r365287) @@ -126,7 +126,9 @@ drm_probe_helper(device_t kdev, const drm_pci_id_list_ device_get_nameunit(kdev), id_entry->name); device_set_desc(kdev, id_entry->name); } +#if !defined(__arm__) DRM_OBSOLETE(kdev); +#endif return (-BUS_PROBE_GENERIC); } ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r365264 - head/sys/dev/drm2
Author: zeising (doc,ports committer)
Date: Wed Sep 2 18:04:49 2020
New Revision: 365264
URL: https://svnweb.freebsd.org/changeset/base/365264
Log:
drm2: Further improve deprecation message
Further improve the drm2 deprecation message, only displaying information
about the port for relevant architectures, and skipping the message
completely from arm, which uses some parts of drm2 still.
This is mostly intended to be merged to 12, since the base bits of drm2 on
FreeBSD 13 are only really used on arm.
Reviewed by: manu, mmel
Approved by: manu
MFC after:3 days
X-MFC-with: r364737
Differential Revision:https://reviews.freebsd.org/D26275
Modified:
head/sys/dev/drm2/drm_os_freebsd.h
Modified: head/sys/dev/drm2/drm_os_freebsd.h
==
--- head/sys/dev/drm2/drm_os_freebsd.h Wed Sep 2 17:46:56 2020
(r365263)
+++ head/sys/dev/drm2/drm_os_freebsd.h Wed Sep 2 18:04:49 2020
(r365264)
@@ -154,15 +154,21 @@ typedef void irqreturn_t;
*(volatile u_int64_t *)(((vm_offset_t)(map)->handle) + \
(vm_offset_t)(offset)) = htole64(val)
-#define DRM_PORT "graphics/drm-kmod"
+#if !defined(__arm__)
+#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__) ||
defined(__aarch64__)
+#define DRM_MSG "This code is deprecated. Install the graphics/drm-kmod pkg\n"
+#else
+#define DRM_MSG "This code is deprecated."
+#endif
#define DRM_OBSOLETE(dev)
\
do {
\
device_printf(dev,
"===\n"); \
- device_printf(dev, "This code is deprecated. Install the " DRM_PORT "
pkg\n"); \
+ device_printf(dev, DRM_MSG);
\
device_printf(dev,
"===\n"); \
gone_in_dev(dev, 13, "drm2 drivers");
\
} while (0)
+#endif /* __arm__ */
/* DRM_READMEMORYBARRIER() prevents reordering of reads.
* DRM_WRITEMEMORYBARRIER() prevents reordering of writes.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r364737 - head/sys/dev/drm2
On 2020-09-01 16:19, Emmanuel Vadot wrote: On Tue, 1 Sep 2020 15:32:18 +0200 Niclas Zeising wrote: On 2020-09-01 15:16, Emmanuel Vadot wrote: On Tue, 1 Sep 2020 15:13:53 +0200 Michal Meloun wrote: On 25.08.2020 0:53, Niclas Zeising wrote: Author: zeising (doc,ports committer) Date: Mon Aug 24 22:53:23 2020 New Revision: 364737 URL: https://svnweb.freebsd.org/changeset/base/364737 Log: drm2: Update deprecation message Update the deprecation message in the drm2 (aka legacy drm) drivers to point towards the graphics/drm-kmod ports for all architectures, not just amd64. Only known user of drm2 is arm/tegra124 based boards. How graphics/drm-kmod can help for these? Or be more specific - drm2 allows me to hot-plug monitor to tegra based board an use 2 scaled overlay planes (which is exactly whats I want for my application). Which alternative can you offer me? Btw, as you can see, the maintenance cost of drm2 is close to zero and the dev/drm2 code does not inherit with any of the major architectures. Michal I think that the goal was only to mfc this to warn users before 12.2 is branched, maybe a direct commit to 12 would have been better. No, the change is correct. drm-legacy-kmod (the port) is going away, especially on FreeBSD 13, since it is preventing updates to the FreeBSD VM subsystem. I sent an-email about this to a variety of lists about a week ago. I do know that there are a few special users of drm2 in FreeBSD current, I do not know how those are affected. Since, on FreeBSD current, most architectures can use drm-kmod, I believe it is good to point everyone towards that ports, instead of pointing everyone except amd64 users to drm-legacy-kmod. Regards -- Niclas Zeising drm2 in src is only used for arm, so as Michal wrote in another email the warning will be seen only for tegra users, the mfc'ed commit will be seen by intel/amd ones though. I still have to make a general change that can be MFCd. And pointing arm tegra users to drm-legacy-kmod is equally wrong. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r364737 - head/sys/dev/drm2
On 2020-09-01 16:10, Michal Meloun wrote: On 01.09.2020 15:32, Niclas Zeising wrote: On 2020-09-01 15:16, Emmanuel Vadot wrote: On Tue, 1 Sep 2020 15:13:53 +0200 Michal Meloun wrote: On 25.08.2020 0:53, Niclas Zeising wrote: Author: zeising (doc,ports committer) Date: Mon Aug 24 22:53:23 2020 New Revision: 364737 URL: https://svnweb.freebsd.org/changeset/base/364737 Log: drm2: Update deprecation message Update the deprecation message in the drm2 (aka legacy drm) drivers to point towards the graphics/drm-kmod ports for all architectures, not just amd64. Only known user of drm2 is arm/tegra124 based boards. How graphics/drm-kmod can help for these? Or be more specific - drm2 allows me to hot-plug monitor to tegra based board an use 2 scaled overlay planes (which is exactly whats I want for my application). Which alternative can you offer me? Btw, as you can see, the maintenance cost of drm2 is close to zero and the dev/drm2 code does not inherit with any of the major architectures. Michal I think that the goal was only to mfc this to warn users before 12.2 is branched, maybe a direct commit to 12 would have been better. No, the change is correct. drm-legacy-kmod (the port) is going away, especially on FreeBSD 13, since it is preventing updates to the FreeBSD VM subsystem. I sent an-email about this to a variety of lists about a week ago. I do know that there are a few special users of drm2 in FreeBSD current, I do not know how those are affected. Since, on FreeBSD current, most architectures can use drm-kmod, I believe it is good to point everyone towards that ports, instead of pointing everyone except amd64 users to drm-legacy-kmod. No, this change is not correct. You *newly* point ARM drm2 users to use a port marked with "ONLY_FOR_ARCHS= amd64 i386 powerpc64" Do you think that this is correct behavior? So again. I have not a single problem with drm-legacy-kmod removal, I have not a problem with pointing users of supported architectures (by kmod-*) to right port. But I have problem with marking drm2 driver as obsolete for ARM architecture (without single rational reason) and/or by pointing ARM users of drm2 driver to not-existent port. Michal I am only improving an already existing message. Previously, it would point people to drm-legacy-kmod on all architectures except amd64. This is wrong, since drm-legacy-kmod will be removed. drm-legacy-kmod is causing issues and preventing updates to other areas of FreeBSD, as I clearly stated in an email sent to current, ports, x11 and stable mailing lists. drm-current-kmod is only available on i386, amd64 and powerpc64. drm-devel-kmod is available on further architectures, covering almost all of the FreeBSD on desktop segment. With the work manu is doing, this will improve further. For FreeBSD 12, the situation is slightly different, since drm-fbsd12.1-kmod has less support. However, drm-legacy is available in base there, and once again, with the work manu is doing, support for further architectures might be possible even on FreeBSD 12. I have no objections if you want to opt out of the message on your tegra boards, but I do not want us to point users to a port that is deprecated and slated for removal. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r364737 - head/sys/dev/drm2
On 2020-09-01 15:16, Emmanuel Vadot wrote: On Tue, 1 Sep 2020 15:13:53 +0200 Michal Meloun wrote: On 25.08.2020 0:53, Niclas Zeising wrote: Author: zeising (doc,ports committer) Date: Mon Aug 24 22:53:23 2020 New Revision: 364737 URL: https://svnweb.freebsd.org/changeset/base/364737 Log: drm2: Update deprecation message Update the deprecation message in the drm2 (aka legacy drm) drivers to point towards the graphics/drm-kmod ports for all architectures, not just amd64. Only known user of drm2 is arm/tegra124 based boards. How graphics/drm-kmod can help for these? Or be more specific - drm2 allows me to hot-plug monitor to tegra based board an use 2 scaled overlay planes (which is exactly whats I want for my application). Which alternative can you offer me? Btw, as you can see, the maintenance cost of drm2 is close to zero and the dev/drm2 code does not inherit with any of the major architectures. Michal I think that the goal was only to mfc this to warn users before 12.2 is branched, maybe a direct commit to 12 would have been better. No, the change is correct. drm-legacy-kmod (the port) is going away, especially on FreeBSD 13, since it is preventing updates to the FreeBSD VM subsystem. I sent an-email about this to a variety of lists about a week ago. I do know that there are a few special users of drm2 in FreeBSD current, I do not know how those are affected. Since, on FreeBSD current, most architectures can use drm-kmod, I believe it is good to point everyone towards that ports, instead of pointing everyone except amd64 users to drm-legacy-kmod. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r364737 - head/sys/dev/drm2
Author: zeising (doc,ports committer)
Date: Mon Aug 24 22:53:23 2020
New Revision: 364737
URL: https://svnweb.freebsd.org/changeset/base/364737
Log:
drm2: Update deprecation message
Update the deprecation message in the drm2 (aka legacy drm) drivers to point
towards the graphics/drm-kmod ports for all architectures, not just amd64.
drm-kmod has support for more architectures these days, and the
graphics/drm-legacy-kmod port is being deprecated.
Approved by: imp
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D26174
Modified:
head/sys/dev/drm2/drm_os_freebsd.h
Modified: head/sys/dev/drm2/drm_os_freebsd.h
==
--- head/sys/dev/drm2/drm_os_freebsd.h Mon Aug 24 22:48:19 2020
(r364736)
+++ head/sys/dev/drm2/drm_os_freebsd.h Mon Aug 24 22:53:23 2020
(r364737)
@@ -154,16 +154,12 @@ typedef void irqreturn_t;
*(volatile u_int64_t *)(((vm_offset_t)(map)->handle) + \
(vm_offset_t)(offset)) = htole64(val)
-#ifdef amd64
#define DRM_PORT "graphics/drm-kmod"
-#else
-#define DRM_PORT "graphics/drm-legacy-kmod"
-#endif
#define DRM_OBSOLETE(dev)
\
do {
\
device_printf(dev,
"===\n"); \
- device_printf(dev, "This code is obsolete abandonware. Install the "
DRM_PORT " pkg\n"); \
+ device_printf(dev, "This code is deprecated. Install the " DRM_PORT "
pkg\n"); \
device_printf(dev,
"===\n"); \
gone_in_dev(dev, 13, "drm2 drivers");
\
} while (0)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r364436 - head
Author: zeising (doc,ports committer) Date: Thu Aug 20 19:14:53 2020 New Revision: 364436 URL: https://svnweb.freebsd.org/changeset/base/364436 Log: Add ufm(4) to ObsoleteFiles.inc The ufm driver was removed in r364432, add the manual to ObsoleteFiles. OK by:imp Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Thu Aug 20 18:50:46 2020(r364435) +++ head/ObsoleteFiles.inc Thu Aug 20 19:14:53 2020(r364436) @@ -36,6 +36,9 @@ # xargs -n1 | sort | uniq -d; # done +# 20200820: Removal of the ufm driver. +OLD_FILES+=usr/share/man/man4/ufm.4.gz + # 20200816: new clang import which bumps version from 10.0.1 to 11.0.0. OLD_FILES+=usr/lib/clang/10.0.1/include/cuda_wrappers/algorithm OLD_FILES+=usr/lib/clang/10.0.1/include/cuda_wrappers/complex ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r363120 - in stable: 11/sbin/shutdown 12/sbin/shutdown
Author: zeising (doc,ports committer) Date: Sun Jul 12 07:25:02 2020 New Revision: 363120 URL: https://svnweb.freebsd.org/changeset/base/363120 Log: MFC r362942: shutdown.8: Fix typo Fix a typo in shutdown.8, use ',' instead of '.' when listing items. Modified: stable/11/sbin/shutdown/shutdown.8 Directory Properties: stable/11/ (props changed) Changes in other areas also in this revision: Modified: stable/12/sbin/shutdown/shutdown.8 Directory Properties: stable/12/ (props changed) Modified: stable/11/sbin/shutdown/shutdown.8 == --- stable/11/sbin/shutdown/shutdown.8 Sun Jul 12 04:29:39 2020 (r363119) +++ stable/11/sbin/shutdown/shutdown.8 Sun Jul 12 07:25:02 2020 (r363120) @@ -124,7 +124,7 @@ suffix: .Dq Li s , .Dq Li sec , .Dq Li m , -.Dq Li min . +.Dq Li min , .Dq Li h , .Dq Li hour . .It Ar warning-message ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r363120 - in stable: 11/sbin/shutdown 12/sbin/shutdown
Author: zeising (doc,ports committer) Date: Sun Jul 12 07:25:02 2020 New Revision: 363120 URL: https://svnweb.freebsd.org/changeset/base/363120 Log: MFC r362942: shutdown.8: Fix typo Fix a typo in shutdown.8, use ',' instead of '.' when listing items. Modified: stable/12/sbin/shutdown/shutdown.8 Directory Properties: stable/12/ (props changed) Changes in other areas also in this revision: Modified: stable/11/sbin/shutdown/shutdown.8 Directory Properties: stable/11/ (props changed) Modified: stable/12/sbin/shutdown/shutdown.8 == --- stable/12/sbin/shutdown/shutdown.8 Sun Jul 12 04:29:39 2020 (r363119) +++ stable/12/sbin/shutdown/shutdown.8 Sun Jul 12 07:25:02 2020 (r363120) @@ -135,7 +135,7 @@ suffix: .Dq Li s , .Dq Li sec , .Dq Li m , -.Dq Li min . +.Dq Li min , .Dq Li h , .Dq Li hour . .Pp ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r362942 - head/sbin/shutdown
Author: zeising (doc,ports committer) Date: Sun Jul 5 13:08:17 2020 New Revision: 362942 URL: https://svnweb.freebsd.org/changeset/base/362942 Log: shutdown.8: Fix typo Fix a typo in shutdown.8, use ',' instead of '.' when listing items. MFC after:1 week Modified: head/sbin/shutdown/shutdown.8 Modified: head/sbin/shutdown/shutdown.8 == --- head/sbin/shutdown/shutdown.8 Sun Jul 5 10:57:28 2020 (r362941) +++ head/sbin/shutdown/shutdown.8 Sun Jul 5 13:08:17 2020 (r362942) @@ -135,7 +135,7 @@ suffix: .Dq Li s , .Dq Li sec , .Dq Li m , -.Dq Li min . +.Dq Li min , .Dq Li h , .Dq Li hour . .Pp ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361363 - in head/lib/libprocstat: . zfs
On 2020-05-22 13:20, Andriy Gapon wrote: Author: avg Date: Fri May 22 11:20:23 2020 New Revision: 361363 URL: https://svnweb.freebsd.org/changeset/base/361363 Log: libprocstat: fix ZFS support This might have broken a couple of ports. The build is still going, but at least three ports have failed to link, all with the same error: /usr/local/bin/ld: /usr/lib/libprocstat.so.1: undefined reference to `__start_set_pcpu' /usr/local/bin/ld: /usr/lib/libprocstat.so.1: undefined reference to `__stop_set_pcpu' c++: error: linker command failed with exit code 1 (use -v to see invocation) See for instance http://beefy18.nyi.freebsd.org/data/head-amd64-default/p536258_s361404/logs/errors/gnuradio-3.8.1.0_1.log and http://beefy18.nyi.freebsd.org/data/head-amd64-default/p536258_s361404/logs/octave-5.2.0_2.log Or, if you're on IPv4 only: http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fbeefy18.nyi.freebsd.org%2Fdata%2Fhead-amd64-default%2Fp536258_s361404%2Flogs%2Foctave-5.2.0_2.log&b=0&f=norefer Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r360637 - stable/12/sys/dev/evdev
Author: zeising (doc,ports committer) Date: Mon May 4 18:40:56 2020 New Revision: 360637 URL: https://svnweb.freebsd.org/changeset/base/360637 Log: MFC r360126, r360132: Change kern.evdev.rcpt_mask to 12 by default Original commit messages: Change kern.evdev.rcpt_mask from 3 to 12 by default. This makes us much more evdev-friendly, and will prevent everyone using xorg and wayland with evdev devices (the default) from needing to change this locally. powerpc32 still uses the old value for the keyboard part, becaues the adb keyboard driver used there is not evdev compatible. In r360126, I meant to have a different mask only on powerpc, not powerpc64. Update the check to check that we're not compiling for powerpc64. Approved by: wulf (implicit, mfc) Relnotes: yes Differential Revision:https://reviews.freebsd.org/D24370 Modified: stable/12/sys/dev/evdev/evdev.c Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/dev/evdev/evdev.c == --- stable/12/sys/dev/evdev/evdev.c Mon May 4 17:45:04 2020 (r360636) +++ stable/12/sys/dev/evdev/evdev.c Mon May 4 18:40:56 2020 (r360637) @@ -66,7 +66,12 @@ enum evdev_sparse_result MALLOC_DEFINE(M_EVDEV, "evdev", "evdev memory"); -int evdev_rcpt_mask = EVDEV_RCPT_SYSMOUSE | EVDEV_RCPT_KBDMUX; +/* adb keyboard driver used on powerpc does not support evdev yet */ +#if defined(__powerpc__) && !defined(__powerpc64__) +int evdev_rcpt_mask = EVDEV_RCPT_KBDMUX | EVDEV_RCPT_HW_MOUSE; +#else +int evdev_rcpt_mask = EVDEV_RCPT_HW_MOUSE | EVDEV_RCPT_HW_KBD; +#endif int evdev_sysmouse_t_axis = 0; SYSCTL_NODE(_kern, OID_AUTO, evdev, CTLFLAG_RW, 0, "Evdev args"); ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r360126 - head/sys/dev/evdev
On 2020-04-20 20:13, Conrad Meyer wrote: Hi Niclas, On Mon, Apr 20, 2020 at 9:57 AM Niclas Zeising wrote: On 2020-04-20 18:39, Justin Hibbits wrote: For just powerpc32, you should have: #if defined(__powerpc__) && !defined(__powerpc64__) Ok, I wasn't aware of that, I'll fix it. FYI, arch(7) is a great resource here (thanks, emaste@): """ Architecture-specific macros: ArchitecturePredefined macros ... powerpc __powerpc__ powerpcspe __powerpc__, __SPE__ powerpc64 __powerpc__, __powerpc64__ """ For other predefined macros not covered in arch(7), I highly recommend https://sourceforge.net/p/predef/wiki/Home/ . I'll remember that for next time, thanks! In any case, this should be fixed with r360132, sorry about that. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r360132 - head/sys/dev/evdev
Author: zeising (doc,ports committer) Date: Mon Apr 20 18:23:31 2020 New Revision: 360132 URL: https://svnweb.freebsd.org/changeset/base/360132 Log: Fix kern.evdev.rcpt_mask on powerpc In r360126, I meant to have a different mask only on powerpc, not powerpc64. Update the check to check that we're not compiling for powerpc64. Reported by: jhibbits Approved by: wulf (implicit) MFC after:2 weeks X-MFC-Note: 12 only X-MFC-With: r360126 Differential Revision:D24370 (followup) Modified: head/sys/dev/evdev/evdev.c Modified: head/sys/dev/evdev/evdev.c == --- head/sys/dev/evdev/evdev.c Mon Apr 20 18:01:45 2020(r360131) +++ head/sys/dev/evdev/evdev.c Mon Apr 20 18:23:31 2020(r360132) @@ -67,7 +67,7 @@ enum evdev_sparse_result MALLOC_DEFINE(M_EVDEV, "evdev", "evdev memory"); /* adb keyboard driver used on powerpc does not support evdev yet */ -#ifdef __powerpc__ +#if defined(__powerpc__) && !defined(__powerpc64__) int evdev_rcpt_mask = EVDEV_RCPT_KBDMUX | EVDEV_RCPT_HW_MOUSE; #else int evdev_rcpt_mask = EVDEV_RCPT_HW_MOUSE | EVDEV_RCPT_HW_KBD; ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r360126 - head/sys/dev/evdev
On 2020-04-20 18:39, Justin Hibbits wrote: On Mon, 20 Apr 2020 16:17:17 + (UTC) Niclas Zeising wrote: Author: zeising (doc,ports committer) Date: Mon Apr 20 16:17:16 2020 New Revision: 360126 URL: https://svnweb.freebsd.org/changeset/base/360126 Log: Change kern.evdev.rcpt_mask to 12 by default Change kern.evdev.rcpt_mask from 3 to 12 by default. This makes us much more evdev-friendly, and will prevent everyone using xorg and wayland with evdev devices (the default) from needing to change this locally. powerpc32 still uses the old value for the keyboard part, becaues the adb keyboard driver used there is not evdev compatible. Reviewed by: wulf Approved by: wulf MFC after: 2 weeks X-MFC-Note: 12 only Relnotes:yes Differential Revision: https://reviews.freebsd.org/D24370 Modified: head/sys/dev/evdev/evdev.c Modified: head/sys/dev/evdev/evdev.c == --- head/sys/dev/evdev/evdev.c Mon Apr 20 16:14:44 2020 (r360125) +++ head/sys/dev/evdev/evdev.cMon Apr 20 16:17:16 2020(r360126) @@ -66,7 +66,12 @@ enum evdev_sparse_result MALLOC_DEFINE(M_EVDEV, "evdev", "evdev memory"); -int evdev_rcpt_mask = EVDEV_RCPT_SYSMOUSE | EVDEV_RCPT_KBDMUX; +/* adb keyboard driver used on powerpc does not support evdev yet */ +#ifdef __powerpc__ This affects *all* powerpc, not just powerpc32. For just powerpc32, you should have: #if defined(__powerpc__) && !defined(__powerpc64__) Ok, I wasn't aware of that, I'll fix it. But I'm curious, why not attach to sysmouse(4) and kbdmux(4)? What breakage does that cause? I could maybe see not attaching to sysmouse(4) by default, if the protocol isn't expressive enough, but kbdmux(4) should be sufficient. Sysmouse hides features from evdev, so it's better to let xorg or wayland access the device directly. If both are enabled, you'll get double events, meaning double key presses when using USB devices: https://reviews.freebsd.org/D24370#538523 Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r360126 - head/sys/dev/evdev
Author: zeising (doc,ports committer) Date: Mon Apr 20 16:17:16 2020 New Revision: 360126 URL: https://svnweb.freebsd.org/changeset/base/360126 Log: Change kern.evdev.rcpt_mask to 12 by default Change kern.evdev.rcpt_mask from 3 to 12 by default. This makes us much more evdev-friendly, and will prevent everyone using xorg and wayland with evdev devices (the default) from needing to change this locally. powerpc32 still uses the old value for the keyboard part, becaues the adb keyboard driver used there is not evdev compatible. Reviewed by: wulf Approved by: wulf MFC after:2 weeks X-MFC-Note: 12 only Relnotes: yes Differential Revision:https://reviews.freebsd.org/D24370 Modified: head/sys/dev/evdev/evdev.c Modified: head/sys/dev/evdev/evdev.c == --- head/sys/dev/evdev/evdev.c Mon Apr 20 16:14:44 2020(r360125) +++ head/sys/dev/evdev/evdev.c Mon Apr 20 16:17:16 2020(r360126) @@ -66,7 +66,12 @@ enum evdev_sparse_result MALLOC_DEFINE(M_EVDEV, "evdev", "evdev memory"); -int evdev_rcpt_mask = EVDEV_RCPT_SYSMOUSE | EVDEV_RCPT_KBDMUX; +/* adb keyboard driver used on powerpc does not support evdev yet */ +#ifdef __powerpc__ +int evdev_rcpt_mask = EVDEV_RCPT_KBDMUX | EVDEV_RCPT_HW_MOUSE; +#else +int evdev_rcpt_mask = EVDEV_RCPT_HW_MOUSE | EVDEV_RCPT_HW_KBD; +#endif int evdev_sysmouse_t_axis = 0; SYSCTL_NODE(_kern, OID_AUTO, evdev, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359985 - stable/12/sys/dev/atkbdc
On 2020-04-16 03:04, Warner Losh wrote: On Wed, Apr 15, 2020, 6:51 PM Rodney W. Grimes mailto:free...@gndrsh.dnsmgr.net>> wrote: [ Charset UTF-8 unsupported, converting... ] > Author: zeising (doc,ports committer) > Date: Wed Apr 15 19:47:19 2020 > New Revision: 359985 > URL: https://svnweb.freebsd.org/changeset/base/359985 > > Log: > MFC r348873: Enable touch and trackpads by default > > Enable synaptics and elantech touchpads, as well as IBM/Lenovo TrackPoints > by default, instead of having users find and toggle a loader tunable. > This makes things like two finger scroll and other modern features work out > of the box with X. By enabling these settings by default, we get a better > desktop experience in X, since xserver and evdev can make use of the more > advanced synaptics and elantech features. > > Approved by: imp RELNOTES: Y? Yea. This is a release notes item. Yes, this should have been marked with relnotes, my bad. How can I fix this? Did we create the RELNOTES file, and if so, should I commit to that one directly in 12, or first in head and then MFC? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r359985 - stable/12/sys/dev/atkbdc
Author: zeising (doc,ports committer)
Date: Wed Apr 15 19:47:19 2020
New Revision: 359985
URL: https://svnweb.freebsd.org/changeset/base/359985
Log:
MFC r348873: Enable touch and trackpads by default
Enable synaptics and elantech touchpads, as well as IBM/Lenovo TrackPoints
by default, instead of having users find and toggle a loader tunable.
This makes things like two finger scroll and other modern features work out
of the box with X. By enabling these settings by default, we get a better
desktop experience in X, since xserver and evdev can make use of the more
advanced synaptics and elantech features.
Approved by: imp
Modified:
stable/12/sys/dev/atkbdc/psm.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/dev/atkbdc/psm.c
==
--- stable/12/sys/dev/atkbdc/psm.c Wed Apr 15 19:33:42 2020
(r359984)
+++ stable/12/sys/dev/atkbdc/psm.c Wed Apr 15 19:47:19 2020
(r359985)
@@ -513,9 +513,9 @@ static devclass_t psm_devclass;
/* Tunables */
static int tap_enabled = -1;
static int verbose = PSM_DEBUG;
-static int synaptics_support = 0;
-static int trackpoint_support = 0;
-static int elantech_support = 0;
+static int synaptics_support = 1;
+static int trackpoint_support = 1;
+static int elantech_support = 1;
/* for backward compatibility */
#defineOLD_MOUSE_GETHWINFO _IOR('M', 1, old_mousehw_t)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r354966 - head
Author: zeising (doc,ports committer) Date: Thu Nov 21 15:38:27 2019 New Revision: 354966 URL: https://svnweb.freebsd.org/changeset/base/354966 Log: ObsoleteFiles.inc: add sio(4) leftovers Add the manual page for sio(4) to ObsoleteFiles.inc, so that make delete-all will remove it. The manual page was removed together with sio(4) in r354929. Approved by: emaste Differential Revision:https://reviews.freebsd.org/D22477 Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Thu Nov 21 14:55:27 2019(r354965) +++ head/ObsoleteFiles.inc Thu Nov 21 15:38:27 2019(r354966) @@ -38,6 +38,8 @@ # xargs -n1 | sort | uniq -d; # done +# 20191121: Removal of sio(4) +OLD_FILES+=usr/share/man/man4/sio.4.gz # 20191105: picobsd(8), et al, removed. OLD_FILES+=usr/share/man/man8/picobsd.8.gz # 20191009: new clang import which bumps version from 8.0.1 to 9.0.0. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352707 - in head/sys: conf kern net sys
On 2019-09-26 17:03, Charlie Li via freebsd-x11 wrote: Kyle Evans wrote: On Thu, Sep 26, 2019 at 9:49 AM Charlie Li wrote: This breaks building the drm-kmod ports, as the build cannot find opt_epoch.h (drm-devel-kmod example shown, drm-current-kmod dies the exact same way): --- linux_anon_inodes.o --- cc -O2 -pipe -fno-strict-aliasing -include /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/drivers/gpu/drm/drm_os_config.h '-DKBUILD_MODNAME="linuxkpi_gplv2"' -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/include -I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/dummy/include -I/wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include -I/usr/src/sys/compat/linuxkpi/common/include -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -MD -MF.depend.linux_anon_inodes.o -MTlinux_anon_inodes.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -Wno-pointer-arith -mno-aes -mno-avx -std=iso9899:1999 -c /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodes.c -o linux_anon_inodes.o In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodes.c:12: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/anon_inodes.h:4: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/fs.h:6: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/shrinker.h:5: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/list.h:56: In file included from /usr/src/sys/net/if_var.h:83: /usr/src/sys/sys/epoch.h:44:10: fatal error: 'opt_epoch.h' file not found #include "opt_epoch.h" ^ --- linux_anon_inodefs.o --- In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/src/linux_anon_inodefs.c:45: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/debugfs.h:18: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/fs.h:6: In file included from /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi/gplv2/include/linux/shrinker.h:5: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/list.h:56: In file included from /usr/src/sys/net/if_var.h:83: /usr/src/sys/sys/epoch.h:44:10: fatal error: 'opt_epoch.h' file not found #include "opt_epoch.h" ^ --- linux_anon_inodes.o --- 1 error generated. *** [linux_anon_inodes.o] Error code 1 make[2]: stopped in /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-dc414a9/linuxkpi --- linux_anon_inodefs.o --- 1 error generated. *** [linux_anon_inodefs.o] Error code 1 Interestingly enough, does not happen when drm-current-kmod is built as part of buildkernel (using an existing installed package with SOURCE on). FWIW, johalun noticed this yesterday and addressed it here: https://github.com/FreeBSDDesktop/kms-drm/commit/b486949e7e9f0cfe8dac5f0ac7fe1a660300981d Ah, of course I would miss these commits in the kms-drm repo, considering that I watch them roll in. Will wait for the updated snapshots in ports. I'll get to updating the ports as soon as I can. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352128 - in head: . usr.bin usr.bin/colldef usr.bin/mklocale
On 2019-09-10 09:54, Baptiste Daroussin wrote: Author: bapt Date: Tue Sep 10 07:54:49 2019 New Revision: 352128 URL: https://svnweb.freebsd.org/changeset/base/352128 Log: Remove mklocale(1) and colldef(1) which are deprecated since FreeBSD 11 In FreeBSD 11 along with the rework on the collation, mklocale(1) and colldef(1) has been replaced by localedef(1) (a note has been added to the manpage to state it). mklocale(1) and colldef(1) has been kept around to be able to build older versions of FreeBSD. None of the version requiring those tools are supported anymore so it is time to remove them from base Deleted: head/usr.bin/colldef/ head/usr.bin/mklocale/ Modified: head/ObsoleteFiles.inc head/usr.bin/Makefile Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Tue Sep 10 07:47:52 2019(r352127) +++ head/ObsoleteFiles.inc Tue Sep 10 07:54:49 2019(r352128) @@ -38,6 +38,11 @@ # xargs -n1 | sort | uniq -d; # done +# 20190910: mklocale(1) and colldef(1) removed +OLD_FILES+=usr.bin/mklocale ^^ should be usr/bin/mklocale +OLD_FILES+=usr/share/man/man1/mklocale.1.gz +OLD_FILES+=usr.bin/colldef ^^ should be usr/bin/colldef +OLD_FILES+=usr/share/man/man1/colldef.1.gz # 20190904: Remove boot1.efifat OLD_FILES+=boot/boot1.efifat # 20190903: pc-sysinstall(8) removed Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351831 - in head: . stand/efi/boot1 stand/efi/gptboot tools/build/mk
On 2019-09-05 07:57, Dimitry Andric wrote: On 4 Sep 2019, at 22:55, Rebecca Cran wrote: Author: bcran Date: Wed Sep 4 20:55:48 2019 New Revision: 351831 URL: https://svnweb.freebsd.org/changeset/base/351831 Log: The efifat files are no longer used: remove the code to build them Reviewed by: imp, tsoome, emaste Differential Revision:https://reviews.freebsd.org/D20562 So what are now the instructions for updating an EFI partition, after a buildworld? I used to find that efifat file quite handy, I could just use gpart -p to write it into the EFI partition... :-/ -Dimitry This is what I do: mount -t msdosfs /dev/ada0p1 /mnt # (if that's the ESP, check with gpart list) cp /boot/loader.efi /mnt/EFI/FreeBSD/loader.efi umount /mnt This works if proper EFI boot variables have been set up. This can be done with, it's only needed the first time, or if they are somehow overwritten. efibootmgr --create --activate --label FreeBSD --loader /dev/ada0p1:/EFI/FreeBSD/loader.efi Once again, check that /dev/ada0p1 is the ESP. You can check your efi boot variables with efibootmgr -v Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r351608 - head
Author: zeising (doc,ports committer) Date: Thu Aug 29 17:25:50 2019 New Revision: 351608 URL: https://svnweb.freebsd.org/changeset/base/351608 Log: Use relative paths in ObsoleteFiles.inc Approved by: imp Differential Revision:https://reviews.freebsd.org/D21467 Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Thu Aug 29 17:17:39 2019(r351607) +++ head/ObsoleteFiles.inc Thu Aug 29 17:25:50 2019(r351608) @@ -39,8 +39,8 @@ # done # 20190825: zlib 1.0.4 removed from kernel -OLD_FILES+=/usr/include/sys/zlib.h -OLD_FILES+=/usr/include/sys/zutil.h +OLD_FILES+=usr/include/sys/zlib.h +OLD_FILES+=usr/include/sys/zutil.h # 20190817: pft_ping.py and sniffer.py moved to /usr/tests/sys/netpfil/common OLD_FILES+=usr/tests/sys/netpfil/pf/sniffer.py OLD_FILES+=usr/tests/sys/netpfil/pf/pft_ping.py ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r351607 - head
Author: zeising (doc,ports committer) Date: Thu Aug 29 17:17:39 2019 New Revision: 351607 URL: https://svnweb.freebsd.org/changeset/base/351607 Log: pwm.9 symlink shouldn't be removed When the pwm.9 manual was removed, a symlink between pwmbus.9 and pwm.9 was created, but there's an entry in ObsoleteFiles.inc to remove pwn.9, meaning that on every installation pwm.9 is created, and make delete-old deletes it. Remove the entry from ObsoleteFiles.inc, the symlink is clearly intentional and shouldn't be removed. Reviewed by: imp, ian Approved by: imp (implicit, review OK) Differential Revision:https://reviews.freebsd.org/D21198 Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Thu Aug 29 17:02:02 2019(r351606) +++ head/ObsoleteFiles.inc Thu Aug 29 17:17:39 2019(r351607) @@ -57,8 +57,8 @@ OLD_FILES+=usr/share/man/man3/cap_random_buf.3.gz OLD_FILES+=usr/share/man/man9/vm_page_hold.9.gz # 20190618: sys/capability.h removed (sys/capsicum.h is the one to use) OLD_FILES+=usr/include/sys/capability.h -# 20190615: sys/pwm.h renamed to dev/pwmc.h and pwm(9) removed -OLD_FILES+=usr/include/sys/pwm.h usr/share/man/man9/pwm.9.gz +# 20190615: sys/pwm.h renamed to dev/pwmc.h +OLD_FILES+=usr/include/sys/pwm.h # 20190612: new clang import which bumps version from 8.0.0 to 8.0.1. OLD_FILES+=usr/lib/clang/8.0.0/include/sanitizer/allocator_interface.h OLD_FILES+=usr/lib/clang/8.0.0/include/sanitizer/asan_interface.h ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351009 - head/sys/compat/linuxkpi/common/include/linux
On 2019-08-14 21:24, Cy Schubert wrote: On August 14, 2019 12:06:24 PM PDT, Hans Petter Selasky wrote: On 2019-08-14 21:00, Cy Schubert wrote: John's patch to drm-current-kmod (ports r508877) works! This broke drm-current-kmod. You need to update the port. This patch should have been tested too. Did you try that first? --HPS The port is up to date. Sorry for not attaching output. I was in a rush to get back to $JOB. I'll rerun it tonight. Ports should be updated with a fix now, sorry about that. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350390 - head/sys/kern
On 2019-07-28 18:14, Alan Somers wrote:
On Sun, Jul 28, 2019 at 10:11 AM Niclas Zeising
wrote:
On 2019-07-28 18:07, Alan Somers wrote:
Author: asomers
Date: Sun Jul 28 16:07:27 2019
New Revision: 350390
URL: https://svnweb.freebsd.org/changeset/base/350390
Log:
Better comments for vlrureclaim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/kern/vfs_subr.c
Modified: head/sys/kern/vfs_subr.c
==
--- head/sys/kern/vfs_subr.c Sun Jul 28 15:20:47 2019(r350389)
+++ head/sys/kern/vfs_subr.c Sun Jul 28 16:07:27 2019(r350390)
@@ -947,9 +947,16 @@ vattr_null(struct vattr *vap)
* desirable to reuse such vnodes. These conditions may cause the
* number of vnodes to reach some minimum value regardless of what
* you set kern.maxvnodes to. Do not set kern.maxvnodes too low.
+ *
+ * @param mp Try to reclaim vnodes from this mountpoint
+ * @param reclaim_nc_src Only reclaim directories with outgoing namecache
+ *entries if this argument is strue
+ * @param trigger Only reclaim vnodes with fewer than this many resident
+ *pages.
+ * @returnThe number of vnodes that were reclaimed.
*/
static int
-vlrureclaim(struct mount *mp, int reclaim_nc_src, int trigger)
+vlrureclaim(struct mount *mp, bool reclaim_nc_src, int trigger)
{
struct vnode *vp;
int count, done, target;
@@ -1238,7 +1245,8 @@ vnlru_proc(void)
{
struct mount *mp, *nmp;
unsigned long onumvnodes;
- int done, force, reclaim_nc_src, trigger, usevnodes;
+ int done, force, trigger, usevnodes;
+ bool reclaim_nc_src;
EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, vnlruproc,
SHUTDOWN_PRI_FIRST);
Was this change intended? It's not mentioned in the commit message.
Thanks!
Regards
--
Niclas
Yes, it was intended. Since it makes no difference at runtime, I
thought of the type change as basically being documentation. That's
why I didn't explicitly mention it.
Ok!
Thank you for the explanation.
Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r350390 - head/sys/kern
On 2019-07-28 18:07, Alan Somers wrote:
Author: asomers
Date: Sun Jul 28 16:07:27 2019
New Revision: 350390
URL: https://svnweb.freebsd.org/changeset/base/350390
Log:
Better comments for vlrureclaim
MFC after: 2 weeks
Sponsored by:The FreeBSD Foundation
Modified:
head/sys/kern/vfs_subr.c
Modified: head/sys/kern/vfs_subr.c
==
--- head/sys/kern/vfs_subr.cSun Jul 28 15:20:47 2019(r350389)
+++ head/sys/kern/vfs_subr.cSun Jul 28 16:07:27 2019(r350390)
@@ -947,9 +947,16 @@ vattr_null(struct vattr *vap)
* desirable to reuse such vnodes. These conditions may cause the
* number of vnodes to reach some minimum value regardless of what
* you set kern.maxvnodes to. Do not set kern.maxvnodes too low.
+ *
+ * @param mpTry to reclaim vnodes from this mountpoint
+ * @param reclaim_nc_src Only reclaim directories with outgoing namecache
+ * entries if this argument is strue
+ * @param trigger Only reclaim vnodes with fewer than this many resident
+ * pages.
+ * @return The number of vnodes that were reclaimed.
*/
static int
-vlrureclaim(struct mount *mp, int reclaim_nc_src, int trigger)
+vlrureclaim(struct mount *mp, bool reclaim_nc_src, int trigger)
{
struct vnode *vp;
int count, done, target;
@@ -1238,7 +1245,8 @@ vnlru_proc(void)
{
struct mount *mp, *nmp;
unsigned long onumvnodes;
- int done, force, reclaim_nc_src, trigger, usevnodes;
+ int done, force, trigger, usevnodes;
+ bool reclaim_nc_src;
EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, vnlruproc,
SHUTDOWN_PRI_FIRST);
Was this change intended? It's not mentioned in the commit message.
Thanks!
Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349770 - stable/11/share/man/man4
Author: zeising (doc,ports committer) Date: Fri Jul 5 22:21:20 2019 New Revision: 349770 URL: https://svnweb.freebsd.org/changeset/base/349770 Log: MFC r349607: pci(4): Use plural registers Original commit message: pci(4): Use plural configuration registers Change to use registers instead of register, as it is customary to use plural when talking about PCI registers. This was missed in r349150. Modified: stable/11/share/man/man4/pci.4 Directory Properties: stable/11/ (props changed) Modified: stable/11/share/man/man4/pci.4 == --- stable/11/share/man/man4/pci.4 Fri Jul 5 22:21:02 2019 (r349769) +++ stable/11/share/man/man4/pci.4 Fri Jul 5 22:21:20 2019 (r349770) @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration register specified by the passed-in +configuration registers specified by the passed-in .Va pci_io structure. The ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349769 - stable/12/share/man/man4
Author: zeising (doc,ports committer) Date: Fri Jul 5 22:21:02 2019 New Revision: 349769 URL: https://svnweb.freebsd.org/changeset/base/349769 Log: MFC r349607: pci(4): Use plural registers Original commit message: pci(4): Use plural configuration registers Change to use registers instead of register, as it is customary to use plural when talking about PCI registers. This was missed in r349150. Modified: stable/12/share/man/man4/pci.4 Directory Properties: stable/12/ (props changed) Modified: stable/12/share/man/man4/pci.4 == --- stable/12/share/man/man4/pci.4 Fri Jul 5 20:01:06 2019 (r349768) +++ stable/12/share/man/man4/pci.4 Fri Jul 5 22:21:02 2019 (r349769) @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration register specified by the passed-in +configuration registers specified by the passed-in .Va pci_io structure. The ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349607 - head/share/man/man4
Author: zeising (doc,ports committer) Date: Tue Jul 2 17:48:27 2019 New Revision: 349607 URL: https://svnweb.freebsd.org/changeset/base/349607 Log: pci(4): Use plural configuration registers Change to use registers instead of register, as it is customary to use plural when talking about PCI registers. This was missed in r349150. MFC after:3 days Modified: head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4 Tue Jul 2 17:24:25 2019(r349606) +++ head/share/man/man4/pci.4 Tue Jul 2 17:48:27 2019(r349607) @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration register specified by the passed-in +configuration registers specified by the passed-in .Va pci_io structure. The ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349606 - stable/11/share/man/man4
Author: zeising (doc,ports committer) Date: Tue Jul 2 17:24:25 2019 New Revision: 349606 URL: https://svnweb.freebsd.org/changeset/base/349606 Log: MFC 349133 349146 349150: document PCIOCATTACHED r349133: pci(4): Document PCIOCATTACHED Document the PCIOCATTACHED ioctl(2) in the pci(4) manual. PCIOCATTACHED is used to query if a driver has attached to a PCI. Reviewed by: bcr, imp Differential Revision:https://reviews.freebsd.org/D20652 r349146: pci.4: wordsmith and add missing words Add missing words after PCI in the description of the PCIOCWRITE and PCIOCATTACHED ioctls. Use singular in PCIOCREAD, we only read one register at the time. Reviewed by: bcr, bjk, rgrimes, cem Differential Revision:https://reviews.freebsd.org/D20671 r349150: pci.4: Use plural configuration registers It is customary to use plural when talking about PCI configure registers. Reported by: scottl Merge conflicts manually. Modified: stable/11/share/man/man4/pci.4 Directory Properties: stable/11/ (props changed) Modified: stable/11/share/man/man4/pci.4 == --- stable/11/share/man/man4/pci.4 Tue Jul 2 17:23:37 2019 (r349605) +++ stable/11/share/man/man4/pci.4 Tue Jul 2 17:24:25 2019 (r349606) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 8, 2016 +.Dd June 17, 2019 .Dt PCI 4 .Os .Sh NAME @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration registers specified by the passed-in +configuration register specified by the passed-in .Va pci_io structure. The @@ -307,7 +307,7 @@ from the ioctl. .It pi_reg The .Tn PCI -configuration register the user would like to access. +configuration registers the user would like to access. .It pi_width The width, in bytes, of the data the user would like to read. This value @@ -323,7 +323,7 @@ This .Xr ioctl 2 allows users to write to the .Tn PCI -specified in the passed-in +configuration registers specified in the passed-in .Va pci_io structure. The @@ -334,6 +334,26 @@ reading registers, above, also apply to writing .Tn PCI configuration registers. .El +.It PCIOCATTACHED +This +.Xr ioctl 2 +allows users to query if a driver is attached to the +.Tn PCI +device specified in the passed-in +.Va pci_io +structure. +The +.Va pci_io +structure is described above, however, the +.Va pi_reg +and +.Va pi_width +fields are not used. +The status of the device is stored in the +.Va pi_data +field. +A value of 0 indicates no driver is attached, while a value larger than 0 +indicates that a driver is attached. .Sh LOADER TUNABLES Tunables can be set at the .Xr loader 8 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349605 - stable/12/share/man/man4
Author: zeising (doc,ports committer) Date: Tue Jul 2 17:23:37 2019 New Revision: 349605 URL: https://svnweb.freebsd.org/changeset/base/349605 Log: MFC 349133 349146 349150: document PCIOCATTACHED r349133: pci(4): Document PCIOCATTACHED Document the PCIOCATTACHED ioctl(2) in the pci(4) manual. PCIOCATTACHED is used to query if a driver has attached to a PCI. Reviewed by: bcr, imp Differential Revision:https://reviews.freebsd.org/D20652 r349146: pci.4: wordsmith and add missing words Add missing words after PCI in the description of the PCIOCWRITE and PCIOCATTACHED ioctls. Use singular in PCIOCREAD, we only read one register at the time. Reviewed by: bcr, bjk, rgrimes, cem Differential Revision:https://reviews.freebsd.org/D20671 r349150: pci.4: Use plural configuration registers It is customary to use plural when talking about PCI configure registers. Reported by: scottl Modified: stable/12/share/man/man4/pci.4 Directory Properties: stable/12/ (props changed) Modified: stable/12/share/man/man4/pci.4 == --- stable/12/share/man/man4/pci.4 Tue Jul 2 16:56:27 2019 (r349604) +++ stable/12/share/man/man4/pci.4 Tue Jul 2 17:23:37 2019 (r349605) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 14, 2018 +.Dd June 17, 2019 .Dt PCI 4 .Os .Sh NAME @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration registers specified by the passed-in +configuration register specified by the passed-in .Va pci_io structure. The @@ -307,7 +307,7 @@ from the ioctl. .It pi_reg The .Tn PCI -configuration register the user would like to access. +configuration registers the user would like to access. .It pi_width The width, in bytes, of the data the user would like to read. This value @@ -323,7 +323,7 @@ This .Xr ioctl 2 allows users to write to the .Tn PCI -specified in the passed-in +configuration registers specified in the passed-in .Va pci_io structure. The @@ -333,6 +333,26 @@ The limitations on data width described for reading registers, above, also apply to writing .Tn PCI configuration registers. +.It PCIOCATTACHED +This +.Xr ioctl 2 +allows users to query if a driver is attached to the +.Tn PCI +device specified in the passed-in +.Va pci_io +structure. +The +.Va pci_io +structure is described above, however, the +.Va pi_reg +and +.Va pi_width +fields are not used. +The status of the device is stored in the +.Va pi_data +field. +A value of 0 indicates no driver is attached, while a value larger than 0 +indicates that a driver is attached. .It PCIOCBARMMAP This .Xr ioctl 2 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r349146 - head/share/man/man4
On 2019-06-17 19:27, Scott Long wrote: It’s customary to refer to PCI configuration registers in the plural form. Would you mind changing back from “register” to “registers”? I didn't know that. Changed in r349150 Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349150 - head/share/man/man4
Author: zeising (doc,ports committer) Date: Mon Jun 17 17:35:55 2019 New Revision: 349150 URL: https://svnweb.freebsd.org/changeset/base/349150 Log: pci.4: Use plural configuration registers It is customary to use plural when talking about PCI configure registers. Reported by: scottl MFC after:2 weeks X-MFC-with: r349133 Modified: head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4 Mon Jun 17 17:17:01 2019(r349149) +++ head/share/man/man4/pci.4 Mon Jun 17 17:35:55 2019(r349150) @@ -307,7 +307,7 @@ from the ioctl. .It pi_reg The .Tn PCI -configuration register the user would like to access. +configuration registers the user would like to access. .It pi_width The width, in bytes, of the data the user would like to read. This value @@ -323,7 +323,7 @@ This .Xr ioctl 2 allows users to write to the .Tn PCI -configuration register specified in the passed-in +configuration registers specified in the passed-in .Va pci_io structure. The ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349146 - head/share/man/man4
Author: zeising (doc,ports committer) Date: Mon Jun 17 16:54:51 2019 New Revision: 349146 URL: https://svnweb.freebsd.org/changeset/base/349146 Log: pci.4: wordsmith and add missing words Add missing words after PCI in the description of the PCIOCWRITE and PCIOCATTACHED ioctls. Use singular in PCIOCREAD, we only read one register at the time. Reviewed by: bcr, bjk, rgrimes, cem MFC after:2 weeks X-MFC-with: r349133 Differential Revision:https://reviews.freebsd.org/D20671 Modified: head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4 Mon Jun 17 16:50:58 2019(r349145) +++ head/share/man/man4/pci.4 Mon Jun 17 16:54:51 2019(r349146) @@ -290,7 +290,7 @@ This .Xr ioctl 2 reads the .Tn PCI -configuration registers specified by the passed-in +configuration register specified by the passed-in .Va pci_io structure. The @@ -323,7 +323,7 @@ This .Xr ioctl 2 allows users to write to the .Tn PCI -specified in the passed-in +configuration register specified in the passed-in .Va pci_io structure. The @@ -338,7 +338,7 @@ This .Xr ioctl 2 allows users to query if a driver is attached to the .Tn PCI -specified in the passed-in +device specified in the passed-in .Va pci_io structure. The ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r349133 - head/share/man/man4
On 2019-06-17 12:27, Niclas Zeising wrote: On 2019-06-17 11:03, Rodney W. Grimes wrote: On 2019-06-17 09:56, Benjamin Kaduk wrote: On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising mailto:zeis...@freebsd.org>> wrote: Author: zeising (doc,ports committer) Date: Mon Jun 17 05:41:47 2019 New Revision: 349133 URL: https://svnweb.freebsd.org/changeset/base/349133 Log: ? pci(4): Document PCIOCATTACHED ? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual. ? PCIOCATTACHED is used to query if a driver has attached to a PCI. ? Reviewed by:? bcr, imp ? MFC after:? ? 2 weeks ? Differential Revision: https://reviews.freebsd.org/D20652 Modified: ? head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019 (r349132) +++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019 (r349133) @@ -24,7 +24,7 @@ ?.\" ?.\" $FreeBSD$ ?.\" -.Dd June 14, 2018 +.Dd June 17, 2019 ?.Dt PCI 4 ?.Os ?.Sh NAME @@ -333,6 +333,26 @@ The limitations on data width described for ?reading registers, above, also apply to writing ?.Tn PCI ?configuration registers. +.It PCIOCATTACHED +This +.Xr ioctl 2 +allows users to query if a driver is attached to the +.Tn PCI +specified in the passed-in Is there a missing word like "device" here? Actally I think the missing word, in both cases, is register, unless I am misreading some part of the manual page and what a struct pci_io points at. I guess if the pi_reg is null then this would be device. Either way there is defanity a missing word. I'll try to fix this. In the PCIOCWRITE case, perhaps register is best, however, inthe PCIOCATTACHED case, device is best, I think. I'll create a patch and put it for review, I'll get back to you once it's done. Regards Here's the review with my proposed change. Let me know what you think. https://reviews.freebsd.org/D20671 Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r349133 - head/share/man/man4
On 2019-06-17 11:03, Rodney W. Grimes wrote:
On 2019-06-17 09:56, Benjamin Kaduk wrote:
On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising mailto:zeis...@freebsd.org>> wrote:
Author: zeising (doc,ports committer)
Date: Mon Jun 17 05:41:47 2019
New Revision: 349133
URL: https://svnweb.freebsd.org/changeset/base/349133
Log:
? pci(4): Document PCIOCATTACHED
? Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
? PCIOCATTACHED is used to query if a driver has attached to a PCI.
? Reviewed by:? bcr, imp
? MFC after:? ? 2 weeks
? Differential Revision: https://reviews.freebsd.org/D20652
Modified:
? head/share/man/man4/pci.4
Modified: head/share/man/man4/pci.4
==
--- head/share/man/man4/pci.4? ?Mon Jun 17 03:48:44 2019
(r349132)
+++ head/share/man/man4/pci.4? ?Mon Jun 17 05:41:47 2019
(r349133)
@@ -24,7 +24,7 @@
?.\"
?.\" $FreeBSD$
?.\"
-.Dd June 14, 2018
+.Dd June 17, 2019
?.Dt PCI 4
?.Os
?.Sh NAME
@@ -333,6 +333,26 @@ The limitations on data width described for
?reading registers, above, also apply to writing
?.Tn PCI
?configuration registers.
+.It PCIOCATTACHED
+This
+.Xr ioctl 2
+allows users to query if a driver is attached to the
+.Tn PCI
+specified in the passed-in
Is there a missing word like "device" here?
Actally I think the missing word, in both cases, is register,
unless I am misreading some part of the manual page and
what a struct pci_io points at. I guess if the pi_reg is null
then this would be device. Either way there is defanity a
missing word.
I'll try to fix this. In the PCIOCWRITE case, perhaps register is best,
however, inthe PCIOCATTACHED case, device is best, I think.
I'll create a patch and put it for review, I'll get back to you once
it's done.
Regards
I just followed the same syntax as for the PCIOCWRITE ioctl in the
paragraph before.
Probably a mistake there too.
I found it a little strange when I read it, but I
kind of assumed there was a reason it said PCI and not PCI device,
perhaps similar to using RAM instead of RAM memory, if you understand
what I mean.
RAM memory == Random Access Memory Memory
PCI == Peripheral Component Interconnect
PCI {Register, Device, Bus} all make valid sense,
PCI alone does not.
Regards
Niclas
+.Va pci_io
+structure.
+The
+.Va pci_io
+structure is described above, however, the
+.Va pi_reg
+and
+.Va pi_width
+fields are not used.
+The status of the device is stored in the
+.Va pi_data
+field.
+A value of 0 indicates no driver is attached, while a value larger
than 0
+indicates that a driver is attached.
?.It PCIOCBARMMAP
?This
?.Xr ioctl 2
--
Niclas Zeising
--
Niclas Zeising
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r349133 - head/share/man/man4
On 2019-06-17 09:56, Benjamin Kaduk wrote: On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising <mailto:zeis...@freebsd.org>> wrote: Author: zeising (doc,ports committer) Date: Mon Jun 17 05:41:47 2019 New Revision: 349133 URL: https://svnweb.freebsd.org/changeset/base/349133 Log: pci(4): Document PCIOCATTACHED Document the PCIOCATTACHED ioctl(2) in the pci(4) manual. PCIOCATTACHED is used to query if a driver has attached to a PCI. Reviewed by: bcr, imp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20652 Modified: head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4 Mon Jun 17 03:48:44 2019 (r349132) +++ head/share/man/man4/pci.4 Mon Jun 17 05:41:47 2019 (r349133) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 14, 2018 +.Dd June 17, 2019 .Dt PCI 4 .Os .Sh NAME @@ -333,6 +333,26 @@ The limitations on data width described for reading registers, above, also apply to writing .Tn PCI configuration registers. +.It PCIOCATTACHED +This +.Xr ioctl 2 +allows users to query if a driver is attached to the +.Tn PCI +specified in the passed-in Is there a missing word like "device" here? I just followed the same syntax as for the PCIOCWRITE ioctl in the paragraph before. I found it a little strange when I read it, but I kind of assumed there was a reason it said PCI and not PCI device, perhaps similar to using RAM instead of RAM memory, if you understand what I mean. Regards Niclas +.Va pci_io +structure. +The +.Va pci_io +structure is described above, however, the +.Va pi_reg +and +.Va pi_width +fields are not used. +The status of the device is stored in the +.Va pi_data +field. +A value of 0 indicates no driver is attached, while a value larger than 0 +indicates that a driver is attached. .It PCIOCBARMMAP This .Xr ioctl 2 -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r349133 - head/share/man/man4
Author: zeising (doc,ports committer) Date: Mon Jun 17 05:41:47 2019 New Revision: 349133 URL: https://svnweb.freebsd.org/changeset/base/349133 Log: pci(4): Document PCIOCATTACHED Document the PCIOCATTACHED ioctl(2) in the pci(4) manual. PCIOCATTACHED is used to query if a driver has attached to a PCI. Reviewed by: bcr, imp MFC after:2 weeks Differential Revision:https://reviews.freebsd.org/D20652 Modified: head/share/man/man4/pci.4 Modified: head/share/man/man4/pci.4 == --- head/share/man/man4/pci.4 Mon Jun 17 03:48:44 2019(r349132) +++ head/share/man/man4/pci.4 Mon Jun 17 05:41:47 2019(r349133) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 14, 2018 +.Dd June 17, 2019 .Dt PCI 4 .Os .Sh NAME @@ -333,6 +333,26 @@ The limitations on data width described for reading registers, above, also apply to writing .Tn PCI configuration registers. +.It PCIOCATTACHED +This +.Xr ioctl 2 +allows users to query if a driver is attached to the +.Tn PCI +specified in the passed-in +.Va pci_io +structure. +The +.Va pci_io +structure is described above, however, the +.Va pi_reg +and +.Va pi_width +fields are not used. +The status of the device is stored in the +.Va pi_data +field. +A value of 0 indicates no driver is attached, while a value larger than 0 +indicates that a driver is attached. .It PCIOCBARMMAP This .Xr ioctl 2 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r348873 - head/sys/dev/atkbdc
On 2019-06-10 22:04, Rodney W. Grimes wrote: Author: zeising (doc,ports committer) Date: Mon Jun 10 18:19:49 2019 New Revision: 348873 URL: https://svnweb.freebsd.org/changeset/base/348873 Log: psm(4): Enable touchpads and trackpads by default Enable synaptics and elantech touchpads, as well as IBM/Lenovo TrackPoints by default, instead of having users find and toggle a loader tunable. This makes things like two finger scroll and other modern features work out of the box with X. By enabling these settings by default, we get a better desktop experience in X, since xserver and evdev can make use of the more advanced synaptics and elantech features. Reviewed by: imp, wulf, 0mp Approved by: imp Sponsored by:B3 Init (zeising) Differential Revision: https://reviews.freebsd.org/D20507 This should of probably had a Relnotes: Yes as it changes default system behavior. You are right, sorry for not thinking about that. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r348873 - head/sys/dev/atkbdc
Author: zeising (doc,ports committer)
Date: Mon Jun 10 18:19:49 2019
New Revision: 348873
URL: https://svnweb.freebsd.org/changeset/base/348873
Log:
psm(4): Enable touchpads and trackpads by default
Enable synaptics and elantech touchpads, as well as IBM/Lenovo TrackPoints
by default, instead of having users find and toggle a loader tunable.
This makes things like two finger scroll and other modern features work out
of the box with X. By enabling these settings by default, we get a better
desktop experience in X, since xserver and evdev can make use of the more
advanced synaptics and elantech features.
Reviewed by: imp, wulf, 0mp
Approved by: imp
Sponsored by: B3 Init (zeising)
Differential Revision:https://reviews.freebsd.org/D20507
Modified:
head/sys/dev/atkbdc/psm.c
Modified: head/sys/dev/atkbdc/psm.c
==
--- head/sys/dev/atkbdc/psm.c Mon Jun 10 17:44:50 2019(r348872)
+++ head/sys/dev/atkbdc/psm.c Mon Jun 10 18:19:49 2019(r348873)
@@ -513,9 +513,9 @@ static devclass_t psm_devclass;
/* Tunables */
static int tap_enabled = -1;
static int verbose = PSM_DEBUG;
-static int synaptics_support = 0;
-static int trackpoint_support = 0;
-static int elantech_support = 0;
+static int synaptics_support = 1;
+static int trackpoint_support = 1;
+static int elantech_support = 1;
/* for backward compatibility */
#defineOLD_MOUSE_GETHWINFO _IOR('M', 1, old_mousehw_t)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r348355 - head/sys/dev/iicbus
On 2019-06-03 17:19, Andriy Gapon wrote: On 03/06/2019 17:52, Ian Lepore wrote: Please don't. We still have a situation where nobody has shown a runtime failure at all. This build failure could be fixed by simply defining a do-nothing iicbus_set_nostop() function if a quick fix is needed. Well, I am quite certain that the run-time failure will follow after the build time failure is fixed. Putting this nostop concept into code that is shared by many drivers is an abomination. We have exactly one driver that needs this functionality, so the right fix is to implement it wholly within that one driver. I'll put together a diff for that. That's true that we have just one such driver. At the same time, the "no stop" (or rather, repeated start) behavior makes more sense. If stop+start between transfers are needed then that can be done with multiple calls to iicbus_transfer. If multiple messages are given to iicbus_transfer, then it's reasonable to assume that a repeated started is wanted between them. But it would be a big change to review and, if needed, fix or tidy up all code that uses iicbus_transfer. So, iicbus_set_nostop() could be just a small step towards the bigger goal. But I really don't have a strong opinion. Fixing drm2 directly is just as good for me as iicbus_set_nostop. Hi! From my perspective, either solution is fine, as long as the drm-legacy drivers keep on working, and I get some help fixing the issue. Is there any way we can revert this change while we're discussing the best solution to this? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r348355 - head/sys/dev/iicbus
On 2019-06-03 14:08, Andriy Gapon wrote: On 03/06/2019 14:16, Niclas Zeising wrote: Hi! It seems like things broke after all, latest pkg build (on head-amd64) reports this: /wrkdirs/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-12bd551/src/dev/drm2/i915/intel_iic.c:570:2: error: implicit declaration of function 'iicbus_set_nostop' is invalid in C99 [-Werror,-Wimplicit-function-declaration] iicbus_set_nostop(idev, true); ^ /wrkdirs/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-12bd551/src/dev/drm2/i915/intel_iic.c:570:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] 2 errors generated. Full log: http://beefy12.nyi.freebsd.org/data/head-amd64-default/p503023_s348376/logs/drm-legacy-kmod-g20190523.log Hi! Thank you for the report. I am going to restore iicbus_set_nostop, but this time as a function that modifies iicbus softc (instead of an ivar accessor for the bus). I am including a patch that I would like to commit. However, for the drm code to request the nostop mode correctly it needs to be fixed as well. My proposed patch is here: https://github.com/FreeBSDDesktop/drm-legacy/pull/9 Thank you, I will try it out. Will this break drm-legacy-kmod on 12, which doesn't have the iic bus change you proposed? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r348355 - head/sys/dev/iicbus
On 2019-05-29 22:52, Ian Lepore wrote: On Wed, 2019-05-29 at 15:12 +0300, Andriy Gapon wrote: On 29/05/2019 14:54, Niclas Zeising wrote: On 2019-05-29 11:08, Andriy Gapon wrote: Author: avg Date: Wed May 29 09:08:20 2019 New Revision: 348355 URL: https://svnweb.freebsd.org/changeset/base/348355 Log: revert r273728 and parts of r306589, iicbus no-stop by default feature Since drm2 removal, there has not been any consumer of the feature in the tree. I am also unaware of any out-of-tree consumer. More importantly, the feature has been broken from the very start, both before and after r306589, because the ivar was set on a device that does not support it and it was read from another device that also does not support it. A bus-wide no-stop flag cannot be implemented as an ivar as iicbus attaches as a child of various drivers. Implementing the ivar in each and every I2C driver is just impractical. If we ever want to implement this feature properly, then probably the easiest way to do it would be via a flag in the softc of iicbus. In fact, we might have to do that in the stable branches if we want to fix the code for them. Reported by:ian (long time ago) MFC after:1 month (maybe) X-MFC-note:cannot just merge the change, must keep drm2 happy Hi! Just a note, be aware that drm2 lives on in ports as drm-legacy-kmod. I haven't tested, but, from the description above I worry that it will affect the port. What do you think? Oh, I forgot about that one... I think that it could be affected if it still uses FreeBSD iic code. I guess I might have to revert the change. I don't think so, because I don't think this change ever worked. I'm not sure how anybody convinced themselves that it did. It attempts to retrieve ivars from a device that doesn't have them, so the net effect is that the nostop variable is initialized from stack garbage. Maybe whoever wrote and tested it was lucky enough to have that accidentally be consistently zero or non-zero, so their testing appeared to work. Looking at the drm2 code that is the only user of this, it appears that the nostop value is only used in the case where the driver falls back to using the builtin intel_iicbb_driver. That driver relies on iicbus_transfer_gen() which is where the nostop kludge was added. That's the fundamental problem in all of this: the right thing to do, IMO, would have been to implement the iicbus_transfer method directly in the intel_iicbb_driver (probably by just cut-and-pasting the code from iicconf.c then doing whatever is necessary to ignore stops). And we can still do that, pretty trivially, if necessary. -- Ian Hi! It seems like things broke after all, latest pkg build (on head-amd64) reports this: /wrkdirs/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-12bd551/src/dev/drm2/i915/intel_iic.c:570:2: error: implicit declaration of function 'iicbus_set_nostop' is invalid in C99 [-Werror,-Wimplicit-function-declaration] iicbus_set_nostop(idev, true); ^ /wrkdirs/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-12bd551/src/dev/drm2/i915/intel_iic.c:570:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] 2 errors generated. Full log: http://beefy12.nyi.freebsd.org/data/head-amd64-default/p503023_s348376/logs/drm-legacy-kmod-g20190523.log Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r348355 - head/sys/dev/iicbus
On 2019-05-29 11:08, Andriy Gapon wrote: Author: avg Date: Wed May 29 09:08:20 2019 New Revision: 348355 URL: https://svnweb.freebsd.org/changeset/base/348355 Log: revert r273728 and parts of r306589, iicbus no-stop by default feature Since drm2 removal, there has not been any consumer of the feature in the tree. I am also unaware of any out-of-tree consumer. More importantly, the feature has been broken from the very start, both before and after r306589, because the ivar was set on a device that does not support it and it was read from another device that also does not support it. A bus-wide no-stop flag cannot be implemented as an ivar as iicbus attaches as a child of various drivers. Implementing the ivar in each and every I2C driver is just impractical. If we ever want to implement this feature properly, then probably the easiest way to do it would be via a flag in the softc of iicbus. In fact, we might have to do that in the stable branches if we want to fix the code for them. Reported by: ian (long time ago) MFC after: 1 month (maybe) X-MFC-note: cannot just merge the change, must keep drm2 happy Hi! Just a note, be aware that drm2 lives on in ports as drm-legacy-kmod. I haven't tested, but, from the description above I worry that it will affect the port. What do you think? Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r348114 - head
Author: zeising (doc,ports committer) Date: Wed May 22 16:59:22 2019 New Revision: 348114 URL: https://svnweb.freebsd.org/changeset/base/348114 Log: Fix ObsoleteFiles after ethernet driver removal Fix OpsoleteFiles.inc after removal of ethernet drivers. The drivers have manual pages, and manual pages are generally stored compressed, with a .gz suffix, but this is not reflected in ObsoleteFiles and make delete-old fails to remove them. Approved by: brooks Sponsored by: B3 Init Differential Revision:https://reviews.freebsd.org/D20351 Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Wed May 22 16:24:39 2019(r348113) +++ head/ObsoleteFiles.inc Wed May 22 16:59:22 2019(r348114) @@ -39,31 +39,31 @@ # done # 20190517: Remove obsolete 10 and 10/100 ethernet drivers. -OLD_FILES+=usr/share/man/man4/bm.4 -OLD_FILES+=usr/share/man/man4/cs.4 -OLD_FILES+=usr/share/man/man4/de.4 -OLD_FILES+=usr/share/man/man4/if_de.4 -OLD_FILES+=usr/share/man/man4/ed.4 -OLD_FILES+=usr/share/man/man4/if_ed.4 -OLD_FILES+=usr/share/man/man4/ep.4 -OLD_FILES+=usr/share/man/man4/ex.4 -OLD_FILES+=usr/share/man/man4/fe.4 -OLD_FILES+=usr/share/man/man4/pcn.4 -OLD_FILES+=usr/share/man/man4/if_pcn.4 -OLD_FILES+=usr/share/man/man4/sf.4 -OLD_FILES+=usr/share/man/man4/if_sf.4 -OLD_FILES+=usr/share/man/man4/sn.4 -OLD_FILES+=usr/share/man/man4/if_sn.4 -OLD_FILES+=usr/share/man/man4/tl.4 -OLD_FILES+=usr/share/man/man4/if_tl.4 -OLD_FILES+=usr/share/man/man4/tx.4 -OLD_FILES+=usr/share/man/man4/if_tx.4 -OLD_FILES+=usr/share/man/man4/txp.4 -OLD_FILES+=usr/share/man/man4/if_txp.4 -OLD_FILES+=usr/share/man/man4/vx.4 -OLD_FILES+=usr/share/man/man4/wb.4 -OLD_FILES+=usr/share/man/man4/xe.4 -OLD_FILES+=usr/share/man/man4/if_xe.4 +OLD_FILES+=usr/share/man/man4/bm.4.gz +OLD_FILES+=usr/share/man/man4/cs.4.gz +OLD_FILES+=usr/share/man/man4/de.4.gz +OLD_FILES+=usr/share/man/man4/if_de.4.gz +OLD_FILES+=usr/share/man/man4/ed.4.gz +OLD_FILES+=usr/share/man/man4/if_ed.4.gz +OLD_FILES+=usr/share/man/man4/ep.4.gz +OLD_FILES+=usr/share/man/man4/ex.4.gz +OLD_FILES+=usr/share/man/man4/fe.4.gz +OLD_FILES+=usr/share/man/man4/pcn.4.gz +OLD_FILES+=usr/share/man/man4/if_pcn.4.gz +OLD_FILES+=usr/share/man/man4/sf.4.gz +OLD_FILES+=usr/share/man/man4/if_sf.4.gz +OLD_FILES+=usr/share/man/man4/sn.4.gz +OLD_FILES+=usr/share/man/man4/if_sn.4.gz +OLD_FILES+=usr/share/man/man4/tl.4.gz +OLD_FILES+=usr/share/man/man4/if_tl.4.gz +OLD_FILES+=usr/share/man/man4/tx.4.gz +OLD_FILES+=usr/share/man/man4/if_tx.4.gz +OLD_FILES+=usr/share/man/man4/txp.4.gz +OLD_FILES+=usr/share/man/man4/if_txp.4.gz +OLD_FILES+=usr/share/man/man4/vx.4.gz +OLD_FILES+=usr/share/man/man4/wb.4.gz +OLD_FILES+=usr/share/man/man4/xe.4.gz +OLD_FILES+=usr/share/man/man4/if_xe.4.gz # 20190513: libcap_sysctl interface change OLD_FILES+=lib/casper/libcap_sysctl.1 # 20190509: tests/sys/opencrypto requires the net/py-dpkt package. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r347695 - in head/sys: amd64/amd64 amd64/include kern
On 2019-05-19 10:11, Dmitry Chagin wrote: сб, 18 мая 2019 г. в 11:44, Konstantin Belousov : On Sat, May 18, 2019 at 11:35:29AM +0300, Dmitry Chagin wrote: чт, 16 мая 2019 г. в 16:29, Konstantin Belousov : Author: kib Date: Thu May 16 13:28:48 2019 New Revision: 347695 URL: https://svnweb.freebsd.org/changeset/base/347695 Log: amd64 pmap: rework delayed invalidation, removing global mutex. For machines having cmpxcgh16b instruction, i.e. everything but very early Athlons, provide lockless implementation of delayed invalidation. The implementation maintains lock-less single-linked list with the trick from the T.L. Harris article about volatile mark of the elements being removed. Double-CAS is used to atomically update both link and generation. New thread starting DI appends itself to the end of the queue, setting the generation to the generation of the last element +1. On DI finish, thread donates its generation to the previous element. The generation of the fake head of the list is the last passed DI generation. Basically, the implementation is a queued spinlock but without spinlock. Hi, Kostik! First of all thanks for the previous help. Second, this commit broke i915kms module. Unfortunatelly, I can't give you a lot of information becouse I see only black screen, but I can help with testing Did you recompiled the module ? I use pkg, but after your mail, yes, compiled drm-current-kmod root@mordor:~ # kldstat Id Refs AddressSize Name 14 0x8020 1d536e0 kernel 21 0x81f54000 11e8 acpi_call.ko root@mordor:~ # kldload i915kms sysctl_warn_reuse: can't re-use a leaf (compat.linuxkpi.debug)! drmn1: on vgapci1 device_attach: drmn1 attach returned 19 root@mordor:~ so, I'll ping freebsd-x11 Hi! drm-current-kmod was updated to the 20190519 snapshot, can you try that? If it still fails, please send a message to x...@freebsd.org . Thanks! Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346958 - head/sys/compat/linuxkpi/common/src
On 2019-04-30 12:41, Hans Petter Selasky wrote: Author: hselasky Date: Tue Apr 30 10:41:20 2019 New Revision: 346958 URL: https://svnweb.freebsd.org/changeset/base/346958 Log: Reduce the number of mutexes after r346645 in the LinuxKPI. Make function macro wrappers for locking and unlocking to ease readability. No functional change. Discussed with: kib@, tychon@ and zeising@ I was not part of any discussion regarding this. If this is related to https://reviews.freebsd.org/D20097 I explicitly asked you on gitter to hold of for a bit, while we try to figure out why we are seeing regressions in graphics with the latest dmar changes. Can you please revert this since it colludes the dmar graphics issue, and it makes the suggested patch not apply cleanly, which makes it harder to get people to help test. Thank you! Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r346899 - head
Author: zeising (doc,ports committer) Date: Mon Apr 29 18:20:51 2019 New Revision: 346899 URL: https://svnweb.freebsd.org/changeset/base/346899 Log: Add a note to MAINTAINERS for lkpi for graphics Add a note to MAINTAINERS requesting pre-commit review from the graphics team, using phabricator, for changes to the lkpi subsystem. This is done in order to give us a chance to test the graphics drivers (drm drivers) for regressions, and to try to avoid breakage, errors and issues with the graphics drivers. The review is done via the #x11 group on phabricator. Please note that hselasky also want to review changes. Discussed with: hselasky, imp Approved by: imp Modified: head/MAINTAINERS Modified: head/MAINTAINERS == --- head/MAINTAINERSMon Apr 29 18:09:55 2019(r346898) +++ head/MAINTAINERSMon Apr 29 18:20:51 2019(r346899) @@ -90,6 +90,10 @@ share/mk/*.test.mk freebsd-testing,ngie (same list as stand/forthdteske Pre-commit review requested. stand/lua kevans Pre-commit review requested sys/compat/linuxkpihselaskyIf in doubt, ask. + zeising, johalunpre-commit review requested via + #x11 phabricator group. + (to avoid drm graphics drivers + inpact) sys/contrib/ipfilter cy Pre-commit review requested. sys/dev/e1000 erj Pre-commit phabricator review requested. sys/dev/ixgbe erj Pre-commit phabricator review requested. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r342389 - head/share/man/man5
On 12/28/18 7:43 PM, Chris Rees wrote: Hey, On 28 December 2018 18:19:57 GMT+00:00, Niclas Zeising wrote: On 12/24/18 11:47 AM, Chris Rees wrote: Author: crees (doc,ports committer) Date: Mon Dec 24 10:47:48 2018 New Revision: 342389 URL: https://svnweb.freebsd.org/changeset/base/342389 Log: Clarify kld_list format PR: docs/234248 Submitted by: David Fiander Submitted by: Miroslav Lachman Modified: head/share/man/man5/rc.conf.5 Modified: head/share/man/man5/rc.conf.5 == --- head/share/man/man5/rc.conf.5 Mon Dec 24 06:14:32 2018 (r342388) +++ head/share/man/man5/rc.conf.5 Mon Dec 24 10:47:48 2018 (r342389) @@ -248,12 +248,14 @@ Default .Pa /etc/ddb.conf . .It Va kld_list .Pq Vt str -A list of kernel modules to load right after the local -disks are mounted. +A whitespace-separated list of kernel modules to load right after +the local disks are mounted, without any +.Pa .ko +extension or path. Loading modules at this point in the boot process is much faster than doing it via .Pa /boot/loader.conf -for those modules not necessary for mounting local disk. +for those modules not necessary for mounting local disks. .It Va kldxref_enable .Pq Vt bool Set to Hi! Sorry for jumping into this so late. Please please PLEASE don't break loading modules by path in kld_list. This is used by the drm-kmod files to distinguish them from the base modules, and this has been communicated in documentation all over the place, including numerous ports. Can this please be reverted, or amended to match reality. In practice, adding both the path and the extension (.ko) to a module in kld_list works and the module loads. As the code itself stands, it works for loading, but throws an error if you try to load an already loaded module adding a .ko extension. In other words, it works but is wrong. The path actually still does work, which was my mistake. I'm awaiting approval for this, which correctly handles all cases: https://reviews.freebsd.org/D18670 Konstantin has reviewed, but doesn't feel comfortable giving approval as it's not his area, which is fair enough. Chris Ok. Will this continue to work when loading /path/to/foo.ko rather than path/to/foo? (I assume it will) Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r342389 - head/share/man/man5
On 12/24/18 11:47 AM, Chris Rees wrote: Author: crees (doc,ports committer) Date: Mon Dec 24 10:47:48 2018 New Revision: 342389 URL: https://svnweb.freebsd.org/changeset/base/342389 Log: Clarify kld_list format PR: docs/234248 Submitted by:David Fiander Submitted by:Miroslav Lachman Modified: head/share/man/man5/rc.conf.5 Modified: head/share/man/man5/rc.conf.5 == --- head/share/man/man5/rc.conf.5 Mon Dec 24 06:14:32 2018 (r342388) +++ head/share/man/man5/rc.conf.5 Mon Dec 24 10:47:48 2018 (r342389) @@ -248,12 +248,14 @@ Default .Pa /etc/ddb.conf . .It Va kld_list .Pq Vt str -A list of kernel modules to load right after the local -disks are mounted. +A whitespace-separated list of kernel modules to load right after +the local disks are mounted, without any +.Pa .ko +extension or path. Loading modules at this point in the boot process is much faster than doing it via .Pa /boot/loader.conf -for those modules not necessary for mounting local disk. +for those modules not necessary for mounting local disks. .It Va kldxref_enable .Pq Vt bool Set to Hi! Sorry for jumping into this so late. Please please PLEASE don't break loading modules by path in kld_list. This is used by the drm-kmod files to distinguish them from the base modules, and this has been communicated in documentation all over the place, including numerous ports. Can this please be reverted, or amended to match reality. In practice, adding both the path and the extension (.ko) to a module in kld_list works and the module loads. Regards -- Niclas Zeising FreeBSD Graphics Team ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r341831 - stable/12/sys/powerpc/conf
Author: zeising (doc,ports committer) Date: Tue Dec 11 21:01:38 2018 New Revision: 341831 URL: https://svnweb.freebsd.org/changeset/base/341831 Log: MFC 340694: Enable evdev on ppc32 Enable evdev on ppc32 as well, similar to what was done i386 and amd64 in r340387 and ppc64 in r340632. Evdev can be used by X and is used by wayland to handle input devices. Approved by: jhibbits Modified: stable/12/sys/powerpc/conf/GENERIC Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/powerpc/conf/GENERIC == --- stable/12/sys/powerpc/conf/GENERIC Tue Dec 11 20:56:05 2018 (r341830) +++ stable/12/sys/powerpc/conf/GENERIC Tue Dec 11 21:01:38 2018 (r341831) @@ -219,3 +219,8 @@ device sound # Generic sound driver (required) device snd_ai2s# Apple I2S audio device snd_davbus # Apple DAVBUS audio device snd_uaudio # USB Audio + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r341830 - stable/12/sys/powerpc/conf
Author: zeising (doc,ports committer) Date: Tue Dec 11 20:56:05 2018 New Revision: 341830 URL: https://svnweb.freebsd.org/changeset/base/341830 Log: MFC 340632 Enable evdev on ppc64 Enable evdev on ppc64 as well, similar to what was done for amd64 and i386 in r340387. Evdev can be used by X and is used by wayland to handle input devices. Approved by: mmacy Modified: stable/12/sys/powerpc/conf/GENERIC64 Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/powerpc/conf/GENERIC64 == --- stable/12/sys/powerpc/conf/GENERIC64Tue Dec 11 20:47:00 2018 (r341829) +++ stable/12/sys/powerpc/conf/GENERIC64Tue Dec 11 20:56:05 2018 (r341830) @@ -227,3 +227,7 @@ device sound # Generic sound driver (required) device snd_ai2s# Apple I2S audio device snd_uaudio # USB Audio +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r340997 - head/lib/libarchive
On 12/2/18 4:03 AM, Justin Hibbits wrote:
On Mon, Nov 26, 2018 at 3:45 PM Martin Matuska wrote:
Author: mm
Date: Mon Nov 26 21:45:27 2018
New Revision: 340997
URL: https://svnweb.freebsd.org/changeset/base/340997
Log:
libarchive configuration changes
- move HAVE_BZLIB_H, HAVE_LIBLZMA and HAVE_LZMA_H to config_freebsd.h
- activate support for multi-threaded lzma encoding [1]
PR: 233543 [1]
Reported by: cem
MFC after:1 week
Modified:
head/lib/libarchive/Makefile
head/lib/libarchive/config_freebsd.h
Modified: head/lib/libarchive/Makefile
==
--- head/lib/libarchive/MakefileMon Nov 26 20:56:05 2018
(r340996)
+++ head/lib/libarchive/MakefileMon Nov 26 21:45:27 2018
(r340997)
@@ -7,7 +7,6 @@ _LIBARCHIVEDIR= ${SRCTOP}/contrib/libarchive
LIB= archive
LIBADD=z bz2 lzma bsdxml
-CFLAGS+= -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1
# FreeBSD SHLIB_MAJOR value is managed as part of the FreeBSD system.
# It has no real relation to the libarchive version number.
Modified: head/lib/libarchive/config_freebsd.h
==
--- head/lib/libarchive/config_freebsd.hMon Nov 26 20:56:05 2018
(r340996)
+++ head/lib/libarchive/config_freebsd.hMon Nov 26 21:45:27 2018
(r340997)
@@ -133,14 +133,17 @@
#define HAVE_LCHFLAGS 1
#define HAVE_LCHMOD 1
#define HAVE_LCHOWN 1
+#define HAVE_LIBLZMA 1
#define HAVE_LIBZ 1
#define HAVE_LIMITS_H 1
#define HAVE_LINK 1
+#define HAVE_LZMA_H 1
#define HAVE_LOCALE_H 1
#define HAVE_LOCALTIME_R 1
#define HAVE_LONG_LONG_INT 1
#define HAVE_LSTAT 1
#define HAVE_LUTIMES 1
+#define HAVE_LZMA_STREAM_ENCODER_MT 1
#define HAVE_MBRTOWC 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMORY_H 1
This breaks ports-mgmt/pkg now, with the following failure log:
--- pkg-static ---
/usr/lib/liblzma.a(stream_encoder_mt.o): In function `mythread_cond_init':
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:230:
undefined reference to `pthread_condattr_init'
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:233:
undefined reference to `pthread_condattr_setclock'
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:237:
undefined reference to `pthread_condattr_destroy'
/usr/lib/liblzma.a(stream_encoder_mt.o): In function `get_thread':
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:237:
undefined reference to `pthread_condattr_destroy'
/usr/lib/liblzma.a(stream_encoder_mt.o): In function `mythread_cond_init':
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:233:
undefined reference to `pthread_condattr_setclock'
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:237:
undefined reference to `pthread_condattr_destroy'
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:230:
undefined reference to `pthread_condattr_init'
/usr/local/poudriere/jails/ppc64/usr/src/contrib/xz/src/common/mythread.h:237:
undefined reference to `pthread_condattr_destroy'
*** [pkg-static] Error code 1
I'm seeing the same issue when builing i386 packages on amd64 using
poudriere. For some reason the amd64 build is fine. This needs to be
reverted or fixed asap.
In the diff above it also looks like the -DHAVE_BZLIB_H=1 flag was
forgottgen when moving to config_freebsd.h, but perhaps this was
intentional.
Regards
--
Niclas Zeising
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r340695 - in stable/12/sys: amd64/conf i386/conf
On 11/20/18 9:07 PM, Rodney W. Grimes wrote: [ Charset UTF-8 unsupported, converting... ] Author: zeising (doc,ports committer) Date: Tue Nov 20 19:37:09 2018 New Revision: 340695 URL: https://svnweb.freebsd.org/changeset/base/340695 Log: MFC r340387: Add evdev support to amd64 and i386 This merge is done sans sys/i386/conf/MINIMAL, since that doesn't exist in stable/12, only current. Could you do me a favor and track down why MINIMAL has not be mfc'ed? And if there is not a good reason for it to not be MFC'ed see that it does get done. I asked about it cem (the original author of i386/conf/MINIMAL) about it here: https://lists.freebsd.org/pipermail/svn-src-all/2018-November/172337.html The reply is here: https://lists.freebsd.org/pipermail/svn-src-all/2018-November/172353.html Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r340695 - in stable/12/sys: amd64/conf i386/conf
Author: zeising (doc,ports committer) Date: Tue Nov 20 19:37:09 2018 New Revision: 340695 URL: https://svnweb.freebsd.org/changeset/base/340695 Log: MFC r340387: Add evdev support to amd64 and i386 This merge is done sans sys/i386/conf/MINIMAL, since that doesn't exist in stable/12, only current. Include evdev support and drivers in the amd64 GENERIC and MINIMAL, and i386 GENERIC kernels. Evdev is used by X and wayland to handle input devices, and this change, together with upcomming changes in ports will make us handle input devices better in graphical UIs. Reviewed by: wulf, bapt, imp Approved by: imp Modified: stable/12/sys/amd64/conf/GENERIC stable/12/sys/amd64/conf/MINIMAL stable/12/sys/i386/conf/GENERIC Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/amd64/conf/GENERIC == --- stable/12/sys/amd64/conf/GENERICTue Nov 20 19:31:02 2018 (r340694) +++ stable/12/sys/amd64/conf/GENERICTue Nov 20 19:37:09 2018 (r340695) @@ -360,3 +360,8 @@ device vmx # VMware VMXNET3 Ethernet # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Modified: stable/12/sys/amd64/conf/MINIMAL == --- stable/12/sys/amd64/conf/MINIMALTue Nov 20 19:31:02 2018 (r340694) +++ stable/12/sys/amd64/conf/MINIMALTue Nov 20 19:37:09 2018 (r340695) @@ -137,3 +137,8 @@ device bpf # Berkeley packet filter # NOTE: XENHVM depends on xenpci. They must be added or removed together. optionsXENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Modified: stable/12/sys/i386/conf/GENERIC == --- stable/12/sys/i386/conf/GENERIC Tue Nov 20 19:31:02 2018 (r340694) +++ stable/12/sys/i386/conf/GENERIC Tue Nov 20 19:37:09 2018 (r340695) @@ -358,3 +358,8 @@ device xenpci # Xen HVM Hypervisor services driver # VMware support device vmx # VMware VMXNET3 Ethernet + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r340694 - head/sys/powerpc/conf
Author: zeising (doc,ports committer) Date: Tue Nov 20 19:31:02 2018 New Revision: 340694 URL: https://svnweb.freebsd.org/changeset/base/340694 Log: Enable evdev on ppc32 Enable evdev on ppc32 as well, similar to what was done i386 and amd64 in r340387 and ppc64 in r340632. Evdev can be used by X and is used by wayland to handle input devices. Approved by: jhibbits MFC after:2 weeks Differential Revision:https://reviews.freebsd.org/D18049 Modified: head/sys/powerpc/conf/GENERIC Modified: head/sys/powerpc/conf/GENERIC == --- head/sys/powerpc/conf/GENERIC Tue Nov 20 19:02:10 2018 (r340693) +++ head/sys/powerpc/conf/GENERIC Tue Nov 20 19:31:02 2018 (r340694) @@ -228,3 +228,8 @@ device sound # Generic sound driver (required) device snd_ai2s# Apple I2S audio device snd_davbus # Apple DAVBUS audio device snd_uaudio # USB Audio + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r340632 - head/sys/powerpc/conf
On 11/19/18 4:42 PM, Justin Hibbits wrote: On Mon, 19 Nov 2018 15:36:58 + (UTC) Niclas Zeising wrote: Author: zeising (doc,ports committer) Date: Mon Nov 19 15:36:58 2018 New Revision: 340632 URL: https://svnweb.freebsd.org/changeset/base/340632 Log: Enable evdev on ppc64 Enable evdev on ppc64 as well, similar to what was done for amd64 and i386 in r340387. Evdev can be used by X and is used by wayland to handle input devices. Approved by: mmacy MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D18026 Modified: head/sys/powerpc/conf/GENERIC64 Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Mon Nov 19 15:31:54 2018(r340631) +++ head/sys/powerpc/conf/GENERIC64 Mon Nov 19 15:36:58 2018(r340632) @@ -246,3 +246,8 @@ device snd_uaudio # USB Audio # Netmap provides direct access to TX/RX rings on supported NICs devicenetmap # netmap(4) support + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Is there a reason this is only in GENERIC64, not GENERIC as well? Does it not compile for 32-bit powerpc? - Justin Hi! mmacy only asked about ppc64, and as far as I know it's only tested there. I can create a patch for ppc32 as well, but I can't test myself. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r339476 - head/sys/i386/conf
On 10/20/18 9:16 PM, Conrad Meyer wrote: Author: cem Date: Sat Oct 20 19:16:43 2018 New Revision: 339476 URL: https://svnweb.freebsd.org/changeset/base/339476 Log: Add a MINIMAL config for i386, based on amd64 Any plans to MFC this? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r340632 - head/sys/powerpc/conf
Author: zeising (doc,ports committer) Date: Mon Nov 19 15:36:58 2018 New Revision: 340632 URL: https://svnweb.freebsd.org/changeset/base/340632 Log: Enable evdev on ppc64 Enable evdev on ppc64 as well, similar to what was done for amd64 and i386 in r340387. Evdev can be used by X and is used by wayland to handle input devices. Approved by: mmacy MFC after:2 weeks Differential Revision:https://reviews.freebsd.org/D18026 Modified: head/sys/powerpc/conf/GENERIC64 Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Mon Nov 19 15:31:54 2018 (r340631) +++ head/sys/powerpc/conf/GENERIC64 Mon Nov 19 15:36:58 2018 (r340632) @@ -246,3 +246,8 @@ device snd_uaudio # USB Audio # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf
On 11/13/18 7:10 AM, Kevin Bowling wrote: ppc64 will be the next arch after amd64 to get modern graphics (https://github.com/POWER9BSD/freebsd/commits/projects/lkpi) but we like the tier-2 status for now and will replay changes from amd64 GENERIC once I'm able to test. FWIW evdev is the standard with libinput for X11 under Linux. It's useful for modern trackpads and has no downsides for traditional keyboards and mice under X11. It's also a requisite for Wayland. So I am happy to see this change, thanks Niclas!. This is great! Let me and the rest of the graphics team know if we can help in any way. I have no problem enabling evdev support in ppc64 (or any other arches) if it's tested at least a little. The only reason I only enabled it for i386 and amd64 is that those are the platforms I have available myself. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf
On 11/13/18 1:49 AM, Warner Losh wrote: On Mon, Nov 12, 2018 at 5:30 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net wrote: Author: zeising (doc,ports committer) Date: Mon Nov 12 21:01:28 2018 New Revision: 340387 URL: https://svnweb.freebsd.org/changeset/base/340387 Log: Add evdev support to amd64 and i386 kernels Include evdev support and drivers in the amd64 and i386 GENERIC and MINIMAL kernels. Evdev is used by X and wayland to handle input devices, and this change, together with upcomming changes in ports will make us handle input devices better in graphical UIs. Well these "upcomming" changes in ports effect aarch64 and powerpc who are also consumers of X? Likely. Though there is little experience with them, so we don't know if it is even safe to turn them on there yet. This has taken 6 months to get stable on x86 due to its fragile console locking protocol. Similar time has not been invested elsewhere, so until that happens, we should keep them off by default. Otherwise we run the risk of destabilizing these platforms, even for people who don't use X. As tier 2 platforms, this has been how we've traditionally approached risk. Even though aarch64 is approaching tier1 status overall, in graphics it is still lagging. From some place aarch64 is already a tier1 platform, specifically it is listed as such in the pkg.freebsd.org package download page. Graphics on aarch64 is tier 2, and will remain tier 2 for the foreseeable future. Tier 1 support requires that we leverage other people's drivers, and we can't easily do that w/o a good linux compat layer. The structure of FreeBSD and Linux are just enough different that doing so is somewhat tricky and labor intensive. This is especially true for the acceleration features. Basic framebuffer support isn't terribly hard, but to get good 2d and 3d acceleration, we'll likely need to run upstream vendor's code (which in many cases is available only as a binary blob + linux glue). My real concern here is that it sounded like changes to what are in the ports/packages are going to be made in such a way that you are required to have evdev to use them. If this suddently becomes mandatory to be able to use X we need to ensure that this code (evdev) does infact work on aarch64 and others before such changes are put in place. My reading here is that this code is only avaliable as static compile into the kernel, aka no moduleto load, making this a non-trivial road block to rpi3, etc users. This is just for touchscreen support on x86, which requires evdev to work well. Whatever works today won't change. However, without a lot of testing, I'm hesitant to blindly enable it on aarch64. Once that changes, we can turn it on, but until then it would be unwise. And evdev can be turned off on a per-platform basis in the packages / ports tree should the need arise. I don't think this is going to be an issue. Hi! This change makes it easier, and in some case possible, to use certain input devices, such as touchscreens, input tablets and so on. It will make it easier to use things like two finger scrolling or horizontal scrolling on touchpads, for instance. Using evdev and libinput (from ports) is a prerequisite for Wayland, and useful for X, however, for X the old input drivers are not going away, and can still be used on architectures without evdev. The input stack (for graphical environments) in FreeBSD is lagging behind Linux, and this is a first step to get it at least a little bit closer in terms of support. With regards to other architectures, I only have access to amd64 and to some extent i386, and only enabled the drivers there. I have no problem with enabling this on further architectures if I get help testing, or hardware to test on. As stated, this won't cause regressions on these platforms, the old input device drivers (xf86-input-*) won't go anywhere in a hurry, if ever, and is still available for use. I hope this clears things up a little. Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r340387 - in head/sys: amd64/conf i386/conf
Author: zeising (doc,ports committer) Date: Mon Nov 12 21:01:28 2018 New Revision: 340387 URL: https://svnweb.freebsd.org/changeset/base/340387 Log: Add evdev support to amd64 and i386 kernels Include evdev support and drivers in the amd64 and i386 GENERIC and MINIMAL kernels. Evdev is used by X and wayland to handle input devices, and this change, together with upcomming changes in ports will make us handle input devices better in graphical UIs. Reviewed by: wulf, bapt, imp Approved by: imp Differential Revision:https://reviews.freebsd.org/D17912 Modified: head/sys/amd64/conf/GENERIC head/sys/amd64/conf/MINIMAL head/sys/i386/conf/GENERIC head/sys/i386/conf/MINIMAL Modified: head/sys/amd64/conf/GENERIC == --- head/sys/amd64/conf/GENERIC Mon Nov 12 20:44:22 2018(r340386) +++ head/sys/amd64/conf/GENERIC Mon Nov 12 21:01:28 2018(r340387) @@ -372,3 +372,8 @@ device vmx # VMware VMXNET3 Ethernet # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Modified: head/sys/amd64/conf/MINIMAL == --- head/sys/amd64/conf/MINIMAL Mon Nov 12 20:44:22 2018(r340386) +++ head/sys/amd64/conf/MINIMAL Mon Nov 12 21:01:28 2018(r340387) @@ -147,3 +147,8 @@ device bpf # Berkeley packet filter # NOTE: XENHVM depends on xenpci. They must be added or removed together. optionsXENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Modified: head/sys/i386/conf/GENERIC == --- head/sys/i386/conf/GENERIC Mon Nov 12 20:44:22 2018(r340386) +++ head/sys/i386/conf/GENERIC Mon Nov 12 21:01:28 2018(r340387) @@ -366,3 +366,8 @@ device xenpci # Xen HVM Hypervisor services driver # VMware support device vmx # VMware VMXNET3 Ethernet + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev Modified: head/sys/i386/conf/MINIMAL == --- head/sys/i386/conf/MINIMAL Mon Nov 12 20:44:22 2018(r340386) +++ head/sys/i386/conf/MINIMAL Mon Nov 12 21:01:28 2018(r340387) @@ -148,3 +148,8 @@ device bpf # Berkeley packet filter # NOTE: XENHVM depends on xenpci. They must be added or removed together. optionsXENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver + +# evdev interface +optionsEVDEV_SUPPORT # evdev support in legacy drivers +device evdev # input event device support +device uinput # install /dev/uinput cdev ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r339823 - in head/sys/dev: atkbdc evdev kbdmux usb/input
On 10/27/18 11:26 PM, Vladimir Kondratyev wrote: On 27.10.2018 23:32, Niclas Zeising wrote: On 10/27/18 10:22 PM, Vladimir Kondratyev wrote: Author: wulf Date: Sat Oct 27 20:22:41 2018 New Revision: 339823 URL: https://svnweb.freebsd.org/changeset/base/339823 Log: evdev: Use console lock as evdev lock for all supported keyboard drivers. Now evdev part of keyboard drivers does not take any locks if corresponding input/eventN device node is not opened by userland consumers. Do not assert console lock inside evdev to handle the cases when keyboard driver is called from some special single-threaded context like shutdown thread. Related to https://reviews.freebsd.org/D15070 ? Yes it is a part of D15070. Along with r339824 it closes all issues known to me that preventing evdev to be enabled by default. Thank you! Any chance you can add a note in phabricator and close/abandon the review? Once again thank you! Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r339823 - in head/sys/dev: atkbdc evdev kbdmux usb/input
On 10/27/18 10:22 PM, Vladimir Kondratyev wrote: Author: wulf Date: Sat Oct 27 20:22:41 2018 New Revision: 339823 URL: https://svnweb.freebsd.org/changeset/base/339823 Log: evdev: Use console lock as evdev lock for all supported keyboard drivers. Now evdev part of keyboard drivers does not take any locks if corresponding input/eventN device node is not opened by userland consumers. Do not assert console lock inside evdev to handle the cases when keyboard driver is called from some special single-threaded context like shutdown thread. Modified: head/sys/dev/atkbdc/atkbd.c head/sys/dev/evdev/evdev_private.h head/sys/dev/kbdmux/kbdmux.c head/sys/dev/usb/input/ukbd.c Related to https://reviews.freebsd.org/D15070 ? Regards -- Niclas Zeising ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers
On 07/19/18 15:20, Cy Schubert wrote: In message <2f0ab2c2-b7cc-3dae-2d65-ea3c4a951...@daemonic.se>, Niclas Zeising w rites: [ sending this again since I missed the list the first time, apologies if anyone receives a duplicate ] On 07/19/18 13:57, Kyle Evans wrote: On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev wrote : On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: ... Yesterday I updated my notebook (with iwm(4)) and also noticed that wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restart wlan0 helps. After your message I reinstalled wpa_supplicant from old source and now it works stable already about 2 hours. So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ Well, "broken". It's incredibly stable outside of rekeying events, and further testing shows that I don't actually notice these disconnects most of the time because it reassociates fast enough. I noticed it the first time because apparently I had both SSIDs from my AP uncommented in my wpa_supplicant.conf and it decided at that point to connect to the other one, which took a little longer. Contrary to Andrey's report, though, I don't have to kick wpa_supplicant at all. It will reassociate on its own every single time. Hi! I have the exact same problem as Andrey, with the same driver. I've not investigated very much, but when using the 2.8 wpa_supplicant the wifi network dies after a little while, and I have to restart it (usually with /etc/rc.d/netif restart). Then it works for a little while, before going down again. With the old wpa_supplicant I didn't have this problem. I don't have very much else to add except noting that I'm affected as well. I haven't had time to debug it properly (which is why I've never reported it) Do these events happen at regular intervals as Kyle experienced or randomly? What sort of key_mgmt do you connect with to your AP? Could it be WPA-EAP? I do not know if it is random or not, I haven't timed it. It usually happens quite soon after a reboot. All nets I've tested have been WPA2 PSK. I've had the difference connecting to at least two different hotspots, once dual band 2.4/5GHz (although the NIC used 2.4GHz) and one with only 5 GHz. Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers
[ sending this again since I missed the list the first time, apologies if anyone receives a duplicate ] On 07/19/18 13:57, Kyle Evans wrote: On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev wrote: On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: ... Yesterday I updated my notebook (with iwm(4)) and also noticed that wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restart wlan0 helps. After your message I reinstalled wpa_supplicant from old source and now it works stable already about 2 hours. So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ Well, "broken". It's incredibly stable outside of rekeying events, and further testing shows that I don't actually notice these disconnects most of the time because it reassociates fast enough. I noticed it the first time because apparently I had both SSIDs from my AP uncommented in my wpa_supplicant.conf and it decided at that point to connect to the other one, which took a little longer. Contrary to Andrey's report, though, I don't have to kick wpa_supplicant at all. It will reassociate on its own every single time. Hi! I have the exact same problem as Andrey, with the same driver. I've not investigated very much, but when using the 2.8 wpa_supplicant the wifi network dies after a little while, and I have to restart it (usually with /etc/rc.d/netif restart). Then it works for a little while, before going down again. With the old wpa_supplicant I didn't have this problem. I don't have very much else to add except noting that I'm affected as well. I haven't had time to debug it properly (which is why I've never reported it) Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r334288 - head/etc/mtree
Author: zeising (doc,ports committer) Date: Mon May 28 17:08:37 2018 New Revision: 334288 URL: https://svnweb.freebsd.org/changeset/base/334288 Log: Complete removal of lmc(4) The lmc(4) driver was removed in r333144 and relevant files added to ObsoleteFiles.inc, however, include/sys/dev/lmc was not removed from mtree and is recreated on every install. Remove it from mtree. Reviewed by: imp, emaste Approved by: emaste Differential Revision:https://reviews.freebsd.org/D15590 Modified: head/etc/mtree/BSD.include.dist Modified: head/etc/mtree/BSD.include.dist == --- head/etc/mtree/BSD.include.dist Mon May 28 16:23:39 2018 (r334287) +++ head/etc/mtree/BSD.include.dist Mon May 28 17:08:37 2018 (r334288) @@ -128,8 +128,6 @@ .. io .. -lmc -.. mfi .. mlx5 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r333420 - in head: lib/libc/string usr.sbin/ipfwpcap
Author: zeising (doc,ports committer) Date: Wed May 9 17:06:52 2018 New Revision: 333420 URL: https://svnweb.freebsd.org/changeset/base/333420 Log: Remove "all rights reserved" on files where I have copyright. According to r91 it is not needed any more. Reviewed by: imp, emaste Differential Revision:https://reviews.freebsd.org/D15370 Modified: head/lib/libc/string/strchrnul.c head/usr.sbin/ipfwpcap/ipfwpcap.8 Modified: head/lib/libc/string/strchrnul.c == --- head/lib/libc/string/strchrnul.cWed May 9 16:52:28 2018 (r333419) +++ head/lib/libc/string/strchrnul.cWed May 9 17:06:52 2018 (r333420) @@ -2,7 +2,6 @@ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD * * Copyright (c) 2013 Niclas Zeising - * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions Modified: head/usr.sbin/ipfwpcap/ipfwpcap.8 == --- head/usr.sbin/ipfwpcap/ipfwpcap.8 Wed May 9 16:52:28 2018 (r333419) +++ head/usr.sbin/ipfwpcap/ipfwpcap.8 Wed May 9 17:06:52 2018 (r333420) @@ -1,5 +1,4 @@ .\" Copyright (c) 2006 Niclas Zeising -.\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r331880 - stable/11/etc
On 04/10/18 04:28, Kyle Evans wrote:
On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh wrote:
On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans wrote:
Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
and fix the ports to do the right thing for 12.x while that's still
not a technically supported branch?
Don't back out the version bump. Other things may be riding along on it 'for
free'. Better to bump it again when you unMFC (if it's been more than a few
days since we've had one), and then yet-again when a fixed MFC happens.
Unless there's something you can ride along on for free :)
Otherwise, that's a great plan.
Ok, I think the result of this thread and discussion with 0mp is the
following set of actions:
1.) One (1) commit to stable/11 to revert the MFC and bump
FreeBSD_Version again for the removal
2.) One (1) commit to doc to document the new FreeBSD_Version
3.) Fixing ports to use the "new" behavior on 12, both the
yet-to-be-patched ports and the ports that had already been patched
under the assumption that it would still land first in 11.1-stable
4.) Documenting the original commit?
The hard part of point #3 has already been done by 0mp, who has
submitted patches for all of the ports using this behavior. His
patches will just need a bump of the version they're testing to the
12.x FreeBSD_Version and a fix-up on the patches that already landed.
For point #4, this seems like the type of breakage we should be
documenting in release notes or something for the eventual upgrading
of systems to 12.0. All usage of _limits stuff in custom rc scripts
need to be audited, and all rc.conf(5)'s need to be scrubbed for
${name}_limits usage that doesn't make sense with the new context. I'm
not sure what the most appropriate action here is, or what we should
do this far ahead of time for such a thing.
If this sounds like a good path forward, I'll execute #1 and #2 in the
morning (CST, so ~11 hours from this e-mail being sent).
This still doesn't fix the issue of some early start up scripts
depending on stuff that's not available yet, when for instance /usr is
on a separate FS (which was the normal way to set up a system way back
when).
This issue was first noticed more than 2 years ago, so someone did
notice the breakage. It just hasn't been fixed for an entire release cycle.
Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r331880 - stable/11/etc
On 04/02/18 17:39, Rodney W. Grimes wrote:
Author: kevans
Date: Mon Apr 2 15:28:48 2018
New Revision: 331880
URL: https://svnweb.freebsd.org/changeset/base/331880
Log:
MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
Usage is ${name}_limits, and the argument is any flags accepted by
limits(1), such as `-n 100' (e.g. only allow 100 open files).
Modified:
stable/11/etc/rc.subr
Directory Properties:
stable/11/ (props changed)
Modified: stable/11/etc/rc.subr
==
--- stable/11/etc/rc.subr Mon Apr 2 15:07:41 2018(r331879)
+++ stable/11/etc/rc.subr Mon Apr 2 15:28:48 2018(r331880)
@@ -773,6 +773,8 @@ check_startmsgs()
#
# ${name}_login_class n Login class to use, else "daemon".
#
+# ${name}_limits n limits(1) to apply to ${command}.
+#
Caution, limits(1) is in /usr/bin, this code can fail if used before
/usr is mounted. (Ie, our rc.initdiskless) is probably broken by
this change if a call is made to limits.
Sorry for jumping on this so late. This is also an issue in CURRENT,
and has been since at least 2016.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r329154 - in head/etc: defaults devd
On 02/12/18 10:25, Gary Jennejohn wrote: On Mon, 12 Feb 2018 07:01:56 + Alexey Dokuchaev wrote: On Sun, Feb 11, 2018 at 10:55:48PM -0800, Cy Schubert wrote: In message <201802120651.w1c6pkqf042...@repo.freebsd.org>, Warner Losh writes: New Revision: 329154 URL: https://svnweb.freebsd.org/changeset/base/329154 Log: Turn devmatch on by default. Turn devmatch on by default. However, use 'start' instead of 'onestart' in the devmatch.conf file so the setting of 'devmatch_enable' is honored. Give an example of what to put in devd.conf if you want to disable just the run-time part of devmatch. ... @@ -41,7 +41,7 @@ ddb_enable="NO" # Set to YES to load ddb script s at b ddb_config="/etc/ddb.conf" # ddb(8) config file. devd_enable="YES" # Run devd, to trigger programs on device tree changes. devd_flags="" # Additional flags for devd(8). -devmatch_enable="NO" # Demand load kernel modules based on device ids. +devmatch_enable="YES"# Demand load kernel modules based on device id s. This assumes that everyone has /usr in /. We might want to consider moving devmatch to /sbin, or document that I was actually surprised to find out it's installed as /usr/sbin/devmatch; /sbin indeed looks more appropriate. /usr and / be merged. Please don't. +1 Any chance of moving /usr/bin/limits to /bin/limits at the same time? It's preventing some scripts (ddb) from running at boot. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291 for info. Regards! -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r326792 - head/stand/uboot/common
On 12/12/17 20:27, Cy Schubert wrote: PR 224080??? Yes please. Regards -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r326733 - head/usr.sbin/acpi/acpiconf
Author: zeising (doc,ports committer)
Date: Sat Dec 9 15:59:10 2017
New Revision: 326733
URL: https://svnweb.freebsd.org/changeset/base/326733
Log:
Improve options and error handling.
Improve options handling and error out if multiple mutually exclusive
options are passed to acpiconf. Switch from using atoi() to strtol() for
argument parsing, and add error checking and handling, instead of blindly
trusting that the integer conversion is OK.
Cange err() to errx() in once case, the errno value was garbage there.
Reviewed by: emaste
Approved by: emaste
Differential Revision:D13430
Modified:
head/usr.sbin/acpi/acpiconf/acpiconf.c
Modified: head/usr.sbin/acpi/acpiconf/acpiconf.c
==
--- head/usr.sbin/acpi/acpiconf/acpiconf.c Sat Dec 9 15:47:26 2017
(r326732)
+++ head/usr.sbin/acpi/acpiconf/acpiconf.c Sat Dec 9 15:59:10 2017
(r326733)
@@ -92,7 +92,7 @@ acpi_battinfo(int num)
uint32_t volt;
if (num < 0 || num > 64)
- err(EX_USAGE, "invalid battery %d", num);
+ errx(EX_USAGE, "invalid battery %d", num);
/* Print battery design information. */
battio.unit = num;
@@ -205,8 +205,9 @@ usage(const char* prog)
int
main(int argc, char *argv[])
{
- char*prog;
- int c, sleep_type;
+ char*prog, *end;
+ int c, sleep_type, battery, ack;
+ int iflag = 0, kflag = 0, sflag = 0;
prog = argv[0];
if (argc < 2)
@@ -218,16 +219,24 @@ main(int argc, char *argv[])
while ((c = getopt(argc, argv, "hi:k:s:")) != -1) {
switch (c) {
case 'i':
- acpi_battinfo(atoi(optarg));
+ iflag = 1;
+ battery = strtol(optarg, &end, 10);
+ if ((size_t)(end - optarg) != strlen(optarg))
+ errx(EX_USAGE, "invalid battery");
break;
case 'k':
- acpi_sleep_ack(atoi(optarg));
+ kflag = 1;
+ ack = strtol(optarg, &end, 10);
+ if ((size_t)(end - optarg) != strlen(optarg))
+ errx(EX_USAGE, "invalid ack argument");
break;
case 's':
+ sflag = 1;
if (optarg[0] == 'S')
- sleep_type = optarg[1] - '0';
- else
- sleep_type = optarg[0] - '0';
+ optarg++;
+ sleep_type = strtol(optarg, &end, 10);
+ if ((size_t)(end - optarg) != strlen(optarg))
+ errx(EX_USAGE, "invalid sleep type");
if (sleep_type < 1 || sleep_type > 4)
errx(EX_USAGE, "invalid sleep type (%d)",
sleep_type);
@@ -241,7 +250,25 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
- if (sleep_type != -1)
+ if (iflag != 0 && kflag != 0 && sflag != 0)
+ errx(EX_USAGE, "-i, -k and -s are mutually exclusive");
+
+ if (iflag != 0) {
+ if (kflag != 0)
+ errx(EX_USAGE, "-i and -k are mutually exclusive");
+ if (sflag != 0)
+ errx(EX_USAGE, "-i and -s are mutually exclusive");
+ acpi_battinfo(battery);
+ }
+
+ if (kflag != 0) {
+ if (sflag != 0)
+ errx(EX_USAGE, "-k and -s are mutually exclusive");
+ acpi_sleep_ack(ack);
+ }
+
+
+ if (sflag != 0)
acpi_sleep(sleep_type);
close(acpifd);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r326099 - head/usr.bin/iscsictl
Author: zeising (doc,ports committer)
Date: Wed Nov 22 18:06:41 2017
New Revision: 326099
URL: https://svnweb.freebsd.org/changeset/base/326099
Log:
Fix language in a bunch of error messages.
Reviewed by: emaste
Approved by: emaste
MFC after:1 month
Differential Revision:D13193
Modified:
head/usr.bin/iscsictl/iscsictl.c
Modified: head/usr.bin/iscsictl/iscsictl.c
==
--- head/usr.bin/iscsictl/iscsictl.cWed Nov 22 16:45:27 2017
(r326098)
+++ head/usr.bin/iscsictl/iscsictl.cWed Nov 22 18:06:41 2017
(r326099)
@@ -813,41 +813,41 @@ main(int argc, char **argv)
if (Aflag != 0) {
if (aflag != 0) {
if (enable != ENABLE_UNSPECIFIED)
- xo_errx(1, "-a and -e and mutually exclusive");
+ xo_errx(1, "-a and -e are mutually exclusive");
if (portal != NULL)
- xo_errx(1, "-a and -p and mutually exclusive");
+ xo_errx(1, "-a and -p are mutually exclusive");
if (target != NULL)
- xo_errx(1, "-a and -t and mutually exclusive");
+ xo_errx(1, "-a and -t are mutually exclusive");
if (user != NULL)
- xo_errx(1, "-a and -u and mutually exclusive");
+ xo_errx(1, "-a and -u are mutually exclusive");
if (secret != NULL)
- xo_errx(1, "-a and -s and mutually exclusive");
+ xo_errx(1, "-a and -s are mutually exclusive");
if (nickname != NULL)
- xo_errx(1, "-a and -n and mutually exclusive");
+ xo_errx(1, "-a and -n are mutually exclusive");
if (discovery_host != NULL)
- xo_errx(1, "-a and -d and mutually exclusive");
+ xo_errx(1, "-a and -d are mutually exclusive");
if (rflag != 0)
- xo_errx(1, "-a and -r and mutually exclusive");
+ xo_errx(1, "-a and -r are mutually exclusive");
} else if (nickname != NULL) {
if (enable != ENABLE_UNSPECIFIED)
- xo_errx(1, "-n and -e and mutually exclusive");
+ xo_errx(1, "-n and -e are mutually exclusive");
if (portal != NULL)
- xo_errx(1, "-n and -p and mutually exclusive");
+ xo_errx(1, "-n and -p are mutually exclusive");
if (target != NULL)
- xo_errx(1, "-n and -t and mutually exclusive");
+ xo_errx(1, "-n and -t are mutually exclusive");
if (user != NULL)
- xo_errx(1, "-n and -u and mutually exclusive");
+ xo_errx(1, "-n and -u are mutually exclusive");
if (secret != NULL)
- xo_errx(1, "-n and -s and mutually exclusive");
+ xo_errx(1, "-n and -s are mutually exclusive");
if (discovery_host != NULL)
- xo_errx(1, "-n and -d and mutually exclusive");
+ xo_errx(1, "-n and -d are mutually exclusive");
if (rflag != 0)
- xo_errx(1, "-n and -r and mutually exclusive");
+ xo_errx(1, "-n and -r are mutually exclusive");
} else if (discovery_host != NULL) {
if (portal != NULL)
- xo_errx(1, "-d and -p and mutually exclusive");
+ xo_errx(1, "-d and -p are mutually exclusive");
if (target != NULL)
- xo_errx(1, "-d and -t and mutually exclusive");
+ xo_errx(1, "-d and -t are mutually exclusive");
} else {
if (target == NULL && portal == NULL)
xo_errx(1, "must specify -a, -n or -t/-p");
@@ -874,15 +874,15 @@ main(int argc, char **argv)
if (nickname != NULL) {
if (enable != ENABLE_UNSPECIFIED)
- xo_errx(1, "-n and -e and mutually exclusive");
+ xo_errx(1, "-n and -e are mutually exclusive");
if (portal != NULL)
- xo_errx(1, "-n and -p and mutually exclusive");
+
svn commit: r303106 - head/lib/libc/sys
Author: zeising (doc,ports committer) Date: Wed Jul 20 18:16:58 2016 New Revision: 303106 URL: https://svnweb.freebsd.org/changeset/base/303106 Log: Change wording to use function rather than system call in the description as well. Reviewed by: brooks MFC after:5 days Modified: head/lib/libc/sys/pipe.2 Modified: head/lib/libc/sys/pipe.2 == --- head/lib/libc/sys/pipe.2Wed Jul 20 18:11:22 2016(r303105) +++ head/lib/libc/sys/pipe.2Wed Jul 20 18:16:58 2016(r303106) @@ -46,7 +46,7 @@ .Sh DESCRIPTION The .Fn pipe -system call +function creates a .Em pipe , which is an object allowing ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r288291 - head/etc
On 2016-06-19 16:08, Cy Schubert wrote: > In message <4e985ab9-0d98-a160-bdad-fa4924ddc...@freebsd.org>, Niclas > Zeising writes: >> >> This is wrong, and how I discovered it. ddb (/etc/rc.d/ddb) starts >> before disks, and currently refuses to start on my systems with this >> issue. This means no crash dumps, unless I remember to manually start >> it later in the boot process, so this is an issue. > > ddb isn't a daemon. It's an interface into the kernel that configures DDB > properties. It runs and completes. And, yes, it is affected by limits not > being found in the path. I think I misunderstood what you mean, I thought you meant nothing is affected by this. Apologies for that. > > My point is, since there are no daemons, as per the definition of a daemon > (processes that become daemons and run in the background) prior to the > filesystems being run, to say that there would be differing systems > behavior before and after filesystems are started is presently false > (though technically true because one day we might have daemons started > before critical filesystems are mounted). Agreed. I understand if we are too late in the release cycle for 11 to move limits to /bin, which seems like the best solutions. Are there any other reasons not to move /usr/bin/limits? I wanted to bring this to attention, since it seems noone else has noticed it, or cared enough about it. It is nothing that stops me from using FreeBSD, I will just have to remember to start ddb manually, or run the commands in case of a panic. Regards! -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r288291 - head/etc
On 2016-06-19 07:12, Cy Schubert wrote: > In message om> > , Adrian Chadd writes: >> i think that's fine for -11. I'd like to just move limits to /bin for >> 12. (I mean, it's 2016, why are you splitting / and /usr again? But..) >> >> I don't want to see differing system behaviour between limits but it's >> likely unavoidable for 11 and could do with some errata notice so >> people know what to expect. > > There aren't any daemons started prior to critical local filesystems being > mounted. I suppose one day there could be but none at this point in time. > Setting limits before filesystems are mounted is practically a NOP anyway. > (Except it could negatively affect fsck of huge UFS filesystems some day.) > > This is wrong, and how I discovered it. ddb (/etc/rc.d/ddb) starts before disks, and currently refuses to start on my systems with this issue. This means no crash dumps, unless I remember to manually start it later in the boot process, so this is an issue. Regards! Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r288291 - head/etc
On 2016-06-19 05:45, Allan Jude wrote: > On 2016-06-18 23:32, Adrian Chadd wrote: >> i think that's fine for -11. I'd like to just move limits to /bin for >> 12. (I mean, it's 2016, why are you splitting / and /usr again? But..) >> > > bsdinstall for UFS just uses one big /, and ZFS does something similar > for boot environments. Only people who have partitioned manually, or > upgraded in place from 8.x or earlier, will still have separate / and > /usr. We can't throw those people under the bus, but, it is reasonable > to consider switching things around for 12. > I have several systems with separate /usr, done either manually or upgraded in place since forever, so this is an issue, and I expect there are several others out there in the same situation. Regards! -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r288291 - head/etc
On 09/27/15 06:03, Adrian Chadd wrote:
> Author: adrian
> Date: Sun Sep 27 04:03:11 2015
> New Revision: 288291
> URL: https://svnweb.freebsd.org/changeset/base/288291
>
> Log:
> Enforce consistent limits of daemons run from rc.subr:
>
> * Allow the user to configure the login class to use in rc.conf
> by using {daemon}_login_class, which;
> * Use the daemon class by default;
> * .. and then use 'limits' to set the login class so it works both
> via init at startup (which runs this in 'daemon' class) and via
> whichever root environment (eg command line, other daemons, etc.)
>
> Reviewed by:dteske
> Differential Revision: https://reviews.freebsd.org/D3630
>
> Modified:
> head/etc/rc.subr
>
> Modified: head/etc/rc.subr
> ==
> --- head/etc/rc.subr Sun Sep 27 03:46:55 2015(r288290)
> +++ head/etc/rc.subr Sun Sep 27 04:03:11 2015(r288291)
> @@ -768,6 +768,8 @@ check_startmsgs()
> #
> #${name}_prepend n Command added before ${command}.
> #
> +#${name}_login_class n Login class to use, else "daemon".
> +#
> #${rc_arg}_cmd n If set, use this as the method when invoked;
> #Otherwise, use default command (see below)
> #
> @@ -942,7 +944,7 @@ run_rc_command()
> _nice=\$${name}_nice_user=\$${name}_user \
> _group=\$${name}_group _groups=\$${name}_groups \
> _fib=\$${name}_fib _env=\$${name}_env \
> - _prepend=\$${name}_prepend
> + _prepend=\$${name}_prepend
> _login_class=\${${name}_login_class:-daemon}
>
> if [ -n "$_user" ]; then# unset $_user if running as that user
> if [ "$_user" = "$(eval $IDCMD)" ]; then
> @@ -1050,6 +1052,9 @@ $command $rc_flags $command_args"
> fi
> fi
>
> + # Prepend default limits
> + _doit="limits -C $_login_class $_doit"
^^
> +
> # run the full command
> #
> if ! _run_rc_doit "$_doit"; then
Apologies for waking so late.
This breaks the start of scripts running before file systems are
mounted, for example /etc/rc.d/ddb, if / and /usr are on separate
partitions. The issue is that limits is /usr/bin/limits, and for
obvious reasons can't be found before /usr is mounted.
I suggest either move /usr/bin/limits to /bin/limits or avoid using it
altogether.
Do you want me to open a PR to track this issue?
Regards!
--
Niclas Zeising
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r299125 - head/sys/modules/bhnd/bhndb_pci
Author: zeising (doc,ports committer) Date: Thu May 5 17:55:10 2016 New Revision: 299125 URL: https://svnweb.freebsd.org/changeset/base/299125 Log: Fix kernel build with parallel make. Approved by: jhb Modified: head/sys/modules/bhnd/bhndb_pci/Makefile Modified: head/sys/modules/bhnd/bhndb_pci/Makefile == --- head/sys/modules/bhnd/bhndb_pci/MakefileThu May 5 17:51:14 2016 (r299124) +++ head/sys/modules/bhnd/bhndb_pci/MakefileThu May 5 17:55:10 2016 (r299125) @@ -6,6 +6,6 @@ KMOD= bhndb_pci SRCS= bhndb_pci.c bhndb_pci_hwdata.c SRCS+= bhnd_bus_if.h bhndb_bus_if.h bhndb_if.h -SRCS+= device_if.h bus_if.h +SRCS+= device_if.h bus_if.h pci_if.h .include ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r299109 - head/sys/modules/bhnd/bhndb
On 2016-05-05 17:51, Adrian Chadd wrote: > I'll check. I've done full kernel builds with this though, I wonder > why it's not showing up here. > Hi! I'm bitten by the same issue and just developed the same fix independently of Ivan Klymenko. However, at least for me, the issue only shows when doing a parallel build of the kernel, in my case make -j8. Regards! -- Niclas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r262836 - in stable: 10/share/man/man5 10/usr.sbin/jail 9/share/man/man5 9/usr.sbin/jail
Author: zeising (doc,ports committer)
Date: Thu Mar 6 10:26:25 2014
New Revision: 262836
URL: http://svnweb.freebsd.org/changeset/base/262836
Log:
MFC r261832-261834:
r261832:
Add cross references between rc.conf(5) and jail.conf(5).
r261833:
Add commas (,) to the list in the SEE ALSO section, to match most
other manuals.
r261834:
Bump .Dd forgotten in r261832.
Modified:
stable/10/share/man/man5/rc.conf.5
stable/10/usr.sbin/jail/jail.conf.5
Directory Properties:
stable/10/ (props changed)
Changes in other areas also in this revision:
Modified:
stable/9/share/man/man5/rc.conf.5
stable/9/usr.sbin/jail/jail.conf.5
Directory Properties:
stable/9/ (props changed)
stable/9/share/ (props changed)
stable/9/share/man/ (props changed)
stable/9/share/man/man5/ (props changed)
stable/9/usr.sbin/ (props changed)
stable/9/usr.sbin/jail/ (props changed)
Modified: stable/10/share/man/man5/rc.conf.5
==
--- stable/10/share/man/man5/rc.conf.5 Thu Mar 6 10:11:23 2014
(r262835)
+++ stable/10/share/man/man5/rc.conf.5 Thu Mar 6 10:26:25 2014
(r262836)
@@ -4469,6 +4469,7 @@ ruleset to load for
.Xr fstab 5 ,
.Xr ipf 5 ,
.Xr ipnat 5 ,
+.Xr jail.conf 5 ,
.Xr motd 5 ,
.Xr newsyslog.conf 5 ,
.Xr pf.conf 5 ,
Modified: stable/10/usr.sbin/jail/jail.conf.5
==
--- stable/10/usr.sbin/jail/jail.conf.5 Thu Mar 6 10:11:23 2014
(r262835)
+++ stable/10/usr.sbin/jail/jail.conf.5 Thu Mar 6 10:26:25 2014
(r262836)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 23, 2012
+.Dd February 13, 2014
.Dt JAIL.CONF 5
.Os
.Sh NAME
@@ -206,8 +206,9 @@ bar {
}
.Ed
.Sh SEE ALSO
-.Xr jail_set 2
-.Xr jail 8
+.Xr jail_set 2 ,
+.Xr rc.conf 5 ,
+.Xr jail 8 ,
.Xr jls 8
.Sh HISTORY
The
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r262836 - in stable: 10/share/man/man5 10/usr.sbin/jail 9/share/man/man5 9/usr.sbin/jail
Author: zeising (doc,ports committer)
Date: Thu Mar 6 10:26:25 2014
New Revision: 262836
URL: http://svnweb.freebsd.org/changeset/base/262836
Log:
MFC r261832-261834:
r261832:
Add cross references between rc.conf(5) and jail.conf(5).
r261833:
Add commas (,) to the list in the SEE ALSO section, to match most
other manuals.
r261834:
Bump .Dd forgotten in r261832.
Modified:
stable/9/share/man/man5/rc.conf.5
stable/9/usr.sbin/jail/jail.conf.5
Directory Properties:
stable/9/ (props changed)
stable/9/share/ (props changed)
stable/9/share/man/ (props changed)
stable/9/share/man/man5/ (props changed)
stable/9/usr.sbin/ (props changed)
stable/9/usr.sbin/jail/ (props changed)
Changes in other areas also in this revision:
Modified:
stable/10/share/man/man5/rc.conf.5
stable/10/usr.sbin/jail/jail.conf.5
Directory Properties:
stable/10/ (props changed)
Modified: stable/9/share/man/man5/rc.conf.5
==
--- stable/9/share/man/man5/rc.conf.5 Thu Mar 6 10:11:23 2014
(r262835)
+++ stable/9/share/man/man5/rc.conf.5 Thu Mar 6 10:26:25 2014
(r262836)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd October 19, 2013
+.Dd February 13, 2014
.Dt RC.CONF 5
.Os
.Sh NAME
@@ -4705,6 +4705,7 @@ The default is 30.
.Xr fstab 5 ,
.Xr ipf 5 ,
.Xr ipnat 5 ,
+.Xr jail.conf 5 ,
.Xr motd 5 ,
.Xr newsyslog.conf 5 ,
.Xr pf.conf 5 ,
Modified: stable/9/usr.sbin/jail/jail.conf.5
==
--- stable/9/usr.sbin/jail/jail.conf.5 Thu Mar 6 10:11:23 2014
(r262835)
+++ stable/9/usr.sbin/jail/jail.conf.5 Thu Mar 6 10:26:25 2014
(r262836)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 23, 2012
+.Dd February 13, 2014
.Dt JAIL.CONF 5
.Os
.Sh NAME
@@ -206,8 +206,9 @@ bar {
}
.Ed
.Sh SEE ALSO
-.Xr jail_set 2
-.Xr jail 8
+.Xr jail_set 2 ,
+.Xr rc.conf 5 ,
+.Xr jail 8 ,
.Xr jls 8
.Sh HISTORY
The
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r261834 - in head: share/man/man5 usr.sbin/jail
Author: zeising (doc,ports committer) Date: Thu Feb 13 13:11:34 2014 New Revision: 261834 URL: http://svnweb.freebsd.org/changeset/base/261834 Log: Bump .Dd forgotten in r261832. MFC after:2 weeks Modified: head/share/man/man5/rc.conf.5 head/usr.sbin/jail/jail.conf.5 Modified: head/share/man/man5/rc.conf.5 == --- head/share/man/man5/rc.conf.5 Thu Feb 13 12:53:57 2014 (r261833) +++ head/share/man/man5/rc.conf.5 Thu Feb 13 13:11:34 2014 (r261834) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd December 25, 2013 +.Dd February 13, 2014 .Dt RC.CONF 5 .Os .Sh NAME Modified: head/usr.sbin/jail/jail.conf.5 == --- head/usr.sbin/jail/jail.conf.5 Thu Feb 13 12:53:57 2014 (r261833) +++ head/usr.sbin/jail/jail.conf.5 Thu Feb 13 13:11:34 2014 (r261834) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 23, 2012 +.Dd February 13, 2014 .Dt JAIL.CONF 5 .Os .Sh NAME ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
