Causing a mount from kernel

I believe that we aren't "allowed" (supposed to?) call mount from within the kernel, at least, I have not

yet found a way to do so that isn't dreadful.


It is how "upstream" does it and I'm trying to maintain familiarity to users.


But in "recent" kernels, there is SNAPSHOT_OP_MOUNT - and I am trying to mount a snapshot -

just one of mine, not Apple's.


Is this interface also Apple private? Or could I use it to mount my snapshots?

If it was public, I could then presumably also create/revert snapshots in my filesystem

issued by macOS utilities if I defined those vnops?

Replies

I'm not sure what you are asking. There is a user space mounting API in NetFSMountURLSync and similar. I don't know if that would be appropriate or userful with a local snapshot.

Not sure I can call a user-space-mounting API from kernel though.


I'd like to call "kernel_mount()" but it is private, and only for NFS. Failing that, __mac_mount() but also private. Then there is the userland handler mount() - but it takes a "struct mount_args" which isn't defined, unless I shadow it - but I was hoping to find a "legal" way to mount from kernel.

You can have the kernel side talk to the user side. People do that all the time. I'm not sure what you are doing in the kernel anyway. All that stuff is being deprecated you know.

I do believe the proper way is to create a new device in kernel, with ContentHint, and have a fs-bundle match it in userland, diskarbitrationd kicks in, have a utility for probe, and utility to issue mount, then we come back into the kernel for mounting - yes.


That is a lot of work to avoid calling "kernel_mount()"


but presumably that is what Apple wants us to do. Except, their one open-source example, NFS, calls kernel_mount like a first class citizen, so they aren't setting a very good example. So I wanted to see if Apple's new snapshot-mount they added very recently would allow us to trigger a snapshot mount from kernel.


I'm doing it in the kernel for the same reason NFS is. So I look forward to what Apple does to NFS so I can follow suit.

their one open-source example, NFS, calls kernel_mount like a first class citizen, so they aren't setting a very good example.

What are you looking at, specifically? I'm not aware of any kernel extension sample code. Are you looking at Apple's open source XNU code? That's something entirely different. That's for social media, not 3rd party developers developers.


So I look forward to what Apple does to NFS so I can follow suit.

I'm pretty sure Apple is going to toss it into the bit-bucket. You should do likewise.


The only path forward for low-level system modifications like this are the new system extensions.

Is this interface also Apple private?

No. The basic advice from QA1575 Supported KPIs is still valid today:

  • Does the function appear in the Kernel framework headers?

  • Is the function exported by one of the supported KPI symbol sets?

SNAPSHOT_OP_MOUNT
fails at the first hurdle.

that is what Apple wants us to do.

Correct.

Except, their one open-source example, NFS, calls

kernel_mount
like a first class citizen, so they aren't setting a very good example.

IMO NFS is not a good example of anything (-: With specific reference to macOS’s kernel, NFS is very old and does all sorts of weird things that would be inappropriate in new code.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

IMO NFS is not a good example of anything (-:


Hah, it is showing its age, that is true. Thanks for letting me know what I suspected.

What would have been awesome though, is if there was an Apple approved example. 🙂


Cheers,

Lund

What would have been awesome though, is if there was an Apple approved example.

What, you mean like MFSLives?

Seriously though, it’s hard to recommend that anyone develop a VFS plug-in at this point. Apple has already announced that we plan to discontinue KEXTs at some point in the future. There is not yet a replacement for VFS plug-ins but, on iOS, we have File Provider extensions and it’s not a great stretch to imagine that coming over to the Mac [1].

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Indeed, early 10.15 betas supported File Provider extensions.

What, you mean like MFSLives?


Never seen it before, and I spent hours googling for it back in 2013. But that aside, I only see userland calling mount(), and not

the kernel triggered a mount - but I did only skim over the sources.


Seriously though, it’s hard to recommend that anyone develop a VFS plug-in at this point. Apple has already announced that we plan to discontinue KEXTs at some point in the future.


Of course, this is work started in 2013, so I'll keep supporting it until Apple kicks us out, then I'll have to find another platform (or hobby).


on iOS, we have File Provider extensions


And do you think that is something good enough to do a full ZFS? Or even EXT3/NTFS etc?


I had a bunch of questions I was curious about wrt to XNU kernel, but I suppose there isn't much reason to chase those down 🙂

And do you think that is something good enough to do a full ZFS?

*shrug* File providers offer a very different view of the world. There’s nothing stopping you from using them to implement ZFS, but the end result would be very different from the VFS plug-in approach that you’re used to [1].

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] And, to be clear, I’m talking iOS here. I can’t say anything concrete about macOS at the moment.

File providers offer a very different view of the world. There’s nothing stopping you from using them to implement ZFS, but the end result would be very different from the VFS plug-in approach that you’re used to



True - but interesting you didn't immediately say "impossible". I recently ported ZFS to Windows, and that sure was different to a VFS style system.


Cheers,

Lund