linux-kernel - Re: how to have the kernel do udev's job and autoload the right modules ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1505061142440.2429@nftneq.ynat.uz>
Date:	Wed, 6 May 2015 11:53:13 -0700 (PDT)
From:	David Lang <david@...g.hm>
To:	linuxcbon linuxcbon <linuxcbon@...il.com>
cc:	Ken Moffat <zarniwhoop@...world.com>,
	Richard Weinberger <richard@....at>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: how to have the kernel do udev's job and autoload the right
 modules ?

On Wed, 6 May 2015, linuxcbon linuxcbon wrote:

> On Wed, May 6, 2015 at 5:55 PM, Ken Moffat <zarniwhoop@...world.com> wrote:
>> I suggest that you take the time to look at eudev and mdev, and
>> think about how you can use the facilities they offer.

> I was wishing the kernel would offer some minimal support for
> network, sound and full screen video for my hw :(.
> But it seems I need to load modules to achieve this. And to load modules,
> it needs some kind of "hotplug" called udev or mdev.

I've been building my own kernels for production systems for a long time. It is 
absolutly possible to have a kernel provide support for your hardware without 
modules.

The problem is the question of how much hardware you want to support. Modules 
were created because compiling everything into the kernel at once has multiple 
problems

1. sometimes different drivers can handle the same hardware, and you can only 
use one driver for the hardware

2. sometimes different hardware conflicts in that drivers for one piece of 
hardware will think that they've found their hardware, and prevent the proper 
drivers from working (sometimes doing 'strange' things to the hardware in the 
process)

3. the resulting kernel is VERY large. Back in the day, the problem was that the 
kernel would no longer fit on a floppy. We don't have that limit, but we still 
don't want to waste time reading a huge amount of data into RAM (at which point 
it prevents the RAM from being used for other things)

4. boot time would be horrible as all the drivers try to detect their hardware 
and time out.

so if you want to cover your hardware, you have two choices.

1. If you have a relatively small variation of hardware, just compile in all the 
drivers you need. This even works for most hotplugged items.

2. use modules

If you use modules, then you need to have some way of loading them. It's a very 
bad idea to have this happen by magic, without any control over the policies 
(sometimes you don't want drivers to load just because hardware exists). So you 
need to have a place to set the policy. Since the kernel provides mechanisms, 
not policy, the result is that the kernel tells userspace what it thinks it's 
found and it's up to userspace to then 'do the right thing'

So if you don't want to use udev, then you need to have something that replaces 
it to load the right module with the right options.

It's perfectly legitimate to not want to use udev, but that doesn't mean that 
the kernel will (or should) do it for you.

David Lang

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/