forward or backward by a specified number of tracks (defaulting to 1).
Use strvisx() to display the media catalog in case it contains unprintable
characters. Sort includes. Based on two patches submitted by PR, plus
style fixes and other changes of my own.
Submitted by: Seth Kingsley <sethk@osd.bsdi.com>, Maxime Henrion <mux@qualys.com>
PR: bin/22672, bin/26962
MFC After: 1 week
Add a CAPI (hardware independent) driver i4bcapi(4) and hardware driver
iavc (4) to support active CAPI-based BRI and PRI cards (currently AVM
B1 and T1 cards) to isdn4bsd.
interrupts on other buses. Right now it isn't used, but will be for
the pci attachment.
# Add copyright by me for this year since I've changed so much.
The STLport will probably become broken again, but I'll work on fixing it
later.
I wish someone would explain why the NetBSD Cirtus branch has the types
in their stddef.h...
Requested by: bde, ru
PR: 27606
Submitted by: Naohiko Tsuji <yakisoba@f2.dion.ne.jp>
reason not to add it to others later). This causes the pam_unix
module to check the user's _own_ password, not the password of the
account that the user is authenticating into. This will allow eg:
WHEELSU type behaviour from su(1).
forever. Since the lock file doesn't get cleaned up, this prevents
other users from accessing the target device.
(phk adds: Man, this has been bugging me for YEARS!)
PR: 12528
Submitted by: Craig Leres leres@ee.lbl.gov
MFC after: 1 week
Tor created a while ago, removes the raw I/O piece (that has cache coherency
problems), and adds a buffer cache / VM freeing piece.
Essentially this patch causes O_DIRECT I/O to not be left in the cache, but
does not prevent it from going through the cache, hence the 80%. For
the last 20% we need a method by which the I/O can be issued directly to
buffer supplied by the user process and bypass the buffer cache entirely,
but still maintain cache coherency.
I also have the code working under -stable but the changes made to sys/file.h
may not be MFCable, so an MFC is not on the table yet.
Submitted by: tegge, dillon
o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_PCMCIA and
programming interface is 0, assume that it is a generic PCMCIA PCI
chip we can program. I don't think there are any of these that
we don't know about, but you never know.
o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_CARDBUS and
programming interface is 0, assume that it is a YENTA cardbus bridge
that we know how to cope with. There are likely some cardbus bridges
that haven't it made it in here yet.
pcic_{get,put}b_io. There are some pci bridges (the CL-PD6729 and
maybe others) that do not have memory mapped registers, so we'll need
these in both places. Declare them in pcicvar.h.
