From owner-freebsd-current Fri Feb 9 14:41:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA21011 for current-outgoing; Fri, 9 Feb 1996 14:41:08 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA20995 for ; Fri, 9 Feb 1996 14:41:04 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id OAA00618; Fri, 9 Feb 1996 14:40:54 -0800 From: Julian Elischer Message-Id: <199602092240.OAA00618@ref.tfs.com> Subject: Re: FS PATCHES: THE NEXT GENERATION To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 9 Feb 1996 14:40:53 -0800 (PST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <21606.823904510@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 02:21:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > > I think that *not* requiring the implementation of the persistance > > facility (think netbooting, again) prior to deployment of a mandatory > > devfs is a *major* incentive to cause the feature to be added by the > > people who feel they need it. The lag on the developement of the > > ability to save "boot -c" data after "boot -c" was implemented was not > > an inherently bad thing. > > But -c was never a critical part of the system, and certainly not > *mandatory*. I remain unconvinced by your arguments, I'm afraid. > > I don't think that devfs should ever be *mandatory* until the current > semantics, which are known even if not necessarily loved by a > generation of UNIX hackers, are preserved. Let's make it optional, > sure, but mandatory? In its proposed form? You've got to be > kidding. > > Jordan > I plan on it being default, though not mandatory at this time, however I think that it duplicates the known semantics enough to make it mandatory. I think that the persistance factor is a security issue and can be dealt with by the use of a special tool to handle the issue. As I said, it's possible that syslog might be used for loging these changes, however I think that the persistance argument is in fact a red herring. Devices are not a property of a filesystem and have no purpose being in such. Devices are a property of the particular hardware/System and puting devices in the filesystem is a semantically broken concept. DMR once said that it was done that way because they couldn't afford the memory to impliment a flexible dynamic method on a pdp11. What does plan 9 do?