From owner-freebsd-current  Tue May 18 20: 0:36 1999
Delivered-To: freebsd-current@freebsd.org
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
	by hub.freebsd.org (Postfix) with ESMTP id E91AE150C9
	for <current@FreeBSD.ORG>; Tue, 18 May 1999 20:00:31 -0700 (PDT)
	(envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA31984;
	Wed, 19 May 1999 13:00:24 +1000
Date: Wed, 19 May 1999 13:00:24 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199905190300.NAA31984@godzilla.zeta.org.au>
To: bright@rush.net, current@FreeBSD.ORG
Subject: Re: nodump is not a dump routine.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>i'm wondering why when the system dumpdev is set to a device that 
>doesn't have a read dump routine (nodump()) why it lies about the
>dump being successful.

Just another bug.

>Index: kern_shutdown.c
>===================================================================
>RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
>retrieving revision 1.52
>diff -u -r1.52 kern_shutdown.c
>--- kern_shutdown.c	1999/05/12 22:30:46	1.52
>+++ kern_shutdown.c	1999/05/19 00:38:43
>@@ -387,6 +387,10 @@
> 	printf("dump ");
> 	switch ((*bdevsw(dumpdev)->d_dump)(dumpdev)) {
> 
>+	case ENODEV:
>+		printf("device has no dump routine\n");
>+		break;
>+

Also, the default case should print "failed", and only the 0 case
should print "succeeded".

>shouldn't 
>src/sys/i386/i386/autoconf.c, and
>src/sys/alpha/alpha/autoconf.c decline to set the dump device
>to a device that has nodump() as its dump routine?

setdumpdev() probably shouldn't know so much about the dump routine.
The driver can easily have a routine that fails when it is actually
called for reasons that setdumpdev() can't know.  Perhaps nodump
should be simply ((d_dump_t)NULL).  dumpsys() already checks for a
null d_dump pointer before calling it, although setdumpdev() doesn't.

>one other question, considering the newbus stuff, shouldn't
>there be a way to get the text string of the dump device somehow
>so "dumpon" with no arguments can print out the current value
>without scanning /dev for a device that matches it?

This was broken by "newsysctl", not by newbus.  In Lite1, the CONSDEV
sysctl is specially handled and the device number is converted to a name
using devname(3).  Newsysctl neglects to convert to a name, and can't in
general, since it has no way of knowing if the device is a cdev or a bdev.

devname() is also broken.  ISTR it has some fundamental problems, and it
now returns NULL instead of the documented "??" when it can't determine
the device name.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message