| #
71625ec9
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c comment pattern
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
| #
d65427ad
|
| 27-Dec-2020 |
Marius Strobl <marius@FreeBSD.org> |
sym(4): Remove remainder of SYM_SETUP_LP_PROBE_MAP support
Missed in 221ac8f4cd823a2b047c2807e2cf744c7176dd1f and r339575 respectively.
|
| #
cd853791
|
| 28-Nov-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pag
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value.
Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work.
Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav.
Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225
show more ...
|
| #
71625ec9
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c comment pattern
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
| #
d65427ad
|
| 27-Dec-2020 |
Marius Strobl <marius@FreeBSD.org> |
sym(4): Remove remainder of SYM_SETUP_LP_PROBE_MAP support
Missed in 221ac8f4cd823a2b047c2807e2cf744c7176dd1f and r339575 respectively.
|
| #
cd853791
|
| 28-Nov-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pag
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value.
Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work.
Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav.
Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225
show more ...
|
| #
718cf2cc
|
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
| #
23090366
|
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
| #
de720122
|
| 15-Jul-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r236710 through r238467.
|
| #
6cf87ec8
|
| 13-Jul-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @238412.
|
| #
b652778e
|
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
| #
2d5e7d2e
|
| 30-May-2012 |
Will Andrews <will@FreeBSD.org> |
IFC @ r236291. Diff reductions to the enclosure driver made in r235911.
|
| #
31ccd489
|
| 28-May-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r236168.
|
| #
718cf2cc
|
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
| #
23090366
|
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
| #
de720122
|
| 15-Jul-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r236710 through r238467.
|
| #
6cf87ec8
|
| 13-Jul-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @238412.
|
| #
b652778e
|
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
| #
2d5e7d2e
|
| 30-May-2012 |
Will Andrews <will@FreeBSD.org> |
IFC @ r236291. Diff reductions to the enclosure driver made in r235911.
|
| #
31ccd489
|
| 28-May-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r236168.
|
| #
4bc42357
|
| 14-Jun-2012 |
Marius Strobl <marius@FreeBSD.org> |
Fix a braino in r236469; the number of DMA tags required for handling MAXPHYS should be based on PAGE_SIZE rather than SYM_CONF_DMA_BOUNDARY. While at it, reuse the SYM_CONF_MAX_SG macro for specifyi
Fix a braino in r236469; the number of DMA tags required for handling MAXPHYS should be based on PAGE_SIZE rather than SYM_CONF_DMA_BOUNDARY. While at it, reuse the SYM_CONF_MAX_SG macro for specifying the maximum number of DMA tags so sym(4) itself doesn't size memory beyond what's required for handling MAXPHYS.
PR: 168928 MFC after: 3 days
show more ...
|
| #
21b5913f
|
| 26-May-2012 |
Marius Strobl <marius@FreeBSD.org> |
- When creating the DMA tag for user data, don't ask for more segments than required for handling MAXPHYS and report the resulting maximum I/O size to CAM instead of implicitly limiting it to DFL
- When creating the DMA tag for user data, don't ask for more segments than required for handling MAXPHYS and report the resulting maximum I/O size to CAM instead of implicitly limiting it to DFLTPHYS. - Move the variables of sym_action2() out of nested scope as required by style(9) and remove extraneous curly braces. - Replace a magic value for PCIR_COMMAND with the appropriate macro. - Use DEVMETHOD_END. - Use NULL instead of 0 for pointers.
Tested with a HBA donated by wilko.
MFC after: 3 days
show more ...
|
| #
098ca2bd
|
| 06-Jan-2005 |
Warner Losh <imp@FreeBSD.org> |
Start each of the license/copyright comments with /*-, minor shuffle of lines
|
| #
2a8dc282
|
| 11-Nov-2001 |
Gerard Roudier <groudier@FreeBSD.org> |
MFC after: 0 days
|
| #
c5595f9d
|
| 29-Apr-2000 |
Gerard Roudier <groudier@FreeBSD.org> |
This new version adds support for early NCR chips. 53C810 non 'A', 53C815 and 53C825 non 'A' are now attached by the driver (by default). The driver uses a different SCRIPTS set based on MEMORY MOVE
This new version adds support for early NCR chips. 53C810 non 'A', 53C815 and 53C825 non 'A' are now attached by the driver (by default). The driver uses a different SCRIPTS set based on MEMORY MOVE instructions for these chips.
2 SCRIPTS sets (firmwares) numbered #1 and #2 are used for the whole support of the 53C8XX family to get possible:
- FW #1 : Only based on MEMORY MOVE instructions. Selected for 810, 815, 825. - FW #2 : LOAD/STORE based. This is the firmware also used by previous driver versions. Selected for other chips.
When both `ncr' and `sym' are configured, `sym' will now attach all the 53C8XX devices by default. Previous balancing between `ncr' and `sym' can be preserved by:
- Either editing sym_conf.h and commenting the following compile option: #define SYM_CONF_GENERIC_SUPPORT (This also saves about 3.5Kb of kernel memory).
- Or setting kernel config option SYM_SETUP_LP_PROBE_MAP to 64 (bit 0x40)
show more ...
|