- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 30 2023
Dec 1 2023
Nov 30 2023
Changed iiccopyinmsgs32 to iic_copyinmsgs32, per suggested comments
Addressed comments from jhb
Nov 29 2023
Nov 20 2023
Nov 15 2023
Nov 3 2023
Looks good, verified with the board where we had seen the issue.
Nov 2 2023
Updated to current "main" branch and removed $FreeBSD$ lines
Oct 30 2023
In D42025#967445, @kib wrote:You also need to rename the vars in the summary.
Updated the review summary from the commit log
Updated environment variable to match the variables used internally.
Instead of OPTIONAL_STATIC_TLS, the name is now STATIC_TLS_EXTRA.
Updated the man page also.
Oct 29 2023
Made changes per review comments.
Oct 13 2023
Sep 29 2023
I should also note that we currently have at least one case of this in our source tree currently, which is what prompted the change. It compiles fine with "c99", but does not with "gnu99".
It's going to take some time for the code to be able to be changed to address the issues.
In D42019#958440, @jrtc27 wrote:In D42019#958439, @sjg wrote:In D42019#958437, @jrtc27 wrote:Given conf generates one big Makefile for the entire kernel, and thus CSTD is global for everything compiled into the kernel, I'm unsure how sensible this really is
As already noted, this makefile is used by kernel modules too.
The makefile generated by config(8) is not relevant.Yes, but typically modules can also be compiled into the kernel, where you need to use -std= explicitly. I don't object to it going in, I just don't see it being all that useful.
In D42019#958400, @imp wrote:I've been running with this set to c11....
What do you want to set higher? And what do people think about just inching this up across the board.
Sep 22 2023
Sep 20 2023
Sep 19 2023
In D41674#954474, @imp wrote:This seems fine.
Aug 31 2023
Aug 30 2023
Aug 24 2023
Aug 20 2023
This was committed as rG332af8c25dfc9857e997817281d7b7fa406783ef
Aug 18 2023
Updated to use SIZEOF_LONG check instead of LP64
Updated according to suggestions by Andrew
Aug 17 2023
In D41429#944544, @andrew wrote:It looks like IS_DMA_32B came from when the generic_xhci.c was added as a Marvell specific driver. It looks like it should only be 1 on 32-bit platforms.
Aug 16 2023
Aug 15 2023
Fix typo in the compatible string
In D41429#943512, @andrew wrote:How does Linux handle this? I see the brcm,generic-xchi compat string in u-boot, but not Linux.
Aug 11 2023
Aug 8 2023
Aug 1 2023
Jul 27 2023
In D41207#938522, @kib wrote:In D41207#938511, @mjg wrote:is this really of practical usage today? i was considering removing these printfs to begin with
I agree, better to remove it.
Jun 9 2023
Apr 27 2023
In D39768#906366, @glebius wrote:What's the point of so_checkfiballowed? Can't find it being called. If we bring the processing SO_SETFIB down to protocols, then all protocols that aren't inetsw, inet6sw or routesw will return error just automagically. Where can we need so_checkfiballowed?
Apr 23 2023
In D39768#905218, @melifaro wrote:Conceptually it looks good to me. Please see some implementation-level comments - happy to discuss it further.
Removed includes that are no longer necessary.
Moved setfib syscall to uipc_syscalls.c and just call the callback to check validity of the FIB number
The syscall registration can be removed if sys_setfib is moved to sys/kern, which it should be able to be moved. Since the setting is on the thread itself and there's a callback function for the netstack to be able to veto the FIB number, there's no need for it to live in sys/net/route/route_tables.c now.
Removed the whitespace change in sys/net/route.h
These changes were tested with the test application in tools/regression/sockets/so_setfib
Apr 22 2023
Apr 21 2023
In D39587#904360, @jhb wrote:I think it make sense to keep 8250 as it's definitely an 8250-style UART. Is the custom logic here really confined to Denverton chipsets though and not something that might be present on other chipsets? Given the proliferation of Intel chipset names that are all nearly identical from a software point of view, it seems unlikely for this to really be specific to just one (or is Denverton a reference to a family of chipsets like Atom is for CPUs?)
Apr 20 2023
In D39587#903566, @imp wrote:given how small the dnv8250 driver is, I'm surprised it's not just a simple quirk for the normal driver like half a dozen others.. Seems like a lot of extra mechanism for not a lot of gain.
Added -v flag for verbose mode. Added man page details for the flag.
Added .if !defined(%POSIX)/.endif around RPCGEN setting