copyrights to the inf parser files.
Add a -n flag to ndiscvt to allow the user to override the default
device name of NDIS devices. Instead of "ndis0, ndis1, etc..."
you can have "foo0, foo1, etc..." This allows you to have more than
one kind of NDIS device in the kernel at the same time.
Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c
and subr_ndis.c.
Create UMA zones for ndis_packet and ndis_buffer structs allocated
on transmit. The zones are created and destroyed in the modevent
handler in kern_ndis.c.
printf() and UMA changes submitted by green@freebsd.org
and list_verbose(), so don't open /dev/pci read-write. This allows
pciconf -l[v] to work for non-root users, assuming the securelevel is
0 or -1.
Problem experienced by: William Michael Grim <wgrim@siue.edu>
case so that if devices need different initialization, we can key off
this in the rc scripts (currently unused). Also update the man page
which is a 100% duplicate of the rc scripts.
snprintf (buf, size, fmt, buf, etc). This only works by chance with our
libc, but fails (with a truncated string) on e.g. glibc.
Okayed by: sobomax
MFC after: 1 week
/libexec to /mnt2/libexec, and execute /mnt2/rescue/ldconfig to add
the /mnt2/lib and /mnt2/usr/lib library directories. Thanks to John Baldwin
for working to track this down.
Submitted by: jhb
than a char array. Emitting the data as a big char array works fine in
the typical case, where a .sys file may be ~50K in size. Unfortunately,
some .sys files can be several hundred Kbytes in size, or even several
megabytes in size. One extreme case is the Intel centrino wireless
driver, which is 2.4MB. This causes us to emit an ndis_driver_data.h
file that's on the order of 15MB in size, and gcc consumes enormous
amounts of virtual memory while trying to compile it. On my laptop,
with 128MB of RAM and 256MB of swap space, gcc consumed all available
VM and crashed without being able to compile if_ndis.o.
By emitting the array as assembler, we bypass the C compiler and consume
much less memory. I was able to easily test compile if_ndis.ko with the
centrino driver on my laptop after this change.
This is merely a convenience, and should not have any operational effect
on the NDISulator itself.
definitions for more than one device (usually differentiated by
the PCI subvendor/subdevice ID). Each device also has its own tree
of registry keys. In some cases, each device has the same keys, but
sometimes each device has a unique tree but with overlap. Originally,
I just had ndiscvt(8) dump out all the keys it could find, and we
would try to apply them to every device we could find. Now, each key
has an index number that matches it to a device in the device ID list.
This lets us create just the keys that apply to a particular device.
I also added an extra field to the device list to hold the subvendor
and subdevice ID.
Some devices are generic, i.e. there is no subsystem definition. If
we have a device that doesn't match a specific subsystem value and
we have a generic entry, we use the generic entry.
mostly used on 80x25 displays, and the actual window is about ten
characters narrower than that, resulting in the need for horizontal
scrolling. No functional change.
RELENG_5_2 candidate.
needed to be statically populated with device nodes. The first two are no
longer true, which makes the third pretty moot. In fact, we don't seem to
put device node bits into the distribution archives at all anymore.
So..... remove the god-aweful nasty hack that force unmounted devfs during
installation so that static device nodes could land in /dev. Now that the
vnode cleaner handles this case better this isn't strictly needed, but
axeing code in sysinstall is almost always benficial. Thanks to Don Lewis
for pointing out this attribute of sysinstall.
the case where there's an entry in the manufacturer's device list but
no corresponding installation section (and hence no AddReg assignments),
i.e. if dev = find_assign(sname, "AddReg"); returns NULL, then
don't try to dereference dev.
There is a fundamental problem with the handling of .INF files that
contain definitions for multiple devices: right now we dump all the
AddReg sections that we find, but don't distinguish what device they
belong to. This often results in duplicate keys.
Yes, it's what you think it is. Yes, you should run away now.
This is a special compatibility module for allowing Windows NDIS
miniport network drivers to be used with FreeBSD/x86. This provides
_binary_ NDIS compatibility (not source): you can run NDIS driver
code, but you can't build it. There are three main parts:
sys/compat/ndis: the NDIS compat API, which provides binary
compatibility functions for many routines in NDIS.SYS, HAL.dll
and ntoskrnl.exe in Windows (these are the three modules that
most NDIS miniport drivers use). The compat module also contains
a small PE relocator/dynalinker which relocates the Windows .SYS
image and then patches in our native routines.
sys/dev/if_ndis: the if_ndis driver wrapper. This module makes
use of the ndis compat API and can be compiled with a specially
prepared binary image file (ndis_driver_data.h) containing the
Windows .SYS image and registry key information parsed out of the
accompanying .INF file. Once if_ndis.ko is built, it can be loaded
and unloaded just like a native FreeBSD kenrel module.
usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf
into an ndis_driver_data.h file that can be compiled into if_ndis.o.
Contains an .inf file parser graciously provided by Matt Dodd (and
mercilessly hacked upon by me) that strips out device ID info and
registry key info from a .INF file and packages it up with a binary
image array. The ndiscvt(8) utility also does some manipulation of
the segments within the .sys file to make life easier for the kernel
loader. (Doing the manipulation here saves the kernel code from having
to move things around later, which would waste memory.)
ndiscvt is only built for the i386 arch. Only files.i386 has been
updated, and none of this is turned on in GENERIC. It should probably
work on pc98. I have no idea about amd64 or ia64 at this point.
This is still a work in progress. I estimate it's about %85 done, but
I want it under CVS control so I can track subsequent changes. It has
been tested with exactly three drivers: the LinkSys LNE100TX v4 driver
(Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK
(e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It
still needs to have a net80211 stuff added to it. To use it, you would
do something like this:
# cd /sys/modules/ndis
# make; make load
# cd /sys/modules/if_ndis
# ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h
# make; make load
# sysctl -a | grep ndis
All registry keys are mapped to sysctl nodes. Sometimes drivers refer
to registry keys that aren't mentioned in foo.inf. If this happens,
the NDIS API module creates sysctl nodes for these keys on the fly so
you can tweak them.
An example usage of the Broadcom wireless driver would be:
# sysctl hw.ndis0.EnableAutoConnect=1
# sysctl hw.ndis0.SSID="MY_SSID"
# sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc)
# ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up
Things to be done:
- get rid of debug messages
- add in ndis80211 support
- defer transmissions until after a status update with
NDIS_STATUS_CONNECTED occurs
- Create smarter lookaside list support
- Split off if_ndis_pci.c and if_ndis_pccard.c attachments
- Make sure PCMCIA support works
- Fix ndiscvt to properly parse PCMCIA device IDs from INF files
- write ndisapi.9 man page
PR:
Submitted by:
Reviewed by:
Approved by:
Obtained from:
MFC after:
such that 'ispcvt' can build. Unforunately 'ispcvt' is needed in order for
/etc/rc.d/syscons to run. This fixes the bug where I could not get my
keymap effective at boot.
it returns. This allows it to connect to the server side again, which
has been listening on IPv6 addresses exclusively for more than 2 years.
PR: 59369
(Lite Edition) respectively. These "lite" packages are streamlined to
provide users with the core essentials for each desktop and to fit on the
release disc 1.
Approved by: re (scottl)
permitting the administrator to select a securelevel top operate
at. Include a helpfile summarizing some of the information from
init(8). This allows for explicit configuration of securelevels,
which was previously implicit in Security Profile selection.
Currently, there are no checkboxes for the active securelevel,
because sysinstall's facilities for deriving "current settings"
from rc.conf may use only one variable, not two, and I opted for
the simplest approach at this point.
Approved by: re (scottl)
selection is used to drive two configuration parameters:
(1) Default enable/disable for sshd
(2) Default enable/disable for securelevels
Replace this with an explicit choice to enable/disable sshd. A
follow-up commit will add a configuration option to the Security
post-install configuration menu to set the securelevel in rc.conf
explicitly. This should reduce the level of foot-shooting associated
with accidental enabling of securelevels, make the nature and
implications of the securelevel configuration options more explicit,
as well as make the choice to enable/disable sshd more explicit.
Approved by: re (scottl)
