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    [W:0.025 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site