tree. Otherwise a 5.2 version of getifaddrs(2) gets errors.
This makes the 5.2 version of ifconfig(8) behave the same on both
NetBSD-8 and -current. HOWEVER, both of them print nothing (for
``ifconfig -l'' command) so there's still a bug somewhere.
As reported originally by der Mouse.
<subsystem>_<function>_<version>_hook
NFCI
XXX Note that although this introduces a change in the kernel-to-
XXX module interface, we are NOT bumping the kernel version number.
XXX We will bump the version number once the interface stabilizes.
to allow conversion of the ioctl cmd --> ncmd
Should address issue reported by msaitoh@ on irc as well as via e-mail
from Patrick Welche and Ryo ONODERA.
entry point (such as ioctl) instead.
- Attempt to autoload the module before using it.
Naming: Should the names of the hooks be:
<category>_<version>_<function>_hook_t
or:
<category>_<function>_<version>_hook_t
We should make those consistent.
These structs don't have padding but safer to keep the code
structured the same way between the various ntp_gettimes in case
anyone makes more copypasta of it for future updates.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q
Discussed on tech-toolchain@
XXX: pullup 8
1. alignment was wrong for > 1 message
2. macros were doing incorrect pointer comparisons, fortunately ending
the iteration early after the fists cmsg instead of crashing.
3. don't output 32 bit ktrace records for cmsg. 32 bit programs running
under emulation on 64 bit systems should produce 64 bit ktrace records
so that the native ktrace can handle the records; remove extra arguments
that are now not needed (the 32 bit msghdr).
4. output the correct type for cmsg trace records.
5. output all the cmsg records in traces instead of just the first one.
Welcome to 8.99.15 because of the argument removal.
XXX: Really all the code should be changed to use the CMSG_{FIRST,NXT}HDR
macros...
The sockargs refactoring broke it, because sockargs only works with a user
address. Added an argument to sockargs to indicate where the address is
coming from. Welcome to 8.99.14.
belongs.
Update the code to invoke the two routines compat_cvtcmd() and
compat_ifioctl() through indirect pointers. Initialize those
pointers in sys/net/if.c and update them in the compat module's
initialization code.
Addresses the issue pointed out in PR kern/51598
The former location gets included in both libcompat and the compat
module, leading to redefined symbols when the module is loaded. By
moving it to the main Makefile, it gets included only in libcompat.
XXX This still isn't an ideal solution, but it will suffice until
XXX PR kern/51598 is addressed.
build for one of the XEN kernels.
Adding it back to the list. At least the build will be successful.
XXX This is probably not the end of this saga, as we still have the
XXX redefined-symbol issue when loading the compat module on amd64.
XXX But for now, a working build for the vast majority of users
XXX (including our automated test suites) is more important than a
XXX successfully-loadable compat module.
to compat_cvtcmd() in if.c. Ideally, if.c would be modified to have
a pointer to a no-op compat_cvtcmd() and that pointer would get
replaced by compat_modcmd(MODULE_CMD_INIT, ...) code. But for now,
just don't include it in the compat module at all.
- Share lists between the libcompat and module makefiles.
- Include some omitted entries in compat.kmod:
. if_43.c
. kern_sa_60.c
. kern_time_30.c
. rndpseudo_50.c
. rtsock_14.c
. rtsock_50.c
. rtsock_70.c
. uipc_syscalls_40.c
. uipc_syscalls_50.c
- Exclude a (harmless) spurious entry in sysv_ipc.kmod on LP64 systems:
. kern_ipc_10.c
Should fix broken ifconfig on modular current kernels.
ok pgoyette
This change makes struct ifaddr and its variants (in_ifaddr and in6_ifaddr)
MP-safe by using pserialize and psref. At this moment, pserialize_perform
and psref_target_destroy are disabled because (1) we don't need them
because of softnet_lock (2) they cause a deadlock because of softnet_lock.
So we'll enable them when we remove softnet_lock in the future.
The change ensures that ifnet objects in the ifnet list aren't freed during
list iterations by using pserialize(9) and psref(9).
Note that the change adds a pslist(9) for ifnet but doesn't remove the
original ifnet list (ifnet_list) to avoid breaking kvm(3) users. We
shouldn't use the original list in the kernel anymore.
were vaguely useful back when we didn't run make -j, but now you end
up with a single line "done" every so often, with no idea what it is
for. very few other targets claim they're done so just remove these.
drive instead of its associated vfsops. Makes it more friendly, and allows
compat binaries to autoload VFS modules if needed.
sent on tech-kern@, ok christos@
gets handled properly even in built-in module case.
XXX
Whatever was I thinking when I put those conditionals in? And wouldn't it
be a wonderful thing to have some atf regression tests to actually catch
errors in the compat{,_sysv} modules? :)
For monolithic kernels, both modules will be compiled as "built-ins",
while modular environments will be able to load the SYSVSEM, SYSVSHM,
and SYSVMSG code independant from the rest of compat.
This is a necessary precursor step to making the "STD" SYSV* code
into a separate module.
Tested in both monolithic and modular environments with no errors
seen.
