(was slashes, now NFS devices)

[Root Boy Jim]

In <BZS.91Feb22163556 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>
>I don't see the slightest ambiguity or confusion in how NFS should
>interpret special device entries. Obviously they should be interpreted
>relative to the local host only.

Obviously, they belong to the system whose DISK they reside on.
After all, the filehandle does contain the network address,
which is an extension of the device number.

What you say? That's not transparent? It's just as transparent
as creating a file in someone else's directory. Where do you
think it's stored? Obviously on the remote system.

>This is a network FILE system, not a network DEVICE system.

Funny. Rick once said, "It's a network FILE system, not a
network LOCKING system" in response to someone's complaint.
What else is it not? A network IOCTL system? A network
FCNTL system? A network open, then unlink, then reading system?
Oh yeah, that one's been "fixed".

>That one can think of times where it would be convenient to reference
>/dev/tape and have it use the server's tape drive (eg) has nothing
>whatsoever to do with NFS.

Only because of how NFS was designed/evolved/mutated.

>It's merely A NEAT IDEA that might almost work if the world were just
>slightly different. NFS did its job: You opened the string "/dev/tape"
>(or whatever) and your kernel got the major/minor numbers, protection
>etc which is stored in the FILE SYSTEM.

Yes, but it also got an implicit network address.
See the example of creating a file in a remote directory above.

>Mapping that device elsewhere is just a whole other project.

No. The problem is how to get a di?kless WS to treat devices on
the server's disk as its own. Obviously with mount and exportfs options.

>Everyone arguing for this is utterly confusing possible utility with
>intention and design goals. Local interpretation of device specials is
>entirely consistent with NFS's design goals.

How can I disagree with a tautology?

>You can say that it would be handy to have this feature etc etc, but
>calling NFS a kludge for not providing this is like calling grep a
>kludge because it won't remove slashes from filenames. It's just
>nonsense.

I never wanted grep to do that.

>The proper (ahem/IMHBCO) approach to this is just another device type
>in the file system (it could either be totally new, or just some sort
>of new use of a pre-allocated major/minor) which means "I am a remote
>device".

The other way. Mount my root and treat devices as local.
It just so happens that Sun has more di?kless WS than people
who want to use remote devices.

Devices are vulnerable in a any environment, especially a networked one.
One way to increase security is to limit where devices are.
If they're not on my disk, I don't have to worry about them.

>Given that you can deal with all the crap having to do with "remote on
>what system?", and permissions and error handling and all that.
>
>But just whacking it into NFS is the kludge.

Anything done to a kluge remains a kluge.

The more I use NFS, the more I hate it.
Statelessness? What crap!
Idempotent operations with datagrams?
Truly sad.

But perhaps the worst thing is trashing UNIX semantics
in order to bend over backwards for other systems.
Perhaps options for dealing with foreign systems
would have been better.

Now RFS itself is a nightmare too. I'd like to see RFS
semantics in NFS clothing.

I hate to agree with the bellboys, but people,
wake up and see the evils of NFS.

I hope UCB did a better job.
-- 
		[rbj at uunet 1] stty sane
		unknown mode: sane