summaryrefslogtreecommitdiffstats
path: root/sys/modules/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Remove bridge(4) from the tree. if_bridge(4) is a full functionalmlaier2005-09-271-1/+0
| | | | | | | | replacement and has additional features which make it superior. Discussed on: -arch Reviewed by: thompsa X-MFC-after: never (RELENG_6 as transition period)
* Switch from OLDCARD to NEWCARD on pc98.nyan2005-09-271-3/+3
|
* Connect smbfs build on powerpc.imura2005-09-191-0/+1
|
* Hook up the hptmv driver for amd64.scottl2005-09-081-0/+1
| | | | MFC After: 3 days
* Remove the el(4) driver for 3Com 3c501 ISA NICs from HEAD as threatenedjhb2005-08-261-3/+0
| | | | | | | | earlier as no one has stepped up to test recent changes to the driver. Oddly, the module was actually turned on on ia64 though I'm fairly certain that no ia64 machine has ever had or will ever have an ISA slot. Axe borrowed from: phk
* Add VIA/ACE "PadLock" support as a crypto(9) driver.pjd2005-08-181-0/+6
| | | | | | HW donated by: Mike Tancsa <mike@sentex.net> Most of the code obtained from: OpenBSD MFC after: 3 days
* kbdmux(4) keyboard multiplexer integrationemax2005-07-141-0/+1
| | | | | | | | | | | | | o Add minimal kbdmux(4) man page to the source tree (more details to follow); o Hook up kbdmux(4) to the build. This concludes the first part of the kbdmux(4) keyboard multiplexer integration. It now should be possible to use kbdmux(4), however one must configure kbdmux(4) by hand (i.e. load kbdmux(4) module and use kbdcontrol(1) to add/remove slave keyboards to/from kbdmux(4)). MFC after: 1 week
* Build blank_saver.ko, fade_saver.ko and green_saver.ko on sparc64marius2005-07-101-4/+1
| | | | | | | now that they work with creator(4) and machfb(4). Reviewed by: ru (style) Approved by: re (scottl)
* i386->amd64 syncpeter2005-06-301-0/+2
| | | | | | Add ath_hal and ichwd modules Approved by: re (blanked i386<->amd64 sync)
* Buid reiserifs.ko on every platforms, not only i386 and pc98.dumbbell2005-06-211-2/+1
| | | | | Reviewed by: mux (mentor) Approved by: re (dougb)
* Connect if_bridge to the build.thompsa2005-06-051-0/+1
| | | | Approved by: mlaier (mentor)
* Connect the ReiserFS filesystem to the modules build (i386 only).dumbbell2005-05-241-0/+2
| | | | Approved by: mux (mentor)
* Attach ng_nat and libalias to build.glebius2005-05-061-0/+1
|
* Throw the switch on the new driver generation/loading mechanism. Fromwpaul2005-04-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
* Add sio and puc to i386 build.imp2005-04-221-1/+4
| | | | Remove ray from ia64 build since it hasn't been tested there.
* Revert previous commit: build hwpmc(4) on all architectures.marcel2005-04-201-3/+1
| | | | Ok'd by: jkoshy@
* Only compile for the hwpmc module for supported architectures.jkoshy2005-04-201-1/+3
| | | | Submitted by: grehan
* Bring a working snapshot of hwpmc(4), its associated libraries, userland ↵jkoshy2005-04-191-0/+1
| | | | | | | | | | utilities and documentation into -CURRENT. Bump FreeBSD_version. Reviewed by: alc, jhb (kernel changes)
* Initial import of ipw, iwi, ral and ural drivers:damien2005-04-181-0/+4
| | | | | | | | | ipw - Intel PRO/Wireless 2100 iwi - Intel PRO/Wireless 2200BG/2225BG/2915ABG ral - Ralink Technology RT2500 ural - Ralink Technology RT2500USB Approved by: silby (mentor)
* Build cpufreq on ia64. The upcoming Montecito processor supports themarcel2005-04-131-0/+1
| | | | | | | | Enhanced SpeedStep (that is, a follow-up of it called Foxton). Until we actually have support for that, we build to catch regressions in the framework. Triggered by: njl
* Don't build arcmsr on pc98. The card either won't fit/work in theimp2005-04-011-1/+1
| | | | | | | pc98 machines because (a) it is PCIe or PCI-X (b) there's a BIOS that must run at boot which assumes IBM-AT compatible boot environment. Noticed by: scottl
* Glue the arcmsr driver into the tree.scottl2005-03-311-0/+3
|
* This is the much rumoured ATA mkIII update that I've been working on.sos2005-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load "atapci and ata" to get the base support, and then one or more of the device subdrivers "atadisk atapicd atapifd atapist ataraid". All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. Also probing is done without the need for interrupts, making earlier probing possible. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE: only supported on controllers that has this feature: Promise and Silicon Image for now. On other controllers the usual atacontrol detach/attach dance is still needed. o Support for "atomic" composite ATA requests used for RAID. o ATA RAID support has been rewritten and and now supports these metadata formats: "Adaptec HostRAID" "Highpoint V2 RocketRAID" "Highpoint V3 RocketRAID" "Intel MatrixRAID" "Integrated Technology Express" "LSILogic V2 MegaRAID" "LSILogic V3 MegaRAID" "Promise FastTrak" "Silicon Image Medley" "FreeBSD PseudoRAID" o Update the ioctl API to match new RAID levels etc. o Update atacontrol to know about the new RAID levels etc NOTE: you need to recompile atacontrol with the new sys/ata.h, make world will take care of that. NOTE2: that rebuild is done differently from the old system as the rebuild is now done piggybacked on read requests to the array, so atacontrol simply starts a background "dd" to rebuild the array. o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Support of new chipsets. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing or changed features from current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata from all the above metadata formats, not write all of them (Promise and Highpoint V2 so far). This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. There is more to it than just the missing write metadata support, those formats are not unique to a given controller like Promise and Highpoint formats, instead they exist for several types, and even worse, some controllers can have different formats and its impossible to tell which one. The outcome is that we cannot reliably create the metadata of those formats and be sure the controller BIOS will understand it. However write support is needed to update/fail/rebuild the arrays properly so it sits fairly high on the TODO list. o So far atapicam is not supported with these changes. When/if this will change is up to the maintainer of atapi-cam so go there for questions. HW donated by: Webveveriet AS HW donated by: Frode Nordahl HW donated by: Yahoo! HW donated by: Sentex Patience by: Vife and my boys (and even the cats)
* Add USB Communication Device Class Ethernet driver. Originally written forsobomax2005-03-221-0/+1
| | | | | | | | | | FreeBSD based on aue(4) it was picked by OpenBSD, then from OpenBSD ported to NetBSD and finally NetBSD version merged with original one goes into FreeBSD. Obtained from: http://www.gank.org/freebsd/cdce/ NetBSD OpenBSD
* Don't build the nve on pc98.nyan2005-03-121-1/+1
|
* FreeBSD consumer bits of the nForce MCP NIC binary blob.obrien2005-03-121-0/+3
| | | | | | | Demanded by: DES Encouraged by: scottl Obtained from: q@onthenet.com.au (partially) KNF'ed by: obrien
* reorder ath_rate_onoe to after ath_rate_sample so it gets used as thesam2005-03-111-1/+1
| | | | | default rate control algorithm; this should be done differently but for now use this simple solution
* SampleRate rate control algorithm for the ath driversam2005-03-111-0/+1
| | | | Submitted by: John Bicket
* connect wlan_acl to the buildsam2005-03-091-0/+1
| | | | Submitted by: Alexey Zelkin
* Add support for Windows/x86-64 binaries to Project Evil.wpaul2005-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
* Only compile the cpufreq driver on i386 and amd64.scottl2005-02-051-1/+3
|
* Hook up the cpufreq framework, acpi_perf(4), and cpufreq(4) drivers.njl2005-02-041-0/+1
|
* Fix alignment in the last commit.ru2005-02-031-2/+2
|
* Don't build syscons, uart or vpo on PPC.grehan2005-02-031-3/+8
|
* Build "digi" on i386, pc98, and amd64 only.ru2005-01-301-1/+3
|
* Remove local hack which cowardly slipped into previous commit.sobomax2005-01-291-2/+0
| | | | MFC after: 2 weeks
* o Split out kernel part of execve(2) syscall into two parts: one thatsobomax2005-01-291-0/+2
| | | | | | | | | | | copies arguments into the kernel space and one that operates completely in the kernel space; o use kernel-only version of execve(2) to kill another stackgap in linuxlator/i386. Obtained from: DragonFlyBSD (partially) MFC after: 2 weeks
* "pst" is not 64-bit clean for reasons specified in sys/amd64/conf/NOTES.ru2005-01-271-1/+2
|
* Comment out "lnc" on amd64 for reasons specified in sys/amd64/conf/NOTES.ru2005-01-271-1/+1
|
* ar and sr (and their netgraph cousins) don't appear to be 64-bit clean, soimp2005-01-271-1/+1
| | | | disable them on all but i386.
* The ar driver appears to do naughty things with pointers and integersimp2005-01-271-1/+1
| | | | and so appears to not be 64-bit clean. disable it on ia64 for the moment.
* pcic is goneimp2005-01-271-1/+0
|
* Add cs module. It has built in my tree for ages, and it just neverimp2005-01-261-0/+2
| | | | made it into FreeBSD's tree.
* Provide a WITHOUT_MODULES variable that specifies a list of moduleswes2005-01-201-0/+4
| | | | | | | | | to elide. This is a somewhat more convenient way of specifying in e.g. make.conf a list of modules you know you will never need. PR: kern/76225 Submitted by: David Yeske <dyeske@yahoo.com> MFC after: 2 weeks
* NOCRYPT -> NO_CRYPTru2004-12-211-1/+1
|
* Separate mse driver into a core driver and a bus attachments. Separate outimp2004-12-121-0/+2
| | | | | | | | | | | | | the ISA and CBUS (called isa on pc98) attachments. Eliminate all PC98 ifdefs in the process (the driver in pc98/pc98/mse.c was a copy of the one in i386/isa/mse.c with PC98 ifdefs). Create a module for this driver. I've tested this my PC-9821RaS40 with moused. I've not tested this on i386 because I have no InPort cards, or similar such things. NEC standardized on bus mice very early, long before ps/2 mice ports apeared, so all PC-98 machines supported by FreeBSD/pc98 have bus mice, I believe. Reviewed by: nyan-san
* Update/new modules for net80211 and ath changes.sam2004-12-081-0/+6
|
* Add vkdb(4) man page and connect vkbd(4) to the build.emax2004-11-161-0/+1
|
* Put _ray back, as appropriate.imp2004-11-151-0/+2
|
* Add comment about why amd64 and ia64 don't build acpi modules.imp2004-11-151-2/+2
|
OpenPOWER on IntegriCloud