Re: bsp/riscv: Store/AMO address misaligned trap occured
On 03/11/2022 06:40, padmarao.beg...@microchip.com wrote: On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote: t0 contains the address of .Lsecondary_processor_go start.S has: ```asm #if __riscv_xlen == 32 .align 2 #elif __riscv_xlen == 64 .align 3 #endif .Lsecondary_processor_go: ``` Can you confirm the value of __riscv_xlen is properly defined to 64 for the PolarFire? No, the value of __riscv_xlen is showing 32(config.log) instead of 64 for PolarFire SoC and other 64-bit RISCV BSPs. This is a compiler built-in define. It doesn't matter what is in the config.log. What matters is that the compiler is invoked with the right options. In my build this looks all right. What is the value of t0 in amoswap.w zero, zero, 0(t0) ? Does it help to revert the commit? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On 02/11/2022 08:10, Christian MAUDERER wrote: Am 01.11.22 um 22:08 schrieb Chris Johns: On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to make it a mandatory attribute? It makes the yaml files bigger. It will only mean that we have to look for copy and paste bugs instead of missing attributes if someone adds a new third party library. Can you avoid having to add the item to all? I am no spec build system expert (having invested time) and seem to remember needing to hit a lot of files when adding something ... https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2 Chris The documentation mentions at least some optional attributes in the specification files. For example "format" in a build option item or the "do-configure" in a build script item: https://docs.rtems.org/branches/master/eng/req/items.html#build-option-item-type https://docs.rtems.org/branches/master/eng/req/items.html#build-script-item-type But I think the wscript has to take into account that the value might not exist. I'm not sure whether it does that for the existing "optional" attributes. For example my first guess would be that the "do-configure" could throw a KeyError: https://git.rtems.org/rtems/tree/wscript#n1127 def do_configure(self, conf, cic): script = self.data["do-configure"] if script: exec(script) Usually I would have expected the following code instead: def do_configure(self, conf, cic): try: script = self.data["do-configure"] except KeyError: script = None if script: exec(script) So I can't clearly answer your question. I would have to try it. But regardless whether there are currently such options or not: They shouldn't be hard to implement. I just hope that this doesn't break some use case. I'll try to remember to ask Sebastian about it next week. When I worked on the new build system there was a discussion whether all attributes should be explicit in the items or not. It was decided to make all attributes mandatory in the items. We could of course reconsider this decision, however, from my point of view it was a good decision. It keeps the wscript code simple and the items are self-contained. You don't have to know the source code to figure out what an item describes. Changing the items is very simple with a Python script which uses the stuff in rtems-central. Simple things can be done using grep and sed. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On 31/10/2022 20:01, Gedare Bloom wrote: I would like to float the idea of managing 3rd party source tracking through the build system spec files. I believe this would be the most efficient way to maintain this information, and we can leverage the existing build system code for tasks such as automatic format checks, generating lists of third-party code, etc. This will require refactoring some spec files to pull 3rd party code out to a separate .yml file that gets linked. Once that is done, then we could add another attribute for this tracking purpose. I would like to keep it simple as a boolean, maybe just "third-party: true/false" Attached is an example patch showing how this might work for the dtc/libfdt code as a build objects item type 'obj', and for zlib library as a build library item type 'lib' with some proof-of-concept code for generating a listing of third party source files. In the future we could expand this third-party attribute to a dictionary to provide more detailed information about the third-party sources, for example the upstream Git repository, the import commit, path translation mappings, post and pre import actions. This could be used to automatically generate updates from upstream changes. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsp/riscv: Store/AMO address misaligned trap occured
Hi Sebastian, > On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote: > > On 03/11/2022 06:40, padmarao.beg...@microchip.com wrote: > > > On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote: > > > > > > t0 contains the address of .Lsecondary_processor_go > > > > > > start.S has: > > > ```asm > > > #if __riscv_xlen == 32 > > >.align 2 > > > #elif __riscv_xlen == 64 > > >.align 3 > > > #endif > > > > > > .Lsecondary_processor_go: > > > ``` > > > Can you confirm the value of __riscv_xlen is properly defined to > > > 64 > > > for the PolarFire? > > > > > No, the value of __riscv_xlen is showing 32(config.log) instead of > > 64 > > for PolarFire SoC and other 64-bit RISCV BSPs. > > This is a compiler built-in define. It doesn't matter what is in the > config.log. What matters is that the compiler is invoked with the > right > options. In my build this looks all right. > > What is the value of t0 in > > amoswap.w zero, zero, 0(t0) > > ? > The "t0" value is 0x1000ae > Does it help to revert the commit? > Yes, removed ".option norelax" from start.S and it's working fine. Regards Padmarao > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas > Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsp/riscv: Store/AMO address misaligned trap occured
On 04/11/2022 10:44, padmarao.beg...@microchip.com wrote: Hi Sebastian, On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote: On 03/11/2022 06:40,padmarao.beg...@microchip.com wrote: On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote: t0 contains the address of .Lsecondary_processor_go start.S has: ```asm #if __riscv_xlen == 32 .align 2 #elif __riscv_xlen == 64 .align 3 #endif .Lsecondary_processor_go: ``` Can you confirm the value of __riscv_xlen is properly defined to 64 for the PolarFire? No, the value of __riscv_xlen is showing 32(config.log) instead of 64 for PolarFire SoC and other 64-bit RISCV BSPs. This is a compiler built-in define. It doesn't matter what is in the config.log. What matters is that the compiler is invoked with the right options. In my build this looks all right. What is the value of t0 in amoswap.w zero, zero, 0(t0) ? The "t0" value is 0x1000ae Ok, is this the address of .Lsecondary_processor_go? It is a value > 4GiB. I am not sure how such a value is loaded through la or lla. Does it help to revert the commit? Yes, removed ".option norelax" from start.S and it's working fine. Ok, thanks for testing. I guess we need a hand crafted instruction sequence to load absolute addresses instead of using la or lla. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsp/riscv: Store/AMO address misaligned trap occured
On 04/11/2022 10:49, Sebastian Huber wrote: On 04/11/2022 10:44, padmarao.beg...@microchip.com wrote: Hi Sebastian, On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote: On 03/11/2022 06:40,padmarao.beg...@microchip.com wrote: On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote: t0 contains the address of .Lsecondary_processor_go start.S has: ```asm #if __riscv_xlen == 32 .align 2 #elif __riscv_xlen == 64 .align 3 #endif .Lsecondary_processor_go: ``` Can you confirm the value of __riscv_xlen is properly defined to 64 for the PolarFire? No, the value of __riscv_xlen is showing 32(config.log) instead of 64 for PolarFire SoC and other 64-bit RISCV BSPs. This is a compiler built-in define. It doesn't matter what is in the config.log. What matters is that the compiler is invoked with the right options. In my build this looks all right. What is the value of t0 in amoswap.w zero, zero, 0(t0) ? The "t0" value is 0x1000ae Ok, is this the address of .Lsecondary_processor_go? It is a value > 4GiB. I am not sure how such a value is loaded through la or lla. It seems that the .align directive is broken in the assembler. I checked in b4ffaa7cdcce4fedb857f6b8342301f8dde65c78 as a workaround. Could you please test this commit? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On Fri, Nov 4, 2022 at 2:59 AM Sebastian Huber wrote: > > On 31/10/2022 20:01, Gedare Bloom wrote: > > I would like to float the idea of managing 3rd party source tracking > > through the build system spec files. I believe this would be the most > > efficient way to maintain this information, and we can leverage the > > existing build system code for tasks such as automatic format checks, > > generating lists of third-party code, etc. > > > > This will require refactoring some spec files to pull 3rd party code > > out to a separate .yml file that gets linked. Once that is done, then > > we could add another attribute for this tracking purpose. I would like > > to keep it simple as a boolean, maybe just "third-party: true/false" > > Attached is an example patch showing how this might work for the > > dtc/libfdt code as a build objects item type 'obj', and for zlib > > library as a build library item type 'lib' with some proof-of-concept > > code for generating a listing of third party source files. > > In the future we could expand this third-party attribute to a dictionary > to provide more detailed information about the third-party sources, for > example the upstream Git repository, the import commit, path translation > mappings, post and pre import actions. This could be used to > automatically generate updates from upstream changes. > Nice. I don't see an explicit "dictionary" type for attributes, but I do see that dict-like behavior could be achieved using a 'list' of attributes nested below an attribute. I have the time allocated that i could try to learn how to do this with a simple example, for example to add a "upstream" and an "import-commit" field. Then, the third-party indicator will change from third-party: false -> third-party: [] third-party: true-> third-party: - upstream: URL - import-commit: git-sha I would guess. Would this kind of structure "just work" in the current support of spec/build or will it require some integration with rtems-central? Or, am I following the wrong ideas, -Gedare > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On 04/11/2022 15:38, Gedare Bloom wrote: On Fri, Nov 4, 2022 at 2:59 AM Sebastian Huber wrote: On 31/10/2022 20:01, Gedare Bloom wrote: I would like to float the idea of managing 3rd party source tracking through the build system spec files. I believe this would be the most efficient way to maintain this information, and we can leverage the existing build system code for tasks such as automatic format checks, generating lists of third-party code, etc. This will require refactoring some spec files to pull 3rd party code out to a separate .yml file that gets linked. Once that is done, then we could add another attribute for this tracking purpose. I would like to keep it simple as a boolean, maybe just "third-party: true/false" Attached is an example patch showing how this might work for the dtc/libfdt code as a build objects item type 'obj', and for zlib library as a build library item type 'lib' with some proof-of-concept code for generating a listing of third party source files. In the future we could expand this third-party attribute to a dictionary to provide more detailed information about the third-party sources, for example the upstream Git repository, the import commit, path translation mappings, post and pre import actions. This could be used to automatically generate updates from upstream changes. Nice. I don't see an explicit "dictionary" type for attributes, but I do see that dict-like behavior could be achieved using a 'list' of attributes nested below an attribute. I have the time allocated that i could try to learn how to do this with a simple example, for example to add a "upstream" and an "import-commit" field. Then, the third-party indicator will change from third-party: false -> third-party: [] third-party: true-> third-party: - upstream: URL - import-commit: git-sha I would guess. Would this kind of structure "just work" in the current support of spec/build or will it require some integration with rtems-central? Or, am I following the wrong ideas, third-party: null would indicate that this object/library doesn't have an upstream project. If there is an upstream project, then we could describe this through additional attributes, for example: third-party: type: git commit: abc repository: def file-map: - replace regex 1 - replace regex 2 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On Fri, Nov 4, 2022 at 8:58 AM Sebastian Huber
wrote:
>
> On 04/11/2022 15:38, Gedare Bloom wrote:
> > On Fri, Nov 4, 2022 at 2:59 AM Sebastian Huber
> > wrote:
> >> On 31/10/2022 20:01, Gedare Bloom wrote:
> >>> I would like to float the idea of managing 3rd party source tracking
> >>> through the build system spec files. I believe this would be the most
> >>> efficient way to maintain this information, and we can leverage the
> >>> existing build system code for tasks such as automatic format checks,
> >>> generating lists of third-party code, etc.
> >>>
> >>> This will require refactoring some spec files to pull 3rd party code
> >>> out to a separate .yml file that gets linked. Once that is done, then
> >>> we could add another attribute for this tracking purpose. I would like
> >>> to keep it simple as a boolean, maybe just "third-party: true/false"
> >>> Attached is an example patch showing how this might work for the
> >>> dtc/libfdt code as a build objects item type 'obj', and for zlib
> >>> library as a build library item type 'lib' with some proof-of-concept
> >>> code for generating a listing of third party source files.
> >> In the future we could expand this third-party attribute to a dictionary
> >> to provide more detailed information about the third-party sources, for
> >> example the upstream Git repository, the import commit, path translation
> >> mappings, post and pre import actions. This could be used to
> >> automatically generate updates from upstream changes.
> >>
> > Nice. I don't see an explicit "dictionary" type for attributes, but I
> > do see that dict-like behavior could be achieved using a 'list' of
> > attributes nested below an attribute. I have the time allocated that i
> > could try to learn how to do this with a simple example, for example
> > to add a "upstream" and an "import-commit" field. Then, the
> > third-party indicator will change from
> > third-party: false ->
> > third-party: []
> > third-party: true->
> > third-party:
> > - upstream: URL
> > - import-commit: git-sha
> > I would guess. Would this kind of structure "just work" in the current
> > support of spec/build or will it require some integration with
> > rtems-central? Or, am I following the wrong ideas,
>
> third-party: null
>
> would indicate that this object/library doesn't have an upstream project.
>
> If there is an upstream project, then we could describe this through
> additional attributes, for example:
>
> third-party:
>type: git
>commit: abc
>repository: def
>file-map:
>- replace regex 1
>- replace regex 2
>
OK, that makes sense. I think I can make a first pass just to put in
the framework for extending this later. Taking DTC as an example,
maybe something like the following makes sense?
third-party:
- type: git
- repository: git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- commits:
- upstream: c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21
- import: 175263ec91f00f6668ae7f28f385850a1c77bf6b
- update: cherry-pick
Where we will have to define some update methods such as applying
patches from the upstream (cherry-pick).
As POC I can process this with wscript and obtain
[{'type': 'git'}, {'repository':
'git://git.kernel.org/pub/scm/utils/dtc/dtc.git'}, {'commits':
[{'upstream': 'c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21'}, {'import':
'175263ec91f00f6668ae7f28f385850a1c77bf6b'}]}, {'update':
'cherry-pick'}, {'source': ['cpukit/dtc/libfdt/fdt.c',
'cpukit/dtc/libfdt/fdt_addresses.c',
'cpukit/dtc/libfdt/fdt_empty_tree.c', 'cpukit/dtc/libfdt/fdt_ro.c',
'cpukit/dtc/libfdt/fdt_rw.c', 'cpukit/dtc/libfdt/fdt_strerror.c',
'cpukit/dtc/libfdt/fdt_sw.c', 'cpukit/dtc/libfdt/fdt_wip.c']}]
If this looks reasonable, I can try to add these fields as part of my
sweep through the cpukit tagging third-party sources.
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: List third party files in cpukit and testsuites
On Mon, Apr 11, 2022 at 8:58 AM Joel Sherrill wrote: > > > > On Mon, Apr 11, 2022 at 9:46 AM Gedare Bloom wrote: >> >> On Fri, Apr 8, 2022 at 12:35 PM Ryan Long wrote: >> > >> > This is the set of files in the source code that are all third party. >> > This means they should not be re-licensed or re-formatted. >> > >> > If anything on this list is wrong, or if I missed some, please comment. >> > >> > Thanks, >> > >> > Ryan >> > >> > David Gibson, IBM Corporation >> > cpukit/dtc/libfdt/fdt.c >> > cpukit/dtc/libfdt/fdt_empty_tree.c >> > cpukit/dtc/libfdt/fdt_ro.c >> > cpukit/dtc/libfdt/fdt_rw.c >> > cpukit/dtc/libfdt/fdt_strerror.c >> > cpukit/dtc/libfdt/fdt_sw.c >> > cpukit/dtc/libfdt/fdt_wip.c >> > cpukit/dtc/libfdt/libfdt_internal.h >> > cpukit/include/fdt.h >> > cpukit/include/libfdt.h >> > cpukit/include/libfdt_env.h >> > >> ok, the dtc/libfdt is 3rd party. It should be specified as cpukit/dtc >> >> > The Regents of the University of California >> > cpukit/include/arpa/ftp.h >> > cpukit/include/machine/_kernel_in.h >> > cpukit/include/machine/_kernel_mman.h >> > .cpukit/libmisc/shell/dd-args.c >> > cpukit/libmisc/shell/dd-conv.c >> > cpukit/libmisc/shell/dd-conv_tab.c >> > cpukit/libmisc/shell/dd-misc.c >> > cpukit/libmisc/shell/dd-position.c >> > cpukit/libmisc/shell/dd.h >> > cpukit/libmisc/shell/err.c >> > cpukit/libmisc/shell/err.h >> > cpukit/libmisc/shell/errx.c >> > cpukit/libmisc/shell/extern-cp.h >> > cpukit/libmisc/shell/extern-dd.h >> > cpukit/libmisc/shell/extern-ls.h >> > cpukit/libmisc/shell/filemode.c >> > cpukit/libmisc/shell/fts.c >> > cpukit/libmisc/shell/fts.h >> > cpukit/libmisc/shell/hexdump-conv.c >> > cpukit/libmisc/shell/hexdump-display.c >> > cpukit/libmisc/shell/hexdump-odsyntax.c >> > cpukit/libmisc/shell/hexdump-parse.c >> > cpukit/libmisc/shell/hexdump.h >> > cpukit/libmisc/shell/hexsyntax.c >> > cpukit/libmisc/shell/main_cp.c >> > cpukit/libmisc/shell/main_dd.c >> > cpukit/libmisc/shell/main_echo.c >> > cpukit/libmisc/shell/main_hexdump.c >> > cpukit/libmisc/shell/main_mv.c >> > cpukit/libmisc/shell/main_ln.c >> > cpukit/libmisc/shell/main_ls.c >> > cpukit/libmisc/shell/main_rm.c >> > cpukit/libmisc/shell/pathnames-mv.h >> > cpukit/libmisc/shell/print-ls.c >> > cpukit/libmisc/shell/pwcache.c >> > cpukit/libmisc/shell/sysexits.h >> > cpukit/libmisc/shell/utils-cp.c >> > cpukit/libmisc/shell/utils-ls.c >> > cpukit/libmisc/shell/verr.c >> > cpukit/libmisc/shell/verrx.c >> > cpukit/libmisc/shell/vis.c >> > cpukit/libmisc/shell/vis.h >> > cpukit/libmisc/shell/vwarn.c >> > cpukit/libmisc/shell/vwarnx.c >> > cpukit/libmisc/shell/warn.c >> > cpukit/libmisc/shell/warnx.c >> > cpukit/score/src/iovprintf.c >> > cpukit/libcsupport/src/cfmakeraw.c >> > cpukit/libcsupport/src/cfmakesane.c >> > /include/machine/_kernel_uio.h >> > >> I've had this question in the past about whether or not 'shell' is 3rd >> party. I never had a great answer. The question about not touching 3rd >> party sources is more about whether or not there is someone upstream >> that maintains them. If there's not any update path, then we >> effectively own the code now (clone and own). > > > A lot (68/104) files in shell have RTEMS GPL so most of the code is > really ours. There often is enough hacking to argue clone and own on > some but it is still possible to compare and update. I think Ryan did a > fair bit of this and reporting upstream when addressing Coverity issues. > >> >> That said, everything that is copyrighted by The Regents of the >> University of California can be licensed to 3-BSD. > > > I politely ask you to make this change. You understand the why > and how. >> >> >> Meanwhile, this list has me thinking that you should also use grep >> "\$FreeBSD" to find source files imported from there. Ditto for >> NetBSD. I think it makes more sense to track 3rd party software based >> on where it comes from rather than based on the contributor/copyright >> holder. > > > That was a manual flag for third party but I don't think it ever got to > a grep. >> >> >> > Mark Murray >> > cpukit/include/crypt.h >> For example, this would be better identified as being part of the >> NetBSD libcrypt > > > Where it came from is just for discussion now. Ultimately we only > care that it is third party. Circling back to this, there are several source files especially contributed by EB/Sebastian that are oriented toward *BSD code bases. I believe these files should be treated as "third party" within rtems.git as well, since we would not want to reformat them, and without sleuthing I don't know if they exist in upstream or not. >> >> >> > >> > NetBSD >> > cpukit/include/dlfcn.h >> > cpukit/include/link.h >> > cpukit/include/link_elf.h >> > cpukit/libmisc/shell/cmp-ls.c >> > cpukit/libdl/rtl-mdreloc-arm.c >> > cpukit/libdl/rtl-mdreloc-i386.c >> > cpukit/libdl/rtl-mdreloc-m68k.c >> > cpukit/libdl/rtl-mdreloc-riscv.c >> > cpukit/libdl/rtl-mdreloc-sparc.c >> > cpukit/libmisc/shell/main_mknod.c >> > cpukit/libmisc/shell/mknod-pac
Re: Fwd: Identify 3rd party source in spec?
On Fri, Nov 4, 2022 at 9:55 AM Gedare Bloom wrote:
>
> On Fri, Nov 4, 2022 at 8:58 AM Sebastian Huber
> wrote:
> >
> > On 04/11/2022 15:38, Gedare Bloom wrote:
> > > On Fri, Nov 4, 2022 at 2:59 AM Sebastian Huber
> > > wrote:
> > >> On 31/10/2022 20:01, Gedare Bloom wrote:
> > >>> I would like to float the idea of managing 3rd party source tracking
> > >>> through the build system spec files. I believe this would be the most
> > >>> efficient way to maintain this information, and we can leverage the
> > >>> existing build system code for tasks such as automatic format checks,
> > >>> generating lists of third-party code, etc.
> > >>>
> > >>> This will require refactoring some spec files to pull 3rd party code
> > >>> out to a separate .yml file that gets linked. Once that is done, then
> > >>> we could add another attribute for this tracking purpose. I would like
> > >>> to keep it simple as a boolean, maybe just "third-party: true/false"
> > >>> Attached is an example patch showing how this might work for the
> > >>> dtc/libfdt code as a build objects item type 'obj', and for zlib
> > >>> library as a build library item type 'lib' with some proof-of-concept
> > >>> code for generating a listing of third party source files.
> > >> In the future we could expand this third-party attribute to a dictionary
> > >> to provide more detailed information about the third-party sources, for
> > >> example the upstream Git repository, the import commit, path translation
> > >> mappings, post and pre import actions. This could be used to
> > >> automatically generate updates from upstream changes.
> > >>
> > > Nice. I don't see an explicit "dictionary" type for attributes, but I
> > > do see that dict-like behavior could be achieved using a 'list' of
> > > attributes nested below an attribute. I have the time allocated that i
> > > could try to learn how to do this with a simple example, for example
> > > to add a "upstream" and an "import-commit" field. Then, the
> > > third-party indicator will change from
> > > third-party: false ->
> > > third-party: []
> > > third-party: true->
> > > third-party:
> > > - upstream: URL
> > > - import-commit: git-sha
> > > I would guess. Would this kind of structure "just work" in the current
> > > support of spec/build or will it require some integration with
> > > rtems-central? Or, am I following the wrong ideas,
> >
> > third-party: null
> >
> > would indicate that this object/library doesn't have an upstream project.
> >
> > If there is an upstream project, then we could describe this through
> > additional attributes, for example:
> >
> > third-party:
> >type: git
> >commit: abc
> >repository: def
> >file-map:
> >- replace regex 1
> >- replace regex 2
> >
>
> OK, that makes sense. I think I can make a first pass just to put in
> the framework for extending this later. Taking DTC as an example,
> maybe something like the following makes sense?
>
> third-party:
> - type: git
> - repository: git://git.kernel.org/pub/scm/utils/dtc/dtc.git
> - commits:
> - upstream: c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21
> - import: 175263ec91f00f6668ae7f28f385850a1c77bf6b
> - update: cherry-pick
>
>
> Where we will have to define some update methods such as applying
> patches from the upstream (cherry-pick).
>
> As POC I can process this with wscript and obtain
> [{'type': 'git'}, {'repository':
> 'git://git.kernel.org/pub/scm/utils/dtc/dtc.git'}, {'commits':
> [{'upstream': 'c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21'}, {'import':
> '175263ec91f00f6668ae7f28f385850a1c77bf6b'}]}, {'update':
> 'cherry-pick'}, {'source': ['cpukit/dtc/libfdt/fdt.c',
> 'cpukit/dtc/libfdt/fdt_addresses.c',
> 'cpukit/dtc/libfdt/fdt_empty_tree.c', 'cpukit/dtc/libfdt/fdt_ro.c',
> 'cpukit/dtc/libfdt/fdt_rw.c', 'cpukit/dtc/libfdt/fdt_strerror.c',
> 'cpukit/dtc/libfdt/fdt_sw.c', 'cpukit/dtc/libfdt/fdt_wip.c']}]
>
> If this looks reasonable, I can try to add these fields as part of my
> sweep through the cpukit tagging third-party sources.
>
Given the complexity of this tagging, I'm going to start with just the
true/false approach to categorize third-party sources. We can do
something like the above in the future.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
xz_crc64.c not compiled
Hi all, I don't see an entry in spec/build anywhere for xz_crc64.c >From what I can tell it is not compiled/tested. I guess the This leads me to believe it is not compiled. And therefore is not being called or tested anywhere. Should it be compiled, or should it be removed? Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xz_crc64.c not compiled
On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom wrote: > Hi all, > > I don't see an entry in spec/build anywhere for xz_crc64.c > > From what I can tell it is not compiled/tested. I guess the > This leads me to believe it is not compiled. And therefore is not > being called or tested anywhere. > > Should it be compiled, or should it be removed? > What about in 5 and the autotools build system? --joel > Gedare > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xz_crc64.c not compiled
On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill wrote: > > > > On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom wrote: >> >> Hi all, >> >> I don't see an entry in spec/build anywhere for xz_crc64.c >> >> From what I can tell it is not compiled/tested. I guess the >> This leads me to believe it is not compiled. And therefore is not >> being called or tested anywhere. >> >> Should it be compiled, or should it be removed? > > > What about in 5 and the autotools build system? > It appears to be omitted from 5's cpukit/Makefile.am I don't see the code in 4.11. It was added by Chris to support untar of tgz files. > --joel > >> >> Gedare >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On Fri, Nov 4, 2022 at 11:00 AM Gedare Bloom wrote:
>
> On Fri, Nov 4, 2022 at 9:55 AM Gedare Bloom wrote:
> >
> > On Fri, Nov 4, 2022 at 8:58 AM Sebastian Huber
> > wrote:
> > >
> > > On 04/11/2022 15:38, Gedare Bloom wrote:
> > > > On Fri, Nov 4, 2022 at 2:59 AM Sebastian Huber
> > > > wrote:
> > > >> On 31/10/2022 20:01, Gedare Bloom wrote:
> > > >>> I would like to float the idea of managing 3rd party source tracking
> > > >>> through the build system spec files. I believe this would be the most
> > > >>> efficient way to maintain this information, and we can leverage the
> > > >>> existing build system code for tasks such as automatic format checks,
> > > >>> generating lists of third-party code, etc.
> > > >>>
> > > >>> This will require refactoring some spec files to pull 3rd party code
> > > >>> out to a separate .yml file that gets linked. Once that is done, then
> > > >>> we could add another attribute for this tracking purpose. I would like
> > > >>> to keep it simple as a boolean, maybe just "third-party: true/false"
> > > >>> Attached is an example patch showing how this might work for the
> > > >>> dtc/libfdt code as a build objects item type 'obj', and for zlib
> > > >>> library as a build library item type 'lib' with some proof-of-concept
> > > >>> code for generating a listing of third party source files.
> > > >> In the future we could expand this third-party attribute to a
> > > >> dictionary
> > > >> to provide more detailed information about the third-party sources, for
> > > >> example the upstream Git repository, the import commit, path
> > > >> translation
> > > >> mappings, post and pre import actions. This could be used to
> > > >> automatically generate updates from upstream changes.
> > > >>
> > > > Nice. I don't see an explicit "dictionary" type for attributes, but I
> > > > do see that dict-like behavior could be achieved using a 'list' of
> > > > attributes nested below an attribute. I have the time allocated that i
> > > > could try to learn how to do this with a simple example, for example
> > > > to add a "upstream" and an "import-commit" field. Then, the
> > > > third-party indicator will change from
> > > > third-party: false ->
> > > > third-party: []
> > > > third-party: true->
> > > > third-party:
> > > > - upstream: URL
> > > > - import-commit: git-sha
> > > > I would guess. Would this kind of structure "just work" in the current
> > > > support of spec/build or will it require some integration with
> > > > rtems-central? Or, am I following the wrong ideas,
> > >
> > > third-party: null
> > >
> > > would indicate that this object/library doesn't have an upstream project.
> > >
> > > If there is an upstream project, then we could describe this through
> > > additional attributes, for example:
> > >
> > > third-party:
> > >type: git
> > >commit: abc
> > >repository: def
> > >file-map:
> > >- replace regex 1
> > >- replace regex 2
> > >
> >
> > OK, that makes sense. I think I can make a first pass just to put in
> > the framework for extending this later. Taking DTC as an example,
> > maybe something like the following makes sense?
> >
> > third-party:
> > - type: git
> > - repository: git://git.kernel.org/pub/scm/utils/dtc/dtc.git
> > - commits:
> > - upstream: c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21
> > - import: 175263ec91f00f6668ae7f28f385850a1c77bf6b
> > - update: cherry-pick
> >
> >
> > Where we will have to define some update methods such as applying
> > patches from the upstream (cherry-pick).
> >
> > As POC I can process this with wscript and obtain
> > [{'type': 'git'}, {'repository':
> > 'git://git.kernel.org/pub/scm/utils/dtc/dtc.git'}, {'commits':
> > [{'upstream': 'c0c2e115f82ed3bc5f9d3f9e5380f0f7e81a1c21'}, {'import':
> > '175263ec91f00f6668ae7f28f385850a1c77bf6b'}]}, {'update':
> > 'cherry-pick'}, {'source': ['cpukit/dtc/libfdt/fdt.c',
> > 'cpukit/dtc/libfdt/fdt_addresses.c',
> > 'cpukit/dtc/libfdt/fdt_empty_tree.c', 'cpukit/dtc/libfdt/fdt_ro.c',
> > 'cpukit/dtc/libfdt/fdt_rw.c', 'cpukit/dtc/libfdt/fdt_strerror.c',
> > 'cpukit/dtc/libfdt/fdt_sw.c', 'cpukit/dtc/libfdt/fdt_wip.c']}]
> >
> > If this looks reasonable, I can try to add these fields as part of my
> > sweep through the cpukit tagging third-party sources.
> >
>
> Given the complexity of this tagging, I'm going to start with just the
> true/false approach to categorize third-party sources. We can do
> something like the above in the future.
I have come across one problem with my approach. Headers that aren't
installed (e.g., #include "fastlz.h") do not appear within the build
system. These might need to be identified and handled as some kind of
special case. There are 79 such files in cpukit.
rtems/cpukit$ find . -name "*.h" | grep -v include | wc
79 792072
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] wscript: fix formatting with yapf
---
wscript | 305 ++--
1 file changed, 139 insertions(+), 166 deletions(-)
diff --git a/wscript b/wscript
index 4071cc9ef8..6bf3b25012 100755
--- a/wscript
+++ b/wscript
@@ -73,13 +73,10 @@ class VersionControlKeyHeader:
#define _RTEMS_VERSION_VC_KEY_H_
"""
try:
-rev = bld.cmd_and_log(
-"git rev-parse HEAD", quiet=Context.STDOUT
-).strip()
+rev = bld.cmd_and_log("git rev-parse HEAD",
+ quiet=Context.STDOUT).strip()
content += """#define RTEMS_VERSION_VC_KEY "{}"
-""".format(
-rev
-)
+""".format(rev)
except WafError:
content += """/* No version control key found; release? */
"""
@@ -96,6 +93,7 @@ class VersionControlKeyHeader:
class EnvWrapper(object):
+
def __init__(self, env):
self._env = env
@@ -155,9 +153,8 @@ def _is_enabled(enabled, enabled_by):
def _asm_explicit_target(self, node):
-task = self.create_task(
-"asm", node, self.bld.bldnode.make_node(self.target)
-)
+task = self.create_task("asm", node,
+self.bld.bldnode.make_node(self.target))
try:
self.compiled_tasks.append(task)
except AttributeError:
@@ -180,6 +177,7 @@ def process_start_files(self):
class Item(object):
+
def __init__(self, uid, data):
self.uid = uid
self.data = data
@@ -192,8 +190,7 @@ class Item(object):
uid = link["uid"]
if not os.path.isabs(uid):
uid = os.path.normpath(
-os.path.join(os.path.dirname(self.uid), uid)
-)
+os.path.join(os.path.dirname(self.uid), uid))
self._links.append(items[uid])
self.links = self._yield_links
for link in self._links:
@@ -248,9 +245,7 @@ class Item(object):
except Exception as e:
ctx.fatal(
"In item '{}' substitution in '{}' failed: {}".format(
-self.uid, value, e
-)
-)
+self.uid, value, e))
if isinstance(value, list):
more = []
for item in value:
@@ -284,7 +279,8 @@ class Item(object):
asflags=self.substitute(bld, self.data["asflags"]),
cppflags=self.substitute(bld, self.data["cppflags"]),
features="asm_explicit_target asm c",
-includes=bic.includes + self.substitute(bld,
self.data["includes"]),
+includes=bic.includes +
+self.substitute(bld, self.data["includes"]),
source=[source],
target=target,
)
@@ -297,8 +293,10 @@ class Item(object):
cflags=self.substitute(bld, self.data["cflags"]),
cppflags=cppflags + self.substitute(bld, self.data["cppflags"]),
features="c",
-includes=bic.includes + self.substitute(bld,
self.data["includes"]),
-rule="${CC} ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
+includes=bic.includes +
+self.substitute(bld, self.data["includes"]),
+rule=
+"${CC} ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
source=[source] + deps,
target=target,
)
@@ -311,8 +309,10 @@ class Item(object):
cppflags=cppflags + self.substitute(bld, self.data["cppflags"]),
cxxflags=self.substitute(bld, self.data["cxxflags"]),
features="cxx",
-includes=bic.includes + self.substitute(bld,
self.data["includes"]),
-rule="${CXX} ${CXXFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
+includes=bic.includes +
+self.substitute(bld, self.data["includes"]),
+rule=
+"${CXX} ${CXXFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
source=[source] + deps,
target=target,
)
@@ -322,14 +322,14 @@ class Item(object):
from waflib.Task import Task
class link(Task):
+
def __init__(self, item, bic, cmd, env):
super(link, self).__init__(self, env=env)
self.cmd = cmd
self.ldflags = bic.ldflags + item.data["ldflags"]
self.stlib = item.data["stlib"]
-self.use = (
-item.data["use-before"] + bic.use + item.data["use-after"]
-)
+self.use = (item.data["use-before"] + bic.use +
+item.data["use-after"])
def run(self):
cmd = [self.cmd]
@@ -368,6 +368,
Re: [PATCH] wscript: fix formatting with yapf
This is just the result of running
yapf -i wscript
on the master branch.
On Fri, Nov 4, 2022 at 2:23 PM Gedare Bloom wrote:
>
> ---
> wscript | 305 ++--
> 1 file changed, 139 insertions(+), 166 deletions(-)
>
> diff --git a/wscript b/wscript
> index 4071cc9ef8..6bf3b25012 100755
> --- a/wscript
> +++ b/wscript
> @@ -73,13 +73,10 @@ class VersionControlKeyHeader:
> #define _RTEMS_VERSION_VC_KEY_H_
> """
> try:
> -rev = bld.cmd_and_log(
> -"git rev-parse HEAD", quiet=Context.STDOUT
> -).strip()
> +rev = bld.cmd_and_log("git rev-parse HEAD",
> + quiet=Context.STDOUT).strip()
> content += """#define RTEMS_VERSION_VC_KEY "{}"
> -""".format(
> -rev
> -)
> +""".format(rev)
> except WafError:
> content += """/* No version control key found; release? */
> """
> @@ -96,6 +93,7 @@ class VersionControlKeyHeader:
>
>
> class EnvWrapper(object):
> +
> def __init__(self, env):
> self._env = env
>
> @@ -155,9 +153,8 @@ def _is_enabled(enabled, enabled_by):
>
>
> def _asm_explicit_target(self, node):
> -task = self.create_task(
> -"asm", node, self.bld.bldnode.make_node(self.target)
> -)
> +task = self.create_task("asm", node,
> +self.bld.bldnode.make_node(self.target))
> try:
> self.compiled_tasks.append(task)
> except AttributeError:
> @@ -180,6 +177,7 @@ def process_start_files(self):
>
>
> class Item(object):
> +
> def __init__(self, uid, data):
> self.uid = uid
> self.data = data
> @@ -192,8 +190,7 @@ class Item(object):
> uid = link["uid"]
> if not os.path.isabs(uid):
> uid = os.path.normpath(
> -os.path.join(os.path.dirname(self.uid), uid)
> -)
> +os.path.join(os.path.dirname(self.uid), uid))
> self._links.append(items[uid])
> self.links = self._yield_links
> for link in self._links:
> @@ -248,9 +245,7 @@ class Item(object):
> except Exception as e:
> ctx.fatal(
> "In item '{}' substitution in '{}' failed: {}".format(
> -self.uid, value, e
> -)
> -)
> +self.uid, value, e))
> if isinstance(value, list):
> more = []
> for item in value:
> @@ -284,7 +279,8 @@ class Item(object):
> asflags=self.substitute(bld, self.data["asflags"]),
> cppflags=self.substitute(bld, self.data["cppflags"]),
> features="asm_explicit_target asm c",
> -includes=bic.includes + self.substitute(bld,
> self.data["includes"]),
> +includes=bic.includes +
> +self.substitute(bld, self.data["includes"]),
> source=[source],
> target=target,
> )
> @@ -297,8 +293,10 @@ class Item(object):
> cflags=self.substitute(bld, self.data["cflags"]),
> cppflags=cppflags + self.substitute(bld, self.data["cppflags"]),
> features="c",
> -includes=bic.includes + self.substitute(bld,
> self.data["includes"]),
> -rule="${CC} ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
> ${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
> +includes=bic.includes +
> +self.substitute(bld, self.data["includes"]),
> +rule=
> +"${CC} ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
> ${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
> source=[source] + deps,
> target=target,
> )
> @@ -311,8 +309,10 @@ class Item(object):
> cppflags=cppflags + self.substitute(bld, self.data["cppflags"]),
> cxxflags=self.substitute(bld, self.data["cxxflags"]),
> features="cxx",
> -includes=bic.includes + self.substitute(bld,
> self.data["includes"]),
> -rule="${CXX} ${CXXFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
> ${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
> +includes=bic.includes +
> +self.substitute(bld, self.data["includes"]),
> +rule=
> +"${CXX} ${CXXFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES}
> ${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
> source=[source] + deps,
> target=target,
> )
> @@ -322,14 +322,14 @@ class Item(object):
> from waflib.Task import Task
>
> class link(Task):
> +
> def __init__(self, item, bic, cmd, env):
> super(link, self).__init__(self, env=env)
> self.cmd = cmd
> self.ldflags = bic.ldflags + item.data["ldflags"]
>
Re: List third party files in cpukit and testsuites
Out of the original list, the following are the files that have NOT been marked as third-party in my proof-of-concept available at https://git.rtems.org/gedare/rtems.git/log/?h=test-split-3rd-party Most of the .h files are not included because uninstalled headers aren't in the spec files. This includes the following headers: -- cpukit/dtc/libfdt/libfdt_internal.h cpukit/libmisc/shell/dd.h cpukit/libmisc/shell/err.h cpukit/libmisc/shell/extern-cp.h cpukit/libmisc/shell/extern-dd.h cpukit/libmisc/shell/extern-ls.h cpukit/libmisc/shell/fts.h cpukit/libmisc/shell/hexdump.h cpukit/libmisc/shell/pathnames-mv.h cpukit/libmisc/shell/sysexits.h cpukit/libmisc/shell/vis.h cpukit/libmisc/shell/mknod-pack_dev.h cpukit/libfs/src/jffs2/src/acl.h cpukit/libfs/src/jffs2/src/compr.h cpukit/libfs/src/jffs2/src/debug.h cpukit/libfs/src/jffs2/src/jffs2_fs_i.h cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h cpukit/libfs/src/jffs2/src/nodelist.h cpukit/libfs/src/jffs2/src/rtems-jffs2-config.h cpukit/libfs/src/jffs2/src/summary.h cpukit/libfs/src/jffs2/src/xattr.h cpukit/libmisc/uuid/uuidP.h cpukit/libmisc/uuid/uuidd.h cpukit/libmisc/xz/xz_config.h cpukit/libmisc/xz/xz_lzma2.h cpukit/libmisc/xz/xz_private.h cpukit/libmisc/xz/xz_stream.h cpukit/zlib/gzguts.h cpukit/zlib/inffast.h cpukit/zlib/inflate.h cpukit/zlib/inftrees.h cpukit/zlib/deflate.h cpukit/zlib/zutil.h cpukit/zlib/crc32.h cpukit/zlib/inffixed.h cpukit/zlib/trees.h -- The RTL is owned by RTEMS now, including: -- cpukit/libdl/rtl-mdreloc-arm.c cpukit/libdl/rtl-mdreloc-i386.c cpukit/libdl/rtl-mdreloc-m68k.c cpukit/libdl/rtl-mdreloc-riscv.c cpukit/libdl/rtl-mdreloc-sparc.c cpukit/libdl/fastlz.c cpukit/libdl/fastlz.h -- These two are RTEMS-owned, authored by Till and Kevin Kirspel -- cpukit/libfs/src/defaults/default_mmap.c cpukit/score/cpu/nios2/include/rtems/score/nios2-count-zeros.h -- There are several header files related to ISA-specific support that might be worth identifying as third-party. -- cpukit/score/cpu/i386/include/machine/elf_machdep.h cpukit/score/cpu/m68k/include/machine/elf_machdep.h cpukit/score/cpu/mips/include/machine/elf_machdep.h cpukit/score/cpu/nios2/include/machine/elf_machdep.h cpukit/score/cpu/sparc/include/machine/elf_machdep.h cpukit/score/cpu/x86_64/include/machine/elf_machdep.h cpukit/score/cpu/mips/include/rtems/mips/idtcpu.h cpukit/score/cpu/mips/include/rtems/mips/iregdef.h -- Some random files: -- cpukit/include/pci/pcireg.h cpukit/libmisc/mouse/mouse_parser.c cpukit/libmisc/xz/xz_crc64.c -- And I didn't touch the testsuites: -- testsuites/samples/paranoia/paranoia.c testsuites/benchmarks/dhrystone/dhry.h testsuites/benchmarks/dhrystone/dhry_1.c testsuites/benchmarks/dhrystone/dhry_2.c testsuites/benchmarks/linpack/linpack-pc.c testsuites/benchmarks/whetstone/whetstone.c -- ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: List third party files in cpukit and testsuites
On Fri, Nov 4, 2022 at 5:01 PM Gedare Bloom wrote: > Out of the original list, the following are the files that have NOT > been marked as third-party in my proof-of-concept available at > https://git.rtems.org/gedare/rtems.git/log/?h=test-split-3rd-party > > Most of the .h files are not included because uninstalled headers > aren't in the spec files. This includes the following headers: > I'll comment on the ones I am fairly confident on. > -- > cpukit/dtc/libfdt/libfdt_internal.h > cpukit/libmisc/shell/dd.h > cpukit/libmisc/shell/err.h > cpukit/libmisc/shell/extern-cp.h > cpukit/libmisc/shell/extern-dd.h > cpukit/libmisc/shell/extern-ls.h > cpukit/libmisc/shell/fts.h > cpukit/libmisc/shell/hexdump.h > cpukit/libmisc/shell/pathnames-mv.h > cpukit/libmisc/shell/sysexits.h > cpukit/libmisc/shell/vis.h > cpukit/libmisc/shell/mknod-pack_dev.h > cpukit/libfs/src/jffs2/src/acl.h > cpukit/libfs/src/jffs2/src/compr.h > cpukit/libfs/src/jffs2/src/debug.h > cpukit/libfs/src/jffs2/src/jffs2_fs_i.h > cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h > cpukit/libfs/src/jffs2/src/nodelist.h > cpukit/libfs/src/jffs2/src/rtems-jffs2-config.h > cpukit/libfs/src/jffs2/src/summary.h > cpukit/libfs/src/jffs2/src/xattr.h > All of the jffs2 except the rtems file > cpukit/libmisc/uuid/uuidP.h > cpukit/libmisc/uuid/uuidd.h > cpukit/libmisc/xz/xz_config.h > cpukit/libmisc/xz/xz_lzma2.h > cpukit/libmisc/xz/xz_private.h > cpukit/libmisc/xz/xz_stream.h > cpukit/zlib/gzguts.h > cpukit/zlib/inffast.h > cpukit/zlib/inflate.h > cpukit/zlib/inftrees.h > cpukit/zlib/deflate.h > cpukit/zlib/zutil.h > cpukit/zlib/crc32.h > cpukit/zlib/inffixed.h > cpukit/zlib/trees.h > All of the uuid, xz, and zlib. > -- > > The RTL is owned by RTEMS now, including: > -- > cpukit/libdl/rtl-mdreloc-arm.c > cpukit/libdl/rtl-mdreloc-i386.c > cpukit/libdl/rtl-mdreloc-m68k.c > cpukit/libdl/rtl-mdreloc-riscv.c > cpukit/libdl/rtl-mdreloc-sparc.c > Yes. > cpukit/libdl/fastlz.c > cpukit/libdl/fastlz.h > How did these get changed enough to be our code. > -- > > These two are RTEMS-owned, authored by Till and Kevin Kirspel > -- > cpukit/libfs/src/defaults/default_mmap.c > cpukit/score/cpu/nios2/include/rtems/score/nios2-count-zeros.h > -- > > There are several header files related to ISA-specific support that > might be worth identifying as third-party. > -- > cpukit/score/cpu/i386/include/machine/elf_machdep.h > cpukit/score/cpu/m68k/include/machine/elf_machdep.h > cpukit/score/cpu/mips/include/machine/elf_machdep.h > cpukit/score/cpu/nios2/include/machine/elf_machdep.h > cpukit/score/cpu/sparc/include/machine/elf_machdep.h > cpukit/score/cpu/x86_64/include/machine/elf_machdep.h > Yes. These mostly came from FreeBSD. Not sure about the nios2 though. > cpukit/score/cpu/mips/include/rtems/mips/idtcpu.h > cpukit/score/cpu/mips/include/rtems/mips/iregdef.h > Yep. Wonder if these should be in the BSP area though. > -- > > Some random files: > -- > cpukit/include/pci/pcireg.h > Grrr... this file could have been managed better. * Copyright (c) 1997, Stefan Esser * All rights reserved. * * New PCI library written from scratch. Defines in this file was taken from * FreeBSD commit f1d6f4778d2044502209708bc167c05f9aa48615. * auto-generated pci_ids.h also reused from RTEMS. * Copyright 2009, Cobham Gaisler AB It is ours but if we had been clever, it may not have been or could have had ifdef rtems. > cpukit/libmisc/mouse/mouse_parser.c > I think mouse_parser.c is third party but I don't remember where it came from > cpukit/libmisc/xz/xz_crc64.c > I don't know where xz came from but I found this: http://web.mit.edu/freebsd/head/sys/contrib/xz-embedded/ crc64 appears to be disabled by default for space reasons but a 64-bit CRC would be more robust. I'm prone to turn the code on. We aren't forcing it onto anyone. > -- > > And I didn't touch the testsuites: > -- > testsuites/samples/paranoia/paranoia.c > testsuites/benchmarks/dhrystone/dhry.h > testsuites/benchmarks/dhrystone/dhry_1.c > testsuites/benchmarks/dhrystone/dhry_2.c > testsuites/benchmarks/linpack/linpack-pc.c > testsuites/benchmarks/whetstone/whetstone.c > Ideally these are all third party but I suspect paranoia may have been modified too much before we got good rules. Eventually we may want to grab a new copy, put an rtems_config.c with a "main()" and see if we can avoid editing it. > -- > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
On 5/11/2022 4:00 am, Gedare Bloom wrote: Given the complexity of this tagging, I'm going to start with just the true/false approach to categorize third-party sources. We can do something like the above in the future. Sounds good. We can consider a dict when someone maps out how to manage 3rd party source. I think it would premature to do it without further consideration. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xz_crc64.c not compiled
On 5/11/2022 6:46 am, Gedare Bloom wrote: On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill wrote: On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom wrote: Hi all, I don't see an entry in spec/build anywhere for xz_crc64.c From what I can tell it is not compiled/tested. I guess the This leads me to believe it is not compiled. And therefore is not being called or tested anywhere. Should it be compiled, or should it be removed? What about in 5 and the autotools build system? It appears to be omitted from 5's cpukit/Makefile.am I don't see the code in 4.11. It was added by Chris to support untar of tgz files. Sorry I do not recall why it was not added into the build. There are no calls in the code to it. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
