bilbo.niket@locus.ucla.edu (Niket K. Patwardhan) (12/03/85)
>From: Frans Meulenbroeks <frans%duvel.uucp@BRL.ARPA> >Subject: Xenix on PC/AT ldt, gdt (driver) question >Date: 26 Nov 85 14:01:35 GMT >Followup-To: net.micro.pc >To: info-unix@BRL-SEM.ARPA > >[Follow-up to net.micro.pc] > >Being in the process of writing a device driver for PC/AT under Xenix, I am >stuck with the following questions: > >Can I just take an unused entry in the gdt table to use as a descriptor to a >piece of physical memory? > >How can I determine whether an entry is free? Because it is all zero's? >Because it has no define in mmu.h? > >Or is it better to use an ldt, and keeps things local for each task. >(This means creating a descriptor each time an interrupt is given, and > restoring it to its original state at the end of the interrupt routine) > >Has anyone ever encountered these problems? If so, how did you solve them? >Have you ever encountered products which use memory mapped i/o? Do you >know how they "do the job"? > >Thanks in advance! If I remember right the GDT for PC/AT XENIX has two sections in it (at least) for additional descriptors. One of them is for additional code segments, and the other for data segments needed by device drivers. XENIX had a function called "dscralloc()" which you could call in the "devinit" routines to allocate a descriptor, but I believe they dumped it in the PC/AT version causing the problem you describe. To solve the problem, you need to look for an unused entry in the appropriate section of the GDT in "mmu.h".... and hope that somebody else's device driver is not using the same entry. Using the LDT is a bad idea, since it may not be an honest-to-god LDT when your interrupt comes along... (that is the LDT in which you are keeping your descriptor may not itself have a descriptor... I believe that they just switch the base address part of the one LDT descriptor rather than switch LDT descriptors when they do a task switch!)