From: Rusty Russell <rusty@rustcorp.com.au>
To: Alexander Viro <viro@math.psu.edu>
Cc: Doug Ledford <dledford@redhat.com>,
Linux Scsi Mailing List <linux-scsi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Why /dev/sdc1 doesn't show up...
Date: Wed, 20 Nov 2002 08:29:52 +1100 [thread overview]
Message-ID: <20021120072654.3EE7A2C08B@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 19 Nov 2002 02:12:54 CDT." <Pine.GSO.4.21.0211190116420.27757-100000@steklov.math.psu.edu>
In message <Pine.GSO.4.21.0211190116420.27757-100000@steklov.math.psu.edu> you
write:
> Wrong granularity. "module had finished initialization" is _not_ a natural
> event wrt stuff exported by that module.
Well, I have to disagree here. "I have successfully finished my
initialization" is the same logic you're trying to beat into module
author's heads before they commit their interfaces.
> And that's one of the main problems I have with your approach - you
> are trying to make module loader do the stuff that has nothing
> whatsoever with modules.
Or, put another way, I'm trying to ensure that correct code in the
kernel is correct code in a module, by having the module code simulate
the conditions in which the original occurred.
> Moreover, if driver is built into the kernel, you get (at the very least)
> a different mechanism for triggering the same events, if not the outright
> different sequence of events. Which is a Bad Thing(tm) since it leads to
> a shitload of extra problems with debugging.
Speaking of which, what's the long-term plan for hotplug events at
boot? Will you get a shitload of "add" events, or rely on userspace
to scan?
> Double freeing. Forgetting to free. Dereference after freeing. Leaving
> timers active. Leaving pointers to local structures in global arrays.
Hmm, my audit of copy_to/from_user uncovered similar bogosities, and
I've dropped more than one Trivial Patch Monkey patches because they
cleaned up one case in an incurable sewer of problems 8(
The "better to have a bad driver than no driver" becomes less true as
people start copying from it, too. This is where meta-maintainers
like Jeff Garzik make a definite difference as chief shit-kicker.
> On that background all shite you are so concerned about is a noise.
Perhaps. But I can't change the world: that's your job.
> What we _can_ do (and that will be on per-subsystem basis) is providing
> APIs that would cut down on the amount of glue needed in driver init.
Fervently agree: it's hard to get one line wrong, *and* almost any
scheme can be implemented on top of it.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-11-20 7:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-19 5:52 Rusty Russell
2002-11-19 7:12 ` Alexander Viro
2002-11-19 21:29 ` Rusty Russell [this message]
2002-11-19 22:33 ` Andries Brouwer
2002-11-19 16:06 ` Doug Ledford
2002-11-19 17:55 ` Jeff Garzik
2002-11-19 21:42 ` Rusty Russell
2002-11-20 23:41 ` john slee
-- strict thread matches above, loose matches on Subject: below --
2002-11-17 19:52 Doug Ledford
2002-11-17 20:01 ` Alexander Viro
2002-11-17 20:12 ` Doug Ledford
2002-11-17 20:16 ` Alexander Viro
2002-11-17 23:20 ` Andries Brouwer
2002-11-17 23:45 ` Doug Ledford
2002-11-18 8:52 ` Rusty Russell
2002-11-18 9:51 ` Alexander Viro
2002-11-18 23:49 ` Rusty Russell
2002-11-19 0:08 ` Linus Torvalds
2002-11-19 20:54 ` Rusty Russell
2002-11-20 15:45 ` Linus Torvalds
2002-11-24 22:30 ` Rusty Russell
2002-11-19 0:09 ` Doug Ledford
2002-11-19 20:58 ` Rusty Russell
2002-11-19 0:32 ` Alan Cox
2002-11-18 10:02 ` Roman Zippel
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=20021120072654.3EE7A2C08B@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=dledford@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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®