LinuxLists.cc - Automatic Configuration of a Kernel

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

another advantage of having an auto-config for the kernel is that people
who are experimenting may have the auto-config find hardware that they
didn't realize they had (or they didn't realize that support had been
added)

I know that most of my kernels don't have support for everything the
motherboards have on them (mostly I don't care much about the other
features, but in some cases they weren't supported, or weren't worth the
hassle of figureing the correct config for when I started, and I've never
gone back to try and figure it out)

and while I'm not a kernel hacker, I've been compiling my own kernels
since about '94 so I'm not exactly a newbe :-)

David Lang

On Wed, 14 Sep 2005, Hua Zhong wrote:

> Date: Wed, 14 Sep 2005 17:37:41 -0700
> From: Hua Zhong <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: Automatic Configuration of a Kernel
>
> I concur.
>
> There seems to be a trend that discourages normal users from running
> kernel.org kernels, but I rarely find myself agree with such mind set.
> Do we want more people to test vanilla kernels or not?
>
> On 9/14/05, Marek W <[email protected]> wrote:
>> On Thu, 15 Sep 2005 09:49, Daniel Thaler wrote:
>>> Michal Piotrowski wrote:
>>>> Hi,
>>>>
>>>> On 15/09/05, Ahmad Reza Cheraghi <[email protected]> wrote:
>>>>> Hi
>>>>>
>>>>> I wrote this Framework for making a .config based on
>>>>> the System Hardwares. It would be a great help if some
>>>>> people would give me their opinion about it.
>>>>>
>>>>> Regards
>>>>
>>>> It's for new linux users? They should use distributions kernels.
>>>> It's for "power users"? They just do make menuconfig...
>>>> It's for kernel developers? They just do vi .config.
>>>
>>> I like the idea.
>>> I'm a power user and of course I can do make menuconfig, but it would be
>>> useful when building a kernel for new hardware for example.
>>>
>>> Currently that involves looking at dmesg output to figure out the correct
>>> options; this would provide a nice base config to work with and reduce the
>>> amount of effort.
>>
>> I second that. Unlike majority of users I suppose, I upgrade the kernel often
>> and I am on the bleeding edge (laptop user with some drivers still being in
>> development). Even with oldconfig it's easy to miss a useful driver
>> (sometimes there's no help or the volume of new options is too large).
>>
>> Something that can do the hardware detection, then maps that to drivers would
>> be very useful.
>>
>>
>> --
>>
>> Marek W
>> Send instant messages to your online friends http://au.messenger.yahoo.com
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-15 03:04:07

by Lee Revell

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Wed, 2005-09-14 at 19:03 -0700, David Lang wrote:
> another advantage of having an auto-config for the kernel is that people
> who are experimenting may have the auto-config find hardware that they
> didn't realize they had (or they didn't realize that support had been
> added)
>
> I know that most of my kernels don't have support for everything the
> motherboards have on them (mostly I don't care much about the other
> features, but in some cases they weren't supported, or weren't worth the
> hassle of figureing the correct config for when I started, and I've never
> gone back to try and figure it out)

Why does this have to be in the kernel again? Isn't this exactly what
you get with a fully modular config and hotplug?

Lee

2005-09-15 03:30:47

by Daniel Thaler

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Lee Revell wrote:
> Why does this have to be in the kernel again? Isn't this exactly what
> you get with a fully modular config and hotplug?

It doesn't go in the kernel. If I understand correctly, it's a script that is
invoked by 'make autoconfig'. Note that I didn't read the patch, because it's a
.tgz on a website and I couldn't be bothered to download it.

Daniel

2005-09-15 04:16:51

by Lee Revell

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 2005-09-15 at 05:37 +0200, Daniel Thaler wrote:
> Lee Revell wrote:
> > Why does this have to be in the kernel again? Isn't this exactly what
> > you get with a fully modular config and hotplug?
>
> It doesn't go in the kernel. If I understand correctly, it's a script that is
> invoked by 'make autoconfig'. Note that I didn't read the patch, because it's a
> .tgz on a website and I couldn't be bothered to download it.

Oh, sorry. Then read that as "what's the point"?

Lee

2005-09-15 04:54:37

by Marek Wawrzyczny

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005 13:04, Lee Revell wrote:
> On Wed, 2005-09-14 at 19:03 -0700, David Lang wrote:
> > another advantage of having an auto-config for the kernel is that people
> > who are experimenting may have the auto-config find hardware that they
> > didn't realize they had (or they didn't realize that support had been
> > added)
> >
> > I know that most of my kernels don't have support for everything the
> > motherboards have on them (mostly I don't care much about the other
> > features, but in some cases they weren't supported, or weren't worth the
> > hassle of figureing the correct config for when I started, and I've never
> > gone back to try and figure it out)
>
> Why does this have to be in the kernel again? Isn't this exactly what
> you get with a fully modular config and hotplug?

Not so much the kernel. When compiling the kernel I'd prefer not to waste time
and space compiling the 100+ modules I will never ever use on my laptop. I'd
prefer for something to select the modules necessary for my hardware. I can't
afford the time to keep up to date with that's new and what isn't, what has
changed, what has been superseded, which module works with which device,
chipset even, etc...

--
-
Marek W

--
2b | !2b
Send instant messages to your online friends http://au.messenger.yahoo.com

2005-09-15 06:18:17

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005 14:18:13 +1000, Marek W said:

> Not so much the kernel. When compiling the kernel I'd prefer not to waste time
> and space compiling the 100+ modules I will never ever use on my laptop.

It's actually a lot worse than that - here's my minimized custom kernel that
drives everything on my laptop and then some, and a recent Fedora kernel:

[/lib/modules]2 find 2.6.13-mm1/kernel/drivers -name '*.ko' | wc -l
37
[/lib/modules]2 find 2.6.12-1.1400_FC5/kernel/drivers/ -name '*.ko' | wc -l
832

(OK, so I *do* have a few builtins that Fedora builds as modules. That's gonna
change the numbers by half a dozen or so...)

> I'd
> prefer for something to select the modules necessary for my hardware. I can't
> afford the time to keep up to date with that's new and what isn't, what has
> changed, what has been superseded, which module works with which device,
> chipset even, etc...

I'm of the opinion that if you don't have that much time, you should be using a
distro kernel where somebody *else* is taking the time. If you're the type
that builds their own kernel, the *last* thing you want is a tool glossing over
the fact that a module has been superceded. Who's going to take care of the
matching changes for /etc/modprobe.conf and similar userspace changes, and
other stuff like that? (I figure if 'make oldconfig' asks a question, I should
take notice, and any userspace changes that don't get made are my fault - and
if 'make oldconfig' switches drivers on me without asking, that's a *bug* that
lkml will hear about.. ;)

Attachments:

(No filename) (226.00 B)

2005-09-15 07:58:36

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

> > Something that can do the hardware detection, then
> maps that to drivers
> > would be very useful.
>
> well, in theory this works as well. If you do this
> in the kernel source

> directory:
>
> make allmodconfig
>
> that makes a kernel with all possible configure
> options that can be built as
> modules enabled.
>
> make install
>
> and you have a couple of nice files in
> /lib/modules/(version)/modules.*map
>
> -rw-r--r-- 1 root root 73 Sep 14 23:15
> modules.ieee1394map
> -rw-r--r-- 1 root root 132 Sep 14 23:15
> modules.inputmap
> -rw-r--r-- 1 root root 81 Sep 14 23:15
> modules.isapnpmap
> -rw-r--r-- 1 root root 7834 Sep 14 23:15
> modules.pcimap
> -rw-r--r-- 1 root root 43 Sep 14 23:15
> modules.seriomap
> -rw-r--r-- 1 root root 80010 Sep 14 23:15
> modules.usbmap
>
> the usual favorite of mine is modules.pcimap, which,
> when compined with lspci
> can give you the proper module for your pci device.
> Granted it has the fault
> of a) how to figure out the configure option.
> Sometimes it's CONFIG_[name],
> sometimes it's not (grepping maybe?)

For that reason I thought the best way is: using the
option-name given out, by make menuconfig or make
config... And you can even easily upgraded it if the
option-name(for the same Hardware) is changed by a new
Kernel. By only putting this new option-name in the
rules_list with the same rule.

b) sometimes
> two drivers do the same
> thing, but if enabled together will cause kittens to
> cry and babies to pull
> flowers. Therein lies one of the main issues. I'm
> going to assume by seeing
> the rules_file bit that you address it in that way.
> However, seeing the
> development model of the kernel, trying to keep that
> updated may get a little
> weird.

Yes your right. The idea(eventhuogh it is a dream) is
that, this Framework might be hopefully in the future,
a part of the Kernel. So it can be updated everytime
before a new Kernel will be releases.

> My 1.5 $denomination
> Chris White
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005-09-15 08:12:17

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Lee Revell <[email protected]> wrote:

> On Thu, 2005-09-15 at 05:37 +0200, Daniel Thaler
> wrote:
> > Lee Revell wrote:
> > > Why does this have to be in the kernel again?
> Isn't this exactly what
> > > you get with a fully modular config and hotplug?
> >
> > It doesn't go in the kernel. If I understand
> correctly, it's a script that is
> > invoked by 'make autoconfig'. Note that I didn't
> read the patch, because it's a
> > .tgz on a website and I couldn't be bothered to
> download it.
>
> Oh, sorry. Then read that as "what's the point"?
>
> Lee
>
It does go in the Kernel. The files are all kept in
the directory <KERNEL>/scripts/kconfig/.
And I changed a little bit the Makefile and the conf.c
in the <KERNEl>/scrips/kconfig.

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

2005-09-15 09:13:49

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Daniel Thaler wrote:
>
> I like the idea.
> I'm a power user and of course I can do make menuconfig, but it would be
> useful when building a kernel for new hardware for example.

I agree ! When compiling for a new platform you would like to have at
least a minimal skeleton of the .config which is working for your
machine and then add stuff like NFS, netfilter, and other stuff.

Something like:

make autoconfig ---> generate a skeleton (compile and run)
make menuconfig ---> add the stuff you want (file systems, firewall, ...)

However, if the "make autoconfig" target generate nothing but a bare
minimal .config which is fitting exactly your hardware, which would
compile and run on your platform (with a stripped down network layer,
only one file system, etc). Then I would like to have this.

> Currently that involves looking at dmesg output to figure out the correct
> options; this would provide a nice base config to work with and reduce the
> amount of effort.

Yes. Especially for strange platforms where you usually end-up with a
try and error methodology... (yes, I got a Transmeta Crusoe Sony Vaio
C1-MZX once ! :)).

Regards
--
Emmanuel Fleury

Assistant Professor | Office: B1-201
Computer Science Department, | Phone: +45 96 35 72 23
Aalborg University, | Mobile: +45 26 22 98 03
Fredriks Bajersvej 7E, | E-mail: [email protected]
9220 Aalborg East, Denmark | URL: http://www.cs.aau.dk/~fleury

2005-09-15 09:33:42

by Marek Wawrzyczny

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005 16:18, [email protected] wrote:

Wasn't I being optimistic :) but hey, it's good to see that many modules.

> > I'd prefer for something to select the modules necessary for my hardware.
> > I can't afford the time to keep up to date with that's new and what
> > isn't, what has changed, what has been superseded, which module works
> > with which device, chipset even, etc...
>
> I'm of the opinion that if you don't have that much time, you should be
> using a distro kernel where somebody *else* is taking the time. If you're
> the type that builds their own kernel, the *last* thing you want is a tool
> glossing over the fact that a module has been superceded. Who's going to
> take care of the matching changes for /etc/modprobe.conf and similar
> userspace changes, and other stuff like that? (I figure if 'make oldconfig'
> asks a question, I should take notice, and any userspace changes that don't
> get made are my fault - and if 'make oldconfig' switches drivers on me
> without asking, that's a *bug* that lkml will hear about.. ;)

This is exactly why I switched to Gentoo and use gentoo-sources kernel.

However, keep in mind that when I do 'make oldconfig', more often then now the
help on new options is insufficient to make a decision on whether or not
something should be included.

Secondly, I'd love to know exactly what sort of hardware is inside my laptop,
but funnily enough I find out the chipsets and vendors by running lspci.

--
-
Marek W

--
2b | !2b
Send instant messages to your online friends http://au.messenger.yahoo.com

2005-09-15 09:48:47

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Marek W <[email protected]> wrote:

> On Thu, 15 Sep 2005 16:18, [email protected]
> wrote:
>
> Wasn't I being optimistic :) but hey, it's good to
> see that many modules.
>
> > > I'd prefer for something to select the modules
> necessary for my hardware.
> > > I can't afford the time to keep up to date with
> that's new and what
> > > isn't, what has changed, what has been
> superseded, which module works
> > > with which device, chipset even, etc...
> >
> > I'm of the opinion that if you don't have that
> much time, you should be
> > using a distro kernel where somebody *else* is
> taking the time. If you're
> > the type that builds their own kernel, the *last*
> thing you want is a tool
> > glossing over the fact that a module has been
> superceded. Who's going to
> > take care of the matching changes for
> /etc/modprobe.conf and similar
> > userspace changes, and other stuff like that? (I
> figure if 'make oldconfig'
> > asks a question, I should take notice, and any
> userspace changes that don't
> > get made are my fault - and if 'make oldconfig'
> switches drivers on me
> > without asking, that's a *bug* that lkml will hear
> about.. ;)
>
> This is exactly why I switched to Gentoo and use
> gentoo-sources kernel.
>
As far as I know uses Gentoo the configuration that
will be on the live-Cd. So
1. they might be alot of not needed modules
2. Some Hardware might be undetected.

> However, keep in mind that when I do 'make
> oldconfig', more often then now the
> help on new options is insufficient to make a
> decision on whether or not
> something should be included.
>
> Secondly, I'd love to know exactly what sort of
> hardware is inside my laptop,
> but funnily enough I find out the chipsets and
> vendors by running lspci.

The good thing about lspci (comparing to the others
Hardware detection like kudzu or discovery) it not
only uses the /proc files for getting the Hardware
information it also grabs its information directly
from the I/O of the Hardwares. But it lacks of getting
alls the Hardwares e.g. CD-Rom, floppy...
It would be great if there is a Programm that gets all
the Hardware information directyl from the I/O
independent from the Kernel-installation.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005-09-15 09:57:00

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Michal Piotrowski
<[email protected]> wrote:

> Hi,
>
> On 15/09/05, Ahmad Reza Cheraghi
> <[email protected]> wrote:
> > Hi
> >
> > I wrote this Framework for making a .config based
> on
> > the System Hardwares. It would be a great help if
> some
> > people would give me their opinion about it.
> >
> > Regards
>
> It's for new linux users? They should use
> distributions kernels.
> It's for "power users"? They just do make
> menuconfig...
> It's for kernel developers? They just do vi .config.
>
> I'll try it later, but I'm a bit sceptical.
>
> How about networking options? It can detect what
> protocols are needed?
> Filesystems?

The Network option or the Filesystes are choosen as a
Standard. So it will be there without checking if they
needed or not. Because I think Protocols like TCP-IP
or Filesystems like NTFS or expt2 has to be installed
on the now days Systems. But if they are any
suggestion or ideas of detecting those thing. No
problem just send me rule that does that and I will
updated easily on the Framework.Thats the benefit of
this Framework.;-)

> Regards,
> Michal Piotrowski
>

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

2005-09-15 10:27:32

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Wed, 14 Sep 2005, Lee Revell wrote:

> On Wed, 2005-09-14 at 19:03 -0700, David Lang wrote:
>> another advantage of having an auto-config for the kernel is that people
>> who are experimenting may have the auto-config find hardware that they
>> didn't realize they had (or they didn't realize that support had been
>> added)
>>
>> I know that most of my kernels don't have support for everything the
>> motherboards have on them (mostly I don't care much about the other
>> features, but in some cases they weren't supported, or weren't worth the
>> hassle of figureing the correct config for when I started, and I've never
>> gone back to try and figure it out)
>
> Why does this have to be in the kernel again? Isn't this exactly what
> you get with a fully modular config and hotplug?

I happen to be one of those crazy people who believe that there are
advantages to building non-modular kernels.

1. they compile faster

2. they use less memory (if tightly configured) as each module loaded will
average a 1/2 page of wasted memory

3. it's far easier to moveone file around then a file and a directory tree
of modules

4. the non-modular kernel will be slightly faster (all calls to modules
must be far calls, if it's not modular the compiler can optimize some of
the calls)

5. once kmem and mem can be made read-only there is a security advantage
in not having kernel modules available (yes the machine can be rebooted
into a new kernel, but that's easier to detect then a module getting
loaded)

6. the kernel takes less space on disk (matters in embedded devices and
other places where your media is small)

none of this matters if you're dealing with a large desktop system that
you are installing from a series of CD/DVD disks from a top-5 distro, but
that's not the entire world

note that a good autodetect routine will have no impact on the kernel once
it's compiled, it just generates a .config file.

I believe it makes more sense to have this be part of the kernel source
distro then a seperate project as it needs to have a lot of knowledge
about what a particular kernel supports and that's going to change from
release to release.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-15 10:45:48

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005 [email protected] wrote:

> On Thu, 15 Sep 2005 14:18:13 +1000, Marek W said:
>
>> Not so much the kernel. When compiling the kernel I'd prefer not to waste time
>> and space compiling the 100+ modules I will never ever use on my laptop.
>
> It's actually a lot worse than that - here's my minimized custom kernel that
> drives everything on my laptop and then some, and a recent Fedora kernel:
>
> [/lib/modules]2 find 2.6.13-mm1/kernel/drivers -name '*.ko' | wc -l
> 37
> [/lib/modules]2 find 2.6.12-1.1400_FC5/kernel/drivers/ -name '*.ko' | wc -l
> 832
>
> (OK, so I *do* have a few builtins that Fedora builds as modules. That's gonna
> change the numbers by half a dozen or so...)
>
>> I'd
>> prefer for something to select the modules necessary for my hardware. I can't
>> afford the time to keep up to date with that's new and what isn't, what has
>> changed, what has been superseded, which module works with which device,
>> chipset even, etc...
>
> I'm of the opinion that if you don't have that much time, you should be using a
> distro kernel where somebody *else* is taking the time. If you're the type
> that builds their own kernel, the *last* thing you want is a tool glossing over
> the fact that a module has been superceded. Who's going to take care of the
> matching changes for /etc/modprobe.conf and similar userspace changes, and
> other stuff like that? (I figure if 'make oldconfig' asks a question, I should
> take notice, and any userspace changes that don't get made are my fault - and
> if 'make oldconfig' switches drivers on me without asking, that's a *bug* that
> lkml will hear about.. ;)

sometimes tracking down exactly what options need to be enabled to let you
at other options that apply to your system can be quite a chore, a tool to
start from no .config file and get you one that is tailered to your system
could be useful.

I agree that make oldconfig shouldn't do this type of thing, but that
requires that youhave an existing .config for the box. if you do a make
autoconfig you are explicitly asking the software to do this for you.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-15 11:20:33

by مسعود شربیانی

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, Sep 15, 2005 at 01:12:14AM -0700, Ahmad Reza Cheraghi wrote:
>
>
> --- Lee Revell <[email protected]> wrote:
>
> > On Thu, 2005-09-15 at 05:37 +0200, Daniel Thaler
> > wrote:
> > > Lee Revell wrote:
> > > > Why does this have to be in the kernel again?
> > Isn't this exactly what
> > > > you get with a fully modular config and hotplug?
> > >
> > > It doesn't go in the kernel. If I understand
> > correctly, it's a script that is
> > > invoked by 'make autoconfig'. Note that I didn't
> > read the patch, because it's a
> > > .tgz on a website and I couldn't be bothered to
> > download it.
> >
> > Oh, sorry. Then read that as "what's the point"?
> >
> > Lee
> >
> It does go in the Kernel. The files are all kept in
> the directory <KERNEL>/scripts/kconfig/.
> And I changed a little bit the Makefile and the conf.c
> in the <KERNEl>/scrips/kconfig.
>
>
OK, What he meant was: "Make it a as patch to, say, 2.6.14-rc1 and distribute it so that people can download and apply more easily, compared to a bigger tarbala"
cheers,
Masoud

2005-09-15 11:21:43

by Roman Zippel

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Hi,

On Wed, 14 Sep 2005, Ahmad Reza Cheraghi wrote:

> I wrote this Framework for making a .config based on
> the System Hardwares. It would be a great help if some
> people would give me their opinion about it.

How interested are you in finishing this project?
I'm asking because the major part is still ahead of you and I'm not sure
how much further you want to take it take it beyond your university
project.

The basic problem is that maintaining the bulk of autoconfig information
in a separate file is not feasible, it would be a nightmare to maintain.
This means it would be better to integrate this information into Kconfig
and define interface so that external program/scripts (preferably shell
instead of perl) can use that to configure the kernel.

A simple example could look like this:

config FOO
bool "foo"
def_auto y

Internally this would become:

config FOO
bool "foo" if !AUTO_CONFIG
default y if AUTO_CONFIG

AUTO_CONFIG could also be used to ask some simple questions for things
that can't be automatically configured and these answers can be used to
adjust other parameters, e.g.:

config AUTO_SERVER
bool "Configure for a server"
depends on AUTO_CONFIG

config BAR
bool "blah"
def_auto AUTO_SERVER

Driver configuration might look something like this:

module foo
tristate "foo support"

Kconfig would generate a config symbol FOO and a Makefile entry for this.
Autoconfiguration could now either look like this:

module foo
pci_map VENDOR DEVICE [...]

or we just an option and extract the data from the source:

module foo
option pci

In either case Kconfig would feed this data an to external program which
matches it with the existing data and returns the matching config symbols
(the matching process would be pretty much like what hotplug already
does).

As you can see a proper integration would require a bit of work, I can
help with Kconfig related parts, but it needs integration into several
systems. The end result would be much more useful. Instead of maintaining
another file, the data is shared and automatically updated by the relevant
system.

bye, Roman

2005-09-15 12:03:38

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Hi,

Roman Zippel wrote:
>
> The basic problem is that maintaining the bulk of autoconfig information
> in a separate file is not feasible, it would be a nightmare to maintain.
> This means it would be better to integrate this information into Kconfig
> and define interface so that external program/scripts (preferably shell
> instead of perl) can use that to configure the kernel.
>
> A simple example could look like this:
>
> config FOO
> bool "foo"
> def_auto y

Why not directly having a direct reference to the name of the script ?

config FOO
bool "foo"
auto "detect-foo-script"

Where you have a specific directory in scripts/autoconfig/ where you
store the scripts. Each script output y, n or m.

But, it means a hell of scripts (except if we can pass arguments in the
auto field: auto "detect-foo-script card-XYZ release-32-or-higher").

This scheme seems much simpler to me (and yet not restrictive at all).
Of course, each script might have to ask few questions to the user as:
Do you want this FOO support ? [y/m/n]:

Or (when no module option):
Do you want this FOO support ? [y/n]:

When the feature is not detected or no field "auto" is found, the
feature is simply skipped silently.

I think this way is minimizing the foot print on the code and yet is
quite powerful. Moreover, you can add the auto-detection scripts without
interfering with the rest of the building system. The target autoconfig
will just be more and more efficient as long as more scripts are added.

Regards
--
Emmanuel Fleury

Assistant Professor | Office: B1-201
Computer Science Department, | Phone: +45 96 35 72 23
Aalborg University, | Mobile: +45 26 22 98 03
Fredriks Bajersvej 7E, | E-mail: [email protected]
9220 Aalborg East, Denmark | URL: http://www.cs.aau.dk/~fleury

2005-09-15 13:02:11

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Emmanuel Fleury <[email protected]> wrote:

> Hi,
>
> Roman Zippel wrote:
> >
> > The basic problem is that maintaining the bulk of
> autoconfig information
> > in a separate file is not feasible, it would be a
> nightmare to maintain.
> > This means it would be better to integrate this
> information into Kconfig
> > and define interface so that external
> program/scripts (preferably shell
> > instead of perl) can use that to configure the
> kernel.
> >
> > A simple example could look like this:
> >
> > config FOO
> > bool "foo"
> > def_auto y
>
> Why not directly having a direct reference to the
> name of the script ?
>
> config FOO
> bool "foo"
> auto "detect-foo-script"
>
> Where you have a specific directory in
> scripts/autoconfig/ where you
> store the scripts. Each script output y, n or m.
>
> But, it means a hell of scripts (except if we can
> pass arguments in the
> auto field: auto "detect-foo-script card-XYZ
> release-32-or-higher").

To pass argument it is not a problem we do it like we
passed the rules in the rules_list(see the function
exec_rule in auto_conf.c ). The lex parser has to be
expanded in that way that it gives everything written
after "auto" to the autoconfig.

config FOO
bool "foo"
auto "detect-foo-script"

So the new programm will work like that:

It goes through are the Kconfig as usual. For any
Option that doesn't have any "auto" a '\n' will be
given. If there is an "auto" it will execute the
script that is written after it. I think it might work
like that. Any suggestion??

> This scheme seems much simpler to me (and yet not
> restrictive at all).
> Of course, each script might have to ask few
> questions to the user as:
> Do you want this FOO support ? [y/m/n]:
>
> Or (when no module option):
> Do you want this FOO support ? [y/n]:

If the script want to ask some question, what will be
the difference if we write make config.

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

2005-09-15 13:03:41

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Emmanuel Fleury <[email protected]> wrote:

> Hi,
>
> Roman Zippel wrote:
> >
> > The basic problem is that maintaining the bulk of
> autoconfig information
> > in a separate file is not feasible, it would be a
> nightmare to maintain.
> > This means it would be better to integrate this
> information into Kconfig
> > and define interface so that external
> program/scripts (preferably shell
> > instead of perl) can use that to configure the
> kernel.
> >
> > A simple example could look like this:
> >
> > config FOO
> > bool "foo"
> > def_auto y
>
> Why not directly having a direct reference to the
> name of the script ?
>
> config FOO
> bool "foo"
> auto "detect-foo-script"
>
> Where you have a specific directory in
> scripts/autoconfig/ where you
> store the scripts. Each script output y, n or m.
>
> But, it means a hell of scripts (except if we can
> pass arguments in the
> auto field: auto "detect-foo-script card-XYZ
> release-32-or-higher").

To pass argument it is not a problem we do it like we
passed the rules in the rules_list(see the function
exec_rule in auto_conf.c ). The lex parser has to be
expanded in that way that it gives everything written
after "auto" to the autoconfig.

config FOO
bool "foo"
auto "detect-foo-script"

So the new programm will work like that:

It goes through are the Kconfig as usual. For any
Option that doesn't have any "auto" a '\n' will be
given. If there is an "auto" it will execute the
script that is written after it. I think it might work
like that. Any suggestion??

> This scheme seems much simpler to me (and yet not
> restrictive at all).
> Of course, each script might have to ask few
> questions to the user as:
> Do you want this FOO support ? [y/m/n]:
>
> Or (when no module option):
> Do you want this FOO support ? [y/n]:

If the script want to ask some question, what will be
the difference if we write make config.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005-09-15 13:29:45

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Ahmad Reza Cheraghi wrote:
>
> If the script want to ask some question, what will be
> the difference if we write make config.

The main difference will be that the options without "auto" flag
or where the script said "n" will be skipped.

It will reduce quite considerably the number of questions.

The algorithm is quite simple:

If (no "auto" field) ---> go for the default

If ("auto" field) --->
script gives n ---> go for "n"
script gives y ---> ask for [y/n]
script gives y/m --> ask for [y/m/n]

That's all folks...

Regards
--
Emmanuel Fleury

Assistant Professor | Office: B1-201
Computer Science Department, | Phone: +45 96 35 72 23
Aalborg University, | Mobile: +45 26 22 98 03
Fredriks Bajersvej 7E, | E-mail: [email protected]
9220 Aalborg East, Denmark | URL: http://www.cs.aau.dk/~fleury

2005-09-15 14:59:00

by Nix

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On 15 Sep 2005, David Lang yowled:
> 5. once kmem and mem can be made read-only there is a security
> advantage in not having kernel modules available (yes the machine can
> be rebooted into a new kernel, but that's easier to detect then a
> module getting loaded)

Here, have a small patch (against 2.6.12.x, but easily forward-portable)
that eliminates that advantage:

diff -durN linux-2.6.12.1-seal-orig/include/linux/kernel.h linux-2.6.12.1-seal/include/linux/kernel.h
--- linux-2.6.12.1-seal-orig/include/linux/kernel.h 2005-06-27 19:28:54.000000000 +0100
+++ linux-2.6.12.1-seal/include/linux/kernel.h 2005-06-27 22:21:48.000000000 +0100
@@ -165,6 +165,9 @@
extern int tainted;
extern const char *print_tainted(void);
extern void add_taint(unsigned);
+#ifdef CONFIG_MODULE_SEAL
+extern int module_seal;
+#endif

/* Values used for system_state */
extern enum system_states {
diff -durN linux-2.6.12.1-seal-orig/include/linux/sysctl.h linux-2.6.12.1-seal/include/linux/sysctl.h
--- linux-2.6.12.1-seal-orig/include/linux/sysctl.h 2005-06-27 19:28:57.000000000 +0100
+++ linux-2.6.12.1-seal/include/linux/sysctl.h 2005-06-27 22:26:12.000000000 +0100
@@ -136,6 +136,7 @@
KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
KERN_RANDOMIZE=68, /* int: randomize virtual address space */
+ KERN_MODULE_SEAL=69, /* int: module loading forbidden */
};

@@ -801,6 +802,8 @@
void __user *, size_t *, loff_t *);
extern int proc_dointvec_bset(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
+extern int proc_dointvec_seal(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
diff -durN linux-2.6.12.1-seal-orig/init/Kconfig linux-2.6.12.1-seal/init/Kconfig
--- linux-2.6.12.1-seal-orig/init/Kconfig 2005-06-27 19:28:59.000000000 +0100
+++ linux-2.6.12.1-seal/init/Kconfig 2005-06-27 22:21:49.000000000 +0100
@@ -463,6 +463,16 @@
the version). With this option, such a "srcversion" field
will be created for all modules. If unsure, say N.

+config MODULE_SEAL
+ bool "Module sealing support"
+ depends on MODULES && PROC_FS
+ help
+ This option provides a file /proc/sys/kernel/module_seal,
+ initially containing the value 0. If it is set to a non-zero
+ value, all module loading and unloading will be prohibited
+ until the next reboot: further changes to the flag will be
+ ignored.
+
config KMOD
bool "Automatic kernel module loading"
depends on MODULES
diff -durN linux-2.6.12.1-seal-orig/kernel/module.c linux-2.6.12.1-seal/kernel/module.c
--- linux-2.6.12.1-seal-orig/kernel/module.c 2005-06-27 19:28:59.000000000 +0100
+++ linux-2.6.12.1-seal/kernel/module.c 2005-06-27 22:21:49.000000000 +0100
@@ -49,6 +49,10 @@
#define ARCH_SHF_SMALL 0
#endif

+#ifdef CONFIG_MODULE_SEAL
+int module_seal = 0;
+#endif
+
/* If this is set, the section belongs in the init part of the module */
#define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))

@@ -1765,6 +1769,12 @@
if (!capable(CAP_SYS_MODULE))
return -EPERM;

+#ifdef CONFIG_MODULE_SEAL
+ /* Must not be sealed */
+ if (module_seal)
+ return -EPERM;
+#endif
+
/* Only one module load at a time, please */
if (down_interruptible(&module_mutex) != 0)
return -EINTR;
diff -durN linux-2.6.12.1-seal-orig/kernel/sysctl.c linux-2.6.12.1-seal/kernel/sysctl.c
--- linux-2.6.12.1-seal-orig/kernel/sysctl.c 2005-06-27 19:29:00.000000000 +0100
+++ linux-2.6.12.1-seal/kernel/sysctl.c 2005-06-27 22:21:49.000000000 +0100
@@ -589,6 +589,16 @@
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+#ifdef CONFIG_MODULE_SEAL
+ {
+ .ctl_name = KERN_MODULE_SEAL,
+ .procname = "module_seal",
+ .data = &module_seal,
+ .maxlen = sizeof(int),
+ .mode = 0600,
+ .proc_handler = &proc_dointvec_seal,
+ },
+#endif
{
.ctl_name = KERN_PRINTK_RATELIMIT,
.procname = "printk_ratelimit",
@@ -1663,6 +1673,22 @@
do_proc_dointvec_bset_conv,&op);
}

+#ifdef CONFIG_MODULE_SEAL
+/*
+ * You can't change the seal unless it's zero.
+ */
+
+int proc_dointvec_seal(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ if (module_seal != 0) {
+ return -EPERM;
+ }
+
+ return do_proc_dointvec(table,write,filp,buffer,lenp,ppos,NULL,NULL);
+}
+#endif
+
struct do_proc_dointvec_minmax_conv_param {
int *min;
int *max;

--
`One cannot, after all, be expected to read every single word
of a book whose author one wishes to insult.' --- Richard Dawkins

2005-09-15 17:09:00

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005, Nix wrote:

> On 15 Sep 2005, David Lang yowled:
>> 5. once kmem and mem can be made read-only there is a security
>> advantage in not having kernel modules available (yes the machine can
>> be rebooted into a new kernel, but that's easier to detect then a
>> module getting loaded)
>
> Here, have a small patch (against 2.6.12.x, but easily forward-portable)
> that eliminates that advantage:

it's still easier to say 'don't use modules' then it is to make sure you
wait until the right time to seal the modules (remember that the current
hotplug is asyncronous so you don't have any good way to know that it's
finished detecting everything and loading all the modules it will need to)

David Lang

> diff -durN linux-2.6.12.1-seal-orig/include/linux/kernel.h linux-2.6.12.1-seal/include/linux/kernel.h
> --- linux-2.6.12.1-seal-orig/include/linux/kernel.h 2005-06-27 19:28:54.000000000 +0100
> +++ linux-2.6.12.1-seal/include/linux/kernel.h 2005-06-27 22:21:48.000000000 +0100
> @@ -165,6 +165,9 @@
> extern int tainted;
> extern const char *print_tainted(void);
> extern void add_taint(unsigned);
> +#ifdef CONFIG_MODULE_SEAL
> +extern int module_seal;
> +#endif
>
> /* Values used for system_state */
> extern enum system_states {
> diff -durN linux-2.6.12.1-seal-orig/include/linux/sysctl.h linux-2.6.12.1-seal/include/linux/sysctl.h
> --- linux-2.6.12.1-seal-orig/include/linux/sysctl.h 2005-06-27 19:28:57.000000000 +0100
> +++ linux-2.6.12.1-seal/include/linux/sysctl.h 2005-06-27 22:26:12.000000000 +0100
> @@ -136,6 +136,7 @@
> KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
> KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
> KERN_RANDOMIZE=68, /* int: randomize virtual address space */
> + KERN_MODULE_SEAL=69, /* int: module loading forbidden */
> };
>
>
> @@ -801,6 +802,8 @@
> void __user *, size_t *, loff_t *);
> extern int proc_dointvec_bset(ctl_table *, int, struct file *,
> void __user *, size_t *, loff_t *);
> +extern int proc_dointvec_seal(ctl_table *table, int write, struct file *filp,
> + void __user *buffer, size_t *lenp, loff_t *ppos);
> extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
> void __user *, size_t *, loff_t *);
> extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
> diff -durN linux-2.6.12.1-seal-orig/init/Kconfig linux-2.6.12.1-seal/init/Kconfig
> --- linux-2.6.12.1-seal-orig/init/Kconfig 2005-06-27 19:28:59.000000000 +0100
> +++ linux-2.6.12.1-seal/init/Kconfig 2005-06-27 22:21:49.000000000 +0100
> @@ -463,6 +463,16 @@
> the version). With this option, such a "srcversion" field
> will be created for all modules. If unsure, say N.
>
> +config MODULE_SEAL
> + bool "Module sealing support"
> + depends on MODULES && PROC_FS
> + help
> + This option provides a file /proc/sys/kernel/module_seal,
> + initially containing the value 0. If it is set to a non-zero
> + value, all module loading and unloading will be prohibited
> + until the next reboot: further changes to the flag will be
> + ignored.
> +
> config KMOD
> bool "Automatic kernel module loading"
> depends on MODULES
> diff -durN linux-2.6.12.1-seal-orig/kernel/module.c linux-2.6.12.1-seal/kernel/module.c
> --- linux-2.6.12.1-seal-orig/kernel/module.c 2005-06-27 19:28:59.000000000 +0100
> +++ linux-2.6.12.1-seal/kernel/module.c 2005-06-27 22:21:49.000000000 +0100
> @@ -49,6 +49,10 @@
> #define ARCH_SHF_SMALL 0
> #endif
>
> +#ifdef CONFIG_MODULE_SEAL
> +int module_seal = 0;
> +#endif
> +
> /* If this is set, the section belongs in the init part of the module */
> #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
>
> @@ -1765,6 +1769,12 @@
> if (!capable(CAP_SYS_MODULE))
> return -EPERM;
>
> +#ifdef CONFIG_MODULE_SEAL
> + /* Must not be sealed */
> + if (module_seal)
> + return -EPERM;
> +#endif
> +
> /* Only one module load at a time, please */
> if (down_interruptible(&module_mutex) != 0)
> return -EINTR;
> diff -durN linux-2.6.12.1-seal-orig/kernel/sysctl.c linux-2.6.12.1-seal/kernel/sysctl.c
> --- linux-2.6.12.1-seal-orig/kernel/sysctl.c 2005-06-27 19:29:00.000000000 +0100
> +++ linux-2.6.12.1-seal/kernel/sysctl.c 2005-06-27 22:21:49.000000000 +0100
> @@ -589,6 +589,16 @@
> .mode = 0644,
> .proc_handler = &proc_dointvec,
> },
> +#ifdef CONFIG_MODULE_SEAL
> + {
> + .ctl_name = KERN_MODULE_SEAL,
> + .procname = "module_seal",
> + .data = &module_seal,
> + .maxlen = sizeof(int),
> + .mode = 0600,
> + .proc_handler = &proc_dointvec_seal,
> + },
> +#endif
> {
> .ctl_name = KERN_PRINTK_RATELIMIT,
> .procname = "printk_ratelimit",
> @@ -1663,6 +1673,22 @@
> do_proc_dointvec_bset_conv,&op);
> }
>
> +#ifdef CONFIG_MODULE_SEAL
> +/*
> + * You can't change the seal unless it's zero.
> + */
> +
> +int proc_dointvec_seal(ctl_table *table, int write, struct file *filp,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> +{
> + if (module_seal != 0) {
> + return -EPERM;
> + }
> +
> + return do_proc_dointvec(table,write,filp,buffer,lenp,ppos,NULL,NULL);
> +}
> +#endif
> +
> struct do_proc_dointvec_minmax_conv_param {
> int *min;
> int *max;
>
>
> --
> `One cannot, after all, be expected to read every single word
> of a book whose author one wishes to insult.' --- Richard Dawkins
>

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-15 19:34:28

by Chris White

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thursday 15 September 2005 18:56, Ahmad Reza Cheraghi wrote:

> > How about networking options? It can detect what
> > protocols are needed?
> > Filesystems?
>
> The Network option or the Filesystes are choosen as a
> Standard. So it will be there without checking if they
> needed or not. Because I think Protocols like TCP-IP
> or Filesystems like NTFS or expt2 has to be installed
> on the now days Systems. But if they are any
> suggestion or ideas of detecting those thing. No
> problem just send me rule that does that and I will
> updated easily on the Framework.Thats the benefit of
> this Framework.;-)

Couldn't one pull up info from /etc/fstab for filesystems? And if it was
network mounts, the appropriate configuration file? I wonder how viable that
would be. As far as network protocols, who knows...

Chris White

Attachments:

(No filename) (836.00 B)
(No filename) (189.00 B)
Download all attachments

2005-09-15 20:37:00

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005 15:58:38 BST, Nix said:
> On 15 Sep 2005, David Lang yowled:
> > 5. once kmem and mem can be made read-only there is a security
> > advantage in not having kernel modules available (yes the machine can
> > be rebooted into a new kernel, but that's easier to detect then a
> > module getting loaded)
>
> Here, have a small patch (against 2.6.12.x, but easily forward-portable)
> that eliminates that advantage:

Two comments:

1) This patch is pointless without other kernel magic to guarantee that
even root can't open /dev/kmem - either SELinux and/or the 'devmem.patch'
that's in current Fedora kernels. There's well-known ways to do the equivalent of
an insmod even if the kernel is built with 'CONFIG_MODULES=n'.

2) Guess it's time to re-post my sysctl patch to provide a general-purpose
one-shot... (Diffed against 2.6.11-mm4, but applies cleanly to 2.6.13-mm1 as well).

--- cut here for patch

Quite often, we see re-inventions of "allow a sysctl until/unless a given
flag is set to zero/one". The following code implements a general-purpose
one-shot facility to assist in building such "lockdown/jail" modes.

Usage: In a sysctl definition, we use something like:

int security_enable = 1;
int security_myflag = 0;

{
.ctl_name = ,
.procname = "myflag",
.data = &security_myflag,
.maxlen = sizeof(security_myflag),
.mode = 0644,
.proc_handler = &proc_dointvec_gated,
.extra1 = &security_enable,
},
{
.ctl_name = ,
.procname = "security_lock",
.data = &security_enable,
.maxlen = sizeof(security_enable),
.mode = 0644,
.proc_handler = &proc_dointvec_gated,
.extra1 = &security_enable,
}

Writes to myflag are allowed until a 0 is written to security_lock, at
which point both myflag and security_lock go read-only...

Signed-off-by: <[email protected]>

--- linux-2.6.11-mm4/include/linux/sysctl.h.sysctl 2005-03-17 02:16:12.000000000 -0500
+++ linux-2.6.11-mm4/include/linux/sysctl.h 2005-03-17 02:17:02.000000000 -0500
@@ -798,6 +798,8 @@ extern int proc_dointvec(ctl_table *, in
void __user *, size_t *, loff_t *);
extern int proc_dointvec_bset(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
+extern int proc_dointvec_gated(ctl_table *, int, struct file *,
+ void __user *, size_t *, loff_t *);
extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
--- linux-2.6.11-mm4/kernel/sysctl.c.sysctl 2005-03-17 02:16:14.000000000 -0500
+++ linux-2.6.11-mm4/kernel/sysctl.c 2005-03-17 02:17:02.000000000 -0500
@@ -16,6 +16,7 @@
* Wendling.
* The list_for_each() macro wasn't appropriate for the sysctl loop.
* Removed it and replaced it with older style, 03/23/00, Bill Wendling
+ * Added proc_dointvec_gated, 06/14/04, Valdis Kletnieks
*/

#include <linux/config.h>
@@ -1693,6 +1694,37 @@ static int do_proc_dointvec_minmax_conv(
}

/**
+ * proc_dointvec_gated - read a vector of integers only if a specified flag
+ * word is non-zero
+ * @table: the sysctl table
+ * @write: %TRUE if this is a write to the sysctl file
+ * @filp: the file structure
+ * @buffer: the user buffer
+ * @lenp: the size of the user buffer
+ *
+ * Reads/writes up to table->maxlen/sizeof(unsigned int) integer
+ * values from/to the user buffer, treated as an ASCII string.
+ *
+ * This is identical to proc_dointvec, except that we additionally
+ * check that the location pointed to by table->extra1 is non-zero
+ * (useful for creating a 'lockdown' sysctl that allows setting of
+ * the variable only until some specified condition is fulfilled).
+ *
+ * Returns 0 on success.
+ */
+int proc_dointvec_gated(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ int *flag = (int *) (table->extra1);
+ if (write && flag && !(*flag)) {
+ return -EPERM;
+ }
+ return do_proc_dointvec(table, write, filp, buffer, lenp, ppos,
+ do_proc_dointvec_conv, NULL);
+}
+
+
+/**
* proc_dointvec_minmax - read a vector of integers with min/max values
* @table: the sysctl table
* @write: %TRUE if this is a write to the sysctl file

Attachments:

(No filename) (226.00 B)

2005-09-15 20:51:06

by Nix

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On Thu, 15 Sep 2005, Valdis Kletnieks murmured woefully:
> 1) This patch is pointless without other kernel magic to guarantee that
> even root can't open /dev/kmem - either SELinux and/or the 'devmem.patch'
> that's in current Fedora kernels. There's well-known ways to do the equivalent of
> an insmod even if the kernel is built with 'CONFIG_MODULES=n'.

Agreed; I use it in conjunction with a one-liner to remove CAP_RAWIO
from the capability bounding set.

> 2) Guess it's time to re-post my sysctl patch to provide a general-purpose
> one-shot... (Diffed against 2.6.11-mm4, but applies cleanly to 2.6.13-mm1 as well).

Yes, much nicer. (My goal, to get a better patch by posting my ugly one,
is achieved! ;) )

--
`One cannot, after all, be expected to read every single word
of a book whose author one wishes to insult.' --- Richard Dawkins

2005-09-15 20:58:44

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Daniel Thaler <[email protected]> wrote:

> Lee Revell wrote:
> > Why does this have to be in the kernel again?
> Isn't this exactly what
> > you get with a fully modular config and hotplug?
>
> It doesn't go in the kernel. If I understand
> correctly, it's a script that is
> invoked by 'make autoconfig'. Note that I didn't
> read the patch, because it's a
> .tgz on a website and I couldn't be bothered to
> download it.

Since im a new Bee, I didn't know that I patched
shouldnt be tgz. So here is a new patch as URL and
attachment.
The URL :
http://www.energyparty.de/ahmad/autoconfig.patch

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Attachments:

autoconfig.patch (69.47 kB)
1146041466-autoconfig.patch

2005-09-15 21:04:07

by Jesper Juhl

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On 9/15/05, Ahmad Reza Cheraghi <[email protected]> wrote:
> --- Daniel Thaler <[email protected]> wrote:
>
> > Lee Revell wrote:
> > > Why does this have to be in the kernel again?
> > Isn't this exactly what
> > > you get with a fully modular config and hotplug?
> >
> > It doesn't go in the kernel. If I understand
> > correctly, it's a script that is
> > invoked by 'make autoconfig'. Note that I didn't
> > read the patch, because it's a
> > .tgz on a website and I couldn't be bothered to
> > download it.
>
> Since im a new Bee, I didn't know that I patched
> shouldnt be tgz. So here is a new patch as URL and
> attachment.

Normally patches are just send inline in the email, as plain text.
This makes them easy to quote when you want to reply with feedback.

> The URL :
> http://www.energyparty.de/ahmad/autoconfig.patch
>

Not Found
The requested URL /ahmad/autoconfig.patch was not found on this server.

--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

2005-09-16 07:14:04

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Chris White wrote:
>
> Couldn't one pull up info from /etc/fstab for filesystems? And if it was
> network mounts, the appropriate configuration file? I wonder how viable that
> would be. As far as network protocols, who knows...

I guess the /etc/mtab is more trustable. But, you not anymore speaking
about hardware detection here... I think that everything which is beyond
hardware detection is purely magic and shouldn't be trusted because for
one type of detection if it fit few users, it won't fit many.

And anyway, in the case you are considering, make oldconfig is probably
the one to use.

Regards
--
Emmanuel Fleury

I think there is a world market for maybe five computers.
-- Thomas Watson, chairman of IBM, 1943

2005-09-16 08:11:51

by Coywolf Qi Hunt

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

On 9/15/05, Ahmad Reza Cheraghi <[email protected]> wrote:
> Hi
>
> I wrote this Framework for making a .config based on
> the System Hardwares. It would be a great help if some
> people would give me their opinion about it.
>
> Regards
>
> A.R.Cheraghi
>

How about the idea that we have a .hwconfig file and we do `make
hwconfig' to generate it? So normal filesystems and network stack
stuff don't belong to hwconfig.

.hwconfig file merely stores the result from auto hardware detection.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

2005-09-16 08:21:35

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Coywolf Qi Hunt wrote:
>
> How about the idea that we have a .hwconfig file and we do `make
> hwconfig' to generate it? So normal filesystems and network stack
> stuff don't belong to hwconfig.
>
> .hwconfig file merely stores the result from auto hardware detection.

Well, at the end you just want to have one .config file with everything
inside. If I follow your logic we also should have a .fsconfig, a
.netconfig, a .audioconfig, ... and so on.

So, working on the .config seems nice to me.

Simplicity is good ! ^_^

Regards
--
Emmanuel Fleury

A child of five could understand this. Fetch me a child of five.
-- Groucho Marx

2005-09-16 08:32:07

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

--- Emmanuel Fleury <[email protected]> wrote:

> Coywolf Qi Hunt wrote:
> >
> > How about the idea that we have a .hwconfig file
> and we do `make
> > hwconfig' to generate it? So normal filesystems
> and network stack
> > stuff don't belong to hwconfig.
> >
> > .hwconfig file merely stores the result from auto
> hardware detection.
>
> Well, at the end you just want to have one .config
> file with everything
> inside. If I follow your logic we also should have a
> .fsconfig, a
> .netconfig, a .audioconfig, ... and so on.
>
> So, working on the .config seems nice to me.
>
> Simplicity is good ! ^_^
>
Yes thats true. It will be a hard also, for those
Users which doesn't have that much experience for the
configuration of a Kernel.

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

2005-09-16 08:52:09

[permalink] [raw]

Subject: Re: Automatic Configuration of a Kernel

Ahmad, as far as I understood, your spirit is more or less to:

- Drop automagically all the hardware which is for sure NOT here
- Propose to the user to include the hardware which is detected
- Leave as default the rest of the choices
(i.e. the choices that might be uncertain: fs, protocols, ...)

Therefore, "make autoconfig" is a quick first run through the .config
with the help of all the scripts stored in scripts/autoconfig/.

Regards
--
Emmanuel Fleury

Step #1 in programming: understand people.
-- Linus Torvalds

2005-09-16 09:19:04