On 4/3/2024 6:35 pm, Sebastian Huber wrote: > On 04.03.24 08:22, Chris Johns wrote: >>> diff --git a/spec/build/bsps/powerpc/qoriq/mkimage.yml >>> b/spec/build/bsps/powerpc/qoriq/mkimage.yml >>> new file mode 100644 >>> index 0000000000..712fd237b1 >>> --- /dev/null >>> +++ b/spec/build/bsps/powerpc/qoriq/mkimage.yml >>> @@ -0,0 +1,39 @@ >>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause >>> +build-type: mkimage >>> +content: | >>> + #!${PYTHON} >>> + >>> + import gzip >>> + import os >>> + import shutil >>> + import subprocess >>> + import sys >>> + import tempfile >>> + >>> + with tempfile.TemporaryDirectory() as tmp_dir: >>> + bin_path = os.path.join(tmp_dir, "bin") >>> + gz_path = os.path.join(tmp_dir, "gz") >>> + subprocess.run([ >>> + "${OBJCOPY}", >>> + "-O", "binary", sys.argv[1], bin_path >>> + ], >>> + check=True) >>> + with open(bin_path, "rb") as f_bin: >>> + with gzip.open(gz_path, "wb") as f_gz: >>> + shutil.copyfileobj(f_bin, f_gz) >>> + subprocess.run([ >>> + "${U_BOOT_MKIMAGE}", >>> + "-A", "ppc", "-O", "linux", "-T", "kernel", "-a", "0x4000", "-e", >>> + "0x4000", "-n", "RTEMS", "-d", gz_path, sys.argv[2] >>> + ], >>> + check=True) >> Sorry this patch is a no from me and adding python like this with such >> limited >> error checking is something I am not comfortable with. >> >> I am OK wih a python module that something robust can import and validate >> giving >> the user consistent and meaningful error messages but as I have just said >> whole >> programs in spec files like this, sorry thet is no from me. > > Python exceptions usually give a lot of context, but sure you always can > improve > things.
Lets define and implement what we want from the start. I do not think I am asking for a major piece of work to be written but this task has some ground work that needs to be established with an architecture that scales. It is an important feature we need so I am happy to find a suitable initial starting point. > If someone doesn't like the error handling in a mkimage script he can > improve it through patches. > > The script may have to know details of the BSP configuration, so what would be > your approach to address this? As a said a loadable module of code that confirms to an API to export the "BSP configuration" as an option. That module would be wrapped in a generic command that validates the module and handles the error checking presenting the user with errors messages that are not language based or implementation specific. A key point is defining what is exported. The command line tool can be in rtems-tools and based on the framework there if that helps. The imported module could contain variables, a class or a series of calls. For example: m.py USES_TEMPFILE = True Then you can: import m if hasattr(m, 'USES_TEMPFILE') and m.USES_TEMPFILE: # get a temp file try: m.something() finally: # clean up temp file The tool can be focused on your use case with a stable command line interface yet extendible. > With the script in the build specification item > you can simply use the variable substitution. I don't think these scripts will > be super complex, just a sequence of commands. May be it is simpler if we just say no host code fragments like this in spec files? I fine and relieved if that is the case. It would forced formalisation of the exporting of these parameters, something I think we need long term. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel