unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: raid5atemyhomework via Guix-patches via <guix-patches@gnu.org>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 45403@debbugs.gnu.org
Subject: [bug#45403] [PATCH] gnu: zfs: Split into packages specific for each of our major supported kernel versions.
Date: Mon, 04 Jan 2021 16:07:08 +0000	[thread overview]
Message-ID: <gSyEfBfe8jy1gzBjq_Mo6YLPvI3rz9ent6fT0ePZDBX2ktrMhOUhjTCB5FRUjQhVsYla9WVBeTwXspntIpjqnDTMvcGCNaJtZqZOLZymFIo=@protonmail.com> (raw)
In-Reply-To: <qiyCn7JkdMDaI-vjdqGGycCMX6FaqQzRZF69apGSm4cL9dFbZ-w8JDilCiuIfiXa9WvbNpaJbmhaRAJbXZgVNh_6HOKqlAxFfdi7pf6reIc=@protonmail.com>


Here's another alternative:

* Remove the separate "module" output and put the `.ko` file in the "out" output.
* Create a separate `zfs-guix-tools` which provides `zpool`, `zfs`, `zed`, `arc_summary`, `arcstat`, `dbufstat`, `raidz_test`, `zgenhostid`, `zvol_wait`, `fsck.zfs`, `mount.zfs`, `zdb`, `zhack`, `zinject`, `zstreamdump`, `ztest`.
  * What the provided binaries do is:
    * It looks at `/run/booted-system/kernel/manifest` and looks for a `"zfs"` package.
    * It `exec`s into the corresponding file in the `/gnu/store` for that package.

This way, we can have a separate package for ZFS userspace tools, which just calls the corresponding tools in the actual ZFS that gets installed.
It's somewhat magical, though.

Thanks
raid5atemyhomework

> This doesn't work, for two reasons:
>
> -   The kernel-module is in the output "module" of the `zfs` package. The code specifically checks for `(package? module)`, but we have to specify it as `(list system-zfs "module")`.
> -   ZFS is primarily managed via userspace tools, that's what ZFS users know how to use, and we should support that so that Guix users can ask non-Guix ZFS users for help with their ZFS problems. The userspace tools are included in the package. If the base `zfs` package cannot compile because it's incompatible with the default kernel, then the userspace tools are nonexistent and there is no way to manage ZFS.
>     -   So, for example we can't just remove the "module" output and have the `.ko` installed in the default "out" output, our core problem is we need to compile a ZFS module and userspace tools.
>     -   We can try to split the compilation to separate the ZFS module from the userspace tool, but that risks brittleness and subtle incompatibilities between a ZFS module compiled for your local kernel (which cannot be the latest and greatest kernel since the kernel does not maintain interface compatibility with kernel modules and the ZFS module is always having to catch up), and ZFS userspace tool compiled for the default latest-and-greatest kernel (even if we somehow manage to compile just the userspace tools with the latest kernel, there may be implicit assumptions about kernel constants and so on passed from the userspace tools to the kernel module, which may cause problems and birttleness).
>
>         So it's just safer to always override the `zfs` `#:linux` with the system kernel, and install it in `(packages ...)` and in `(kernel-loadable-modules ...)`.
>
> -   We get compileability as long as older kernel is used.
> -   We ensure that the userspace tool is built for the same kernel module for a compatible kernel, at all generations of the `guix system`.
>
>     Thanks
>     raid5atemyhomework
>
>
> > Why is this needed? KERNEL-LOADABLE-MODULES are already automatically
> > adapted in this way.
> > See this in gnu/system.scm :
> > (define* (operating-system-directory-base-entries os)
> > "Return the basic entries of the 'system' directory of OS for use as the
> > value of the SYSTEM-SERVICE-TYPE service."
> > (let* ((locale (operating-system-locale-directory os))
> > (kernel (operating-system-kernel os))
> > (hurd (operating-system-hurd os))
> > (modules (operating-system-kernel-loadable-modules os))
> > (kernel (if hurd
> > kernel
> > (profile
> > (content (packages->manifest
> >
> >                                  (cons kernel
> >                                        (map (lambda (module)
> >                                               (if (package? module)
> >                                                   (package-for-kernel kernel    <-----
> >                                                                       module)
> >                                                   module))
> >                                             modules))))
> >                        (hooks (list linux-module-database)))))
> >          (initrd  (and (not hurd) (operating-system-initrd-file os)))
> >          (params  (operating-system-boot-parameters-file os)))
> >     `(("kernel" ,kernel)
> >       ,@(if hurd `(("hurd" ,hurd)) '())
> >       ("parameters" ,params)
> >       ,@(if initrd `(("initrd" ,initrd)) '())
> >       ("locale" ,locale))))   ;used by libc
> >






  reply	other threads:[~2021-01-04 16:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-24 10:59 [bug#45403] [PATCH] gnu: zfs: Split into packages specific for each of our major supported kernel versions raid5atemyhomework via Guix-patches via
2020-12-24 20:41 ` Leo Famulari
2020-12-25  1:12 ` raid5atemyhomework via Guix-patches via
2020-12-25  4:09   ` Tobias Geerinckx-Rice via Guix-patches via
2021-01-04 13:58     ` Danny Milosavljevic
2021-01-04 15:49       ` raid5atemyhomework via Guix-patches via
2021-01-04 16:07         ` raid5atemyhomework via Guix-patches via [this message]
2021-01-04 16:32           ` raid5atemyhomework via Guix-patches via
2021-01-08 15:50 ` bug#45403: " raid5atemyhomework via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='gSyEfBfe8jy1gzBjq_Mo6YLPvI3rz9ent6fT0ePZDBX2ktrMhOUhjTCB5FRUjQhVsYla9WVBeTwXspntIpjqnDTMvcGCNaJtZqZOLZymFIo=@protonmail.com' \
    --to=guix-patches@gnu.org \
    --cc=45403@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    --cc=raid5atemyhomework@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).