BSD Commit Log Search

   remove unnecessary check in post-order; this is handled elsewhere

   when '-i[rR]' is given, prompt the user for examination of directories as well as for removal

   Previously, interactively and recursively removing a directory hierarchy
   did not iteratively prompt the user for confirmation for both descending
   into as well as removing directories.

   This uses the patch suggested by rvp at SDF.ORG on tech-userlevel back in
   February to more closely match the behavior of macOS and Linux as well
   as user expectations.

   fix RDTSC issue.

   Diable a few options unlikely to be all that useful on a NeXT:
   - COMPAT_NOMID, COMPAT_SUNOS
   - file-system MFS (TMPFS is preferred)
   - dse, se (SCSI Ethernet)
   - sl (SLIP), ppp / pppoe

   Shrinks the kernel by ~167KB.

   Add 68030 versions of the TT register values that are needed to
   enable the MMU.

   This *should* make 68030 NeXTs "just work".

   Update current testing status.

   Switch next68k to the new pmap by default.

   Add a new pmap_bootmap flag, "CWT", which says to create a static mapping
   with write-through caching.

   Fix inverted "cacheable" logic in the __HAVE_NEW_PMAP_68K case.

   With this fix, my 68040 NeXTstation boots diskless multi-user with
   the new pmap.

   Properly account for the display frame buffer in machine_bootmap[].

   New pmap now at least get close to single-user on my slab.  Issue
   with Ethernet driver?

   new thread cryptodev test

   Add a threaded test to test for races in cryptodev.

   Use pmap_{pa_has,va_is}_static_mapping() rather than hard-coding the
   VIRT68K TT ranges.

   Introduce new functions:
   - pmap_pa_has_static_mapping() -- Does the specified physical address
     range have a static mapping (either TT or allocated in pmap_bootstrap1())?
   - pmap_va_is_static_mapping() -- Is the specified virtual address range
     one of those static mappings?

   These platforms don't yet have the necessary changes to use the new
   68k pmap, but declare an empty machine_bootmap[] for a future change
   to shared code that will reference it.

   Remove __HAVE_NEW_PMAP_68K for declaring machine_bootmap[].

   Fix previous; the old cpuspeed was in MHz by the end of cpu_startup(),
   not MHz*10 (despite being MHz*10 earlier in startup).

   Also, don't const-fold by hand; let the compiler do it so that it's
   more obvious what is going on.

   Oops, <m68k/mmu.h> isn't needed by user-land.  Include it when _KERNEL
   only.

   Fully duplicate the pmap_bootmap definitions from the new 68k pmap
   module to simplify the transitional phase and faciliate some future
   code sharing.

   Adapt to cpuspeed -> cpuspeed_khz changes.

   Add mmu_range_is_tt() helper function that consults the TT register
   configuration to determine if a physical address range is transparently-
   translated for the specified access.

   (missed "cvs add")

   Add mmu_range_is_tt() helper function that consults the TT register
   configuration to determine if a physical address range is transparently-
   translated for the specified access.

   stack(7): tweak diagrams for readability a bit

   lint, make: only enable strict bool mode when using GCC

   The GCC precompiler marks each token whether it comes from a system
   header. Lint uses this information to allow some expressions that aren't
   strictly bool, such as in __predict_true and __predict_false. The Clang
   preprocessor treats all tokens as not coming from system headers, thus
   being too strict.

   Use the new FCNTL mechanism to move blocks to clean segments, rather than
   duplicating the code in user space.  lfs_cleanerd still decides which
   segments' blocks to move but no longer identifies individual blocks
   for cleaning, and does not handle file data.

   Wait to determine inode-block size until the block and fragment sizes have
   been finalized.

   Add ibsize to the summary output.

   stack(7): fix stack base computation

   ok uwe@

   Note release of tz{code,data}2026b

   sysctl(7): document guard size macros