exactly the same functionality via a sysctl, making this feature
a run-time option.
The default is 1(ON), which means that /dev/random device will
NOT block at startup.
setting kern.random.sys.seeded to 0(OFF) will cause /dev/random
to block until the next reseed, at which stage the sysctl
will be changed back to 1(ON).
While I'm here, clean up the sysctls, and make them dynamic.
Reviewed by: des
Tested on Alpha by: obrien
__FreeBSD_version 500015 can be used to detect their disappearance.
- Move the symbols for SMP_prvspace and lapic from globals.s to
locore.s.
- Remove globals.s with extreme prejudice.
compiled under newcard yet. ep works just fine under newcard with the
missing ID matching code added (not committed yet):
ep0: <3Com 3c589 10Mbps Ethernet> at port 0x300-0x30f irq 9 function 0
config 1 on pccard1
ep0: Ethernet address 00:10:4b:df:48:57
To use it, some dll is needed. And currently, the dll is only for NetBSD.
So one more kernel module is needed.
For more infomation,
http://chiharu.haun.org/peace/ .
Reviewed by: bp
this gives us several benefits, including:
* easier extensibility- new optional methods can be added to
ac97/mixer/channel classes without having to fixup every driver.
* forward compatibility for drivers, provided no new mandatory methods are
added.
This is a driver for the LanMedia/SBE LMC150x E1/T1 family of cards.
The driver currently support unframed E1 (2048kbit/s) and framed
E1 (nx64).
These cards will provision E1/T1 lines for about 1/4 the cost of
a cisco router...
- Break out the /dev/pci driver into a separate file.
- Kill the COMPAT_OLDPCI support.
- Make the EISA bridge attach a bit more like the old code; explicitly
check for the existence of eisa0/isa0 and only attach if they don't
already exist. Only make one bus_generic_attach() pass over the
bridge, once both busses are attached. Note that the stupid Intel
bridge's class is entirely unpredictable.
- Add prototypes and re-layout the core PCI modules in line with
current coding standards (not a major whitespace change, just moving
the module data to the top of the file).
- Remove redundant type-2 bridge support from the core PCI code; the
PCI-CardBus code does this itself internally. Remove the now
entirely redundant header-class-specific support, as well as the
secondary and subordinate bus number fields. These are bridge
attributes now.
- Add support for PCI Extended Capabilities.
- Add support for PCI Power Management. The interface currently
allows a driver to query and set the power state of a device.
- Add helper functions to allow drivers to enable/disable busmastering
and the decoding of I/O and memory ranges.
- Use PCI_SLOTMAX and PCI_FUNCMAX rather than magic numbers in some
places.
- Make the PCI-PCI bridge code a little more paranoid about valid
I/O and memory decodes.
- Add some more PCI register definitions for the command and status
registers. Correct another bogus definition for type-1 bridges.
but serves to work around some uncleanliness whereby the ISA bus is not
found on Alpha systems with PCI:EISA bridges due to the lack of EISA code
for the Alpha.
held and panic if so (conditional on witness).
- Change witness_list to return the number of locks held so this is easier.
- Add kern/syscalls.c to the kernel build if witness is defined so that the
panic message can contain the name of the offending system call.
- Add assertions that Giant and sched_lock are not held when returning from
a system call, which were missing for alpha and ia64.
.PATH to ${.CURDIR}/[...]/kern , the "exists" expression will fail for the
form exists(${.CURDIR}/[...]/kern/). This appears to be happening because
make is searching for the argument to "exists" by using .PATH rather than a
relative search, because .PATH and the argument match at the beginning.
Additionally, make appears to consider a path that starts with ${.CURDIR}
as relative, even though it expands to an absolute path.
The reason that most people aren't seeing this problem is that the absolute
paths of /usr/src/sys and /sys are also searched, so as long as the kernel
source can be found in at least one of those places, no problems surface.
This problem was inadvertently introduced on 1 December 2000, with the
addition of the sysvipc modules.
- Make pccbb/cardbus kld loadable and unloadable.
- Make pccbb/cardbus use the power interface from pccard instead of inventing its own.
- some other minor fixes
using a cardbus based system with pccbb providing the pcic interface).
Something isn't quite right.. when the driver allocates and activates
its resources, the IO space that was requested reads as all zeros (versus
the original 0xff's as it normally is when there is no device responding).
Also, deactivate the resources before releasing them. OLDCARD doesn't
seem to care but NEWCARD/CARDBUS get rather unhappy if you release
a resource that hasn't been deactivated yet.
Make pcic_p.c only compile with oldcard kernels.
This code has help us comprehence ACPI spec .
Contributors of this code is as follows(except for FreeBSD commiter):
Yasuo Yokoyama,
Munehiro Matsuda,
and ALL acpi-jp@jp.freebsd.org people.
Thanks.
R.I.P.
function declared in kern_ktr.c. The only inline checks left are the
checks that compare KTR_COMPILE with the supplied mask and thus should
be optimized away into either nothing or a direct call to ktr_tracepoint().
- Move several KTR-related options to opt_ktr.h now that they are only
needed by kern_ktr.c and not by ktr.h.
- Add in the ktr_verbose functionality if KTR_EXTEND is turned on. If the
global variable 'ktr_verbose' is non-zero, then KTR messages will be
dumped to the console. This variable can be set by either kernel code
or via the 'debug.ktr_verbose' sysctl. It defaults to off unless the
KTR_VERBOSE kernel option is specified in which case it defaults to on.
This can be useful when the machine locks up spinning in a loop with
interrupts disabled as you might be able to see what it is doing when it
locks up.
Requested by: phk
- Layout reorganisation to enhance portability. The driver now has
a relatively MI 'core' and a FreeBSD-specific layer over the top.
Since the NetBSD people have already done their own port, this is
largely just to help me with the BSD/OS port.
- Request ID allocation changed to improve performance (I'd been
considering switching to this approach after having failed to come
up with a better way to dynamically allocate request IDs, and seeing
Andy Doran use it in the NetBSD port of the driver convinced me
that I was wasting my time doing it any other way). Now we just
allocate all the requests up front.
- Maximum request count bumped back to 255 after characterisation
of a firmware issue (off-by-one causing it to crash with 256
outstanding commands).
- Control interface implemented. This allows 3ware's '3dm' utility to
talk to the controller. 3dm will be available from 3ware shortly.
- Controller soft-reset feature added; if the controller signals a
firmware or protocol error, the controller will be reset and all
outstanding commands will be retried.
(a NetBSD port for NEC PC-98x1 machines). They are ncv for NCR 53C500,
nsp for Workbit Ninja SCSI-3, and stg for TMC 18C30 and 18C50.
I thank NetBSD/pc98 and bsd-nomads people.
Obtained from: NetBSD/pc98
reducues the maintenance load for the mutex code. The only MD portions
of the mutex code are in machine/mutex.h now, which include the assembly
macros for handling mutexes as well as optionally overriding the mutex
micro-operations. For example, we use optimized micro-ops on the x86
platform #ifndef I386_CPU.
- Change the behavior of the SMP_DEBUG kernel option. In the new code,
mtx_assert() only depends on INVARIANTS, allowing other kernel developers
to have working mutex assertiions without having to include all of the
mutex debugging code. The SMP_DEBUG kernel option has been renamed to
MUTEX_DEBUG and now just controls extra mutex debugging code.
- Abolish the ugly mtx_f hack. Instead, we dynamically allocate
seperate mtx_debug structures on the fly in mtx_init, except for mutexes
that are initiated very early in the boot process. These mutexes
are declared using a special MUTEX_DECLARE() macro, and use a new
flag MTX_COLD when calling mtx_init. This is still somewhat hackish,
but it is less evil than the mtx_f filler struct, and the mtx struct is
now the same size with and without mutex debugging code.
- Add some micro-micro-operation macros for doing the actual atomic
operations on the mutex mtx_lock field to make it easier for other archs
to override/optimize mutex ops if needed. These new tiny ops also clean
up the code in some places by replacing long atomic operation function
calls that spanned 2-3 lines with a short 1-line macro call.
- Don't call mi_switch() from mtx_enter_hard() when we block while trying
to obtain a sleep mutex. Calling mi_switch() would bogusly release
Giant before switching to the next process. Instead, inline most of the
code from mi_switch() in the mtx_enter_hard() function. Note that when
we finally kill Giant we can back this out and go back to calling
mi_switch().
This commit adds support for Xircom X3201 based cardbus cards.
Support for the TDK 78Q2120 MII is also added.
IBM Etherjet, Intel and Xircom cards uses these chips.
Note that as a result of this commit, some Intel/DEC 21143 based cardbus
cards will also attach, but not get link. That is being looked at.
Files:
dev/cardbus/cardbus.c
dev/cardbus/cardbusreg.h
dev/cardbus/cardbusvar.h
dev/cardbus/cardbus_cis.c
dev/cardbus/cardbus_cis.h
dev/pccbb/pccbb.c
dev/pccbb/pccbbreg.h
dev/pccbb/pccbbvar.h
dev/pccbb/pccbb_if.m
This should support:
- cardbus controllers:
* TI 113X
* TI 12XX
* TI 14XX
* Ricoh 47X
* Ricoh 46X
* ToPIC 95
* ToPIC 97
* ToPIC 100
* Cirrus Logic CLPD683x
- cardbus cards
* 3c575BT
* 3c575CT
* Xircom X3201 (includes IBM, Xircom and, Intel cards)
[ 3com support already in kernel, Xircom will be committed real soon now]
This doesn't work with 16bit pccards under NEWCARD.
Enable in your config by having "device pccbb" and "device cardbus".
(A "device pccard" will attach a pccard bus, but it means you system have
a high chance of panicing when a 16bit card is inserted)
It should be fairly simple to make a driver attach to cardbus under
NEWCARD -- simply add an entry for attaching to cardbus on a new
DRIVER_MODULE and add new device IDs as necessary. You should also make
sure the card can be detached nicely without the interrupt routine doing
something weird, like going into an infinite loop. Usually that should
entail adding an additional check when a pci register or the bus space is
read to check if it equals 0xffffffff.
Any problems, please let me know.
Reviewed by: imp
now in dirs called sys/*/random/ instead of sys/*/randomdev/*.
Introduce blocking, but only at startup; the random device will
block until the first reseed happens to prevent clients from
using untrustworthy output.
Provide a read_random() call for the rest of the kernel so that
the entropy device does not need to be present. This means that
things like IPX no longer need to have "device random" hardcoded
into thir kernel config. The downside is that read_random() will
provide very poor output until the entropy device is loaded and
reseeded. It is recommended that developers do NOT use the
read_random() call; instead, they should use arc4random() which
internally uses read_random().
Clean up the mutex and locking code a bit; this makes it possible
to unload the module again.
description:
How it works:
--
Basically ifs is a copy of ffs, overriding some vfs/vnops. (Yes, hack.)
I didn't see the need in duplicating all of sys/ufs/ffs to get this
off the ground.
File creation is done through a special file - 'newfile' . When newfile
is called, the system allocates and returns an inode. Note that newfile
is done in a cloning fashion:
fd = open("newfile", O_CREAT|O_RDWR, 0644);
fstat(fd, &st);
printf("new file is %d\n", (int)st.st_ino);
Once you have created a file, you can open() and unlink() it by its returned
inode number retrieved from the stat call, ie:
fd = open("5", O_RDWR);
The creation permissions depend entirely if you have write access to the
root directory of the filesystem.
To get the list of currently allocated inodes, VOP_READDIR has been added
which returns a directory listing of those currently allocated.
--
What this entails:
* patching conf/files and conf/options to include IFS as a new compile
option (and since ifs depends upon FFS, include the FFS routines)
* An entry in i386/conf/NOTES indicating IFS exists and where to go for
an explanation
* Unstaticize a couple of routines in src/sys/ufs/ffs/ which the IFS
routines require (ffs_mount() and ffs_reload())
* a new bunch of routines in src/sys/ufs/ifs/ which implement the IFS
routines. IFS replaces some of the vfsops, and a handful of vnops -
most notably are VFS_VGET(), VOP_LOOKUP(), VOP_UNLINK() and VOP_READDIR().
Any other directory operation is marked as invalid.
What this results in:
* an IFS partition's create permissions are controlled by the perm/ownership of
the root mount point, just like a normal directory
* Each inode has perm and ownership too
* IFS does *NOT* mean an FFS partition can be opened per inode. This is a
completely seperate filesystem here
* Softupdates doesn't work with IFS, and really I don't think it needs it.
Besides, fsck's are FAST. (Try it :-)
* Inodes 0 and 1 aren't allocatable because they are special (dump/swap IIRC).
Inode 2 isn't allocatable since UFS/FFS locks all inodes in the system against
this particular inode, and unravelling THAT code isn't trivial. Therefore,
useful inodes start at 3.
Enjoy, and feedback is definitely appreciated!
and initialized during boot. This avoids bloating sizeof(struct lock).
As a side effect, it is no longer necessary to enforce the assumtion that
lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been
removed.
Idea taken from: BSD/OS.
disk drivers along with a load of fixes to context switching, fork
handling and a load of other stuff I can't remember now. This takes us as
far as start_init() before it dies. I guess now I will have to finish off
the VM system and syscall handling :-).
platforms.
While here, work around a strange quirk in config(8) that I do not yet
understand. Rearrange which atapi* files have 'optional' vs. 'count'
so that you can have atapifd without atapicd. The only difference should
be that this works instead of having a link error because atapi-all.o got
left out of the kernel.
support which use National Semiconductor DP8393X (SONIC) as ethernet
controller. Currently, this driver is used on only PC-98.
Submitted by: Motomichi Matsuzaki <mzaki@e-mail.ne.jp>
Obtained from: NetBSD/pc98
drivers (again). These drivers have not compiled for 5-6 months.
Now that the new sound code supports MIDI, the major reason we had for
reviving it is gone. It is a far better investment polishing the new
midi code than trying to keep this on life support. Come 5.0-REL, if
there are major shortcomings in the pcm sound driver then maybe we can
rethink this, but until then we should focus on pcm.
Remember, these have not been compilable since ~April-May this year.
that it's enabled in acpireg.h only if DIAGNOSTIC option is specified.
ACPICA OSD functions will be compiled in machine/acpi_machdep.c again
tentatively (if DIAGNOSTIC option is specified).
# Should we have acpica_osd.c ?
- Move all register I/O into acpi_io.c
- Move event handling into acpi_event.c
- Reorganise headers into acpivar/acpireg/acpiio
- Move find-RSDT and find-ACPI-owned-memory into acpi_machdep
- Allocate all resources (except those detailed only by AML)
as real resources. Add infrastructure that will make adding
resource support to AML code easy.
- Remove all ACPI #ifdefs in non-ACPI code
- Removed unnecessary includes
- Minor style and commenting fixes
Reviewed by: iwasaki
not work on any real hardware (or fully work on any simulator). Much more
needs to happen before this is actually functional but its nice to see
the FreeBSD copyright message appear in the ia64 simulator.
sequencer files. Different platforms place the included files in different
locations and it is easier to modify the include path passed as arguments
to the assembler than adding #ifdef support to the assembler.
Previously, these cards were supported by the lnc driver (and they
still are, but the pcn driver will claim them first), which is fine
except the lnc driver runs them in 16-bit LANCE compatibility mode.
The pcn driver runs these chips in 32-bit mode and uses the RX alignment
feature to achieve zero-copy receive. (Which puts it in the same
class as the xl, fxp and tl chipsets.) This driver is also MI, so it
will work on the x86 and alpha platforms. (The lnc driver is still
needed to support non-PCI cards. At some point, I'll need to newbusify
it so that it too will me MI.)
The Am79c978 HomePNA adapter is also supported.
