Make linux(4) create /dev/shm.

[trasz]

Summary

Make linux(4) create /dev/shm. Linux applications often expect
a tmpfs to be mounted there, and because they like to verify it's
actually a mountpoint, a symlink won't do.

[dchagin]

linux_common is not used in i386

[dchagin]

I would prefer put common code to the compat/linux/linux.c and put linux_dev_shm_destroy/linux_dev_shm_create decl to the linux.h

[trasz]

Move stuff around.

[trasz]

In D20333#438430, @dchagin wrote:

linux_common is not used in i386

What do you mean? Or, ask another way, where should I call it from to make it work for i386?

[dchagin]

In D20333#438435, @trasz wrote:

In D20333#438430, @dchagin wrote:

linux_common is not used in i386

What do you mean? Or, ask another way, where should I call it from to make it work for i386?

in linux_elf_modevent() in i386/linux/linux_sysvec.c

[trasz]

Also call stuff for i386.

[tijl]

Please also bump OSVERSION so the creation of /compat/linux/dev/shm can be made conditional in emulators/linux_base-c[67]

[dchagin]

as far as I understand we can create /dev/fd same way?

[trasz]

This is a bit hacky, even for my standards, so I've come up with this as an alternative: https://reviews.freebsd.org/D20411.

[emaste]

I have no objection

[emaste]

I have no objection

Further, I am not familiar enough with the devfs machinery to effectively review (previously I would not have suspected make_dev as the way to create a devfs directory), but I support the intent / effect of this change.

[kib]

sys/compat/linux/linux.c

538 ↗

(On Diff #57758)

I suggest "shm/.placeholder" or "shm/.dummy". Might also make sense to change mode to 0.

540 ↗

(On Diff #57758)

\n at the EoL

[emaste]

sys/compat/linux/linux.c

538 ↗

(On Diff #57758)

Ah I see now. What about shm/.mountpoint in that case?

[trasz]

Apply comments from kib@ and emaste@.

[kib]

sys/i386/linux/linux_sysvec.c

1009 ↗

(On Diff #63735)

So if both 64 and 32bit linix.ko are loaded, one of them would print an error. If another one is unloaded before the module that printed an error, the node is destroyed. Which raises the next question, did you actually tried it ? I wonder what happens to the system when devfs directory goes away while being used as mount point (I have no idea and curious).

[trasz]

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

As for what happens when the devfs goes away - you're left with a mount point that's not accessible with full path. You can unmount it just fine, though. And we depend on that behaviour for reroot.

[kib]

In D20333#484711, @trasz wrote:

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

Then there must be a bug either in the testing methodology or in the code, right ? Ensure that the make_dev line is executed in both cases.

[trasz]

In D20333#484720, @kib wrote:

In D20333#484711, @trasz wrote:

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

Then there must be a bug either in the testing methodology or in the code, right ? Ensure that the make_dev line is executed in both cases.

I'm not sure how it works, but there seems to be some magic that makes sure it gets called in the right circumstances. Existing code already depends on it - eg linux_osd_jail_register() is called in the exact same way.

[tijl]

On amd64 the code is in linux_common.ko, not linux.ko and linux64.ko. So the directory is created/destroyed when linux_common is loaded/unloaded.