bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments about SMP


From: Adam Van Ymeren
Subject: Re: Comments about SMP
Date: Sun, 10 Mar 2019 13:08:23 -0400
User-agent: K-9 Mail for Android


On March 10, 2019 11:58:14 AM EDT, Almudena Garcia <liberamenso10000@gmail.com> 
wrote:
>>
>> My point is that it doesn't have to be during boot, it could be after
>> userland started a least a bit.
>>
>
>A simple question: Is It possible to run a routine in userland from
>gnumach?
>Or It's necessary to run a external userland application, as a Hurd
>server.
>
>I don't know if could be possible to call to Hurd ACPI translator from
>gnumach.

I don't think that's necessary.  The process doesn't have to initiated from 
gnumach.  Hurd could have an SMP server that is started at boot, parses acpi 
tables and calls in to Mach to initialize the additional cores and start 
scheduling on them.

>
>
>
>El dom., 10 mar. 2019 a las 16:16, Samuel Thibault
>(<samuel.thibault@gnu.org>)
>escribió:
>
>> Almudena Garcia, le dim. 10 mars 2019 16:04:29 +0100, a ecrit:
>> > I don't sure about you says.  Are you suggesting to boot the other
>cores
>> from a
>> > Hurd server?
>>
>> I mean to possibly provide from userland to the kernel the
>information
>> for booting the other cores.
>>
>> > My idea is about to implement SMP support from gnumach, searching
>and
>> starting
>> > the cpus during the boot.
>>
>> My point is that it doesn't have to be during boot, it could be after
>> userland started a least a bit.
>>
>> > I can find the other cpus (the local apic and ioapic) from ACPI
>tables,
>> but
>> > after this I need to send an IPI to enable them, and configure
>their
>> lapic and
>> > ioapic.
>>
>> Sure, the actual implementation needs to be in the kernel. I just
>mean
>> we can avoid the complex ACPI stuff part in the kernel by just using
>a
>> user-level implementation.
>>
>> Samuel
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]