lkml.org 
[lkml]   [1998]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: GGI Project Unhappy On Linux
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans