linux-kernel - Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

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: <Pine.LNX.4.64.0801060652390.16883@asgard.lang.hm>
Date:	Sun, 6 Jan 2008 07:05:36 -0800 (PST)
From:	david@...g.hm
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Adrian Bunk <bunk@...nel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Sam Ravnborg <sam@...nborg.org>, Al Boldi <a1426z@...ab.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Brownell <david-b@...bell.net>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage	support

On Sun, 6 Jan 2008, Stefan Richter wrote:

> David Lang wrote:
>> On Sun, 6 Jan 2008, Stefan Richter wrote:
>>> Module autoloading is quite different.
>>
>> but if boot scripts can figure out what modules to autoload, why can't
>> scripts be written to figure out what drives to build into a system?
>
> Because build-time configuration has to deal with different, more
> complex questions than run-time configuration.  For starters, build-time
> configuration narrows down the options for run-time configuration.

Ok, I'll bite.

what config options must be selected by the user at build time? (i.e. no 
sane default can possibly be deduced from the hardware)

there are a lot of options that, if selected, will affect the final result 
significantly. but I can't think of any that can't have a reasonable 
default.

what sysadmins like me would really like is a set of scripts that could 
generate a .config from an existing system. After we have one that covers 
the hardware for the system we will then have a much better starting point 
to work from. We may disable some drivers (sound drivers on a server for 
example). We may enable other drivers (or combine the results of runs on 
seperate hardware to make a slightly more general kernel config). And we 
will make many other selections that are not hardware dependant (SLAB vs 
SLUB vs SLOB, IO schedulers, etc) but just figuring out what drivers are 
needed to support a particular piece of hardware would be a huge help. 
It's frequently hard to figure out which drivers are needed for a Vendor X 
model 12345 motherboard (major things are easy, it gets hard when you want 
to do power monitoring and things like that) it is even harder when you 
have to figure out what needs to be enabled so that you can see the help 
text of other options to see if they are the right ones.

I started toying with Linux (on my home systems) in the 0.99 days and have 
been makeing my living with it starting in the 1.3 days, so it's not that 
I am a newcomer to kernel configuration, but even with my experiance it's 
sometimes hard to figure out what I need to enable when I start needing a 
new set of functionality on a system.

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/