Thanks yours!! Now I can continue my work ;)
I like your latest SMP commit too. It will be very useful to the next
development stage. :-)
http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=a76bc939142f61e615fcc39fc940961e39a26207
Thanks!!
El sáb., 19 sept. 2020 a las 21:58, Samuel
Hello,
Juan's copyright assignation was complete, so I could push your code,
thanks!
Samuel
I attach new set of patches, fixing the latest errors
El jue., 13 ago. 2020 a las 0:41, Samuel Thibault ()
escribió:
> Almudena Garcia, le jeu. 13 août 2020 00:35:36 +0200, a ecrit:
> > > Users do need that to understand what's happening.
> > But, if by any reason, the machine has more than cpu
Almudena Garcia, le jeu. 13 août 2020 00:35:36 +0200, a ecrit:
> > Users do need that to understand what's happening.
> But, if by any reason, the machine has more than cpu but the detection fails,
> could be interesting to advise about the system being running with an only
> cpu.
> It's not?
> Applied and fixed a bit, thanks!
Thanks. Now I only have to fix the next patches. We are closer now
> But that will only enter if when api_success != 0, thus when we actually
> have a failure. Compare explicitly against ACPI_SUCCESS
Oops, I forget this. I will fix It.
> Then there is no need
Fair enough. I'll see if I can't try to help you in your project. Fair
warning, I am a little out of my league here. Just writing plain
ordinary C programs with pointers to strucks and memory management is
hard for me.
--
Joshua Branson
Sent from Emacs and Gnus
Almudena Garcia, le mer. 12 août 2020 16:03:06 +0200, a ecrit:
> Subject: [PATCH 1/5] smp: Add pseudoclass to manage APIC operations
Applied, thanks!
> Subject: [PATCH 2/5] vm_kern: Add kmem_alloc_aligned_table
Applied and fixed a bit, thanks!
> Subject: [PATCH 3/5] smp: Add APIC finder and
Almudena Garcia, le mar. 11 août 2020 02:17:35 +0200, a ecrit:
> > What for?
> > num_cpus is something that you make returned by a smp_get_numcpus()
> > function, so it's not actually useful to also expose it in a struct.
> > What else would go into that structure?
> By example, the master cpu
I attach a new set of patches, fixing some errors
El mar., 11 ago. 2020 a las 23:44, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> I fixed the problem manually. I expect the patch works fine.
>
> El mar., 11 ago. 2020 a las 23:24, Almudena Garcia (<
> liberamenso10...@gmail.com>)
I fixed the problem manually. I expect the patch works fine.
El mar., 11 ago. 2020 a las 23:24, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> oops!! I forgot add i386/i386/smp.h and i386/i386/smp.c to i386/Makefrag.am
>
> I will try to fix the patch to add this
>
> El mar., 11 ago.
oops!! I forgot add i386/i386/smp.h and i386/i386/smp.c to i386/Makefrag.am
I will try to fix the patch to add this
El mar., 11 ago. 2020 a las 23:03, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> I attach a new set of patches. I wait this time will be better than last
> time
>
>
I attach a new set of patches. I wait this time will be better than last
time
El mar., 11 ago. 2020 a las 2:27, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> > So don't bring them online then? The user asked for 4 CPUs, so bring up
> > 3 APs alongside the BSP and that's that.
>
Almudena Garcia, le mar. 11 août 2020 14:17:17 +0200, a ecrit:
> > You can use b (break) within a git rebase session to stop at some point.
> > That way you can stop before the big change, commit part of it, and use
> > git rebase --continue, and let git discover that part of the big change
> > is
Yes, It is. This is the branch.
https://github.com/AlmuHS/GNUMach_SMP/tree/smp-new
All commits are related with this patch. The development was long
El mar., 11 ago. 2020 a las 14:30, Amos Jeffries ()
escribió:
> On 12/08/20 12:17 am, Almudena Garcia wrote:
> >> You can use b (break) within a
On 12/08/20 12:17 am, Almudena Garcia wrote:
>> You can use b (break) within a git rebase session to stop at some point.
>> That way you can stop before the big change, commit part of it, and use
>> git rebase --continue, and let git discover that part of the big change
>> is already there and
On 11/08/20 11:57 pm, Samuel Thibault wrote:
> Almudena Garcia, le mar. 11 août 2020 13:45:19 +0200, a ecrit:
>>> P.S. You might be interested in using the program git send-email.
>>> Apparently it makes it really easy to send in a patches series. It's
>>> actually what GNU Guix contributing
> You can use b (break) within a git rebase session to stop at some point.
> That way you can stop before the big change, commit part of it, and use
> git rebase --continue, and let git discover that part of the big change
> is already there and drop it from the big change.
But I have tons of
Almudena Garcia, le mar. 11 août 2020 13:45:19 +0200, a ecrit:
> > P.S. You might be interested in using the program git send-email.
> > Apparently it makes it really easy to send in a patches series. It's
> > actually what GNU Guix contributing guidelines recommends.
> My problem is that, in my
Hi! Thanks for your comments!!
> P.S. You might be interested in using the program git send-email.
> Apparently it makes it really easy to send in a patches series. It's
> actually what GNU Guix contributing guidelines recommends.
My problem is that, in my internal repository, I do many commits
Almudena! Nice work on this! and Holy cow! Your English is getting
fantastic! It inspires me, when I see how much you're learning on this
SMP project. Keep up the good work!
P.S. You might be interested in using the program git send-email.
Apparently it makes it really easy to send in a
> So don't bring them online then? The user asked for 4 CPUs, so bring up
> 3 APs alongside the BSP and that's that.
It's not a bad idea. Then I will fix my cpu enumeration loop to add this
new condition.
El mar., 11 ago. 2020 a las 2:23, Jessica Clarke ()
escribió:
> On 11 Aug 2020, at 01:17,
On 11 Aug 2020, at 01:17, Almudena Garcia wrote:
>
> > That being said, instead of hardcoding the maximum number of CPUs to
> > be 256, you can just let the user choose whatever value is preferred.
> > That's what Linux does.
>
> But this could cause coherency problems.
Coherency is a very
> That being said, instead of hardcoding the maximum number of CPUs to
> be 256, you can just let the user choose whatever value is preferred.
> That's what Linux does.
But this could cause coherency problems.
By example, if the user sets mach_ncpus=4 , and the processor has 8 cores,
It can
Almudena Garcia, le mar. 11 août 2020 01:23:49 +0200, a ecrit:
> > ? git diff produces the same as format-patch, in terms of formatting
> > mistakes... The disadvantage of git diff is that your patches then mix
> > things altogether, see the additions to Makefrag.am. I just cannot apply
> > the
> ? git diff produces the same as format-patch, in terms of formatting
> mistakes... The disadvantage of git diff is that your patches then mix
> things altogether, see the additions to Makefrag.am. I just cannot apply
> the series as it is.
Yes, The problem is that I didn't write each file in a
Hello,
Almudena Garcia, le lun. 10 août 2020 20:56:13 +0200, a ecrit:
> I attach a new version of my patch, fixing some errors and following the
> latest
> comments about this.
That looks nice overall!
> This time, I've generated the files manually from "git diff", instead using
> "git
I attach a new version of my patch, fixing some errors and following the
latest comments about this.
This time, I've generated the files manually from "git diff", instead using
"git format-patch", so the patches could contain little format mistakes.
Excuse me about this issue.
El jue., 30 jul.
> You don't. Read about GDT and segments register, and segmentation in
> general. In the GDT you'd only store a pointer to the per-cpu data, and
> processors will load it.
> > Is there any way to avoid using an array for that?
> Yes, you'd just store the ID in the per-cpu data.
Thanks, I'll
Almudena Garcia, le jeu. 30 juil. 2020 23:30:55 +0200, a ecrit:
> > As Richard said, we just want to have different GDTs on the different
> > processors, so that we wan use the fs segment register to implement TLS
> > in the kernel and have per-cpu data cost essentially the same as global
> >
> As Richard said, we just want to have different GDTs on the different
> processors, so that we wan use the fs segment register to implement TLS
> in the kernel and have per-cpu data cost essentially the same as global
> data.
Yes, but how can I store the relation APIC ID - Kernel ID in the GDT?
> Well, yes, though you probably don't want to be using a fancy hash
> table in such low-level code, so you'd either have an array of 2^16 CPU
> IDs which is a bit absurd.
The maximum number of cpus in xAPIC is 256, not 2^16. My array is indexed
by Kernel ID.
My array is refitted to the exact
Samuel Thibault, le jeu. 30 juil. 2020 23:21:02 +0200, a ecrit:
> As Richard said, we just want to have different GDTs on the different
> processors, so that we wan use the fs segment register to implement TLS
> in the kernel and have per-cpu data cost essentially the same as global
> data.
(I
As Richard said, we just want to have different GDTs on the different
processors, so that we wan use the fs segment register to implement TLS
in the kernel and have per-cpu data cost essentially the same as global
data.
Samuel
> You can build a CPU ID table on the BSP, and associate CPU IDs
> with all local APIC IDs discovered, and use that look-up table later
> to obtain a CPU ID from the local APIC ID of the CPU running the code.
It's my idea, of course. I don't know what you refer to exactly with "using
a segment
On 30 Jul 2020, at 22:12, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
>>> It's physically memory mapped to the local APIC address space, but
>>> because of that, it's also not optimal. All systems I know use a scheme
>>> similar to TLS, i.e. using the fs
On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
> > It's physically memory mapped to the local APIC address space, but
> > because of that, it's also not optimal. All systems I know use a scheme
> > similar to TLS, i.e. using the fs or gs segment register, to fetch
> > a per-CPU
On 30 Jul 2020, at 22:06, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote:
I'm wondering: is it really *that* simple to get the current cpu number,
just read a memory location? I'm surprised that this would provide
different results on
Almudena Garcia, le jeu. 30 juil. 2020 22:59:02 +0200, a ecrit:
> The local APIC's registers are memory-mapped in physical page FEE00xxx (as
> seen
> in table 8-1 of Intel P4 SPG). This address is the same for each local APIC
> that exists in a configuration, meaning you are only able to directly
On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote:
> > > I'm wondering: is it really *that* simple to get the current cpu number,
> > > just read a memory location? I'm surprised that this would provide
> > > different results on different cpus.
> >
> > The APIC ID is stored in the
> That's alright while debugging. But before we commit the source code, we
> need it to be in a way which is the most readable, so people can easily
> work it out.
Ok, then I will modify my code this way.
> ? No. Introducing a variable, remembering that it holds a value, and
> eventually
Almudena Garcia, le mar. 28 juil. 2020 10:27:55 +0200, a ecrit:
> > Simply return rather than using a variable.
> I prefer using a temporary variable to ease debugging in case of error. Direct
> return can be difficult to debug in this case.
That's alright while debugging. But before we commit
> @@ -170,6 +172,14 @@ void machine_init(void)
> linux_init();
> #endif
>
> +#if NCPUS > 1
> + int smp_success = smp_init();
> +
> + if(smp_success != 0) {
> +printf("Error: no SMP found");
> +}
> +#endif /* NCPUS > 1 */
> +
> There's a bogus indent here. Tell your
> 256 is a common default
> (I know that's what FreeBSD uses for x86) as the APIC IDs are 8-bit,
> and I think this should be 256 rather than 255 too
I agree. It's a mistake.
> Though I do
> question what the point of mach_ncpus is if it isn't being used to
> determine NCPUS.
Currently,
On 28 Jul 2020, at 00:44, Samuel Thibault wrote:
> Almudena Garcia, le lun. 27 juil. 2020 21:15:10 +0200, a ecrit:
>> [if [ $mach_ncpus -gt 1 ]; then]
>> AC_DEFINE([MULTIPROCESSOR], [1], [set things up for a multiprocessor])
>> + AC_DEFINE_UNQUOTED([NCPUS], [255], [number of CPUs])
>
>
Hello,
Thanks for your work, we're getting closer!
Almudena Garcia, le lun. 27 juil. 2020 21:15:10 +0200, a ecrit:
> @@ -170,6 +172,14 @@ void machine_init(void)
> linux_init();
> #endif
>
> +#if NCPUS > 1
> + int smp_success = smp_init();
> +
> + if(smp_success != 0) {
> +
New patches collection, fixing the formatting
El lun., 20 jul. 2020 a las 0:35, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> Here are the fixed patches. Check this and advise me if there are any
> errors.
>
> El dom., 19 jul. 2020 a las 23:53, Almudena Garcia (<
>
Here are the fixed patches. Check this and advise me if there are any
errors.
El dom., 19 jul. 2020 a las 23:53, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> > Note: before doing rebases etc. I'd advise to push your current tree to
> > a separate branch that you can always restart
I also find it really helpful to use magit. Emacs' plugin to help me do
git things.
This video is a short introduction for it:
https://www.youtube.com/watch?v=mtliRYQd0j4
--
Joshua Branson
Sent from Emacs and Gnus
> Note: before doing rebases etc. I'd advise to push your current tree to
> a separate branch that you can always restart from, to avoid risking
> losing everything. There are ways to restore things, but it's way easier
> to just keep a branch on the side where you know your changes are safe.
At
Note: before doing rebases etc. I'd advise to push your current tree to
a separate branch that you can always restart from, to avoid risking
losing everything. There are ways to restore things, but it's way easier
to just keep a branch on the side where you know your changes are safe.
Samuel
Almudena Garcia writes:
> But I've already committed these changes in my repository. How can I
> recommit them?
You can change commits with “git rebase”. Use “git rebase -i” for
interactive rebasing, which gives you a list of commits to which you can
apply changes. If you want to change all
On 19 Jul 2020, at 20:07, Almudena Garcia wrote:
>
> But I've already committed these changes in my repository. How can I recommit
> them?
> Added to this, I need to generate the patch using the "master" branch (which
> points to gnumach's upstream) to compare with the mine.
>
> How can I
But I've already committed these changes in my repository. How can I
recommit them?
Added to this, I need to generate the patch using the "master" branch
(which points to gnumach's upstream) to compare with the mine.
How can I solve this?
El dom., 19 jul. 2020 a las 20:51, Almudena Garcia (<
ok. I had splitted It manually. Now I'll try again this way.
El dom., 19 jul. 2020 a las 20:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 19:46, Almudena Garcia
> wrote:
> >
> > > for any patch it’s best to not just show a single large diff but to
> > > split the changes into logically
On 19 Jul 2020, at 19:46, Almudena Garcia wrote:
>
> > for any patch it’s best to not just show a single large diff but to
> > split the changes into logically related commits
> I've just split the patch. I enumerated them following the dependencies
> order.
>
> > The commit
> > message
> for any patch it’s best to not just show a single large diff but to
> split the changes into logically related commits
I've just split the patch. I enumerated them following the dependencies
order.
> The commit
> message should describe the changes in a GNU-style ChangeLog format; you
> may
Anyway, my patch is short. Maybe I can split It manually, taking care about
dependencies between blocks.
El dom., 19 jul. 2020 a las 20:17, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> Thanks for your explanation:
>
> > To commit only some changes and not others you can select
Thanks for your explanation:
> To commit only some changes and not others you can select lines of
> interest with “git add -p” (or similar). Once all connected changes
> have been staged you can commit them. Do this repeatedly until you have
> a series of commits that are all small enough that
Hi,
for any patch it’s best to not just show a single large diff but to
split the changes into logically related commits. You’re probably
working with Git, so the unit that we’re working with is a Git commit.
You should group related changes and commit them together. The commit
message
There are many files with different code styles. I'm confused about what is
the correct style.
El dom., 19 jul. 2020 a las 19:10, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 18:06, Almudena Garcia
> wrote:
> >
> > I fixed tabulations and comments style. Now better?
>
> Not hugely. Go read
Thanks. I'm grateful for your support of my work.
It's a difficult task, and I'm very noob yet. But I'm trying to advance
until my knowledge allows.
The Hurd devs support is very important to learn the necessary to get this
objective.
El dom., 19 jul. 2020 a las 19:01, escribió:
> Hey
On 19 Jul 2020, at 18:06, Almudena Garcia wrote:
>
> I fixed tabulations and comments style. Now better?
Not hugely. Go read files in the same directory and see if they look
like what you've written.
Jess
> El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
> escribió:
> On 19 Jul 2020,
I fixed tabulations and comments style. Now better?
El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 17:44, Almudena Garcia
> wrote:
> >
> > Hi all:
> >
> > I attach a patch, with the code to find the cpus and enumerate them,
> reading from ACPI tables and
Hey Almudena!
I quite admire your determination to work on the Hurd SMP! I would be terrified
to try to work on something crazy cool like that. But as a friend told me
recently, "No one cares about your theories and thoughts. People care about
your actions. There were nights when I was doing a
Ok. I'll check the coding style. I'm trying to follow GNU style, but maybe
I missed It in some files.
El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 17:44, Almudena Garcia
> wrote:
> >
> > Hi all:
> >
> > I attach a patch, with the code to find the cpus and
On 19 Jul 2020, at 17:44, Almudena Garcia wrote:
>
> Hi all:
>
> I attach a patch, with the code to find the cpus and enumerate them, reading
> from ACPI tables and MADT (APIC) tables.
>
> I've tested it over Qemu, but I recommends to test It before committing,
> anyway.
>
> You can find
Hi all:
I attach a patch, with the code to find the cpus and enumerate them,
reading from ACPI tables and MADT (APIC) tables.
I've tested it over Qemu, but I recommends to test It before committing,
anyway.
You can find the rest of the work in my GitHub repository
67 matches
Mail list logo
