Date: Mon, 29 Apr 1996 17:11:16 -0700 (PDT) From: "JULIAN Elischer" <julian@ref.tfs.com> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: devfs policy question. Message-ID: <199604300011.RAA04376@ref.tfs.com> In-Reply-To: <199604292232.PAA05343@phaeton.artisoft.com> from "Terry Lambert" at Apr 29, 96 03:32:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > [ ... 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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604300011.RAA04376>