1.131 is slightly broken, and I would commit the fix to that here, but it
has been reported that any deviation from the original code is causing
problems with some 82557 chips, causing them to lock hard.
Until those issues have been figured out, going back to the original
code is the best plan.
Frustrated: Silby
so that the data is less likely to be inconsistent if SYSCTL_OUT() blocks.
If the data is large, wire the output buffer instead.
This is somewhat less than optimal, since the handler could skip the copy
if it knew that the data was static.
If the data is dynamic, we are still not guaranteed to get a consistent
copy since another processor could change the data while the copy is in
progress because the data is not locked. This problem could be solved if
the generic handlers had the ability to grab the proper lock before the
copy and release it afterwards.
This may duplicate work done in other sysctl handlers in the kernel which
also copy the data, possibly while a lock is held, before calling they call
a generic handler to output the data. These handlers should probably call
SYSCTL_OUT() directly.
SYSCTL_OUT() from blocking while locks are held. This should
only be done when it would be inconvenient to make a temporary copy of
the data and defer calling SYSCTL_OUT() until after the locks are
released.
1) Define _KERNEL while including sys/time.h to get some function prototypes.
2) Add prototypes and ANSIify definitions.
3) Constness changes.
4) Remove register keyword.
5) Actually return a sensible value from main.
6) Make fread_tail take a void * instead of a char *.
7) Avoid a signedness warning by casting to a size_t. Should be safe
enough 'cos we also check for nonnegativity.
8) Be extra chummy with sigset_t rather than passing a struct to printf
and pretending it is an int.
userland for libc/gmon to compile, so the typedef in <machine/types.h>
isn't good enough. This is really ugly since we end up with the
actual value which uintfptr_t is typedef'd from, in multiple places.
This is bug for bug compatible with the other FreeBSD architectures.
Noticed by: sparc64 tinderbox
those of us who want to figure out how old Jim Mock is, but only want to
type 'calendar -f calendar.freebsd'. This is done in a way that should
be totally backwards compatible with no noticable differences, at all.
Reviewed by: mux
MFC after: 4 weeks
(and make it easier to find stuff for the old ones). I originally put
everything under one "RULE SUBSYSTEM" so it didn't look like devfs(8)
is dedicated to the rule subsystem, but since nobody has any idea what
else might go here, it's not worth confusing people just to save a
little time for someone that might add something rule-unrelated to
devfs(8) in a few years.
Suggested by: sheldonh, phk
