From: Chris Marusich <cmmarusich@gmail.com>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Packaging CDEmu and VHBA kernel module
Date: Thu, 14 Feb 2019 02:34:45 -0800 [thread overview]
Message-ID: <87k1i27j5m.fsf@gmail.com> (raw)
In-Reply-To: <87o97g1v4n.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Tue, 12 Feb 2019 23:48:08 +0100")
[-- 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 --]
next prev parent reply other threads:[~2019-02-14 10:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 22:48 Packaging CDEmu and VHBA kernel module Pierre Neidhardt
2019-02-14 10:34 ` Chris Marusich [this message]
2019-03-05 17:35 ` Pierre Neidhardt
2019-04-14 17:13 ` Pierre Neidhardt
2019-04-14 17:23 ` Danny Milosavljevic
2019-04-14 17:24 ` Pierre Neidhardt
2019-04-14 17:28 ` Pierre Neidhardt
2019-04-14 17:31 ` Danny Milosavljevic
2019-04-14 17:57 ` Tobias Geerinckx-Rice
2019-04-14 17:39 ` Tobias Geerinckx-Rice
2019-06-23 3:06 ` Chris Marusich
2019-06-23 6:39 ` Pierre Neidhardt
2019-06-23 6:40 ` Pierre Neidhardt
2019-06-24 13:04 ` Danny Milosavljevic
2019-06-23 22:03 ` Chris Marusich
2019-06-24 7:52 ` Pierre Neidhardt
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1i27j5m.fsf@gmail.com \
--to=cmmarusich@gmail.com \
--cc=guix-devel@gnu.org \
--cc=mail@ambrevar.xyz \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.