Packaging CDEmu and VHBA kernel module

Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

Hi!

I'm down to packaging CDEmu (https://cdemu.sourceforge.io/about/vhba/)
which depends on its own kernel module, VHBA
(https://cdemu.sourceforge.io/about/vhba/).

I wonder how we are supposed to package this in Guix.

- Where to store the kernel module?
- VHBA's documentation recommends setting up some Udev rule.  Does it
  mean that it's up to the user to configure those rules so that they
  have access to VHBA and thus CDEmu?

From the documentation:

--8<---------------cut here---------------start------------->8---
VHBA module provides the control character device via which communication between userspace and kernelspace is done. This requires both read and write permissions on the character device for the user running the CDEmu daemon.

Typically, the read-write permissions on the /dev/vhba_ctl are achieved by using udev's "uaccess" tag, by creating the following udev rule:

KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="uaccess"

The rule should be stored in a .rule file in either /lib/udev/rules.d or /etc/udev/rules.d directory. For the "uaccess" tag to be applied properly, the rule must be executed before the uaccess rule. Therefore, if the uaccess rule is contained by /lib/udev/rules.d/70-uaccess.rules, the rule above must be stored in a file with number smaller than 70.
--8<---------------cut here---------------end--------------->8---

Insights?

--
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> - Where to store the kernel module?

I'm not sure what the best way to build and use this will be.  FWIW, I
found these prior discussions.  Maybe they'll be useful:

https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01457.html
https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00446.html
https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00221.html

I think you might need to build a custom linux-libre kernel.  You also
might need to fiddle with base-initrd or raw-initrd procedures to load
your module in the initrd.  See "(guix) Initial RAM Disk" for details.
Hopefully somebody else can give better guidance here.

> - VHBA's documentation recommends setting up some Udev rule.  Does it
>   mean that it's up to the user to configure those rules so that they
>   have access to VHBA and thus CDEmu?

Basically, I think the answer is "yes, the user has to do it."  That's
not a great user experience, though.

The best way right now to install udev rules is either to manually add
custom udev rules (see: (guix) Base Services) in your operating system
declaration, or manually add a service in your operating system
declaration that extends the udev-service-type (such a service should
add the right udev rules for you).

If you're defining a new system service, you can extend the
udev-service-type.  That way, anybody who uses your service will
automatically get the right rules.  However, I'm not sure that what you
are doing can be modeled as a system service.  You're adding a kernel
module, which is not accomplished by adding a system service.

Maybe there's a better way that I don't know about.  If so, I'd like to
know!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Hi again,

Thanks for the tips, Chris, and sorry for the long silence.

> https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01457.html
> https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00446.html
> https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00221.html

Hmmm...  As far as I get it, none of those links tackle the issue of building an
_external_ kernel module.  The modules mentioned in the links are all part of
the linux-libre kernel.

Currently it seems that we have no way to build an external module.  It's quite problematic.

I've sent a patch: 34758@debbugs.gnu.org.

It needs the following:

- Fix vhba-module 'build phase.
- Optional: make a udev-related service to simplify the setup.  The service
  won't work if the module is not included in the kernel.

I'll continue the discussion there.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

I've merged the patch, cdemu-daemon and cdemu are now on master.
Big thanks to Danny for integration the new make-linux-module.

This is not the end though :p
At the moment, CDEmu is a bit of a hassle to use:

- insmod vhba.ko
- Add the following udev rule to your Guix system config so that non-root can use it:

(define %cdemu-vhba-udev-rule
 ;; For the "uaccess" tag to be applied properly, the rule must be executed
 ;; before the uaccess rule
 ;; (/run/current-system/profile/lib/udev/rules.d/70-uaccess.rules).
  (udev-rule
   "69-cdemu-vhba.rules"
   (string-append "KERNEL==\"vhba_ctl\", SUBSYSTEM==\"misc\", TAG+=\"uaccess\"")))

- cdemu load 0 /path/to/image/file
- cdemu status

--8<---------------cut here---------------start------------->8---
Devices' status:
DEV   LOADED     FILENAME
0     True       /path/to/image/file
--8<---------------cut here---------------end--------------->8---

Great success!

Now somehow I can't mount this drive.

$ sudo mount /dev/sr0 /mnt

hangs indefinitely.

dmesg gives me a lot of

--8<---------------cut here---------------start------------->8---
[ 2098.573872] udevd[3858]: timeout: killing 'cdrom_id --lock-media /dev/sr0' [3859]
[ 2098.573882] udevd[3858]: slow: 'cdrom_id --lock-media /dev/sr0' [3859]
--8<---------------cut here---------------end--------------->8---

Not sure what's happening.  Can anyone reproduce?

Could we configure a service that automatically inserts the kernel
module and sets up the right udev rule?  Danny?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hi Pierre,

On Sun, 14 Apr 2019 19:13:33 +0200
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Could we configure a service that automatically inserts the kernel
> module and sets up the right udev rule?  Danny?

Probably, but that's not the official way to do those things in modern Linux.

Linux is supposed to automatically load modules it needs (if it needs them
and they are indeed built as a module) on first access of the device file.

So we'd have to extend the generator of /run/booted-system/kernel/lib/modules
in guix to take a list of packages and union those, put the result in the
directory mentioned here and run depmod on it.

I have no idea where that generator is in guix. 

In order to set up udev, just add an udev service-extension in your service
(see gnu/services/sane.scm for an example).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

Arch Wiki (https://wiki.archlinux.org/index.php/Cdemu) hints that we
need the "sg" and "sr_mod" kernel modules.  lsmod tells me they are not
loaded.

    sudo modprobe sg sr_mod

returns normally, but lsmod still does not list the modules.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

O, my bad, sg and sr_mod are built-in with linux-libre.
Sorry for the noise.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Sun, 14 Apr 2019 19:24:42 +0200
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Arch Wiki (https://wiki.archlinux.org/index.php/Cdemu) hints that we
> need the "sg" and "sr_mod" kernel modules.  lsmod tells me they are not
> loaded.
> 
>     sudo modprobe sg sr_mod
> 
> returns normally, but lsmod still does not list the modules.

They are probably built-in, then.

Unfortunately, /proc/config.gz is disabled, so it's not easy to check.

But try checking gnu/packages/aux-files/linux-libre/5.0-x86_64.conf for
CHR_DEV_SG (see drivers/scsi/Kconfig in the Linux source as for why).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Pierre,

Pierre Neidhardt wrote:
> need the "sg" and "sr_mod" kernel modules.  lsmod tells me they 
> are not
> loaded.

At the risk of pointing out the obvious:

  $ grep -E "CHR_DEV_SG|BLK_DEV_SR" 
  /run/current-system/kernel/.config
  CONFIG_BLK_DEV_SR=y
  # CONFIG_BLK_DEV_SR_VENDOR is not set
  CONFIG_CHR_DEV_SG=y

lsmod only lists, well, modules.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Danny Milosavljevic wrote:
> Unfortunately, /proc/config.gz is disabled, so it's not easy to 
> check.

Mmm, I think Guix does the right thing here by just installing 
.config directly.

Having to load, as root, executable code into kernel space merely 
to export a compressed text file back to the user is dubious AF 
IMO.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Hi Pierre and Danny,

Apologies for my late reply.

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> I've sent a patch: 34758@debbugs.gnu.org.

I read through that, and I see that not only did you add vhba, but Danny
provided a generic linux-module-build-system that can build out-of-tree
modules like vhba.  Wow!  I checked it out, and it seems great.

On other distros, it always seemed like this sort of thing was easier.
It's great to see yet another example of how to hack on your system
using Guix.  What once was hard is now easier.  What I really like is
that by examining the Guile scheme source code, one can see how all the
pieces fit together - something that is much harder on a traditional
distro, since even when you can view the source, it's not always clear
how it all fits together.  In Guix, it's clear.

Thank you, Pierre and Danny!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

Hi Chris!

Thanks for the feedback, and I totally agree with that!
Guix is finally building an OS in a constructive way :)

That said, CDEmu does not work for me.  That daemon starts, the VHBA
module gets loaded, but when I mount something nothing happens.

Anyone?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

Does anyone have a hardware DVD/CD-ROM reader working with Guix?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> That said, CDEmu does not work for me.  That daemon starts, the VHBA
> module gets loaded, but when I mount something nothing happens.
>
> Anyone?

I wish I could offer advice, but I'm afraid I've never used these
before, and I'm working on some other things that are taking up my time
at the moment.  If I get around to playing with this, I'll let you know.

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Does anyone have a hardware DVD/CD-ROM reader working with Guix?

I'm not sure if this counts, but: I have successfully used an external
DVD drive, connected to my computer with a USB cable.  When I do that,
it is accessible via both /dev/sr0 and /dev/cdrom, and GNOME (or
something else I don't know about) automatically sees it and mounts it
when I insert a DVD containing files.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> I'm not sure if this counts, but: I have successfully used an external
> DVD drive, connected to my computer with a USB cable.  When I do that,
> it is accessible via both /dev/sr0 and /dev/cdrom, and GNOME (or
> something else I don't know about) automatically sees it and mounts it
> when I insert a DVD containing files.

If you see /dev/sr0, then I guess it counts.  Thanks for reporting.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging CDEmu and VHBA kernel module

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 73 bytes --]

Yes, I have a USB DVD writer on my Guix machine--works fine (/dev/sr0).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]