From owner-cvs-all  Tue May 12 12:48:10 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA10734
          for cvs-all-outgoing; Tue, 12 May 1998 12:48:10 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA10542;
          Tue, 12 May 1998 12:47:53 -0700 (PDT)
          (envelope-from luoqi@watermarkgroup.com)
Received: by watermarkgroup.com (4.1/SMI-4.1)
	id AA29566; Tue, 12 May 98 15:47:23 EDT
Date: Tue, 12 May 98 15:47:23 EDT
From: luoqi@watermarkgroup.com (Luoqi Chen)
Message-Id: <9805121947.AA29566@watermarkgroup.com>
To: bde@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG,
        cvs-sys@FreeBSD.ORG
Subject: Re:  cvs commit: src/sys/i386/i386 autoconf.c src/sys/kern kern_shutdown.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

> bde         1998/05/12 10:34:04 PDT
> 
>   Modified files:
>     sys/i386/i386        autoconf.c 
>     sys/kern             kern_shutdown.c 
>   Log:
>   Backed out previous commit.  It is invalid to call d_ioctl() on
>   possibly non-open devices, and we don't want to restrict dumping
>   to swap devices anwyay.  It is especially invalid to call d_ioctl()
>   in non-process context for panics.  d_psize() can be called on
>   non-open devices, at least on non-SLICED ones that support d_dump(),
>   and setdumpdev() has depended on this for a long time although it
>   is probably wrong, but even d_psize() can't be called in non-process
>   context - that's why dumpsys() depends on previously computed values
>   although these values may be stale.  The historical restriction to
>   devices with dkpart(dev) == SWAP_PART should go away.
>   
>   Revision  Changes    Path
>   1.97      +2 -5      src/sys/i386/i386/autoconf.c
>   1.31      +3 -8      src/sys/kern/kern_shutdown.c
> 
I know it is a kludge when I submit. But the specific ioctl (DIOCGPART)
is only intended to be called (if I understand correctly) from a kernel
context, so absence of a process context shouldn't really matter. As to
calling d_ioctl on non-open devices, I have to admit it's inapporiate.
But again for the DIOCGPART ioctl, it is no more evil than calling d_psize
or d_dump -- they all make the same assumption (i.e. slices are initialized).

The previous commit is necessary to enable dump for a SLICE kernel. An
alternative would be to get rid of the bogus swap partition check. One
has to be extremely careful not to point dump dev to a fs partition after
this safty check is gone.

We will still have problem with d_dump and d_psize for device that has
never been opened (and thus slices not initialized) unless we switch to
a SLICE kernel. Or call dsinit() in an interrupt hook just as what the
slice device does.

-lq

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