In D21382#465307, @jhb wrote:This stuff is a bit too fragile in general, but if I fixed it, I would do a larger rototill by having MODUL_DEPEND only specify the version it is compiled against and then having modules advertise the versions they have compatible shims for (so instead of modules trying to guess a __FreeBSD_version range of kernels they are compatible with, the kernel would say which range of values it could handle modules from, and to handle things like virtual box and drm-kmod that want to use VM internals we might have a freebsd_vm "module" for which kernels advertise a smaller compatible range).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Aug 23 2019
Aug 23 2019
D21385: Use makefs -t msdos in make_esp_file is now accepted and ready to land.
This looks good to me.
Some functionality like this is needed, since we need to have some way to try again later. It isn't like the interrupt delay we need for things like disk drives because there's no signal to try again like there is when we turn on the interrupts...
If we wanted to avoid the race between device_delayed_attach() and device_attach, we could have device_attach return EAGAIN, per the changes I suggested.
this generally looks good. a couple of nits.
Turn off -Werror for gcc 4.2.1 for userland
Turn off -Werror for gcc 4.2.1
add Turn off -Werror for gcc 4.2.1 for userland
Passes MALTA kernel build.
Passes MALTA64 kernel build.
Passes powerpc GENERIC build.
Aug 22 2019
Aug 22 2019
When we have errors resetting the device before we allocate the
We need to define version 1 of nvme, not nvme_foo. Otherwise nvd won't
Move releasing of resources to later
In D16698#461247, @wulf wrote:Hi @marc.priggemeyer_gmail.com,
I wrote iicbus(4) extension which performs ACPI-based enumeration of I2C devices connected to a controller. It is not limited to HID devices and fires at iicbus attach stage.
The extension walks through ACPI children of I2C controller and for each device found it:
- Creates iicbus child device
- Adds I2C address to ivars
- Adds ACPI-handle to iicbus-child ivars, so you can evaluate acpi_get_handle(dev); on iicbus child
- Copies all newbus resources from corresponding ACPIbus-hosted device to I2Cbus-hosted one.
It effectively makes a copy of existing ACPI device on top of I2C bus.
It should also fix ig4 bug that brokes allocation of interrupts on ig4 children (Only partially tested yet, I have access only to GPIO devices now)I think using of this extension should eliminate nasty ACPI<->I2C devices interaction that is found in the patch from current review.
iicbus(4) extension support in my driver (for reference): https://github.com/wulf7/iichid/commit/6f5c3d3eb008848ab9d18e1dcf8fd35ca80e517ePatch could be found here: https://people.freebsd.org/~wulf/acpi_iicbus.patch
D21330: mips: hide regnum definitions behind _KERNEL/_WANT_MIPS_REGNUM is now accepted and ready to land.
I'm cool, though I'd like to think about having mips share more of the .S's with libc and have good ifdefs there.
imp added inline comments to D21330: mips: hide regnum definitions behind _KERNEL/_WANT_MIPS_REGNUM.
We're getting enough of these that perhaps a refactor may be in order at some point...
But this is fine for now.
Remove stray line that was duplicated.
Document Intel RST support just added
Aug 21 2019
Aug 21 2019
D21264: Fix universe to include arm LINT kernel configs. is now accepted and ready to land.
This looks good to me.
Document RST support in nvme(4) and ahci(4).
Separate the pci attachment from the rest of nvme
Create a AHCI attachment for nvme.
D21353: Export OFW PCI resource allocation methods is now accepted and ready to land.
OK. Other than the updating the comments, I'm convinced this is a good thing.
Nesting is there as a sanity check when you try to create an inner container at offset 0, you don't recurse with the outer container somehow... Does this run afoul of that?
Aug 20 2019
Aug 20 2019
D21334: Fix s" word in Ficl to account for memory used by the string literal is now accepted and ready to land.
If we do it for other things, I'm cool with this going in...
one last nit.
Still object to copying, but since no progress on de-dupe has been made and there's been a 2 year lag, I accept it's the last bad choice to move this forward.
imp added a comment to D21334: Fix s" word in Ficl to account for memory used by the string literal.
Won't this slowly eat all memory as we run through loops with s" in them?
D21330: mips: hide regnum definitions behind _KERNEL/_WANT_MIPS_REGNUM is now accepted and ready to land.
Aug 19 2019
Aug 19 2019
In D21297#463778, @luporl wrote:In D21297#463774, @imp wrote:In D21297#463764, @luporl wrote:I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:.if ${MACHINE_ARCH} == "powerpc64" SRCS+= cas.c CFLAGS+= -DCAS .endifIt seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64" SRCS+= cas.c CFLAGS+= -DCAS .endifBut I'm also fine with just removing the if block.
TARGET_ARCH isn't a thing you can test anywhere outside of Makefile.inc1, so this suggestion can't be right. In the cross build case, we always set MACHINE_ARCH correctly.
Ok, but then the following use case is not supported, right?
cd /usr/src/stand && make TARGET=powerpc TARGET_ARCH=powerpcBecause the following command outputs "powerpc64":
In D21297#463764, @luporl wrote:I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:.if ${MACHINE_ARCH} == "powerpc64" SRCS+= cas.c CFLAGS+= -DCAS .endifIt seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64" SRCS+= cas.c CFLAGS+= -DCAS .endifBut I'm also fine with just removing the if block.
Aug 18 2019
Aug 18 2019
it looks to my eye that all prior comments had been addressed...
generally I like this. Couple of minor spacing nits, and a question about a possible improper use of KASSERT
Aug 17 2019
Aug 17 2019
Fix small bug in wrapping introduced in r325955.
Add nowerror and local to the list of tokens.
Move initializations of config earlier.
D21297: Fix loader on powerpc32 is now accepted and ready to land.
This does what the comment says it does... I'm not qualified too know if that's actually the right thing to do or not.
D21296: Remove some compatability with Seventh Edition UNIX realloc(). is now accepted and ready to land.
This is good, and good commit message. V7 was released 40 years ago this past January. It flourished in the late 70s and early 80s as a platform people ported to (I'm aware of maybe a dozen such ports too 4 or 5 different architectures)... then all those ports migrated to System III or System V by maybe 1989 or so. The last time I saw this software pattern was in the mid 90s when I updated the program in question to not do that.... I doubt this code path has been execute in the last decade or two except by pedants testing V7 compatibility.
Aug 16 2019
Aug 16 2019
D20562: The efifat files are no longer used: remove the code to build them. is now accepted and ready to land.
kill them with fire :)
D21293: Fix compilation of kernels with usb and fdt enabled, but no miibus is now accepted and ready to land.
Ah, I see where it's used now. There are several alternatives, but this is the least bad one that comes to mind.
We have a little bit of dead code vs having #ifdefs for FDT in usb_ethernet.c.
It's more modular to have it like this, so I'm cool with it.
looks fine as far as it goes, but what's including this? usb_ethernet.c certainly needs miibus too compile...
imp added a comment to D21060: Stop installing clang, clang++, and clang-cpp hardlinks in /usr/bin..
In D21060#462958, @kib wrote:In D21060#462930, @imp wrote:I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).
See below.
And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.
I stated that exp run is required after the discussion is finished. I see no reason to ask portmgr to spend their time unless there is a clear route to commit the change.
WRT to optional symlinks, I am fine with it as far as defaults are to not have them. The reason for this change is to remove the surprise and the need to answer 'why' questions for people that start developing on FreeBSD. The same group of people are proficient in Linux and they do not have to manipulate $PATH or create symlinks in ~/bin because 'this is how FreeBSD happens to not-handle it' for all the time (it == conflict between base and ports binaries). If symlinks are on by default, this change does not worth the time.
D21291: stand: fix build with xtoolchain-llvm90 is now accepted and ready to land.
looks great to me.
ah, enough searching and I see that it is.
well, it could be in the files, but it's unambiguous enough. I assume this is how it is upstream?
D20653: Import spleen bitmap fonts to contrib/ is now accepted and ready to land.
This detached license is basically required since bdf files don't have a good way to add it.
D21060: Stop installing clang, clang++, and clang-cpp hardlinks in /usr/bin. now requires changes to proceed.
I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).
D21286: Loader: Add load offset to powerpc kernel entry point now requires changes to proceed.
D21282: stand: fix build with xtoolchain-llvm90 is now accepted and ready to land.
I think this is fine.... Not 100% sure, but I think we'll be good. The time may be here to always link in libsa.a, but if you don't *NEED* that, then let's not go there yet. the day will come though...
OK. Not really worth optimizing then. Thanks for the feedback.
Seems sane enough...
Aug 15 2019
Aug 15 2019
Catch mkheaders.c up to the removal of counted device support in 2005.
Sort getopt(3) options and case statements per style(9)
In D11115#462518, @emaste wrote:side by side comparison with the .o generated
Looking at boot1.o differences there are lots of header, debug, etc. changes, and changes due to differing offsets. The real change is different instruction size for the test instruction at the beginning of read
read: testb $FL_PACKET,%cs:MEM_REL+flags-start # LBA support enabled?GNU as produces
0000:012e 2e f6 06 b0 08 80 test byte cs:[0x8b0], 0x80 ; [0x8b0:1]=255 ; 128While Clang IAS produces:
0000:012e 2e 67 f6 05 b3 08 00 00 80 test byte cs:[0x8b3], 0x80 ; [0x8b3:1]=255 ; 128This is fine for boot2, other than using three bytes more than necessary.
had the same thing in mind
Aug 14 2019
Aug 14 2019
Move all the hp* drivers too files.x86
imp committed rS351053: Move the common x86 ipmi files to files.x86. The powerpc file list is different.
Move the common x86 ipmi files to files.x86. The powerpc file list is different
Windows ndis support is x86 only. Move the MI parts there.
The x86 part of hwpmc is shared, so move it to files.x86.
Intel's isci is part of the chipset, so it is x86 specific.
imp committed rS351048: The bxe driver, QLogic NetXtreme II Ethernet 10Gb PCIe adapter driver, is x86.
The bxe driver, QLogic NetXtreme II Ethernet 10Gb PCIe adapter driver, is x86
The ACPI parts are identical between i386 and amd64
Move via padlock files to files.x86.
Apart from one MD file, aesni is common to x86. Move it into files.x86.
Move the identical x86 lines to files.x86
Aug 13 2019
Aug 13 2019
D21256: Stop listing "on motherboard" as the parent of nexus devices on x86. is now accepted and ready to land.
P,S, I don't know the clicky button to say this is no longer blocked by core@, so don't let that stop you from committing it.
Alternatively, you could add a explicit reference to the location of the license file in FreeBSD's repo in the .c and .h. That would be fine enough.
In D18613#462036, @jpaetzel wrote:@vbhakta_vmware.com is there anything I can do to facilitate the changes this driver needs to get it into the tree?
D21249: Remove deprecated GEOM classes is now accepted and ready to land.
time to go... but need to remove from files and double check to make sure there's no lingering man page Xr's.
r350976 accidentally removed nvram device. Restore it.
vx(4) was removed in r347921. Remove stray reference.
Flowtables were removed in r321618, remove stray reference here.
nsp(4) was removed in r339571. Remove stray reference.
imp committed rS350982: fe(4) driver has been removed from the tree in r347914. Remove stray reference..
fe(4) driver has been removed from the tree in r347914. Remove stray reference.
minor comment fixing.
In D21248#461858, @jhb wrote:There were several other things that looked like they were also identical (e.g. several agp drivers, all the atkbdc stuff, acpi_wmi_if.m). Those can be followup commits though.