> Date: Sat, 13 Jul 2024 00:15:05 +0100
> From: Stuart Henderson <stu@spacehopper.org>
> 
> On 2024/07/12 17:15, j@bitminer.ca wrote:
> > I think we are in agreement here.  comments below.
> > 
> > On 2024-07-12 16:24, Stuart Henderson wrote:
> > > On 2024/07/12 16:08, j@bitminer.ca wrote:
> > > > Some features are fairly complicated to understand; e.g. the array
> > > > of avx instructions varies dramatically with implementation (code
> > > > name of the cpu). Fortunately cpuid on Intel is unprivileged so
> > > > software can decide
> > > 
> > > Well, with avx512, it also depends on whether the OS
> > > supports it. If not
> > > then no matter what CPU, it won't work.
> > 
> > Yes, and the porter is obliged to limit compiled instructions to avoid
> > failure.  Or, for some codes, to ensure executed
> > instructions fall within
> > the cpu feature set because the code adapts to the currently
> > executing cpu.
> 
> That is stupid.
> 
> If there's a way the OS can pass on information about what
> works, that's definitely a simpler/more reliable way to handle it than
> parsong text strings.
> 
> If the OS can't do this then maybe some extra ports work maybe needed,
> but if there's a way to prevent advertising support for something
> which is known not to work, that's the way to go, easier to fix in the
> first place, and easier to remove later when support is added.
> 
> > As above, the porter wants to avoid illegal instruction faults.
> 
> You ask a lot of a very limited number of porters, who have quite
> limited access to hardware, for what is a relatively small scale OS with
> a specific definition that says "Focus on being developer-oriented in
> all senses".
> 
> I think you fundamentally misunderstand OpenBSD and would be happier
> running fedora or something.

Well, Linux does things the same way that we propose here ;).