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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:17 EST