Re: HEADSUP: drm-current-kmod now installs sources
Is it then possible to introduce another option - install only drm-kmod sources and don't build a module, so that a user that builds a new kernel often can build when he chooses to? signature.asc Description: PGP signature
Re: HEADSUP: drm-current-kmod now installs sources
On 8/16/19 5:33 PM, Rozhuk Ivan wrote: > On Fri, 16 Aug 2019 17:23:08 -0700 > John Baldwin wrote: > >>> I use better way: >>> /etc/make.conf: >>> # Modules to build with kernel. >>> PORTS_MODULES+= graphics/drm-fbsd12.0-kmod >>> graphics/gpu-firmware-kmod >> >> This doesn't work for folks who use pre-built packages. >> > > I update mine /usr/src via rsync from other mine server, so any > changes made by port or me or ... will lost. > > Probably there is must be some solution like special folder where > ports can store some file with port name, that automaticly go to > PORTS_MODULES on build kernel. > And probably pkg can do with this something for "folks who use pre-built > packages". That is what this framework does. Ports install a Makefile to /usr/local/sys/modules//Makefile. That makefile is invoked during the 'modules' stages of buildkernel and installkernel. In the case of drm-current-kmod, the port installs sources into subdirectories of /usr/local/sys/modules/drm-current-kmod and installs a top-level Makefile in /usr/local/sys/modules/drm-current-kmod/Makefile that uses bsd.subdir.mk to recurse into those subdirectories. Currently, LOCAL_MODULES is automatically populated to a list of the directories in /usr/local/sys/modules and the debate is about when LOCAL_MODULES should be auto-populated or not. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Fri, Aug 16, 2019 at 6:37 PM John Baldwin wrote: > On 8/16/19 2:51 PM, Rodney W. Grimes wrote: > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > >>> I've lost the original thread, but would the sources in > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > And, now that sources may be installed by a port, what is the method for > _just_ updating the sources? Why do I even need to build and install the > port? Personally, I would just rather have the drm-kmod sources just > imported into base and maintained there. If I have 2 or more different > checked out base src trees, how do I get the correct drm-kmod to go with > them if there is only one /usr/local/sys/modules? Do I need multiple port > trees just to pull in out of tree module sources? > >> > >> In some ways, installing sources for DRM is a compromise for the fact > that we > >> can't have DRM in the base source anymore (for various reasons). > However, > >> virtualbox is also probably in that camp as well. > > > > I applaud this effort to provide a source compile mode for DRM, > > but I think it has come up a bit short on execution with numorious > > problems sited. > > Do you have a reported problem vs a theoretical problem? The > only reported problem I've seen is that LOCAL_MODULES="" doesn't > work. That and Cy reported a build error from a recent commit to > head due to LOCAL_MODULES working as intended. > And once it's working like it is supposed too, you can override it on a per-tree basis. But it needs to be on by default to avoid POLA. > > I too am not real happy that /usr/local/src is going to get > > automatically invoked from my some odd 10+ src trees that > > are of various WIP's. I need a way to easily disable this > > both on a global scale, and on a per src tree way. > > Modulo the LOCAL_MODULES="" not working (you have to just use > LOCAL_MODULES=) this already exists. You can set it in > /etc/src.conf, in a kernel config, or on the command line. > You can also per-tree settings on a src.conf if you want. Nanobsd overrides /etc/src.conf and others to set per-build defaults that are reproducible w/o host contamination, for example. We have half a dozen mechanisms for managing per-tree settings. > > Rather than a default to on with an opt out mechanism perhaps > > while we gain experience change this to a default to off with > > an opt in mechanism? > > It's head, not stable. We can't gain experience with something > that isn't turned Turned off by default violates POLA for people that pkg install the drm stuff. They expect it to just work, even if they rebuild the kernel. So for at least the non-cross-build cases, it should be on by default. People with special needs, like 10 trees, will have to tweak their defaults. We cannot set the defaults based on that. Most developers have one or two trees and can easily manage when they are building stuff for other systems, jail images, etc on a case by case basis. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/16/19 2:51 PM, Rodney W. Grimes wrote: >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >>> I've lost the original thread, but would the sources in >>> /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? >>> And, now that sources may be installed by a port, what is the method for >>> _just_ updating the sources? Why do I even need to build and install the >>> port? Personally, I would just rather have the drm-kmod sources just >>> imported into base and maintained there. If I have 2 or more different >>> checked out base src trees, how do I get the correct drm-kmod to go with >>> them if there is only one /usr/local/sys/modules? Do I need multiple port >>> trees just to pull in out of tree module sources? >> >> In some ways, installing sources for DRM is a compromise for the fact that we >> can't have DRM in the base source anymore (for various reasons). However, >> virtualbox is also probably in that camp as well. > > I applaud this effort to provide a source compile mode for DRM, > but I think it has come up a bit short on execution with numorious > problems sited. Do you have a reported problem vs a theoretical problem? The only reported problem I've seen is that LOCAL_MODULES="" doesn't work. That and Cy reported a build error from a recent commit to head due to LOCAL_MODULES working as intended. > I too am not real happy that /usr/local/src is going to get > automatically invoked from my some odd 10+ src trees that > are of various WIP's. I need a way to easily disable this > both on a global scale, and on a per src tree way. Modulo the LOCAL_MODULES="" not working (you have to just use LOCAL_MODULES=) this already exists. You can set it in /etc/src.conf, in a kernel config, or on the command line. > Rather than a default to on with an opt out mechanism perhaps > while we gain experience change this to a default to off with > an opt in mechanism? It's head, not stable. We can't gain experience with something that isn't turned on. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 17:23:08 -0700 John Baldwin wrote: > > I use better way: > > /etc/make.conf: > > # Modules to build with kernel. > > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod > > graphics/gpu-firmware-kmod > > This doesn't work for folks who use pre-built packages. > I update mine /usr/src via rsync from other mine server, so any changes made by port or me or ... will lost. Probably there is must be some solution like special folder where ports can store some file with port name, that automaticly go to PORTS_MODULES on build kernel. And probably pkg can do with this something for "folks who use pre-built packages". ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On August 16, 2019 4:32:18 PM PDT, "Rodney W. Grimes" wrote: >> On Fri, 16 Aug 2019 15:40:24 -0700 >> Cy Schubert wrote: >> >> > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" >> > wrote: >> > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >> > >> > I've lost the original thread, but would the sources in >> > >/usr/local/sys/modules get built regardless of what >MAKEOBJDIRPREFIX >> > >is? And, now that sources may be installed by a port, what is the >> > >method for _just_ updating the sources? Why do I even need to >build >> > >and install the port? Personally, I would just rather have the >> > >drm-kmod sources just imported into base and maintained there. If >I >> > >have 2 or more different checked out base src trees, how do I get >the >> > >correct drm-kmod to go with them if there is only one >> > >/usr/local/sys/modules? Do I need multiple port trees just to >pull >> > >in out of tree module sources? >> > >> >> > >> In some ways, installing sources for DRM is a compromise for the >> > >> fact >> > >that we >> > >> can't have DRM in the base source anymore (for various reasons). > >> > >However, >> > >> virtualbox is also probably in that camp as well. >> > > >> > >I applaud this effort to provide a source compile mode for DRM, >> > >but I think it has come up a bit short on execution with numorious >> > >problems sited. >> > > >> > >I too am not real happy that /usr/local/src is going to get >> > >automatically invoked from my some odd 10+ src trees that >> > >are of various WIP's. I need a way to easily disable this >> > >both on a global scale, and on a per src tree way. >> > > >> > >Rather than a default to on with an opt out mechanism perhaps >> > >while we gain experience change this to a default to off with >> > >an opt in mechanism? >> > > >> > >Sadly I do not have proposed solution, but something better >> > >than what is there now needs to be found. >> > > >> > >Regards, >> > >> > Could we have a .src.conf in the root of the tree to configure this >> > on a tree by tree basis? >> > >> > >> >> >> I use better way: >> /etc/make.conf: > >That file is global to all src trees, >so that does not achive the desired effect. > >> # Modules to build with kernel. >> PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod > >Can we some how trigger that from either a kernel conf file, >or at least on a per src tree basis? Ala cy's .src.conf? > >> + >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 > >I do like the patch that makes these go into the obj dir, good stuff! Presently we can use $SRCCONF. It's a PITA. .src.conf would override any preexisting variables. We could expand the concept to look in ~/.src.conf prior to $SRCTOP/.src.conf. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/16/19 3:52 PM, Rozhuk Ivan wrote: > On Fri, 16 Aug 2019 15:40:24 -0700 > I use better way: > /etc/make.conf: > # Modules to build with kernel. > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod This doesn't work for folks who use pre-built packages. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 16:32:18 -0700 (PDT) "Rodney W. Grimes" wrote: > > > >> > I've lost the original thread, but would the sources in > > > >/usr/local/sys/modules get built regardless of what > > > >MAKEOBJDIRPREFIX is? And, now that sources may be installed by > > > >a port, what is the method for _just_ updating the sources? Why > > > >do I even need to build and install the port? Personally, I > > > >would just rather have the drm-kmod sources just imported into > > > >base and maintained there. If I have 2 or more different > > > >checked out base src trees, how do I get the correct drm-kmod to > > > >go with them if there is only one /usr/local/sys/modules? Do I > > > >need multiple port trees just to pull in out of tree module > > > >sources? > > > >> > > > >> In some ways, installing sources for DRM is a compromise for > > > >> the fact > > > >that we > > > >> can't have DRM in the base source anymore (for various > > > >> reasons). > > > >However, > > > >> virtualbox is also probably in that camp as well. > > > > > > > >I applaud this effort to provide a source compile mode for DRM, > > > >but I think it has come up a bit short on execution with > > > >numorious problems sited. > > > > > > > >I too am not real happy that /usr/local/src is going to get > > > >automatically invoked from my some odd 10+ src trees that > > > >are of various WIP's. I need a way to easily disable this > > > >both on a global scale, and on a per src tree way. > > > > > > > >Rather than a default to on with an opt out mechanism perhaps > > > >while we gain experience change this to a default to off with > > > >an opt in mechanism? > > > > > > > >Sadly I do not have proposed solution, but something better > > > >than what is there now needs to be found. > > > > > > > > > > Could we have a .src.conf in the root of the tree to configure > > > this on a tree by tree basis? > > > > > > > > > > > > I use better way: > > /etc/make.conf: > > That file is global to all src trees, > so that does not achive the desired effect. You can override this using env __MAKE_CONF=PATH_TO_MAKE.CONF SRCCONF=PATH_TO_SRC.CONF > > # Modules to build with kernel. > > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod > > graphics/gpu-firmware-kmod > > Can we some how trigger that from either a kernel conf file, > or at least on a per src tree basis? Ala cy's .src.conf? I dont know, never use it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
> On Fri, 16 Aug 2019 15:40:24 -0700 > Cy Schubert wrote: > > > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" > > wrote: > > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > > >> > I've lost the original thread, but would the sources in > > >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX > > >is? And, now that sources may be installed by a port, what is the > > >method for _just_ updating the sources? Why do I even need to build > > >and install the port? Personally, I would just rather have the > > >drm-kmod sources just imported into base and maintained there. If I > > >have 2 or more different checked out base src trees, how do I get the > > >correct drm-kmod to go with them if there is only one > > >/usr/local/sys/modules? Do I need multiple port trees just to pull > > >in out of tree module sources? > > >> > > >> In some ways, installing sources for DRM is a compromise for the > > >> fact > > >that we > > >> can't have DRM in the base source anymore (for various reasons). > > >However, > > >> virtualbox is also probably in that camp as well. > > > > > >I applaud this effort to provide a source compile mode for DRM, > > >but I think it has come up a bit short on execution with numorious > > >problems sited. > > > > > >I too am not real happy that /usr/local/src is going to get > > >automatically invoked from my some odd 10+ src trees that > > >are of various WIP's. I need a way to easily disable this > > >both on a global scale, and on a per src tree way. > > > > > >Rather than a default to on with an opt out mechanism perhaps > > >while we gain experience change this to a default to off with > > >an opt in mechanism? > > > > > >Sadly I do not have proposed solution, but something better > > >than what is there now needs to be found. > > > > > >Regards, > > > > Could we have a .src.conf in the root of the tree to configure this > > on a tree by tree basis? > > > > > > > I use better way: > /etc/make.conf: That file is global to all src trees, so that does not achive the desired effect. > # Modules to build with kernel. > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod Can we some how trigger that from either a kernel conf file, or at least on a per src tree basis? Ala cy's .src.conf? > + > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 I do like the patch that makes these go into the obj dir, good stuff! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 15:40:24 -0700 Cy Schubert wrote: > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" > wrote: > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > >> > I've lost the original thread, but would the sources in > >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX > >is? And, now that sources may be installed by a port, what is the > >method for _just_ updating the sources? Why do I even need to build > >and install the port? Personally, I would just rather have the > >drm-kmod sources just imported into base and maintained there. If I > >have 2 or more different checked out base src trees, how do I get the > >correct drm-kmod to go with them if there is only one > >/usr/local/sys/modules? Do I need multiple port trees just to pull > >in out of tree module sources? > >> > >> In some ways, installing sources for DRM is a compromise for the > >> fact > >that we > >> can't have DRM in the base source anymore (for various reasons). > >However, > >> virtualbox is also probably in that camp as well. > > > >I applaud this effort to provide a source compile mode for DRM, > >but I think it has come up a bit short on execution with numorious > >problems sited. > > > >I too am not real happy that /usr/local/src is going to get > >automatically invoked from my some odd 10+ src trees that > >are of various WIP's. I need a way to easily disable this > >both on a global scale, and on a per src tree way. > > > >Rather than a default to on with an opt out mechanism perhaps > >while we gain experience change this to a default to off with > >an opt in mechanism? > > > >Sadly I do not have proposed solution, but something better > >than what is there now needs to be found. > > > >Regards, > > Could we have a .src.conf in the root of the tree to configure this > on a tree by tree basis? > > I use better way: /etc/make.conf: # Modules to build with kernel. PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" wrote: >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >> > I've lost the original thread, but would the sources in >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX >is? And, now that sources may be installed by a port, what is the >method for _just_ updating the sources? Why do I even need to build >and install the port? Personally, I would just rather have the >drm-kmod sources just imported into base and maintained there. If I >have 2 or more different checked out base src trees, how do I get the >correct drm-kmod to go with them if there is only one >/usr/local/sys/modules? Do I need multiple port trees just to pull in >out of tree module sources? >> >> In some ways, installing sources for DRM is a compromise for the fact >that we >> can't have DRM in the base source anymore (for various reasons). >However, >> virtualbox is also probably in that camp as well. > >I applaud this effort to provide a source compile mode for DRM, >but I think it has come up a bit short on execution with numorious >problems sited. > >I too am not real happy that /usr/local/src is going to get >automatically invoked from my some odd 10+ src trees that >are of various WIP's. I need a way to easily disable this >both on a global scale, and on a per src tree way. > >Rather than a default to on with an opt out mechanism perhaps >while we gain experience change this to a default to off with >an opt in mechanism? > >Sadly I do not have proposed solution, but something better >than what is there now needs to be found. > >Regards, Could we have a .src.conf in the root of the tree to configure this on a tree by tree basis? -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
> On 8/14/19 3:40 PM, Daniel Eischen wrote: > > I've lost the original thread, but would the sources in > > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > > And, now that sources may be installed by a port, what is the method for > > _just_ updating the sources? Why do I even need to build and install the > > port? Personally, I would just rather have the drm-kmod sources just > > imported into base and maintained there. If I have 2 or more different > > checked out base src trees, how do I get the correct drm-kmod to go with > > them if there is only one /usr/local/sys/modules? Do I need multiple port > > trees just to pull in out of tree module sources? > > In some ways, installing sources for DRM is a compromise for the fact that we > can't have DRM in the base source anymore (for various reasons). However, > virtualbox is also probably in that camp as well. I applaud this effort to provide a source compile mode for DRM, but I think it has come up a bit short on execution with numorious problems sited. I too am not real happy that /usr/local/src is going to get automatically invoked from my some odd 10+ src trees that are of various WIP's. I need a way to easily disable this both on a global scale, and on a per src tree way. Rather than a default to on with an opt out mechanism perhaps while we gain experience change this to a default to off with an opt in mechanism? Sadly I do not have proposed solution, but something better than what is there now needs to be found. Regards, -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 1:19 PM, Ian Lepore wrote:
> On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
>> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
>>
>>> On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
On 8/14/19 11:06 AM, Kyle Evans wrote:
> LOCAL_MODULES="" does seem like a sensible default when we're
> not
> building a native kernel.
Unfortunately kern.post.mk has no way of knowing that as
MACHINE_*
are already set to the TARGET_* values by the time this target is
invoked. Also, the 'make tinderbox' use case is a legit use case
that some folks want (for CI, etc.)
>>>
>>> BUILDHOST_ARCH!= uname -p
>>> .if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
>>>
>>> Unfortunately, I don't think it's as easy to compare the buildhost
>>> running version with the version of source being built, unless the
>>> build is started from the top level so that Makefile.inc1 sets the
>>> variables.
>>>
>>
>> We already know MACHINE_ARCH != TARGET_ARCH in Makefile.inc1 and
>> already do
>> different things based on it. But to be honest, I'd think there'd be
>> times
>> I'd absolutely want to build them all, and other times I wouldn't
>> which
>> strongly suggests some kind of knob specific for cross building the
>> port/pkg-based kernel modules. We could then pass that knob into the
>> kernel
>> builds which would then not try to guess whether or not to build
>> LOCAL_MODULES...
>>
>>
>
> This is just about AUTOMATICALLY deciding to build something, based on
> the presence of source code in an arbitrary fixed location outside of
> the source tree on the build machine. Anything set by the user should
> be honored without question, including LOCAL_MODULES.
>
> My point is only that the build machinery should not be deciding to
> build something the user didn't specify based on the existence of out-
> of-tree files on the build machine (I'd like to put the period right
> here in this sentence), unless there's a very high likelyhood that the
> build being done is for the build machine.
>
> Things like CI that want to include more than in-tree sources as part
> of the build should be handling that by setting appropriate knobs as
> part of invoking the build.
I talked with Warner some offline and I think having some knob that
controls whether or not LOCAL_MODULES auto-populates and having make
buildkernel default it to on/off for native/cross builds (but it can
always be forcefully set on the command line) is fine with me.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 3:40 PM, Daniel Eischen wrote: > I've lost the original thread, but would the sources in > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > And, now that sources may be installed by a port, what is the method for > _just_ updating the sources? Why do I even need to build and install the > port? Personally, I would just rather have the drm-kmod sources just > imported into base and maintained there. If I have 2 or more different > checked out base src trees, how do I get the correct drm-kmod to go with them > if there is only one /usr/local/sys/modules? Do I need multiple port trees > just to pull in out of tree module sources? In some ways, installing sources for DRM is a compromise for the fact that we can't have DRM in the base source anymore (for various reasons). However, virtualbox is also probably in that camp as well. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
> On Aug 14, 2019, at 6:59 PM, Steve Kargl > wrote: > >> On Wed, Aug 14, 2019 at 06:40:28PM -0400, Daniel Eischen wrote: >> I've lost the original thread, but would the sources in >> /usr/local/sys/modules get built regardless of what >> MAKEOBJDIRPREFIX is? And, now that sources may be installed >> by a port, what is the method for _just_ updating the sources? >> Why do I even need to build and install the port? Personally, >> I would just rather have the drm-kmod sources just imported >> into base and maintained there. > > You're joking right? Not fully, no. > You remember drm and drm2 (aka drm-legacy-kmod). Yes, I remember them. -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, Aug 14, 2019 at 06:40:28PM -0400, Daniel Eischen wrote: > I've lost the original thread, but would the sources in > /usr/local/sys/modules get built regardless of what > MAKEOBJDIRPREFIX is? And, now that sources may be installed > by a port, what is the method for _just_ updating the sources? > Why do I even need to build and install the port? Personally, > I would just rather have the drm-kmod sources just imported > into base and maintained there. You're joking right? You remember drm and drm2 (aka drm-legacy-kmod). It was working just fine (for some) before its removal. My last panics were caused from forgetting to rebuild drm-legacy-kmod after installing a new kernel/world. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
I've lost the original thread, but would the sources in /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? And, now that sources may be installed by a port, what is the method for _just_ updating the sources? Why do I even need to build and install the port? Personally, I would just rather have the drm-kmod sources just imported into base and maintained there. If I have 2 or more different checked out base src trees, how do I get the correct drm-kmod to go with them if there is only one /usr/local/sys/modules? Do I need multiple port trees just to pull in out of tree module sources? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On August 14, 2019 11:04:20 AM PDT, Ian Lepore wrote:
>On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
>> On 2019-08-14 19:23, Emmanuel Vadot wrote:
>> > On Wed, 14 Aug 2019 10:13:48 -0700
>> > John Baldwin wrote:
>> >
>> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
>> > > > This all sounds vaguely wrong, backwards, to me. A developer
>> > > > who is
>> > > > using a given module on their build system might want that
>> > > > module to be
>> > > > rebuilt automatically, but only if the build parameters match
>> > > > those of
>> > > > the running build host system.
>> > > >
>> > > > If my build host is running freebsd 12 amd64 and I'm doing a
>> > > > build for
>> > > > freebsd 13 armv7, I have no interest in automatic rebuilds of
>> > > > an amd64
>> > > > driver module for a different OS arch and version just because
>> > > > that
>> > > > module happens to be installed on the system I use to do
>> > > > crossbuilds.
>> > > >
>> > > > My objections are theoretical... this automation just seems
>> > > > improperly
>> > > > designed to me. But it won't actually affect me in any way,
>> > > > because I
>> > > > don't build video driver modules from ports, and I don't run
>> > > > freebsd
>> > > > current on my build host machine. Probably the number of
>> > > > people doing
>> > > > crossbuilding is small enough that nobody else is going to
>> > > > object to
>> > > > this "the whole world is amd64" automation.
>> > >
>> > > You assume DRM is amd64-only when it is definitely not. It also
>> > > has
>> > > suitable guards in its Makefile to only build the relevant kernel
>> > > modules on supported architectures.
>> >
>> > I clearly don't want to spend time to build the drm and radeon
>> > modules
>> > when I'm hacking on arm64.
>> > Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
>> > subdirectory ? So when you install drm-kmod-* it will only install
>> > the
>> > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or
>> > whatever
>> > the correct dir is).
>> >
>>
>> I'm not sure what you're trying to accomplish. I might be
>> misunderstanding completely, but, at least the drm ports have
>> safeguards
>> in their makefiles so they'll only be built for those arches where
>> there
>> is support, and only the modules needed, as an example, i915kms.ko
>> will
>> only be built on amd64 and i386, if that's what you're worried about.
>> Regards
>
>I can't understand what you guys are not-understanding. New machinery
>has been added that says "if some module source code exists in this
>absolute fixed location on the build machine, then whenever you do any
>kernel build for any OS version or any arch, rebuild that module source
>code so that the the build machine's video drivers stay in sync with
>the build machine's kernel."
>
>Do you not see that for some of us, only a tiny fraction of the builds
>done (maybe none of them at all) involve the kernel for the build host
>machine or the video drivers for the build host machine? And yet, for
>us, every build we do will now inapppropriately rebuild this video
>driver module which has nothing to do with the machine the build is
>targeting.
>
>And it's not just about crossbuilds, because it's about versions too.
>Even when a developer is running 13-current and wants their video
>driver rebuilt and installed automatically along with the kernel,
>they're certainly going to want that to happen only when they're
>building 13-current. If they're doing a test-build for 12-stable they
>certainly aren't going to want to build and install that video driver.
>
>-- Ian
>
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"
How about build/install when arch is the same as local machine arch?
--
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
>
> > On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > > LOCAL_MODULES="" does seem like a sensible default when we're
> > > > not
> > > > building a native kernel.
> > >
> > > Unfortunately kern.post.mk has no way of knowing that as
> > > MACHINE_*
> > > are already set to the TARGET_* values by the time this target is
> > > invoked. Also, the 'make tinderbox' use case is a legit use case
> > > that some folks want (for CI, etc.)
> > >
> >
> > BUILDHOST_ARCH!= uname -p
> > .if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
> >
> > Unfortunately, I don't think it's as easy to compare the buildhost
> > running version with the version of source being built, unless the
> > build is started from the top level so that Makefile.inc1 sets the
> > variables.
> >
>
> We already know MACHINE_ARCH != TARGET_ARCH in Makefile.inc1 and
> already do
> different things based on it. But to be honest, I'd think there'd be
> times
> I'd absolutely want to build them all, and other times I wouldn't
> which
> strongly suggests some kind of knob specific for cross building the
> port/pkg-based kernel modules. We could then pass that knob into the
> kernel
> builds which would then not try to guess whether or not to build
> LOCAL_MODULES...
>
>
This is just about AUTOMATICALLY deciding to build something, based on
the presence of source code in an arbitrary fixed location outside of
the source tree on the build machine. Anything set by the user should
be honored without question, including LOCAL_MODULES.
My point is only that the build machinery should not be deciding to
build something the user didn't specify based on the existence of out-
of-tree files on the build machine (I'd like to put the period right
here in this sentence), unless there's a very high likelyhood that the
build being done is for the build machine.
Things like CI that want to include more than in-tree sources as part
of the build should be handling that by setting appropriate knobs as
part of invoking the build.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
> On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > LOCAL_MODULES="" does seem like a sensible default when we're not
> > > building a native kernel.
> >
> > Unfortunately kern.post.mk has no way of knowing that as MACHINE_*
> > are already set to the TARGET_* values by the time this target is
> > invoked. Also, the 'make tinderbox' use case is a legit use case
> > that some folks want (for CI, etc.)
> >
>
> BUILDHOST_ARCH!= uname -p
> .if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
>
> Unfortunately, I don't think it's as easy to compare the buildhost
> running version with the version of source being built, unless the
> build is started from the top level so that Makefile.inc1 sets the
> variables.
>
We already know MACHINE_ARCH != TARGET_ARCH in Makefile.inc1 and already do
different things based on it. But to be honest, I'd think there'd be times
I'd absolutely want to build them all, and other times I wouldn't which
strongly suggests some kind of knob specific for cross building the
port/pkg-based kernel modules. We could then pass that knob into the kernel
builds which would then not try to guess whether or not to build
LOCAL_MODULES...
Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> On 8/14/19 11:06 AM, Kyle Evans wrote:
> > LOCAL_MODULES="" does seem like a sensible default when we're not
> > building a native kernel.
>
> Unfortunately kern.post.mk has no way of knowing that as MACHINE_*
> are already set to the TARGET_* values by the time this target is
> invoked. Also, the 'make tinderbox' use case is a legit use case
> that some folks want (for CI, etc.)
>
BUILDHOST_ARCH!= uname -p
.if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
Unfortunately, I don't think it's as easy to compare the buildhost
running version with the version of source being built, unless the
build is started from the top level so that Makefile.inc1 sets the
variables.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 11:04 AM, Ian Lepore wrote: > On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote: > I can't understand what you guys are not-understanding. New machinery > has been added that says "if some module source code exists in this > absolute fixed location on the build machine, then whenever you do any > kernel build for any OS version or any arch, rebuild that module source > code so that the the build machine's video drivers stay in sync with > the build machine's kernel." To back up a bit, one thing I didn't say (and should have in the first email) is that this change is only in HEAD for now specifically to gain some experience for what the default policy should be. However, I'd at least like to _try_ it for a bit so we can get some data to determine that instead of only going on theory. And it's not just DRM though that is the only test case for now. Did you know that we shipped 11.3 release such that if you did 'pkg install virtualbox' and loaded the kernel module your machine panicked because the pre-built module was built for 11.2 and didn't work on 11.3? Certain kmods aren't suitable for binary-only distribution and need other options, and we need to figure out how to handle other options. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 11:06 AM, Kyle Evans wrote: > LOCAL_MODULES="" does seem like a sensible default when we're not > building a native kernel. Unfortunately kern.post.mk has no way of knowing that as MACHINE_* are already set to the TARGET_* values by the time this target is invoked. Also, the 'make tinderbox' use case is a legit use case that some folks want (for CI, etc.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 2019-08-14 11:04, Ian Lepore wrote: I can't understand what you guys are not-understanding. New machinery has been added that says "if some module source code exists in this absolute fixed location on the build machine, then whenever you do any kernel build for any OS version or any arch, rebuild that module source code so that the the build machine's video drivers stay in sync with the build machine's kernel." Do you not see that for some of us, only a tiny fraction of the builds done (maybe none of them at all) involve the kernel for the build host machine or the video drivers for the build host machine? And yet, for us, every build we do will now inapppropriately rebuild this video driver module which has nothing to do with the machine the build is targeting. Most of the kernel builds I do _are_ for the host machine, yet I don't want the new behavior either. Why? The build logic of the source tree should be self-contained and easily understandable. Looking all over the system and trying to automate fixes is what ports are for. Automated hacks for this sort of situation, that do the right thing 90% of the time but inevitably break down on other perfectly reasonable use cases, are one of the factors that pushed me away from the operating systems I used before FreeBSD. Managing the host's kernel and needed modules from source from a single tool certainly is useful, but I think it should be just that: a tool, used when appropriate, not a default behavior. This tool can be recommended to kmod port users/developers for local system work while everyone else may continue using source tree as expected. On 2019-08-14 11:06, Kyle Evans wrote: LOCAL_MODULES="" does seem like a sensible default when we're not building a native kernel. More generally there should be a switch for defeating any and all attempts to use anything "local" (non /usr/src). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 11:04:03 -0700 John Baldwin wrote: > On 8/14/19 10:23 AM, Emmanuel Vadot wrote: > > On Wed, 14 Aug 2019 10:13:48 -0700 > > John Baldwin wrote: > > > >> On 8/14/19 9:22 AM, Ian Lepore wrote: > >>> This all sounds vaguely wrong, backwards, to me. A developer who is > >>> using a given module on their build system might want that module to be > >>> rebuilt automatically, but only if the build parameters match those of > >>> the running build host system. > >>> > >>> If my build host is running freebsd 12 amd64 and I'm doing a build for > >>> freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 > >>> driver module for a different OS arch and version just because that > >>> module happens to be installed on the system I use to do crossbuilds. > >>> > >>> My objections are theoretical... this automation just seems improperly > >>> designed to me. But it won't actually affect me in any way, because I > >>> don't build video driver modules from ports, and I don't run freebsd > >>> current on my build host machine. Probably the number of people doing > >>> crossbuilding is small enough that nobody else is going to object to > >>> this "the whole world is amd64" automation. > >> > >> You assume DRM is amd64-only when it is definitely not. It also has > >> suitable guards in its Makefile to only build the relevant kernel > >> modules on supported architectures. > > > > I clearly don't want to spend time to build the drm and radeon modules > > when I'm hacking on arm64. > > Didn't you when DRM2 was in base? No, DRM2 was never connected for aarch64. > Do you use MODULES_OVERRIDE now to > limit the number of modules you are building? Most of the time yes, but if I don't set it, it shouldn't mean that I want to compile an out of tree module that I installed for another arch. > Setting LOCAL_MODULES would > be no different to setting MODULES_OVERRIDE. If you aren't setting > MODULES_OVERRIDE, then I don't buy your argument as the default set of > modules dwarfs DRM several times over. If nothing changes I will endup setting LOCAL_MODULES="" everytime but again this is not the problem, see above. > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, Aug 14, 2019 at 1:04 PM Ian Lepore wrote:
>
> On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> > On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > > On Wed, 14 Aug 2019 10:13:48 -0700
> > > John Baldwin wrote:
> > >
> > > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > > This all sounds vaguely wrong, backwards, to me. A developer
> > > > > who is
> > > > > using a given module on their build system might want that
> > > > > module to be
> > > > > rebuilt automatically, but only if the build parameters match
> > > > > those of
> > > > > the running build host system.
> > > > >
> > > > > If my build host is running freebsd 12 amd64 and I'm doing a
> > > > > build for
> > > > > freebsd 13 armv7, I have no interest in automatic rebuilds of
> > > > > an amd64
> > > > > driver module for a different OS arch and version just because
> > > > > that
> > > > > module happens to be installed on the system I use to do
> > > > > crossbuilds.
> > > > >
> > > > > My objections are theoretical... this automation just seems
> > > > > improperly
> > > > > designed to me. But it won't actually affect me in any way,
> > > > > because I
> > > > > don't build video driver modules from ports, and I don't run
> > > > > freebsd
> > > > > current on my build host machine. Probably the number of
> > > > > people doing
> > > > > crossbuilding is small enough that nobody else is going to
> > > > > object to
> > > > > this "the whole world is amd64" automation.
> > > >
> > > > You assume DRM is amd64-only when it is definitely not. It also
> > > > has
> > > > suitable guards in its Makefile to only build the relevant kernel
> > > > modules on supported architectures.
> > >
> > > I clearly don't want to spend time to build the drm and radeon
> > > modules
> > > when I'm hacking on arm64.
> > > Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
> > > subdirectory ? So when you install drm-kmod-* it will only install
> > > the
> > > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or
> > > whatever
> > > the correct dir is).
> > >
> >
> > I'm not sure what you're trying to accomplish. I might be
> > misunderstanding completely, but, at least the drm ports have
> > safeguards
> > in their makefiles so they'll only be built for those arches where
> > there
> > is support, and only the modules needed, as an example, i915kms.ko
> > will
> > only be built on amd64 and i386, if that's what you're worried about.
> > Regards
>
> I can't understand what you guys are not-understanding. New machinery
> has been added that says "if some module source code exists in this
> absolute fixed location on the build machine, then whenever you do any
> kernel build for any OS version or any arch, rebuild that module source
> code so that the the build machine's video drivers stay in sync with
> the build machine's kernel."
LOCAL_MODULES="" does seem like a sensible default when we're not
building a native kernel.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > This all sounds vaguely wrong, backwards, to me. A developer
> > > > who is
> > > > using a given module on their build system might want that
> > > > module to be
> > > > rebuilt automatically, but only if the build parameters match
> > > > those of
> > > > the running build host system.
> > > >
> > > > If my build host is running freebsd 12 amd64 and I'm doing a
> > > > build for
> > > > freebsd 13 armv7, I have no interest in automatic rebuilds of
> > > > an amd64
> > > > driver module for a different OS arch and version just because
> > > > that
> > > > module happens to be installed on the system I use to do
> > > > crossbuilds.
> > > >
> > > > My objections are theoretical... this automation just seems
> > > > improperly
> > > > designed to me. But it won't actually affect me in any way,
> > > > because I
> > > > don't build video driver modules from ports, and I don't run
> > > > freebsd
> > > > current on my build host machine. Probably the number of
> > > > people doing
> > > > crossbuilding is small enough that nobody else is going to
> > > > object to
> > > > this "the whole world is amd64" automation.
> > >
> > > You assume DRM is amd64-only when it is definitely not. It also
> > > has
> > > suitable guards in its Makefile to only build the relevant kernel
> > > modules on supported architectures.
> >
> > I clearly don't want to spend time to build the drm and radeon
> > modules
> > when I'm hacking on arm64.
> > Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
> > subdirectory ? So when you install drm-kmod-* it will only install
> > the
> > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or
> > whatever
> > the correct dir is).
> >
>
> I'm not sure what you're trying to accomplish. I might be
> misunderstanding completely, but, at least the drm ports have
> safeguards
> in their makefiles so they'll only be built for those arches where
> there
> is support, and only the modules needed, as an example, i915kms.ko
> will
> only be built on amd64 and i386, if that's what you're worried about.
> Regards
I can't understand what you guys are not-understanding. New machinery
has been added that says "if some module source code exists in this
absolute fixed location on the build machine, then whenever you do any
kernel build for any OS version or any arch, rebuild that module source
code so that the the build machine's video drivers stay in sync with
the build machine's kernel."
Do you not see that for some of us, only a tiny fraction of the builds
done (maybe none of them at all) involve the kernel for the build host
machine or the video drivers for the build host machine? And yet, for
us, every build we do will now inapppropriately rebuild this video
driver module which has nothing to do with the machine the build is
targeting.
And it's not just about crossbuilds, because it's about versions too.
Even when a developer is running 13-current and wants their video
driver rebuilt and installed automatically along with the kernel,
they're certainly going to want that to happen only when they're
building 13-current. If they're doing a test-build for 12-stable they
certainly aren't going to want to build and install that video driver.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 10:23 AM, Emmanuel Vadot wrote: > On Wed, 14 Aug 2019 10:13:48 -0700 > John Baldwin wrote: > >> On 8/14/19 9:22 AM, Ian Lepore wrote: >>> This all sounds vaguely wrong, backwards, to me. A developer who is >>> using a given module on their build system might want that module to be >>> rebuilt automatically, but only if the build parameters match those of >>> the running build host system. >>> >>> If my build host is running freebsd 12 amd64 and I'm doing a build for >>> freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 >>> driver module for a different OS arch and version just because that >>> module happens to be installed on the system I use to do crossbuilds. >>> >>> My objections are theoretical... this automation just seems improperly >>> designed to me. But it won't actually affect me in any way, because I >>> don't build video driver modules from ports, and I don't run freebsd >>> current on my build host machine. Probably the number of people doing >>> crossbuilding is small enough that nobody else is going to object to >>> this "the whole world is amd64" automation. >> >> You assume DRM is amd64-only when it is definitely not. It also has >> suitable guards in its Makefile to only build the relevant kernel >> modules on supported architectures. > > I clearly don't want to spend time to build the drm and radeon modules > when I'm hacking on arm64. Didn't you when DRM2 was in base? Do you use MODULES_OVERRIDE now to limit the number of modules you are building? Setting LOCAL_MODULES would be no different to setting MODULES_OVERRIDE. If you aren't setting MODULES_OVERRIDE, then I don't buy your argument as the default set of modules dwarfs DRM several times over. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 19:55:02 +0200
Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> >> On 8/14/19 9:22 AM, Ian Lepore wrote:
> >>> This all sounds vaguely wrong, backwards, to me. A developer who is
> >>> using a given module on their build system might want that module to be
> >>> rebuilt automatically, but only if the build parameters match those of
> >>> the running build host system.
> >>>
> >>> If my build host is running freebsd 12 amd64 and I'm doing a build for
> >>> freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
> >>> driver module for a different OS arch and version just because that
> >>> module happens to be installed on the system I use to do crossbuilds.
> >>>
> >>> My objections are theoretical... this automation just seems improperly
> >>> designed to me. But it won't actually affect me in any way, because I
> >>> don't build video driver modules from ports, and I don't run freebsd
> >>> current on my build host machine. Probably the number of people doing
> >>> crossbuilding is small enough that nobody else is going to object to
> >>> this "the whole world is amd64" automation.
> >>
> >> You assume DRM is amd64-only when it is definitely not. It also has
> >> suitable guards in its Makefile to only build the relevant kernel
> >> modules on supported architectures.
> >
> > I clearly don't want to spend time to build the drm and radeon modules
> > when I'm hacking on arm64.
> > Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
> > subdirectory ? So when you install drm-kmod-* it will only install the
> > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
> > the correct dir is).
> >
>
> I'm not sure what you're trying to accomplish. I might be
> misunderstanding completely, but, at least the drm ports have safeguards
> in their makefiles so they'll only be built for those arches where there
> is support, and only the modules needed, as an example, i915kms.ko will
> only be built on amd64 and i386, if that's what you're worried about.
> Regards
> --
> Niclas Zeising
Greg.V is making radeon/amdgpu building on aarch64. So when the
ports will have support for it if I don't set some env variable I will
spend some time building drm + amdgpu when I buildkernel on my amd64
13-CURRENT machine for aarch64. This is not something that I want to do.
So what I said was that if I install drm-kmod-* on an amd64 machine
this should only trigger a build of the module when I'm building an
amd64 kernel, hence my proposal to only install sources in a ${TARGET}.$
{TARGET_ARCH} subdir.
--
Emmanuel Vadot
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 2019-08-14 19:23, Emmanuel Vadot wrote:
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin wrote:
On 8/14/19 9:22 AM, Ian Lepore wrote:
This all sounds vaguely wrong, backwards, to me. A developer who is
using a given module on their build system might want that module to be
rebuilt automatically, but only if the build parameters match those of
the running build host system.
If my build host is running freebsd 12 amd64 and I'm doing a build for
freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
driver module for a different OS arch and version just because that
module happens to be installed on the system I use to do crossbuilds.
My objections are theoretical... this automation just seems improperly
designed to me. But it won't actually affect me in any way, because I
don't build video driver modules from ports, and I don't run freebsd
current on my build host machine. Probably the number of people doing
crossbuilding is small enough that nobody else is going to object to
this "the whole world is amd64" automation.
You assume DRM is amd64-only when it is definitely not. It also has
suitable guards in its Makefile to only build the relevant kernel
modules on supported architectures.
I clearly don't want to spend time to build the drm and radeon modules
when I'm hacking on arm64.
Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
subdirectory ? So when you install drm-kmod-* it will only install the
source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
the correct dir is).
I'm not sure what you're trying to accomplish. I might be
misunderstanding completely, but, at least the drm ports have safeguards
in their makefiles so they'll only be built for those arches where there
is support, and only the modules needed, as an example, i915kms.ko will
only be built on amd64 and i386, if that's what you're worried about.
Regards
--
Niclas Zeising
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin wrote:
> On 8/14/19 9:22 AM, Ian Lepore wrote:
> > This all sounds vaguely wrong, backwards, to me. A developer who is
> > using a given module on their build system might want that module to be
> > rebuilt automatically, but only if the build parameters match those of
> > the running build host system.
> >
> > If my build host is running freebsd 12 amd64 and I'm doing a build for
> > freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
> > driver module for a different OS arch and version just because that
> > module happens to be installed on the system I use to do crossbuilds.
> >
> > My objections are theoretical... this automation just seems improperly
> > designed to me. But it won't actually affect me in any way, because I
> > don't build video driver modules from ports, and I don't run freebsd
> > current on my build host machine. Probably the number of people doing
> > crossbuilding is small enough that nobody else is going to object to
> > this "the whole world is amd64" automation.
>
> You assume DRM is amd64-only when it is definitely not. It also has
> suitable guards in its Makefile to only build the relevant kernel
> modules on supported architectures.
I clearly don't want to spend time to build the drm and radeon modules
when I'm hacking on arm64.
Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
subdirectory ? So when you install drm-kmod-* it will only install the
source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
the correct dir is).
--
Emmanuel Vadot
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
CC @current, as I had originally intended. On 2019-08-14 09:08, John Baldwin wrote: 1) You can set LOCALBASE to a different path either in a kernel config (via makeoptions) or when invoking buildkernel. For example, I mount my rpi's sdcard at /mnt on my amd64 laptop and then cross-build into it, so I could set LOCALBASE to /mnt/usr/local when building the rpi's kernel to honor any kmod packages installed on the rpi. Normally LOCALBASE is interpreted by ports as the default for PREFIX, meaning it should be a path _within_ the target system, not the path to where it is mounted. There is DESTDIR for that. Now for kernel build this is not a problem for the reason that LOCALBASE is being used just to find sources, not to build ports. However, given how that variable is normally used, it seems like a problem waiting to happen. It would be better to use a variable specific to the purpose at hand. How about when I'm doing a build of 11-stable for testing, but what's in my /usr/local is sources for a 13-current driver? Given that the kmod's are supposed to be portable across branches, the build really shouldn't be breaking. But the same ability is still there to as above to disable builds either in general or for specific kernel configs or buildkernel invocations. The concern appears to be that there is no longer a clear way to separate what base source tree does from what is in the local system's configuration. Is there any one single knob to tell /usr/src not to use any configuration from /usr/local? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 9:22 AM, Ian Lepore wrote: > This all sounds vaguely wrong, backwards, to me. A developer who is > using a given module on their build system might want that module to be > rebuilt automatically, but only if the build parameters match those of > the running build host system. > > If my build host is running freebsd 12 amd64 and I'm doing a build for > freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 > driver module for a different OS arch and version just because that > module happens to be installed on the system I use to do crossbuilds. > > My objections are theoretical... this automation just seems improperly > designed to me. But it won't actually affect me in any way, because I > don't build video driver modules from ports, and I don't run freebsd > current on my build host machine. Probably the number of people doing > crossbuilding is small enough that nobody else is going to object to > this "the whole world is amd64" automation. You assume DRM is amd64-only when it is definitely not. It also has suitable guards in its Makefile to only build the relevant kernel modules on supported architectures. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote: > On 8/13/19 3:17 PM, Ian Lepore wrote: > > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: > > > For developers this means even if you are doing testing on a box > > > that doesn't use DRM, you can install the package so that kernel > > > builds will try to compile it and hopefully spot KPI/KBI changes > > > before they land in the tree so that the port/package can be > > > patched in tandem with committing changes to HEAD. Note that > > > even > > > builds of work trees in git checkouts, etc. will find the DRM > > > modules and try to build them if the package is installed. > > > > That last sentence sounds ominous. Are you saying that when I'm on > > my > > amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6 > > it's going to find /usr/local/sys/modules/drm-current-kmod and try > > to > > crossbuild it for armv6? > > Yes, meaning that you _can_ cross-build a DRM kernel module. This > also means > that if you are trying out a KPI change and have the package > installed, make > tinderbox will now catch a change that breaks the DRM drivers on only > a subset > of platforms (e.g. a powerpc or arm-only breakage that currently goes > unnoticed when a developer is only doing build testing from an amd64 > host). > > There are several ways you can disable this either globally or in > more > fine-grained ways: > > 1) You can set LOCALBASE to a different path either in a kernel > config >(via makeoptions) or when invoking buildkernel. > >For example, I mount my rpi's sdcard at /mnt on my amd64 laptop > and >then cross-build into it, so I could set LOCALBASE to > /mnt/usr/local when >building the rpi's kernel to honor any kmod packages installed on > the rpi. > > 2) You can set LOCAL_MODULES (makeoptions, command line) to a list of > modules >to build (empty disables building any of them). > > 3) You could set LOCAL_MODULES in /etc/src.conf to affect all kernel > builds. >(You probably don't want to set LOCALBASE there as it probably > affects >other things.) > > 4) You can build the port with the SOURCES option disabled if you > want to >never build modules for a specific port. > > > How about when I'm doing a build of 11-stable for testing, but > > what's > > in my /usr/local is sources for a 13-current driver? > > Given that the kmod's are supposed to be portable across branches, > the build really shouldn't be breaking. But the same ability is > still > there to as above to disable builds either in general or for > specific kernel configs or buildkernel invocations. > This all sounds vaguely wrong, backwards, to me. A developer who is using a given module on their build system might want that module to be rebuilt automatically, but only if the build parameters match those of the running build host system. If my build host is running freebsd 12 amd64 and I'm doing a build for freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 driver module for a different OS arch and version just because that module happens to be installed on the system I use to do crossbuilds. My objections are theoretical... this automation just seems improperly designed to me. But it won't actually affect me in any way, because I don't build video driver modules from ports, and I don't run freebsd current on my build host machine. Probably the number of people doing crossbuilding is small enough that nobody else is going to object to this "the whole world is amd64" automation. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 8/13/19 3:17 PM, Ian Lepore wrote: > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: >> For developers this means even if you are doing testing on a box >> that doesn't use DRM, you can install the package so that kernel >> builds will try to compile it and hopefully spot KPI/KBI changes >> before they land in the tree so that the port/package can be >> patched in tandem with committing changes to HEAD. Note that even >> builds of work trees in git checkouts, etc. will find the DRM >> modules and try to build them if the package is installed. > > That last sentence sounds ominous. Are you saying that when I'm on my > amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6 > it's going to find /usr/local/sys/modules/drm-current-kmod and try to > crossbuild it for armv6? Yes, meaning that you _can_ cross-build a DRM kernel module. This also means that if you are trying out a KPI change and have the package installed, make tinderbox will now catch a change that breaks the DRM drivers on only a subset of platforms (e.g. a powerpc or arm-only breakage that currently goes unnoticed when a developer is only doing build testing from an amd64 host). There are several ways you can disable this either globally or in more fine-grained ways: 1) You can set LOCALBASE to a different path either in a kernel config (via makeoptions) or when invoking buildkernel. For example, I mount my rpi's sdcard at /mnt on my amd64 laptop and then cross-build into it, so I could set LOCALBASE to /mnt/usr/local when building the rpi's kernel to honor any kmod packages installed on the rpi. 2) You can set LOCAL_MODULES (makeoptions, command line) to a list of modules to build (empty disables building any of them). 3) You could set LOCAL_MODULES in /etc/src.conf to affect all kernel builds. (You probably don't want to set LOCALBASE there as it probably affects other things.) 4) You can build the port with the SOURCES option disabled if you want to never build modules for a specific port. > How about when I'm doing a build of 11-stable for testing, but what's > in my /usr/local is sources for a 13-current driver? Given that the kmod's are supposed to be portable across branches, the build really shouldn't be breaking. But the same ability is still there to as above to disable builds either in general or for specific kernel configs or buildkernel invocations. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On 2019-08-14 00:35, Conrad Meyer wrote: This is super cool, thank you! Is it feasible to integrate other out-of-tree kmods in a similar way, e.g., nvidia-driver? It should be possible to expand this to work with other ports that install kmods. I think the plan is to have drm-current-kmod work like this for a while, to shake out any bugs or other unexpected issues, and then look into converting more kmod ports. Regards -- Niclas Zeising ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
This is super cool, thank you! Is it feasible to integrate other out-of-tree kmods in a similar way, e.g., nvidia-driver? On Tue, Aug 13, 2019 at 2:58 PM John Baldwin wrote: > > With help from zeising@ in particular, I've just committed a change > to the drm-current-kmod port that makes it install sources into > /usr/local/sys/modules by default. This will result in some behavior > changes on HEAD (and only head for now): > > 1) When you build a kernel after installing the updated package, >your buildkernel will now build DRM modules using the sources >from the package. For developers at least I suspect this to be >a win as if you have made changes to the kernel KBI you will >always end up with matching modules installed into /boot/kernel >alongside your kernel. > > 2) In order to use these modules, you need to update the 'kld_list' >lines in your rc.conf to just list the modules without a >path, e.g. "kld_list=i915kms" just as you would for other >modules. This will prefer the module built with your kernel if >one exists and fall back to the module in /boot/modules >otherwise. > > If a change in current breaks the build of DRM modules, you have a > couple of options: > > 1) Pass 'LOCAL_MODULES=' (empty string) on the command line of >'make buildkernel' to disable building the DRM modules. > > 2) Hack on the sources in /usr/local/sys/modules/drm-current-kmod >to fix the compile breakage, perhaps using a patch from the >mailing lists if one exists. > > 3) Wait for a new package/port version and update to that before >doing a buildkernel. > > For developers this means even if you are doing testing on a box > that doesn't use DRM, you can install the package so that kernel > builds will try to compile it and hopefully spot KPI/KBI changes > before they land in the tree so that the port/package can be > patched in tandem with committing changes to HEAD. Note that even > builds of work trees in git checkouts, etc. will find the DRM > modules and try to build them if the package is installed. > > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: > For developers this means even if you are doing testing on a box > that doesn't use DRM, you can install the package so that kernel > builds will try to compile it and hopefully spot KPI/KBI changes > before they land in the tree so that the port/package can be > patched in tandem with committing changes to HEAD. Note that even > builds of work trees in git checkouts, etc. will find the DRM > modules and try to build them if the package is installed. That last sentence sounds ominous. Are you saying that when I'm on my amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6 it's going to find /usr/local/sys/modules/drm-current-kmod and try to crossbuild it for armv6? How about when I'm doing a build of 11-stable for testing, but what's in my /usr/local is sources for a 13-current driver? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
