Changeset View
Standalone View
sys/README.md
FreeBSD Kernel Source: | FreeBSD Kernel Source: | ||||||
---------------------- | ---------------------- | ||||||
This directory contains the source files and build glue that make up the FreeBSD | This directory contains the source files and build glue that make up the FreeBSD | ||||||
kernel and its modules, including both original and contributed software. | kernel and its modules, including both original and contributed software. | ||||||
Source Roadmap: | Source Roadmap: | ||||||
--------------- | --------------- | ||||||
| Directory | Description | | | Directory | Description | | ||||||
| --------- | ----------- | | | --------- | ----------- | | ||||||
| amd64 | AMD64 architecture support | | | amd64 | AMD64 (64-bit x86) architecture support | | ||||||
emaste: Maybe add reference to v6/v7 here? @imp? | |||||||
Not Done Inline ActionsI struggled here. I think 32-bit is a sufficient level of detail for this file, though
would also be good. I think that extra bi tis short enough and clarifying enough that it's good, even if it isn't completely correct (it's really v7 with 1 v6 cpu that has some of the v7 extensions), it's sufficient for the context and short enough to not interfere with the clarity. Though technically, mhorne is right that aarch32 (armv8) is a thing we don't separately support,, that's also generally not a thing that exists that doesn't work with our v7 support w/o taking advantage of the new v8 32-bit features. imp: I struggled here. I think 32-bit is a sufficient level of detail for this file, though
| arm |… | |||||||
| arm | ARM architecture support | | | arm | 32-bit ARM architecture support | | ||||||
Not Done Inline ActionsNote that you can have an ARMv8 AArch32 binary. Maybe "64-bit ARMv8+"? emaste: Note that you can have an ARMv8 AArch32 binary. Maybe "64-bit ARMv8+"? | |||||||
Done Inline ActionsRight, so do we like: 32-bit ARMv6+ architecture support 64-bit ARMv8+ (AArch64) architecture support ? mhorne: Right, so do we like:
```
32-bit ARMv6+ architecture support
64-bit ARMv8+ (AArch64)… | |||||||
| arm64 | ARMv8 architecture support | | | arm64 | 64-bit ARM (AArch64) architecture support | | ||||||
| cam | `cam(4)` and `ctl(4)` | | | cam | Common Access Method storage subsystem - `cam(4)` and `ctl(4)` | | ||||||
| cddl | CDDL-licensed optional sources, including ZFS and DTrace | | | cddl | CDDL-licensed optional sources such as DTrace | | ||||||
| ddb | `ddb(4)` | | | conf | kernel build glue | | ||||||
| fs | most filesystems | | | compat | Linux compatibility layer, FreeBSD 32-bit compatibility | | ||||||
| contrib | 3rd-party imported software such as OpenZFS | | |||||||
| crypto | crypto drivers | | |||||||
| ddb | interactive kernel debugger - `ddb(4)` | | |||||||
| fs | most filesystems, excluding UFS, NFS, and ZFS | | |||||||
| dev | device drivers | | | dev | device drivers | | ||||||
| geom | `geom(4)` | | | gdb | kernel remote GDB stub - `gdb(4)` | | ||||||
Done Inline ActionsI'd be tempted here to say kernel debugger stubs, since it's really a remote frontend rather than a debugger. I think that nuance is easy enough to convey accurately w/o getting too verbose and affecting the clarity of things. imp: I'd be tempted here to say kernel debugger stubs, since it's really a remote frontend rather… | |||||||
| i386 | i386 (32 bit) architecture support | | | geom | GEOM framework - `geom(4)` | | ||||||
| i386 | i386 (32-bit x86) architecture support | | |||||||
Done Inline ActionsIt's really 486 and newer. I think 'i486+ (32-bit x86) architecture support' would express this nicely w/o undue verbosity. imp: It's really 486 and newer. I think 'i486+ (32-bit x86) architecture support' would express this… | |||||||
Done Inline ActionsI would like to note it, but i386 is the colloquial name used throughout the source tree, so it needs to be in there (also in the 'x86' entry below). mhorne: I would like to note it, but i386 is the colloquial name used throughout the source tree, so it… | |||||||
| kern | main part of the kernel | | | kern | main part of the kernel | | ||||||
| net80211 | `net80211(4)` | | | libkern | libc-like and other support functions for kernel use | | ||||||
Done Inline ActionsMaybe add descriptions to these while we're here? E.g. WiFi? Grab the title from the referenced man pages perhaps? emaste: Maybe add descriptions to these while we're here? E.g. WiFi? Grab the title from the referenced… | |||||||
Done Inline ActionsWe might want to mention that this is both 32- and 64-bit emaste: We might want to mention that this is both 32- and 64-bit | |||||||
Done Inline Actionsagreed, but I'd think twice about the longer sub-types beyond that (eg poerpc64le). imp: agreed, but I'd think twice about the longer sub-types beyond that (eg poerpc64le). | |||||||
Done Inline Actionss/libc/libc-like/ maybe? or libc-subset since it's similar / subsetted libc support for the kernel. But I'd not make it much more verbose than that, and would accept that it's fine as is if you don't think this suggestion adds value. I'm finding myself a little torn, but leaning towards 'short addition to better express the nuance' over omitting. imp: s/libc/libc-like/ maybe? or libc-subset since it's similar / subsetted libc support for the… | |||||||
Done Inline Actions64-bitt RISC-V architecture support maybe? We don't have 32-bit support at all and likely never will, but it is a thing that other system call out. imp: `64-bitt RISC-V architecture support` maybe? We don't have 32-bit support at all and likely… | |||||||
| netgraph | `netgraph(4)` | | | modules | kernel module infrastructure | | ||||||
Done Inline Actions
might be less verbose? imp: | modules | kernel module infrastructure |
might be less verbose?
| |||||||
| netinet | `inet(4)` | | | net | core networking code | | ||||||
| netinet6 | `inet6(4)` | | | net80211 | wireless networking (IEEE 802.11) - `net80211(4)` | | ||||||
| netipsec | `ipsec(4)` | | | netgraph | graph-based networking subsystem - `netgraph(4)` | | ||||||
| netpfil | `ipfw(4)` and `pf(4)` | | | netinet | IPv4 protocol implementation - `inet(4)` | | ||||||
| opencrypto | `crypto(7)` | | | netinet6 | IPv6 protocol implementation - `inet6(4)` | | ||||||
| powerpc | PowerPC/POWER architecture support | | | netipsec | IPsec protocol implementation - `ipsec(4)` | | ||||||
| riscv | RISC-V architecture support | | | netpfil | packet filters - `ipfw(4)`, `pf(4)`, and `ipfilter(4)` | | ||||||
| security | `audit(4)` and `mac(4)` | | | opencrypto | OpenCrypto framework - `crypto(7)` | | ||||||
| powerpc | PowerPC/POWER (32 and 64-bit) architecture support | | |||||||
| riscv | 64-bit RISC-V architecture support | | |||||||
| security | security facilities - `audit(4)` and `mac(4)` | | |||||||
| sys | kernel headers | | | sys | kernel headers | | ||||||
| ufs | Unix File System | | | tests | kernel unit tests | | ||||||
| ufs | Unix File System - `ffs(7)` | | |||||||
| vm | virtual memory system | | |||||||
Done Inline ActionsWould adding 'MACH-deriverd' be helpful here? I'm not sure. Even though it's short, maybe it's too confusing and I'm too picky. imp: Would adding 'MACH-deriverd' be helpful here? I'm not sure. Even though it's short, maybe it's… | |||||||
Done Inline ActionsThinking back to when I first started with the source tree, I think I would have found it confusing. Certainly the history is captured properly elsewhere. mhorne: Thinking back to when I first started with the source tree, I think I would have found it… | |||||||
| x86 | code shared by AMD64 and i386 architectures | | | x86 | code shared by AMD64 and i386 architectures | |
Maybe add reference to v6/v7 here? @imp?