an imported zpool should appear as a synthetic device in sysfs

[devvythelopper]

Describe the feature would like to see added to OpenZFS

It would be nice if an imported zpool would show up as a synthetic device in sysfs (on linux), and in case it does, then in such a fashion, that systemd would list it as a "device".

How will this feature improve OpenZFS?

This would facilitate easier integration with systemd units as they could simply depend on the zpool appearing as a xyz.device. It might give similar advantages I'm not seeing currently.

Additional context

[rincebrain]

Unfortunately, IIRC, sysfs and debugfs access are GPL-only in the Linux kernel, so proc is the only place we get to be.

[jittygitty]

Unfortunately, IIRC, sysfs and debugfs access are GPL-only in the Linux kernel, so proc is the only place we get to be.

@rincebrain Oh boy am I getting so fatigued from the increasing number of symbol doors being slammed shut on our noses. Can't we simply code ZFS with "TWO" pathways, one with "we can use ALL" the symbols" via build zfs as GPL?

Is that really too much to ask? Yea that's why you see my posts making these pains obvious, I'd really like to see every feature to have a pathway using the kernel exports when they exist, regardless if they are export_symbol or export_symbol_gpl.

There is nothing wrong with treating all GPL exports as in reality COPYLEFT exports.
There is nothing wrong with us simply building zfs as gpl if we're not "distributing".

Not sure if you read the rest of #14555 and I had also emailed @ryao privately to elaborate. The point is that as ornias and many have pointed out, all this export symbol stuff was Linus/Linux trying to fight off "closed source" proprietary kernel modules. Therefore, preventing COPYLEFT use of gpl-only symbols was never the "intent", and Linus won't make himself a hypocrite.

The zfs project for most practical purposes is in reality GPL functionally, all source here is open not closed and if people distribute changes, they release their sources.

While a "proprietary CLOSED source" module would have big trepidation slapping "GPL" to their license, changing CDDL to GPL in META file is 'trivial' by comparison.

So while I highly discourage those who recommended changing export_symbol_gpl instances to export_symbol, even though its technically "legal" to even "distribute" binary+source with such changes, I think changing cddl to gpl before building zfs is perfectly fine and Linux/Linus should really not have any problem with it at all. They may even love it if closed source proprietary drivers did the same thing and then accidently "distributed" it, so then they can say, hey hand over the "CODE NOW!" :)

(The problem with changing export_symbol_gpl to export_symbol is that it would create a bad legal precedence and end up "helping" proprietary "closed modules".)

Even if someone accidently "distributed" zfs binary+code with license changed to gpl, though technically that would violate the CDDL license of zfs, legally nothing would really be done, because there is "no real damage", no "practical" change etc.
Yea, Linus could then ask that zfs comply with gpl, but in reality, it "already" DOES!

All legal/law has lots to do with intent, not license 'name', COPYLEFT is the Intent! :)