31 Dec
2021
31 Dec
'21
11:55 a.m.
Thanks for your thoughtful response (and for reading the paper).
This for me is the catch:
*But there is a whole ecosystem of shell scripts, programs, user's finger
macros, etc., that would break if we "made things better" or made things
simpler.*
And of course you're right, but we've known how to roll out breaking
changes in software for a very long time now. And we do so often. Few Unix
programs from the past would compile and run today without being updated to
"modern" interfaces and compilers.
I believe it could be done, and I believe it should be done. Rolled out
carefully and explained well it would please far more than it offends, and
is arguably far closer to correct than the current situation.
Of course, I am not volunteering, sorry. Easy for me to snipe, I admit, but
then I paid my OS dues long ago.
-rob
On Fri, Dec 31, 2021 at 4:16 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike
wrote:
In broad strokes, that's exactly what we did
in Plan 9, with great
results,
as was said here a while back. The paper ended
with a plea to do the same
to Unix, which I think is quite doable.
https://9p.io/sys/doc/lexnames.html
I'm sure it *could* be done. In fact, Linux has a number of the
pieces of the implementations already, which could be reused for a
Plan-9-style lexical namespace. Linux has bind mounts, and a dentry is
essentially a cached directory lookup (it contains a pointer to its
parent dentry, the filename used to do the lookup and a pointer to the
resulting inode). And a struct file contains a struct dentry, which
means in Linux it is possible to determine the path used to open a
particular file. There are some differences of course; so it's not
exact, but I agree with you that it is quite "doable". (In
particular, how Linux dentries and symlinks interact appears to be
different from how Plan 9 and Channels did things, if I understand the
paper correctly.)
The question though, is whether Linux *should* do it. Or rather,
*could* we do it without breaking backwards compatibility with users
and application which expect that dot-dot works the way it does in
classical Unix implementations for the past 4 decades or so.
Granted that the combination of symlinks, and hard links, and in
Linux, bind mounts (not to mention bind namespaces, chroots, and
pivot_root operations), can be confusing. But there is a whole
ecosystem of shell scripts, programs, user's finger macros, etc., that
would break if we "made things better" or "made things simpler".
One of the benefits of research OS's is that you can experiment with
things without having to worry about the howls of angry users when you
break backwards compatibility, or eliminate some particular awkward
API or feature.
- Ted
P.S. For example, how I wish I could eliminate telldir/seekdir, or at
least change things so that telldir/seekdir used a substantially
larger "cookie" to memoize a position in a directory's readdir stream
which has to be valid effectively forever. Today, you can pass a
32-bit telldir cookie to seekdir, and readdir MUST not return a
directory entry that it had already returned, and MUST not skip a
directory entry that was present at the time of the telldir(). Thus
spake POSIX, and there are applications which depend on
telldir/seekdir/readdir having this precise set of semantics
If your directory is stored internally as a linear stream, that's not
too bad; but if you're using a more complex data structure, life gets
interesting. I know of one file system (JFS) which added an extra,
separate, on-disk b-tree structure to each directory just to be able
to provide stable telldir/seekdir cookies. (And of course, there's a
performance impact to needing to update an extra b-tree each time a
directory entry is added or removed.)
With a research OS, it's at least possible to say, "Well, *that* was a
mistake; let's pretend it never happened and let's see how much better
life would be." :-)