identical to the previous incarnation.
- Update using m68k asm.h macros
- Move initialization towards the front of the file
- Rename mac68k_buserr_addr to m68k_fault_addr
- Reorganize trap 15 handler, similar in structure to -- though not as
complete as -- the hp300 version
- Reorganize doboot() for easier integration of external cache, and
make room for the latter (#ifdef __notyet__)
- General garbage collection of unused code/data
Only information leaks now are:
* if '-s -s' is used (only allow s/key users, and force s/key use),
then "login incorrect" will be given if a non-s/key user (or
non-existant user) attempts to login; no password will be prompted
for.
XXX: maybe this should be fixed, but further analysis is required.
* an s/key user will be reminded in the "Password" prompt that they
have an s/key. Therefore it would be possible to determine if a user
is active on the machine if they have an s/key.
XXX: maybe an option is required to control this behaviour
_PASSWORD_WARNDAYS from <pwd.h>). For non-root users, enforce expiry when
it happens. From Simon Gerraty <sjg@zen.void.oz.au> in [bin/935].
* Check for group 0 in process's current group membership (as returned by
getgroups(2)), instead of just looking at the entry for wheel in /etc/group.
Based on code by Dan Caresone <dan@oink.geek.com.au> in [bin/792], and
also solves [bin/2466].
* Clean up to pass -Wall
_buserr point to the 68020/030 buserr code _only_. This has broken access
error handling in the 060 support code.
This is repaired by jumping to _buserr60 from the 060SP, and by providing
a _buserr60 label identical to the _buserr in the unchanged m68k ports
using the 68060.
permission has in VFS; execute permission permission on a directory is ignored
by AmigaDOS: when translating permissions from AmigaDOS to VFS, set up VFS
execute permission for AmigaDOS-readable directories.
Fixes PR kern/3787 from Michael van Elst <mlelstv@serpens.swb.de>.
had not be implemented. It would cause an "adress space leak" and, if
the same object would opened multiple time, unwanted relocations.
Re: Comment from Chris:
"The a.out ld.so has some problems with dlclose. It doesn't properly
unmap objects which are dlclosed. That's a known problem (though a
serious one for programs which dlopen then dlclose lots of objects,
because it causes address space exhaustion), but it has a
previously-unknown side-effect.
If a single object is dlopened, then dlclosed, then dlopened _again_,
the relocations will be processed again. That causes obvious
problems."
scottr