From: Tim Hockin <thockin@hockin.org>
To: James Clark <jimwclark@ntlworld.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Discourage Uniform Driver Model
Date: Mon, 15 Sep 2003 16:26:52 -0700 [thread overview]
Message-ID: <20030915162651.A27457@hockin.org> (raw)
In-Reply-To: <200309160013.38466.jimwclark@ntlworld.com>; from jimwclark@ntlworld.com on Tue, Sep 16, 2003 at 12:13:38AM +0100
On Tue, Sep 16, 2003 at 12:13:38AM +0100, James Clark wrote:
> I understand the way competitor binary interfaces work. Currently I'm not
> going to roll up my sleeves and write this system. I don't have the technical
> expertise to design such a thing and although I could learn the curve at this
> time is too steep. I do think that my experience with similar competitor
> systems allows me to speak on the subject. However, I feel that pushing for
> this change is a positive thing. It has started a debate on 'misusing' the
> GPL to prevent binary only modules and has resulted in some positive
> comments. If they debate it rationally and then decide not to bother I will
> have achieved a lot. I do feel qualified to make this (obvious) suggestion
> and comment on the design of any resulting interface.
I and others have repeatedly pointed out the big failings in this, which you
have ignored.
To do this means you must freeze the size of any structure passed across the
kernel-module boundary. You must freeze any functions which are in-lined.
spin_lock() must not have debugging code which is enabled by a CONFIG_
option, or it must become a function call. You can never optimize away
stuff that only matters on SMP systems. You can never have a structure
include members conditionally upon CONFIG_ options, or you have to provide
accessor functions for every field of every struct.
This is what you are not getting. Because module code is a first-class
citizen in Linux, you CAN'T decouple them, without imposing BIG UGLY
restrictions on all modules. Do you understand the examples I am giving
you? I can be more explicit, if you like.
Now, if you, or someone can devise a cleanish way to do it, SHOW US CODE.
It doesn't have to work fully, just enough to convince us it could work AT
ALL.
I assert that any solution will have one or more of the following
attributes, any of which are unacceptable:
* will perform terribly
* will be cumbersome to code
* will impose new restrictions on kernel developers
* will be unmaintainable
I BEG YOU to prove me wrong.
--
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books. Cause and effect,
or merely an ironic juxtaposition of unrelated facts?
next prev parent reply other threads:[~2003-09-15 23:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-13 23:27 Discourage Uniform Driver Model? James Clark
2003-09-13 23:45 ` Dr. David Alan Gilbert
2003-09-14 20:38 ` James Clark
2003-09-14 21:06 ` Valdis.Kletnieks
2003-09-14 22:11 ` Alan Cox
2003-09-15 23:13 ` Discourage Uniform Driver Model James Clark
2003-09-15 23:26 ` Tim Hockin [this message]
2003-09-16 14:01 ` Timothy Miller
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=20030915162651.A27457@hockin.org \
--to=thockin@hockin.org \
--cc=jimwclark@ntlworld.com \
--cc=linux-kernel@vger.kernel.org \
/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®