are duplicated by newly defined types/options in RFC3121
- We have no backward compatibility issue. There is no apps in our
distribution which use the above types/options.
Obtained from: KAME
MFC after: 2 weeks
lock. We now use temporary variables to save the process argument pointer
and just update the pointer while holding the lock. We then perform the
free on the cached pointer after releasing the lock.
. staticize out_fdc(), there's no longer an ft(4) driver sharing its use
. remove in_fdc(), has been used by ft(4) last time, long since obsoleted
by fd_in()
. move the declaration of fd_clone() to where most of the other function
declarations are
. de-__P()ify fd_clone(), it's been the only _P()ed function in the
entire file
something: offset into the first mbuf of the target chain before copying
the source data over.
Make drivers using m_devget() with a first argument "data - ETHER_ALIGN"
to use the offset argument to pass ETHER_ALIGN in. The way it was previously
done is potentially dangerous if the source data was at the top of a page
and the offset caused the previous page to be copied (if the
previous page has not yet been appropriately mapped).
The old `offset' argument in m_devget() is not used anywhere (it's always
0) and dates back to ~1995 (and earlier?) when support for ethernet trailers
existed. With that support gone, it was merely collecting dust.
Tested on alpha by: jlemon
Partially submitted by: jlemon
Reviewed by: jlemon
MFC after: 3 weeks
the console device was open. At other times, the interrupts that
are used to detect the break signal or ~^B sequence were disabled,
so these events would not be noticed until the next open (e.g. the
next kernel printf). This was mainly a problem while there was no
getty running on the console, such as during bootup or shutdown.
For serial consoles with break-to-debugger support, we now enable
the generation of interrupts at attach time, and we leave them
enabled while the device is closed.
Reviewed by: bde (I've since made chages as per his suggestions)
via the new DIGIIO_SETALTPIN ioctl, and allow the port's ALTPIN setting
to be queried via DIGIIO_GETALTPIN.
The initial state and lock devices are normally used to set and/or
lock ALTPIN settings although the device itself may also be used.
ALTPIN settings are applied per-device and apply to both the callin
and callout device at the same time.
sizeof(ro_dst) is not necessarily the correct one.
this change would also fix the recent path MTU discovery problem for the
destination of an incoming TCP connection.
Submitted by: JINMEI Tatuya <jinmei@kame.net>
Obtained from: KAME
MFC after: 2 weeks
of tunclose() rather than the end, and tunopen() grabbed that unit
before tunclose() finished (one process is allocating it while another
is freeing it!).
It may be worth hanging some sort of rw mutex around all specinfo
calls where d_close and the detach handler get a write lock and all
other functions get a read lock. This would guarantee certain levels
of ``atomicity'' (is that a word?) that people may expect (I believe
Solaris does something like this).
requirements(RFC1573, interface MIB). This change for 4.4BSD was
first introduced in if_ethersubr.c:1.17->1.18.
BTW, iflastchange on all of IFs are inconsistent. e.g.
ether, tun: update
fddi, tokenring, ppp: not update
I'll make patch later.
Obtained from: KAME
MFC after: 2 weeks
converting from the old external mbuf buffer code to the new (with the
MEXTADD() macro). Also free free list memory correctly in
foo_free_jumbo_mem() routines: grab the head of the list, then
remove it, _then_ free() it.
This fixes the memory corruption problem I've been chasing in the level 1
driver.
and its associated constants. Implement _SC_IOV_MAX in the usual way.
Be a bit sloppy about the namespace question; this should get cleared up
in time for 5.0.
MFC after: 1 month
startup routine more closely matches that of alpha and ia64. At some
point the common mutexes shared across all platforms probably should move
into sys/kern_mutex.c.
trace code that was brought over from NetBSD.)
- Check for "syscall_with_err_pushed" as the label prior to a syscall trap
frame rather than "Xlcall_syscall" and "Xint0x80_syscall". We don't
have a valid trapframe during the short range of code that those two
symbols now cover.
- Simplify db_next_frame() to avoid duplicating the code for the different
trap frame types.
- Don't try to trace a swapped-out process. (Brought over from NetBSD via
the new alpha trace code.)
1.307 Turn on kernel debug support
1.309 Turn off pcm
1.311 move wx to miibus chipsets
1.312 Comment out USERCONFIG
Reminded by: mihira-san <sanpei@sanpei.org>