public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: Options depending on STANDALONE
@ 2006-08-03 20:49 Brown, Len
  2006-08-03 20:51 ` Greg KH
  2006-08-07 17:33 ` Thomas Renninger
  0 siblings, 2 replies; 11+ messages in thread
From: Brown, Len @ 2006-08-03 20:49 UTC (permalink / raw)
  To: Greg KH, Adrian Bunk
  Cc: Dave Jones, Zachary Amsden, Arjan van de Ven,
	Linux Kernel Mailing List, Linus Torvalds, Andrew Morton,
	Christoph Hellwig, Rusty Russell, Jack Lo, v4l-dvb-maintainer,
	linux-acpi

>On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
>> ACPI_CUSTOM_DSDT seems to be the most interesting case.
>> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
>> people prefer to get the kernel working with all original DSDTs
>> (which usually work with at least one other OS) than letting 
>> the people workaround the problem by using a custom DSDT.
>
>Not true at all.  For SuSE kernels, we have a patch that lets people
>load a new DSDT from initramfs due to broken machines requiring a
>replacement in order to work properly.

CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
by building a modified DSDT into the kernel to over-ride what
came with the system.  It would make no sense for a distro
to use it, unless the distro were shipping only on 1 model machine.
This technique is necessary for debugging, but makes no
sense for production.

The initramfs method shipped by SuSE is more flexible, allowing
the hacker to stick the DSDT image in the initrd and use it
without re-compiling the kernel.

I have refused to accept the initrd patch into Linux many times,
and always will.

I've advised SuSE many times that they should not be shipping it,
as it means that their supported OS is running on modified firmware --
which, by definition, they can not support.  Indeed, one could view
this method as couter-productive to the evolution of Linux --
since it is our stated goal to run on the same machines that Windows
runs on -- without requiring customers to modify those machines
to run Linux.

-Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
* A proposal - binary
@ 2006-08-03 10:14 Zachary Amsden
  2006-08-03 11:16 ` Arjan van de Ven
  0 siblings, 1 reply; 11+ messages in thread
From: Zachary Amsden @ 2006-08-03 10:14 UTC (permalink / raw)
  To: Linux Kernel Mailing List, Linus Torvalds, greg, Andrew Morton,
	Christoph Hellwig, Rusty Russell, Jack Lo

I would like to propose an interface for linking a GPL kernel, 
specifically,
Linux, against binary blobs.  Stop.  Before you condemn this as evil, 
let me
explain in precise detail what a binary blob is.

First, there are two kinds of binary blobs.  There are the evil, malignant
kind, that use manipulative and despicable techniques to subvert the GPL by
copying code into Linux and, the most evil kind, which uses a GPL 
wrapper to
export GPL-only symbols to the binary blob.  This is unconditionally 
wrong.  I
do not support this kind of use.  These evil blobs are used to lock 
people into
a particular type of protocol or proprietary hardware interface.  In my
personal opinion, they should be unconditionally banned, or at least 
phased out
rapidly from any GPL kernel.  I have been frustrated by this in the 
past, where
binary filesystem modules would not allow me access to AFS when 
upgrading to a
new kernel version.  I do not wish that on anyone.

But there is also another kind of binary blob.  These are not the evil, 
nasty
subversion type blobs, but a benign kind that actually exists in binary 
form
not to close off choice, but to open it.  This is exactly the kind of 
binary
interface we are proposing with the VMI design.  Only with a specific
ABI can you guarantee future compatibility.  This is exactly the same thing
I believe some hardware vendors are trying to do.  When you have a fairly
complex interaction with the hardware layer, you have a lot of code which
suddenly becomes hardware dependent.  When that hardware is actually 
changing
rapidly, you have a serious problem keeping released drivers for that 
hardware
in sync.  Software release cycles are becoming much longer, and 
delivering new
capabilities to average consumers outside of that software release cycle 
is a
very difficult problem to solve.  As a result, vendors build some smarts 
into
the hardware - a firmware piece that can be loaded and actually run on the
processor.  This firmware allows the same driver to be used for many 
different
versions of the hardware, allowing a single software release to support
multiple versions of yet to be released hardware.  It is only natural to 
run
this privileged software inside a privileged context - the kernel.

In our case, this "hardware" is actually the virtual machine.  We must deal
with changes to the underlying hardware, as they are happening rapidly, 
and we
must support future compatibility for customers that decide to start 
using a
virtual machine in 2006 - it is a virtual machine, after all, and it should
continue running in 2016, no matter what the underlying hardware at that 
time
will look like.  In this sense, we have an even larger future compatibility
problem to solve than most hardware vendors.  So it is critical to get an
interface that works now.

The essence of our interface is a separation between the kernel, and the
hypervisor compatibility layer, which we call the VMI.  This layer is
completely separate from the kernel, and absolutely cannot be compiled 
into the
kernel.  Why?  Because doing so negates all of the benefits this layer is
supposed to provide.  It is separate from the kernel not to lock anyone 
into a
proprietary design or prevent anyone from distributing a working 
kernel.  It is
separate to allow the hypervisor backend to change radically without
introducing any changes whatsoever into the kernel.  This is absolutely
required for future compatibility - with new versions of each hypervisor 
being
released regularly, and new competing hypervisors emerging, it is a 
necessity.
This allows the hypervisor development process, as well as the Linux kernel
development process, to continue unimpeded in the face of rapid change 
on each
side.  Having an open binary interface encourages growth and competition in
this area, rather than locking anyone into a proprietary design.  It 
also does
not stop anyone from distributing a working, fully source compiled 
kernel in
any circumstance I can imagine.  If you don't have the firmware for a 
VE-10TB
network card compiled into your kernel, but also don't have a VE-10TB 
network
card, you haven't been deprived of anything, and have very little to 
complain
about.  Provided, of course, that when you do buy a VE-10TB network 
card, it
happily provides the required firmware to you at boot time.

On the other hand, the GPL is not friendly to this type of linking against
binary fragments that come from firmware.  But they really, absolutely, 
must be
separate from the kernel.  There is no argument against this from a feature
point of view.  But there is also no reason that they must be 
binary-only.  The
interface between the two components surely must be binary - just as the
interface between userspace and the kernel, or between the apps and 
glibc must
be binary.  This means the code from one layer is visible to the other 
purely
as a binary "blob".  But not an evil one.  And by NO circumstances, is it
required to be a CLOSED source binary blob.  In fact, why can't it be 
open?  In
the event of a firmware bug, in fact, it is very desirable to have this
software be open so that it can be fixed - and reflashed onto the card, 
where
the firmware belongs.

Let me illustrate the major differences between an "evil" binary blob, a
typical vendor designed hardware support layer, a well designed, open 
binary
interface, and a traditional ROM or extensible firmware layer.  I think you
will see why our VMI layer is quite similar to a traditional ROM, and very
dissimilar to an evil GPL-circumvention device.  I can't truly speak for 
the
video card vendors who have large binary modules in the kernel, but I would
imagine I'm not far off in my guesses, and they can correct me if I am 
wrong.

                                         EVIL    VENDOR     VMI      ROM
Module runs at kernel privilege level:     YES       YES     YES    
MAYBE (*)
Module is copied into the kernel:          YES     MAYBE      NO       NO
Module is part of kernel address space:    YES       YES      NO(+)    ??
Module has hooks back into kernel:         YES     MAYBE      NO       NO
Kernel has hooks into module:              YES       YES     YES      YES
Module has proprietary 3rd party code:   MAYBE     MAYBE(?)   NO      YES
Module has significant software IP:        YES     MAYBE(?)   NO    
MAYBE (?)
Module is open source:                      NO     MAYBE   MAYBE       NO

(*) In the ROM case, sometimes these are run in V8086 mode, not at full
hardware privilege level, and whether the < 1MB physical ROM region is 
part of
the "kernel" address space proper, or just happens to appear in kernel 
address
space as a result of linear mapping of physical space is a debatable 
matter.

(+) The VMI layer is not technically part of the kernel address space.  
It is
never mapped by the kernel, and merely exists magically hanging out in 
virtual
address space above the top of the fixmap, in hypervisor address space.  
But it
can be read and called into by the kernel, so whether this constitutes 
being
part of the same address space is a dicey matter of precise definition.  
I would
propose that only supervisor level pages that are allocated, mapped and
controlled by the kernel constitute the kernel address space, or 
alternately,
the kernel address space consists of the linear range of virtual address 
space
for which it can create supervisor-level mappings.

(?) There are only two reasonable objections I can see to open sourcing the
binary layer.  One is revealing IP by letting people see the code.  This is
really a selfish concern, not a justification for keeping the code 
binary only,
while still allowing it the privilege of running in the kernel address 
space.
The other objection I see is if that code has 3rd party pieces in it 
that are
unable to be licensed under an open software license.  This really is a 
hard
stopper for open sourcing the code, as the vendor doesn't actually own the
copyright, and thus can't redistribute that code under a different 
license.  We
don't have any such restrictions, as we wrote all our code ourselves, 
but many
ROMs and firmware layers do have such problems.  ROMs might also have 
some IP
in the form of trade secrets protecting power management or other 
features run
in SMM mode - but this is just a guess.  And IANAL - so take all this 
with a
grain of salt, it is purely my uninformed personal opinion.

This brings me to the essence of my proposal - why not allow binary 
"blobs" to
be linked inside Linux, in exactly the same way modules are linked?  If 
these
binary modules are actually open sourced, but separate from the kernel, is
there no reason they can't actually link against GPL symbols within Linux?
What if these modules exposed an ELF header which had exactly the same
information as a typical module?  In this case, kernel version is not 
relevant,
as these modules are truly kernel independent, but device/module version 
is.
The biggest issue is that the source and build environment to these 
modules is
not the standard environment -- in fact many of these binary modules 
might have
extremely bizarre build requirements.  We certainly do.  But still there
remains no reason that a well encapsulated build environment and open 
source
distribution of these modules cannot exist.  We are actively working on 
this for
our VMI layer.  Perhaps a good solution to this problem would be to 
provide a
link embedded in the binary which points to a URL where this environment 
can be
downloaded and built - or even fully buildable compressed source within the
binary itself for most friendly binaries with plenty of space to burn.
There may be other issues which I may not be aware of on our end, but that
has no bearing on finding out what the Linux and open source community 
wants.

I propose this as a solution because I would like to see binary (only) 
blobs go
away, and I would never again like to see hardware vendors design stupid 
code
which relies on firmware in the operating system to initialize a hardware
device (can I say WinModem?) which is not published and open code.  The 
point
of an interface like this is to open and standardize things in a way that
vendors can benefit from a hardware abstraction layer, and to make sure 
that
the GPL is not violated in the process of doing so.  I would very much 
like to
see Linux come up with a long term proposal that can accommodate open 
firmware
which actually runs in kernel mode, while at the same time assuring that 
this
code is authorized within the license boundaries afforded to it and 
available
for use by any operating system.

Thank you very much for your patience - I can get verbose, and I've already
gone too long.  This is still a very controversial issue, and I wanted to
clarify several points that merit attention before dooming myself to 
enduring
the yet to come flames.  Again, I must say IANAL, and I can't promise
that VMware or any other hardware vendor that wants to use a binary
interface will agree to everything I have proposed.  But I would like to
open the issue for discussion and get feedback from the open source 
community
on this issue, which I think will become more important in the future.

Zach

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-08-08 10:56 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-03 20:49 Options depending on STANDALONE Brown, Len
2006-08-03 20:51 ` Greg KH
2006-08-03 21:01   ` Dave Jones
2006-08-03 21:41     ` Greg KH
2006-08-07 17:33 ` Thomas Renninger
2006-08-07 17:56   ` Greg KH
2006-08-07 18:46   ` Eric Piel
2006-08-08 11:00   ` Thomas Renninger
  -- strict thread matches above, loose matches on Subject: below --
2006-08-03 10:14 A proposal - binary Zachary Amsden
2006-08-03 11:16 ` Arjan van de Ven
2006-08-03 18:08   ` Zachary Amsden
2006-08-03 19:03     ` Greg KH
2006-08-03 19:14       ` Zachary Amsden
2006-08-03 19:36         ` Greg KH
2006-08-03 19:56           ` Dave Jones
2006-08-03 20:25             ` Options depending on STANDALONE Adrian Bunk
2006-08-03 20:28               ` Greg KH
2006-08-03 20:41                 ` Dave Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox