lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 17 May 2016 19:49:53 -0400
From:	Jes Sorensen <>
To:	Greg KH <>
Cc:	David Kershner <>,,,,,,,,,,,,,,,,,,,
Subject: Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

Greg KH <> writes:
> On Tue, May 17, 2016 at 10:01:55AM -0400, Jes Sorensen wrote:
>> Greg KH <> 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/.

I am open, if people prefer to have drivers/visorbus I can support that.
I find right now it's really messy with things being put all over the
place, and it's not obvious what the real placement is for all of this.


Powered by blists - more mailing lists