* x86_64/boothdr.S: there is no reason to not use it right away
---
x86_64/boothdr.S | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/x86_64/boothdr.S b/x86_64/boothdr.S
index d81f9a78..0ab9bd55 100644
--- a/x86_64/boothdr.S
+++ b/x86_64/boothdr.S
@@ -158,7 +158,7 @@ switch6
* i386/i386/idt.c: add selector for the interrupt-specific stack
* i386/i386/ktss.c: configure ist1
* i386/i386/trap.c: add double fault handler, which just prints the
state and panics. There is not much else to do in this case but it's
useful for troubleshooting
* x86_64/idt_inittab.S: allow t
When entering a syscall we're still using the user stack, so we can't
reliably handle exceptions or interrupts, otherwise a user thread can
easily crash the machine with an invalid stack. Instead, disable
interrupts and (hopefullly) avoid traps in the fragments where we need
to have the user stack
Il 15/06/23 19:41, Sergey Bugaev ha scritto:
On Thu, Jun 15, 2023 at 8:02 PM Luca wrote:
That's a bit strange, with my kernel I can now successfully end the
second stage, and without these warnings. Strangely, I don't see the
"Setting up translators: " line...
Check /debootstrap/debootatrap.l
We need to properly convert MACH_PORT_NAME_DEAD (which is 32-bit -1)
into IO_DEAD, which is 64-bit -1.
To reproduce:
$ portinfo -va 1
(see the Mach crash trying to access a port at 0x)
---
ipc/ipc_kmsg.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/ipc/ipc_k
On Thu, Jun 15, 2023 at 8:02 PM Luca wrote:
> That's a bit strange, with my kernel I can now successfully end the
> second stage, and without these warnings. Strangely, I don't see the
> "Setting up translators: " line...
Check /debootstrap/debootatrap.log :)
The output I posted was from both de
Hi Sergey,
Il 15/06/23 16:54, Sergey Bugaev ha scritto:
* For USER32, don't store fs/gs base at all
* For !USER32, store fs/gs base outside of the PCB stack
* For !USER32, don't store or touch es, ds, fs, gs (but keep ss and cs)
* For !USER32, disable all of the v86 code
---
Incidentally I hav
Sergey Bugaev, le jeu. 15 juin 2023 18:15:12 +0300, a ecrit:
> On Thu, Jun 15, 2023 at 6:00 PM Samuel Thibault
> wrote:
> > > debootstrap is still not quite happy. I've uploaded the log here: [0]
> > >
> > > [0]: https://paste.gg/p/anonymous/c976008dc38342cd963b0778586ead19
> >
> > Which part see
On Thu, Jun 15, 2023 at 6:00 PM Samuel Thibault wrote:
> > debootstrap is still not quite happy. I've uploaded the log here: [0]
> >
> > [0]: https://paste.gg/p/anonymous/c976008dc38342cd963b0778586ead19
>
> Which part seems problematic?
All those warnings, but these in particular:
---
dpkg: war
Sergey Bugaev, le jeu. 15 juin 2023 17:54:10 +0300, a ecrit:
> (not that I know what v86 is, but it sounds like something we don't
> need to support considering we only allow running x86_64 code).
Yes we don't care :)
> debootstrap is still not quite happy. I've uploaded the log here: [0]
>
> [0
* For USER32, don't store fs/gs base at all
* For !USER32, store fs/gs base outside of the PCB stack
* For !USER32, don't store or touch es, ds, fs, gs (but keep ss and cs)
* For !USER32, disable all of the v86 code
---
So I went ahead and just made x86_64 !USER32 not store or access those
segment
On Thu, Jun 15, 2023 at 2:14 AM Samuel Thibault wrote:
> > Well, if there was, say, a call for pre-release testing,
>
> Well, Debian did ask for testing.
>
> I guess I should explicitly tell debian-hurd@ "hey that's a matter for
> *us* too".
I don't think I understand what you mean; but what I me
12 matches
Mail list logo
