[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#30629] Device mapper modalias
From: |
Danny Milosavljevic |
Subject: |
[bug#30629] Device mapper modalias |
Date: |
Wed, 7 Mar 2018 19:56:25 +0100 |
Hi Ludo,
On Thu, 01 Mar 2018 11:11:11 +0100
address@hidden (Ludovic Courtès) wrote:
> > assert(tablestatus.header.target_count == 1);
> > printf("target_type %s\n", tablestatus.items[0].target_type); //
> > prints "crypto", hence we should modprobe "dm-crypto".
>
> 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 = target_type of the table
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’s 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.
I checked it now - it's only reported for events: it reports which target caused
the event.
It would be easy to extend Linux to also report the targets in the state, but
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.
>
> Hmm! So how do other distros do? There must be a way to get the module
> name no?
Good question... no idea.
pgpmo2r1UZfio.pgp
Description: OpenPGP digital signature