From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 16:35:54 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ADB016A403; Tue, 27 Jun 2006 16:35:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA30D43D8D; Tue, 27 Jun 2006 16:35:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5RGXgpk022930; Tue, 27 Jun 2006 10:33:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jun 2006 10:33:43 -0600 (MDT) Message-Id: <20060627.103343.-432837786.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <52322.1151337322@critter.freebsd.dk> References: <20060626.093240.-432837692.imp@bsdimp.com> <52322.1151337322@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:35:54 -0000 In message: <52322.1151337322@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20060626.093240.-432837692.imp@bsdimp.com>, "M. Warner Losh" writes : : : : >: I suspect that the proponents of this scheme will object to my proposal : >: because they can not do a "ls /dev/mumble/*" to get a list of disk : >: serial numbers[...] : > : >I'm curious... what's wrong with adding additional things to the /dev : >directory? One of the biggest annoyances I have in troubleshooting is : >not being able to see what files are there and having magic file names : >that one can open but not list. : : devfs is not a hardware inventory facility, it is magic place for : performing a rendez-vous with a device driver. True, but somewhat irrelvant. This does not go to the question that I asked. What problems does having fully enumerated devices cause? devfs does allow directory listings, therefore absent some compelling reason to the contrary these listings should be complete. This is an enumeration of the available devices, which closely mirrors the available hardware. There are other facilities for finding out the underlying hardware, but there's no way to find the magic names in /dev easily. While it is a magic place, that magic place exists in the context of a file system, and file systems aren't supposed to randomly open files. It is also a security concern. If I wanted to have non-default permissions on these magic nodes, at the very least I'd have no way to audit them. I'm unclear if doing the normal unix operations on the magic nodes would suffice. : We really do not want to prepopulate /dev with all possible devices, : that model broke down in the late 1980ies and it has not become more : feasible in the meantime. You are arguing apples and oranges here. The fully enumerated /dev with all possible device entries based on what the machine might possibly have is not what I'm asking. We all know there are issues with that. My question is more specific. What is wrong with having entries in devfs of files you can actually open, when we know the universe that is possible given the current knowledge of the kernel? Why have some of them hidden and some of them present? Why subject the user to the hassles that having hidden, magic files causes? : The reason people have trouble understanding this very basic point is : that UCB strayed from the UNIX philosophy when they added all the socket : system calls instead of adding the /net filesystem. Again, you are comparing apples to oranges. The current local node cannot know the list of possibilities for nodes on the network. In the specific case that I'm asking about, we do know the possibilities. The number of entries, even on a large system, is relatively small. : If we had /net, everybody would be able to see that non-storage filesystems : should not be prepopulated with every conceiveable vnode. This is true, but irrelevant. There are different design considerations for different types of virtual file systmes. : The automounter is another good example: here quite complex software : was written specifically to avoid prepopulation with all conceiveable : vnodes and mountpoints, that that is even for storage filesystems. This is a bug in the automounter, and has been for a very long time. I've always hated it. My big problem with magic files and hiding them is that it becomes difficult or impossible to diagnose and troubleshoot. They can create security problems, especially if there's no way to audit their existance and attributes. If there's a real, compelling reason to hide the files, I might understand. But so far I've seen no real, compelling reason proffered as to why the kernel can't expose the knowledge that it has in this manner. Warner