Almudena Garcia, le jeu. 30 août 2018 23:46:46 +0200, a ecrit:
> Yes. With "duplicate", I referred to exists code files which has an
> implementation to single core case and other implementation to the multicore
> case.
> Not the same exact code, simply the files has different algorithms to each
>
Yes. With "duplicate", I referred to exists code files which has an
implementation to single core case and other implementation to the
multicore case.
Not the same exact code, simply the files has different algorithms to each
case.
El jue., 30 ago. 2018 a las 23:37, Samuel Thibault ()
escribió:
>
Almudena Garcia, le jeu. 30 août 2018 20:43:24 +0200, a ecrit:
> If I execute "grep -R "NCPUS > 1", it returns this files ;)
> kern/machine.c:#if NCPUS > 1
> kern/machine.c:#endif /* NCPUS > 1 */
> kern/machine.c:#if NCPUS > 1
> kern/machine.c:#else /* NCPUS > 1 */
> kern/machine.c:#en
Enabling multicore support in the processor is only a small part of the
problem. The OS is still in charge of deciding how to utilize those multiple
cores to run all its threads and processes.
From: Almudena Garcia
Sent: Thursday, August 30, 2018 1:36 PM
To: Richard Braun; bug-hurd@gnu.org; Jos
Almudena Garcia, le jeu. 30 août 2018 20:30:57 +0200, a ecrit:
> For example, I saw the duplicated code in pmap.h and pmap.c.
Which duplication? All I see there is macros which are non-trivial in
the SMP case, and very trivial in the non-SMP case.
> Also in kern/ cpu_number.h (the code what I fix
If I execute "grep -R "NCPUS > 1", it returns this files ;)
kern/machine.c:#ifNCPUS > 1
kern/machine.c:#endif/* NCPUS > 1 */
kern/machine.c:#ifNCPUS > 1
kern/machine.c:#else/* NCPUS > 1 */
kern/machine.c:#endif /* NCPUS > 1 */
kern/processor.c:#ifNCPUS > 1
kern/processor.c:#end
> Both components are duplicated its codes to run with a single processor
and
> multiprocessor.
Which duplication do you see? sched_prim.c is shared.
For example, I saw the duplicated code in pmap.h and pmap.c. Also in
kern/cpu_number.h (the code what I fixed), and many codes in kern/
directory.
Almudena Garcia, le jeu. 30 août 2018 20:12:07 +0200, a ecrit:
> Both components are duplicated its codes to run with a single processor and
> multiprocessor.
Which duplication do you see? sched_prim.c is shared.
> Also, there is another problem with drivers, what aren't thread-safe. Then, we
> h
Yes, I know. But the processor scheduler is implemented yet in GNU Mach
code. Also the Memory Management Unit.
Both components are duplicated its codes to run with a single processor and
multiprocessor. May can be needed to do code fixes to repair any error, but
these components exist.
Also, there
Almudena Garcia, le jeu. 30 août 2018 19:35:23 +0200, a ecrit:
> But... Why we can't implement this via hardware?
Because it would cast into stone the way to schedule threads. OSes use
very finely tuned heuristics (for fairness, priorities, locality, etc.)
to schedule threads, which we do not want
But... Why we can't implement this via hardware? Configuring multiprocessor
in the CPU.
I don't know what is the problem to do this.
Also, this multiprocessor support can be optional, allowing the user to
enable or disable It.
El jue., 30 ago. 2018 a las 19:01, Samuel Thibault ()
escribió:
>
Hello,
Almudena Garcia, le jeu. 30 août 2018 18:58:19 +0200, a ecrit:
> Instead, It feels to use a strange implementation to do
> multithreading (not real multiprocessor) via software.
It's not "strange", it's what all OSes do. Even with multiple
processors, OSes do that, to schedule threads on t
>
> That's not what I meant. Please improve your English.
Excuse me, I'm trying to improve my English, hahaha.
You're heavily misusing words here. You're not talking about a "hardware
> SMP implementation", just asking the system how many processors it has.
> That's a very tiny detail among all
On Thu, Aug 30, 2018 at 06:15:28PM +0200, Almudena Garcia wrote:
> It's not only a test. Obviously, It must start as a test, but I want to add
> this to Hurd if runs.
>
>
>
> El jue., 30 ago. 2018 a las 18:02, Richard Braun ()
> escribió:
>
> > On Thu, Aug 30, 2018 at 05:53:42PM +0200, Almudena
On Thu, Aug 30, 2018 at 05:53:42PM +0200, Almudena Garcia wrote:
> I've said It yet.
>
> > As this
> > form, we don't need to know how many cores has the processor and set the
> > core number in Mach in compilation time. Instead, the same processor will
> > detect the cores number and configure SM
It's not only a test. Obviously, It must start as a test, but I want to add
this to Hurd if runs.
El jue., 30 ago. 2018 a las 18:02, Richard Braun ()
escribió:
> On Thu, Aug 30, 2018 at 05:53:42PM +0200, Almudena Garcia wrote:
> > I've said It yet.
> >
> > > As this
> > > form, we don't need to
On Thu, Aug 30, 2018 at 05:32:40PM +0200, Almudena Garcia wrote:
> Excuse me, It's a little offtopic.
>
> I was talking about implement SMP via hardware in Hurd (Mach really). In
> this implementation, Mach configures the processor during the boot,
> enabling multicore support. (All Pentium 4 or m
I've said It yet.
> As this
> form, we don't need to know how many cores has the processor and set the
> core number in Mach in compilation time. Instead, the same processor will
> detect the cores number and configure SMP automatically.
I don't know the exact assembly instructions, but I read ab
Excuse me, It's a little offtopic.
I was talking about implement SMP via hardware in Hurd (Mach really). In
this implementation, Mach configures the processor during the boot,
enabling multicore support. (All Pentium 4 or modern x86 processor supports
this)
In the current SMP support, this multic
On Thu, Aug 30, 2018 at 04:52:28PM +0200, Almudena Garcia wrote:
> > But this solution would be specific to Intel chips? ie: this method of
> > SMP wouldn't work on AMD or POWER right
>
> All x86 architecture, I think
What on Earth are you talking about ?
--
Richard Braun
>
>
> But this solution would be specific to Intel chips? ie: this method of
> SMP wouldn't work on AMD or POWER right
All x86 architecture, I think
El jue., 30 ago. 2018 a las 15:09, Joshua Branson ()
escribió:
> Almudena Garcia writes:
>
> > Hi:
> >
> > Also how does one implement SMP via
Almudena Garcia writes:
> Hi:
>
> Also how does one implement SMP via hardware and NOT software? Is this
> a portable approach to do SMP? Will this approach allow SMP on Intel,
> AMD, ARM, POWER, and RISC chips?
>
> I'm reading about Intel processor can be configured to run in multicore mode
Joan Lledó, le jeu. 30 août 2018 10:15:40 +0200, a ecrit:
> sockets: fix lwip_getsockname/lwip_getpeername for dual-stack:
> ip_addr_t type "any" (dual) has to be converted to AF_INET6
Applied, thanks!
Samuel
sockets: fix lwip_getsockname/lwip_getpeername for dual-stack:
ip_addr_t type "any" (dual) has to be converted to AF_INET6
---
debian/patches/getpeername_dual | 11 +++
debian/patches/series | 1 +
2 files changed, 12 insertions(+)
create mode 100644 debian/patches/getpeername_
Hi,
I found a bug in the lwip version we're using for our debian package and
created a new patch to apply the solution. The bug is fixed upstream, in fact,
this new patch is a particular commit cherry-picked from upstream, so must be
marked as "already upstream".
25 matches
Mail list logo