I've caught NIX up to 9front tip of tree. All works.
I've backed out one set of changes, to fpu.c.
There's a lingering problem: in the original NIX, at the end of system
calls, we had a function, fakeretfromsyscall, which we called on the tcore,
as we exited back out to the acore.
We've not brou
On 2025/03/08 18:43, Jacob Moody wrote:
Or maybe you start from old
nix and bring in the parts of 9front that you'd need in order to get things
running
on the system you want.
That's a tedious, expensive, but in my opinion wise move. It's also
optional, because clearly 9front is not going to
On 3/8/25 03:03, tlaro...@kergis.com wrote:
> On Fri, Mar 07, 2025 at 01:09:30PM -0600, Jacob Moody wrote:
>> On 3/7/25 06:10, tlaro...@kergis.com wrote:
>>> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
thanks, Jacob.
I'm going to keep at it, and your rebase has now made i
>From my point of view, there's no wrong moves here. Our goal is to learn. I
learned a lot just bringing it all back to life, and I am sure Thierry will
learn a lot with his approach. I look forward to seeing what he does.
Folks, I'm serious, there are lots of simple things to do, and there are
ha
On Sat, Mar 08, 2025 at 10:43:46AM -0600, Jacob Moody wrote:
> > On 3/8/25 03:03, tlaro...@kergis.com wrote:
> >
> > I will start from the subset isolated (due to the pace of Ron and
> > Paul, looong ago now; at least two weeks...), having the current
> > state as reference, but trying to get thin
On Fri, Mar 07, 2025 at 01:09:30PM -0600, Jacob Moody wrote:
> On 3/7/25 06:10, tlaro...@kergis.com wrote:
> > On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> >> thanks, Jacob.
> >> I'm going to keep at it, and your rebase has now made it much easier to
> >> keep up.
> >>
> >> In the
It's not like cgroups at all.
Consider a system with lots of CPUs. Kernels, as they boot, will allocate
all those CPUs for their own use. These CPUs will assigned to different
processes over time, or be assigned to running kernel processes. Interrupts
will be scheduled across this set of cores, wi
Forgive the layman question but is NIX somewhat similar to cgroups in the
Linux kernel?
On Fri, Mar 7, 2025, 6:08 AM wrote:
> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> > thanks, Jacob.
> > I'm going to keep at it, and your rebase has now made it much easier to
> > keep up.
>
On 3/7/25 06:10, tlaro...@kergis.com wrote:
> On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
>> thanks, Jacob.
>> I'm going to keep at it, and your rebase has now made it much easier to
>> keep up.
>>
>> In the usual manner of such things, I think now that we figured out that we
>> ca
The bind approach looked ok for a while. But the problem is the NIX changes
are pretty intrusive. Here are the new files:
sys/src/9/pc64/acore.c
sys/src/9/pc64/nix.s
sys/src/9/pc64/tcore.c
sys/src/cmd/execac.c
there are about 30 changed files, but only 4 new ones. Now, some change we
can get along
On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote:
> thanks, Jacob.
> I'm going to keep at it, and your rebase has now made it much easier to
> keep up.
>
> In the usual manner of such things, I think now that we figured out that we
> can make it work, it's time to toss a lot of those co
thanks, Jacob.
I'm going to keep at it, and your rebase has now made it much easier to
keep up.
In the usual manner of such things, I think now that we figured out that we
can make it work, it's time to toss a lot of those commits away, and get to
something a lot less messy. There's where others c
On 3/6/25 15:07, ron minnich wrote:
> Jacob re the rebase, thank you, it works in qemu and on my t420.
>
> I'm thinking to just set my 9front head to what you've done, push it to my
> fork, and proceed from there. Do you see any reason not to?
Sure by all means.
>
> Where, ultimately, might w
Jacob re the rebase, thank you, it works in qemu and on my t420.
I'm thinking to just set my 9front head to what you've done, push it to my
fork, and proceed from there. Do you see any reason not to?
Where, ultimately, might we want NIX to land?
I need to start turning the dial down on debug pri
On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaro...@kergis.com wrote:
> On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaro...@kergis.com wrote:
> > I need to update the documentation about the building (one needs to
> > bind above the 9front hier, but also to get plan9front/firmware, and
> > to build a
On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaro...@kergis.com wrote:
> I need to update the documentation about the building (one needs to
> bind above the 9front hier, but also to get plan9front/firmware, and
> to build and install brekky).
>
> But it also uses ftq.
BTW, execac is missing also.
I need to update the documentation about the building (one needs to
bind above the 9front hier, but also to get plan9front/firmware, and
to build and install brekky).
But it also uses ftq.
If I'm not mistaken, the git master has an unchanged mkfile relating
to several flavors (ftq{15,31,63}) but
On 3/3/25 21:44, ron minnich wrote:
> I am now able to run the HPC FTQ benchmark and get results, first time since
> 2011.
>
> The results are very, very good on my T420. Next step, see how it goes on a
> server class machine.
>
> If anyone wants to help out, the rebase would be most welcome,
I am now able to run the HPC FTQ benchmark and get results, first time
since 2011.
The results are very, very good on my T420. Next step, see how it goes on a
server class machine.
If anyone wants to help out, the rebase would be most welcome, as would
testing of your choice.
Taking a trap on an
I've added the struct offset generator, updated nix.s with proper offsets,
still trying to understand the gpf.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T46bf984700e20849-Md74c41a60b8b035b5613db70
Delivery options: https://9fans.top
20 matches
Mail list logo
