NetBSD Problem Report #1781
From gnats Wed Nov 22 20:35:12 1995
Received: from sun-lamp.pc.cs.cmu.edu by pain.lcs.mit.edu (8.6.12/8.6.9) with ESMTP id UAA14885 for <gnats-bugs@pain.lcs.mit.edu>; Wed, 22 Nov 1995 20:30:02 -0500
Message-Id: <199511230130.UAA01462@sun-lamp.pc.cs.cmu.edu>
Date: Wed, 22 Nov 1995 20:30:00 -0500
From: "Chris G. Demetriou" <cgd@NetBSD.ORG>
Reply-To: cgd@NetBSD.ORG
To: gnats-bugs@gnats.netbsd.org
Subject: 'magic' symbolic link expansion
X-Send-Pr-Version: 3.95
>Number: 1781
>Category: kern
>Synopsis: system-specific special expansions in symlinks.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: thorpej
>State: closed
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Nov 22 20:50:08 +0000 1995
>Closed-Date: Thu Jun 23 00:37:20 +0000 2005
>Last-Modified: Thu Dec 29 01:20:01 +0000 2005
>Originator: Chris G. Demetriou
>Release: 19951122
>Organization:
Kernel Hackers 'r' Us
>Environment:
System: NetBSD sun-lamp.pc.cs.cmu.edu 1.0A NetBSD 1.0A (SUN_LAMP) #9: Wed Nov 22 16:05:06 EST 1995 cgd@sun-lamp.pc.cs.cmu.edu:/usr/src/sys/arch/i386/compile/SUN_LAMP i386
>Description:
Expansion of 'special' strings in symlinks into system-specific
values is a very useful feature in some situations, like:
(1) when booting diskless clients (to help find various
configuration files, etc., when sharing the same
root partition), and
(2) when trying to mount root from a CD-ROM that
contains binaries for several architectures.
NetBSD currently has no such facility, and, because of the
problems with doing multiple-architecture CD-ROMs, it arguably
should. I've implemented solution that enables "magic"
symlink expansion on a per-file system basis. They are enabled
by mounting a file system with the 'magiclinks' mount option,
which sets the MNT_MAGICLINKS mount flag.
On file systems with the MNT_MAGICLINKS flag set, the name
lookup code replaces the "magic" strings in symlinks with
the appropriate replacement text. Magic strings are
of the form "@name", and must end at the end of a pathname
component. That is, assuming "@foo" is a valid magic
string, symlinks containing:
"@foo" would be matched
"@foo/bar" would be matched
"bar@foo" would be matched
"@foobar" would not be matched
etc. The entire "@name" string is replaced by the
replacement text. If, for some reason the replacement
text is empty, the string will be replaced by an
empty string. This can lead to strange results
if the magic string is the only thing in the symlink,
but they're the same as you get when using a sylink
that points to "" (i.e. which is empty).
To get this behaviour for the root file system at
'mountroot' time, the ROOTFS_MAGICLINKS kernel option
is provided. If used, the root file system will be
mounted with MNT_MAGICLINKS set.
The "magic strings" that are supported by my implementation
(the diff for which is included below) are:
@machine_arch value of MACHINE_ARCH for the system.
@machine value of MACHINE for the system.
@hostname the system hostname, as set
with sethostname().
@osrelease the release number of the OS
as defined in /sys/conf/newvers.sh
(e.g. "1.1" for NetBSD 1.1)....
@kernel_ident the kernel config file name
as defined in /sys/conf/newvers.sh
(e.g. "GENERIC" for the kernel
compiles from a kernel config named
"GENERIC")
@domainname the system domainname, as set
with setdomainname().
@ostype the name of the OS. For NetBSD,
this is "NetBSD". I've included
this so that if other operating
systems use this code, they can
fill in their own OS name.
This could, for instance,
make alternately booting NetBSD
and FreeBSD on a single disk
easier.
As noted, if this is picked up for NetBSD, it'd be nice to see
other OS's use the same magic strings and semantics, if not
the same implementation, if they desire similar functionality.
>How-To-Repeat:
[ Not applicable. ]
>Fix:
Apply the following patch. (NOTE: if you don't have
the patch in pr 1776 applied to your /bin/sh, it
will do bad things when traversing 'magic' symlinks.)
The files changed by the patch are:
sys/sys/mount.h
add MNT_MAGICLINKS flag.
sbin/mount/mntopts.h
sbin/mount/mount.c
add a mapping between the 'magiclinks' mount
option and the MNT_MAGICLINKS mount flag.
sys/kern/vfs_lookup.c
do magic link substitution for symlinks on file
systems that have MNT_MAGICLINKS set.
sys/kern/vfs_syscalls.c
Recognize the MNT_MAGICLINKS options, and
allow it to be used.
sys/kern/init_main.c
implement ROOTFS_MAGICLINKS.
sys/conf/newvers.sh
add 'kernel_ident' variable, to support
@kernel_ident.
bin/ln/symlink.7
lib/libc/sys/mount.2
sbin/mount/mount.8
documentation.
Index: bin/ln/symlink.7
===================================================================
RCS file: /a/cvsroot/src/bin/ln/symlink.7,v
retrieving revision 1.3
diff -c -r1.3 symlink.7
*** symlink.7 1995/03/21 09:06:13 1.3
--- symlink.7 1995/11/23 01:04:57
***************
*** 412,417 ****
--- 412,464 ----
or
.Fl P
options.
+ .Sh MAGIC SYMLINKS
+ Symlinks in file systems with the
+ .Li MNT_MAGICLINKS
+ flag set have
+ .Dq magic
+ patterns in symlinks expanded. Those patterns begin with
+ .Dq @
+ (an at-sign), and end at the end of the pathname component
+ (i.e. at the next
+ .Dq / ,
+ or at the end of the symbolic link if there are no more slashes).
+ The following patterns are supported:
+ .Bl -tag -width @machine_arch
+ .It @domainname
+ Expands to the machine's domain name, as set by
+ .Xr setdomainname 3 .
+ .It @hostname
+ Expands to the machine's host name, as set by
+ .Xr sethostname 3 .
+ .It @kernel_ident
+ Expands to the name of the
+ .Xr config 8
+ file used to generate the running kernel.
+ .It @machine
+ Expands to the value of
+ .Li MACHINE
+ for the system (also, the same as
+ .Xr make 1 's
+ .Li ${MACHINE}
+ variable).
+ .It @machine_arch
+ Expands to the value of
+ .Li MACHINE_ARCH
+ for the system (also, the same as
+ .Xr make 1 's
+ .Li ${MACHINE_ARCH}
+ variable).
+ .It @osrelease
+ Expands to the operating system release of the running kernel.
+ .It @ostype
+ Expands to the operating system type of the running kernel.
+ (This will always be
+ .Dq NetBSD
+ for
+ NetBSD
+ systems.)
+ .El
.Sh SEE ALSO
.Xr chflags 1 ,
.Xr chgrp 1 ,
***************
*** 426,431 ****
--- 473,479 ----
.Xr rm 1 ,
.Xr tar 1 ,
.Xr lstat 2 ,
+ .Xr mount 2 ,
.Xr readlink 2 ,
.Xr rename 2 ,
.Xr unlink 2 ,
Index: lib/libc/sys/mount.2
===================================================================
RCS file: /a/cvsroot/src/lib/libc/sys/mount.2,v
retrieving revision 1.9
diff -c -r1.9 mount.2
*** mount.2 1995/10/12 15:41:07 1.9
--- mount.2 1995/11/23 01:04:58
***************
*** 78,83 ****
--- 78,89 ----
may be specified to
suppress default semantics which affect file system access.
.Bl -tag -width MNT_SYNCHRONOUS
+ .It Dv MNT_MACIGLINKS
+ Expand special strings (beginning with
+ .Dq @ )
+ when traversing symbolic links. See
+ .Xr symlink 7
+ for a list of supported strings.
.It Dv MNT_RDONLY
The file system should be treated as read-only;
Even the super-user may not write on it.
Index: sbin/mount/mntopts.h
===================================================================
RCS file: /a/cvsroot/src/sbin/mount/mntopts.h,v
retrieving revision 1.3
diff -c -r1.3 mntopts.h
*** mntopts.h 1995/03/18 14:56:59 1.3
--- mntopts.h 1995/11/23 01:04:58
***************
*** 43,48 ****
--- 43,49 ----
/* User-visible MNT_ flags. */
#define MOPT_ASYNC { "async", 0, MNT_ASYNC }
+ #define MOPT_MAGICLINKS { "magiclinks", 0, MNT_MAGICLINKS }
#define MOPT_NODEV { "dev", 1, MNT_NODEV }
#define MOPT_NOEXEC { "exec", 1, MNT_NOEXEC }
#define MOPT_NOSUID { "suid", 1, MNT_NOSUID }
***************
*** 74,79 ****
--- 75,81 ----
MOPT_USERQUOTA, \
MOPT_GROUPQUOTA, \
MOPT_FSTAB_COMPAT, \
+ MOPT_MAGICLINKS, \
MOPT_NODEV, \
MOPT_NOEXEC, \
MOPT_NOSUID, \
Index: sbin/mount/mount.8
===================================================================
RCS file: /a/cvsroot/src/sbin/mount/mount.8,v
retrieving revision 1.11
diff -c -r1.11 mount.8
*** mount.8 1995/07/12 06:23:21 1.11
--- mount.8 1995/11/23 01:04:58
***************
*** 128,133 ****
--- 128,139 ----
.Fl f ;
forces the revocation of write access when trying to downgrade
a filesystem mount status from read-write to read-only.
+ .It magiclinks
+ Expand special strings (beginning with
+ .Dq @ )
+ when traversing symbolic links. See
+ .Xr symlink 7
+ for a list of supported strings.
.It nodev
Do not interpret character or block special devices on the file system.
This option is useful for a server that has file systems containing
Index: sbin/mount/mount.c
===================================================================
RCS file: /a/cvsroot/src/sbin/mount/mount.c,v
retrieving revision 1.24
diff -c -r1.24 mount.c
*** mount.c 1995/11/18 03:34:29 1.24
--- mount.c 1995/11/23 01:04:58
***************
*** 90,95 ****
--- 90,96 ----
{ MNT_EXPORTANON, 1, "anon uid mapping" },
{ MNT_EXRDONLY, 1, "exported read-only" },
{ MNT_LOCAL, 0, "local" },
+ { MNT_MAGICLINKS, 0, "magiclinks" },
{ MNT_NODEV, 0, "nodev" },
{ MNT_NOEXEC, 0, "noexec" },
{ MNT_NOSUID, 0, "nosuid" },
Index: sys/conf/newvers.sh
===================================================================
RCS file: /a/cvsroot/src/sys/conf/newvers.sh,v
retrieving revision 1.17
diff -c -r1.17 newvers.sh
*** newvers.sh 1994/07/10 22:26:35 1.17
--- newvers.sh 1995/11/23 01:05:00
***************
*** 54,58 ****
--- 54,59 ----
"char version[] = \
\"${ost} ${osr} (${id}) #${v}: ${t}\\n ${u}@${h}:${d}\\n\";" \
>> vers.c
+ echo "char kernel_ident[] = \"${id}\";" >> vers.c
echo `expr ${v} + 1` > version
Index: sys/kern/init_main.c
===================================================================
RCS file: /a/cvsroot/src/sys/kern/init_main.c,v
retrieving revision 1.78
diff -c -r1.78 init_main.c
*** init_main.c 1995/10/07 06:28:05 1.78
--- init_main.c 1995/11/23 01:05:00
***************
*** 296,301 ****
--- 296,304 ----
if ((*mountroot)())
panic("cannot mount root");
mountlist.cqh_first->mnt_flag |= MNT_ROOTFS;
+ #ifdef ROOTFS_MAGICLINKS
+ mountlist.cqh_first->mnt_flag |= MNT_MAGICLINKS;
+ #endif
mountlist.cqh_first->mnt_op->vfs_refcount++;
/* Get the vnode for '/'. Set fdp->fd_fd.fd_cdir to reference it. */
Index: sys/kern/vfs_lookup.c
===================================================================
RCS file: /a/cvsroot/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.15
diff -c -r1.15 vfs_lookup.c
*** vfs_lookup.c 1995/03/08 01:20:50 1.15
--- vfs_lookup.c 1995/11/23 01:05:00
***************
*** 42,47 ****
--- 42,48 ----
#include <sys/param.h>
#include <sys/systm.h>
+ #include <sys/kernel.h>
#include <sys/syslimits.h>
#include <sys/time.h>
#include <sys/namei.h>
***************
*** 56,61 ****
--- 57,64 ----
#include <sys/ktrace.h>
#endif
+ int symlink_magic __P((char *cp, int *len));
+
/*
* Convert a pathname into a pointer to a locked inode.
*
***************
*** 184,190 ****
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
! if (linklen + ndp->ni_pathlen >= MAXPATHLEN) {
if (ndp->ni_pathlen > 1)
free(cp, M_NAMEI);
error = ENAMETOOLONG;
--- 187,199 ----
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
! /*
! * Do symlink substitution, if appropriate, and
! * check length for potential overflow.
! */
! if ((ndp->ni_vp->v_mount->mnt_flag & MNT_MAGICLINKS
! && symlink_magic(cp, &linklen)) ||
! (linklen + ndp->ni_pathlen >= MAXPATHLEN)) {
if (ndp->ni_pathlen > 1)
free(cp, M_NAMEI);
error = ENAMETOOLONG;
***************
*** 205,210 ****
--- 214,307 ----
vput(ndp->ni_vp);
ndp->ni_vp = NULL;
return (error);
+ }
+
+ /*
+ * Substitute replacement text for 'magic' strings in symlinks.
+ * Returns 0 if successful, and returns non-zero if an error
+ * occurs. (Currently, the only possible error is running
+ * out of temporary pathname space.)
+ *
+ * Looks for "@<string>" and "@<string>/", where <string> is a
+ * recognized 'magic' string. Replaces the "@<string>" with
+ * the appropriate replacement text. (Note that in some
+ * cases the replacement text may have zero length.)
+ *
+ * This would have been table driven, but the variance in
+ * replacement strings (& replacement string lengths) made
+ * that impractical.
+ */
+
+ #define MATCH(str) \
+ ((i + (sizeof(str) - 1) == *len) || \
+ ((i + (sizeof(str) - 1) < *len) && \
+ (cp[i + sizeof(str) - 1] == '/'))) && \
+ !strncmp((str), &cp[i], sizeof(str) - 1)
+
+ #define SUBSTITUTE(m, s, sl) \
+ if ((newlen + (sl)) > MAXPATHLEN) \
+ return (1); \
+ i += sizeof(m) - 1; \
+ bcopy((s), &tmp[newlen], (sl)); \
+ newlen += (sl); \
+ change = 1;
+
+ int
+ symlink_magic(cp, len)
+ char *cp;
+ int *len;
+ {
+ char tmp[MAXPATHLEN];
+ int change, i, newlen;
+
+ for (change = i = newlen = 0; i < *len; ) {
+ if (cp[i] != '@')
+ tmp[newlen++] = cp[i++];
+ else {
+ i++;
+ /*
+ * The following checks should be ordered
+ * according to frequency of use.
+ */
+ if (MATCH("machine_arch")) {
+ SUBSTITUTE("machine_arch", MACHINE_ARCH,
+ sizeof(MACHINE_ARCH) - 1);
+ } else if (MATCH("machine")) {
+ SUBSTITUTE("machine", MACHINE,
+ sizeof(MACHINE) - 1);
+ } else if (MATCH("hostname")) {
+ SUBSTITUTE("hostname", hostname,
+ hostnamelen);
+ } else if (MATCH("osrelease")) {
+ extern char osrelease[];
+
+ SUBSTITUTE("osrelease", osrelease,
+ strlen(osrelease));
+ } else if (MATCH("kernel_ident")) {
+ extern char kernel_ident[];
+
+ SUBSTITUTE("kernel_ident", kernel_ident,
+ strlen(kernel_ident));
+ } else if (MATCH("domainname")) {
+ SUBSTITUTE("domainname", domainname,
+ domainnamelen);
+ } else if (MATCH("ostype")) {
+ extern char ostype[];
+
+ SUBSTITUTE("ostype", ostype,
+ strlen(ostype));
+ } else
+ tmp[newlen++] = '@';
+ }
+ }
+
+ if (!change)
+ return (0);
+
+ bcopy(tmp, cp, newlen);
+ *len = newlen;
+
+ return (0);
}
/*
Index: sys/kern/vfs_syscalls.c
===================================================================
RCS file: /a/cvsroot/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.59
diff -c -r1.59 vfs_syscalls.c
*** vfs_syscalls.c 1995/11/11 22:00:18 1.59
--- vfs_syscalls.c 1995/11/23 01:05:02
***************
*** 228,236 ****
else if (mp->mnt_flag & MNT_RDONLY)
mp->mnt_flag |= MNT_WANTRDWR;
mp->mnt_flag &=~ (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV |
! MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC);
mp->mnt_flag |= SCARG(uap, flags) & (MNT_NOSUID | MNT_NOEXEC |
! MNT_NODEV | MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC);
/*
* Mount the filesystem.
*/
--- 228,237 ----
else if (mp->mnt_flag & MNT_RDONLY)
mp->mnt_flag |= MNT_WANTRDWR;
mp->mnt_flag &=~ (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV |
! MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | MNT_MAGICLINKS);
mp->mnt_flag |= SCARG(uap, flags) & (MNT_NOSUID | MNT_NOEXEC |
! MNT_NODEV | MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC |
! MNT_MAGICLINKS);
/*
* Mount the filesystem.
*/
Index: sys/sys/mount.h
===================================================================
RCS file: /a/cvsroot/src/sys/sys/mount.h,v
retrieving revision 1.44
diff -c -r1.44 mount.h
*** mount.h 1995/11/11 22:00:21 1.44
--- mount.h 1995/11/23 01:05:03
***************
*** 119,125 ****
};
/*
! * Mount flags.
*
* Unmount uses MNT_FORCE flag.
*/
--- 119,125 ----
};
/*
! * Mount flags: FLAGS MAY BE OUT OF ORDER, for backward compatibility.
*
* Unmount uses MNT_FORCE flag.
*/
***************
*** 130,135 ****
--- 130,136 ----
#define MNT_NODEV 0x00000010 /* don't interpret special files */
#define MNT_UNION 0x00000020 /* union with underlying filesystem */
#define MNT_ASYNC 0x00000040 /* file system written asynchronously */
+ #define MNT_MAGICLINKS 0x00008000 /* interpret symlinks for magic names */
/*
* exported mount flags.
>Release-Note:
>Audit-Trail:
From: Greg Hudson <ghudson@mit.edu>
To: cgd@NetBSD.ORG
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Wed, 22 Nov 1995 22:31:48 EST
Three notes:
1. AFS already has an expansion @sys to the AFS sysname (which is of a
form like "i386_nbsd1"), if that expansion results in a file that
already exists.
2. AFS's expansion takes place at the nami level. Why did you choose
to implement this change at symlink expansion time? It seems
illogical that I can't type "foo/@machine_arch/bar" by hand, but I can
make a symlink in the current directory and it will work fine.
3. After using AFS for three and a half years, I've decided that @sys
expansions are more trouble than they're worth (although the trouble
they cause is quite subtle, and the advantages are very obvious). So
I would tend to recommend against incorporating this change in any
form.
(The main trouble caused by @sys expansions is that programs, scripts,
or users will reference symlinks which go through @sys, and it will
fail to work on a system with a different @sys value even though the
operation would have succeeded if the program, script, or user were
using the canonical name for the file. A common example is Linux
binaries running under NetBSD's Linux emulation.)
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: cgd@NetBSD.ORG, gnats-bugs@gnats.netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Wed, 22 Nov 1995 22:43:33 -0500
> 1. AFS already has an expansion @sys to the AFS sysname (which is of a
> form like "i386_nbsd1"), if that expansion results in a file that
> already exists.
yes, i know that; i deliberately avoided @sys for just that reason.
> 2. AFS's expansion takes place at the nami level. Why did you choose
> to implement this change at symlink expansion time? It seems
> illogical that I can't type "foo/@machine_arch/bar" by hand, but I can
> make a symlink in the current directory and it will work fine.
I did it at the 'namei' level as well. I did it differently, for a
bunch of reasons.
First, the semantics seem a lot cleaner, to me, if the 'magic' is only
present in symlinks.
Second, it's _much_ _much_ easier and cleaner to implement the
substitution as part of symlink handling.
> 3. After using AFS for three and a half years, I've decided that @sys
> expansions are more trouble than they're worth (although the trouble
> they cause is quite subtle, and the advantages are very obvious). So
> I would tend to recommend against incorporating this change in any
> form.
>
> (The main trouble caused by @sys expansions is that programs, scripts,
> or users will reference symlinks which go through @sys, and it will
> fail to work on a system with a different @sys value even though the
> operation would have succeeded if the program, script, or user were
> using the canonical name for the file. A common example is Linux
> binaries running under NetBSD's Linux emulation.)
The good point about my change is that it completely avoids the
problem as you've stated it.
first, people can enable or disable the symlink expansion on a
per-filesystem basis (let alone not bothering to create symlinks that
use 'magic' in the first place 8-).
second, programs can't use the 'magic' directly, because "cd @hostname"
won't work in any case.
Additionally, i don't see how your example is actually an example, and
would appreciate a more concrete one.
I'm not necessarily arguing for this feature's inclusion. I provided
it because i think many people will find it useful. If that's the
case, then it's in NetBSD's best interest to include it, some would
say.
cgd
From: Greg Hudson <ghudson@mit.edu>
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Wed, 22 Nov 1995 23:16:46 EST
> Additionally, i don't see how your example is actually an example,
> and would appreciate a more concrete one.
Concrete example: suppose someone wants to install netscape in some
place (I'll call it /mit/infoagents). Since netscape has no site
default files, the installer uses a wrapper script. In the name of
easier maintenance, the wrapper script is actually the same for all
platforms, and it runs "/mit/infoagents/bin/netscape.real" to find the
real binary to run. /mit/infoagents/bin is a symlink to
arch/@sys/bin. Everything works fine until you try to run the Linux
"netscape" under NetBSD's Linux emulation, at which point things
gratuitously fail because /mit/infoagents/bin doesn't point to the
right place.
I claim that the right answer is to have the wrapper script be
different for each platform, and know the canonical name for the real
binary on the platform it's installed from. This answer may seem like
more of a maintenance hassle, but if you actually have a source tree
(which you should), a Makefile that automates performing the relevant
substitutions, it's certainly no worse than intalling a binary, and
not necessarily worse than having the script be the same on all
platforms. And it's a more robust answer. It's also an answer
supported by programs which use gnu autoconf, since you have "prefix"
and "exec-prefix", the latter being system-dependent.
There are other cases where things fail besides binary emulation: when
you want to copy the installation into a filesystem that doesn't
support @sys, for example.
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
To: Greg Hudson <ghudson@mit.EDU>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 01:07:53 -0500
> > Additionally, i don't see how your example is actually an example,
> > and would appreciate a more concrete one.
>
> Concrete example: suppose someone wants to install netscape in some
> place (I'll call it /mit/infoagents). Since netscape has no site
> default files, the installer uses a wrapper script. In the name of
> easier maintenance, the wrapper script is actually the same for all
> platforms, and it runs "/mit/infoagents/bin/netscape.real" to find the
> real binary to run. /mit/infoagents/bin is a symlink to
> arch/@sys/bin. Everything works fine until you try to run the Linux
> "netscape" under NetBSD's Linux emulation, at which point things
> gratuitously fail because /mit/infoagents/bin doesn't point to the
> right place.
>
> I claim that the right answer is to have the wrapper script be
> different for each platform, and know the canonical name for the real
> binary on the platform it's installed from.
and, that's not a fault of "magic" symlinks. it's a mismatch between
what you want the wrapper to do, and what it does.
the wrapper would have the same problem, if, instead of running the
program in /mit/infoagents/bin, it ran /mit/infoagents/arch/`uname
-m`/bin...
Would you propose to eliminate 'uname' because it is so easily and
often misused? 8-)
> There are other cases where things fail besides binary emulation: when
> you want to copy the installation into a filesystem that doesn't
> support @sys, for example.
well, in My World, any and all file systems can support the special
names, not just Special file systems like AFS.
I'd like to be able to take a single CD-ROM and a bunch of boot
floppies -- one for the sparc, one for the i386, one for the alpha,
say -- and wander around to various machines, and boot NetBSD.
I can't think of any easier, more straightforward way than 'magic'
symlinks. (if you don't have rational multisession support, and if
you don't use them, you have to hack both init and the kernel, to do
the right thing with finding binaries...)
I also like the notion of sharing network-booted machines' root
FS, and allowing different configurations on the machines.
I certainly don't claim that 'magic' symlinks should be used more than
necessary -- they take a toll, in terms of performance, among other
things. however, there are cases where they really do improve 'life'
a lot...
chris
From: Jukka Partanen <jtp@cs.hut.fi>
To: cgd@NetBSD.ORG
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 13:27:41 +0200
Chris G. Demetriou writes:
> The "magic strings" that are supported by my implementation
> (the diff for which is included below) are:
>
> @machine_arch value of MACHINE_ARCH for the system.
[...]
This is a very useful feature and Lites (4.4BSD single server
on top of Mach) has similar functionality. Another useful
variable would be @bin (or whatever), i.e. the binary type of
the running program (e.g. i386_netbsd, i386_linux). I don't
know how hard it would be to implement this in NetBSD, however.
jtp
Send your questions to ``ASK ZIPPY'', Box 40474,
San Francisco, CA 94140, USA
From: John Kohl <jtk@kolvir.arlington.ma.us>
To: gnats-bugs@NetBSD.ORG, cgd@NetBSD.ORG
Cc: netbsd-bugs@NetBSD.ORG
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 09:21:43 -0500
>>>>> "CGD" == Chris G Demetriou <cgd@NetBSD.ORG> writes:
CGD> Expansion of 'special' strings in symlinks into system-specific
CGD> values is a very useful feature in some situations, like:
CGD> (2) when trying to mount root from a CD-ROM that
CGD> contains binaries for several architectures.
CGD> NetBSD currently has no such facility, and, because of the
CGD> problems with doing multiple-architecture CD-ROMs, it arguably
CGD> should. I've implemented solution that enables "magic"
CGD> symlink expansion on a per-file system basis. They are enabled
CGD> by mounting a file system with the 'magiclinks' mount option,
CGD> which sets the MNT_MAGICLINKS mount flag.
The CD-ROM issue might be handled by using the special name feature in
the Rock Ridge specification which allows for a component of a symlink
target pathname to be replaced by the "hostname".
On the face of it, this seems like quite a silly feature: how can you
predict anything useful about the end-user's machine's name when you
create a RRIP CD-ROM? (About the only thing you could hope for is that
a hostname-relative symlink to someplace _else_ in the mounted file
system hierarchy might make some sense).
If you replace "hostname" with "machine executable format name", then
this magic symlink component becomes much more useful.
(RRIP also a neat construct for volume-relative symlinks that magically
point to some path rooted at the CD-ROM moint point)
Another alternative would be to provide alternate volume descriptors on
the CD-ROM, tweak the mount code a bit to find a "best" match among
them, and then provide separate name spaces for each of the
architectures (sharing the file storage for shared files, of course).
==John
From: Wolfgang Solfrank <ws@tools.de>
To: cgd@netbsd.org, gnats-bugs@netbsd.org, jtk@kolvir.arlington.ma.us
Cc: netbsd-bugs@netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 17:47:33 +0100
> The CD-ROM issue might be handled by using the special name feature in
> the Rock Ridge specification which allows for a component of a symlink
> target pathname to be replaced by the "hostname".
>
...
>
> (RRIP also a neat construct for volume-relative symlinks that magically
> point to some path rooted at the CD-ROM moint point)
Note that these two features were deleted from the RRIP specification when
it got to be the IEEE P1282 draft.
--
ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800
From: Ted Lemon <mellon@fugue.com>
To: John Kohl <jtk@kolvir.arlington.ma.us>
Cc: gnats-bugs@NetBSD.ORG, cgd@NetBSD.ORG, netbsd-bugs@NetBSD.ORG
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 08:56:11 -0800
Hm. Is there anything in the Rock Ridge or ISO9660 formats that
allows one to specify a different boot block for each architecture?
Without that, a multiple-architecture CD-ROM isn't all that
exciting... :'(
_MelloN_
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
To: John Kohl <jtk@kolvir.arlington.ma.us>
Cc: gnats-bugs@netbsd.org, cgd@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 15:13:11 -0500
> On the face of it, this seems like quite a silly feature: how can you
> predict anything useful about the end-user's machine's name when you
> create a RRIP CD-ROM? (About the only thing you could hope for is that
> a hostname-relative symlink to someplace _else_ in the mounted file
> system hierarchy might make some sense).
did you completely miss point number (1) (you quoted (2)) -- hostname
could be very, very, very useful for NFS-booted systems sharing a root
partition.
chris
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
To: Ted Lemon <mellon@fugue.com>
Cc: John Kohl <jtk@kolvir.arlington.ma.us>, gnats-bugs@netbsd.org,
cgd@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 15:09:07 -0500
> Hm. Is there anything in the Rock Ridge or ISO9660 formats that
> allows one to specify a different boot block for each architecture?
> Without that, a multiple-architecture CD-ROM isn't all that
> exciting... :'(
think "boot floppies." i'm perfectly willing to walk up to a machine,
insert a floppy and a CD-ROM, boot the floppy and tell it to get
root from the CD-ROM.
that also makes updating the kernel (bug fixes) a lot easier... 8-)
chris
From: Ted Lemon <mellon@fugue.com>
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Cc: John Kohl <jtk@kolvir.arlington.ma.us>, gnats-bugs@NetBSD.ORG,
cgd@NetBSD.ORG, netbsd-bugs@NetBSD.ORG
Subject: Re: kern/1781: 'magic' symbolic link expansion
Date: Thu, 23 Nov 1995 12:40:25 -0800
> think "boot floppies." i'm perfectly willing to walk up to a machine,
> insert a floppy and a CD-ROM, boot the floppy and tell it to get
> root from the CD-ROM.
Works great, *if* you can boot from floppies...
_MelloN_
State-Changed-From-To: open->suspended
State-Changed-By: soren
State-Changed-When: Wed Aug 7 15:50:27 PDT 2002
State-Changed-Why:
This is not a change-request as such, rather a reference for the idea.
From: "Perry E. Metzger" <perry@piermont.com>
To: "Chris G. Demetriou" <cgd@NetBSD.ORG>
Cc: gnats-bugs@gnats.netbsd.org, perry@piermont.com
Subject: Re: kern/1781
Date: 08 Apr 2003 13:56:46 -0400
>Synopsis: system-specific special expansions in symlinks.
This PR has been open since 1995. It appears consensus was against the
change. May I close the PR?
Perry
From: "Perry E. Metzger" <perry@piermont.com>
To: Jason Thorpe <thorpej@wasabisystems.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: 08 Apr 2003 14:08:45 -0400
Jason Thorpe <thorpej@wasabisystems.com> writes:
> On Tuesday, April 8, 2003, at 10:57 AM, Perry E. Metzger wrote:
>
> >> Synopsis: system-specific special expansions in symlinks.
> >
> > This PR has been open since 1995. It appears consensus was against the
> > change. May I close the PR?
>
> Please suspend it; personally, I'd like to have this feature in our
> kernel.
It is currently suspended. However, the PR (which contains full
patches, btw.) has been lying around for eight years now. It would be
valuable to make a final decision on this and then either apply the
patches or allow the change to die.
A great number of people with experience with AFS etc. seem to have
opposed the change when it was first proposed, by the way.
Perry
From: Jason Thorpe <thorpej@wasabisystems.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: Tue, 8 Apr 2003 11:17:03 -0700
On Tuesday, April 8, 2003, at 11:08 AM, Perry E. Metzger wrote:
> It is currently suspended. However, the PR (which contains full
> patches, btw.) has been lying around for eight years now. It would be
> valuable to make a final decision on this and then either apply the
> patches or allow the change to die.
So leave it lying around ... it doesn't hurt it to be there.
> A great number of people with experience with AFS etc. seem to have
> opposed the change when it was first proposed, by the way.
Hooray for them. It was a mount option, and people who don't want to
use it don't have to.
-- Jason R. Thorpe <thorpej@wasabisystems.com>
From: "Perry E. Metzger" <perry@piermont.com>
To: Jason Thorpe <thorpej@wasabisystems.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: 08 Apr 2003 14:25:28 -0400
Jason Thorpe <thorpej@wasabisystems.com> writes:
> On Tuesday, April 8, 2003, at 11:08 AM, Perry E. Metzger wrote:
> > It is currently suspended. However, the PR (which contains full
> > patches, btw.) has been lying around for eight years now. It would be
> > valuable to make a final decision on this and then either apply the
> > patches or allow the change to die.
>
> So leave it lying around ... it doesn't hurt it to be there.
It does actually hurt. People end up having to examine it over and
over again. Having unresolved PRs around for many years makes it hard
to fix the ones that can be resolved because it takes time for people
(over and over again) to figure out that the PR will never be advanced.
> > A great number of people with experience with AFS etc. seem to have
> > opposed the change when it was first proposed, by the way.
>
> Hooray for them. It was a mount option, and people who don't want to
> use it don't have to.
Then add it so we can close the PR. I'm fine with that. However, I'm
not fine with the PR database becoming the "Problem Reports Graveyard"
-- that makes it hard for it to serve as a place to report system
problems we can resolve.
Perry
From: Jason Thorpe <thorpej@wasabisystems.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: Tue, 8 Apr 2003 11:31:35 -0700
On Tuesday, April 8, 2003, at 11:25 AM, Perry E. Metzger wrote:
> It does actually hurt. People end up having to examine it over and
> over again. Having unresolved PRs around for many years makes it hard
> to fix the ones that can be resolved because it takes time for people
> (over and over again) to figure out that the PR will never be advanced.
That's total nonsense. A suspended PR hurts nothing. It does not make
anyone's life harder.
If you close the PR, I will simply re-open (suspend) it.
> Then add it so we can close the PR. I'm fine with that. However, I'm
> not fine with the PR database becoming the "Problem Reports Graveyard"
> -- that makes it hard for it to serve as a place to report system
> problems we can resolve.
So assign it to me and let GNATS pester me, rather than you pestering
me.
-- Jason R. Thorpe <thorpej@wasabisystems.com>
From: "Perry E. Metzger" <perry@piermont.com>
To: Jason Thorpe <thorpej@wasabisystems.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: 08 Apr 2003 14:40:25 -0400
Jason Thorpe <thorpej@wasabisystems.com> writes:
> On Tuesday, April 8, 2003, at 11:25 AM, Perry E. Metzger wrote:
> > It does actually hurt. People end up having to examine it over and
> > over again. Having unresolved PRs around for many years makes it hard
> > to fix the ones that can be resolved because it takes time for people
> > (over and over again) to figure out that the PR will never be advanced.
>
> That's total nonsense. A suspended PR hurts nothing. It does not
> make anyone's life harder.
I'm afraid that's untrue. One is forced to go back and figure out why
PRs were suspended. (I unsuspended and fixed a couple in the last
week, for instance).
It is, of course, easy for someone to say that if they aren't actively
working on finding and fixing problems hidden in the PR database, but
as someone who is doing so actively (me) can testify, it takes time
just to examine and re-examine things to determine why they are open,
and that time takes away from dealing with things that can actually be
fixed. That's why I've proposed the new "dead" state, by the way.
> If you close the PR, I will simply re-open (suspend) it.
That's not very productive, Jason. How about you actually agree that
if you want to add the facility you will do so and soon.
The patches are all there, after all. This has been waiting for eight
years. If it can't be dealt with now, when can it be dealt with?
However, Chris has said that he's happy having the thing closed.
Perry
From: Jason Thorpe <thorpej@wasabisystems.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cgd@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/1781
Date: Tue, 8 Apr 2003 11:46:59 -0700
On Tuesday, April 8, 2003, at 11:40 AM, Perry E. Metzger wrote:
> That's not very productive, Jason. How about you actually agree that
> if you want to add the facility you will do so and soon.
I asked you to assign it to me... how does that convey a message that I
won't look at it soon? Let's clue up, here...
> The patches are all there, after all. This has been waiting for eight
> years. If it can't be dealt with now, when can it be dealt with?
Sure, patches are there, but that does not necessarily help. In any
case, assign it to me, and you won't have to worry about it any more.
-- Jason R. Thorpe <thorpej@wasabisystems.com>
Responsible-Changed-From-To: kern-bug-people->thorpej
Responsible-Changed-By: thorpej
Responsible-Changed-When: Tue Apr 8 12:17:27 PDT 2003
Responsible-Changed-Why:
I will handle this PR.
From: Paul Ripke <stix@stix.homeunix.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/1781
Date: Sun, 8 Aug 2004 22:47:40 +1000
Just found this PR, and thought it worth noting that there is at
least one other OS with magic symlinks: Tru64 (and maybe HP-UX in the
future). They are called Context-Dependant Symbolic Links (CDSL), and
play a key part in shared root filesystems in Tru64 clusters. It
seems only one variable is defined, but there is prior art.
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/
ARH9FETE/FLSMNTCH.HTM#anch_0699
State-Changed-From-To: suspended->analyzed
State-Changed-By: thorpej@netbsd.org
State-Changed-When: Wed, 22 Jun 2005 23:48:14 +0000
State-Changed-Why:
Re-opening. Changes are merged into my local tree.
From: Jason R Thorpe <thorpej@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/1781 CVS commit: src
Date: Thu, 23 Jun 2005 00:30:29 +0000 (UTC)
Module Name: src
Committed By: thorpej
Date: Thu Jun 23 00:30:29 UTC 2005
Modified Files:
src/include: mntopts.h
src/lib/libc/sys: mount.2
src/sbin/mount: mount.8
src/share/man/man4: options.4
src/share/man/man7: symlink.7
src/sys/conf: files newvers.sh
src/sys/kern: init_main.c vfs_lookup.c vfs_syscalls.c
src/sys/sys: fstypes.h systm.h
Log Message:
Implement expansion of special "magic" strings in symlinks into
system-specific values. Submitted by Chris Demetriou in Nov 1995 (!)
in PR kern/1781, modified only slighly by me.
This is enabled on a per-mount basis with the MNT_MAGICLINKS mount
flag. It can be enabled at mountroot() time by building the kernel
with the ROOTFS_MAGICLINKS option.
The following magic strings are supported by the implementation:
@machine value of MACHINE for the system
@machine_arch value of MACHINE_ARCH for the system
@hostname the system host name, as set with sethostname()
@domainname the system domain name, as set with setdomainname()
@kernel_ident the kernel config file name
@osrelease the releaes number of the OS
@ostype the name of the OS (always "NetBSD" for NetBSD)
Example usage:
mkdir /arch/i386/bin
mkdir /arch/sparc/bin
ln -s /arch/@machine_arch/bin /bin
To generate a diff of this commit:
cvs rdiff -r1.5 -r1.6 src/include/mntopts.h
cvs rdiff -r1.32 -r1.33 src/lib/libc/sys/mount.2
cvs rdiff -r1.46 -r1.47 src/sbin/mount/mount.8
cvs rdiff -r1.279 -r1.280 src/share/man/man4/options.4
cvs rdiff -r1.6 -r1.7 src/share/man/man7/symlink.7
cvs rdiff -r1.719 -r1.720 src/sys/conf/files
cvs rdiff -r1.40 -r1.41 src/sys/conf/newvers.sh
cvs rdiff -r1.247 -r1.248 src/sys/kern/init_main.c
cvs rdiff -r1.60 -r1.61 src/sys/kern/vfs_lookup.c
cvs rdiff -r1.222 -r1.223 src/sys/kern/vfs_syscalls.c
cvs rdiff -r1.3 -r1.4 src/sys/sys/fstypes.h
cvs rdiff -r1.178 -r1.179 src/sys/sys/systm.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: analyzed->closed
State-Changed-By: thorpej@netbsd.org
State-Changed-When: Thu, 23 Jun 2005 00:37:20 +0000
State-Changed-Why:
This feature is (finally!) checked in.
From: Jeff Rizzo <riz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/1781 CVS commit: [netbsd-3] src
Date: Thu, 29 Dec 2005 00:57:10 +0000 (UTC)
Module Name: src
Committed By: riz
Date: Thu Dec 29 00:57:09 UTC 2005
Modified Files:
src/include [netbsd-3]: mntopts.h
src/lib/libc/sys [netbsd-3]: mount.2
src/sbin/mount [netbsd-3]: mount.8
src/share/man/man4 [netbsd-3]: options.4
src/share/man/man7 [netbsd-3]: symlink.7
src/sys/conf [netbsd-3]: files newvers.sh
src/sys/kern [netbsd-3]: init_main.c vfs_lookup.c vfs_syscalls.c
src/sys/sys [netbsd-3]: fstypes.h systm.h
Log Message:
Pull up following revision(s) (requested by thorpej in ticket #490):
lib/libc/sys/mount.2: revision 1.33
sys/sys/systm.h: revision 1.179
sys/sys/fstypes.h: revision 1.4
include/mntopts.h: revision 1.6
sys/conf/newvers.sh: revision 1.41
sys/kern/vfs_syscalls.c: revision 1.223
sys/conf/files: revision 1.720
sys/kern/vfs_lookup.c: revision 1.61
share/man/man7/symlink.7: revision 1.7
sbin/mount/mount.8: revision 1.47
sys/kern/init_main.c: revision 1.248 via patch
share/man/man4/options.4: revision 1.280 via patch
Implement expansion of special "magic" strings in symlinks into
system-specific values. Submitted by Chris Demetriou in Nov 1995 (!)
in PR kern/1781, modified only slighly by me.
This is enabled on a per-mount basis with the MNT_MAGICLINKS mount
flag. It can be enabled at mountroot() time by building the kernel
with the ROOTFS_MAGICLINKS option.
The following magic strings are supported by the implementation:
@machine value of MACHINE for the system
@machine_arch value of MACHINE_ARCH for the system
@hostname the system host name, as set with sethostname()
@domainname the system domain name, as set with setdomainname()
@kernel_ident the kernel config file name
@osrelease the releaes number of the OS
@ostype the name of the OS (always "NetBSD" for NetBSD)
Example usage:
mkdir /arch/i386/bin
mkdir /arch/sparc/bin
ln -s /arch/@machine_arch/bin /bin
To generate a diff of this commit:
cvs rdiff -r1.5 -r1.5.2.1 src/include/mntopts.h
cvs rdiff -r1.32 -r1.32.2.1 src/lib/libc/sys/mount.2
cvs rdiff -r1.46 -r1.46.2.1 src/sbin/mount/mount.8
cvs rdiff -r1.268.2.4 -r1.268.2.5 src/share/man/man4/options.4
cvs rdiff -r1.6 -r1.6.6.1 src/share/man/man7/symlink.7
cvs rdiff -r1.712.2.5 -r1.712.2.6 src/sys/conf/files
cvs rdiff -r1.40 -r1.40.4.1 src/sys/conf/newvers.sh
cvs rdiff -r1.244.6.4 -r1.244.6.5 src/sys/kern/init_main.c
cvs rdiff -r1.57 -r1.57.2.1 src/sys/kern/vfs_lookup.c
cvs rdiff -r1.217.2.7 -r1.217.2.8 src/sys/kern/vfs_syscalls.c
cvs rdiff -r1.3 -r1.3.10.1 src/sys/sys/fstypes.h
cvs rdiff -r1.175 -r1.175.4.1 src/sys/sys/systm.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Chris Demetriou <c.g.demetriou@gmail.com>
To: gnats-bugs@netbsd.org
Cc: thorpej@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, cgd@netbsd.org
Subject: Re: PR/1781 CVS commit: [netbsd-3] src
Date: Wed, 28 Dec 2005 17:18:23 -0800
wow.
mmm, `node_data. 8-)
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home