From: Jamie Lokier <jamie@shareable.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Using GPL'd Linux drivers with non-GPL, binary-only kernel
Date: Tue, 6 May 2003 23:18:19 +0100 [thread overview]
Message-ID: <20030506221819.GC6284@mail.jlokier.co.uk> (raw)
In-Reply-To: <20030506204305.GA5546@elf.ucw.cz>
Pavel Machek wrote:
> If you can make those drivers in your userspace, its certainly okay...
Agreed. Now, what is userspace?
If I load a Java class into a Java VM, that class is executing in the
VM's "userspace", even though both the class and VM execute together
in the underlying kernel's userspace. If I load an Emacs Lisp library
into Emacs, that's ok too in the same way.
I don't want to go over this old argument of where the interface
boundaries are. That's a very old argument and thoroughly off topic
for this list.
What I want to know is the reasonableness of using Linux drivers,
filesystems and network stack, extracted from the Linux kernel, in
something that is not Linux and not necessarily GPL'd, using a very
clear _virtual_ boundary between the Linux parts and the not GPL'd part.
Running User Mode Linux on HP-UX would be an example which I think is
clearly acceptable. (Note that User Mode Linux doesn't access devices
directly, but perhaps it could with some changes).
I have in mind a virtual machine which is capable of executing device
drivers written in an appropriate subset of the C language, in which
wrappers for Linux (and BSD) drivers can be written, so the Java and
Emacs VM examples above are quite appropriate.
This seems reasonable to me, although it also seems like quite a
perversion of Linux to fragment it into GPL'd parts atop a non-GPL'd
kernel, which is why I had to (being a pervert :) mention the idea on
this list.
-- Jamie
next prev parent reply other threads:[~2003-05-06 22:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 16:42 Jamie Lokier
2003-05-06 17:35 ` Alan Cox
2003-05-06 18:54 ` Jamie Lokier
2003-05-06 19:28 ` Jean-Marc Lienher
2003-05-06 19:53 ` Alan Cox
2003-05-06 22:31 ` Jamie Lokier
2003-05-06 21:38 ` Alan Cox
2003-05-08 21:36 ` Pavel Machek
2003-05-06 19:17 ` Eric W. Biederman
2003-05-06 21:55 ` Jamie Lokier
2003-05-06 22:21 ` David Schwartz
2003-05-07 8:21 ` Eric W. Biederman
2003-05-07 14:25 ` Valdis.Kletnieks
2003-05-07 14:31 ` Jamie Lokier
2003-05-07 15:50 ` Eric W. Biederman
2003-05-06 20:43 ` Pavel Machek
2003-05-06 22:18 ` Jamie Lokier [this message]
2003-05-06 21:31 ` Alan Cox
2003-05-06 22:48 ` Jamie Lokier
2003-05-07 12:20 ` Alan Cox
2003-05-07 14:26 ` Jamie Lokier
2003-05-07 15:18 ` Pavel Machek
2003-05-08 11:11 ` Krzysztof Halasa
[not found] <20030506165014$3d57@gated-at.bofh.it>
[not found] ` <20030506193019$0d29@gated-at.bofh.it>
[not found] ` <20030506220018$5b96@gated-at.bofh.it>
2003-05-07 1:17 ` Tony 'Nicoya' Mantler
[not found] <BKEGKPICNAKILKJKMHCAAEBCCLAA.Riley@Williams.Name>
2003-05-07 16:57 ` Eric W. Biederman
2003-05-09 1:23 Jean Tourrilhes
2003-05-13 9:08 Dean McEwan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030506221819.GC6284@mail.jlokier.co.uk \
--to=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®