From: Paul Gortmaker <p_gortmaker@yahoo.com>
To: Robert Love <rml@tech9.net>
Cc: Bill Davidsen <davidsen@tmr.com>, Andrew Morton <akpm@digeo.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] deprecate use of bdflush()
Date: Tue, 03 Dec 2002 14:05:26 -0500 [thread overview]
Message-ID: <3DED0076.55B970DD@yahoo.com> (raw)
In-Reply-To: 1038935401.994.9.camel@phantasy
Robert Love wrote:
>
> On Tue, 2002-12-03 at 09:24, Bill Davidsen wrote:
>
> > My take on this is that it's premature. This would be fine in the 2.6.0-rc
> > series, but the truth is that the majority of 2.5 users boot 2.5 for
> > testing but run 2.4 for normal use. They aren't going to get rid of
> > bdflush and this just craps up the logs. At least with the occurrence
> > limit it will only happen a few times. I would like to see it once only,
> > myself, as a reminder rather than a nag.
>
> 2.4 does not need bdflush, either.
>
> Bdflush the user-space daemon went away a long time ago, ~1995.
Yes, removal is not premature; long overdue if anything. At the risk
of overlapping Andries' job as official historian, I found this in my
archive of cruft. So it was almost 1996 :)
Paul.
--
Date: Fri, 22 Dec 1995 07:59:40 +0200
From: Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>
Message-Id: <199512220559.HAA25383@keos.cs.Helsinki.FI>
In-Reply-To: Paul Gortmaker's message as of Dec 22, 3:13
To: Paul Gortmaker <gpg109@rsphy1.anu.edu.au>, linux-kernel@vger.rutgers.edu
Subject: Re: Ramdisk fixes for 1.3.49
Status: RO
Paul Gortmaker: "Ramdisk fixes for 1.3.49" (Dec 22, 3:13):
>
> I don't know if anyone noticed, but I came across this while impementing
> the CONFIG_BLK_DEV_RAM.
>
> The new ramdisk code has an ugly hack (IMHO) where it uses the global
> variable rd_loading for the *sole purpose* of blocking the
>
> "Warning - bdflush not running."
>
> message (buffer.c) while loading the image off of the floppy. Eeecch.
> Rather than have this ramdisk dependant cruft in buffer.c, I fixed this
> in a much better fashion. The solution is simple. We just call
> sync_dev(ramdisk) ourselves every so often while writing the floppy
> contents to the ramdisk. By doing this, wakeup_bdflush() never gets
> tripped, and thus no "Warning - bdflush not running." messages pop out.
> And buffer.c doesn't get touched. Nice and clean.
I'd prefer it even more if you'd just start "bdflush" instead.
I know that user-level isn't running yet, but it should be reasonably
trivial to do
kernel_thread(sys_bdflush, NULL);
and off you go.. Could you try this instead? I'd be happer (this is how
bdflush should have been started in the first place, but back when
bdflush was done there were no easy access to kernel threads..)
(oh, btw, in the meantime I applied this set of patches, because they
are better than it used to be. But I'd be grateful for a new set on top
of this that does the above, hint, hint).
Linus
next prev parent reply other threads:[~2002-12-03 19:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-02 21:21 [PATCH] deprecate use of bdflush() Robert Love
2002-12-02 22:11 ` Andrew Morton
2002-12-02 22:26 ` Robert Love
2002-12-03 14:24 ` Bill Davidsen
2002-12-03 17:10 ` Robert Love
2002-12-03 19:05 ` Paul Gortmaker [this message]
2002-12-04 1:12 ` Krzysztof Halasa
2002-12-04 16:11 ` Robert Love
2002-12-04 13:10 ` Daniel Kobras
2002-12-04 16:12 ` Robert Love
2002-12-04 19:29 ` Daniel Kobras
2002-12-05 17:39 ` Bill Davidsen
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=3DED0076.55B970DD@yahoo.com \
--to=p_gortmaker@yahoo.com \
--cc=akpm@digeo.com \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
/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;
as well as URLs for NNTP newsgroup(s).