Regarding naming, how about we settle on something like "bsps/amd64/amd64_generic", borrowing from how the riscv target is structured?
On Tue, May 8, 2018 at 9:02 AM, Chris Johns <chr...@rtems.org> wrote: > On 05/05/2018 04:07, Amaan Cheval wrote: >> On Fri, May 4, 2018 at 7:03 AM Chris Johns <chr...@rtems.org> wrote: >> >>> On 03/05/2018 17:09, Amaan Cheval wrote: >>>> On Thu, May 3, 2018 at 5:56 AM Chris Johns <chr...@rtems.org> wrote: >>>> >>>>> On 01/05/2018 23:09, Amaan Cheval wrote: >>>>>> Quick update: My x86_64 stub port compiles and can be linked to all >>>> default >>>>>> tests now! _dance_ >>>>>> >>>>>> I've pushed the stub port for the x86_64 to my fork on Github; the >>>> commits >>>>>> are horribly messy (I did most of the work aiming for the stub to be >> one >>>>>> commit, then later I realized several commits would make more sense >> for >>>>>> when I'll have to rebase and catch up with master - TL;DR: ignore the >>>>>> commits, I'll squash and make them make more sense later). >>>>>> >>>>>> >>>> >> https://github.com/AmaanC/rtems/tree/ac/stub-x86-link-tests-pre-bspreorg-bak >>>>>> >>>> >>>>> Thanks. Updating to master would be good, lots has changed. >>>> >>>>> Why ... >>>> >>>>> bsps/x86_64/i386 >>>>> bsps/x86_64/i386/pc386 >>>> >>>>> .. ? Can the BSP's layout be simplified to something flatter? >>>> >>>> >>>> Definitely - the work so far has been very hacky, leaving a mess all >> over >>>> the place to just make note of issues that I'll need to look into in >> more >>>> detail. With the rebase to master, I'll be making these changes with a >> lot >>>> more thought. >> >>> Excellent and thanks. >> >>>> >>>>> I see FreeBSD has amd64, x86 and i386 in src/sys. I do not know what >> the >>>>> differences are? I run FreeBSD amd64 on Intel devices. >>>> >>>> >>>> Not sure of the differences, really. I noticed that earlier too, but >> I'll >>>> have to dig into that later. >>>> >> >>> I briefly looked and it seems the amd64 was more complete. >> >>> Do you think we should have bsps/x86_64/amd64 as the BSP? >> >>> I think the more generic name of 'amd64' is better than 'pc' plus it >> aligns us >>> with the naming other platforms use. >> >> >> Given that amd64/x86_64 refer to the ISAs, not specific processors, I think >> it's up between these for me: >> >> - amd64/pc >> - x86_64/pc > > I would prefer we have a single BSP. If we reach a point these differences are > important I would be super impressed. > > >> I don't feel strongly about this, but I think the generic "x86_64/pc" may >> be more technically accurate given that there are some very subtle >> differences between x86-64 and AMD64, and this port will be tested on >> generic 64-bit Intel processors.> >> https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64 >> >> What do you think? > > When I look at an OS I tend to get the amd64 build for any x86_64 > implementation, maybe this is just my view of things. > > These offer amd64 ... > > http://mirror.internode.on.net/pub/ubuntu/releases/18.04/ > http://mirror.internode.on.net/pub/FreeBSD/releases/ > http://mirror.internode.on.net/pub/NetBSD/NetBSD-7.1.2/ > http://mirror.internode.on.net/pub/debian/dists/Debian9.4/main/ > > CentOS and Fedora are different and offer x86_64: > > http://mirror.internode.on.net/pub/centos/7.4.1708/isos/x86_64/ > http://mirror.internode.on.net/pub/fedora/linux/releases/28/Everything/x86_64/ > > macOS (darwin) is x86_64: > > $ uname -a > Darwin mohua 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar 5 22:24:32 PST > 2018; > root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64 > >> >>>>> Is there a build of x86_64 hardware that is _not_ a PC? I think it >> makes >>>> sense >>>>> to assume for now we support just a PC and so we can have x86_64/pc. To >>>> clarify >>>>> this statement, I am sure there are a number VME, CompactPCI and other >>>>> industrial boards which I suspect will be a PC architecture to the >>>> operating >>>>> systems running on them. >>>> >>>>> I would prefer you commit files from the i386/.. tree as they are >> merged, >>>> tested >>>>> and cleaned up rather than dumping in the existing PC BSP into the new >>>> BSP. For >>>>> example I would prefer we consider: >>>> >>>>> https://github.com/freebsd/freebsd/tree/master/sys/dev/vt >>>> >>>>> for the console for this BSP. The code will have FreeBSD kernel >>>> dependencies >>>>> which can be wrapped or compiled out. Please consider following the >> rules >>>> we use >>>>> for adding and changing FreeBSD source in libbsd, it would help us >> track >>>> FreeBSD >>>>> in the future. I would also consider adding this code to x86_64/dev/vt >>>> and have >>>>> the x86_64/pc BSP reference it. >> >> What do you think about x86_64/contrib/dev/vt etc. instead and then have >> x86_64/pc reference it? Sounds good to me. > > Contrib as opposed too what other type of sources? I think we will have a lot > of > contributed code in this BSP given the mature base of existing code. My > concern > is everything ends up under that directory. :) > > The 'pc' name does tend to imply it only runs on a PC which may not or should > not be true. It will run on a minow board as well. > > Joel do you have a view? > >> If that complicates things too much with the build system, I'll make sure >> to follow the guidelines here, at least: >> https://devel.rtems.org/wiki/Developer/Coding/ThirdPartyCode >> >> Would you let me know if there's anything more to keep in mind than >> mentioned there? > > I do not know yet. I am sure we will discover things as we go. > >> Also, I'm not quite sure what belongs in libbsd vs. in the rtems repo under >> a specific BSP - do you foresee me needing to make any contributions to >> libbsd during the course of this project? I can't think of anything, since >> even the FreeBSD code I'll adapt will likely be pretty arch/BSP specific, >> but I figured I'd confirm. > > Libbsd is a framework to support FreeBSD services on RTEMS. This BSP is about > the x86_64 support and what it needs to boot and run an RTEMS kernel. We need > to > provide just enough to make this happen and to be self contained. > > We may bring into the BSP tables, data or functions libbsd may need to access > to > work but I feel that is for later if we get time. I am sure we will not get > the > balance right at this point in time so while we should consider this it should > not be a priority for this effort. > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
