On 03/03/2014 01:12 PM, Greg KH wrote:
On Mon, Mar 03, 2014 at 11:01:14AM -0600, Ken Cox wrote:
This series includes a base set of drivers for the Unisys s-Par system.
This set of drivers is enough to get a virtual guest up and running on s-Par
hardware. The remaining drivers needed to have a fully functional system
will be submitted after review of this initial set.
s-Par is firmware that provides hardware partitioning capabilities for
splitting large-scale Intel x86 servers into multiple isolated
partitions. s-Par provides a set of para-virtualized device drivers to
allow guest partitions on the same server to share devices that would
normally be unsharable; specifically, PCI network interfaces and host
bus adapters that do not support shared access via SR-IOV. The shared
device is owned and managed by a small, single-purpose service
partition, which communicates with each guest partition sharing that
device through an area of shared memory called a channel. Additional
drivers provide support interfaces for communicating with s-Par
services, logging and diagnostics, and accessing the Linux console
from the s-Par user interface.
The driver stack consists of a set of support modules, a set of bus
modules, and a set of device driver modules. The support modules
handle a number of common functions across each of the other
drivers. The bus modules provide organization for the device driver
modules, which provide the shared device functionality.
These drivers are for the Unisys virtual PCI hardware model where the
hypervisor need not intervene (other than normal interrupt handling)
in the interactions between the client drivers and the virtual adapter
firmware in the adapter service partition.
Why do you want these in the drivers/staging/ part of the kernel? I
have my guesses, but you need to tell me why :)
Frankly, I wasn't sure of the most appropriate place since this is a
conglomeration of drivers for hba, serial, video, etc. but they don't
stand alone outside of the s-PAR environment. If you can recommend a
better place for them I'll be happy to move them over.
Also, I need a TODO file, like the rest of the staging drivers have,
listing what needs to be done to get the code out of staging, and who is
responsible for the code. Ideally, a MAINTAINERS entry as well, so that
the same people get copied when people use scripts/get_maintainer.pl on
patches.
sorry about that. I'll add them.
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
