Subject: Re: kern/1781: 'magic' symbolic link expansion
To: None <firstname.lastname@example.org, email@example.com>
From: Arne H. Juul <firstname.lastname@example.org>
Date: 11/23/1995 15:01:56
> >>>>> "Peter" == Peter Seebach <email@example.com> writes:
> Peter> Are we absolutely sure there's no better solution? Where, if
> Peter> anywhere, will this stop? I distrust the additional magic,
> Peter> mostly because it breaks the rule that anything but nul and '/'
> Peter> can be in a name.
> So don't mount your FSs with magiclinks then... I cannot see how an
> optional facility like this can disturb you like that.
It's not optional. Each and every name lookup do that extra little
check to see if we should expand magic in the first place. If it's made
a kernel option which is *not* enabled in standard configuration, then
it's "just" extra cruft (aka "optional facility"). I'd rather have cruft
like i386-specific bounce buffer support, but for some reason that isn't
"necessary" enough [see footnote].
Maybe worse is: If people start to *use* this kind of abominations,
however, soon they'll be arguing that other programs should be changed to
support this kind of thing. Already there is a need for patching /bin/sh
(granted, I agree with that fix anyway).
As long as this is an option to help people making cd-roms (and not
something that the rest of us have to worry about) I don't mind that
extra cruft/facility. So to be a bit more constructive I'll just note
that one needs to consider the precedents set by other systems:
>> From: John Hawkinson <firstname.lastname@example.org>
>> Subject: Re: Boot from CD-ROM
>> Date: Wed, 12 Apr 1995 08:08:35 -0400 (EDT)
>> It should be noted that the @sys convention is derived from AFS, and
>> anyone seriously implementing this ought to try and make sure that
>> they pick the same expansions as are already in use...
>> (AFS typically uses architecture_osversion, eg sun4m_413. The NetBSD
>> AFS clients currently use i386_nbsd1 (Intel 386 NetBSD 1.0),
>> m68k8k_nbsd1 (for Amiga, Mac, sun3), m68k4k_nbsd1 (hp300), sparc_nbsd1
>> (Sun 4s)...)
Since this particular discussion has been had several times now, it's
probably just a matter of grep'ing the archives :-)
- Arne H. J.
You can probably tell that I'm among those people who are peeved by the
fact that this problem, which has been well known (with known solutions)
since *before* NetBSD started, hasn't been fixed because the solutions
wasn't "clean" enough. Well, it's a dirty problem, and that's because
the hardware sucks, so what do you expect? "Buy a better motherbord"
just isn't a solution, to most people. "Switch to linux" is. End peeve.