Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752771AbbEFSxb (ORCPT ); Wed, 6 May 2015 14:53:31 -0400 Received: from mail.lang.hm ([64.81.33.126]:58117 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbbEFSxa (ORCPT ); Wed, 6 May 2015 14:53:30 -0400 Date: Wed, 6 May 2015 11:53:13 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: linuxcbon linuxcbon cc: Ken Moffat , Richard Weinberger , LKML Subject: Re: how to have the kernel do udev's job and autoload the right modules ? In-Reply-To: Message-ID: References: <5547B89B.5070502@nod.at> <5547FFB8.5050007@nod.at> <20150505222644.GA27497@milliways> <20150506165556.GA23190@milliways> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2785 Lines: 63 On Wed, 6 May 2015, linuxcbon linuxcbon wrote: > On Wed, May 6, 2015 at 5:55 PM, Ken Moffat 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/