[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0610241354280.11608@yvahk01.tjqt.qr>
Date: Tue, 24 Oct 2006 13:59:27 +0200 (MEST)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Zan Lynx <zlynx@....org>
cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Giridhar Pemmasani <pgiri@...oo.com>
Subject: Re: incorrect taint of ndiswrapper
>
>The kernel itself links GPL code to non-GPL via the Posix API (the
>syscall layer). The kernel also links GPL code to non-GPL via the PCI
>layer (all that proprietary firmware on the other side). The
>ndiswrapper links GPL code to non-GPL via the NDIS API.
>
>No difference, really.
Behind the syscall layer is userspace (the well known ring 3), which, all bugs
and problems aside, and exceptions like ioperm ruled out, cannot crash the
kernel.
I am not too aware about firmware and how it affects the running kernel, but
usually it is a binary blob that gets loaded into the PCI device. May or may
not crash the kernel - as said, I am not too aware of how it can tamper with
the kernel.
NDIS code however is, unlike the above, run unconditionally in superprivileged
level (ring 0), which quite distinct from userspace or firmwarespace[note
warning above].
Lastly, there is the new IIO code, which sounds like it is a well-defined (you
name it) interface, to userspace however.
If Windows drivers could run in userspace, there would not be a problem, would
there be?
> Implementing a well-defined interface
>abstraction layer doesn't make either side of it derived from the other.
>(Exactly how well-defined, how abstract, and how derived are all
>arguments for the lawyers.)
>--
>Zan Lynx <zlynx@....org>
>
-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists