guix-patches
[Top][All Lists]
Advanced

[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.

Attachment: pgpmo2r1UZfio.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]