From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eteFM-0003LG-R0 for guix-patches@gnu.org; Wed, 07 Mar 2018 13:57:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eteFK-0002rd-7Y for guix-patches@gnu.org; Wed, 07 Mar 2018 13:57:04 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41925) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eteFK-0002rX-4d for guix-patches@gnu.org; Wed, 07 Mar 2018 13:57:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eteFJ-00064K-Qy for guix-patches@gnu.org; Wed, 07 Mar 2018 13:57:01 -0500 Subject: [bug#30629] Device mapper modalias Resent-Message-ID: Date: Wed, 7 Mar 2018 19:56:25 +0100 From: Danny Milosavljevic Message-ID: <20180307195625.1708032a@scratchpost.org> In-Reply-To: <87r2p46r7k.fsf@gnu.org> References: <20180227141720.12513-1-ludo@gnu.org> <20180227222632.42bcf52c@scratchpost.org> <87tvu2w2vg.fsf@gnu.org> <20180228040227.4299790b@scratchpost.org> <87r2p46r7k.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/cY27D+H+k_AxxadENcfK2=Q"; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30629@debbugs.gnu.org --Sig_/cY27D+H+k_AxxadENcfK2=Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, On Thu, 01 Mar 2018 11:11:11 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > > assert(tablestatus.header.target_count =3D=3D 1); > > printf("target_type %s\n", tablestatus.items[0].target_type); /= / prints "crypto", hence we should modprobe "dm-crypto". =20 >=20 > Is this target_type/module name mapping always correct? Yes - since that's how Linux itself loads the dm modules: ./drivers/md/dm-target.c: request_module("dm-%s", name); (and see dm-table.c where once can see that name =3D target_type of the tab= le structure) On the other hand, not all dm-*.ko are targets! > If so, we could always implement this DM_TABLE_STATUS ioctl and use it, > although if it loads modules as a side effect that=E2=80=99s not great. > > Alternatively, there's even a dm-uevent.c for sysfs AND we have enabled= it AND it's supposed > > to report DM_TARGET - but I can't see it. Maybe it only does that for = events and not for state. =20 I checked it now - it's only reported for events: it reports which target c= aused the event. It would be easy to extend Linux to also report the targets in the state, b= ut that won't help us with past kernels - and since our use case is mostly to get the module list starting from an already-running system, it won't help us. So I think the ioctl is the best way. > > $ udevadm info -q all /dev/dm-0 > > > > ... which has quite a lot of the info, but not the module name. =20 >=20 > Hmm! So how do other distros do? There must be a way to get the module > name no? Good question... no idea. --Sig_/cY27D+H+k_AxxadENcfK2=Q Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlqgNdkACgkQ5xo1VCww uqWdLwf9E95OIXhoB1Ou0PSyometcTUtgCb+ptb5vczHab6TTNEplERrLIvNeOUl fHb+SIQM725IT+5zNG9fvxehlb9SI84tQJHN2SgEIghQ1qF/hDivLOVYnH+B0pxF KmQOiYIfuK98GMbQB0i8TsjfOiYW13YJwnHgQQVbc1oqRJrA2yg+hguCzxFyKuu8 vG1amOxM9D7J5XvGs9xhS8N1enUfmcHrNX9bseC1ew89T2Vh7iMp31XhT4UJBrVU Sp3tOtBLmdC5wlcqC9+xJNjBAJr0CG9FUSawDMt4zgZ2lF7Iti8Pt3gzC1A6FK/8 kLmMNwVFZEoG2vjOXPu0IjKOK12ELg== =Xfc8 -----END PGP SIGNATURE----- --Sig_/cY27D+H+k_AxxadENcfK2=Q--