History log of /dragonfly/sys/vfs/dirfs/dirfs.h (Results 1 – 7 of 7)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3
# 7ea34faa 20-Oct-2019 zrj <rimvydas.jasinskas@gmail.com>

kernel/vfs: Consistently check if MALLOC_DECLARE was defined.

Keep these checks even in _KERNEL context and even if <sys/malloc.h>
is included before. Helps a lot for userland testing.


# 513a5bc4 06-Oct-2019 zrj <rimvydas.jasinskas@gmail.com>

kernel: Make chflags syscalls argument types consistent with userland.

There was an inconsistency between userland and syscalls argument types
that was inherited after initial fork. Adjust protot

kernel: Make chflags syscalls argument types consistent with userland.

There was an inconsistency between userland and syscalls argument types
that was inherited after initial fork. Adjust prototypes to use u_long
and add missing const char* too. Rerun sysent. Change tmpfs/dirfs to
use u_int for flags since mask for superuser changeable flags is
SF_SETTABLE 0xffff0000 (most fs use uint32_t), adjust mksubr script.
Remove no longer needed (u_long) casts I could find elsewhere.

While there, adjust unistd.h prototypes to use generic types too.

show more ...


Revision tags: v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1
# 08905fc5 28-Jul-2015 Antonio Huete Jimenez <tuxillo@quantumachine.net>

dirfs - Add kqueue(2) support

- Based on tmpfs work on 80ae59d743
- FIFO ops not added


# 26ec059c 26-Jul-2015 Antonio Huete Jimenez <tuxillo@quantumachine.net>

dirfs - Change debug levels

- Specific debug levels are specified for easier debugging:

1 Calls to VFS operations (mount, umount, ...)
3 Calls to VN operations (open, close, rea

dirfs - Change debug levels

- Specific debug levels are specified for easier debugging:

1 Calls to VFS operations (mount, umount, ...)
3 Calls to VN operations (open, close, read, ...)
5 Calls to subroutines
9 Everything

- Once dirfs is stabilised, debugging facilities will go and
only KTR will remain.

show more ...


Revision tags: v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc
# 66bce8a2 25-May-2015 Matthew Dillon <dillon@apollo.backplane.com>

dirfs - only expose inlines to the kernel

* Only expose inlines to kernel code, user code can get tripped up on
things like KKASSERT().


Revision tags: v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0
# 83837cef 10-Oct-2013 Antonio Huete Jimenez <tuxillo@quantumachine.net>

dirfs - Rework how host file permissions are checked.

* Retrieve uid/gid of the user running the vkernel on mount time
instead of on every open(2).


Revision tags: v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0
# 509bc517 22-Aug-2012 Antonio Huete Jimenez <tuxillo@quantumachine.net>

Bring in DIRFS: A filesystem for VKERNELS

* What is DIRFS?
dirfs is a pseudo-filesystem specific for vkernel(7) which allows mounting
host's directories into the vkernel. It runs directly in the

Bring in DIRFS: A filesystem for VKERNELS

* What is DIRFS?
dirfs is a pseudo-filesystem specific for vkernel(7) which allows mounting
host's directories into the vkernel. It runs directly in the vkernel's VFS
code, as any other regular filesystem, but it does syscalls (vkernels are
userland programs) to retrieve or post the information needed on every
operation requested.

Needless to say that the operations that you can perform in the host
directories/files depend on the permissions the user that runs the vkernel.
For example, you will not be able to 'chflags schg' if you run the vkernel
with a regular user and not with root.

* How does it work?
It basically works like any other filesystem. It has its own mount_dirfs
command that will be called by the system's mount(8) command when needed.

vkernel64 # mount -t dirfs /usr/src2 /mnt
vkernel64 # df -h /mnt
Filesystem Size Used Avail Capacity Mounted on
dirfs@/usr/src2 47G 36G 12G 75% /mnt

Umounting is a normal operation too:

vkernel64 # mount | fgrep dirfs
dirfs@/usr/src2 on /mnt (dirfs)
vkernel64 # umount /mnt

* What's the current status
Currently it is in a *experimental* status, with (probably) many bugs and some
parts missing.

TODO
- Make dirfs mpsafe.
- Fix problems with multiple mount points.
- Implement VOP_NLINK so that hardlinks are possible.
- Add missing kqueue(2) support.
- dirfs root so that a vkernel can be booted from it.
- Locking mechanisms for opened fds between host <-> vkernel.
- Make sure dirfs is properly restored after vkernel checkpointing
(upcoming GSoC project).
- Bug hunting & bug fixing.
- Any ideas?

show more ...