[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200313190529.GB55327@gmail.com>
Date: Fri, 13 Mar 2020 12:05:29 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: NeilBrown <neilb@...e.de>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jeff Vander Stoep <jeffv@...gle.com>,
Jessica Yu <jeyu@...nel.org>,
Kees Cook <keescook@...omium.org>, NeilBrown <neilb@...e.com>
Subject: Re: [PATCH v2 3/4] docs: admin-guide: document the kernel.modprobe
sysctl
On Fri, Mar 13, 2020 at 01:07:27AM +0000, Luis Chamberlain wrote:
> > > +modprobe:
> > > +=========
> > > +
> > > +The path to the usermode helper for autoloading kernel modules, by
> > > +default "/sbin/modprobe". This binary is executed when the kernel
> > > +requests a module. For example, if userspace passes an unknown
> > > +filesystem type "foo" to mount(), then the kernel will automatically
> > > +request the module "fs-foo.ko" by executing this usermode helper.
> >
> > I don't think it is right to add the ".ko" there. The string "fs-foo"
> > is what is passed to the named executable, and it make well end up
> > loading "bar.ko", depending what aliases are set up.
> > I would probably write '... request the module named 'fs-foo" by executing..'
>
> And that is just because filesystems, in this case a mount call, will
> use the fs- prefix for aliases. This is tribal knowledge in the context
> above, and so someone not familiar with this won't easily grasp this.
>
> Is there an easier autoloading example other than filesystems we can use that
> doesn't require you to explain the aliasing thing?
>
> What is module autoloading? Where is this documented ? If that
> can be slightly clarified this would be even easier to understand as
> well.
>
I think we're getting too down into the weeds here. The purpose of this patch
is just to document the modprobe sysctl, not to to give a full explanation of
how module autoloading works including modaliases and everything. And this
sysctl isn't needed to enable module autoloading; it's enabled by default.
Most users already use module autoloading without ever touching this sysctl.
Let's just write instead:
For example, if userspace passes an unknown filesystem type to mount(),
then the kernel will automatically request the corresponding filesystem
module by executing this usermode helper. This usermode helper should
insert the needed module into the kernel.
If someone wants to write a new documentation file that fully explains kernel
modules (I don't see any yet), they should should certainly do so. It's more
than I set out to do, though. IMO, just documenting this sysctl is already a
nice improvement by itself.
- Eric
Powered by blists - more mailing lists