diff --git a/FAQ/hackers.sgml b/FAQ/hackers.sgml index 0409c10029..6d899feb73 100644 --- a/FAQ/hackers.sgml +++ b/FAQ/hackers.sgml @@ -1,265 +1,265 @@ - + For serious FreeBSD hackers only What are SNAPs and RELEASEs?

There are currently three active/semi-active branches in the FreeBSD :

Right now, The How do I make my own custom release?

To make a release you need to do three things: First, you need to be running a kernel with the driver configured in. Add this to your kernel config file and build a new kernel: pseudo-device vn #Vnode driver (turns a file into a device)

Second, you have to have the whole CVS repository at hand. To get this you can use but in your supfile set the release name to cvs and remove any tag or date fields: *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all

Then run Finally, you need a chunk of empty space to build into. Let's say it's in /some/big/filesystem, and from the example above you've got the CVS repository in /home/ncvs: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release

An entire release will be built in /some/big/filesystem/release and you will have a full FTP-type installation in /some/big/filesystem/release/R/ftp when you're done. If you want to build your SNAP along some other branch than -current, you can also add How do I create customized installation disks?

The entire process of creating installation disks and source and binary archives is automated by various targets in /usr/src/release/Makefile. The information there should be enough to get you started. However, it should be said that this involves doing a ``make world'' and will therefore take up a lot of time and disk space. ``make world'' clobbers my existing installed binaries.

Yes, this is the general idea; as its name might suggest, ``make world'' rebuilds every system binary from scratch, so you can be certain of having a clean and consistent environment at the end (which is why it takes so long).

If the environment variable ${DESTDIR}. Some random combination of shared libraries modifications and program rebuilds can cause this to fail in `` When my system boots, it says ``(bus speed defaulted)''.

The Adaptec 1542 SCSI host adapters allow the user to configure their bus access speed in software. Previous versions of the 1542 driver tried to determine the fastest usable speed and set the adapter to that. We found that this breaks some users' systems, so you now have to define the `` Can I follow current with limited Internet access?

Yes, you can do this How did you split the distribution into 240k files?

Newer BSD based systems have a ``Here is an example from /usr/src/Makefile. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) I've written a kernel extension, who do I send it to?

Please take a look at

And thanks for the thought! How are Plug N Play ISA cards detected and initialized?

By:

In a nutshell, there a few I/O ports that all of the PnP boards respond to when the host asks if anyone is out there. So when the PnP probe routine starts, he asks if there are any PnP boards present, and all the PnP boards respond with their model # to a I/O read of the same port, so the probe routine gets a wired-OR ``yes'' to that question. At least one bit will be on in that reply. Then the probe code is able to cause boards with board model IDs (assigned by Microsoft/Intel) lower than X to go ``off-line''. It then looks to see if any boards are still responding to the query. If the answer was ``The IDs are two 32-bit fields (hence 2ˆ64) + 8 bit checksum. The first 32 bits are a vendor identifier. They never come out and say it, but it appears to be assumed that different types of boards from the same vendor could have different 32-bit vendor ids. The idea of needing 32 bits just for unique manufacturers is a bit excessive.

The lower 32 bits are a serial #, ethernet address, something that makes this one board unique. The vendor must never produce a second board that has the same lower 32 bits unless the upper 32 bits are also different. So you can have multiple boards of the same type in the machine and the full 64 bits will still be unique.

The 32 bit groups can never be all zero. This allows the wired-OR to show non-zero bits during the initial binary search.

Once the system has identified all the board IDs present, it will reactivate each board, one at a time (via the same I/O ports), and find out what resources the given board needs, what interrupt choices are available, etc. A scan is made over all the boards to collect this information.

This info is then combined with info from any ECU files on the hard disk or wired into the MLB BIOS. The ECU and BIOS PnP support for hardware on the MLB is usually synthetic, and the peripherals don't really do genuine PnP. However by examining the BIOS info plus the ECU info, the probe routines can cause the devices that are PnP to avoid those devices the probe code cannot relocate.

Then the PnP devices are visited once more and given their I/O, DMA, IRQ and Memory-map address assignments. The devices will then appear at those locations and remain there until the next reboot, although there is nothing that says you can't move them around whenever you want.

There is a lot of oversimplification above, but you should get the general idea.

Microsoft took over some of the primary printer status ports to do PnP, on the logic that no boards decoded those addresses for the opposing I/O cycles. I found a genuine IBM printer board that did decode writes of the status port during the early PnP proposal review period, but MS said ``tough''. So they do a write to the printer status port for setting addresses, plus that use that address + Will FreeBSD ever support other architectures?

Several different groups have expressed interest in working on multi-architecture support for FreeBSD and some people are currently working on a port of FreeBSD to the ALPHA, with the cooperation of DEC. For general discussion on new architectures, - use the <platforms@FreeBSD.ORG> + use the <freebsd-platforms@FreeBSD.ORG> . I need a major number for a device driver I've written.

This depends on whether or not you plan on making the driver publicly available. If you do, then please send us a copy of the driver source code, plus the appropriate modifications to files.i386, a sample configuration file entry, and the appropriate code to create any special files your device uses. If you do not, or are unable to because of licensing restrictions, then character major number 32 and block major number 8 have been reserved specifically for this purpose; please use them. In any case, we'd appreciate hearing about your driver on - <hackers@FreeBSD.ORG>. + <freebsd-hackers@FreeBSD.ORG>. diff --git a/FAQ/misc.sgml b/FAQ/misc.sgml index 30d675d0db..80debd1ddb 100644 --- a/FAQ/misc.sgml +++ b/FAQ/misc.sgml @@ -1,218 +1,218 @@ - + Miscellaneous Questions FreeBSD uses far more swap space than Linux. Why?

It doesn't. You might mean ``why does my swap seem full?''. If that is what you really meant, it's because putting stuff in swap rather than discarding it makes it faster to recover than if the pager had to go through the file system to pull in clean (unmodified) blocks from an executable.

The actual amount of dirty pages that you can have in core at once is not reduced; the clean pages are displaced as necessary. Why use (what are) a.out and ELF executable formats?

To understand why FreeBSD uses the a.out format, you must first know a little about the 3 currently "dominant" executable formats for UNIX:

The oldest and `classic' unix object format. It uses a short and compact header with a magic number at the beginning that's often used to characterize the format (see for more details). It contains three loaded segments: .text, .data, and .bss plus a symbol table and a string table. COFF

The SVR3 object format. The header now comprises a section table, so you can have more than just .text, .data, and .bss sections. ELF

The successor to FreeBSD tries to work around this problem somewhat by providing a utility for branding a known for more information.

FreeBSD comes from the "classic" camp and has traditionally used the format, a technology tried and proven through many generations of BSD releases. Though it has also been possible for some time to build and run native In FreeBSD's case, our shared library mechanism is based more closely on Sun's SunOS-style shared library mechanism and, as such, is very easy to use. However, starting with 3.0, FreeBSD will offically support Why won't chmod change the permissions on symlinks?

You have to use either `` and man pages for more info.

without any options and follow the symlink with a trailing slash (``/''). For example, if `` chmod 555 foo/

With the trailing slash, will follow the symlink, `` Why are login names

You'd think it'd be easy enough to change Can I run DOS binaries under FreeBSD?

Yes, starting with version 3.0 you can using BSDI's if you're interested in joining this ongoing effort!

For pre-3.0 systems, there is a neat utility called in the ports collection which emulates an 8088 and enough BIOS services to run DOS text mode applications. It requires the X Window System (provided as XFree86). What is ``

stands for Software Update Protocol, and was developed by CMU for keeping their development trees in sync. We used it to keep remote sites in sync with our central development sources.

SUP is not bandwidth friendly, and has been retired. The current recommended method to keep your sources up to date is How cool is FreeBSD?

Q. Has anyone done any temperature testing while running FreeBSD? I know Linux runs cooler than dos, but have never seen a mention of FreeBSD. It seems to run really hot.

A. No, but we have done numerous taste tests on blindfolded volunteers who have also had 250 micrograms of LSD-25 administered beforehand. 35% of the volunteers said that FreeBSD tasted sort of orange, whereas Linux tasted like purple haze. Neither group mentioned any particular variances in temperature that I can remember. We eventually had to throw the results of this survey out entirely anyway when we found that too many volunteers were wandering out of the room during the tests, thus skewing the results. I think most of the volunteers are at Apple now, working on their new ``scratch and sniff'' GUI. It's a funny old business we're in!

Seriously, both FreeBSD and Linux uses the `` Who's scratching in my memory banks??

Q. Is there anything "odd" that FreeBSD does when compiling the kernel which would cause the memory to make a scratchy sound? When compiling (and for a brief moment after recognizing the floppy drive upon startup, as well), a strange scratchy sound emanates from what appears to be the memory banks.

A. Yes! You'll see frequent references to ``daemons'' in the BSD documentation, and what most people don't know is that this refers to genuine, non-corporeal entities that now possess your computer. The scratchy sound coming from your memory is actually high-pitched whispering exchanged among the daemons as they best decide how to deal with various system administration tasks.

If the noise gets to you, a good ``fdisk /mbr'' from DOS will get rid of them, but don't be surprised if they react adversely and try to stop you. In fact, if at any point during the exercise you hear the satanic voice of Bill Gates coming from the built-in speaker, take off running and don't ever look back! Freed from the counterbalancing influence of the BSD daemons, the twin demons of DOS and Windows are often able to re-assert total control over your machine to the eternal damnation of your soul. Given a choice, I think I'd prefer to get used to the scratchy noises, myself! diff --git a/FAQ/preface.sgml b/FAQ/preface.sgml index 9e623e5920..5affe53472 100644 --- a/FAQ/preface.sgml +++ b/FAQ/preface.sgml @@ -1,505 +1,506 @@ - + Preface

Welcome to the FreeBSD 2.X FAQ! What is the purpose of this FAQ?

As is usual with Usenet FAQs, this document aims to cover the most frequently asked questions concerning the FreeBSD operating system (and of course answer them!). Although originally intended to reduce bandwidth and avoid the same old questions being asked over and over again, FAQs have become recognized as valuable information resources.

Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, please feel free to mail them to the . What is FreeBSD?

Briefly, FreeBSD 2.X is a UN*X-like operating system based on U.C. Berkeley's 4.4BSD-lite release for the i386 platform. It is also based indirectly on William Jolitz's port of U.C. Berkeley's Net/2 to the i386, known as 386BSD, though very little of the 386BSD code remains. A fuller description of what FreeBSD is and how it can work for you may be found on the .

FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation. See some of them in the

For more detailed information on FreeBSD, please see the What are the goals of FreeBSD?

The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we're definitely not prepared to insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, we believe, one of the most fundamental goals of Free Software and one that we enthusiastically support.

That code in our source tree which falls under the GNU Public License (GPL) or GNU Library Public License (GLPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed BSD copyright whenever possible. Why is it called FreeBSD?

It may be used free of charge, even by commercial users. Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial). Anyone who has an improvement and/or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisos).

For those of our readers whose first language is not English, it may be worth pointing out that the word ``free'' is being used in two ways here, one meaning ``at no cost'', the other meaning ``you can do whatever you like''. Apart from one or two things you What is the latest version of FreeBSD?

Version is the latest stable version; it was released in October, 1997. This is also the latest release version.

Briefly explained, -stable is aimed at the ISP or other corporate user who wants stability and a low change count over the wizzy new features of the latest release. At the moment, these versions are one and the same, but it shouldn't be long before the -current branch is polished enough for general release.

This is not to say that a 3.0-current snapshot is unusable for business services, and many people who need some 3.0 specific feature (newer compiler technology, faster networking code, etc) have decided to take a chance with it with very good results. We simply do not wish to "certify" 3.0 as mission-worthy until it's been better shaken-out. What is FreeBSD-current?

is the development version of the operating system, which will in due course become 3.0-RELEASE. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the in the for details on running -current.

If you are not familiar with the operating system or are not capable of identifying the difference between a real problem and a temporary problem, you should not use FreeBSD-current. This branch sometimes evolves quite quickly and can be un-buildable for a number of days at a time. People that use FreeBSD-current are expected to be able to analyze any problems and only report them if they are deemed to be mistakes rather than ``glitches''. Questions such as ``make world produces some error about groups'' on the -current mailing list are sometimes treated with contempt.

Every now and again, a release is also made of this -current development code, CDROM distributions of the occasional snapshot even now being made available. The goals behind each snapshot release are: To test the latest version of the installation software. To give people who would like to run -current but who don't have the time and/or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems. To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although CVS normally prevents anything horrible like this happening :) To ensure that any new features in need of testing have the greatest possible number of potential testers.

No claims are made that any snapshot can be considered ``production quality'' for any purpose. For stability and tested mettle, you will have to stick to full releases.

Snapshot releases are directly available from and are generated, on the average, once a day for both the 3.0-current and 2.2-stable branches. What is the FreeBSD-stable concept?

Back when FreeBSD 2.0.5 was released, we decided to branch FreeBSD development into two parts. One branch was named , with the intention that only well-tested bug fixes and small incremental enhancements would be made to it (for Internet Service Providers and other commercial enterprises for whom sudden shifts or experimental features are quite undesirable). The other branch was , which essentially has been one unbroken line leading towards 3.0-RELEASE (and beyond) since 2.0 was released. If a little ASCII art would help, this is how it looks: 2.0 | | | [2.1-stable] *BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-stable ends] | (Mar 1997) | | | [2.2-stable] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5-RELEASE -> ... | (Mar 1997) (Oct 1997) | | 3.0-SNAPs (started Q1 1997) | | 3.0.0-RELEASE (Q1 1998) | \|/ + [future 3.x releases]

The -current branch is slowly progressing towards 3.0 and beyond, whereas the previous 2.1-stable branch was superceded by the release of 2.2.0, the new "stability branch" aka 2.2-stable. 3.0-current will continue to be where the active development takes place, up until the actual release of 3.0. At that point, 3.0 will become yet another branch and 3.1-current will become the next "current branch". Why did the 2.1-stable branch end with 2.1.7.1?

While we'd certainly like to be able to continue 3 branches of development, we've found that the version control tools available to us are not particularly well-suited for this; in fact, they quickly result in a maintenance nightmare for any branch which lives much beyond 2-3 months. The 2.1-stable branch has, by contrast, lasted for well over a year and what little sanity the FreeBSD developers have left would be in serious jeopardy if we continued in this way. Perhaps in the future we'll figure out another model which gives everyone what they want, and we are working on such a model, but in the meantime it's probably best to think of the old -stable coming to an end with (the final point release after 2.1.7), and the new -stable beginning with 2.2.2. When are FreeBSD releases made?

As a general principle, the FreeBSD core team only release a new version of FreeBSD when they believe that there are sufficient new features and/or bug fixes to justify one, and are satisfied that the changes made have settled down sufficiently to avoid compromising the stability of the release. Many users regard this caution as one of the best things about FreeBSD, although it can be a little frustrating when waiting for all the latest goodies to become available...

Releases are made about every 6 months on average.

For people needing (or wanting) a little more excitement, there are SNAPs released more frequently, particularly during the month or so leading up to a release. Is FreeBSD only available for PCs ?

At present, yes, though a port to the and architecture is under way. If your machine has a different architecture and you need something right now, we suggest you look at or . Who is responsible for FreeBSD?

The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a of some 17 people. There is a much larger team of around 80+ who are authorized to make changes directly to the FreeBSD source tree.

However, most non-trivial changes are discussed in advance in the , and there are no restrictions on who may take part in the discussion. Where can I get FreeBSD?

Every significant release of FreeBSD is available via anonymous ftp from the : For the current 2.2-stable release, 2.2.6R see the directory. For the current 3.0-current release, 3.0-SNAP, see the directory. releases are made once a day along the RELENG_2_2 branch (2.2.6 -> 2.2.x) as it winds its way towards the next point release on the 2.2 branch. With the occasional exception of accidental breakage, the RELENG_2_2 branch is being carefully maintained (no experimental changes, fixes made only after testing in -current). releases are also made once a day for the branch, these being of service purely to bleeding-edge testers and developers.

FreeBSD is also available via CDROM, from the following place(s):

Walnut Creek CDROM 4041 Pike Lane, Suite F Concord, CA 94520 USA Orders: +1 800 786-9907 Questions: +1 925 674-0783 FAX: +1 925 674-0821 email: WWW:

In Australia, you may find it at:

Advanced Multimedia Distributors Factory 1/1 Ovata Drive Tullamarine, Melbourne Victoria Australia Voice: +61 3 9338 6777 CDROM Support BBS 17 Irvine St Peppermint Grove WA 6011 Voice: +61 9 385-3793 Fax: +61 9 385-2360 And in the UK: The Public Domain & Shareware Library Winscombe House, Beacon Rd Crowborough Sussex. TN6 1UL Voice: +44 1892 663-298 Fax: +44 1892 667-473 Where do I find info on the FreeBSD mailing lists?

You can find full information in the What FreeBSD news groups are available?

You can find full information in the Are there FreeBSD IRC (Internet Relay Chat) channels?

There are two channels about FreeBSD on IRC: The main channel is #FreeBSD on the EFNET. You can use your regular IRC server for it. You can point your IRC client to Books on FreeBSD

Greg Lehey's book ``Installing and Running FreeBSD'' is available from Walnut Creek and ships with the 2.2.6 CDROM. There is also a larger book entitled ``The Complete FreeBSD'', which comes with additional printed manpages and includes the 2.2.6 CDROM set. It should be available in most good book shops now.

There is a FreeBSD Documentation Project which you may contact (or even better, join) on the doc mailing list: - . + . This list is for discussion of the FreeBSD documentation. For actual questions about FreeBSD, there is the questions mailing list: - . + .

A FreeBSD ``handbook'' is available, and can be found as: . Note that this is a work in progress, and so parts may be incomplete.

However, as FreeBSD 2.2.X is based upon Berkeley 4.4BSD-Lite2, most of the 4.4BSD manuals are applicable to FreeBSD 2.2.X. O'Reilly and Associates publishes these manuals: 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages : 1-56592-080-5 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages : 1-56592-075-9 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages : 1-56592-076-7 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages : 1-56592-078-3 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages : 1-56592-079-1

A description of these can be found via WWW as:

For a more in-depth look at the 4.4BSD kernel organization, you can't go wrong with:

McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman.

The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. 0-201-54979-4

A good book on system administration is:

Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 : 0-13-151051-7

This book covers the basics, as well as TCP/IP, DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, printing, etc.. It's expensive (approx. US$45-$55), but worth it. It also includes a CDROM with the sources for various tools; most of these, however, are also on the FreeBSD 2.2.6R CDROM (and the FreeBSD CDROM often has newer versions). How do I access your Problem Report database?

The Problem Report database of all open user change requests may be queried (or submitted to) by using our web-based PR and interfaces. The send-pr(1) command can also be used to submit problem reports and change requests via electronic mail. Other sources of information.

The following newsgroups contain pertinent discussion for FreeBSD users: (moderated)

Web resources: The .

The FreeBSD handbook also has a fairly complete section which is worth reading if you're looking for actual books to buy.