Commonly asked questions. Why not?

Piercarlo Grandi pcg at rupert.cs.aber.ac.uk
Sun Feb 4 07:32:55 AEST 1990


Here the text of an answer I gave to question, one of the commonly asked ones,
about System V on 386s. I try also to give some replies to other commonly
asked questions. I take myself out of the race, but somebody should, like
in other groups, post a standard list of replies monthly. We have too much
rehashing here of old things.

I should have posted the reply in comp.sys.att crossposted to this. Well,
I rectify here (ugh! cancel does not work here... :-/), but here I am to
clumsily rectify. I am adding a few extra answers to common questions.
I thought out in the last few minutes.

In article <7311 at pdn.paradyne.com> wolfe at cygnus.nm.paradyne.com (Mike Wolfe) writes:

   How did you make the disk bootable.  There is no entry in /etc/partitions
   for the floppy device and the only way I could see to make a disk bootable
   was with mkpart.

   I tried an image copy and what I ended up with was a diskette that was not
   bootable.  Sys V will only read 79 tracks from the floppy
   drives I assume this
   is the problem.  So I went to my SUN 3/80 and did the image copy and
   everything was fine.  However I still don't know how to make a boot floppy
   from scratch.

The usual answer is RTFM. A bootable floppy, be it any density,
size, whatever, has the first track that contains the bootstrap
(finding the file in /etc that contains the floppy bootstrap is
left as an exercise to the reader), and the remaining tracks
contain a filesystem, into which you can put what you want, but
usually a miniscule root.

The device files /dev/*dsk/f*t (i.e. those ending in 't') will
give access to the entire floppy, first track inclusive, the
other will only let you access from the second track onwards.

If you want to duplicate a bootable floppy, just use the device file
that ends in 't' (/dev/rdsk/f0t will work almost always).

If you want to create a bootable floppy, just copy the boostrap file
onto the device file that maps the entire floppy, and then mkfs and
fill the rest. For example:

	cp /etc/flboot /dev/dsk/f0t
	mkfs /dev/rdsk/f0 <size>:<inodes> <gap> <cylsize>
	labelit/dev/rdsk/f0 install flop
	mount /dev/dsk/f0 /install
	find <miniroot> -depth -print | cpio -pdlmuav /install

OK? OK? Enough. :->

A proposal: There should be a monthly posting with frequently asked
questions. The ones that seem to surface every now and then are:

	What is the format of a package floppy?

 		Read the f* manual. Installable drivers
		are complicated, think it over carefully.

	How do I create a bootable floppy for floppy type X?

		First track is boostrap, rest is filesystem.

	How do I get the cartridge tape to stream?

		Use pax or GNU tar and 'ddd' or 'team', (best is
		GNU tar with team, or may be pax 2 with team)
		or, if you don't have any, 'cpio' with the
		undocumented block factor options (-C xxxx).

	How do I get the -z option of ld to work?

		Don't even use -z; just a little ld script will do.
		Make your memory begin at 0x1000 (or at any other
		multiple of 0x1000, -z would have it begin at 0x20000),
		and make the text begin in the executable file at 0x1000
		(not higher, otherwise you waste executable file space).
		Remember to define a few segments of memory, 4 meg long,
		at high addresses, for the shared libraries.

		Alternatively use -z and a shell script that makes your
		exeutable text relocate at 0x20000, and begin at 0x1000
		boundary in the file.

		If you use gcc or g++, it is easy to modify the
		link phase spec to use the ld script if option -z is
		specified, or even better, by default.

	Where is alloca()?

		In -lPW.

	How do I get GNU <xxxx> to compile?

		Disable automatic optimizer inlining with -W2,-y0
		after -O on all files that use alloca().

		If you are using GCC, remember to run fixincludes or
		make it use the System V cpp, or manually copy and
		edit the files that do non-ANSI cpp things.

	How do I get GNU C++ to work?

		Check that NO_UNDERSCORES, USE_COLLECT, and COFF are
		defined, and that NO_DOLLAR_IN_LABEL is as well.

		cplus-parse.y has a name too long for RCS, like
		a few others. If you want to apply patches under
		RCS to such files, you should rename them. Me thinks
		that a prefix of 'c++-' instead of 'cplus-' is fine.

		You can compile G++ with the AT&T cc (but for two obvious
		fixes). It is much less hassle than installing
		GCC first. On the other hand, install GDB 3.4; it's
		easy, and is vastly less buggy than sdb, and understands
		G++ name mangling. If you use the CLED history line
		discipline, or similar tricks, you may want to excise
		the history and command line editing code from GDB.
		Clean patches to do this will be posted (soon :->).

		You may want to rework a little	the rule for the
		'collect' stage in gcc.c.

		Alternatively, lobby MDT to make the .ctor/.dtor section
		trick the default under System V, instead of collect.

		Don't use encapsulated a.out format unless you know
		what you are doing.

		Be sure you have the setvbuf patch for i386 in the
		cplus-lex.c file.

		You probably want the link phase spec to use -z, the
		shell script alluded above, and -lc_s by default.

		Making LIBG++ into a shared library is not easy, and
		not worth doing for most of it. Wait for SysV.4...

		For most programs you may wantto use the little streams
		library posted a while ago. Or wait for it to be reposted
		(soon).

	How do I get GNU Emacs to work?

		Easy enough... You can really figure that out yourself,
		and under ESIX you can even have (modulo a few fixes)
		process buffers with BSD ptys; or else use stream
		ptys (look at sysdep.c and imitate the IRIS pty handling).

	My high speed telecomm utility loses under VP/IX or DOSmerge!

		Inevitable. They are running on a semi-simulated
		device under a multitasking OS.

	Serial lines chew up CPU time and lose.

		If you only need a few, just get a dumb card and use
		16550As with a driver that enables the FIFO (e.g. fas2).

	Won't install on a drive whose geometry is not in the BIOS!

		Write manually an /etc/partitions file instead of
		letting the disksetup program write it (interrupt the
		INSTALL script and continue manually). Then set the BIOS
		drive type to an entry that has the right number of heads,
		to make sure the hard disc will boot.

	How do I get fast IO?

		Get ESDI or RLL discs, at least two of them, possibly
		with two controllers, or get a fast SCSI controller, like
		the 1542, with at least two fast (e.g. Micropolis, Imprimis,
		Quantum, or Maxtor discs). Access times under 25 msec.

		If you are not running a fast file system of some sort,
		unfragment the partitions regularly (dump/restore), e.g.
		every few weeks (2-4) for an active filesystem.


		Put the swap on a disc/controller different from the
		root and user filesystems, and the /tmp and spool filesystems
		on one different from those where you keep user home dirs.

		Don't create many small filesystems.

Additional questions/answers:

	I run out of inodes on my news filesystem

		It's a known bug. Corrected in AT&T's 3.2.1 etc..., ISC 2.02,
		and in some binary patches, previously posted here, for
		Microport 3.0e and ISC 2.0 (and Microport SV/AT). If you
		have it, write hate mail to your supplier's expensive QA
		department... It has been known for years.

	Which Unixes for the 386?

		You have AT&T Unix, Dell Unix, Everex Esix, Interactive 2.0,
		SCO Unix 386, SCO Xenix 386 2.3, Venturcom Venix; Not derived
		from AT&T sources, but with a very high degree of (claimed)
		compatibility, Chorus, Lynx, Mach (well, not quite yet).

	Does X windows run under 386 Unixes?

		Yes. Quite well, actually. You really want a mouse, a 16
		bit VGA, and a monitor that is at least 14". Plenty of memory.
		The various X servers are not compatible in the way they
		communicate locally with their clients.

	What is the minimum hardware for running Unix on a 386?

		A 386SX, 2 MBytes (comfortable if you are running Xenix386,
		which has a less stupid swapping policy, a bit tight with
		System V), a 40 MByte disc (Unix will take about 20 of those)
		with an avg. seek time of 28 msec or better, a monochrome
		adapter and screen. You can have this for little over $1000
		mail order nowadays. Using RLL is advisable, and does not
		cost you more.

	Will a caching controller be a good investment?

		The question is not easy to answer. Some believe that
		you'd better just add the same memory to central memory
		and expand the buffer cache. On many machines that have
		a limit of maximum 16 megs of physical memory this cannot
		not be done, if you already have the maximum.

		Remember though that the cache must be not volatile or
		write thru, or you in the absence of an UPS your disc
		contents could be horribly trashed.

	How many users can I run on my 386?

		On a suitably configured (read: multiple fast discs, ESDI
		or SCSI controller, many MBytes of RAM), quite a lot,
		depending on many factors. At least a dozen. As many as
		as three dozen doing light sw developement or similar things.

	What is the bandwidth of an AT Bus?

		Over 5 MBytes per second. As an IO-memory bus, that's still
		plenty. Most peripherals don't go over 1 MByte per second.
		As a CPU-memory bus, no way.

	Can Unix make use of memory in 16 bit AT bus slots?

		Yes, but the slowdown is really impressive. Don't do it.
		When you buy your machine, make sure that you can put in
		1MBit chips, and that you can stuff at least 8MBytes on
		the motherboard or the 32 bit memory board without buying
		anything extra, and that you can go all the way to 16 MBytes
		(or what you see as your maximum) without throwing away
		any chips that are already installed.

--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk

--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk



More information about the Comp.unix.i386 mailing list