RE: testing, testing
On Mon, 12 Jul 1999, Brent Fulgham wrote:
# How is the Linux compatibility handled? Is there already a Libc ported
# to BSD, or does the kernel handle this somehow?
Linux binaries usually use Linux libraries (and this really
only applies to binaries that are dynamically linked). The biggest
thing that happens is that syscalls are mapped differently within
kernel. The loader determines what type of binary it is
running and uses the appropriate syscall map. Not much harder
than changing a pointer to a new table. In some instances,
syscalls map to "shims" to massage arguments into or out of
the kernel. Some things that Linux's kernel has that FreeBSD's
doesn't, have been written, clone is one example I believe.
This is the reason why Linux binaries run as fast (or better
sometimes) on FreeBSD. There is nearly zero overhead. This
sort of trivializes FreeBSD's Linux ABI a bit. There was a
lot of other work that had to have been done to make this a
reality, but you should get the idea that it is not emulation
is the traditional sense of the word. Emulation implies we
run binaries for arch X on arch Y. FreeBSD's Linux ABI runs
i386 binaries on i386 hardware (and Alpha binaries on Alpha
hardware) so we won't "emulate" anything, we provide a
compatibility layer that makes Linux binaries think they are
running on a Linux box. Or so the theory goes. :)
# Does BSD have the concept of "kernel modules"? Does everything have to
# be statically compiled into the kernel?
Yes and no. BSD has two mechanisms for loading kernel modules.
LKM is now defunct in favor of the better KLD implementation.
My screensaver on my FreeBSD/Alpha box is loadable module.
# And Debian has nothing against the BSD license. We just need to make
# sure that whatever we do doesn't violate the terms of one or the other
# license. In the case of Device drivers, I worry that there may be
# some GPL 'infection' of the kernel -- which might be another reason that
# Linux drivers have not been ported more quickly.
As Gary points out this has sparked many religious wars. In
general, GNU licensed kernel bits are not accepted. The userland
bits (much of which are the same as Debian's) can be GNU'd. Though
if a BSD'd version exists it is usually used instead. A prime
example is bmake(1) and gmake(1).
# Can you comment on BSD scalability -- in terms of say multiprocessor
# use, etc.? I know that's an area in which Linux has had some rather
# public "error reports" lately ;-) (Mindcraft Survey anyone?)
FreeBSD's SMP is pretty good considering it is basically a one
lock wonder. There is work currently being done to remedy this
but things in the BSD community tend to take longer to fruition.
They tend to be very conservative about how new things are implemented
and subsequently released. Usually for the better if you are not
a gamer and want the hardware that hit the shelf yesterday. :)
I have four SMP machines, a dual P5-266, two dual PII-333, and
a four CPU Dell PowerEdge server, that run quite well on FreeBSD.
I also have an Alpha machine for doing FreeBSD/Alpha package
builds. FreeBSD doesn't exactly corner the market on the number
of different CPUS it runs on, but the ones it does support it
does pretty darn good. NetBSD is much more interesting in this
respect if you have an old Amiga or PDP-11 that you want to run
a free Un*x and want to stay in the *BSD family.
-steve
PS: I'm not a member of -core either. Though I am a FreeBSD
committer. My views are mine and not those of FreeBSD in
general. :-)
Reply to: