Re: cpu_rootconf() vs booted_device issues
mrg@ wrote: > cpu_rootconf problems.most of these only need to have eg > "if (booted_device) return;" added to a function usually > called findroot() or set_root_device(): : > atari > - also checks RB_ASKNAME, which means no default will be set > (consider removing this check here) As commented in the its cpu_rootconf(), it's inside of "#if defined(MEMORY_DISK_HOOKS)" and necessary for the atari specific "auto load mdroot image from floppy on the first open" for installation, after md(4) has been changed to be dynamically configured: https://mail-index.netbsd.org/source-changes/2010/11/11/msg014346.html https://nxr.netbsd.org/xref/src/sys/arch/atari/atari/autoconf.c?r=1.71#91 "ustarfs based multiple install floppies for atari" is in my todo list, but it requires more detailed info about TOS (an atari's native OS) internal BIOS functions for raw I/O accesses.. --- Izumi Tsutsui
Re: membar_enter semantics
(sorry, lost track of this) On Mon, Feb 14, 2022 at 05:12:13AM +0100, Joerg Sonnenberger wrote: > Am Mon, Feb 14, 2022 at 02:45:46AM + schrieb David Holland: > > On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote: > > > Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland: > > > > In this case I would argue that the names should be membar_load_any() > > > > and membar_any_store(). > > > > > > Kind of like with the BUSDMA_* flags, it is not clear from that name in > > > which direction they work either. As in: is it a barrier that stops the > > > next load? Is it a barrier that ensures that a store is visible? > > > > Given that English is left-to-right, and that memory barriers are > > about ordering memory operations, it seems a lot clearer than "enter". > > I don't think that arguments works with the way barriers around read and > write operations are normally used. A read barrier is normally "ensure > that a read doesn't move before this point", where as write barrier is > normally "ensure that a write operation doesn't move beyond this point". > Note the opposite temporal direction. Not sure if there are sensible use > cases of the inverted directions, i.e. if we care about CPUs that can > reorder reads relative to later writes. I don't follow this argument. The natural interpretation of "membar_any_store" is "barrier between any and store", so for a "read" barrier, that is, "membar_read_read", it's a barrier between reads and reads. I don't see how the motion direction of the anticipated leakage applies, and I think getting the anticipated leakage involved in the naming of the operation is a bad idea. (It would be another example of naming things after when they're supposed to be used rather than what they do.) -- David A. Holland dholl...@netbsd.org
Re: about langage neutral
> - IDL from MACH/HURD (/darwin), no references, blur The Mach Interface Generator (mig) should be documented via a man page and in the PostScript reference documentation that's part of the Mach distribution. -- Chris
Re: membar_enter semantics
On Mon, Feb 14, 2022 at 08:11:57AM +, Taylor R Campbell wrote:
> > On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> > > membar_enter is currently documented to be a store-before-load/store
> > > barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
> > >
> > > membar_enter()
> > >Any store preceding membar_enter() will happen before all
> > memory
> > >operations following it.
> > >
> > > [...]
> >
> > This problem (and others like it) are primarily caused by using silly
> > names like "enter" and "exit" that don't mean anything. (That is: you
> > could redefine enter to be any-before-any and exit to be
> > read-before-read and it still wouldn't be obviously wrong to most
> > people.)
>
> The problem at hand is that one word in the documentation doesn't
> reflect
>
> - 15 years of implementation on x86, powerpc, and sparc,
> - 15 years of usage, or
> - sensible semantics for real-world use cases.
>
> All the other NetBSD membars meet this -- as would the proposed
> one-word documentation change.
My point was somewhat different: we ended up in this hole with the
docs having been wrong for who knows how long precisely because the
terminology is rubbish. If the name "membar_enter" meant anything
coherent that anyone could remember, this sentence would have been
obviously wrong.
I'm not arguing that we shouldn't fix this. I'm arguing that we should
deprecate the names "member_enter" and "membar_exit" because they're
failed terminology, and this issue is evidence of that.
> > In general, things should be named by what they do, not by the
> > context in which you're supposed to use them according to some
> > cookbook thinking-averse approach.
>
> Experience working in an environment where all possible membars are
> available and named according to {load,store}-before-{load,store}
> combinations tells me that it doesn't actually improve anything.
>
> Instead, it just encourages people to overthink bad choices locally
> without thinking about or documenting the two-sided _protocol_ between
> threads, and then leave nonsensical barriers around because they
> locally sounded good.
Perhaps so. But that beats people jumping to conclusions and using the
wrong things because they don't understand what they do and think a
semantically null name is telling them something useful.
Also, I'd say it is not about protocols so much as about data
structure invariants. The use of matching pairs is only meaningful in
specific circumstances where there's one writer and one reader, and
while one writer may be a reasonable assumption, IME one reader
often isn't.
And when you're thinking about it in terms of invariants, the exact
operations you're ordering to satisfy the invariant become much easier
to follow.
At a minimum we should deprecate the meaningless names "enter" and
"exit" and replace them with "acquire" and "release", since while the
latter names also don't inherently mean anything they've also got C99
and some years of research literature backing them up.
Meanwhile "producer" and "consumer" are equally meaningless and
equally failed terminology and the best available names are
"write_write" and "read_read". Unless it's the other way around.
--
David A. Holland
dholl...@netbsd.org
Re: about langage neutral
On Thu, Mar 10, 2022 at 11:10:13AM +0100, Jos? Bollo wrote: > What I have in mind is that there is no need for a specific IDL: the > language itself is the IDL and the code generator. > > I can add that SCHEME interpreters are small piece of code (that you > don't have to change, pick it and use it). Compilers also exist. To some extent the whole point of an IDL is being declarative and not Turing-complete, so you can read the declarations and readily translate them to a wide variety of languages. Writing a script that spits out interface definitions in C (we already have several of these) doesn't help produce interface definitions for other languages. Just writing the script in Scheme instead of sh/awk or Python or whatnot doesn't help much. Plus, we don't have a Scheme interpreter in base. If what you mean instead is to invent a new IDL and use S-expressions as the input syntax to avoid needing a real parser, you're pulling on the wrong end of the problem. Parsers are cheap; the semantics of the IDL are the important part. -- David A. Holland dholl...@netbsd.org
