[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 1/2] virdevmapper: Don't error on kernels without DM support

On Tue, Aug 18, 2020 at 09:54:25 +0200, Michal Privoznik wrote:


> As promised yesterday, I've dived into the code and found out that the major
> number can be specified as a parameter to the dm module (just tested and it
> works). So the next thing I tried was to see how could we check whether the
> module was reloaded. I've tried opening /dev/mapper/control hoping that I
> will get EOF on module unload (which I could then use to run a callback that
> would invalidate the cached value). But having the file open prevents
> unloading the module.
> Loading/unloading a module results in an udev event, BUT we listen for udev
> events only in nodedev driver and moving the code out to a driver agnostic
> location and making it driver agnostic is too much code for a little gain.
> Then I looked whether it's possible to get the major number via an ioctl().
> But haven't found anything.
> Hence, I think the best solution for us is to not cache anything and simply
> parse /proc/devices every time. As an optimization, I can firstly check
> whether /dev/mapper/control exists at all an if not exit early.

I agree with this solution. In the end, loading a <1k file from procfs
and looking for a string doesn't really add too much to the code. In the
end libvirt mainly just shovels strings from one pile to another most of
the time. (see domain definition copy function for example).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]