Bad system call 318

[marghidanu]

I just built a custom application on the system; the compilation went fine. Once I started the application I was greeted with a Bad system call error; dmesg reports this as being:

134 missing syscall 318

After some digging, I discovered here that the 318 syscall is get_cpu, I then proceeded to check /proc/cpuinfo for which I get "No such file or directory". I see meminfo exists, is there a reason why this wasn't implemented yet?

I am using version 1.0.3 (Build 80)

[tbodt]

What were you trying to run?

There's another issue for /proc/cpuinfo: #391

[gitdev-bash]

Same issue as #391 /proc/cpuinfo not found.

I then proceeded to check /proc/cpuinfo for which I get "No such file or directory".

Duplicate of #391 Can be linked and closed.

[marghidanu]

Actually the report is about the fact that the get_cpu syscall is probably not implemented.

[gitdev-bash]

When /proc/cpuinfo does not exist the syscall get_cpu does not work as a result. So First /proc/cpuinfo has to be implemented then the syscall get_cpu. And #58 already says that it is still to be implemented but first #391 has to be implemented.
So the issue already exists I would say it is a duplicate.

Please tell me if I am wrong :)

[marghidanu]

I'm not familiar with the internals of iSH, so I would assume you're right. But even in that case since #391 needs to be implemented first the implementation of get_cpu seems to be a different task.

[gitdev-bash]

Remember #58 does already say that.
So it should be a duplicate.

[saagarjha]

While we appreciate relevant cross-references, we can handle project management just fine at the moment.

I'm leaning towards keeping this open to mark implementing get_cpu.

[gitdev-bash]

Ok as you say but I just wanted them linked not closed

[saagarjha]

Like I said, we are happy to have things surfaced if it makes sense to do so, but we'd also prefer if you'd leave the decision of how we should handle issues to us.