LINT: add a couple of new/missing/undocumented options
files.i386: add linux code so that you can compile a kernel with static
linux emulation ("options LINUX")
i386/*: use #if defined(COMPAT_LINUX) || defined(LINUX) to enable static
support of linux emulation (just like "IBCS2" makes ibcs2 static)
The main thing this is going to make obvious, is that the LINUX code
(when compiled from LINT) has a lot of warnings, some of which dont look
too pleasant..
allow one EISA/ISA/PCI/VL Buslogic controller to be probed. The driver
is almost fully dynamic. It just needs some kdc work and for the SCSI code
to stop passing unit numbers up in the scsi_xfer struct.
introduced.
Fixed the device-driverness of atapi.c and spkr.c.
These changes are actually no-ops because ${DRIVER_C} is the same as
${NORMAL_C} for the i386. I could do without magic CFLAGS. Special
handling should be in the sources if possible.
This code will only be included in your kernel if you have
'options DEVRANDOM', but that will fall away in a couple of days.
Obtained from: Theodore Ts'o, Linux
had a 2.1 tag, thus sending these two changes into the 2.1 branch instead
of -current. Argh. I may bring these changes into the 2.1 anyway (they're
benign there) so I'm not going to admin them out of 2.1 for the time
being.
new driver code, there are diffs to several other existing files
on the system and a man page.
This version of matcd implements the rest of the key ioctls related to
playing audio CDs and reading table of contents information from any
type of disc.
This update also corrects several problems detected since the original
version 1(10) was released. These include:
1. Jordons report on the kernel -c string problem.
2. A problem with the driver being confused by other types of
devices located at addresses it probes.
3. An old CD TOC wouldn't always be cleared after a disc change.
4. Cleaned up code so -Wall yields no warnings on 2.0 and later.
5. A problem with drive getting out of sync with the driver when
changing between CD-Data and CD-DA.
There have only been two reports from the field relating to problems
so either the first release isn't really being used or doesn't have
many problems.
If there are any problems with this submission, please let me know.
Submitted by: Frank Durda IV <uhclem%nemesis@fw.ast.com>
card. This is the braindamaged card with the 80186 CPU on it. It is
slow, probably not very good after all, but hey, if you have one lying
around doing nothing anyway...
Added the "zp0" driver to GENERIC.
briefly over it, and see some serious architectural issues in this stuff.
On the other hand, I doubt that we will have any solution to these issues
before 2.1, so we might as well leave this in.
Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much
in the normal case.
Reviewed by: phk
Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
adapted to FreeBSD by Heikki Suonsivu <hsu@cs.hut.fi>.
Submitted by: Andrew Werple <andrew@werple.apana.org.au> and
Heikki Suonsivu <hsu@cs.hut.fi>
Obtained from: NetBSD
Submitted by: wolf (Wolfgang Stanglmeier)
Most PCI specific files moved from sys/i386/pci to sys/pci.
One PC specific file (pcibus.c) new in sys/i386/isa.
Handles at least Trantor T130 and ProAudioSpectrum adapters.
The pas driver has consequently been removed.
This driver can be configured without without interrupts.
Manpage to follow when PAS16 has been edited in.
Reviewed by: phk
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
Go to a single dependancy in files.i386. Using a .c file for the
sequencer code won't work since I need to know the size of the program,
so we just include the generated .h file as:
"../../sys/gnu/misc/aic7770/aic7770_seq.h"
Reviewed by:
Submitted by:
Obtained from:
instead. The entire scheme just doesn't work as envisioned (hint: think
about make depend as well as all). Those extremely rare individuals who
actually hack on the sequencer code will know how to keep stuff in sync,
I *do* get the feeling!
of config so YOU MUST RECOMPILE CONFIG. Modifying config was the cleanest
solution to integrating this driver into the tree which will become more
obvious in the next commit.
created by Amancio Hasty (specificly, this, in conjunction with his sound
driver mods for dual-mode DMA will allow VAT compiled for BSD/386 1.1 to
run under FreeBSD 2.x.)
will do most of the work for handling them. Only one extra flag and one
bogus dependency was used for machdep.c and there was never anything
special about the others.
Add locore.s, but commented out. It's still special.
Remove com.c and lpa.c.
This is the slowest and most stupid of our SCSI-drivers, but it is there
and it works. It has been tested with CD-ROM and disk.
It uses no interrupts, no DMA, just polled I/0.
Transfer-rate is <= 100Kbyte/sec.
If you set the jumpers on the board, you can change the unit-number and
you will be able to have four of these co-exist in one computer, why one
would do that is somewhat unclear though.
If I ever get my hand on the docs for this, I will improve it of course,
but for now we can install and access those CD-ROMs.
This driver supports all the DEC EtherWORKS III NICs (DE203, DE204,
and DE205) and the later DEC EtherWORKS II NICs (DE200, DE201, DE202,
DE422). DEPCA-style boards prior to the DE200 have not been tested
and may not work.
Submitted by: Matt Thomas (thomas@lkg.dec.com)
put vers.o at the end of the loader line. We are simply jumping in the
moment into the first location of the text segment in 386bsd. So the
linking order is very important :-). With the addition of the const
types in newvers.sh we jumped into them. I have experimented with an
entry point specification, but was unsuccessfull. Someone else should
look at this.
devices.i386:
files.i386:
Added entries for a Sony cdrom driver.
line of Makefile.i386. Fixes the extra rule that gmake complains about
for machdep.o. This fix is from Joans 0lsson.
Rework the depends and rules for assym.s and genassym so that we now use
the .depend rule for genassym.o such that if you change any header files
that are included by genassym.c the right things happen. This is probably
what has caused more bad kernel builds than any other thing in the
Makefile.i386!
