deprecate use of bdflush()

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
@@ -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;

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.

@@ -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;

_

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
@@ -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;

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.

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

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'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

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

We should of. Now its too late - we cannot start printing evil warnings on existing 2.4 systems.

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

sys_bdflush() is still usable in 2.4 to tune kupdated's parameters. Only func==1 functionality is long gone.

And each time you try to twist the flushing parameters.

Regards,

Daniel.

Right. But the bdflush daemon was gone in 2.4.

There are no flushing parameters in 2.5, and this is a patch for 2.5.

Robert Love

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.

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.