Commit Graph

13 Commits

Author SHA1 Message Date
Jonathan T. Looney
bd79708dbf In the TCP stack, the hhook(9) framework provides hooks for kernel modules
to add actions that run when a TCP frame is sent or received on a TCP
session in the ESTABLISHED state. In the base tree, this functionality is
only used for the h_ertt module, which is used by the cc_cdg, cc_chd, cc_hd,
and cc_vegas congestion control modules.

Presently, we incur overhead to check for hooks each time a TCP frame is
sent or received on an ESTABLISHED TCP session.

This change adds a new compile-time option (TCP_HHOOK) to determine whether
to include the hhook(9) framework for TCP. To retain backwards
compatibility, I added the TCP_HHOOK option to every configuration file that
already defined "options INET". (Therefore, this patch introduces no
functional change. In order to see a functional difference, you need to
compile a custom kernel without the TCP_HHOOK option.) This change will
allow users to easily exclude this functionality from their kernel, should
they wish to do so.

Note that any users who use a custom kernel configuration and use one of the
congestion control modules listed above will need to add the TCP_HHOOK
option to their kernel configuration.

Reviewed by:	rrs, lstewart, hiren (previous version), sjg (makefiles only)
Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D8185
2016-10-12 02:16:42 +00:00
Warner Losh
d4f95c889d In kernel config files, it is supposed to be 'options<space><tab>' not
'options<tab><tab>', per long standing (but recently not so strictly
enforced) convention.
2014-03-18 14:41:18 +00:00
David E. O'Brien
0e6a0799a9 Back out r253779 & r253786. 2013-07-31 17:21:18 +00:00
David E. O'Brien
99ff83da74 Decouple yarrow from random(4) device.
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
  The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.

* random(4) device doesn't really depend on rijndael-*.  Yarrow, however, does.

* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
  random_adaptor is basically an adapter that plugs in to random(4).
  random_adaptor can only be plugged in to random(4) very early in bootup.
  Unplugging random_adaptor from random(4) is not supported, and is probably a
  bad idea anyway, due to potential loss of entropy pools.
  We currently have 3 random_adaptors:
  + yarrow
  + rdrand (ivy.c)
  + nehemeiah

* Remove platform dependent logic from probe.c, and move it into
  corresponding registration routines of each random_adaptor provider.
  probe.c doesn't do anything other than picking a specific random_adaptor
  from a list of registered ones.

* If the kernel doesn't have any random_adaptor adapters present then the
  creation of /dev/random is postponed until next random_adaptor is kldload'ed.

* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
  system wide one.

Submitted by: arthurmesh@gmail.com, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
2013-07-29 20:26:27 +00:00
Alexander Motin
45f6d66569 Remove all legacy ATA code parts, not used since options ATA_CAM enabled in
most kernels before FreeBSD 9.0.  Remove such modules and respective kernel
options: atadisk, ataraid, atapicd, atapifd, atapist, atapicam.  Remove the
atacontrol utility and some man pages.  Remove useless now options ATA_CAM.

No objections:	current@, stable@
MFC after:	never
2013-04-04 07:12:24 +00:00
Jayachandran C.
4b3aada9d4 Resource allocation for XLP SoC SDHCI slots
The on-chip SD slots do not have PCI BARs corresponding to them, so
this has to be handled in the custom SoC memory allocation.

Provide memory resource for rids corresponding to BAR 0 and 1 in
the custom allocation code.
2012-03-27 15:43:32 +00:00
Jayachandran C.
2652f84c92 NOR flash driver for XLP.
The NOR interface on the SoC appears on the top level PCI bus. Add
a simple driver for this.
2012-03-27 15:16:38 +00:00
Jayachandran C.
35011d20cb xlpge : driver for XLP network accelerator
Features:
- network driver for the four 10G interfaces and two management ports
  on XLP 8xx.
- Support 4xx and 3xx variants of the processor.
- Source code and firmware building for the 16 mips32r2 micro-code engines
  in the Network Accelerator.
- Basic initialization code for Packet ordering Engine.

Submitted by:	Prabhath Raman (prabhath at netlogicmicro com)
		[refactored and fixed up for style by jchandra]
2012-03-27 14:05:12 +00:00
Jayachandran C.
9b4d140639 Opencrypto driver for XLP Security and RSA/ECC blocks
Support for the Security and RSA blocks on XLP SoC. Even though
the XLP supports many more algorithms, only the ones supported
in OCF have been added.

Submitted by:	Venkatesh J. V. (venkatesh at netlogicmicro com)
2012-03-27 11:43:46 +00:00
Jayachandran C.
8f57f9e0d7 I2C support for XLP, add hints for I2C devices and update PCI resource
allocation code.
2012-03-27 11:17:04 +00:00
Ed Schouten
92396a3174 Remove pty(4) from our kernel configurations.
As of FreeBSD 8, this driver should not be used. Applications that use
posix_openpt(2) and openpty(3) use the pts(4) that is built into the
kernel unconditionally. If it turns out high profile depend on the
pty(4) module anyway, I'd rather get those fixed. So please report any
issues to me.

The pty(4) module is still available as a kernel module of course, so a
simple `kldload pty' can be used to run old-style pseudo-terminals.
2012-03-21 08:38:42 +00:00
Jayachandran C.
f48a19aa93 Fix USB compilation, and add USB options to XLP conf
Remove obsolete header file included in usb_init.c
2011-11-19 14:33:14 +00:00
Jayachandran C.
c82deda35b Rearrange XLP configuration files.
Create std.XLP for configuration options, which is included by the
conf files. The files XLP, XLPN32 and XLP64 will have mostly ABI related
options.

Also move uart and pci to mips/nlm/std.xlp since all XLP configurations
needs these devices.

Obtained from:	prabhath at netlogicmicro com (intial version)
2011-11-18 11:18:59 +00:00