NULL "name" argument to irq_establish indicates that the device will maintain
an evcnt structure for this interrupt. In this case, irq_establish will still
maintain its own count (for DDB machine irqstat), but won't attach it to the
global list.
Change use of ev_group and ev_name to follow guidelines in evcnt(9).
Switch arckbd(4) over to the new arrangements.
This adds support for EtherExpress/16 cards with 16k of RAM, and in the
process adds general support for PIO mode on these cards. This entails
changing the way the i82586 driver handles bus barriers, since it doesn't
allow for strange cases like this.
This has been tested on the i386 port with the 'ix' driver in both
16KB (which was the source of the problem) and 32KB modes, as well
as with the 'ef' driver. I've tested it (briefly) with 'ei' on arm26
as well. In theory, drivers other than 'ix' should follow precisely the
same code paths as before.
following links, hence is usable for checking of presence of a symlink.
Also slighly cleanup EXISTS and CREAT cases - use symbolic constants
instead of 0/1.
This is needed for emulation of readlink(2), lchown(2) and similar.
Addresses kern/11757.
do not return junk data in mbuf (= sockaddr on accept(2)'s 2nd arg).
set the length zero.
behavior checked with bsdi and freebsd.
partial solution to PR 12027 and 10698 (need more investigation).
and link it directly to db_command_table[] so that it's not necessary
to do this at runtime. Make db_machine_command_table[] const on all ports.
g/c now unneded stuff, like db_machine_commands_install(), db_machine_init()
Patch written by enami.
and number of ops, not touch anything - vnode_if.sh now generated
proper offset numbers; vfs_op_check() is only defined and called for DEBUG
kernels
constify extern declaration of vfs_op_descs[]
g/c vfs_opv_numops, use VNODE_OPS_COUNT instead
make vfs_opv_init_explicit() and vfs_opv_init_default() static
then don't need to be patched at runtime
add new define VNODE_OPS_COUNT (to vnode_if.h) so that the number is known
at compile-time
make stuff const, it now can be
Because zeroing them causes zero division panic with devices which don't
support 8kHz mulaw, and the effect of this line was to force calling
audio_calcwater even when unnecessary.
since we do not have feedback mechanism from path MTU to tunnel MTU
(not sure if we should), and inner packet source will not get informed of
outer PMTUD (we shouldn't do this), 1.15 behavior can lead us to
blackhole behavior.
configurable behavior (as suggested in RFC2401 6.1) would be nice to have,
however, reusing net.inet.ipsec.dfbit would be hairy.
