From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: DEVFS_FS Date: Wed, 17 Nov 2004 18:28:34 +0000 Message-ID: <20041117182834.GA6999@mail.shareable.org> References: <20041116192647.GA19365@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Adam J. Richter" , linux-fsdevel@vger.kernel.org, Mike Waychison Return-path: Received: from mail.shareable.org ([81.29.64.88]:16516 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S262417AbUKQS3k (ORCPT ); Wed, 17 Nov 2004 13:29:40 -0500 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: > >In other words, if /dev were auto-generated based on all available > >hardware > > Bear in mind that "all available hardware" may be a set completely > impossible to ascertain. Consider a computer attached to the Internet > that uses ISCSI devices. There would need to be a /dev entry for every > ISCSI logical unit on the Internet. I agree, that is neither feasible nor useful. That's what I meant by the qualifier "to the extent that is possible". We have the same problem with virtual filesystems like httpfs or bittorrentfs: You can't list files in them, except for files the system already knows about. > I find the strategies fall into two major categories: 1) addressing; and > 2) discovery. With addressing, the user identifies the device in such a > way that the system knows everything it needs to find it (or find that no > such device exists). Like identifying a web page by URL. With discovery, > the user identifies the device in a way that doesn't suggest how to reach > it, like identifying a tape drive by the volume ID of the currently > mounted tape. That's a useful distinction to highlight. There are devices that only work nicely in one or other model. -- Jamie