The only in-tree consumer currently looks like the linuxkpi.
This means it's included for all the non-linuxkpi platforms.
This saves a bit of kernel size on embedded platforms which
don't need it.
Details
Details
- Reviewers
cem
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 9342 Build 9805: arc lint + arc unit
Event Timeline
Comment Actions
Except there are plans to use it elsewhere. Many areas may be improved using it.
Having it as a module would mean some devs might refrain from using it because
there is no waranty for it to be there
Areas like VFS and network stack could have a good benefice from using it.
Out of curiousity what size is saved?
Comment Actions
40k on amd64. It looks like quite a bit more (~300k?) on mips, i'll dig later.
It's one of the death-by-a-thousand-cuts that makes it hard to squeeze into the low-cost IoT thingies being made, and I'm trying to arrest some of that growth.
If it gets used elsewhere then great. Right now it's just used in the linuxkpi layer and it only looks like it's being used for the RCU implementation.
Comment Actions
I'd like to have some more in-depth detail on the size issue.
I have no real objection to this but agree with bapt about the signal it gives to other developers, so I'd want there to be an understanding it will go back to being standard when other consumers appear.
Comment Actions
It's used in core kernel code now. To limit size damage, it may be possible to restrict what is built-in on smaller platforms (e.g., do we need anything other than epoch support code?). But I think a module is no longer a useful option, since it will need to be loaded everywhere.