HEADSUP: drm-current-kmod now installs sources

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HEADSUP: drm-current-kmod now installs sources

John Baldwin
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Ian Lepore-3
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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Conrad Meyer-2
In reply to this post by John Baldwin
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 <[hidden email]> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Niclas Zeising-6
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Ian Lepore-3
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Ian Lepore-3
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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Theron Tarigo
In reply to this post by John Baldwin
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?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Tamas Szakaly
In reply to this post by John Baldwin
On Tue, Aug 13, 2019 at 02:58:23PM -0700, 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

Hi all,

Am I correctly assuming that the only advantage of this approach over having
"PORTS_MODULES+= graphics/drm-current-kmod" in /etc/src.conf is that you don't
have to have the ports tree?

And if I'm seeing things correctly, not building from the ports tree have a
disatvantage: If I want to update both my kernel and the module, I have to
install the updated module to get the latest sources, and than I can build the
kernel, which rebuilds the module. If there is no package yet for the module,
I have to build the module twice - or maybe put the updated sources to
/usr/local/sys manually. When using PORTS_MODULES, I can just update the ports
tree and build the kernel.

Regards,
Toma
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Ian Lepore-3
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Theron Tarigo
In reply to this post by John Baldwin
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?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Theron Tarigo
On 8/14/19 9:38 AM, Theron wrote:

> 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.

LOCALBASE is used in various other non-ports Makefiles to find things
installed by ports/packages.  There is in fact another variable I failed to
mention (LOCAL_MODULES_DIR which defaults to LOCALBASE/sys/modules) and
one could set that instead of LOCALBASE for the /mnt case.

>>> 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?

As I said, you can set LOCAL_MODULES="" in /etc/src.conf if you want a global
knob, or you can set it with smaller granularity in either a kernel config
or on the command line.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Emmanuel Vadot-7
In reply to this post by John Baldwin
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin <[hidden email]> 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 <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Niclas Zeising-6
On 2019-08-14 19:23, Emmanuel Vadot wrote:

> On Wed, 14 Aug 2019 10:13:48 -0700
> John Baldwin <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Emmanuel Vadot-7
On Wed, 14 Aug 2019 19:55:02 +0200
Niclas Zeising <[hidden email]> wrote:

> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin <[hidden email]> 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 <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Emmanuel Vadot-7
On 8/14/19 10:23 AM, Emmanuel Vadot wrote:

> On Wed, 14 Aug 2019 10:13:48 -0700
> John Baldwin <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Ian Lepore-3
In reply to this post by Niclas Zeising-6
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 <[hidden email]> 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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Kyle Evans-3
On Wed, Aug 14, 2019 at 1:04 PM Ian Lepore <[hidden email]> 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 <[hidden email]> 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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

Emmanuel Vadot-7
In reply to this post by John Baldwin
On Wed, 14 Aug 2019 11:04:03 -0700
John Baldwin <[hidden email]> wrote:

> On 8/14/19 10:23 AM, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin <[hidden email]> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Kyle Evans-3
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: drm-current-kmod now installs sources

John Baldwin
In reply to this post by Ian Lepore-3
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
12