Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

[Greg KH]

On Tue, May 17, 2016 at 07:49:53PM -0400, Jes Sorensen wrote:
> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> > On Tue, May 17, 2016 at 10:01:55AM -0400, Jes Sorensen wrote:
> >> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> >> > On Tue, May 17, 2016 at 03:27:56AM -0400, David Kershner wrote:
> >> >> This patchset moves the visorbus driver
> >> >> (fromdrivers/staging/unisys/visorbus)
> >> >> and its dependent headers files (from drivers/staging/unisys/include)
> >> >> out of staging into the main kernel tree.
> >> >> 
> >> >> The visorbus driver is a bus driver for various paravirtualized devices
> >> >> presented within a Unisys s-Par guest environment.  Drivers for these
> >> >> devices are also currently present under drivers/staging/unisys/, which we
> >> >> intend to also move out of staging immediately after visorbus.  All of
> >> >> these other drivers are dependent upon visorbus and the include directory,
> >> >> which is why we would like to move these first.
> >> >> 
> >> >> Our initial consultations with various members of the community have led us
> >> >> to the conclusion that the most appropriate locations for these is:
> >> >>     arch/x86/visorbus/       (driver)
> >> >>     include/linux/visorbus/  (header files)
> >> >> 
> >> >> The rationale is that visorbus is dependent on x86-64 architecture.
> >> >
> >> > What makes it dependent on x86?  What prevents it from running on some
> >> > other architecture (not the fact that no one has made such hardware,
> >> > just the code reasons please.)
> >> 
> >> It's dependent on system firmware which is only available on the S-Par
> >> platform which is x86_64 only. The closest similarity is probably what
> >> you find on the PPC and Sparc platforms.
> >
> > Ok, but still no need to put it under arch/ anything, it should go in
> > drivers/ like all other drivers and busses are, no matter what the arch
> > it happens to run on is.
> 
> I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
> and PPC also have their stuff under arch/.

For some things, yes, but let's not make the same mistakes as others :)

Look at drivers/hv/ for an example of a very x86-only bus and driver
subsystem living in drivers/  Please don't burry driver stuff in arch/
the ARM developers are trying to fix their mistakes of the past and move
all of their cruft out of arch/ for that reason.

thanks,

greg k-h