221855 |
13-May-2011 |
mdf |
Move the ZERO_REGION_SIZE to a machine-dependent file, as on many architectures (i386, for example) the virtual memory space may be constrained enough that 2MB is a large chunk. Use 64K for arches other than amd64 and ia64, with special handling for sparc64 due to differing hardware.
Also commit the comment changes to kmem_init_zero_region() that I missed due to not saving the file. (Darn the unfamiliar development environment).
Arch maintainers, please feel free to adjust ZERO_REGION_SIZE as you see fit.
Requested by: alc MFC after: 1 week MFC with: r221853
|
164033 |
06-Nov-2006 |
rwatson |
Sweep kernel replacing suser(9) calls with priv(9) calls, assigning specific privilege names to a broad range of privileges. These may require some future tweaking.
Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov <umka at sevcity dot net>, Skip Ford <skip dot ford at verizon dot net>, Antoine Brodin <antoine dot brodin at laposte dot net>
|
132956 |
01-Aug-2004 |
markm |
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
|
93496 |
31-Mar-2002 |
phk |
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates enough of the old savecores features to do the job, but implements none of the options yet.
I would appreciate if a userland hacker could help me out getting savecore to do what we want it to do from a users point of view, compression, email-notification, space reservation etc etc. (send me email if you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in /etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but looking at the i386 version it should be trivial for anybody familiar with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set the device as dumpdev. To implement the "off" argument, /dev/null is used as the device.
Savecore will fail if handed any options since they are not (yet) implemented. All devices marked "dump" or "swap" in /etc/fstab will be scanned and dumps found will be saved to diskfiles named from the MD5 hash of the header record. The header record is dumped in readable format in the .info file. The kernel is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to improve and extend.
Sponsored by: DARPA, NAI Labs
|
62052 |
25-Jun-2000 |
markm |
New machine independant /dev/null and /dev/zero driver. This device is severely stripped down compared with its predecessor, and is measurably a _lot_ faster.
Many thanks to Jeroen van Gelderen for lots of good ideas.
There is still a problem with this; it is written as a mudule, and as such is theoretically unloadable. However, there is no refcounting done as I would prefer to do that a'la device_busy(9), rather than some "home-rolled" scheme. The point is pretty moot, as /dev/null is effectively compulsory.
Reviewed by: dfr
|