if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
dcons(4): very simple console and gdb port driver
dcons_crom(4): FireWire attachment
dconschat(8): User interface to dcons
Tested with: i386, i386-PAE, and sparc64.
* Uppercase the .Dt command contents.
* Remove incorrect usage of .Fa.
* Use .Va for struct members, and .Vt for structs
(correct replacement for .Fa)
* Markup VM_* and MAP_* macros with .Dv command.
* Replace 'man' with 'manual' for consistency.
* Uppercase .Dt command contents.
* Make use of .Fo and .Fc for marking up functions with
a lot of arguments.
NOTE: Please do not use the `\' line seperator for mdoc(7)
manual pages, as it has problems of its own on some displays;
instead, consult the mdoc(7) manual on using .Fo and .Fc.
* Change 'man' to 'manual' for consistency.
* Add .Vt in the right places, transform some .Fa to .Vt, depending
on discussion context.
* When refering to the function malloc(), use .Fn, and not .Xr.
* Add `The' to prefix a sentence when describing a function, so
it results in ``The xxx() function..."
* Use `system call' instead of `syscall'.
* Improve the sentence which discusses accept_filt_generic_mod_event();
Talk about moduledata_t, and refer to the DECLARE_MODULE(9) manual
page.
* Properly markup .An (Author Name) throughout the AUTHORS section.
* Remove first person sentence start.
* Make use of .Dv for LEASE_READ and LEASE_WRITE.
* Move the LOCKS section below the standard mdoc(7) RETURN VALUES
section.
* Cleanup grammar for RETURN VALUES and AUTHORS section.
* Remove redundant sentence on return values.
rate is how fast modems exchange symbols. Bit rate is how many bits
per second the serial port nominally communicates at. Try to use bit
rate consistently where that's what is ment. The default data rate is
now 9600 baud. 300 baud being default pre-dates 4.4-LITE1. Document
that tip doesn't respect the system default rate for a given channel.
Sorry guys, but no ucbvax, kremvax or kgbvax added to the example.
Noted by: bde
what the entry does for people that are not used to reading
/etc/remote files every day. Keep arpavax, because it is a cool name,
but remove the phone number listed. arpavax hasn't been answering
that number for a while :-)
FreeBSD supports. None of them support an alternate formats, except
the alpha (which prints extra register information).
# if we get a mips port, we can put the mips case back to document the
# actual behavior.
ebay. Also have notes for my recent experiences with 3com pcmcia
cards (mostly this or that doesn't work). Also look at the strings
that are claimed to be supported in the bus specific front ends. Note
that the 3C569* are CBUS.
libraries to be reported as up-to-date.
Before:
# make -f /dev/null nonexistent.a
`nonexistent.a' is up to date.
After:
# make -f /dev/null nonexistent.a
make: don't know how to make nonexistent.a. Stop
PR: bin/44137 (part of)
callout lock while the callout is happening. So the serialization
that I thought was happening isn't. Therefore, remove the part of the
bugs that says this. Leave in the other bug as it is very hard to
work around (impossible?).
Fix various typos.
Also note that timeout/untimeout are considered to be the old interface and
the callout interface should be used insetad.
Submitted by: bde (first two) and wollman (third)
callout has finished or is in progress. Also document that the
locking of the callout code for FreeBSD 5 has eliminated the 'or is in
progress' clause as a possibility and that such elimination is an
accident of the implementation and shouldn't be relied upon.
o It is the /usr/include files, not the /usr include files.
o Document the practice of converting to the c99 standard uintXX_t
form from the older, but non-standard, BSD-style u_intXX_t. This
has been going on in the tree for a while now, and I've heard other
developers also state that this conversion is happening. Note also
that this is a slow process and should be treated like whitespace
changes.
has been supported for the last 10 months. [1]
- Make the device list compact, since it is getting rather large.
Reported by: David Magda <dmagda@magda.ca> [1]
MFC after: 2 weeks
instances: the memory holding a struct disk should be pre-zeroed so
as to initialize any storage framework private data in the structures
properly. In addition, the memory must be writable so that the
private data may be updated.
Pointed out by: phk
APIs permit disk device drivers to register and deregister storage devices
for use by storage device consumers. No doubt this API will change
more as time flies by, but this should be helpful to the creators of
new storage device drivers.
Reviewed by: phk
- Fill in autosense data.
- Add compatibility for RELENG_4.
* scsi_target.c
- Raw device support
- Set correct value in c_descr->offset for CAM_DIR_NONE case.
- Support for CTIO abort.
and use it in src/etc/sendmail/Makefile in case the user wants to use
a different path to the sendmail m4 sources (e.g., sendmail port users).
Submitted by: dinoex
MFC after: 21 days
X-MFC after: RELENG_4 code freeze ends
which are based on the AR5212 and should just work (not verified).
Add Proxim Skyline 4032, the PCI version of th e4030.
Add revision suffix 'B' to D-Link DWL-G520/G650 entries, in order
to indicate that revision A1 cards are not supported by this driver
(both A1 and B1/B2 cards are sold in identical boxes).
Explicitly point out the existence of unsupported DWL-G520/G650
(rev. A1) cards in the CAVEATS section.
Approved by: sam
be hardwired into makefiles, including those under /usr/share/mk.
The reporter submitted a patch, but I've watered it down.
Reported by: Ian Freislich <ianf@za.uu.net>
MFC after: 3 weeks
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
as it was decided that our toolchain will revert to looking
for libraries in /usr/lib only.
- Make /usr/lib/libfoo.so -> /lib/libfoo.so.X symlinks absolute
so that they still work if /usr is symlinked.
- Remove stale /usr/lib/libfoo.so.X libraries during install.
Discussed with: gordon, obrien, peter
It improves on sio(4) in the following areas:
o Fully newbusified to allow for memory mapped I/O. This is a must
for ia64 and sparc64,
o Machine dependent code to take full advantage of machine and firm-
ware specific ways to define serial consoles and/or debug ports.
o Hardware abstraction layer to allow the driver to be used with
various UARTs, such as the well-known ns8250 family of UARTs, the
Siemens sab82532 or the Zilog Z8530. This is especially important
for pc98 and sparc64 where it's common to have different UARTs,
o The notion of system devices to unkludge low-level consoles and
remote gdb ports and provides the mechanics necessary to support
the keyboard on sparc64 (which is UART based).
o The notion of a kernel interface so that a UART can be tied to
something other than the well-known TTY interface. This is needed
on sparc64 to present the user with a device and ioctl handling
suitable for a keyboard, but also allows us to cleanly hide an
UART when used as a debug port.
Following is a list of features and bugs/flaws specific to the ns8250
family of UARTs as compared to their support in sio(4):
o The uart(4) driver determines the FIFO size and automaticly takes
advantages of larger FIFOs and/or additional features. Note that
since I don't have sufficient access to 16[679]5x UARTs, hardware
flow control has not been enabled. This is almost trivial to do,
provided one can test. The downside of this is that broken UARTs
are more likely to not work correctly with uart(4). The need for
tunables or knobs may be large enough to warrant their creation.
o The uart(4) driver does not share the same bumpy history as sio(4)
and will therefore not provide the necessary hooks, tweaks, quirks
or work-arounds to deal with once common hardware. To that extend,
uart(4) supports a subset of the UARTs that sio(4) supports. The
question before us is whether the subset is sufficient for current
hardware.
o There is no support for multiport UARTs in uart(4). The decision
behind this is that uart(4) deals with one EIA RS232-C interface.
Packaging of multiple interfaces in a single chip or on a single
expansion board is beyond the scope of uart(4) and is now mostly
left for puc(4) to deal with. Lack of hardware made it impossible
to actually implement such a dependency other than is present for
the dual channel SAB82532 and Z8350 SCCs.
The current list of missing features is:
o No configuration capabilities. A set of tunables and sysctls is
being worked out. There are likely not going to be any or much
compile-time knobs. Such configuration does not fit well with
current hardware.
o No support for the PPS API. This is partly dependent on the
ability to configure uart(4) and partly dependent on having
sufficient information to implement it properly.
As usual, the manpage is present but lacks the attention the
software has gotten.
hose your system. You end up with just about everything statically linked
(except for libpam.so), which then causes all the pam users to fail.
eg: login, sshd, su etc all stop working because dlopen no longer works
because there is no libc.so in memory anymore.
gcc passes -L/usr/lib to ld. The /usr/lib/libxxx.so symlink is *not* a
compatability link. It is actually the primary link. There should be no
symlinks in /lib at all. Only /lib/libXX.so.Y.
peter@daintree[9:27pm]/usr/bin-104> file yppasswd
yppasswd: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.1.1, dynamically linked (uses shared libs), stripped
peter@daintree[9:27pm]/usr/bin-105> ldd yppasswd
yppasswd:
libpam.so.2 => /usr/lib/libpam.so.2 (0x280d1000)
peter@daintree[9:28pm]/usr/bin-106>
Note no libc.so.5. Hence libpam.so.2 has unresolved dependencies.
I believe this is also the cause of the recent buildworld failures when
pam_krb5.so references -lcrypto stuff etc and when librpcsvc.so references
des_setparity() etc.
This change could not possibly have worked, unless there are other missing
changes to the gcc configuration. It won't work with ports versions of
gcc either.
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
are supported by the driver.
- Use a list to specify which cards are supported.
- Add the 3c592/3c597 EISA cards to the list of supported cards.
PR: docs/56086 (based on)
Submitted by: Lukas Ertl <l.ertl@univie.ac.at>
buildworld targets by default, but allow it to be done for all user
targets by introducing a boolean option, named ALWAYS_CHECK_MAKE.
This change is by no means perfect and I don't even want to claim
this to be a solution. It does however address the fact that not
everybody likes to see make(1) rebuilt simply because the regression
test failed for some reason or other, including pilot error. It
therefore serves the purpose of keeping the crowd happy until we
have something better or simply reached a compromise.
The reasons for changing the default behaviour are:
o It avoids a negative, possibly non-intuitive option,
o It's according to POLA and fond of feet,
o Only buildworld is documented to do its best to be
successful at reasonably cost.
Reviewed by: gad, imp, obrien, peter
Change the manual page title to use the device family name (Rhine),
since the list of supported device id's won't fit on one line anymore.
Submitted by: Lukas Ertl <l.ertl@univie.ac.at> (based on) [1]
PR: docs/55639 (based on) [1]
Confirmed by: driver source code [1]
MFC after: 3 days
names in Amharic instead of English.
Also, remove some extra names I had previously considered
including. They don't make sense since the calendar names
don't match up.
specific interfaces. This is required by aodvd, and may in future help us
in getting rid of the requirement for BPF from our import of isc-dhcp.
Suggested by: fenestro
Obtained from: BSD/OS
Reviewed by: mini, sam
Approved by: jake (mentor)
are created in the correct location. Always make them. For libraries
that live in /lib, this causes a /lib/libfoo.so and a compatibility
/usr/lib/libfoo.so to be created. We may want to drop the
/usr/lib/libfoo.so symlink at some future point.
need relative pathing to work correctly. This is s necessary step
for putting libraries in /lib while the .so symlinks still live
in /usr/lib.
This should be a big NOOP in the case where SHLIBDIR == LIBDIR.
use the atmconfig(8) utility instead of route(8) to install those routes.
For this we need a new rc.conf variable natm_static_routes that works
just like static_routes except that the referenced routes use the syntax
of atmconfig(8).
Okay'ed by: mtm
new ATMIOCOPENVCC/CLOSEVCC. This allows us to not only use UBR channels
for IP over ATM, but also CBR, VBR and ABR. Change the format of the
link layer address to specify the channel characteristics. The old
format is still supported and opens UBR channels.
- Move isa/ppc* to sys/dev/ppc (repo-copy)
- Add an attachment method to ppc for puc
- In puc we need to walk the chain of parents.
Still to do, is to make ppc(4) & puc(4) work on other platforms. Testers
wanted.
PR: 38372 (in spirit done differently)
Verified by: Make universe (if I messed up a platform please fix)
/rescue, from section 7 to section 8. The old rescue.7 file has been
simply subjected to "cvs rm", as there is no history to preserve.
Update the release documentation accordingly.
Requested by: njl, ru
Most text by: Tim Kientzle <kientzle@acm.org>
Reviewed by: ru, doc@
Approved by: ceri (mentor)
for the harp(4) pseudo driver and for loadable native HARP drivers
(like hfa_pci).
To use harp(4) the rc variable natm_interfaces must be set to the
list of NATM interfaces to be used for HARP. These interfaces
will be brought up with ifconfig and the harp(4) will be loaded.
To use loadable native HARP drivers atm_load must be set to
the list of drivers to load.
Reviewed by: mtm, gordon (partly)
The release.9 target is now responsible only for generation of MFS root
file systems, that are built for all architectures, even those that do
not provide a floppy installation option. The release.10 target is now
responsible for creation of a set of boot, MFS root, and fixit floppies,
and the NO_FLOPPIES variable now affects only this target.
Also, replaced the FIXIT_TARGET variable with a check of whether the
*FIXITSIZE variables are present for a given architecture, similar to
how this is done when generating boot floppies.
Discussed with: jhb
