Newsgroups: comp.unix.sysv386
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!stowe.cs.washington.edu!pauld
From: pauld@stowe.cs.washington.edu (Paul Barton-Davis)
Subject: Re: Writing Driver (and usleep)
Message-ID: <1991Apr15.184618.16105@beaver.cs.washington.edu>
Keywords: documentation
Sender: news@beaver.cs.washington.edu (USENET News System)
Reply-To: pauld@cs.washington.edu (Paul Barton-Davis)
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <2357@pdxgate.UUCP>
Date: Mon, 15 Apr 91 18:46:18 GMT

First the good news:

	You can get the driver docs from AT&T, 2 manuals, one
	containing the man pages, the other a general guide to
	device drivers for V/386.

Now the bad news:

	1) Price - each manual is about $150 !!!
	2) Content - the manuals were obviously produced by
		editing those for a 3B2 and still abound with
		irrelevant and sometimes incorrect material
		referring to those systems. Much of what's
		needed for a 386 system is missing or insufficiently
		detailed.
	3) Content(II) - the functions you mention are NOT
		documented.

Finally, if you want one last way to get the kernel docs, try SCO.
They do still distribute the driver man pages, both printed and
otherwise. If you know someone with SCO, they might be able to let you
get (printed or online) copies of the stuff in /usr/man/catK, and SCO
*might* sell you a driver manual on its own.

RAMBLING ---

Its important to realize that there are several thousand functions
in the kernel, any one of which you could call from a driver. That
doesn't mean they are part of the "kernel/driver interface", and
there are no guarantees that they will correctly in the context
of a driver (particularly during interrupt handling).

Furthermore, as for the tenmicrosecond() function - I have to say that
I know of only one way of coding this. You can't use the clock, since
must V/386 systems set HZ to be 50 or 60, which means 16 milliseconds
between ticks right there. All you can do is to block all interrupts,
and then go into a loop that should last for about 10msecs. Move your
code to a 486 or some other compatible system and it may break.
System V timing, like most of the system, sucks. If anyone knows of
any other way to do this, let me know.

Which brings up another kernel bug. There were some postings last week
about a usleep function. SCO apparently don't know how to calculate
msecs, because poll (fds, 0, 1000) only sleeps for .6 second. After
some experimentation, it appears that someone has not corrected some
code that assumes HZ = 100, and to get the correct figure, you have
to do this:

	actual_msecs_required = requested_msecs * 100 / HZ;

This is a serious bug that has implications for areas other than
those of importance to kernel hackers and deep system programmers.



-- 
Paul Barton-Davis			<pauld@cs.washington.edu>
UW Computer Science Lab		``to shatter tradition makes us feel free''