Send events to devd on mount new file system or unmount existing.
- Apply patch, rebuild and install kernell, reboot.
- run: cat /var/run/devd.pipe
- mount some fs, unmount some fs
- mount_msdosfs /dev/ada0p3 /media
- umount /media
!system=kernel subsystem=vfs type=mount fs=msdosfs path="/media"
!system=kernel subsystem=vfs type=unmount fs=msdosfs path="/media"
What's the motivation for this functionality?
This is 1296 bytes on the stack which is a non-starter for the kernel. Also 256 is a rather arbitrary number, should be based on the format string instead.
This is done too early - should be moved past unlocking the vnode one line below.
Why the device is not added?
There is a serious problem with the format: valid pathnames can contain ", spaces, tabs, newlines and other nasty chars which interfere. in general devctl, as it is, is not very well suited for this data
Note that in certain cases jailed root can mount filesystems and unprivileged users can do the same. This means that a nasty jailed root can try to feed devctl maliciously formatted data to cause trouble.
Same for the unmount case.
This is alternate to kqueue EVFILT_FS, but there is no need to keep prev state from getmntinfo() and compare with new to find changes.
Also user can use shell scripts to perform additional actions.
Is 256->16 ok?
I place core near to EVENTHANDLER_DIRECT_INVOKE(), to not break something.
Note the most important problem is that the buffer comes from the stack and it is very big. This should be malloc'ed instead.
256 -> 16 does not address the other problem - sizing is completely detached from how much memory is going to be needed. 256 is more than necessary for the current format string, but may become too small at some point. This is just error prone.
EVENTHANDLER code passes the vnode as an argument and it keeps it locked. Whether that's necessary or not is another question.
Neither snprintf nor devctl_notify deal with the vnode thus there is no reason to call them with it locked. In general you don't want to do stuff with a lock held if you can avoid it (sometimes performance and other times correctness reasons).
The biggest problem though is that devctl is just not prepared to handle user-supplied data. I don't have a definitive answer how to remedy this problem, but it's definitely a lot of work and it is highly unlikely to be worth the effort for this particular purpose. You did not provide an actual usecase for this functionality.
devctl is supposed to filter things properly for the protocols involved.