NBarbieri.es@PARC-MAXC.ARPA (11/30/83)
I'm new at writing device drivers and need some pointers to some documentation if it exists on the kernal device driver interfaces for block and character devices. Our Unix package (Unisoft+) doesn't give a very good description of their interface mechanisms. I called the OEM of the system (Microbar Systems), and they say that the interfaces are standard Unix. Okay, then it must be documented somewhere, hopefully. I'm looking for such things as what each function does, what it expects for input, what it returns, etc. (on such things as ttread(). ttwrite(), ttychars(), ttyopen(), etc.). Any ideas? Nick (NBarbieri.es@parc-maxc)
turner%lsu.csnet@CSNET-RELAY.ARPA (Henry F Turner) (02/24/85)
I'm trying to modify a device driver that supposedly worked on 4.1bsd to work on 4.2bsd. The device is a DEC VS11 display processor. It gets its instructions and data from a "display file" in host (VAX) memory via dma. Thus the driver handles it as an exclusive access device and allows only one read or write, which merely sets up mapping the display file from host memory to the device (on a unibus). Ioctl's are are used to otherwise control/communicate with the device. The original driver used vslock to lock the display file down and included only a comment wondering whether or not it was necessary to unlock it at close time. Well, I made what I thought were the obvious changes and got the driver installed and working, but sure enough, every time we used the device, we would lose memory equivalent to the size of the display file. I added code to save the address and size in the softc structure and then used that at close time to vsunlock it. That worked fine, all memory was returned to the free list. That is, fine PROVIDED the user closed the device before exiting! It seems exit "vrelse"es all a proc's memory and THEN closef's the files. Calling vsunlock with the proc pte entry zeroed out seems to do nasty things to the kernal. It crashes! I put in a check for p_flags with SWEXIT. If set, I print a message about the memory we just pissed away and skip the vsunlock. This makes the device usable with a reasonably conscientious user population but its not a solution. I've tried to study the code to get a real understanding of how the memory management works and what is really going on but the code gets a bit opaque for my experience level. I've notice that among all the drivers that came with the distribution, only one uses the vslock/unlock calls (directly). There must be another way around this problem. If you have any insights into this or have an ideas about where I might be screwing up, I would much appreciate enlightenment. Thanks for your time, Henry F Turner Computer Science Department Room 298 Coates Hall Louisiana State University Baton Rouge, LA 70803 Phone: (504) 388-1495 CSNET: turner@lsu ARPA: turner%lsu@csnet-relay