Open eroom1966 opened 10 months ago
Thanks for the issue @eroom1966.
The unstated assumption here is that on most Linux systems, old files in /tmp
are periodically deleted. On my Ubuntu and Debian machines everything older than one week is automatically removed and on our CentOS machine everything older than a month is deleted. This out-of-the-box behavior so unless you've changed it on your system, these files should not be persistent.
I don't think you can really rely upon systems doing that TBH if the infrastructure is creating temporary files, it should really clean then up after usage - unless there is some crash in which case the cleanup routines may not execute. I also see xcelium creating many temporary files, but these are all reaped at the end of the execution
where in the code is the request made for these temporary files ? it should not be too difficult to work out the expected lifetime of these files
where in the code is the request made for these temporary files ?
The scripts that generates the tmp-files are bin/yaml2make and bin/cfgyaml2make. These scripts are launched by the makefiles, specifically mk/Common.mk, and are not intended to be run by the user. A brief description of their operation is included in mk/TOOLCHAIN.md.
Hi @LeeHoff @MikeOpenHWGroup
I don't really like those tmp/hidden files either. As they are included by makefiles after creation, sometimes it happens that you need to look at them to understand if they are correctly generated. So you have to hack makefiles to report tmp filename to be able to look at them.
I would really prefer them to be generated in $(SIM_RUN_RESULTS) like it is done for ovpsim.ic Nothing hidden any more... Then you can have a look to them if needed and they are destroyed like any other simulation generated stuff when you remove $(SIM_RUN_RESULTS).
Cheers, Pascal.
Hi Pascal I was coming to the same conclusion
Yesterday I spent a lot of time, trying to define these /tmp/tmpxxxx files us .INTERMEDIATE files in the Makefile Usually gmake will remove files flagged as intermediate, but could not get this to work Following this I was coming to the same conclusion you mention, which is that these files should go into the $(SIM_RUN_RESULTS) area
volunteers to implement ..... ? Thx Lee
It appears that running the core-v-verif simulation, especially the full suite of tests is creating hundreds of temporary files in /tmp and not cleaning up on exit. An example of how to reproduce is as follows (based upon cv32e40s)
make clean_all make sanity CV_CORE=cv32e40s
in my environment this resulted in the following files created and left in /tmp, (YMMV)
tmpwcmwdct4 tmpdauke327 have equivalent content tmp4jvohs49 tmp1dvw9oco have equivalent content
$ cat tmpwcmwdct4
$ cat tmp4jvohs49
These should be cleaned up either on exit, or after usage. I noticed in /tmp on my machine I had thousands of these files, and finally narrowed it down to running core-v-verif