[9fans] NIX this morning

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Paul and I have  been going back and forth, tweaking this and that, and he
made a major find and fix last week. Page faults from the AC now work.

Further, he fixed the rfork support, such that processes can set up and
move from a TC to an AC. This restores a long-lost capability.

This is a pretty major step forward. It is now even possible to do things
like this:
main(){
/* set it all up */
rfork(RFACORE); /* something like that */

and your process is now running on a dedicated, non-preempted,
interrupt-free, no kernel code, core all to its own.

If somebody has access to a sapphire rapids server running 9front, there
are some tests I'd like to do.

Thanks Paul!

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Mb43b83d8fb6109f407253598
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1558 bytes --]

Re: [9fans] NIX this morning

[Stuart Morrow]

On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
> Further, he fixed the rfork support, such that processes can set up and move from a TC to an AC. This restores a long-lost capability.
>
> This is a pretty major step forward. It is now even possible to do things like this:
> main(){
> /* set it all up */
> rfork(RFACORE); /* something like that */
>
> and your process is now running on a dedicated, non-preempted, interrupt-free, no kernel code, core all to its own.

Does that block until the resource is available?  9front added the
ability for rfork to fail.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M8b9003970120728d94527605
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this morning

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

No, it does not block, failing if it can't.

This piece is still buggy - the error labeling (waserror(), poperror(),
error()) is out of balance, even in the path that doesn't fork.
So I'm tracing carefully to understand where the missing poperror() or
extra waserror() is.

Paul

On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com>
wrote:

> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
> > Further, he fixed the rfork support, such that processes can set up and
> move from a TC to an AC. This restores a long-lost capability.
> >
> > This is a pretty major step forward. It is now even possible to do
> things like this:
> > main(){
> > /* set it all up */
> > rfork(RFACORE); /* something like that */
> >
> > and your process is now running on a dedicated, non-preempted,
> interrupt-free, no kernel code, core all to its own.
> 
> Does that block until the resource is available?  9front added the
> ability for rfork to fail.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2661 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

I've taken it a bit further, and it's odd.

rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits. But
here's the interesting part.
up->nerrlab is still 1 when we flip the process over to the ac. This is
because of the call to _procctl in syscall()

Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first
waserror() in syscall.

I think before the _procctl() in syscall, there needs to be a poperror().
this fixes it for me.
if (up->procctl == Procto ...) {poperror(); _procctl(up); }
The reason is, that when procctl is set to Proc_toac, that call to procctl
never returns, and the poperror never happens.

Why did this ever work, you say? I don't know.

Paul, see what you think.

On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> No, it does not block, failing if it can't.
>
> This piece is still buggy - the error labeling (waserror(), poperror(),
> error()) is out of balance, even in the path that doesn't fork.
> So I'm tracing carefully to understand where the missing poperror() or
> extra waserror() is.
>
> Paul
>
> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com>
> wrote:
>
>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
>> > Further, he fixed the rfork support, such that processes can set up and
>> move from a TC to an AC. This restores a long-lost capability.
>> >
>> > This is a pretty major step forward. It is now even possible to do
>> things like this:
>> > main(){
>> > /* set it all up */
>> > rfork(RFACORE); /* something like that */
>> >
>> > and your process is now running on a dedicated, non-preempted,
>> interrupt-free, no kernel code, core all to its own.
>> 
>> Does that block until the resource is available?  9front added the
>> ability for rfork to fail.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M6d0cc61e0540afaec8fb578b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4071 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

nix is working pretty reliably for me now.

We're past the will it run stage, now for the clean it up stage. As always,
contributors welcome. I note that Paul dialed down all the nasty debug
prints, so if you use it, you'll find it nicer.

reminder: TODOs are here:
https://github.com/rminnich/9front/blob/nix/TODO.md



On Mon, Mar 24, 2025 at 2:35 PM ron minnich <rminnich@gmail.com> wrote:

> I've taken it a bit further, and it's odd.
>
> rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits.
> But here's the interesting part.
> up->nerrlab is still 1 when we flip the process over to the ac. This is
> because of the call to _procctl in syscall()
>
> Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first
> waserror() in syscall.
>
> I think before the _procctl() in syscall, there needs to be a poperror().
> this fixes it for me.
> if (up->procctl == Procto ...) {poperror(); _procctl(up); }
> The reason is, that when procctl is set to Proc_toac, that call to procctl
> never returns, and the poperror never happens.
>
> Why did this ever work, you say? I don't know.
>
> Paul, see what you think.
>
> On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
>
>> No, it does not block, failing if it can't.
>>
>> This piece is still buggy - the error labeling (waserror(), poperror(),
>> error()) is out of balance, even in the path that doesn't fork.
>> So I'm tracing carefully to understand where the missing poperror() or
>> extra waserror() is.
>>
>> Paul
>>
>> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com>
>> wrote:
>>
>>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
>>> > Further, he fixed the rfork support, such that processes can set up
>>> and move from a TC to an AC. This restores a long-lost capability.
>>> >
>>> > This is a pretty major step forward. It is now even possible to do
>>> things like this:
>>> > main(){
>>> > /* set it all up */
>>> > rfork(RFACORE); /* something like that */
>>> >
>>> > and your process is now running on a dedicated, non-preempted,
>>> interrupt-free, no kernel code, core all to its own.
>>> 
>>> Does that block until the resource is available?  9front added the
>>> ability for rfork to fail.
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Mf774e3ff70947085ef227e27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4973 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

spoke too soon. Hangs on booting on my t420. Possibly IRQ problem, not sure.

On Mon, Mar 24, 2025 at 10:02 PM ron minnich <rminnich@gmail.com> wrote:

> nix is working pretty reliably for me now.
>
> We're past the will it run stage, now for the clean it up stage. As
> always, contributors welcome. I note that Paul dialed down all the nasty
> debug prints, so if you use it, you'll find it nicer.
>
> reminder: TODOs are here:
> https://github.com/rminnich/9front/blob/nix/TODO.md
>
>
>
> On Mon, Mar 24, 2025 at 2:35 PM ron minnich <rminnich@gmail.com> wrote:
>
>> I've taken it a bit further, and it's odd.
>>
>> rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits.
>> But here's the interesting part.
>> up->nerrlab is still 1 when we flip the process over to the ac. This is
>> because of the call to _procctl in syscall()
>>
>> Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first
>> waserror() in syscall.
>>
>> I think before the _procctl() in syscall, there needs to be a poperror().
>> this fixes it for me.
>> if (up->procctl == Procto ...) {poperror(); _procctl(up); }
>> The reason is, that when procctl is set to Proc_toac, that call to
>> procctl never returns, and the poperror never happens.
>>
>> Why did this ever work, you say? I don't know.
>>
>> Paul, see what you think.
>>
>> On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalonde@gmail.com>
>> wrote:
>>
>>> No, it does not block, failing if it can't.
>>>
>>> This piece is still buggy - the error labeling (waserror(), poperror(),
>>> error()) is out of balance, even in the path that doesn't fork.
>>> So I'm tracing carefully to understand where the missing poperror() or
>>> extra waserror() is.
>>>
>>> Paul
>>>
>>> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com>
>>> wrote:
>>>
>>>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
>>>> > Further, he fixed the rfork support, such that processes can set up
>>>> and move from a TC to an AC. This restores a long-lost capability.
>>>> >
>>>> > This is a pretty major step forward. It is now even possible to do
>>>> things like this:
>>>> > main(){
>>>> > /* set it all up */
>>>> > rfork(RFACORE); /* something like that */
>>>> >
>>>> > and your process is now running on a dedicated, non-preempted,
>>>> interrupt-free, no kernel code, core all to its own.
>>>> 
>>>> Does that block until the resource is available?  9front added the
>>>> ability for rfork to fail.
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>>> <https://9fans.topicbox.com/groups/9fans> + participants
>>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11>
>>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M7c012264be6d78e0822cdbb8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5486 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]

#l0 gets "no phy" error
#l1 gets dma error / timeout

good solid hang after that.
I miss ^T^Tp or whatever that sequence was ...
anyway ... hopefully someone else can try on different hardware.

I think it is hung in network startup somehow.


On Mon, Mar 24, 2025 at 10:31 PM ron minnich <rminnich@gmail.com> wrote:

> spoke too soon. Hangs on booting on my t420. Possibly IRQ problem, not
> sure.
>
> On Mon, Mar 24, 2025 at 10:02 PM ron minnich <rminnich@gmail.com> wrote:
>
>> nix is working pretty reliably for me now.
>>
>> We're past the will it run stage, now for the clean it up stage. As
>> always, contributors welcome. I note that Paul dialed down all the nasty
>> debug prints, so if you use it, you'll find it nicer.
>>
>> reminder: TODOs are here:
>> https://github.com/rminnich/9front/blob/nix/TODO.md
>>
>>
>>
>> On Mon, Mar 24, 2025 at 2:35 PM ron minnich <rminnich@gmail.com> wrote:
>>
>>> I've taken it a bit further, and it's odd.
>>>
>>> rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits.
>>> But here's the interesting part.
>>> up->nerrlab is still 1 when we flip the process over to the ac. This is
>>> because of the call to _procctl in syscall()
>>>
>>> Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first
>>> waserror() in syscall.
>>>
>>> I think before the _procctl() in syscall, there needs to be a
>>> poperror(). this fixes it for me.
>>> if (up->procctl == Procto ...) {poperror(); _procctl(up); }
>>> The reason is, that when procctl is set to Proc_toac, that call to
>>> procctl never returns, and the poperror never happens.
>>>
>>> Why did this ever work, you say? I don't know.
>>>
>>> Paul, see what you think.
>>>
>>> On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalonde@gmail.com>
>>> wrote:
>>>
>>>> No, it does not block, failing if it can't.
>>>>
>>>> This piece is still buggy - the error labeling (waserror(), poperror(),
>>>> error()) is out of balance, even in the path that doesn't fork.
>>>> So I'm tracing carefully to understand where the missing poperror() or
>>>> extra waserror() is.
>>>>
>>>> Paul
>>>>
>>>> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com>
>>>> wrote:
>>>>
>>>>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
>>>>> > Further, he fixed the rfork support, such that processes can set up
>>>>> and move from a TC to an AC. This restores a long-lost capability.
>>>>> >
>>>>> > This is a pretty major step forward. It is now even possible to do
>>>>> things like this:
>>>>> > main(){
>>>>> > /* set it all up */
>>>>> > rfork(RFACORE); /* something like that */
>>>>> >
>>>>> > and your process is now running on a dedicated, non-preempted,
>>>>> interrupt-free, no kernel code, core all to its own.
>>>>> 
>>>>> Does that block until the resource is available?  9front added the
>>>>> ability for rfork to fail.
>>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>>>> <https://9fans.topicbox.com/groups/9fans> + participants
>>>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>>>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>>>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11>
>>>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M112075ad17ac7162b7f03e17
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6273 bytes --]

Re: [9fans] NIX this morning

[Ron Minnich]

it was a boofhead move on my part, it's not a real problem.

etymology of boofhead: I don't know, picked it up from ericvh, who
picked it up at Murray Hill.

On Tue, Mar 25, 2025 at 12:21 AM ron minnich <rminnich@gmail.com> wrote:
>
> #l0 gets "no phy" error
> #l1 gets dma error / timeout
>
> good solid hang after that.
> I miss ^T^Tp or whatever that sequence was ...
> anyway ... hopefully someone else can try on different hardware.
>
> I think it is hung in network startup somehow.
>
>
> On Mon, Mar 24, 2025 at 10:31 PM ron minnich <rminnich@gmail.com> wrote:
>>
>> spoke too soon. Hangs on booting on my t420. Possibly IRQ problem, not sure.
>>
>> On Mon, Mar 24, 2025 at 10:02 PM ron minnich <rminnich@gmail.com> wrote:
>>>
>>> nix is working pretty reliably for me now.
>>>
>>> We're past the will it run stage, now for the clean it up stage. As always, contributors welcome. I note that Paul dialed down all the nasty debug prints, so if you use it, you'll find it nicer.
>>>
>>> reminder: TODOs are here: https://github.com/rminnich/9front/blob/nix/TODO.md
>>>
>>>
>>>
>>> On Mon, Mar 24, 2025 at 2:35 PM ron minnich <rminnich@gmail.com> wrote:
>>>>
>>>> I've taken it a bit further, and it's odd.
>>>>
>>>> rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits. But here's the interesting part.
>>>> up->nerrlab is still 1 when we flip the process over to the ac. This is because of the call to _procctl in syscall()
>>>>
>>>> Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first waserror() in syscall.
>>>>
>>>> I think before the _procctl() in syscall, there needs to be a poperror(). this fixes it for me.
>>>> if (up->procctl == Procto ...) {poperror(); _procctl(up); }
>>>> The reason is, that when procctl is set to Proc_toac, that call to procctl never returns, and the poperror never happens.
>>>>
>>>> Why did this ever work, you say? I don't know.
>>>>
>>>> Paul, see what you think.
>>>>
>>>> On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>>>>>
>>>>> No, it does not block, failing if it can't.
>>>>>
>>>>> This piece is still buggy - the error labeling (waserror(), poperror(), error()) is out of balance, even in the path that doesn't fork.
>>>>> So I'm tracing carefully to understand where the missing poperror() or extra waserror() is.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stuart@gmail.com> wrote:
>>>>>>
>>>>>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminnich@gmail.com> wrote:
>>>>>> > Further, he fixed the rfork support, such that processes can set up and move from a TC to an AC. This restores a long-lost capability.
>>>>>> >
>>>>>> > This is a pretty major step forward. It is now even possible to do things like this:
>>>>>> > main(){
>>>>>> > /* set it all up */
>>>>>> > rfork(RFACORE); /* something like that */
>>>>>> >
>>>>>> > and your process is now running on a dedicated, non-preempted, interrupt-free, no kernel code, core all to its own.
>>>>>> 
>>>>>> Does that block until the resource is available?  9front added the
>>>>>> ability for rfork to fail.
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M3db64f77a140ad640e2c54c8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this morning

[Dave Lukes via 9fans]

[-- Attachment #1: Type: text/html, Size: 1211 bytes --]

Re: [9fans] NIX this morning

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

No, it's "boofhead" and it's common Australian slang, derived from a
British cartoon character called a bufflehead, dating from the 1940s.

-rob


On Wed, Mar 26, 2025 at 12:31 PM Dave Lukes via 9fans <9fans@9fans.net>
wrote:

>
>
> On 26 Mar 2025 00:02, Ron Minnich <rminnich@p9f.org> wrote:
>
> etymology of boofhead: I don't know, picked it up from ericvh, who
> picked it up at Murray Hill.
>
>
> The correct spelling is "bofhead": it's a Boyd-ism.
>
> Dave.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Me578c5abe35a9f8f979ffa17>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M7443f33dc163b7cb7f456ce3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2117 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

dave, are you sure?
https://en.wiktionary.org/wiki/boofhead


On Tue, Mar 25, 2025 at 6:31 PM Dave Lukes via 9fans <9fans@9fans.net>
wrote:

>
>
> On 26 Mar 2025 00:02, Ron Minnich <rminnich@p9f.org> wrote:
>
> etymology of boofhead: I don't know, picked it up from ericvh, who
> picked it up at Murray Hill.
>
>
> The correct spelling is "bofhead": it's a Boyd-ism.
>
> Dave.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Me578c5abe35a9f8f979ffa17>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M42f87b1cfd60b1a7690642a4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1900 bytes --]

Re: [9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

oh ho

*Boofhead* was the name of a cartoon character in a Sydney newspaper during
the 1940s.[1] <https://en.wiktionary.org/wiki/boofhead#cite_note-1>

On Tue, Mar 25, 2025 at 8:30 PM ron minnich <rminnich@gmail.com> wrote:

> dave, are you sure?
> https://en.wiktionary.org/wiki/boofhead
>
>
> On Tue, Mar 25, 2025 at 6:31 PM Dave Lukes via 9fans <9fans@9fans.net>
> wrote:
>
>>
>>
>> On 26 Mar 2025 00:02, Ron Minnich <rminnich@p9f.org> wrote:
>>
>> etymology of boofhead: I don't know, picked it up from ericvh, who
>> picked it up at Murray Hill.
>>
>>
>> The correct spelling is "bofhead": it's a Boyd-ism.
>>
>> Dave.
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Me578c5abe35a9f8f979ffa17>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Mfe6b7c534f031ef828cb0f07
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3176 bytes --]

Re: [9fans] NIX this morning

[vester.thacker]

To bring it full circle, Boyd Roberts was from New South Wales, so chances are he used the word boofhead more than once, probably with a grin and a bit of cheek. He had a great sense of humour.

This spring marks 20 years since his passing. Good friends like him are never forgotten.

Vic.

On Wed, Mar 26, 2025, at 12:30, ron minnich wrote:
> dave, are you sure?
> https://en.wiktionary.org/wiki/boofhead
>
>
> On Tue, Mar 25, 2025 at 6:31 PM Dave Lukes via 9fans <9fans@9fans.net>
> wrote:
>
>>
>>
>> On 26 Mar 2025 00:02, Ron Minnich <rminnich@p9f.org> wrote:
>>
>> etymology of boofhead: I don't know, picked it up from ericvh, who
>> picked it up at Murray Hill.
>>
>>
>> The correct spelling is "bofhead": it's a Boyd-ism.
>>
>> Dave.
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-Me578c5abe35a9f8f979ffa17>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M9cbca8a3fbaea9091d60c234
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this morning

[Dave Lukes via 9fans]

[-- Attachment #1: Type: text/html, Size: 3024 bytes --]

Re: [9fans] NIX this morning

[Wes Kussmaul]

Dave, over the last century a rapidly increasing number of jobs that 
keep peoples' noses on their desks and away from the truly beneficial 
state you describe are make-work jobs. People fear algorithms replacing 
meaningful work in the future without realizing that much of it has 
already happened, and so various mandates and commercial pressures yield 
a harvest of fake jobs.

I'm working with a group that is going to try to get public 
acknowledgement of this naked emperor. We want to replace fake jobs with 
mechanisms that facilitate work that is both compensated and fully 
driven by individual initiative, with the notion of an assigned "job 
description" made obsolete.


On 4/1/25 08:32, Dave Lukes via 9fans wrote:
> This is definitely off-topic and relatively long, for which I apologise 
> in advance, but since it might be useful and I can speak about it from 
> experience, I will ...
> 
> I highly recommend retirement, most of all because it frees your mind; 
> it also frees your time, but that will get eaten up by the million&one 
> things that you will find out that you want to do.
> 
> A couple of years ago, I retired early because I could, not because I'm 
> wealthy but because I realised that I possessed "enough" to survive 
> without a job: "enough" being a complex & subjective set of factors.
> I highly recommend saving huge lumps of your income, living frugally in 
> order to get to that point ASAP and doing the above calculation for 
> yourself sooner rather than later, iterating every time you decide that 
> you hate going to work.
> 
> Until I contemplated retirement I didn't truly realise how much of my 
> intellectual+emotional bandwidth as well as my chronological bandwidth 
> was eaten up by the "day job".
> I am well aware that there may be very clever people on this list who 
> can do a job and do lots of other things without messing their brains 
> up, but I realised, too late, that my brain has been burned by too much 
> nonsense.  If you've ever worked on lots of "mainstream" software you 
> may understand what I mean.
> (TBH extreme abuse of so-called "recreational" drugs in my youth 
> probably played a part as well).
> 
> Sadly, all those years working on things I didn't like have soured my 
> brain to the point where I gradually moved away from liking software to 
> tolerating it.
> I now regard myself as merely a user of software: I don't have the 
> intellectual/emotional energy to work on plan9 and other nice things;
> I stay on this mailing list for intellectual pleasure (a true "9fan") 
> and look back nostalgically at the time when I organised the 1st plan9 
> workshop in a room in London :'(.
> 
> My pleasures are now: DIY, gardening, volunteering at repair cafés and 
> other such stuff.  I don't regret my life, I'm happy, but if I'd taken 
> more care of my brain, I might have been happy *and* be typing this on 
> plan9 instead of Linux.
> 
> One caveat is that: if you have been working all your life, retirement 
> may seem strange: you have to manage all your own time; some people 
> tolerate it better than others: I am still adjusting to it after more 
> than a year and a half.
> 
> 
> So maybe a good TL;DR would be: stay away from the ugly software as much 
> as you can and retire ASAP.
> 
> Dave.
> 
> 
> On 28/03/2025 17:55, Brian L. Stuart wrote:
>> On Thu, Mar 27, 2025 at 07:47:02AM -0700, ron minnich wrote:
>>> Off to my day job :-)
>> Ron,
>> I've heard rumors (perhaps apocryphal) that there exists
>> a state of being where there is no "day job" and you can
>> spend all your time on things that are more intellectually
>> satisfying than any suit could ever appreciate.  I think
>> they call it "retirement."  Of course, that may be as mythical
>> as "vacation."  But I've got a basement full of unstarted
>> and half-finished projects that are calling out for me
>> find a path to this nirvana.
>>
>> BLS
>>

-- 



*Wes Kussmaul*

*Reliable Identities, Inc.*
an Authenticity Enterprise
738 Main Street
Waltham, MA 02451 USA
t: +1 781 790 1674
m: +1 781 330 1881
e: wes@ReliableID.com <mailto:wes@ReliableID.com>

Ranked *#12* in the *Thinkers 360* list of

*Top 50 Global Top Thought Leaders *

*and Influencers on Security 2023*

Learn About Authenticity
<https://www.taisites.com/VIDEOS/quick-tour-of-authenticity.mp4>

This message is confidential. It may also be privileged or otherwise
protected by work product immunity or other legal rules. If you have
received it by mistake, please let us know by e-mail reply and delete it
from your system; you may not copy this message or disclose its contents
to anyone. The integrity and security of this message cannot be assured
unless it is digitally signed by the PEN of an identity certificate with
an IDQA score that is sufficient for your purposes.





------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T10229a3f9069de91-Md4545d0354eac0b50c2fded6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this morning

[Dave Lukes via 9fans]

This is definitely off-topic and relatively long, for which I apologise 
in advance, but since it might be useful and I can speak about it from 
experience, I will ...

I highly recommend retirement, most of all because it frees your mind; 
it also frees your time, but that will get eaten up by the million&one 
things that you will find out that you want to do.

A couple of years ago, I retired early because I could, not because I'm 
wealthy but because I realised that I possessed "enough" to survive 
without a job: "enough" being a complex & subjective set of factors.
I highly recommend saving huge lumps of your income, living frugally in 
order to get to that point ASAP and doing the above calculation for 
yourself sooner rather than later, iterating every time you decide that 
you hate going to work.

Until I contemplated retirement I didn't truly realise how much of my 
intellectual+emotional bandwidth as well as my chronological bandwidth 
was eaten up by the "day job".
I am well aware that there may be very clever people on this list who 
can do a job and do lots of other things without messing their brains 
up, but I realised, too late, that my brain has been burned by too much 
nonsense.  If you've ever worked on lots of "mainstream" software you 
may understand what I mean.
(TBH extreme abuse of so-called "recreational" drugs in my youth 
probably played a part as well).

Sadly, all those years working on things I didn't like have soured my 
brain to the point where I gradually moved away from liking software to 
tolerating it.
I now regard myself as merely a user of software: I don't have the 
intellectual/emotional energy to work on plan9 and other nice things;
I stay on this mailing list for intellectual pleasure (a true "9fan") 
and look back nostalgically at the time when I organised the 1st plan9 
workshop in a room in London :'(.

My pleasures are now: DIY, gardening, volunteering at repair cafés and 
other such stuff.  I don't regret my life, I'm happy, but if I'd taken 
more care of my brain, I might have been happy *and* be typing this on 
plan9 instead of Linux.

One caveat is that: if you have been working all your life, retirement 
may seem strange: you have to manage all your own time; some people 
tolerate it better than others: I am still adjusting to it after more 
than a year and a half.


So maybe a good TL;DR would be: stay away from the ugly software as much 
as you can and retire ASAP.

Dave.


On 28/03/2025 17:55, Brian L. Stuart wrote:
> On Thu, Mar 27, 2025 at 07:47:02AM -0700, ron minnich wrote:
>> Off to my day job :-)
> Ron,
> I've heard rumors (perhaps apocryphal) that there exists
> a state of being where there is no "day job" and you can
> spend all your time on things that are more intellectually
> satisfying than any suit could ever appreciate.  I think
> they call it "retirement."  Of course, that may be as mythical
> as "vacation."  But I've got a basement full of unstarted
> and half-finished projects that are calling out for me
> find a path to this nirvana.
> 
> BLS
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T10229a3f9069de91-Me7052bb5ea5846cad9bae068
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX this morning

[Brian L. Stuart]

On Thu, Mar 27, 2025 at 07:47:02AM -0700, ron minnich wrote:
> Off to my day job :-)

Ron,
I've heard rumors (perhaps apocryphal) that there exists
a state of being where there is no "day job" and you can
spend all your time on things that are more intellectually
satisfying than any suit could ever appreciate.  I think
they call it "retirement."  Of course, that may be as mythical
as "vacation."  But I've got a basement full of unstarted
and half-finished projects that are calling out for me
find a path to this nirvana.

BLS


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T10229a3f9069de91-M025e341cd6009ff6e343eee1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

OK, the issue around waserror()/poperror() is fixed, as it was done in the
original NIX. Feel free to pull.

Off to my day job :-)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T10229a3f9069de91-M81d143de9b00d583cd3f2f4a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 856 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Paul and I have been trying things out and, as of this morning, we can
successfully run /bin/date on an AC.

Some things still don't work. Just about anything involving a trap won't
end well; the trap in this case is an fpu trap, because something is not
being set up right. It does not happen in all cases, which is what makes it
so much fun.

As always, I pushed all the latest bits to 9front branch.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T3c9993cc6a455c9f-Mad6a4a2d612c578d8a416ce5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1162 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

OK, I'm on what may be the last problem.

I was having trouble writing a reproducer, until I wrote one by accident,
by fat-fingering %f instead of %d in a print. That caused the problem.

Turns out that I'm still not quite handling the fpu right on the AC, which
will require some more study of what we did in NIX and why.

But programs that don't use float at all work fine.

I think about 1/2 my bug discoveries come from mistakes like this :-)

but ... I have run some commands to completion on an AC at this point, so
it's close.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te5fdc53a0157b4a9-M740e1cdb0a3ebfbb9e6eaa97
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1385 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

I've run a command to completion on an AC, with some help. The command is
date. The problem, it turns out, is that I'm somehow corrupting rsp in
the syscall code. Not sure how I pulled that off :-) but that's the issue.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb56a4dce7fab3b4c-M2499942f74c2305ebced71ba
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 976 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

I'm now able to run system calls, i.e AC makes system call, and TC runs it.

Things are getting garbled, and at some point, things go wrong enough to
panic
the kernel.

Not quite sure what's wrong, people are invited to take a look,
particularly at pc64/nix.s

but it's closer, by the day.

Part of this was relearning what we did in 2011 ... it was pretty cool. I
can see why it took the 6 or so of us a few days to get it right :-)

I still don't totally believe I'm setting  up the stack right when I go to
reset it:
MOVQ RMACH, RSP
ADDQ $MACHSIZE, SP // hmm. Is that really right? Or too big?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb67e80a60bd01ca5-M278d594700b917b76c4030b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1492 bytes --]

[9fans] nix this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

very, very close, I'm running procs on an AC, system calls are messed up
somehow, but ...
getting there.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6ec06670104f2d9f-Mff33bf911b26268d9ef481ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 801 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

we're probably starting the process on an AC, the process is calling a
system call and resuming on the TC, it does the system call, and explodes
once it's back running on the AC.

Multiple little bug fixes and that's where we are. We take a page fault in
kernel mode on the AC, still trying to find that last change needed.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T75ffd266fb318010-Me40c0b87f0588b029cf3c583
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

[9fans] NIX this morning

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

The new default branch is 9front. https://github.com/rminnich/9front

I just pushed a commit that:
1. has the execac command use sysr1 for now
2. drops bootrc into a shell before root is mounted so you can poke around
and run execac
3. adds ratrace, execac, and date

When you build nix, look in systab.h, replace
[SYSR1] sysr1,
with
[SYSR1] sysexecac

it's just easier to coopt sysr1 for now

when you boot, make sure you have at least 2 cores; when it drops to a
shell, try this
execac -c 1 /bin/date
That would run /bin/date on core 1.

In a perfect world.

well ...
qunlock called with qlock not held, from 0xffffffff8021e5c2
qunlock called with qlock not held, from 0xffffffff8021e5c2

oops.

If you know how to debug qemu with gdb, well, here's a place to start.
Or just look at what's at that PC in the kernel, and see what it might be

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5032253608c13e6b-Mc1c1fcd703a83579c25cc727
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1977 bytes --]