[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080612132700.GA18107@elte.hu>
Date: Thu, 12 Jun 2008 15:27:00 +0200
From: Ingo Molnar <mingo@...e.hu>
To: steiner@....com
Cc: akpm@...l.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
holt@....com, andrea@...ranet.com,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [patch 00/11] GRU Driver
* steiner@....com <steiner@....com> wrote:
> This series of patches adds a driver for the SGI UV GRU. The driver is
> still in development but it currently compiles for both x86_64 & IA64.
> All simple regression tests pass on IA64. Although features remain to
> be added, I'd like to start the process of getting the driver into the
> kernel. Additional kernel drivers will depend on services provide by
> the GRU driver.
>
> The GRU is a hardware resource located in the system chipset. The GRU
> contains memory that is mmaped into the user address space. This
> memory is used to communicate with the GRU to perform functions such
> as load/store, scatter/gather, bcopy, AMOs, etc. The GRU is directly
> accessed by user instructions using user virtual addresses. GRU
> instructions (ex., bcopy) use user virtual addresses for operands.
did i get it right that it's basically a fast, hardware based message
passing interface that allows two tasks to communicate via DMA and
interrupts, without holding up the CPU? If that is the case, wouldnt the
proper support model be a network driver, instead of these special
ioctls. (a network driver with no checksumming, with scatter-gather,
zero-copy and TSO support, etc.)
or a filesystem. Anything but special-purpose ioctls ...
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists