Messages in this thread | | | From | Captain Napalm <> | Subject | Re: GGI Project Unhappy On Linux | Date | Fri, 27 Mar 1998 00:07:59 -0500 (EST) |
| |
It was thus said that the Great Mark H. Wood once stated: > On Wed, 25 Mar 1998, David Todd wrote: > > > A side comment: > > > > It may be a far better thing for Linux et al to figure out how to give better > > access to the hardware for such projects. I think they may be doing this, but > > don't quote. > > My understanding is that that is exactly what the KGI portion of GGI is > for, w.r.t. graphics. Other low-level gatekeeping functions should be > explored too. But don't let's just allow any joe-user program to diddle > the hardware registers, like those OSes that crash all the time.
The AmigaOS had the concept of "resources" which a program (or device driver) could aquire, thus gaining exclusive use of that resource (and in this case, the "resource" is a hardware device, like the disk drives, serial port, etc).
I would think a good solution would be a "resource" driver (or drivers) that allows the process that opens the device exclusive use of that resource, which includes hardware IO ports, memory areas, DMA channels (possibly).
There could be several ways to handle this, but the most Unixlike way would be to create a device driver with (for example) a major number of 99, and the minor number relects the particular resource. Then you have the entries in /dev for each resource. That way, you can set up permissions on the devices just like any other driver.
The actual driver, for a given resource, can do whatever magic is required to allow that process, and only that process, access to the resource, and only that resource. For instance, on the 386, you can set up the IO map in the TSS for the process such that it has access to only those ports (and I think the kernel already has code for this, right?). And if the device has memory mapped IO areas, then those areas are mapped into the memory space (mmap() can do this already for devices, right?).
With that, it would be possible to have:
% ls -l /dev/resources/ crw-rw---- 1 root serial 99, 0 Aug 2 1998 ser03f8 crw-rw---- 1 root serial 99, 1 Aug 2 1998 ser02f8 crw-rw---- 1 root serial 99, 10 Aug 2 1998 ne2000 crw-rw---- 1 root video 99, 20 Aug 2 1998 mda crw-rw---- 1 root video 99, 21 Aug 2 1998 cga crw-rw---- 1 root video 99, 22 Aug 2 1998 evga crw-rw---- 1 root video 99, 23 Aug 2 1998 vesa
(Just examples, not to be taken as gospel, yada yada ... )
So, given a program that is setgid serial, I can then do:
struct ioctl_resource { int nports; /* # of IO ports */ int portaddr[]; /* address of IO ports */ int nmptr; /* # of memIO areas */ void *mptrs[]; /* address of memIO areas */ } argp;
fd = open("/dev/resources/ser03f8",O_RDWR); ioctl(fd,GETRESOURCEPARMS,&argp);
That way, I get the port address "I" (or the process) owns, and any memory areas (that are mapped into the VM space of the process) that "I" own as well. I would assume that the program would then know how to manipulate these. This way, user space drivers might be implemented.
If someone else has opened the device, fd is -1 and errno is set to the appropriate error code. Only one process is allowed to open a resource at time (but that's how I see it being done, it doesn't HAVE to be that way ... )
The only problem I might see are handling interrupts for the resource, but I leave that for further discussion.
-spc (Just tossing out ideas ... )
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |