From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4947 invoked from network); 31 Dec 2021 05:56:12 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 05:56:12 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id D16E59D010; Fri, 31 Dec 2021 15:56:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1BF439D006; Fri, 31 Dec 2021 15:55:51 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="OiX5FiuR"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B252C9D006; Fri, 31 Dec 2021 15:55:48 +1000 (AEST) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by minnie.tuhs.org (Postfix) with ESMTPS id AFF3D9D002 for ; Fri, 31 Dec 2021 15:55:45 +1000 (AEST) Received: by mail-pj1-f42.google.com with SMTP id a11-20020a17090a854b00b001b11aae38d6so24924109pjw.2 for ; Thu, 30 Dec 2021 21:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YEa01RGKF8JVYHVNGLJyhEpOLJ7yU31RL2rzpeHtNkg=; b=OiX5FiuRkUBZFHVtI9xSHi7OfMLbHUjNqfM2OIKsBH36cMY6wLiUCFEADygkvfiDIP 32NKkOG6FvcC1T1qD+Zh2//rnUKscqigRGeJlAIr1ylolTL1s7fgxt1nUK0VNWdTdBLH C+Us95H5t903ohJ/QfQt71zWMJ1TE4jSAlG0fMoglLREX5PMi0VYkrJv4wIxb1JF3I6c bIcOg7EGrdZcEDlZOrBJGRRyPwz6yI1w4N7p2veKdIcU9k6a/nnCf4aSYvsBEMndstgR daCT8vIl5v4KvizGCem+BGtEYW1QI/SbjwwFdDVI8SpELeLc3mp7+QwYardnJHUCkTH+ qVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YEa01RGKF8JVYHVNGLJyhEpOLJ7yU31RL2rzpeHtNkg=; b=tHbBgINbOeu+OgjS6/o7ItQTV3UB4wD9RFjX762jhAGKPxRdndWu71k90bwaBl1A/R X7nMrARyA/NmEodk5UcG+z9C11hrhug2Jegt8YXR/tfbg5G/Rq3hw7oNKpSYalFFI7ZT 9bUHP+eTTWGmAxSaxfFpu5t6YUUZzNJUcJKKTweSNaw7WAcu9KXi4uw2KtylXCcNnN7q B10kRcSYaJEj9JMOYFQZHXKS+nwCFCqk3zIYqR5IYrX4cWlWy6U7VdipnUQNcqFO4Xe4 WFmcPaXi9KM1xrGpnry21XB6pXFnNHUdQa+SDOr4/AcsqH+J50Drtqg7V1xm4BMcSThH fvmQ== X-Gm-Message-State: AOAM533aW9jVjbmx0x1evuSo2GTWtK9wdpBQ9sa9EHwrjBjK8eOR2514 GrAahLnXhzgwgaap0tQNUGYdFZOy2kVDG1VFw0Y= X-Google-Smtp-Source: ABdhPJx76i3p4Iul8Nnnqq3s4r+QFz7K7XERy/3vGXlo4p0448hu7+ypLqIrv5f4uYqUq9eEDEPIlzKSVWp4vlLyehI= X-Received: by 2002:a17:90b:4c8c:: with SMTP id my12mr42448742pjb.50.1640930145098; Thu, 30 Dec 2021 21:55:45 -0800 (PST) MIME-Version: 1.0 References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> In-Reply-To: From: Rob Pike Date: Fri, 31 Dec 2021 16:55:34 +1100 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="000000000000665f4005d46ad245" Subject: Re: [TUHS] moving directories in svr2 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Noel Chiappa Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000665f4005d46ad245 Content-Type: text/plain; charset="UTF-8" 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 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." :-) > --000000000000665f4005d46ad245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your thoughtful response (and for reading the p= aper).

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 pa= st would compile and run today without being updated to "modern" = interfaces and compilers.

I believe it could be do= ne, and I believe it should be done. Rolled out carefully and explained wel= l it would please far more than it offends, and is arguably far closer to c= orrect 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@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 s= ame
> to Unix, which I think is quite doable.
>
> https://9p.io/sys/doc/lexnames.html

I'm sure it *could* be done.=C2=A0 In fact, Linux has a number of the pieces of the implementations already, which could be reused for a
Plan-9-style lexical namespace.=C2=A0 Linux has bind mounts, and a dentry i= s
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).=C2=A0 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.=C2=A0 There are some differences of course; so it's no= t
exact, but I agree with you that it is quite "doable".=C2=A0 (In<= br> 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.=C2=A0 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.=C2=A0 But there is a whole
ecosystem of shell scripts, programs, user's finger macros, etc., that<= br> would break if we "made things better" or "made things simpl= er".

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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0- Ted

P.S.=C2=A0 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 readdi= r stream
which has to be valid effectively forever.=C2=A0 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().=C2=A0 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.=C2=A0 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.=C2=A0 (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* w= as a
mistake; let's pretend it never happened and let's see how much bet= ter
life would be."=C2=A0 :-)
--000000000000665f4005d46ad245--