NULL) for now. Bruce says I jumped the gun with my change in
revision 1.131, or maybe it should use nanotime(), or maybe it
shouldn't be decided in the VFS layer at all. I'm leaving it with
the old behavior until the Trans-Pacific Internet Vulcan Mind Meld
yields fuller understanding.
in source input if the -f flag is used, and modify Makefile.yp to only
use -f for the passwd, master.passwd and group maps. These should be
the only ones for which the + and - characters have special meaning
that make it important for us to avoid letting them into any of the map
databases. In some cases (namely the automounter maps) we have to allow
at least the - character through in order to create the map properly.
This closes PR #8699.
`sleep 1; zzz' trick now.
- APM BIOS Call for suspend/standby now should be issued with delay.
- Delay for suspend/standby can be adjusted by using sysctl(8) interface
(eg. sysctl -w machdep.apm_suspend_delay=3).
instead, use generic entry points for all drivers.
- Eliminate bogus makedev().
- Eliminate softc in the lower drivers, as it is no longer necessary.
Submitted (95%) by: phk
keyboard.c
- Call tcsetattr() in VGLKeyboardEnd() to restore tty, only when
tty attributes have been previously saved.
PR: misc/9524
Submitted by: Katusyuki 'kei' Maeda (kei@nanet.co.jp)
- Set up the tty raw mode correctly.
main.c
- Restore VESA_800x600 raster text mode correctly in VGLEnd().
Submitted by: des
text.c
- Allocate the correct size of a font buffer in VGLSetFontFile().
I forgot the submitter ;-(
simple.c, bitmap.c
- Fix address calculation for the VGA mode X in VGLGetXY() and
VGLBitmapCopy().
- Fix typo (dsty -> dstx) in __VGLBitmapCopy().
Reviewed by: sos
by utimes(path, NULL). This gives them the same precision as the
timestamps produced by write operations. Do likewise for lutimes()
and futimes().
Suggested by bde.
have been maintained, and that is still the default. A new sysctl
variable "vfs.timestamp_precision" can be used to enable higher
levels of precision:
0 = seconds only; nanoseconds zeroed (default).
1 = seconds and nanoseconds, accurate within 1/HZ.
2 = seconds and nanoseconds, truncated to microseconds.
>=3 = seconds and nanoseconds, maximum precision.
Level 1 uses getnanotime(), which is fast but can be wrong by up
to 1/HZ. Level 2 uses microtime(). It might be desirable for
consistency with utimes() and friends, which take timeval structures
rather than timespecs. Level 3 uses nanotime() for the higest
precision.
I benchmarked levels 0, 1, and 3 by copying a 550 MB tree with
"cpio -pdu". There was almost negligible difference in the system
times -- much less than 1%, and less than the variation among
multiple runs at the same level. Bruce Evans dreamed up a torture
test involving 1-byte reads with intervening fstat() calls, but
the cpio test seems more realistic to me.
This feature is currently implemented only for the UFS (FFS and
MFS) filesystems. But I think it should be easy to support it in
the others as well.
An earlier version of this was reviewed by Bruce. He's not to
blame for any breakage I've introduced since then.
Reviewed by: bde (an earlier version of the code)
using syslog(3) (log(9)) for its various purposes! This long-awaited
change also includes such nice things as:
* macros expanding into _two_ comma-delimited arguments!
* snprintf!
* more snprintf!
* linting and criticism by more people than you can shake a stick at!
* a slightly more uniform message style than before!
and last but not least
* no less than 5 rewrites!
Reviewed by: committers
PCI fast ethernet controller. Currently, the only card I know that uses
this chip is the D-Link DFE-550TX. (Don't ask me where to buy these: the
only cards I have are samples sent to me by D-Link.)
This driver is the first to make use of the miibus code once I'm sure
it all works together nicely, I'll start converting the other drivers.
The Sundance chip is a clone of the 3Com 3c90x Etherlink XL design
only with its own register layout. Support is provided for ifmedia,
hardware multicast filtering, bridging and promiscuous mode.
should be used from now on for anything security but not auth-related.
Included are updates for all relevant manpages and also to /etc files,
creating a new /var/log/security. Nothing in the system logs to
/var/log/security yet as of the time of this commit.
Reviewed by: rgrimes, imp, chris
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that can
be programmed using an MII interface. It makes sense then to separate
this support out into common code instead of duplicating it in all
of the NIC drivers. The mii code also handles all of the media
detection, selection and reporting via the ifmedia interface.
This is basically the same code from NetBSD's /sys/dev/mii, except
it's been adapted to FreeBSD's bus architecture. The advantage to this
is that it automatically allows everything to be turned into a
loadable module. There are some common functions for use in drivers
once an miibus has been attached (mii_mediachg(), mii_pollstat(),
mii_tick()) as well as individual PHY drivers. There is also a
generic driver for all PHYs that aren't handled by a specific driver.
It's possible to do this because all 10/100 PHYs implement the same
general register set in addition to their vendor-specific register
sets, so for the most part you can use one driver for pretty much
any PHY. There are a couple of oddball exceptions though, hence
the need to have specific drivers.
There are two layers: the generic "miibus" layer and the PHY driver
layer. The drivers are child devices of "miibus" and the "miibus" is
a child of a given NIC driver. The "miibus" code and the PHY drivers
can actually be compiled and kldoaded as completely separate modules
or compiled together into one module. For the moment I'm using the
latter approach since the code is relatively small.
Currently there are only three PHY drivers here: the generic driver,
the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding
others later as I convert various NIC drivers to use this code.
I realize that I'm cvs adding this stuff instead of importing it
onto a separate vendor branch, but in my opinion the import approach
doesn't really offer any significant advantage: I'm going to be
maintaining this stuff and writing my own PHY drivers one way or
the other.
