x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

On Mon, May 14, 2018 at 9:37 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Mon, May 14, 2018 at 10:20 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Mon, May 14, 2018 at 9:30 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> > On 14/05/18 15:20, Amaan Cheval wrote:
>> >>
>> >> For now, do we all agree to x86_64 as the arch, and x86_64_generic as
>> >> the
>> >> BSP?
>> >
>> >
>> > I would drop the _generic. I don't think there will be a non-generic BSP
>> > on
>> > this architecture.
>> >
>>
>> I agree. Use x86_64 for the arch. The BSP name can also be x86_64, or
>> a variant of the generic such as (please don't hit me): amd64, x86 :)
>
>
> amd64's not awful. :)
>
> Another direction which is dated now but I think FreeBSD has directories
> with these names is the "PCxxx" standards. These are the PC System
> Design Guide editions from Intel and Microsoft.
>
> https://en.wikipedia.org/wiki/PC_System_Design_Guide
>
> Unfortunately, the last was PC2001.
>
> http://tech-insider.org/windows/research/2000/1102.html
>
> But that predates UEFI so wouldn't be the best option.
>
> The PCxxx specifications show that the PC evolved slowly but has had
> changes over the years. Don't assume that just because some peripherals
> are part of the "CPU" component now that they aren't shared or won't
> change in the future. For example, the PC/AT included the cascaded
> part of i8259s which are still emulated today in "legacy" mode. However,
> the APIC is the preferred interrupt controller now and it has been through
> a couple of revisions as I recall.  This is leading up to putting this
> support
> code in bsps/x86_64/shared and have BSP variants use various combinations.
> You could start with a "legacy" BSP (bad name) which uses old style
> interrupts, etc. As more code for "non-legacy" comes into being, use
> it in another BSP variant.

This is an interesting idea, but I think I'd rather lean away from it
unless we plan on keeping both the legacy and non-legacy versions for
the BSP variants. Is that the idea?

In my vision, that might happen while I'm working on the port, in my
fork, but what'll be upstreamed won't be multiple BSP variants (unless
we come upon them naturally in the course of the work), in which case
what'll be upstreamed won't need the segregation or the BSP variants,
since it'll only be one variant. Does that seem misguided? (I'm also
leaning away from it because I'm relatively uneducated about the
history of computer architecture, so I'd need to spend more time
figuring out how these things evolved, which seems unnecessary for the
port.)

FYI: For now, I'm going with "bsps/x86_64/amd64" in my fork, and we
can fine-tune the BSP name and its alias as more discussion takes
place (so as to not be blocked by a naming issue).

>
> --joel
>
>>
>>
>>
>> >
>> > --
>> > Sebastian Huber, embedded brains GmbH
>> >
>> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> > Phone   : +49 89 189 47 41-16
>> > Fax     : +49 89 189 47 41-09
>> > E-Mail  : sebastian.huber at embedded-brains.de
>> > PGP     : Public key available on request.
>> >
>> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel