src-test2/usr.bin/modstat, branch release/2.2.8_cvs FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F2.2.8_cvs 1999-01-21T00:55:30Z This commit was manufactured by cvs2svn to create tag 1999-01-21T00:55:30Z cvs2svn cvs2svn@FreeBSD.org 1999-01-21T00:55:30Z urn:sha1:a9e2dc176f709713f9565ed1711c958f0707eb36 'RELENG_2_2_8_RELEASE'. This commit was manufactured to restore the state of the 2.2.8-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs. MFC: doc fixes, enhancements to locate & more, new tail functionality. 1998-07-17T04:21:57Z Jordan K. Hubbard jkh@FreeBSD.org 1998-07-17T04:21:57Z urn:sha1:3d2b5d3d9b22eaf88c8bed2cae02ac8811923614 MFC: correct comment 1998-03-08T12:04:25Z Jordan K. Hubbard jkh@FreeBSD.org 1998-03-08T12:04:25Z urn:sha1:d7e6040dd6afaefaef44f40aacdb56958ffa287c MFC: Lots of cosmetics (plus one gripe from bde about a comment in tail's 1997-09-15T09:20:57Z Jordan K. Hubbard jkh@FreeBSD.org 1997-09-15T09:20:57Z urn:sha1:d253a26a86fb4da73f5914a545a731a1c8235eb6 sources, of all places). MFC: getopt returns -1 not EOF 1997-08-29T05:30:15Z Warner Losh imp@FreeBSD.org 1997-08-29T05:30:15Z urn:sha1:228f50a90c03088066d876b02657d89a13880757 MFC: Cosmetic in usage string. 1997-07-30T06:42:43Z Philippe Charnier charnier@FreeBSD.org 1997-07-30T06:42:43Z urn:sha1:806c6b6bd1ee0f0cd423d6c54d07a2410cec0fe9 YAMFC 1996-12-04T16:12:00Z Poul-Henning Kamp phk@FreeBSD.org 1996-12-04T16:12:00Z urn:sha1:9d0a97d0539e28913d62a92353b727eb61a62e9c Fix a potential buffer overflow condition. 1996-08-08T07:58:07Z Joerg Wunsch joerg@FreeBSD.org 1996-08-08T07:58:07Z urn:sha1:fef1477642f23853674d2f655e867a3f6b8c34b8 Submitted by: Somebody on -hackers, ooops, i've already deleted that mail Setgid kmem not required. 1996-05-30T02:19:03Z Paul Traina pst@FreeBSD.org 1996-05-30T02:19:03Z urn:sha1:73c00cf43fbd6710d910dd7ed8482257e9031c68 Submitted by: smpatel (Sujal Patel) Undo the stupidity I inflicted on these files and replace it with 1995-04-20T05:08:53Z Bill Paul wpaul@FreeBSD.org 1995-04-20T05:08:53Z urn:sha1:de2a1afc4706118d0146e7fcb045c90f9d0b88ec some (hopefully) less offensive stupidity: If we detect that a user has loaded a module that fails to initialize itself correctly, panic. There really isn't a safe way to recover from something like this; we can't know that the module is bad until after the entry point is called, by which time it's too late to do anything about it.