Re: Nested functions [was Re: valgrind]

[Chris Hanson]

On Mar 24, 2022, at 8:16 PM, Mouse  wrote:

> Nested functions are not closures, or at least not what I know as
> closures.  A nested function pointer (conceptually) goes invalid as
> soon as anything it refers to goes out of scope, or at the latest as
> soon as its smallest enclosing block exits (or possibly when its
> smallest enclosing function returns).  The thing I know as a closure
> would preserve the referred-to objects as long as the closure is
> potentially callable.  This requires more reference tracking than C
> typically makes possible.

Closures can easily be used as nested functions, and the blocks feature that 
was created by Apple explicitly addresses this by including runtime functions.

1. You can just declare and use a block if it's not going to go out of scope, 
as if it were a nested function, with just slightly different syntax than 
nested functions. (You do this by declaring a block-typed variable and 
immediately assigning the block to it, then calling through the variable. It 
behaves like a function pointer.)

2. If you have a variable in the outer scope that you want to modify in the 
block, you have to annotate the variable with __block, so the block context 
(activation record) created for the bock can find it. Otherwise everything in 
the enclosing scope is effectively immutable (though one must of course be 
aware that an immutable pointer is not the same as a pointer to immutable data).

3. If you're passing the block to another function or block, whatever you pass 
it to should *either* annotate its block argument as non-escaping via the right 
__attribute__(()) to indicate it doesn't need any memory management, or it 
should Block_copy() the block it's handed and work only with the copy. That 
ensures the block context is hoisted to the heap. Following Apple's general 
patterns, a Block_copy() of a heap block is identical to a BlocK_retain() so 
the latter should really never be called.

4. If something calls Block_copy() because it wants to hold onto a block, it 
needs to call Block_release() to eventually dispose of the block.

Here are the language and runtime specs. They're a great language addition and 
used pervasively on Apple platforms as a result.

Language: https://clang.llvm.org/docs/BlockLanguageSpec.html 

Runtime/ABI: https://clang.llvm.org/docs/Block-ABI-Apple.html 


  -- Chris

Re: about langage neutral

[Chris Hanson]

> - 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: Representing a rotary encoder input device

[Chris Hanson]

On Sep 22, 2021, at 7:10 AM, Jason Thorpe  wrote:

> Well, ultimately, we translate “HID report” -> “ws* input event”.  Or are you 
> suggesting that we should have a new interface to user-space that just sends 
> HID reports?

That sounds like a good long-term plan, IMO, given the prevalence of HID in the 
modern era and the ability to map virtually everything to it.

I've though occasionally about putting together drivers for some of the HP-HIL 
devices (single-dial-and-button rotary encoder, dial box with nine rotary 
encoders, and button box with 32 buttons with LEDs) but haven't had much clue 
how to wire them into the higher layers of the system to actually use.

Having something like a HID abstraction layer that they could adapt to would 
make that more straightforward.

  -- Chris

Re: Introduction to posix_spawn/chdir

[Chris Hanson]

On Jun 27, 2021, at 1:39 AM, Piyush Sachdeva  
wrote:
> 
> On Sun, Jun 27, 2021 at 1:15 PM Chris Hanson  
> wrote:
>> What are the straightforward changes needed to implement this minor 
>> addition? That’s all I’m wondering.
>> 
>> Let’s say I wanted to add something like xnu’s 
>> posix_spawn_file_attr_addinherit_np(). I’d hope that the plan for chdir 
>> would provide some guidance that would at least help > someone get started.
>> 
> 
> Well the implementation plan is simple-

Awesome, thank you!

  — Chris

Re: Introduction to posix_spawn/chdir

[Chris Hanson]

On Jun 27, 2021, at 12:20 AM, Martin Husemann  wrote:
> 
> On Sat, Jun 26, 2021 at 03:02:35PM -0700, Chris Hanson wrote:
>> That's great, I'm more curious about the implementation plan.
> 
> I would understand this question if we were talking about implementing
> posix_spawn from scratch, but we have that since 6.0 and the "plan" is
> to enhance the exisiting implementation by the minor additions in the
> upcoming posix changes. It is a straight forward change.
> 
> So I probably still don't quite understand your question.

What are the straightforward changes needed to implement this minor addition? 
That’s all I’m wondering.

Let’s say I wanted to add something like xnu’s 
posix_spawn_file_attr_addinherit_np(). I’d hope that the plan for chdir would 
provide some guidance that would at least help someone get started.

  — Chris

Re: Introduction to posix_spawn/chdir

[Chris Hanson]

On Jun 25, 2021, at 9:57 PM, Martin Husemann  wrote:
> 
> On Fri, Jun 25, 2021 at 02:45:59PM -0700, Chris Hanson wrote:
>> Also, exactly what form will posix_spawn chdir support take in your project?
> 
> I'm not sure I understand the question correctly.
> 
> There is an upcoming change for the next version of Posix in the Austin
> Group's bug tracker and the project is about enhancing the existing
> posix_spawn implementation in NetBSD to comply with those changes
> (this has been on our wish list for GSoC projects for a while, see
> https://wiki.NetBSD.org/projects/project/posix__95__spawn__40__3__41___chdir_support/)

That’s great, I’m more curious about the implementation plan.

  — Chris

Re: Introduction to posix_spawn/chdir

[Chris Hanson]

Also, exactly what form will posix_spawn chdir support take in your project?

Have you provided an implementation plan somewhere? I read the first blogpost 
as more of a rationale than a plan.

  — Chris

Re: Introduction to posix_spawn/chdir

[Chris Hanson]

On Jun 25, 2021, at 8:33 AM, Piyush Sachdeva  
wrote:
> 
> In the matter of organising my repository (pointed out by Christos Zoulas),
> I have mirrored The NetBSD source in my github repository as a separate 
> branch.
> However, I am using a main branch as a staging area for the TNF mirror,
> and will make commits to it once I can build the kernel and pass initial 
> tests.
> I hope this is alright.
> https://github.com/cosmologistPiyush/posix_spawn-chdir

Instead of using a staging branch that only contains your code, and a separate 
branch with NetBSD source, it’d be best to have your changes _on top of_ the 
NetBSD source. That makes it easiest to actually see what your changes are 
relative to mainline. Right now one had to check out your changes to some 
separate directory and use tools to compare the files, instead of checking out 
your changes and doing `git diff netbsd-9` (or whatever your branch is based 
on).

  — Chris

Re: Booting HP DL360 gen9

[Chris Hanson]

My DL360p Gen8 just worked with 9.0.

Does FreeBSD boot on it? That could provide a decent point of comparison.

  — Chris

Re: bounty for virtio 1.0 (now with instructions!)

[Chris Hanson]

On Dec 18, 2020, at 2:21 PM, Reinoud Zandijk  wrote:
> 
> Hi Chris,
> 
> On Wed, Dec 16, 2020 at 01:08:23AM -0800, Chris Hanson wrote:
>> NetBSD could also use a VirtIO console device, since that’s all
>> Virtualization.framework offers on macOS 11 (whether on x86-64 or Apple
>> Silicon).
> 
> From what I see in videos on youtube, the tooklit displays a standard VGA
> display with apparently a number of text consoles next to it?

Virtualization.framework does not currently expose any sort of display, 
keyboard or pointing device. All it exposes as a "console" is VirtIO Console. 
It also lets you set up socket, network, mass storage, entropy, and memory 
balloon devices.

> Qemu can create a number of console devices that need to be paired with
> various backends like pipes or sockets etc. I presume the virtualization
> framework on macosX11 is providing terminals for each of the activated
> terminals?

macOS 11's Virtualization.framework does not provide terminals or views. I 
don't know what the videos you're watching are, but the framework is very 
focused right now.

  -- Chris

Re: bounty for virtio 1.0 (now with instructions!)

[Chris Hanson]

NetBSD could also use a VirtIO console device, since that’s all 
Virtualization.framework offers on macOS 11 (whether on x86-64 or Apple 
Silicon).

  — Chris

Re: style change: explicitly permit braces for single statements

[Chris Hanson]

On Jul 12, 2020, at 9:31 PM, Greg A. Woods  wrote:
> 
> Personally I don't think there's any good excuse for not always putting
> braces around all single-statement blocks.  The only bad execuse is that
> the language doesn't strictly require them.  People are lazy, I get that
> (I am too), but in my opinion C is just not really safe without them.

I strongly concur, in my professional work for the past few decades the braces 
have never been considered optional (and neither have "extraneous" parentheses 
in expressions).

  -- Chris

Re: Regarding the ULTRIX and OSF1 compats

[Chris Hanson]

Ever since seeing Hubbard & co’s “NextBSD” stuff I’ve been hoping that Mach 
would eventually find its way into the BSDs. For all its warts there’s enormous 
utility in Mach’s primitives, both IPC and other. (Of course I’m also a 
NeXT/Apple/Darwin person, so I’m used to building on them…)

  — Chris