included in all C files if it makes sense (i.e., for compiling kernels
but not for compiling modules), so including it explicitly just
complicates module makefiles.
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.
Use "genassym ... > ${.TARGET}", not "genassym -o $@ ...", so that
genassym(1) doesn't need to support -o.
Removed duplicate -D_KERNEL from CFLAGS.
Removed triplicate -D_KERNEL from flags for compiling svr4_locore.s.
-U_KERNEL became negative when all all the genassym.c's were converted
to be cross-built.
Use "genassym ... > ${.TARGET}", not "genassym -o $@ ...", so that
genassym(1) doesn't need to support -o.
Removed duplicate -D_KERNEL from flags for compiling linux_locore.s.
-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.
-it not seems to be necessary
-to avoid dhcp messages or something like that sent to faith interface
The problem reported by: Jim Bloom <bloom@acm.org>
linux_statfs and linux_fstatfs. Linux binaries testing this expect
the filesystem's magic number and not our vnode's tag.
PR: 15425
Tested by: Vladimir N. Silyaev <vsilyaev@mindspring.com>
- Set MAX_OFFS driver compile option to 63 (was 64 which is wrong).
- Fix a typo in the SYMBIOS NVRAM layout structure and add field and
bit definition for the support of PIM_NOBUSRESET.
- Report to XPT PIM_NOBUSRESET and PIM_SCANHILO if set by user in NVRAM.
- Negotiate SYNC immediately after WIDE response from the target as
suggested by Justin Gibbs.
- Remove some misleading comment about CmdQue handling by CAM.
- Apply correctly the MAX_WIDE and MAX_OFFS driver options.
Include <sys/param.h> before <sys/assym.h> in case any of the magic
in the former is ever needed in the latter.
Removed an unused forward declaration and an unused include.
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 "$<".
now you can dynamically create rate-limited queues for different
flows using masks on dst/src IP, port and protocols.
Read the ipfw(8) manpage for details and examples.
Restructure the internals of the traffic shaper to use heaps,
so that it manages efficiently large number of queues.
Fix a bug which was present in the previous versions which could
cause, under certain unfrequent conditions, to send out very large
bursts of traffic.
All in all, this new code is much cleaner than the previous one and
should also perform better.
Work supported by Akamba Corp.
It seems that the IDE system uses 0x3f6 for itself, which conflicts with
fdc's default 0x3f0-3f7 allocation range. Sigh. Work around this.
Use bus_set_resource() rather than allocating specific areas, it makes
the code a little cleaner.
Based on work by: dfr
Note: the .INF file for LinkSys's driver says the vendor ID is 0x66b,
however this does not agree with the vendor ID listed for LinkSys in
the company list from www.usb.org. In fact, 0x66b doesn't seem to appear
in the company list at all. Furthermore, this same vendor ID crops
up in some of the D-Link .INF files. Frankly I don't know what the heck
is going on here, but I need to add 0x66b to usbdevs and call it
something, so here we are.
certain PHY addresses in aue_miibus_readreg(). Not all adapters based
on the Pegasus chip may have their PHYs wired for the same MII bus
addresses: the logic that I used for my ADMtek eval board might not
apply to other adapters, so make sure to only use it if this is really
an ADMtek eval board (check the vendor/device ID).
This will hopefully make the LinkSys USB100TX adapter work correctly.
makes it a little easier to notice that parity checking an 8bit sram
isn't working.
Turn on scb and internal data-path parity checking for all pci chips types.
We were only doing this for ultra2 chips.
After clearing the parity interrupt status, clear the BRKADRINT. This
avoids seeing a bogus BRKADRINT interrupt after external SCB probing
once normal interrupts are enabled.
an URB before sending ZLP) set to the default. Choosing a bad value
can apparently cause a lockup on some machines/controllers.
Reported by: Doug Ambrisko
