have been there in the first place. A GENERIC kernel shrinks almost 1k.
Add a slightly different safetybelt under nostop for tty drivers.
Add some missing FreeBSD tags
fields in struct cdevsw:
d_stop moved to struct tty.
d_reset already unused.
d_devtotty linkage now provided by dev_t->si_tty.
These fields will be removed from struct cdevsw together with
d_params and d_maxio Real Soon Now.
The changes in this patch consist of:
initialize dev->si_tty in *_open()
initialize tty->t_stop
remove devtotty functions
rename ttpoll to ttypoll
a few adjustments to these changes in the generic code
a bump of __FreeBSD_version
add a couple of FreeBSD tags
This means that we will not have to have a bpf and a non-bpf version
of our driver modules.
This does not open any security hole, because the bpf core isn't loadable
The drivers left unchanged are the "cross platform" drivers where the respective
maintainers are urged to DTRT, whatever that may be.
Add a couple of missing FreeBSD tags.
for you to be told there was an error [during verbose boot].
I poked him for the fix, he poked me to get it committed.
Submitted by: Jason Young <doogie@anet-stl.com>
there are stubs compiled into the kernel if BPF support is not enabled,
there aren't any problems with unresolved symbols. The modules in /modules
are compiled with BPF support enabled anyway, so the most this will do is
bloat GENERIC a little.
be set by a kernel conf option due to the struct buf structural
dependancy (sizing of b_pages[]) creating a conflict with modules
(which are not compiled with kernel config options overrides).
We'll be able to sysctl these two later on when the buffer subsystem
is revamped.
for the AN985 "Centaur" chip, which is apparently the next genetation
of the "Comet." The AN985 is also a tulip clone and is similar to the
AL981 except that it uses a 99C66 EEPROM and a serial MII interface
(instead of direct access to the PHY registers).
Also updated various documentation to mention the AN985 and created
a loadable module.
I don't think there are any cards that use this chip on the market yet:
the datasheet I got from ADMtek has boxes with big X's in them where the
diagrams should be, and the sample boards I got have chips without any
artwork on them.
spaces which cross a segment boundry in the page table. pmap_kextract()
is not designed for access to the user space portion of the page
table and cannot handle the null-page-directory-entry case.
The fix is to have vm_fault_quick() return a success or failure which
is then used to avoid calling pmap_kextract().
It is about 2.5 microseconds or roughly 3 times faster to use this
"PIIX" timecounter than the "i8254" timecounter. Resolution is
also 3 times better.
The code cheats and don't register the PCI device, because other pieces
of code want to use it too.
Originally spotted by: msmith
far-reaching in fd-land, so you'll want to consult the code for
changes. The biggest change is that now, you don't use
fp->f_ops->fo_foo(fp, bar)
but instead
fo_foo(fp, bar),
which increments and decrements the fp refcount upon entry and exit.
Two new calls, fhold() and fdrop(), are provided. Each does what it
seems like it should, and if fdrop() brings the refcount to zero, the
fd is freed as well.
Thanks to peter ("to hell with it, it looks ok to me.") for his review.
Thanks to msmith for keeping me from putting locks everywhere :)
Reviewed by: peter
users have suffered from this breakage, w/o commitment from someone that
they would fix the problems.
This effectively backs out revs 1.{157-160}. It does however fix the
build problem that caused 1.157 to be committed.
If the changes from rev 1.156-1.160 can't be fully tested by the
committer, may I offer posting a diff in the freebsd-current mailing
list for broader testing before inflicting this breakage again.
1) Reworked the probe routine
2) Addition of the 574B's product ID.
3) Added useful info when booting verbosely.
Submitted by: Jason Young <doogie@anet-stl.com>
warnings caused by the arg having the wrong type (not const enough).
The arg was also wrong (a full name instead of a short one) for calls
from from subr_diskmbr.c and pc98/diskslice_machdep.c.
random-seekable devices. This lets dd(1) know it can seek on them. It
also affects spec_vnopen() (IIRC), but only makes the path of execution smaller,
and does not change its behavior. This is when securelevel >= 2.
