We can never get rid of it if we do not deprecate it - so do so and
print a stern warning to those who still run bdflush daemons.
Patch is against 2.5.49-mm2. Please apply.
Robert Love
fs/buffer.c | 6 ++++++
1 files changed, 6 insertions(+)
diff -urN linux-2.5.49-mm2/fs/buffer.c linux/fs/buffer.c
--- linux-2.5.49-mm2/fs/buffer.c 2002-12-02 16:07:53.000000000 -0500
+++ linux/fs/buffer.c 2002-12-02 16:17:16.000000000 -0500
@@ -2757,11 +2757,17 @@
/*
* There are no bdflush tunables left. But distributions are
* still running obsolete flush daemons, so we terminate them here.
+ *
+ * Use of bdflush() is deprecated and will be removed in a future kernel.
+ * The `pdflush' kernel threads fully replace bdflush daemons and this call.
*/
asmlinkage long sys_bdflush(int func, long data)
{
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
+
+ printk(KERN_WARNING "warning: the bdflush system call is deprecated "
+ "and no longer needed. Stop using it.\n");
if (func == 1)
do_exit(0);
return 0;
Robert Love wrote:
>
> We can never get rid of it if we do not deprecate it - so do so and
> print a stern warning to those who still run bdflush daemons.
>
Ho-hum. I was going to do this months ago but general exhaustion
and sluggishness won out.
We should tell the user which process called sys_bdflush() to aid
their expunging efforts.
--- 25/fs/buffer.c~deprecate-bdflush Mon Dec 2 13:40:44 2002
+++ 25-akpm/fs/buffer.c Mon Dec 2 13:45:11 2002
@@ -2755,11 +2755,25 @@ int block_sync_page(struct page *page)
/*
* There are no bdflush tunables left. But distributions are
* still running obsolete flush daemons, so we terminate them here.
+ *
+ * Use of bdflush() is deprecated and will be removed in a future kernel.
+ * The `pdflush' kernel threads fully replace bdflush daemons and this call.
*/
asmlinkage long sys_bdflush(int func, long data)
{
+ static int msg_count;
+
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
+
+ if (msg_count < 5) {
+ msg_count++;
+ printk(KERN_INFO
+ "warning: process `%s' used the obsolete bdflush"
+ " system call\nFix your initscripts?\n",
+ current->comm);
+ }
+
if (func == 1)
do_exit(0);
return 0;
_
On Mon, 2002-12-02 at 17:11, Andrew Morton wrote:
> Ho-hum. I was going to do this months ago but general exhaustion
> and sluggishness won out.
>
> We should tell the user which process called sys_bdflush() to aid
> their expunging efforts.
Good idea.
I could do without the rate limiting, though - the print is after the
CAP_SYS_ADMIN check. Root has plenty of other ways to print crap to the
screen and it saves 32-bits from bss. But, uh, not a big deal at all
either way.
Robert Love
fs/buffer.c | 7 +++++++
1 files changed, 7 insertions(+)
diff -urN linux-2.5.49-mm2/fs/buffer.c linux/fs/buffer.c
--- linux-2.5.49-mm2/fs/buffer.c 2002-12-02 16:07:53.000000000 -0500
+++ linux/fs/buffer.c 2002-12-02 17:24:57.000000000 -0500
@@ -2757,11 +2757,18 @@
/*
* There are no bdflush tunables left. But distributions are
* still running obsolete flush daemons, so we terminate them here.
+ *
+ * Use of bdflush() is deprecated and will be removed in a future kernel.
+ * The `pdflush' kernel threads fully replace bdflush daemons and this call.
*/
asmlinkage long sys_bdflush(int func, long data)
{
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
+
+ printk(KERN_WARNING "warning: process `%s' used the deprecated bdflush"
+ " system call. Fix your initscripts?\n",
+ current->comm);
if (func == 1)
do_exit(0);
return 0;
On 2 Dec 2002, Robert Love wrote:
> On Mon, 2002-12-02 at 17:11, Andrew Morton wrote:
>
> > Ho-hum. I was going to do this months ago but general exhaustion
> > and sluggishness won out.
> >
> > We should tell the user which process called sys_bdflush() to aid
> > their expunging efforts.
>
> Good idea.
>
> I could do without the rate limiting, though - the print is after the
> CAP_SYS_ADMIN check. Root has plenty of other ways to print crap to the
> screen and it saves 32-bits from bss. But, uh, not a big deal at all
> either way.
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.
While it's possible to do version dependent things in init scripts, in
this case there is no need, the call hurts nothing. Some users may post to
the list asking what it means, and others may actually do it, and break
their production systems.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
Besides, you only see the message once for each daemon that is loaded.
So regardless of the rate limiting you probably only see it once on
boot.
Robert Love
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 <[email protected]>
Message-Id: <[email protected]>
In-Reply-To: Paul Gortmaker's message as of Dec 22, 3:13
To: Paul Gortmaker <[email protected]>, [email protected]
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
On Tue, Dec 03, 2002 at 12:10:01PM -0500, Robert Love wrote:
> 2.4 does not need bdflush, either.
>
> Bdflush the user-space daemon went away a long time ago, ~1995.
sys_bdflush() is still usable in 2.4 to tune kupdated's parameters.
Only func==1 functionality is long gone.
> Besides, you only see the message once for each daemon that is loaded.
> So regardless of the rate limiting you probably only see it once on
> boot.
And each time you try to twist the flushing parameters.
Regards,
Daniel.
Paul Gortmaker <[email protected]> writes:
> 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 :)
So why don't we print the warning with 2.4 as well?
intrepid:~/CVS$ rpm -qi bdflush
Name : bdflush Relocations: (not relocateable)
Version : 1.5 Vendor: Red Hat, Inc.
Release : 21 Build Date: Sun Jun 23 16:19:27 2002
And it's run by /etc/inittab.
I don't know if returning -EINVAL (= removing the call completely in 2.5)
isn't better, though - does it have any compatibility implications?
--
Krzysztof Halasa
Network Administrator
On Tue, 2002-12-03 at 20:12, Krzysztof Halasa wrote:
> So why don't we print the warning with 2.4 as well?
We should of. Now its too late - we cannot start printing evil warnings
on existing 2.4 systems.
> I don't know if returning -EINVAL (= removing the call completely in 2.5)
> isn't better, though - does it have any compatibility implications?
Right now the call forces a do_exit(), so the application terminates.
If we just returned `-EINVAL' the application might sit around doing
nothing.
Robert Love
On Wed, 2002-12-04 at 08:10, Daniel Kobras wrote:
> > Bdflush the user-space daemon went away a long time ago, ~1995.
>
> sys_bdflush() is still usable in 2.4 to tune kupdated's parameters.
> Only func==1 functionality is long gone.
Right. But the bdflush daemon was gone in 2.4.
> > Besides, you only see the message once for each daemon that is loaded.
> > So regardless of the rate limiting you probably only see it once on
> > boot.
>
> And each time you try to twist the flushing parameters.
There are no flushing parameters in 2.5, and this is a patch for 2.5.
Robert Love
On Wed, Dec 04, 2002 at 11:12:42AM -0500, Robert Love wrote:
> There are no flushing parameters in 2.5, and this is a patch for 2.5.
I'm aware of that. And I'm not opposed to the patch, but I'm opposed to
the notion that sys_bdflush as a whole has been useless for ages. E.g.
noflushd[1] on 2.4 happily calls it every five seconds. Count this as a
vote for rate limiting the message, for the benefit of folks switching
between 2.4 and 2.5.
Regards,
Daniel.
[1] Admittedly a bad example as it won't start on 2.5 anyway, but there
might be similar codes around.
On 4 Dec 2002, Robert Love wrote:
> On Wed, 2002-12-04 at 08:10, Daniel Kobras wrote:
>
> > > Bdflush the user-space daemon went away a long time ago, ~1995.
> >
> > sys_bdflush() is still usable in 2.4 to tune kupdated's parameters.
> > Only func==1 functionality is long gone.
>
> Right. But the bdflush daemon was gone in 2.4.
It's not *gone* it's just moved into the kernel...
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 0 5 1 15 0 0 0 bdflus SW ? 0:00 [bdflush]
Clearly it doesn't need the syscall interface, so as long as there's a way
to tune useful parameters the interface isn't needed. Don't know why I
thought I was doing stuff using that.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.