Re: priority of paths to kernel modules?
+1. If modules needed are recognized correctly and specified with full-path like /boot/modules/drm.ko, the priority wouldn't matter. On Fri, 24 Aug 2018 17:29:19 -0600 Warner Losh wrote: > On Fri, Aug 24, 2018 at 4:20 PM Niclas Zeising wrote: > > > On 08/24/18 17:20, Warner Losh wrote: > > > This would allow the graphics port to have a rc script that sets > > > this up so when X11 goes to automatically load the module, the right one > > > gets loaded. > > > > > > > I just want to point out that X11 doesn't load the graphics kernel > > driver by default when using the drm-*-kmod ports, and I'm not sure the > > hack to have the intel ddx (xf86-video-intel) load the drm2 driver is > > still around. > > > > It doesn't really matter though, since upstream is moving away from > > having X load the driver, and I'd like us to follow suit by using > > devmatch (this is one of the reasons we wanted to get rid of the base > > drivers, as I've stated before). X can't always know which driver to > > load (when using modesetting for instance), and in my opinion, it should > > be the kernel/loader that decides which drivers to load. > > > Excellent. That reduces the compatibility matrix I need to consider. I have > some ideas, and will hack on them to see if a clever bit of slide of hand > will solve the main problem of loading the wrong driver in a dependency > chain. > > 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" > -- Tomoaki AOKI ___ 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: priority of paths to kernel modules?
On 08/25, Niclas Zeising wrote: On 08/24/18 17:20, Warner Losh wrote: This would allow the graphics port to have a rc script that sets this up so when X11 goes to automatically load the module, the right one gets loaded. I just want to point out that X11 doesn't load the graphics kernel driver by default when using the drm-*-kmod ports, and I'm not sure the hack to have the intel ddx (xf86-video-intel) load the drm2 driver is still around. It doesn't really matter though, since upstream is moving away from having X load the driver, and I'd like us to follow suit by using devmatch (this is one of the reasons we wanted to get rid of the base drivers, as I've stated before). X can't always know which driver to load (when using modesetting for instance), and in my opinion, it should be the kernel/loader that decides which drivers to load. Yes, of course X shouldn't load the driver - also because: - X is not the only display server people use (I use Weston) - the console (vt) should also run with the graphics driver! (e.g. efifb currently conflicts with radeon/amdgpu so you have to turn efifb off to get anything working on EFI + Radeon, also many ARM boards do not have any graphics support in U-Boot or whatever firmware) I'm surprised to hear anyone was relying on the X server to load the kernel module. I *always* used kld_list. ___ 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 4:20 PM Niclas Zeising wrote: > On 08/24/18 17:20, Warner Losh wrote: > > This would allow the graphics port to have a rc script that sets > > this up so when X11 goes to automatically load the module, the right one > > gets loaded. > > > > I just want to point out that X11 doesn't load the graphics kernel > driver by default when using the drm-*-kmod ports, and I'm not sure the > hack to have the intel ddx (xf86-video-intel) load the drm2 driver is > still around. > > It doesn't really matter though, since upstream is moving away from > having X load the driver, and I'd like us to follow suit by using > devmatch (this is one of the reasons we wanted to get rid of the base > drivers, as I've stated before). X can't always know which driver to > load (when using modesetting for instance), and in my opinion, it should > be the kernel/loader that decides which drivers to load. Excellent. That reduces the compatibility matrix I need to consider. I have some ideas, and will hack on them to see if a clever bit of slide of hand will solve the main problem of loading the wrong driver in a dependency chain. 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: priority of paths to kernel modules?
On 08/24/18 17:20, Warner Losh wrote: This would allow the graphics port to have a rc script that sets this up so when X11 goes to automatically load the module, the right one gets loaded. I just want to point out that X11 doesn't load the graphics kernel driver by default when using the drm-*-kmod ports, and I'm not sure the hack to have the intel ddx (xf86-video-intel) load the drm2 driver is still around. It doesn't really matter though, since upstream is moving away from having X load the driver, and I'd like us to follow suit by using devmatch (this is one of the reasons we wanted to get rid of the base drivers, as I've stated before). X can't always know which driver to load (when using modesetting for instance), and in my opinion, it should be the kernel/loader that decides which drivers to load. 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: priority of paths to kernel modules?
In message <1535127391.1488.23.ca...@freebsd.org>, Ian Lepore writes: > On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > > My idea, which I implemented locally and should probably create a > > phab review, was to ifdef DRM in modules/Makefile. We could do this > > too. Default not to build/install. > > > > This seems like the obvious fix. I thought the whole point of all this > is that we support drm2 on some platforms, but not x86 anymore. So to > me that implies not building the modules by default on x86. Then we limit it knob to only those platforms we wish to remove it from now. I suggested default off however in a private email I received it was intimated to me that default on for the first while would be better. Personally, I don't care about the minutia but I do care that we have some kind of migration roadmap. -- 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 5:43 PM Warner Losh wrote: > > > On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg > wrote: > >> There's some tricks we can do here. >>> >>> First, I talked to Kyle yesterday about augmenting the Lua loader to >>> have a X_loadflag option. Some background. We look at a lot of X_ flags >>> for loading modules. X_load=yes being the most familiar. One way to avoid >>> POLA would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so >>> that by default, we'd run load -K i915kms instead of load i915kms. We'd >>> augment the built-in load command so it knew that -K means 'add the kernel >>> to the path last rather than first'. This would solve one of the POLA >>> violations in a very targeted way: people that put i915kms_load=YES in >>> their loader.conf wouldn't be surprised by this transition. It would be at >>> the cost of 2 entires in loader.conf, I believe, and it shuts down one >>> vector of hassle for our users. People do this, btw, to get more lines / >>> columns in the BIOS boot environment for their console, so it's not an >>> unreasonable path to attend to. >>> >>> We could also have a sysctl that we could set to override specific >>> modules locations. This would allow the graphics port to have a rc script >>> that sets this up so when X11 goes to automatically load the module, the >>> right one gets loaded. This would solve the issue for the people that 'do >>> nothing' except install the port. While it's a small bit of programming for >>> the kernel, it's a general mechanism that's laser-focused on exceptions to >>> the rule w/o wholesale changes. This would solve the other main vector and >>> motivator for the 'kill it with fire' calls that doesn't leave behind a >>> scorched earth. >>> >> >> >> Just a small note here. With the modesetting driver (which is replacing >> the deprecated xf86-video-intel and is built into Xorg), X will not load >> the drm driver for you. It has to be done by putting kld_list="i915kms" in >> your rc.conf (I don't think loading drm next modules from /boot/loader.conf >> works). >> > > I have done this in the past, but I had to jump through a number of hoops > to do it. I'll have to buy a laptop and see if I can do it with modern gear > and modern software. > > But if X isn't loading the module for you, that makes the problem much, > much easier. > Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon, X might still do it. Need to test to confirm. However, there's nothing stopping you from loading it in rc.conf before starting X (which is probably better anyway). > 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: priority of paths to kernel modules?
On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > My idea, which I implemented locally and should probably create a > phab review, was to ifdef DRM in modules/Makefile. We could do this > too. Default not to build/install. > This seems like the obvious fix. I thought the whole point of all this is that we support drm2 on some platforms, but not x86 anymore. So to me that implies not building the modules by default on x86. -- Ian > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -Original Message- > From: Johannes Lundberg > Sent: 24/08/2018 01:08 > To: freebsd-current > Subject: priority of paths to kernel modules? > > Hi > > Since we now stuck with drm2 in base for a few more years I have an > idea > would make things much smoother for many of us, hugely reduce the > amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > module_path="/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel > have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed > in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct > this is a > flaw and /boot/ should be inserted last so that any > overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and > you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > .org" > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg wrote: > There's some tricks we can do here. >> >> First, I talked to Kyle yesterday about augmenting the Lua loader to have >> a X_loadflag option. Some background. We look at a lot of X_ flags for >> loading modules. X_load=yes being the most familiar. One way to avoid POLA >> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that >> by default, we'd run load -K i915kms instead of load i915kms. We'd augment >> the built-in load command so it knew that -K means 'add the kernel to the >> path last rather than first'. This would solve one of the POLA violations >> in a very targeted way: people that put i915kms_load=YES in their >> loader.conf wouldn't be surprised by this transition. It would be at the >> cost of 2 entires in loader.conf, I believe, and it shuts down one vector >> of hassle for our users. People do this, btw, to get more lines / columns >> in the BIOS boot environment for their console, so it's not an unreasonable >> path to attend to. >> >> We could also have a sysctl that we could set to override specific >> modules locations. This would allow the graphics port to have a rc script >> that sets this up so when X11 goes to automatically load the module, the >> right one gets loaded. This would solve the issue for the people that 'do >> nothing' except install the port. While it's a small bit of programming for >> the kernel, it's a general mechanism that's laser-focused on exceptions to >> the rule w/o wholesale changes. This would solve the other main vector and >> motivator for the 'kill it with fire' calls that doesn't leave behind a >> scorched earth. >> > > > Just a small note here. With the modesetting driver (which is replacing > the deprecated xf86-video-intel and is built into Xorg), X will not load > the drm driver for you. It has to be done by putting kld_list="i915kms" in > your rc.conf (I don't think loading drm next modules from /boot/loader.conf > works). > I have done this in the past, but I had to jump through a number of hoops to do it. I'll have to buy a laptop and see if I can do it with modern gear and modern software. But if X isn't loading the module for you, that makes the problem much, much easier. 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: priority of paths to kernel modules?
My idea, which I implemented locally and should probably create a phab review, was to ifdef DRM in modules/Makefile. We could do this too. Default not to build/install. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Johannes Lundberg Sent: 24/08/2018 01:08 To: freebsd-current Subject: priority of paths to kernel modules? Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers ___ 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 5:20 PM Warner Losh wrote:
>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
>> wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy
>> wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE
>> wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs
>> of RE
>> > > > and the graphics team + user base on post-2013 hardware - the
>> graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights
>> to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply
>> say we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>
>> Since we are in code freeze we could all go work on those things :-)
>>
>
> Yes. That's why I wanted all removals to wait until after the freeze so
> that I could get the deprecation policy hammered out better, including a
> common set of guidelines to know when to remove, when to disable, and how
> to ease things out of the tree in as a non-disruptive way as possible.
>
>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose
>> to have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>>
>
> There's some tricks we can do here.
>
> First, I talked to Kyle yesterday about augmenting the Lua loader to have
> a X_loadflag option. Some background. We look at a lot of X_ flags for
> loading modules. X_load=yes being the most familiar. One way to avoid POLA
> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
> the built-in load command so it knew that -K means 'add the kernel to the
> path last rather than first'. This would solve one of the POLA violations
> in a very targeted way: people that put i915kms_load=YES in their
> loader.conf wouldn't be surprised by this transition. It would be at the
> cost of 2 entires in loader.conf, I believe, and it shuts down one vector
> of hassle for our users. People do this, btw, to get more lines / columns
> in the BIOS boot environment for their console, so it's not an unreasonable
> path to attend to.
>
> We could also have a sysctl that we could set to override specific modules
> locations. This would allow the graphics port to have a rc script that sets
> this up so when X11 goes to automatically load the module, the right one
> gets loaded. This would solve the issue for the people that 'do nothing'
> except install the port. While it's a small bit of programming for the
> kernel, it's a general mechanism that's laser-focused on exceptions to the
> rule w/o wholesale changes. This would solve the other main vector and
> motivator for the 'kill it with fire' calls that doesn't leave behind a
> scorched earth.
>
Just a small note here. With the modesetting driver (which is replacing the
deprecated xf86-video-intel and is built into Xorg), X will not load the
drm driver for you. It has to be done by putting kld_list="i915kms" in your
rc.conf (I don't think loading drm next modules from /boot/loader.conf
works).
> The people that do nothing, not even install a graphics port, we might be
> able to 'poison pill' the drivers such that we fail the load hard enough
> X11 doesn't start, but with a clear error message about next steps. This is
> a bonus of leaving them in the tree: we would just have a silent failure
> otherwise as X11 tries to load i915kms.ko only to have no driver attach.
>
> > (Putting on my loader ballcap)
>> >
>> > I would like to change this after 12 branches to append by default and
>> > allow one to add ${kernel_path} to their module_path to override that,
>> > since the status quo has been such for 18 years and some may want to
>> > go back to that. I've personally been bitten by it a couple too many
>> > times to be happy with the current situation.
>> >
>> > (Takes off loader ballcap)
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 10:20 AM Warner Losh wrote:
>
>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes
> wrote:
>>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
>> > wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs of
>> > > > RE
>> > > > and the graphics team + user base on post-2013 hardware - the graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply say
>> > > > we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> > > > processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>>
>> Since we are in code freeze we could all go work on those things :-)
>
>
> Yes. That's why I wanted all removals to wait until after the freeze so that
> I could get the deprecation policy hammered out better, including a common
> set of guidelines to know when to remove, when to disable, and how to ease
> things out of the tree in as a non-disruptive way as possible.
>
>>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> > > > demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose to
>> > > have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>
>
> There's some tricks we can do here.
>
> First, I talked to Kyle yesterday about augmenting the Lua loader to have a
> X_loadflag option. Some background. We look at a lot of X_ flags for
> loading modules. X_load=yes being the most familiar. One way to avoid POLA
> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
> the built-in load command so it knew that -K means 'add the kernel to the
> path last rather than first'. This would solve one of the POLA violations in
> a very targeted way: people that put i915kms_load=YES in their loader.conf
> wouldn't be surprised by this transition. It would be at the cost of 2
> entires in loader.conf, I believe, and it shuts down one vector of hassle for
> our users. People do this, btw, to get more lines / columns in the BIOS boot
> environment for their console, so it's not an unreasonable path to attend to.
>
> We could also have a sysctl that we could set to override specific modules
> locations. This would allow the graphics port to have a rc script that sets
> this up so when X11 goes to automatically load the module, the right one gets
> loaded. This would solve the issue for the people that 'do nothing' except
> install the port. While it's a small bit of programming for the kernel, it's
> a general mechanism that's laser-focused on exceptions to the rule w/o
> wholesale changes. This would solve the other main vector and motivator for
> the 'kill it with fire' calls that doesn't leave behind a scorched earth.
>
> The people that do nothing, not even install a graphics port, we might be
> able to 'poison pill' the drivers such that we fail the load hard enough X11
> doesn't start, but with a clear error message about next steps. This is a
> bonus of leaving them in the tree: we would just have a silent failure
> otherwise as X11 tries to load i915kms.ko only to have no driver attach.
>
>> > (Putting on my loader ballcap)
>> >
>> > I would like to change this after 12 branches to append by default and
>> > allow one to add ${kernel_path} to their module_path to override that,
>> > since the status quo has been such for 18 years and some may want to
>> > go back to that. I've personally been bitten by it a couple too many
>> > times to be happy with the current situation.
>> >
>> > (Takes off loader ballcap)
>>
>> I actually like this solution, it appears to be a win for everyone
>> and would make the road smoother in the future for similiar types
>> of things should they happen.
>
>
> Generally, things don't conflict. I like this notion for a number of reasons.
> It lets me have a 'driver disk'
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
> wrote:
> > >
> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy
> wrote:
> > >
> > > > No we're not. x86 and PPC will be disconnected from the build in a
> > > > subsequent commit during the freeze. Warner was simply too tired to
> > > > communicate this adequately and still meet the timeline that RE
> wanted.
> > > >
> > > > And take heart. Even if Warner weren't trying to balance the needs
> of RE
> > > > and the graphics team + user base on post-2013 hardware - the
> graphics
> > > > doesn't _have_ to support 12.x. it's well within the team's rights to
> > > > simply declare 12.x as unsupported. The team is welcome to simply
> say we
> > > > support 11.x and 13.x. The failing was largely in that "expected"
> processes
> > > > are not documented and not well communicated.
>
> The deprececation policy is documented, though poorly, and I agree in
> the spirit that much of the processes here in the FreeBSD project are
> sadly in a similiar situation.
>
To say this is a learning situation for all those involved is not an
understatement.
> Since we are in code freeze we could all go work on those things :-)
>
Yes. That's why I wanted all removals to wait until after the freeze so
that I could get the deprecation policy hammered out better, including a
common set of guidelines to know when to remove, when to disable, and how
to ease things out of the tree in as a non-disruptive way as possible.
> > > > Warner is acting in good faith. He's just trying to balance many
> demands
> > > > in a compressed time period.
> > > >
> > > > Cheers.
> > > > -M
> > > >
> > > >
> > > OK, thanks for the clarification. That's a good compromise I guess.
> > >
> > > Still, regardless of drm, aren't modules in overlay folders suppose to
> have
> > > higher priority than those in the kernel folder?
>
> I agree, but usually do not depend on that to get what I need,
> but rather resort to any special needs by force loading with
> /boot/loader.conf modules that are loaded out of order.
>
There's some tricks we can do here.
First, I talked to Kyle yesterday about augmenting the Lua loader to have a
X_loadflag option. Some background. We look at a lot of X_ flags for
loading modules. X_load=yes being the most familiar. One way to avoid POLA
would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
by default, we'd run load -K i915kms instead of load i915kms. We'd augment
the built-in load command so it knew that -K means 'add the kernel to the
path last rather than first'. This would solve one of the POLA violations
in a very targeted way: people that put i915kms_load=YES in their
loader.conf wouldn't be surprised by this transition. It would be at the
cost of 2 entires in loader.conf, I believe, and it shuts down one vector
of hassle for our users. People do this, btw, to get more lines / columns
in the BIOS boot environment for their console, so it's not an unreasonable
path to attend to.
We could also have a sysctl that we could set to override specific modules
locations. This would allow the graphics port to have a rc script that sets
this up so when X11 goes to automatically load the module, the right one
gets loaded. This would solve the issue for the people that 'do nothing'
except install the port. While it's a small bit of programming for the
kernel, it's a general mechanism that's laser-focused on exceptions to the
rule w/o wholesale changes. This would solve the other main vector and
motivator for the 'kill it with fire' calls that doesn't leave behind a
scorched earth.
The people that do nothing, not even install a graphics port, we might be
able to 'poison pill' the drivers such that we fail the load hard enough
X11 doesn't start, but with a clear error message about next steps. This is
a bonus of leaving them in the tree: we would just have a silent failure
otherwise as X11 tries to load i915kms.ko only to have no driver attach.
> (Putting on my loader ballcap)
> >
> > I would like to change this after 12 branches to append by default and
> > allow one to add ${kernel_path} to their module_path to override that,
> > since the status quo has been such for 18 years and some may want to
> > go back to that. I've personally been bitten by it a couple too many
> > times to be happy with the current situation.
> >
> > (Takes off loader ballcap)
>
> I actually like this solution, it appears to be a win for everyone
> and would make the road smoother in the future for similiar types
> of things should they happen.
>
Generally, things don't conflict. I like this notion for a number of
reasons. It lets me have a 'driver disk' which can be placed first in the
load for install and not have to worry about naming. It also gives us more
flexibility for things in the future. The time to propose it, however, was
May so we could shake things out, so it's
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 2:14 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > We're still trying to figure out that issue. I'd like to do this, but there's a lot of moving parts and objections that I need to plow through before it's a done deal. Expect further incremental steps. We already do not build in the kernel for x86 or powerpc, which gives us a lot more flexibility. The revert was a first step, not a final stop. > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > The graphics team doesn't have to support what's in the tree, at all. One of the things that we absolutely will be doing is putting in big scary notices saying that these drivers are deprecated, that you should be using the ports and to not expect any support and these drivers are present only as a transition. Other ideas that I'm exploring, is the notion of a poison pill for the in-tree drivers. So, we put all the IDs for the *NEW* cards into a driver (maybe the intel/radeon one, maybe a new one: there's pros and cons to each that need to be looked at). All this driver does is return a probe value that's tiny so it usually isn't accepted. But when it is, it prints a message saying "This card isn't supported by the in-tree driver. You must install the port" and fails to attach, which would fail X11 startup. Not completely ideal, but the X11 startup already fails with little clue and this would help. Warner is acting in good faith. He's just trying to balance many demands in > a compressed time period. > Yesterday, hours before Johannes' email went out, I was communicating with the Lua boot loader guy about ways we could change the path the boot loader users for certain modules and other such things to mitigate this problem. Warner > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > > > Hi > > > > Since we now stuck with drm2 in base for a few more years I have an idea > > would make things much smoother for many of us, hugely reduce the amount > of > > bug reports we get and I think would be beneficial in other ways too. > > > > Current I run with something like this in /boot/loader.conf > > > > > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > > > However, if you look at this > > sysctl kern.module_path > > kern.module_path: > > > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > > > /boot/kernel is inserted first and probably modules in /boot/kernel have > > the highest priority. This is also proven by everyone wanting to use > > drm*kmods that get drm.ko from base loaded instead of the installed in > > /boot/modules. > > > > Please correct me if I'm wrong but if my understanding is correct this > is a > > flaw and /boot/ should be inserted last so that any overlays or > > custom modules have higher priority than the default ones. > > > > I can imagine this is also useful when building custom modules and you > > don't want to overwrite or delete the default one in /boot/kernel... > > > > Cheers > > ___ > > 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" > ___ 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: priority of paths to kernel modules?
> On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote:
> >
> > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
> >
> > > No we're not. x86 and PPC will be disconnected from the build in a
> > > subsequent commit during the freeze. Warner was simply too tired to
> > > communicate this adequately and still meet the timeline that RE wanted.
> > >
> > > And take heart. Even if Warner weren't trying to balance the needs of RE
> > > and the graphics team + user base on post-2013 hardware - the graphics
> > > doesn't _have_ to support 12.x. it's well within the team's rights to
> > > simply declare 12.x as unsupported. The team is welcome to simply say we
> > > support 11.x and 13.x. The failing was largely in that "expected"
> > > processes
> > > are not documented and not well communicated.
The deprececation policy is documented, though poorly, and I agree in
the spirit that much of the processes here in the FreeBSD project are
sadly in a similiar situation.
Since we are in code freeze we could all go work on those things :-)
> > > Warner is acting in good faith. He's just trying to balance many demands
> > > in a compressed time period.
> > >
> > > Cheers.
> > > -M
> > >
> > >
> > OK, thanks for the clarification. That's a good compromise I guess.
> >
> > Still, regardless of drm, aren't modules in overlay folders suppose to have
> > higher priority than those in the kernel folder?
I agree, but usually do not depend on that to get what I need,
but rather resort to any special needs by force loading with
/boot/loader.conf modules that are loaded out of order.
> (Putting on my loader ballcap)
>
> I would like to change this after 12 branches to append by default and
> allow one to add ${kernel_path} to their module_path to override that,
> since the status quo has been such for 18 years and some may want to
> go back to that. I've personally been bitten by it a couple too many
> times to be happy with the current situation.
>
> (Takes off loader ballcap)
I actually like this solution, it appears to be a win for everyone
and would make the road smoother in the future for similiar types
of things should they happen.
--
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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote:
>
> On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
>
> > No we're not. x86 and PPC will be disconnected from the build in a
> > subsequent commit during the freeze. Warner was simply too tired to
> > communicate this adequately and still meet the timeline that RE wanted.
> >
> > And take heart. Even if Warner weren't trying to balance the needs of RE
> > and the graphics team + user base on post-2013 hardware - the graphics
> > doesn't _have_ to support 12.x. it's well within the team's rights to
> > simply declare 12.x as unsupported. The team is welcome to simply say we
> > support 11.x and 13.x. The failing was largely in that "expected" processes
> > are not documented and not well communicated.
> >
> > Warner is acting in good faith. He's just trying to balance many demands
> > in a compressed time period.
> >
> > Cheers.
> > -M
> >
> >
> OK, thanks for the clarification. That's a good compromise I guess.
>
> Still, regardless of drm, aren't modules in overlay folders suppose to have
> higher priority than those in the kernel folder?
>
(Putting on my loader ballcap)
I would like to change this after 12 branches to append by default and
allow one to add ${kernel_path} to their module_path to override that,
since the status quo has been such for 18 years and some may want to
go back to that. I've personally been bitten by it a couple too many
times to be happy with the current situation.
(Takes off loader ballcap)
Thanks,
Kyle Evans
___
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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > > Warner is acting in good faith. He's just trying to balance many demands > in a compressed time period. > > Cheers. > -M > > OK, thanks for the clarification. That's a good compromise I guess. Still, regardless of drm, aren't modules in overlay folders suppose to have higher priority than those in the kernel folder? > > > > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > >> Hi >> >> Since we now stuck with drm2 in base for a few more years I have an idea >> would make things much smoother for many of us, hugely reduce the amount >> of >> bug reports we get and I think would be beneficial in other ways too. >> >> Current I run with something like this in /boot/loader.conf >> >> >> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" >> >> So I expect modules to be loaded in that order, with /boot/ >> LAST. >> >> However, if you look at this >> sysctl kern.module_path >> kern.module_path: >> >> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays >> >> /boot/kernel is inserted first and probably modules in /boot/kernel have >> the highest priority. This is also proven by everyone wanting to use >> drm*kmods that get drm.ko from base loaded instead of the installed in >> /boot/modules. >> >> Please correct me if I'm wrong but if my understanding is correct this is >> a >> flaw and /boot/ should be inserted last so that any overlays or >> custom modules have higher priority than the default ones. >> >> I can imagine this is also useful when building custom modules and you >> don't want to overwrite or delete the default one in /boot/kernel... >> >> Cheers >> ___ >> 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: priority of paths to kernel modules?
No we're not. x86 and PPC will be disconnected from the build in a subsequent commit during the freeze. Warner was simply too tired to communicate this adequately and still meet the timeline that RE wanted. And take heart. Even if Warner weren't trying to balance the needs of RE and the graphics team + user base on post-2013 hardware - the graphics doesn't _have_ to support 12.x. it's well within the team's rights to simply declare 12.x as unsupported. The team is welcome to simply say we support 11.x and 13.x. The failing was largely in that "expected" processes are not documented and not well communicated. Warner is acting in good faith. He's just trying to balance many demands in a compressed time period. Cheers. -M On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg wrote: > Hi > > Since we now stuck with drm2 in base for a few more years I have an idea > would make things much smoother for many of us, hugely reduce the amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct this is a > flaw and /boot/ should be inserted last so that any overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > ___ > 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"
priority of paths to kernel modules?
Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers ___ 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"
