- Split terminal emulation code from the main part of the driver so
that we can have alternative terminal emulator modules if we like in
the future. (We are not quite there yet, though.)
- Put sysmouse related code in a separate file, thus, simplifying the
main part of the driver.
As some files are added to the source tree, you need to run config(8)
before you compile a new kernel next time.
You shouldn't see any functional change by this commit; this is only
internal code reorganization.
NICs. (Finally!) The PCMCIA, ISA and PCI varieties are all supported,
though only the ISA and PCI ones will work on the alpha for now.
PCCARD, ISA and PCI attachments are all provided. Also provided an
ancontrol(8) utility for configuring the NIC, man pages, and updated
pccard.conf.sample. ISA cards are supported in both ISA PnP and hard-wired
mode, although you must configure the kernel explicitly to support the
hardwired mode since you have to know the I/O address and port ahead
of time.
Special thanks to Doug Ambrisko for doing the initial newbus hackery
and getting it to work in infrastructure mode.
Collect together the components of several drivers and export eisa from
the i386-only area (It's not, it's on some alphas too). The code hasn't
been updated to work on the Alpha yet, but that can come later.
Repository copies were done a while ago.
Moving these now keeps them in consistant place across the 4.x series
as the newbusification progresses.
Submitted by: mdodd
USB-EL1202A chipset. Between this and the other two drivers, we should
have support for pretty much every USB ethernet adapter on the market.
The only other USB chip that I know of is the SMC USB97C196, and right
now I don't know of any adapters that use it (including the ones made
by SMC :/ ).
Note that the CATC chip supports a nifty feature: read and write combining.
This allows multiple ethernet packets to be transfered in a single USB
bulk in/out transaction. However I'm again having trouble with large
bulk in transfers like I did with the ADMtek chip, which leads me to
believe that our USB stack needs some work before we can really make
use of this feature. When/if things improve, I intend to revisit the
aue and cue drivers. For now, I've lost enough sanity points.
Note1: the correct interrupt level is invoked correctly for each driver.
For this purpose, drivers request the bus before being able to
call BUS_SETUP_INTR and BUS_TEARDOWN_INTR call is forced by the ppbus
core when drivers release it. Thus, when BUS_SETUP_INTR is called
at ppbus driver level, ppbus checks that the caller owns the
bus and stores the interrupt handler cookie (in order to unregister
it later).
Printing is impossible while plip link is up is still TRUE.
vpo (ZIP driver) and lpt are make in such a way that
using the ZIP and printing concurrently is permitted is also TRUE.
Note2: specific chipset detection is not done by default. PPC_PROBE_CHIPSET
is now needed to force chipset detection. If set, the flags 0x40
still avoid detection at boot.
Port of the pcf(4) driver to the newbus system (was previously directly
connected to the rootbus and attached by a bogus pcf_isa_probe function).
Packets are received inside USB bulk transfer callbacks, which run at
splusb() (actually splbio()). The packet input queues are meant to be
manipulated at splimp(). However the locking apparently breaks down under
certain circumstances and the input queues can get trampled.
There's a similar problem with if_ppp, which is driven by hardware/tty
interrupts from the serial driver, but which must also manipulate the
packet input queues at splimp(). The fix there is to use a netisr, and
that's the fix I used here. (I can hear you groaning back there. Hush up.)
The usb_ethersubr module maintains a single queue of its own. When a
packet is received in the USB callback routine, it's placed on this
queue with usb_ether_input(). This routine also schedules a soft net
interrupt with schednetisr(). The ISR routine then runs later, at
splnet, outside of the USB callback/interrupt context, and passes the
packet to ether_input(), hopefully in a safe manner.
The reason this is implemented as a separate module is that there are
a limited number of NETISRs that we can use, and snarfing one up for
each driver that needs it is wasteful (there will be three once I get
the CATC driver done). It also reduces code duplication to a certain
small extent. Unfortunately, it also needs to be linked in with the
usb.ko module in order for the USB ethernet drivers to share it.
Also removed some uneeded includes from if_aue.c and if_kue.c
Fix suggested by: peter
Not rejected as a hairbrained idea by: n_hibma
Driver is not functional yet, but does compile. Tests with xe cards
indicates that it doesn't panic the machine when they are present, but
fail to probe. Interface help in the pcic/pccard layers are needed to
complete this driver.
hinted at in the previous config(8) commits. I've spoken about this with
a few people and after the initial suprise wore off they thought it wasn't
a bad idea. The upshot of it is that all the files*, Makefile*, options*
files are all right next to each other in the hope that people making
changes to one set will remember the others.
Note, config(8) looks to sys/conf first, and falls back to sys/$mach/conf
still, so this doesn't stop people working in subdirs for new platforms.
But once it's in the tree it can be moved next to the other files so that
the non-i386 platforms are (hopefully) treated a little better than as if
they were "second class" ports.
This does not change any user editable files. the config program is
still run in the same directory as before, the per-platform files
(GENERIC, LINT etc) are still in the same place.
COMPAT_LINUX are there. It shouldn't be and isn't used after config
time, except to complicate the svr4 module makefile.
Moved options for emulators to a separate section.
-U_KERNEL became negative when all all the genassym.c's were converted
to be cross-built. Related cleanups: PARAM went away, but was still
used here; KERNEL was renamed to _KERNEL, but was still KERNEL here;
the deprecated macros $@ and $< were still used here.
Use "genassym ... > ${.TARGET}", not "genassym -o $@ ...", so that
genassym(1) doesn't need to support -o.
Removed half-baked hard-coded dependencies of *_genassym.o on headers.
These objects should be added to the list of objects in the depend
rule to get full dependencies. This doesn't happen automatically
because they are not linked into the kernel. Half baked dependencies
don't really help.
essentially as in kernel makefiles, so that module sources can include
<stddef.h> and other standard headers. Only add the second path when
the first path can't be found, instead of when DESTDIR is defined.
Adding it used to be just an obfuscation.
Use "${.OBJDIR}" instyead of "." in -I paths. Using "${.OBJDIR}" just
gave more verbose command lines and depend files.
the misleading comments to that effect.
Prune bogus 'at foo?' (smbus, iicbus, ppbus) appendages on things that
they are meaningless for. It was just eye candy and wasn't used by
anything in the tree. The interconnects were defined by the drivers
themselves and auto discovery.
(The new ppbus code may change this if it uses the resource_get_*() calls
to find it's configured children if self discovery isn't possible)
it's always true on these platforms (and is likely to be on others as
well since loader is the one that is configured for whatever the boot
requirements are)
\begin{quote}
Compile genassym.c with ordinary ${CFLAGS}. The (small) needs for
${GEN_CFLAGS} and -U_KERNEL became negative when all all the
genassym.c's were converted to be cross-built.
Makefile.*:
- Cleanups associated with the old genassym.
- Fixed deprecated spelling of ${.IMPSRC} as "$<".
\end{quote}
Submitted by: bde
${GEN_CFLAGS} and -U_KERNEL became negative when all all the
genassym.c's were converted to be cross-built.
Makefile.*:
- Cleanups associated with the old genassym.
- Fixed deprecated spelling of ${.IMPSRC} as "$<".
ethernet adapters that are supported by the aue and kue drivers.
There are actually a couple more out there from Accton, Asante and
EXP Computer, however I was not able to find any Windows device
drivers for these on their servers, and hence could not harvest
their vendor/device ID info. If somebody has one of these things
and can look in the .inf file that comes with the Windows driver,
I'd appreciate knowing what it says for 'VID' and 'PID.'
Additional adapters include: the D-Link DSB-650 and DSB-650TX, the
SMC 2102USB, 2104USB and 2202USB, the ATen UC10T, and the Netgear EA101.
These are all mentioned in the man pages, relnotes and LINT.
Also correct the date in the kue(4) man page. I wrote this thing
on Jan, 4 2000, not 1999.
