[opensuse-kernel] Some thoughts about 'heavy' kernels...
Hi, Some filosophy.... Maybe i do not make any sense at all, but i am thinking on this for a long time now. When inspecting a hardware system, before installation, communication is going on between hardware detection and all devices on the board, to find out which drivers are needed, to ensure optimal working of the machine with the os. This image, of 'what' exactly is in the particular system, is the template to start the machine and the os, to look at the list of modules to be started. ToDo list. My thought is that what is nessesary should be there, but what is not needed, should not be. So the 'image', can be used to start-up the system, without looking for everything, if it is still there, because it 'knows' everything is there, because why would that change, but if it does, a hardware config module would be handy, to start hardware detection, of to 'mention' the device manualy. (i am not talking about hotplugging devices, but another video-card, or soundcard, or a pcie-usb card, something like that.) This way, a very light startupfile would be able to start up the system, which would save an oughfull lot of actual startup time. This eeepc901 has usb dvd-drive. Startup 'waits' for the device, whetter it is plugged in or not. Why would it wait if it knew the drive was not plugged in? (in this case, to boot from another device would be activated by pressing esc, during first startup, before/during bios invoke screen..) So there is two things: 1) hardware that is 'allways' around, and 2) hotplugging devices. Checking the usb-busses, and other removable cardbusses are checked, and expected to find something connected. After a few boots, software can 'know' the routine of what is used to power-up. To install, all modules need to be present, but only those needed, have to be installed. That is what i actualy mean. Not carry load, that is not needed. The os logs. It can know which apps are used, and which not. It can unload those, that are never used, and started manualy when nessesary, if instructed to do so. This 'tuning' cannot be done by regular users without extensive study, but the os can and should know, and act accordingly. Sophistcated software serves the user, as best as it can. -- Have a nice day ;) Oddball aka M9. OS: Linux 2.6.29-56-default i686 Huidige gebruiker: oddball@EEEPC-901-ROB Systeem: openSUSE 11.1 (i586) KDE: 4.2.2 (KDE 4.2.2) "release 110" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oddball wrote:
Hi,
Some filosophy....
Maybe i do not make any sense at all, but i am thinking on this for a long time now.
When inspecting a hardware system, before installation, communication is going on between hardware detection and all devices on the board, to find out which drivers are needed, to ensure optimal working of the machine with the os. This image, of 'what' exactly is in the particular system, is the template to start the machine and the os, to look at the list of modules to be started. ToDo list.
My thought is that what is nessesary should be there, but what is not needed, should not be.
So the 'image', can be used to start-up the system, without looking for everything, if it is still there, because it 'knows' everything is there, because why would that change, but if it does, a hardware config module would be handy, to start hardware detection, of to 'mention' the device manualy. (i am not talking about hotplugging devices, but another video-card, or soundcard, or a pcie-usb card, something like that.)
This way, a very light startupfile would be able to start up the system, which would save an oughfull lot of actual startup time.
This eeepc901 has usb dvd-drive. Startup 'waits' for the device, whetter it is plugged in or not. Why would it wait if it knew the drive was not plugged in? (in this case, to boot from another device would be activated by pressing esc, during first startup, before/during bios invoke screen..)
So there is two things: 1) hardware that is 'allways' around, and 2) hotplugging devices. Checking the usb-busses, and other removable cardbusses are checked, and expected to find something connected.
After a few boots, software can 'know' the routine of what is used to power-up.
To install, all modules need to be present, but only those needed, have to be installed. That is what i actualy mean. Not carry load, that is not needed. The os logs. It can know which apps are used, and which not. It can unload those, that are never used, and started manualy when nessesary, if instructed to do so.
This 'tuning' cannot be done by regular users without extensive study, but the os can and should know, and act accordingly.
Sophistcated software serves the user, as best as it can.
I think there might be a misunderstanding on how device discovery actually works. During installation, there's a bit of poking around, but that's not how the kernel does device discovery. The kernel doesn't look for e.g. a new video card - it goes down the busses, enumerates what's there, and issues events to userspace to load the appropriate drivers for that hardware. The boot process only loads drivers for common hardware for which there isn't any autodiscovery, like cpufreq. So, for example, if you booted initially with a USB hub and a lot of devices attached to it - if the hub isn't there, it's not going to go out looking for those devices. It'll stop on the last bus. Loading a specific set of drivers unconditionally might speed things up negligibly since it won't need to call out to udev, but the kernel still needs to enumerate all the buses on the system to actually bind the driver to a specific device, and then call out to userspace again. The modules are present on disk, but they're not actually loaded if they're not used. So, yes, they do take up disk space but they don't actually affect the system at runtime otherwise. That said, for a truly minimal system like Jan mentioned with JeOS, that's not what you want either. There are core modules that will nearly always be used like TCP/IP, the SCSI layer, etc, but some of the more esoteric devices and protocol could probably be split out into smaller packages that can be uninstalled easily. Bear in mind that openSUSE is a general purpose OS and we want to make it work as expected for as many users as we can. If someone new to Linux buys some device and plugs it in, it should work without being prompted to install additional drivers. Making it possible for advanced users to remove things they don't want shouldn't sacrifice the ease of use for beginners. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknWTMwACgkQLPWxlyuTD7IJvwCgolVAziWhX5IBCU+T1PvRmyOY lvkAoI911tOFQqGJRk/ajeLsFvwh2Q7v =lKtY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney schreef:
Oddball wrote:
Hi,
Some filosophy....
Maybe i do not make any sense at all, but i am thinking on this for a long time now.
When inspecting a hardware system, before installation, communication is going on between hardware detection and all devices on the board, to find out which drivers are needed, to ensure optimal working of the machine with the os. This image, of 'what' exactly is in the particular system, is the template to start the machine and the os, to look at the list of modules to be started. ToDo list.
My thought is that what is nessesary should be there, but what is not needed, should not be.
So the 'image', can be used to start-up the system, without looking for everything, if it is still there, because it 'knows' everything is there, because why would that change, but if it does, a hardware config module would be handy, to start hardware detection, of to 'mention' the device manualy. (i am not talking about hotplugging devices, but another video-card, or soundcard, or a pcie-usb card, something like that.)
This way, a very light startupfile would be able to start up the system, which would save an oughfull lot of actual startup time.
This eeepc901 has usb dvd-drive. Startup 'waits' for the device, whetter it is plugged in or not. Why would it wait if it knew the drive was not plugged in? (in this case, to boot from another device would be activated by pressing esc, during first startup, before/during bios invoke screen..)
So there is two things: 1) hardware that is 'allways' around, and 2) hotplugging devices. Checking the usb-busses, and other removable cardbusses are checked, and expected to find something connected.
After a few boots, software can 'know' the routine of what is used to power-up.
To install, all modules need to be present, but only those needed, have to be installed. That is what i actualy mean. Not carry load, that is not needed. The os logs. It can know which apps are used, and which not. It can unload those, that are never used, and started manualy when nessesary, if instructed to do so.
This 'tuning' cannot be done by regular users without extensive study, but the os can and should know, and act accordingly.
Sophistcated software serves the user, as best as it can.
I think there might be a misunderstanding on how device discovery actually works. During installation, there's a bit of poking around, but that's not how the kernel does device discovery.
The kernel doesn't look for e.g. a new video card - it goes down the busses, enumerates what's there, and issues events to userspace to load the appropriate drivers for that hardware. The boot process only loads drivers for common hardware for which there isn't any autodiscovery, like cpufreq. If it travels the busses, it should find minipciewifi card, how exactly can it be 'un'-ignored?
So, for example, if you booted initially with a USB hub and a lot of devices attached to it - if the hub isn't there, it's not going to go out looking for those devices. It'll stop on the last bus. Loading a specific set of drivers unconditionally might speed things up negligibly since it won't need to call out to udev, but the kernel still needs to enumerate all the buses on the system to actually bind the driver to a specific device, and then call out to userspace again. very clear discription!
The modules are present on disk, but they're not actually loaded if they're not used. So, yes, they do take up disk space but they don't actually affect the system at runtime otherwise. The diskspace is hardly an issue these days... but startup time is.
That said, for a truly minimal system like Jan mentioned with JeOS, that's not what you want either. There are core modules that will nearly always be used like TCP/IP, the SCSI layer, etc, but some of the more esoteric devices and protocol could probably be split out into smaller packages that can be uninstalled easily. why not?
Bear in mind that openSUSE is a general purpose OS and we want to make it work as expected for as many users as we can. If someone new to Linux buys some device and plugs it in, it should work without being prompted to install additional drivers. Making it possible for advanced users to remove things they don't want shouldn't sacrifice the ease of use for beginners.
-Jeff
Thnx for enlightening my vision.. Very open and straightforward attitude btw. The last alinea completely mirrors my vieuw -- Have a nice day ;) Oddball aka M9. OS: Linux 2.6.29-56-default i686 Huidige gebruiker: oddball@EEEPC-901-ROB Systeem: openSUSE 11.1 (i586) KDE: 4.2.2 (KDE 4.2.2) "release 110" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oddball wrote:
Jeff Mahoney schreef:
The kernel doesn't look for e.g. a new video card - it goes down the busses, enumerates what's there, and issues events to userspace to load the appropriate drivers for that hardware. The boot process only loads drivers for common hardware for which there isn't any autodiscovery, like cpufreq. If it travels the busses, it should find minipciewifi card, how exactly can it be 'un'-ignored?
I'm not sure what you mean here. Are you asking about your original wifi problem? If that's the case, there was nothing you could have done short of rebuilding your own kernel with CONFIG_STAGING=y, CONFIG_EXCLUDE_STAGING_FROM_BUILD=n, and enabling the wifi driver in there. That's the change I committed earlier today, so once the KOTD kernels are building again, it will automatically discover it on boot.
That said, for a truly minimal system like Jan mentioned with JeOS, that's not what you want either. There are core modules that will nearly always be used like TCP/IP, the SCSI layer, etc, but some of the more esoteric devices and protocol could probably be split out into smaller packages that can be uninstalled easily. why not?
Mostly just that there aren't enough hours in the day to get everything done. Hopefully the new kernel spec files are easier to work with than they have in the past. If you have an idea of how you'd like it to look, give it a try and post your results here. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknWWSAACgkQLPWxlyuTD7IVWgCfe3eVKW3z83b3H/nObKkqsLrl H7MAni7RUEooflfo/D5Tg/vabSoc1CIT =DCiD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney schreef:
Oddball wrote:
Jeff Mahoney schreef:
The kernel doesn't look for e.g. a new video card - it goes down the busses, enumerates what's there, and issues events to userspace to load the appropriate drivers for that hardware. The boot process only loads drivers for common hardware for which there isn't any autodiscovery, like cpufreq. If it travels the busses, it should find minipciewifi card, how exactly can it be 'un'-ignored?
I'm not sure what you mean here. Are you asking about your original wifi problem? If that's the case, there was nothing you could have done short of rebuilding your own kernel with CONFIG_STAGING=y, CONFIG_EXCLUDE_STAGING_FROM_BUILD=n, and enabling the wifi driver in there. OK that was all i wanted to know here, yes...
That's the change I committed earlier today, so once the KOTD kernels are building again, it will automatically discover it on boot.
Very nice, i look forward to it..
That said, for a truly minimal system like Jan mentioned with JeOS, that's not what you want either. There are core modules that will nearly always be used like TCP/IP, the SCSI layer, etc, but some of the more esoteric devices and protocol could probably be split out into smaller packages that can be uninstalled easily. why not?
Mostly just that there aren't enough hours in the day to get everything done. Hopefully the new kernel spec files are easier to work with than they have in the past. If you have an idea of how you'd like it to look, give it a try and post your results here.
-Jeff
I agree, there are too few hours in a day, and sometimes it looks there are less every day.... I will deepen my vieuw into the kernel, and knowing the previous, it will take the time it takes... Looking forward to the steadily improving kernels.. Would you please be so kind and tell me where to best start to quickly practice kernel building? (quick reference manual, whatever needed to do the actual job, machines and diskspace i have..) -- Enjoy your time around, Oddball (M9.) (Now or never...) OS: Linux 2.6.29-rc8-5-default x86_64 Huidige gebruiker: oddball@AMD64x2-sfn1 Systeem: openSUSE 11.2 Alpha 0 (x86_64) KDE: 4.2.1 (KDE 4.2.1) "release 1" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Oddball schreef:
Would you please be so kind and tell me where to best start to quickly practice kernel building?
I've started with Linux Kernel in a nutshell.... ;) -- Have a nice day ;) Oddball aka M9. OS: Linux 2.6.29-56-default i686 Huidige gebruiker: oddball@EEEPC-901-ROB Systeem: openSUSE 11.1 (i586) KDE: 4.2.2 (KDE 4.2.2) "release 110" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le samedi 04 avril 2009, Oddball a écrit :
Oddball schreef:
Would you please be so kind and tell me where to best start to quickly practice kernel building?
I've started with Linux Kernel in a nutshell.... ;)
Excellent choice, that's a very good book :) -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Jean Delvare -
Jeff Mahoney -
Oddball