sys: Automated cleanup of cdefs and other formattingApply the following automated changes to try to eliminateno-longer-needed sys/cdefs.h includes as well as now-emptyblank lines in a row.Remov
sys: Automated cleanup of cdefs and other formattingApply the following automated changes to try to eliminateno-longer-needed sys/cdefs.h includes as well as now-emptyblank lines in a row.Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/Remove /\n+#if.*\n#endif.*\n+/Remove /^#if.*\n#endif.*\n/Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/Sponsored by: Netflix
show more ...
sys: Remove $FreeBSD$: one-line .c patternRemove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
sys: Remove $FreeBSD$: two-line .h patternRemove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDThe SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catchup to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDThe SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catchup to that fact and revert to their recommended match of BSD-2-Clause.Discussed with: pfgMFC After: 3 daysSponsored by: Netflix
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas 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 Iwas using misidentified many licenses so this was mostly a manual - errorprone - task.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat the tags are considered only advisory and do not, in any way,superceed or replace the license texts.
- Extract the IODEV_PIO interface from ia64 and make it MI. In the end, it does help fixing /dev/io usage from multithreaded processes.- On i386 and amd64 the old behaviour is kept but multithre
- Extract the IODEV_PIO interface from ia64 and make it MI. In the end, it does help fixing /dev/io usage from multithreaded processes.- On i386 and amd64 the old behaviour is kept but multithreaded processes must use the new interface in order to work well.- Support for the other architectures is greatly improved, where necessary, by the necessity to define very small things now.Manpage update will happen shortly.Sponsored by: Sandvine IncorporatedPR: threads/116181Reviewed by: emaste, marcelMFC after: 3 weeks
Use io(4) for I/O port access on ia64, rather than through sysarch(2).I/O port access is implemented on Itanium by reading and writing to aspecial region in memory. To hide details and avoid misali
Use io(4) for I/O port access on ia64, rather than through sysarch(2).I/O port access is implemented on Itanium by reading and writing to aspecial region in memory. To hide details and avoid misaligned memoryaccesses, a process did I/O port reads and writes by making a MD systemcall. There's one fatal problem with this approach: unprivileged accesswas not being prevented. /dev/io serves that purpose on amd64/i386, soemploy it on ia64 as well. Use an ioctl for doing the actual I/O andremove the sysarch(2) interface.Backward compatibility is not being considered. The sysarch(2) approachwas added to support X11, but support for FreeBSD/ia64 was never fullyimplemented in X11. Thus, nothing gets broken that didn't need more workto begin with.MFC after: 1 week
Remove D_NEEDGIANT from io(4).There is no need to mark this device node to use Giant. The onlyarchitectures that use io(4) (i386 and amd64) only change a flag intd->td_frame, which is only access
Remove D_NEEDGIANT from io(4).There is no need to mark this device node to use Giant. The onlyarchitectures that use io(4) (i386 and amd64) only change a flag intd->td_frame, which is only accessed by curthread.Apart from this change, I think some fishy things may happen when using/dev/io in multithreaded applications. I haven't tested, but looking atthe code, the flag doesn't get cleared when close() is called fromanother thread, but this may not be this important.I'm not removing D_NEEDGIANT from mem(4), because this driver isn'tGiant safe at all (it calls GIANT_REQUIRED).
Remove the unused major/minor numbers from iodev and memdev.Now that st_rdev is being automatically generated by the kernel, thereis no need to define static major/minor numbers for the iodev and
Remove the unused major/minor numbers from iodev and memdev.Now that st_rdev is being automatically generated by the kernel, thereis no need to define static major/minor numbers for the iodev andmemdev. We still need the minor numbers for the memdev, however, todistinguish between /dev/mem and /dev/kmem.Approved by: philip (mentor)
Add module versions.
Break out the MI part of the /dev/[k]mem and /dev/io drivers intotheir own directory and module, leaving the MD parts in the MDarea (the MD parts _are_ part of the modules). /dev/mem and /dev/ioar
Break out the MI part of the /dev/[k]mem and /dev/io drivers intotheir own directory and module, leaving the MD parts in the MDarea (the MD parts _are_ part of the modules). /dev/mem and /dev/ioare now loadable modules, thus taking us one step further towardsa kernel created entirely out of modules. Of course, there is nothingpreventing the kernel from having these statically compiled.