Re: New compat_bsdos.8 Manpage

[Dan Plassche <dplassche%gmail.com@localhost>]

On 2020-08-29 17:58, Valery Ushakov wrote:
> On Sat, Aug 29, 2020 at 17:15:40 -0400, Dan Plassche wrote:
> 
>>> Could you kindly re-diff those changes against the committed version?
>>
>> No problem, below is a diff:
> 
> Thanks, but to nitpick - this is not against the committed version,
> that had several markup fixes.

I had a copy of the initial commit and ran the diff against that.  I see now
there were additional changes afterwards yesterday, so I'll need to rebase my
edits to the latest version in the tree and send you a diff against that.

> Anyway, I've committed the minor wording changes, but I don't feel
> comfortable committing the big /shlib change which, as far as I can
> tell, was initially suggested by David.
> 
> /emul/$foo is a magic place for emulations, the kernel arranges for
> lookups under /emul/$foo before lookups upder the normal root, etc.
> So when the proposed wording suggests to put stuff under /emul/bsdos
> that is NOT magic, that is potentially very confusing.  Yes, I know
> it's also mentioned in the old version (and now that I've noticed, I'm
> not happy about it), but the new text suggests to add symlinks from
> /shlib to /emul/bsdos/shlib and to me that looks like a very confusing
> setup.

The magic setup is a bit more varied though.  For a.out binaries, /emul/$foo
lookups happen for SunOS, but NetBSD a.out libraries are searched under
/emul/aout for COMPAT_09 through COMPAT_14.

> So ideally the wording should explain that bsdos does NOT have a magic
> /emul/$foo root like other emulations as it's COMPAT_NOMID, not
> COMPAT_BSDOS, and the binaries run under COMPAT_NOMID get their files
> looked up in the normal root namespace, so you have to have a real
> /shlib in you file system, whatever that is, a directory or a symlink
> to elsewhere.  /emul/bsdos/shlib might be not that bad a choice for
> $elsewhere, but then the man page has to be super-clear that this is
> just to follow the convention and there's no magic in that choice, as
> /emul prefix might imply.
> 

Okay, you make a good point that the library lookup path needs to be clear to
the user.  I'll revise the wording when sending the next diff to explain that
there's no magic path.


Thank you,

Dan