From owner-freebsd-hackers  Wed May  1 22:49:54 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA22277
          for hackers-outgoing; Wed, 1 May 1996 22:49:54 -0700 (PDT)
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA22264
          for <hackers@freebsd.org>; Wed, 1 May 1996 22:49:51 -0700 (PDT)
Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id RAA04376; Mon, 29 Apr 1996 17:11:16 -0700 (PDT)
Message-Id: <199604300011.RAA04376@ref.tfs.com>
Subject: Re: devfs policy question.
To: terry@lambert.org (Terry Lambert)
Date: Mon, 29 Apr 1996 17:11:16 -0700 (PDT)
From: "JULIAN Elischer" <julian@ref.tfs.com>
Cc: hackers@freebsd.org
In-Reply-To: <199604292232.PAA05343@phaeton.artisoft.com> from "Terry Lambert" at Apr 29, 96 03:32:03 pm
X-Mailer: ELM [version 2.4 PL25 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 
> [ ... Keep in mind, these represent my opinions, not necessarily
>       those of the FreeBSD core team ... ]
> 
> 
> > What should devfs do to a device that is open when
> > the driver requests that it be deleted?
> 
> Refuse the delete with "EBUSY".

The driver wants to delete it because it has been physically removed....

> 
> > what should happen to the vnode for /devfs/rsd1s1d if the slice code
> > decides that that device makes no sense any more, but there is a reference
> > because a process somewhere has it open.. (what if it's mounted?)?
> 
> This is a "device departure event"... I assume this is for removable
> media of some kind?
possibly.. (or a repartitionning)
> 
> For devices with lockable eject, the eject should be locked while the
> device is mounted.
> 
> For devices with lockable eject whose "eject" button functions as an
> "eject request" when the device is locked, the "eject request" should
> be interpreted by the mount code as "flush pending device departure;
> disallow subsequent requests".
> 
> > At the moment a vgone() is done on the vnode.
> > is this right?
> 
> No, it's bogus as all get-out.  Pending writes really screw up.
define 'pending'.. and what if the device has already departed..
(e.g. PCMCIA-card been ejected)..

> 
> This wants more comprehensive/consistent device management code.
> 
> > It is dissociated from devfs and vgone (well vclean actually)
> > associates it with the deadfs vnops.
> > 
> > Is this the right thing to do?
> 
> No, this is bogus as well, and had to do with there  *only* being a
> vnode/extent mapping on buffer cache pages, such that valid cache
> pages without an associated vnode are discared and reloaded instead
> of getting a cache hit.

Which I would consider correct if the device was removed..

> This is most obvious in the vclean/VOP_LOCK
> code for vnode locking, and the UFS ihash cache, which operates as a
> "second chance cache" for discarded vnodes fending LRU flush by
> vclean.  This is the true source of the "free vnode isn't" panic.
> 
> > ---------------
> > 
> > Policy question number two
> > should devfs allow the creation of fifo/named pipes?
> > I tend to think yes.... they are dynamic and kinda-like devices
> > 
> > ---------------
> 
> I think no (you must be thinking of syslog?).  This would require
> committing devfs to stable storage, which in turn would mean we could
> not murder specfs (which needs to be murdered).
> 
> IMO, devfs should be non-optional (ie: no specfs, no commit to stable
> storage, kernel mount before "/", etc.).

why would this require commiting to stable storage?

> 
> > Policy question number three

[...[
other answers stored for later processing...