From: Jamie Lokier <jamie@shareable.org>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: "Adam J. Richter" <adam@yggdrasil.com>,
linux-fsdevel@vger.kernel.org,
Mike Waychison <Michael.Waychison@Sun.COM>
Subject: Re: DEVFS_FS
Date: Wed, 17 Nov 2004 18:28:34 +0000 [thread overview]
Message-ID: <20041117182834.GA6999@mail.shareable.org> (raw)
In-Reply-To: <OFC79B70FC.F87418BC-ON85256F4F.0060DFEC-88256F4F.0064712C@us.ibm.com>
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
next prev parent reply other threads:[~2004-11-17 18:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-16 6:09 DEVFS_FS Adam J. Richter
2004-11-16 19:08 ` DEVFS_FS Mike Waychison
2004-11-16 19:26 ` DEVFS_FS Jamie Lokier
2004-11-16 19:42 ` DEVFS_FS Greg KH
2004-11-16 19:48 ` DEVFS_FS Mike Waychison
2004-11-17 18:19 ` DEVFS_FS Bryan Henderson
2004-11-17 18:28 ` Jamie Lokier [this message]
2004-11-16 19:47 ` DEVFS_FS Bryan Henderson
-- strict thread matches above, loose matches on Subject: below --
2004-11-13 16:29 DEVFS_FS Adam J. Richter
2004-11-15 19:35 ` DEVFS_FS Bryan Henderson
2004-11-11 20:24 DEVFS_FS Adam J. Richter
2004-11-11 19:53 DEVFS_FS Adam J. Richter
2004-11-11 23:00 ` DEVFS_FS Bryan Henderson
2004-11-12 5:55 ` DEVFS_FS Jamie Lokier
2004-11-12 18:50 ` DEVFS_FS Bryan Henderson
2004-11-10 20:46 DEVFS_FS linux-os
2004-11-10 21:03 ` DEVFS_FS Alexandre Costa
2004-11-11 0:06 ` DEVFS_FS Gene Heskett
2004-11-11 0:19 ` DEVFS_FS Greg KH
2004-11-11 6:01 ` DEVFS_FS Gene Heskett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041117182834.GA6999@mail.shareable.org \
--to=jamie@shareable.org \
--cc=Michael.Waychison@Sun.COM \
--cc=adam@yggdrasil.com \
--cc=hbryan@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.