[PATCH] deprecate use of bdflush()

[PATCH] deprecate use of bdflush()

[Robert Love]

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;

Re: [PATCH] deprecate use of bdflush()

[Andrew Morton]

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;

_

Re: [PATCH] deprecate use of bdflush()

[Robert Love]

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;

Re: [PATCH] deprecate use of bdflush()

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] deprecate use of bdflush()

[Robert Love]

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

Re: [PATCH] deprecate use of bdflush()

[Paul Gortmaker]

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

Re: [PATCH] deprecate use of bdflush()

[Krzysztof Halasa]

Paul Gortmaker <p_gortmaker@yahoo.com> 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

Re: [PATCH] deprecate use of bdflush()

[Daniel Kobras]

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.

Re: [PATCH] deprecate use of bdflush()

[Robert Love]

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

Re: [PATCH] deprecate use of bdflush()

[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

Re: [PATCH] deprecate use of bdflush()

[Daniel Kobras]

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.

Re: [PATCH] deprecate use of bdflush()

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.