I have created and opened /tmp/output file from my kernel character driver code using filp_open(). And I am able to do close it using filp_close(). But after unloading the module it is not removing the file /tmp/output.
What should I do to remove it?
Related
I'm writing a game in Lua using Löve2D using google drive syncing for backup, meaning I am directly editing the file in my drive. This means the file path is "G/My Drive/Truck" (Truck is the name of the game folder). When I open the folder in VS Code it works fine and I can access and edit everything, but when I actually try to run the main.lua with the alt+L command I get this error:
boot.lua:577: Cannot load game at path 'g:/My'.
Make sure a folder exists at the specified path.
I'm not sure if it's Löve itself or if it's VS Code which can't cope with the white space.
I have previously accessed, edited and run the file with no issue on a different computer, but am now trying to do so on my laptop, and am encountering this issue.
OS is Windows 11.
I've tried opening "G/My_Drive/Truck" which doesn't work. Since it's google drive I can't just rename it to remove the whitespace.
According to the error message you've provided, Lua does not receive a full path to your folder, just a small piece: 'g:/My'
This usually happens when you pass a string that contains a whitespace by command line like this:
love.exe game.love G:/My Drive/Truck
How to fix:
love.exe game.love "G:/My Drive/Truck"
If that does not help, then post more details: how do you launch it, where path to your gdrive folder is stored.
my issue seems to be a common one, but none of the found answers could solve it.
I am following the software foundations course on Coq, and so I come to the command:
> From LF Require Export Basics.
Whatever I try, I get always the following answer:
"Cannot find a physical path bound to logical path matching suffix <>
and prefix LF."
I compiled Basics.v from coqIde, and the Basics.vo file is created correctly.
I also compiled it from the coqc command line, as suggested somewhere
My _CoqProject file exists, in the same folder as Basics.v, and states: -Q . LF
the _CoqProject parameter is set to "appended to arguments".
when I load Basics.v I see on the bottom of CoqIde "Reading Options from ..._CoqProject"
I put the lf folder into a folder which is in the LoadPath of coq.
What else could I check?
My system is Windows 10. I run CoqIde 8.9.1
Thank you!
I usually work under a Linux machine, but here something I did using a virtual machine.
I downloaded the windows installer from https://github.com/coq/coq/releases/tag/V8.9.1
I downladed the lf.tgz file from https://softwarefoundations.cis.upenn.edu/lf-current/index.html
I ran the windows installer for Coq. It placed the coq system in C:\coq
I used cygwin tools to expand the file lf.tgz so that I had a directory C:\Users\user\foundations\lf containing Basics.v, _CoqProject etc.
Then I used the search command to find coqide as an installed app. I then proceeded with the following steps:
start coqide
open the file Basics.v
use the option Compile->Compile buffer
I could then observe that the directory C:\Users\user\foundations\lf contained a file named Basics.vo
Then I opened a new buffer, and wrote From LF Require Export Basics. and did not try to execute this line
I saved this buffer in a file in directory C:\Users\user\foundations\lf. Let's assume this file is named toto.v
I closed the toto.v buffer.
I re-opened the toto.v using the option File->Open
I executed the file contents.
This process is the result of trial-and-error. What I know is that Require Export ... only works if there are ...vo files on you disk, but coqide needs to know where to look for these files. For this it maintains a "load path". When opening a file from a given directory, coqide looks in this directory (and ancestors) to find a _CoqProject file, and the latter may contain directives to modify the load path. It is the case here "-Q . LF" indicates that all .vo files in the current directory should be considered, and that their symbolic name should start with the prefix "LF."
The problem is that when you start from an empty buffer, no _CoqProject file gets read and coqide does not where to look for your data. This is why I did the steps 5-6-7: when reading the file toto.v, I provoked the reading of the _CoqProject file.
Takeaway lesson: Make sure the Basics.vo file exists, and then make sure the buffer you are working on was obtained through a reading operation from the same directory. If needed, save, close, and re-open to make sure this is the case.
I am trying to install q in a directory other than my home directory. Is this possible? It seems q will fail if it is in another directory. I get this error when trying to run it:
'/Users/cammil/q/q.k. OS reports: No such file or directory
0::
`/Users/cammil/q/q.k
Set your QHOME to directory which contains q.k file. That should solve the issue.
Also, if that directory does not contain k4.lic (license) file then set QLIC to directory containing license file.
Read more details about environment variables here: https://code.kx.com/q4m3/14_Introduction_to_Kdb+/#1481-the-environment-variables
KDB+ uses the QHOME environment variable at startup. QHOME specifies where to find the q.k file, and if it is not defined kdb will by default look into the home directory. It will also look for the licence file in the same way. Therefore you must define your QHOME variable as the directory which holds the .q.k and k4.lic files. (Or alternativley you can define the QLIC variable for the license)
I'm currently trying to build poky-tiny for imx6ulevk (using the BSP Yocto Project Environment provided by NXP).
I first followed the Quick Start Guide, tested and everything worked just fine. I then went to the usual local.conf file (/build/conf/local.conf) and changed the DISTRO variable to poky-tiny.
In poky-tiny distro file (/sources/poky/meta-yocto/conf/distro/poky-tiny.conf), I changed the virtual/kernel in the variable PREFERRED_PROVIDER_virtual/kernel to linux-imx and the PREFERRED_VERSION_linux-imx to 3.14.38 which is compatible (I think).
I finally added to the local.conf the variable IMAGE_FSTYPES with the value tar.bz2 ext3 sdcard.
At this point I tried to build using:
bitbake core-image-minimal
this runs without any problems. But it doesn't generate sdcard image or any u-boot images as is expected. The only files generated are:
core-image-minimal-imx6ulevk-20160517152114.rootfs.cpio.gz
core-image-minimal-imx6ulevk-20160517152114.rootfs.manifest
core-image-minimal-imx6ulevk.cpio.gz
core-image-minimal-imx6ulevk.manifest
modules-imx6ulevk.tgz
zImage
zImage--3.14.38-r0-imx6ul-14x14-evk-20160517152114.dtb
zImage--3.14.38-r0-imx6ul-14x14-evk-csi-20160517152114.dtb
zImage--3.14.38-r0-imx6ulevk-20160517152114.bin
zImage-imx6ul-14x14-evk-csi.dtb
zImage-imx6ul-14x14-evk.dtb
zImage-imx6ulevk.bin
And I got stuck without knowing how to deploy to the imx6ulevk. What did I do wrong? Why is yocto not generating the usual sdcard image?
If anyone gets this what worked for me was the following:
Turns out poky-tiny for imx6ulevk does not create sdcard images normally. So what you need to do, once you build it with a proper kernel, is to manually create a bootable sdcard. This can be done by using gparted cleaning everything in it and adding 2 partitions, then proceed as follow:
1 - First you use gunzip in the file core-image-minimal-imx6ulevk-...-rootfs.cpio.gz.
2 - Call cpio on the generated file: cpio -i -vd < core-image-minimal...-.cpio
3 - You just generated the root file system copy everything into one of the partitions.
4 - the zImage...* files are the generated kernel for the poky-tiny distro. Copy all but the symbolic links to the second partition. You might need to rename the files (I had to) if you're not sure what to rename to, first build regular poky using sdcard image and check out the proper names.
That's pretty much it, you should be able to boot imx6ulevk using the provided files.
I am running MATLAB 2013b on a CentOS machine. Right now I have startup.m set to cd me into another directory, lets call it shared, where I keep all of my code. I also have pathdef.m set to add shared and some of its subdirectories to the MATLAB path.
The problem is that once MATLAB is open and I check the path settings, ~/matlab has also been added to the top of the path list, ahead of shared. The home folder is where I keep some old versions of code, so it causes the wrong version to be run sometimes. I've double checked my pathdef and startup files, and the ~/matlab directory is definitely not listed. What could be causing MATLAB to automatically add this directory to the path, and how can I fix it?