From owner-freebsd-chat Wed May 5 18:54:39 1999 Delivered-To: freebsd-chat@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 33EB2158DC for ; Wed, 5 May 1999 18:54:36 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA38853; Wed, 5 May 1999 18:55:00 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Dale Anderson" Cc: freebsd-chat@FreeBSD.ORG Subject: Re: PCWeek article by Anne Chen -- Comments In-reply-to: Your message of "Wed, 05 May 1999 16:33:28 CDT." Date: Wed, 05 May 1999 18:55:00 -0700 Message-ID: <38849.925955700@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So, your saying that FreeBSD can read in the binary and begin > executing machine instructions without any processing in between, or Correct. It's still an x86 binary and everything in it that's not trapping to the kernel for services is going to be executed exactly as it is under Linux; its shared libraries will be loaded (out of some part of /compat/linux/...), its accesses to many common system devices (like the vga console) dealt with appropriately by compatibility support in the driver, etc. As far as the binary's concerned, it's running on a Linux box. When it makes a system call, that goes through whatever syscall table has been mapped in with the process by the image activator (the bit which handles getting /bin/ls into memory so it can actually run) and if it's a Linux binary image activator, it simply maps in a different syscall table than the FreeBSD ELF binary image activator does. No extra overhead, just a switch pointing in a different direction (so to speak). - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message