tatus: New
>>> Severity: Affects Only Me
>>> Priority: ---
>>> Component: arm
>>> Assignee: freebsd-...@freebsd.org
>>> Reporter: marklmi26-f...@yahoo.com
>>
>> Turns out that internally dlerror is reporting:
>>
>> "/usr/lib/ossl-
...@freebsd.org
>> Reporter: marklmi26-f...@yahoo.com
>
> Turns out that internally dlerror is reporting:
>
> "/usr/lib/ossl-modules/legacy.so: Undefined symbol \"MD4_Update\"", '\000'
>
>
> (as shown via a gdb session printing the s
Product: Base System
> Version: CURRENT
> Hardware: Any
> OS: Any
> Status: New
> Severity: Affects Only Me
> Priority: ---
> Component: arm
> Assignee: freebsd-...@freebsd.org
> Reporter: marklmi26-f...@yahoo.com
Turns out that internally dlerror is reporting:
"/usr/lib/
Aug 2, 2023, 11:27 AM Mark Millard wrote:
>>> man arch reports:
>>>
>>> MACHINE MACHINE_CPUARCH MACHINE_ARCH
>>> arm64 aarch64 aarch64
>>> . . .
>>> arm arm armv6, ar
man arch reports:
MACHINE MACHINE_CPUARCH MACHINE_ARCH
arm64 aarch64 aarch64
. . .
arm arm armv6, armv7
So I'd not expect arm64 in MACHINE_ARCH . But
sys/modules/Makefile has (from a gre
MACHINE MACHINE_CPUARCH MACHINE_ARCH
>> arm64 aarch64 aarch64
>> . . .
>> arm arm armv6, armv7
>>
>> So I'd not expect arm64 in MACHINE_ARCH . But
>> sys/modules/Makefile has (fr
rch64 aarch64
> . . .
>arm arm armv6, armv7
>
> So I'd not expect arm64 in MACHINE_ARCH . But
> sys/modules/Makefile has (from a grep for MACHINE_ARCH):
>
> .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "
armv6, armv7
>
> So I'd not expect arm64 in MACHINE_ARCH . But
> sys/modules/Makefile has (from a grep for MACHINE_ARCH):
>
> .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm64"
> .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH}
t;> /* link_elf_obj.c */
>>>> static int
>>>> link_elf_load_file(linker_class_t cls, const char *filename,
>>>> linker_file_t *result)
>>>> {
>>>> ...
>>>>if (hdr->e_type != ET_REL) {
>>>>
;>>
>>>
>>> /* link_elf_obj.c */
>>> static int
>>> link_elf_load_file(linker_class_t cls, const char *filename,
>>> linker_file_t *result)
>>> {
>>> ...
>>> if (hdr->e_type != ET_REL) {
>>> error = ENOSYS;
>>&g
> On 26. Apr 2023, at 13:38, Hans Petter Selasky wrote:
>
> On 4/26/23 13:12, Konstantin Belousov wrote:
>> No, in-kernel linker does not behave this way.
>> Modules need to contain explicit reference to all modules they depend upon,
>> using the MODULE_DEPEND() ma
On Wed, Apr 26, 2023 at 01:38:32PM +0200, Hans Petter Selasky wrote:
> On 4/26/23 13:12, Konstantin Belousov wrote:
> > No, in-kernel linker does not behave this way.
> > Modules need to contain explicit reference to all modules they depend upon,
> > using the MODULE_DEPEND()
On 4/26/23 13:12, Konstantin Belousov wrote:
No, in-kernel linker does not behave this way.
Modules need to contain explicit reference to all modules they depend upon,
using the MODULE_DEPEND() macro. Only symbols from the dependencies are
resolved.
All modules get an implicit reference to
; > {
> > ...
> > if (hdr->e_type != ET_REL) {
> > error = ENOSYS;
> > goto out;
> > }
> > ...
> > }
> > ```
> >
> > Run the following snip:
> > ```
> > # find /boot/kernel -type f -name
error = ENOSYS;
goto out;
}
...
}
```
Run the following snip:
```
# find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type
```
shows that all the kernel modules' types are `REL (Relocatable file)`.
I guess if some module such as if_bridge
goto out;
}
...
}
```
Run the following snip:
```
# find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type
```
shows that all the kernel modules' types are `REL (Relocatable file)`.
I guess if some module such as if_bridge is linked to DYN type, then I can do
oblem to sort
> out?
> I figured config(8) could generate a bunch of WITHOUT_ of similar, but I
> guess
> sys/modules/Makefile will have to be patched to support it, which it
> only does for some modules at the moment.
>
> I don't have any interest in working on it, so just br
f similar, but I guess
sys/modules/Makefile will have to be patched to support it, which it
only does for some modules at the moment.
I don't have any interest in working on it, so just bringing this up
for interested.
--
Mateusz Guzik
>
> Emmanuel Vadot writes:
> > On Thu, 02 Feb 2023 20:58:58 +
> > "Poul-Henning Kamp" wrote:
> >
> > >
> > > parv/FreeBSD writes:
> > >
> > > > > Does backlight(8) works for you?
> > > >
> > > > Thanks for the clue. It does! It does ...
> > > >
> > > > - I get the same numbe
Emmanuel Vadot writes:
> On Thu, 02 Feb 2023 20:58:58 +
> "Poul-Henning Kamp" wrote:
>
> >
> > parv/FreeBSD writes:
> >
> > > > Does backlight(8) works for you?
> > >
> > > Thanks for the clue. It does! It does ...
> > >
> > > - I get the same number back via "backlight" wit
On Thu, 02 Feb 2023 20:58:58 +
"Poul-Henning Kamp" wrote:
>
> parv/FreeBSD writes:
>
> > > Does backlight(8) works for you?
> >
> > Thanks for the clue. It does! It does ...
> >
> > - I get the same number back via "backlight" without any arguments as
> > what I gave it earlier. T
parv/FreeBSD writes:
> > Does backlight(8) works for you?
>
> Thanks for the clue. It does! It does ...
>
> - I get the same number back via "backlight" without any arguments as
> what I gave it earlier. There was no reporting of value being
> subtracted by one;
Sorry for the delay i
kage/port)
> > & "acpi_video" (FreeBSD) kernel module.
> >
> > Earlier I was able to change brightness via "hw.acpi.video" MIB ...
> >
> > # - Need to have both "i915kms" & "acpi_video" modules already loaded.
> > #
&
Emmanuel Vadot writes:
> What does backlight reports after you've unplugged the AC adaptor ?
I cant make that experiment right now, I also ethernet through that
connector, but I'll do it later today.
But speaking of what backlight reports:
critter phk> backlight
bright
On Tue, 31 Jan 2023 13:09:39 +
"Poul-Henning Kamp" wrote:
>
> Emmanuel Vadot writes:
>
> > > > Does backlight(8) works for you?
> > >
> > > Speaking of backlight(8): On my T14s, I see the following:
> > >
> > > If I set the light with backlight(8) to something, say 30%, and then
Emmanuel Vadot writes:
> > > Does backlight(8) works for you?
> >
> > Speaking of backlight(8): On my T14s, I see the following:
> >
> > If I set the light with backlight(8) to something, say 30%, and then
> > change the power-situation, for instance by unplugging the charger,
> > the
On Tue, 31 Jan 2023 12:33:02 +
"Poul-Henning Kamp" wrote:
>
> Oleksandr Kryvulia writes:
>
> > Does backlight(8) works for you?
>
> Speaking of backlight(8): On my T14s, I see the following:
>
> If I set the light with backlight(8) to something, say 30%, and then
> change the pow
On 1/31/23 13:33, Poul-Henning Kamp wrote:
> Speaking of backlight(8): On my T14s, I see the following:
>
> If I set the light with backlight(8) to something, say 30%, and then
> change the power-situation, for instance by unplugging the charger,
> the backlight goes up to 100%.
>
> If I then try
Oleksandr Kryvulia writes:
> Does backlight(8) works for you?
Speaking of backlight(8): On my T14s, I see the following:
If I set the light with backlight(8) to something, say 30%, and then
change the power-situation, for instance by unplugging the charger,
the backlight goes up to 100
ule.
Earlier I was able to change brightness via "hw.acpi.video" MIB ...
# - Need to have both "i915kms" & "acpi_video" modules already loaded.
#
# 20221120 - These MIBs do not work anymore as they are missing.
hw.acpi.video.lcd0.economy=10
hw.acpi.video.lcd0.
was able to change brightness via "hw.acpi.video" MIB ...
# - Need to have both "i915kms" & "acpi_video" modules already loaded.
#
# 20221120 - These MIBs do not work anymore as they are missing.
hw.acpi.video.lcd0.economy=10
hw.acpi.video.lcd0.fullpower=40
hw.acpi.video.lcd0.
Hi,
Commits over the last couple of days and ones happening
over the next few days change the internal KPI between
the nfs modules (nfscommon.ko, nfscl.ko and nfsserver.ko).
As such, after pulling an up to date main from the git repo
you need to build all nfs modules from the new sources.
I am
Allan Jude wrote:
> On 5/3/2022 2:05 PM, Julian H. Stacey wrote:
> >> From: bugzilla-nore...@freebsd.org
> >> Date: Tue, 03 May 2022 17:20:14 +
> >> To: j...@berklix.com
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758
> >>
> >> Li-Wen Hsu changed:
> >>
> >> What
t #2 from Li-Wen Hsu ---
> > Does WITHOUT_MODULES in make.conf(5) work here?
>
> Ouch ! Thanks ! I didn't know that existed ! I may have wasted time
> re-inventing the wheel, I'll look more at both.
>
> PS Seems to me a whole slew of that man make.conf more properly n
On 5/3/2022 2:05 PM, Julian H. Stacey wrote:
From: bugzilla-nore...@freebsd.org
Date: Tue, 03 May 2022 17:20:14 +
To: j...@berklix.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758
Li-Wen Hsu changed:
What|Removed |Added
-
> From: bugzilla-nore...@freebsd.org
> Date: Tue, 03 May 2022 17:20:14 +
> To: j...@berklix.com
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758
>
> Li-Wen Hsu changed:
>
>What|Removed |Added
> ---
: Fri, 29 Apr 2022 23:57:02 +0200
> >
> > "Julian H. Stacey" wrote:
> >> Ed Maste wrote:
> >>> On Thu, 28 Apr 2022 at 11:28, Julian H. Stacey wrote:
> >>>>
> >>>> but that's crude. It's nice to be able to buil
Hi, Reference:
> From: "Julian H. Stacey"
> Date: Fri, 29 Apr 2022 23:57:02 +0200
"Julian H. Stacey" wrote:
> Ed Maste wrote:
> > On Thu, 28 Apr 2022 at 11:28, Julian H. Stacey wrote:
> > >
> > > but that's crude. It&#
SLOT relocations by the linker which
>>>> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
>>>> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
>>>> entries also depend on a base pointer in %eb
kernel, e.g. loading linux.ko gives "kldload:
> >> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
> >> entries also depend on a base pointer in %ebx but kernel modules aren't
> >> compiled with -fPIC, so this can't work and I suspect
86/elf_machdep.c. The PLT
>> entries also depend on a base pointer in %ebx but kernel modules aren't
>> compiled with -fPIC, so this can't work and I suspect this is a
>> regression in clang12.
>>
>> The following code shows the difference between clang11 and
_PC32).
> These are converted to R_386_JMP_SLOT relocations by the linker which
> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
> entries also depend on a base pointer in %ebx
x27;t supported by the kernel, e.g. loading linux.ko gives "kldload:
unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
entries also depend on a base pointer in %ebx but kernel modules aren't
compiled with -fPIC, so this can't work and I suspect this is a
re
"Julian H. Stacey" wrote:
> Rick Macklem wrote:
> > Julian H. Stacey wrote:
> > >Hi curr...@freebsd.org,
> > >
> > >/sys/modules/ nfscl & nfsd
> > >With .ctm_status src-cur 14656 .svn_revision 364986
> > >
> > >/usr/src/
Julian H. Stacey wrote:
>Hi curr...@freebsd.org,
>
>/sys/modules/ nfscl & nfsd
>With .ctm_status src-cur 14656 .svn_revision 364986
>
>/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h'
>file not found
># #include "opt
Hi curr...@freebsd.org,
/sys/modules/ nfscl & nfsd
With .ctm_status src-cur 14656 .svn_revision 364986
/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h'
file not found
# #include "opt_kern_tls.h"
# /usr/src/sys/modules/nfsd
# /
On 29 Aug 2020, at 0:16, Bjoern A. Zeeb wrote:
Hi,
I’ve been seeing on both i386 and arm64 builds where I tested that
loading modules from loader will then fail by the kernel link in
certain situations. I’ve created an i386 example where I do load a
few modules from loader to show what I
Hi,
I’ve been seeing on both i386 and arm64 builds where I tested that
loading modules from loader will then fail by the kernel link in certain
situations. I’ve created an i386 example where I do load a few
modules from loader to show what I think the problem is.
You may notice in the
HI Andriy Gapon,
Thanks. It works.
On Wed, Jun 17, 2020 at 11:53 AM Andriy Gapon wrote:
> On 17/06/2020 04:53, Rajesh Kumar wrote:
> > Then, I am trying to compile the driver modules and hit the
> > compilation error. I haven't done "install world" as I don&#x
On 17/06/2020 04:53, Rajesh Kumar wrote:
> Then, I am trying to compile the driver modules and hit the
> compilation error. I haven't done "install world" as I don't want the base
> 12.0 to be disturbed.
You should do `make buildenv` and then do the module build
compile the driver modules and hit the
compilation error. I haven't done "install world" as I don't want the base
12.0 to be disturbed.
When I compared the /usr/include/machine/atomic.h and the atomic.h from the
OBJ directory, I see the below highlighted change. Looks like, build
On Tue, Jun 16, 2020 at 12:29:14PM +0530, Rajesh Kumar wrote:
> Hi,
>
> I am trying to build my module with freebsd current branch. But I am
> facing compilation issue with header files as below. I have built and
> installed the freebsd current branch and booted to that kernel before
> building
Hi,
I am trying to build my module with freebsd current branch. But I am
facing compilation issue with header files as below. I have built and
installed the freebsd current branch and booted to that kernel before
building my module. So, not sure what is going wrong.
*In file included from
Oops, should be *hw.syscons.disable=1* in /boot/loader.conf
On Mon, Aug 26, 2019 at 8:56 PM Clay Daniels Jr.
wrote:
> RE:
> "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
RE:
"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 ex
On Fri, Jun 21, 2019, 7:44 AM Scott Long wrote:
>
>
> > On Jun 17, 2019, at 7:46 PM, Julian H. Stacey wrote:
> >
> >>>
> >>> Stop.
> >>> make[3]: stopped in /usr/src/usr.bin/mkesdb_static
> >>>
> >>> A double waste of CPU & human time & power in a hot office.
> >>> Commit bits used to be suspend
> On Jun 17, 2019, at 7:46 PM, Julian H. Stacey wrote:
>
>>>
>>> Stop.
>>> make[3]: stopped in /usr/src/usr.bin/mkesdb_static
>>>
>>> A double waste of CPU & human time & power in a hot office.
>>> Commit bits used to be suspended for un-buildable code. I'll boot
>>> stable.
>>
>> Since you
tacey" wrote:
>>>> "Bjoern A. Zeeb" wrote:
>>>>> On 17 Jun 2019, at 10:37, Mark Linimon wrote:
>>>>>
>>>>>> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey
>>>>>> wrote:
>>>>>>
> H. Stacey
> > " writes:
> >> "Julian H. Stacey" wrote:
> >>> "Bjoern A. Zeeb" wrote:
> >>>>> On 17 Jun 2019, at 10:37, Mark Linimon wrote:
> >>>>>
> >>>>>> On Mon, Jun 17, 201
net>, "Julian
> H. Stacey
> " writes:
> > "Julian H. Stacey" wrote:
> > > "Bjoern A. Zeeb" wrote:
> > > > On 17 Jun 2019, at 10:37, Mark Linimon wrote:
> > > >
> > > > > On Mon, Jun 17, 2019 at 11:41:03AM +0200,
rote:
>>> "Bjoern A. Zeeb" wrote:
>>>>> On 17 Jun 2019, at 10:37, Mark Linimon wrote:
>>>>>
>>>>>> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
>>>>>> svn_revision 348842
>>>
00, Julian H. Stacey
> > > > > > wrote:
> > > > > > > svn_revision 348842
> > > > > >
> > > > > > [ ...]
> > > > > > > /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal
> > > >
; > > On 17 Jun 2019, at 10:37, Mark Linimon wrote:
> > > >
> > > > > On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey
> > > > > wrote:
> > > > > > svn_revision 348842
> > > > >
> > > > > [ ...]
> > &g
at 10:37, Mark Linimon wrote:
> > > >
> > > > > On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey
> > > > > wrote:
> > > > > > svn_revision 348842
> > > > >
> > > > > [ ...]
> > > > >
37, Mark Linimon wrote:
> > >
> > > > On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
> > > >> svn_revision 348842
> > > > [ ...]
> > > >> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
> &
lian H. Stacey
> > > > wrote:
> > > > > svn_revision 348842
> > > >
> > > > [ ...]
> > > > > /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal
> > > > > error:
> > > > > 'opt_cam.h' fi
Stacey wrote:
>> > >> svn_revision 348842
>> > > [ ...]
>> > >> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal
>error:
>> > >> 'opt_cam.h' file not found
>> > >> #include "opt_cam.
"Julian H. Stacey" wrote:
> "Bjoern A. Zeeb" wrote:
> > On 17 Jun 2019, at 10:37, Mark Linimon wrote:
> >
> > > On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
> > >> svn_revision 348842
> > > [ ...]
> >
019, at 10:37, Mark Linimon wrote:
> > >
> > >> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
> > >>> svn_revision 348842
> > >> [ ...]
> > >>> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
&
revision 348842
> >> [ ...]
> >>> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
> >>> 'opt_cam.h' file not found
> >>> #include "opt_cam.h"
> >>> ^~~
> >>> 1 error generat
On June 17, 2019 3:55:45 AM PDT, "Bjoern A. Zeeb" wrote:
>On 17 Jun 2019, at 10:37, Mark Linimon wrote:
>
>> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
>>> svn_revision 348842
>> [ ...]
>>> /usr/src/sys/modules/
Mark Linimon wrote:
> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
> > svn_revision 348842
> [ ...]
> > /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
> > 'opt_cam.h' file not found
> > #include "op
vn_revision 348842
> > [ ...]
> >> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
> >> 'opt_cam.h' file not found
> >> #include "opt_cam.h"
> >> ^~~
> >> 1 error generated.
> >
&
On 17 Jun 2019, at 10:37, Mark Linimon wrote:
On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
svn_revision 348842
[ ...]
/usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
'opt_cam.h' file not found
#include "opt_cam.h"
On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote:
> svn_revision 348842
[ ...]
> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error:
> 'opt_cam.h' file not found
> #include "opt_cam.h"
> ^~~
> 1 error
.ctm_status src-cur 14077 .svn_revision 348842
===> sys/modules/sdio (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sdio/sdio_if.m -c
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/devic
7;t provide any details: which modules are
required.
--
Best regards,
Lev mailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any m
+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,
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
driv
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 X
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
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
> >
ve 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
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
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
>> loadi
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
ait 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.
>
>
>> > > > Warn
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
y as possible.
> > > > Warner is acting in good faith. He's just trying to balance many
> demands
> > > > in a compressed time period.
> > > >
> > > > Cheers.
> > > > -M
> > > >
> > > >
> > >
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
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 comp
;
> > 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, a
.
> -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
>
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/module
="/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
> Author: emaste
> Date: Tue Jun 26 16:50:41 2018
> New Revision: 335672
> URL:
> https://svnweb.freebsd.org/changeset/base/335672
>
>
> Log:
> Build linprocfs and linsysfs also on arm64
>
> Sponsored by: Turing Robotic Industries
>
> . . .
https://ci.freebsd.org/job/FreeBSD-head
n't boot, because of the fact that it didn't recognise
>> the MBR
>> > >> > partitions (it only had a single diskid entry on the mount-root
>> prompt).
>> > >> >
>> > >> > Can anyone explain to me how these kernel options work,
on the mount-root
> prompt).
> > >> >
> > >> > Can anyone explain to me how these kernel options work, as in: they
> are
> > >> > defined in kernel configs and as a consequence in opt_geom.h, but
> how
> > >> are
>
f the fact that it didn't recognise the MBR
> >> > partitions (it only had a single diskid entry on the mount-root prompt).
> >> >
> >> > Can anyone explain to me how these kernel options work, as in: they are
> >> > defined in kernel configs
ain to me how these kernel options work, as in: they
are
> >> > defined in kernel configs and as a consequence in opt_geom.h, but how
> >> are
> >> > they actually used to select which geom_part_* modules/kernel parts
to
> >> > build? I thought these o
1 - 100 of 701 matches
Mail list logo
