2. Instead, open /dev/tty. This problem stopped commands in subshells from
being executed correctly if standard error was redirected.
PR: 36671
Obtained from: NetBSD (but simplified)
NOTES. Add some comments about the potential problems associated with NIC
driver modules and changing these options.
Fix sorting problems in sys/conf/options with the MSIZE and MCLSHIFT
options.
Reviewed by: bde
This code does not imply that SBus cards work yet. They hang for me.
But I can't netboot the latest snapshot on my ultra1e, and things
hang at bus_setup_intr time.
Since I'm offline for a while, I thought I'd toss this in in case somebody
else who has a bit better luck wants to fart around with it. Please try
and wait until I get back to check things in.
warn*(), and setproctitle() functions) to buildworld work again. This
can be cleaned up later if/when a new GCC supports the feature (but personally
I think it's a waste of time to keep mod'ing imported GCC sources for this
since only three procedures are involved).
Suggested by: peter
and kmem_free_wakeup(). Previously, kmem_free_wakeup() always
called wakeup(). In general, no one was sleeping.
o Export vm_map_unlock_and_wait() and vm_map_wakeup() from vm_map.c
for use in vm_kern.c.
the default) is now the only method for i386.
Remove the paraphanalia that supported critmode. Remove td_critnest, clean
up the assembly, and clean up (mostly remove) the old junk from
cpu_critical_enter() and cpu_critical_exit().
This allows accton(1) to be used with an append-only file.
PR: 7169
Reported by: Joao Carlos Mendes Luis <jonny@jonny.eng.br>
Reviewed by: bde
Approved by: sheldonh (mentor)
MFC after: 2 weeks
methodology similar to the vm_map_entry splay and the VM splay that Alan
Cox is working on. Extensive testing has appeared to have shown no
increase in overhead.
Disadvantages
Dirties more cache lines during lookups.
Not as fast as a hash table lookup (but still N log N and optimal
when there is locality of reference).
Advantages
vnode->v_dirtyblkhd is now perfectly sorted, making fsync/sync/filesystem
syncer operate more efficiently.
I get to rip out all the old hacks (some of which were mine) that tried
to keep the v_dirtyblkhd tailq sorted.
The per-vnode splay tree should be easier to lock / SMPng pushdown on
vnodes will be easier.
This commit along with another that Alan is working on for the VM page
global hash table will allow me to implement ranged fsync(), optimize
server-side nfs commit rpcs, and implement partial syncs by the
filesystem syncer (aka filesystem syncer would detect that someone is
trying to get the vnode lock, remembers its place, and skip to the
next vnode).
Note that the buffer cache splay is somewhat more complex then other splays
due to special handling of background bitmap writes (multiple buffers with
the same lblkno in the same vnode), and B_INVAL discontinuities between the
old hash table and the existence of the buffer on the v_cleanblkhd list.
Suggested by: alc
- Remove some obsolete code (NetBSD gem.c r1.12)
- Clean up how the local MAC address is programmed (NetBSD gem.c r1.13)
- Make the driver work on PowerMacs with gigabit interfaces
(NetBSD gem.c r1.14 and r1.15, gemreg.h r1.3 and r1.4, gemvar.h r1.6 and 1.7)
- Suppress RX_MAC interrutps regarding the FRAME_COUNT register.
(NetBSD gem.c r1.16 and r1.17)
- Fix receiver lockups. (NetBSD gem.c r1.18, gemvar.h r1.8)
- Distinguish between Apple and Sun variants (NetBSD if_gem_pci.c r1.9)
Reviewed by: tmm
Obtained from: NetBSD
don't use spaces at the beginning of a line where tabs are normally
used (the worst thing was that half of this file was right (tabs) and
half was wrong (spaces), making for painful reading).
Reviewed by: /sbin/md5, diff -b
implemented using a new VT_LOCKSWITCH ioctl. Although it is possible
to implement something like this by VT_SETMODEing to VT_PROCESS and
never releasing the vty, that method has a number of downsides, the
biggest of which is that some program has to stay resident for the
lock to be in effect.
Reviewed by: roam, sheldonh
like this can be emulated by VT_SETMODEing to VT_PROCESS and never
releasing the vty, but this has a number of problems, most notably
that a process must stay resident for the lock to be in effect.
Reviewed by: roam, sheldonh