(was slashes, now NFS devices)

[David Zink]

lm at slovax.Berkeley.EDU (Larry McVoy) edifies me:
>
> Two points you've misunderstood:

> Suppose we have #define TIOCFOO 0x1234 on the client and I try and send that
> to a remote device on a system with different byte order. What should happen?
> Obviously, (you will say), the server or the client should rewack it into the

I would never say a thing like that.  It is precisely bogus solutions like that
that have caused UN*X to be such a mishmash of hacks.  Like special options
in tar to handle the same thing.

( Painfully enough, rereading this, I was thinking 'bezerkely hacks', and
started thinking about the connection between sun products and ucb. Only
_afterwards_ did I notice your new posting address.)

> appropriate byte order.  OK, what if the server has #define TIOCFOO 0x12, in
> other words, a short.  Now what should happen?  Obviously, (you say) there

A char.  The first example could have been adequately contained in a short.
(Except on Z-80's etc.;)
Have you never noticed that major and minor numbers vary in size under
different OS's?

> should be a lookup table that translates from one machine to another machine,
> using the string "TIOCFOO".  Now, maybe, you begin to understand the problem.

Ooh, a solution using strcmp.  If the correct form of solution hasn't occurred
to you yet, keep thinking.

For some reason string solutions are popular, but that doesn't keep them from
being stupid.  They're just a sort of sleazy way of avoiding name space
collisions by extending the resolution of the identifier, while pretending that
something useful is being accomplished.

If n different machines are connected in a network, the number of translation
programs involved is what, O(n2)? Sounds like too much work.

Or this sort of assumes a single server and a bunch of clients.

> matter what version of Unix is running (good luck, I believe this to be 

Wasn't the whole point of this discussion about the NON-UNIX interfaces?

> These sorts of problems are why we have programs like rdump/rrestore.  They
> use a generalized interface that will work across different OS releases, 

This, of course, is the correct avenue.

The point you're missing is that this sort of translation is already being
done.  When I do a read on the HP from the PC file-server, NFS neatly
converts my 4-byte ints to 2-byte ints. This is because NFS provides a file
level translation.  But no-one will ever get to organize the same thing for
devices because NFS has already screened out that possibility.  Instead of
leaving room for advancement, they have guaranteed that when someone finally
gets around to fixing NFS it won't be by changing unimplemented features to
implemented ones, it will be by changing the nature of the beast.

Better to have defined a byte ordering, etc. that was reasonable, and identical
to that on some popular other brand of computer (or better yet, parts from
several different competitors) and used that as the default method of
transmission across NFS.  After all ioctls are system calls, byte swapping is
cheap by comparison.

Then of course you could use awk to fix all your system source and presto,
hope for the future!

On the brighter side here is an SCO-ODT, NFS & SymLink anecdote.

A friend had logged onto his SCO-ODT and run dos.  He then chdir'ed to a
directory of mine and run some editor on a .c file.  Unfortunately, the file
was a symbolic link, and when he brought it up in the editor, all it had was
the link information.  So with some amusement we proceded to edit the link
and save it. Everything went smoothly, except that the resulting symbolic
link contained a terminating new-line. We can't remember what editor it was,
so we haven't been sure we are unable to reproduce it. I suspect x-tree . . . .
I assume that the NFS server on the HP-9000 was smart enough to reinterpret
writing to a symbolic link as just another 'ln -s'.

Anyway don't moan about how hard it is to write. Why, unix is hard to write,
yet here it is, working just purrfectly ;) Seriously, the point is not to get
it perfect the first time, but to leave openings for the future, and to code
as closely to proper behaviour as you can.

So many times people have decided to accept some gross limitation just because
'No one will ever exceed that limit'.  I remember a disaster prevention
program that crashed on october 1st because 10 has two digits and they had
only allowed one for the month.

Correct design practice is to leave a clear and convenient upgrade path, and
in this the device issue is a clear failing of NFS design.

> different byte orders, etc.  I would welcome a proposal, accepted by all the
> vendors, that generalized remote device access.  I think this would be a good
> thing, if it was done right.  It's a hard thing to get right.  Go to it.

This was my favorite part of the whole shebang.  YOU would be WILLING to
welcome the proposal, IF it's already accepted by ALL the vendors?

_How_ Generous!

Still, since ALL the vendors already LOVE NFS the way it is, I guess we'll
just have to learn to live with it.

--David Zink