nelson@kodak.com (bruce nelson) (07/30/88)
We are contemplating purchase of a display device for which we will be able to obtain an already written device driver for 4.3 BSD on a VAX 750. What will be necessary to convert this device driver code to run on a MicroVax under Ultrix? Is it a trivial (change a few addresses) or hard (reinvent the wheel) kind of a task. Many thanks for your responses. Bruce D. Nelson | UUCP: ...!rutgers!rochester!kodak!hawkeye!nelson Eastman Kodak Company | Voice: 716-726-7890 901 Elmgrove Road | Company Mail: Dept 420 Technical Support Services Rochester, NY 14650 |
jbm@eos.UUCP (Jeffrey Mulligan) (08/04/88)
>From article <51452@felix.UUCP>, by nelson@kodak.com (bruce nelson): > We are contemplating purchase of a display device for which we will be > able to obtain an already written device driver for 4.3 BSD on a VAX 750. > What will be necessary to convert this device driver code to run on > a MicroVax under Ultrix? Is it a trivial (change a few addresses) or > hard (reinvent the wheel) kind of a task. I have just done something like this; I'm not quite through, though. (The driver I started with may have been 4.2 instead of 4.3, I think the Ultrix was 1.2 but I'm not positive.) There was only one real hitch. When I tried to relink the new kernel, the symbols spl6(), splx(), (set processor priority) came up undefined. By doing "nm /vmunix | grep pri" I discovered the two symbols getpriority and setpriority. I substituted these in the appropriate places, but the job is still not finished. Unfortunately, I don't know what is the proper calling syntax of these routines. The spl? routines return the current priority, but it is in the form of a processor status word; thus if you do "splx( n=spl6())" the processor priority gets set to 6, but the value of n is not six, it is some PS word. So my question is, does getpriority() return a small integer, a PS word or something else? (I put printf's at the points where the calls occurred, but that section of the driver hasn't been activated by my activities yet.) If anyone can answer this question I will be very grateful. To the original poster, with that exception, our driver was up and running with no problem. v -- Jeff Mulligan (jbm@aurora.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-6290
angelo@jvnca.csc.org (Michael F. Angelo) (08/17/88)
> There was only one real hitch. When I tried to relink the new kernel, > the symbols spl6(), splx(), (set processor priority) came up > undefined. I think what you want to do, is fake the make - ie ( if the file were named: x.c ): /bin/cc -I. -c -S -DKERNEL x.c /lib/c2 x.s | ../vax/inline/inline | as -o x.o Then load the driver with the rest of the Kernel. > By doing "nm /vmunix | grep pri" I discovered the two symbols getpriority and setpriority. According to the man pages, getpriority/ setpriority ( section 2 of the man): getpriority - returns the highest prio of any specified proc. setpriority - sets the prio of all the specified processes. If I remember correctly, spl6 should return the previous value ( an int ). After you are done, you should do an splx. ie: register x; x= spl6(); .... ... splx(x); hence: splx( x=spl6()); Will set the prio to spl6 and store the value in x. It will then reset the priority back to what it was previously. -- Michael F. Angelo angelo@jvnca.csc.org
jbm@eos.UUCP (Jeffrey Mulligan) (08/23/88)
>From an earlier posting by me: >> There was only one real hitch. When I tried to relink the new kernel, >> the symbols spl6(), splx(), (set processor priority) came up >> undefined. Thanks to all who responded. On the microvax, the filter was not vax/inline/inline but mvax/asm. Interestingly, the source file for my driver was already listed in conf/files.mvax: ../vaxuba/ik.c non-supported device driver I could not find any appropriate makefile entry however; the kernel makefile had something like: ik.o: ln -s ../BINARY.mvax/ik.o ik.o Anyway, I put the (unadulterated) driver source from BINARY.mvax to vaxuba, created a little makefile in BINARY.mvax, and all was well. I still don't see why config didn't put the compile instructions in some makefile by itself. -- Jeff Mulligan (jbm@aurora.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-6290
mouse@Larry.McRCIM.McGill.EDU (der Mouse) (09/06/88)
Reply-to: mouse@Larry.McRCIM.McGill.EDU (der Mouse) In article <54075@felix.UUCP>, angelo@jvnca.csc.org (Michael F. Angelo) writes: [an attribution seems to have been lost here] >> [spl6() and splx()] > [speculation on this subject] > splx( x=spl6()); > Will set the prio to spl6 and store the value in x. It will then > reset the priority back to what it was previously. This is dangerous. Don't do this if there is any chance whatever you might be called from higher priority than spl6()! If this sequence is executed when the processor is at spl7(), for example, IPL will be *dropped* for a moment to spl6(), thus allowing some interrupts which should presumably not happen yet (because someone went to the trouble of setting spl7()). If you want to determine the current IPL, you can either mfpr(IPL) if you don't mind being VAX-dependent, or you can splx(x=splhigh()). (I believe splhigh() is rather recent; some systems call it spl7(). Be careful, because systems with splhigh() generally have spl7() as well.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu