brians@eecs.cs.pdx.edu (Brian Smith) (04/14/91)
I am writing a driver, but I am running into some documentation difficulties. Specifically, there are functions in the kernel that are not documented, and that I need. I originally called ISC for the documentation, but they said that they no longer distributed the docs. They only distribute the "Integrated Software Development Guide," which basically only tells you how to install a driver. (The rest is just incomplete tantalizers.) They told me to get the AT&T manuals, which I did, but they don't document everything that ISC (and apparently Esix) have. The functions I need are, are timing functions and memory management functions. I got the names of the tenmicrosec() and microloop() functions, and the page.c source file from an nm of /unix, but nowhere are the functions documented. They look a lot like what I need, and I would rather not roll my own, not because I can't, but because I should not have to. Who has documentation on these value added features that we can't use? Brian
pauld@stowe.cs.washington.edu (Paul Barton-Davis) (04/16/91)
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''
mburg@unix386.Convergent.COM (Mike Burg) (04/17/91)
In article <1991Apr15.184618.16105@beaver.cs.washington.edu>, pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: [Text deleted about already known quality (bwahah!) of AT&T docs] > 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. Well, AT&T 386/486 kernels have HZ set to 100. So, it's a 1 millsecond resolution. As far as coding of the tenmicrosec() functions goes.. What happens, is when the system is being booted, some part of the PIT (programable interrupt timer) code starts one of the hardware timers, and caculates how many `null' loops it can perform in a given time period (in this case, one microsecond). This "loop" counter is stored in some variable and used latter on by tenmicrosec to provide a execution delay that is ten microsecond long (give or take a few nanoseconds). The code will "sleep" (burn the cycles ;-)) for the same period of time whether it's running on a 486 at 33mhz or a 386SX at 16mhz. The real purpose of the function is not provide to a "exact" microsecond delay, but to provide a fairly constant delay time to allow various hardware pieces (video boards, comm ports, I/O boards, etc) "to settle" or setup after programming. > System V timing, like most of the system, sucks. If anyone knows of > any other way to do this, let me know. Release 3 timing is the pits... Release 4 timing is somewhat decent. -- ---------------------------------- Michael Burg - Unisys/Convergent Corp. Unix Intel Platforms Division San Jose Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg