Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
o Introduce private types for use in linux syscalls for two reasons:
1. establish type independence for ease in porting and,
2. provide a visual queue as to which syscalls have proper
prototypes to further cleanup the i386/alpha split.
Linuxulator types are prefixed by 'l_'. void and char have not
been "virtualized".
o Provide dummy functions for all syscalls and remove dummy functions
or implementations of truely obsolete syscalls.
o Sanitize the shm*, sem* and msg* syscalls.
o Make a first attempt to implement the linux_sysctl syscall. At this
time it only returns one MIB (KERN_VERSION), but most importantly,
it tells us when we need to add additional sysctls :-)
o Bump the kenel version up to 2.4.2 (this is not the same as the
KERN_VERSION MIB, BTW).
o Implement new syscalls, of which most are specific to i386. Our
syscall table is now up to date with Linux 2.4.2. Some highlights:
- Implement the 32-bit uid_t and gid_t bases syscalls.
- Implement a couple of 64-bit file size/offset bases syscalls.
o Fix or improve numerous syscalls and prototypes.
o Reduce style(9) violations while I'm here. Especially indentation
inconsistencies within the same file are addressed. Re-indenting
did not obfuscate actual changes to the extend that it could not
be combined.
NOTE: I spend some time testing these changes and found that if there
were regressions, they were not caused by these changes AFAICT.
It was observed that installing a RH 7.1 runtime environment
did make matters worse. Hangs and/or reboots have been observed
with and without these changes, so when it failed to make life
better in cases it doesn't look like it made it worse.
the cwd is looked up inside the kernel. The native getcwd() in libc
handles this in userland if __getcwd() fails.
Obtained from: NetBSD via OpenBSD
Tested by: Chris Casey <chriss@phys.ksu.edu>, Markus Holmberg <markush@acc.umu.se>
Reviewed by: Darrell Anderson <anderson@cs.duke.edu>
PR: kern/24315
blown over by the Hurricane and had a house dropped on you by the Tornado.
Now it's time to have your parade rained on by... the Typhoon!
This commit adds driver support for 3Com 3cR990 10/100 ethernet
adapters based on the Typhoon I and Typhoon II chipsets. This is actually
a port of the OpenBSD driver with many hacks by me.
No Virginia, there isn't any support for the hardware crypto yet. However
there is support for TCP/IP checksum offload and VLANs.
Special thanks go to Jason Wright, Aaron Campbell and Theo de Raadt for
squeezing enough info out of 3Com to get this written, and for doing
most of the hard work.
Manual page is included. Compiled as a module and included in GENERIC.
it may be plugged into a kernel that supports VLANs. If the kernel is
not VLAN aware, things will still work as before.
Modules don't really have option support, so this is somewhat of a hack.
- All sources are built in a single object, reducing namespace pollution.
- Kill the ready queue, and handle a busy response to mly_start in callers
rather than deferring the command.
- Improve our interaction with CAM:
- Don't advertise physical channels as SCSI busses by default.
- use the SIM queue freeze capability rather than queueing CDBs internally.
- force bus reprobe at module load time.
- Clean up more resources in mly_free.
- Tidy up debugging levels.
- Tidy up handling of events (mostly just code cleanliness).
- Use explanatory macros for operations on bus/target/channel numbers.
- Move the lance_probe function to if_lnc.c.
- Support C-NET(98)S again.
Submitted by: chi@bd.mbn.or.jp (Chiharu Shibata) and nyan
No response from: Paul Richards
a KLD. Still doesn't work well except in the PCMCIA case (now if only
pccardd(8) could load and unload drivers dynamically...). Mainly, it
tries to find fdc0 on the PCI bus for whatever obscure reasons, but i
need someone who understands driver(9) to fix this. However, it's at least
already better than before, and i'm tired of maintaining too many private
changes in my tree, given the large patches bde submitted. :)
Idea of a KLD triggered by: Michael Reifenberger <root@nihil.plaut.de>
could only get a chance of testing it under 4.3, but together with the
if_oltr.c fixes at least it seems to work now. If someone has the chance
to test this under -current, please do.
Unfortunaltey, the TR code itself (if_iso88025subr.c) is not written
in a way that would allow to make a seaparate KLD out of it. By now,
just link it directly into the oltr KLD since it's probably the POLA
to be able to load the TR code together with the only TR hardware
driver we've got by now.
I've got one single unexplained panic (in doreti_switch or somewhere
there, calling a 0xc1XXXXXX address that did no longer belong to the
kernel at all) after unloading the modules once, thus i don't propose
a MFC of this module despite my testing has been done solely on 4.3,
unless someone is really going to test this stuff in -current.
gigabit ethernet controller chip. This device is used on some
fiber optic gigE cards from SMC, D-Link and Addtron. Jumbograms and
TCP/IP checksum offload on receive are supported. Hardware VLAN
filtering is not, because it doesn't play well with our existing
VLAN code. Also add manual page.
There is a 4.x version of this driver available at
http://www.freebsd.org/~wpaul/Level1/4.x if anyone feels adventurous
and wants to test it. I still need to do performance testing and
tuning with this device.
(For my next trick, I will make the 3Com 3cR990 sit up and beg.)
it with vfsload("msdos").
(The proper fix would be to rename the `msdos' file system to
`msdosfs' in VFS_SET(), and mount_msdos(8) to mount_msdosfs(8).
But that would break too many existing fstab(5) setups, and
would require a lot of unnecessary documentation and code
msdos -> msdosfs changes.)
Noticed by: markm
systems were repo-copied from sys/miscfs to sys/fs.
- Renamed the following file systems and their modules:
fdesc -> fdescfs, portal -> portalfs, union -> unionfs.
- Renamed corresponding kernel options:
FDESC -> FDESCFS, PORTAL -> PORTALFS, UNION -> UNIONFS.
- Install header files for the above file systems.
- Removed bogus -I${.CURDIR}/../../sys CFLAGS from userland
Makefiles.
and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000
copper PHY. There are a whole bunch of very low cost cards available with
this chipset selling for $150USD or less. This includes the SMC9462TX,
D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards
from Addtron.
This chip supports TCP/IP checksum offload, VLAN tagging/insertion.
2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs.
I have not done serious performance testing with this driver. I know
it works, and I want it under CVS control so I can keep tabs on it.
Note that there's no serious mutex stuff in here yet either: I need
to talk more with jhb to figure out the right way to do this. That
said, I don't think there will be any problems.
This driver should also work on the alpha. It's not turned on in
GENERIC.
This driver supports PCI Xr-based and ISA Xem Digiboard cards.
dgm will go away soon if there are no problems reported. For now,
configuring dgm into your kernel warns that you should be using
digi. This driver is probably close to supporting Xi, Xe and Xeve
cards, but I wouldn't expect them to work properly (hardware
donations welcome).
The digi_* pseudo-drivers are not drivers themselves but contain
the BIOS and FEP/OS binaries for various digiboard cards and are
auto-loaded and auto-unloaded by the digi driver at initialisation
time. They *may* be configured into the kernel, but waste a lot
of space if they are. They're intended to be left as modules.
The digictl program is (mainly) used to re-initialise cards that
have external port modules attached such as the PC/Xem.
the main benefit this gives for now is that via686 audio devices on
motherboards with ac97 codecs that do not support vra will be able to use
sample rates other than 48khz.
bolted to a ne-2000 chip. This is necessary for the NetGear FA-410TX
and other cards.
This also requires you add mii to your kernel if you have an ed driver
configured.
This code will result in a couple of timeout messages for ed on the
impacted cards. Additional work will be needed, but this does work
right now, and many people need these cards.
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
This helps to stop it from geting out of sync.
It is not part of the normal build but I can use it with all the others
when I make changes to netgraph to ensure it is buildable.
packet flow into two unidirectional flows.
Part of a suite of nodes developed for packet flow control.
More to follow as I have time to port them to 5.x or
as others do so. The ipfw node will be the hardest..
Submitted by: "Vitaly V. Belekhov" <vitaly@riss-telecom.ru>
except for setting it. Also remove count from aha and replace it with
optional.
Also add commented out pccard lines for all the old card drivers.
They have to be commented out until they are converted because it
causes problems in NEWCARD.
the video switch by another. Exactly as VESA does on top of VGA.
It adds linear framebuffer to S3 VESA 1.2 cards.
Obtained from: The original S3 ISA code comes from
Peter Horton <pdh@colonel-panic.com>
To use it, some dll is needed. And currently, the dll is only for NetBSD.
So one more kernel module is needed.
For more infomation,
http://chiharu.haun.org/peace/ .
Reviewed by: bp
this gives us several benefits, including:
* easier extensibility- new optional methods can be added to
ac97/mixer/channel classes without having to fixup every driver.
* forward compatibility for drivers, provided no new mandatory methods are
added.
Add detach routine and turn driver into a module so it can be loaded
and unloaded. Also take a stab at implementing multicast packet
reception so that this NIC will work with IPv6. Promiscuous mode
doesn't seem to work, but I'm not sure why. It works well enough that
I can run dhclient on it and put it on the office network though.
Also ripped out spl stuff and replaced it with mutexes.
- Move PCI core code to dev/pci.
- Split bridge code out into separate modules.
- Remove the descriptive strings from the bridge drivers. If you
want to know what a device is, use pciconf. Add support for
broadly identifying devices based on class/subclass, and for
parsing a preloaded device identification database so that if
you want to waste the memory, you can identify *anything* we know
about.
- Remove machine-dependant code from the core PCI code. APIC interrupt
mapping is performed by shadowing the intline register in machine-
dependant code.
- Bring interrupt routing support to the Alpha
(although many platforms don't yet support routing or mapping
interrupts entirely correctly). This resulted in spamming
<sys/bus.h> into more places than it really should have gone.
- Put sys/dev on the kernel/modules include path. This avoids
having to change *all* the pci*.h includes.
Providing shell scripts that do nothing but load a similarly named
kernel loadable module in out of vogue.
There is no ibcs2(4) manual page, and I haven't managed to coax
anyone into contributing one based on the linux(4) manual page.
our kernel module system learned how to handle dependencies.
Providing a whole bunch of shell scripts that do nothing but load
a similarly named kernel loadable module is out of vogue.
The svr4(8) manual page has been replaced with a much better svr4(4)
page.
- Make pccbb/cardbus kld loadable and unloadable.
- Make pccbb/cardbus use the power interface from pccard instead of inventing its own.
- some other minor fixes
out of fashion. This particular case, unlike joy(8) and friends which
are just plain silly, did more than just load a kernel loadable module.
However, /etc/rc and the linux_base port were adjusted a while back to
cope with the absence of this script.
The only outstanding reason to hang on to it would have been for the
linux(8) manual page, which clued folks into the existence of the
Linuxulator. A new linux(4) was introduced a while back. It does
a much better job.
This script just isn't useful any more.
