[opensuse-factory] Why does MS-Windows need no "initrd-equivalent" in order to boot w/a wider range of x86[-64] compat HW?
Perhaps someone can explain to me why Windows doesn't need a pre-boot ramdisk in order to boot, while Linux does? I know Windows doesn't have all the drivers for all the hardware linked in with it's kernel -- it's dynamically loaded out of it's "/bin (windows/sytem32)" dir. So why does the linux kernel have this extra complication while windows does not? It's a bit embarrassing, I would think to see the wide range of HW supported by Windows **without** a special 'initrd' for drivers, while linux still doesn't support the range of HW that Windows does (some, but not ALL of that being due to short-sited HW providers who can't provide open specs or drivers). So what is Windows doing 'right', that Linux is unable to do? Maybe this is a kernel question -- maybe OpenSuse can't doing anything about this -- is this the case -- is this some kernel limitation? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 28, 2012 at 04:07:28PM -0800, Linda Walsh wrote:
Perhaps someone can explain to me why Windows doesn't need a pre-boot ramdisk in order to boot, while Linux does?
It does need one, and it has one, why do you think it doesn't? Note, this is _way_ off-topic here. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 29, 2012 at 7:23 AM, Greg KH <gregkh@linux.com> wrote:
On Wed, Nov 28, 2012 at 04:07:28PM -0800, Linda Walsh wrote:
Perhaps someone can explain to me why Windows doesn't need a pre-boot ramdisk in order to boot, while Linux does?
It does need one, and it has one, why do you think it doesn't?
Note, this is _way_ off-topic here.
I would not necessarily put it this way. It is always useful to compare technologies and personally I'd love to know more about Windows boot process and what tasks various components performs simply to be able to better help people having multi-boot issues. -andrey -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-29 11:15, Andrey Borzenkov wrote:
On Thu, Nov 29, 2012 at 7:23 AM, Greg KH <gregkh@linux.com> wrote:
On Wed, Nov 28, 2012 at 04:07:28PM -0800, Linda Walsh wrote:
Perhaps someone can explain to me why Windows doesn't need a pre-boot ramdisk in order to boot, while Linux does?
It does need one, and it has one, why do you think it doesn't?
Note, this is _way_ off-topic here.
I would not necessarily put it this way. It is always useful to compare technologies and personally I'd love to know more about Windows boot process and what tasks various components performs simply to be able to better help people having multi-boot issues.
NOT in the factory mail list. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlC3Pi8ACgkQIvFNjefEBxrg2gCfU93Y2QpMTPMxPZseKou26Woz ZQ0AoIQuUQseXEMuryaIbHTx/Cw/oTwT =UKZQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Wed, Nov 28, 2012 at 04:07:28PM -0800, Linda Walsh wrote:
Perhaps someone can explain to me why Windows doesn't need a pre-boot ramdisk in order to boot, while Linux does?
It does need one, and it has one, why do you think it doesn't?
The boot procedure for Windows is documented in the Windows NT internals book. There is no ramdisk that it uses.
Note, this is _way_ off-topic here.
--- Where do you think it would be "on-topic", considering _you_ don't want to hear it in any venue? You know the requirement of an initrd is bull, Claiming windows has one is even worse bullshit than I'd ever give you credit for. You can trace a windows boot -- there is no preload of a memory-resident copy of windows, that then loads windows. The drivers for the hardware are on the disk in /windows/system32/drivers. On Windows, it reads their boot managager, which then loads 'winload' which *demand*-loads drivers and services from disk -- they aren't all bound in to the kernel in order for it too boot. Please read Chapter 13 on Startup and Shutdown of the 5th edition of the Windows Internals book to get straightened out. The only time Windows needs a ramdisk during boot is when the boot-image needs to be downloaded from the net (i.e. a diskless boot). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 29 Nov 2012 17:22:50 -0800 Linda Walsh <suse@tlinx.org> пишет:
You can trace a windows boot -- there is no preload of a memory-resident copy of windows, that then loads windows. The drivers for the hardware are on the disk in /windows/system32/drivers.
On Windows, it reads their boot managager, which then loads 'winload' which *demand*-loads drivers and services from disk -- they aren't all bound in to the kernel in order for it too boot.
To load drivers from \windows\system32\drivers winload needs to include filesystem driver. To be able to read filesystem it must be able to access it first. So either it must include LDM drivers or it must demand that system drive be contained in single partition, even though you converted it to LDM. Functionally intermediate binary that is loaded during boot and includes filesystem and possibly volume manager drivers and logic to load additional drivers on demand is initrd. With the primary difference that initrd supports more than one filesystem, more than one volume manager, places no restrictions on ondisk format, can be used to mount filesystem across networks, can be used to cleanly tear down filesystems during shutdown, ... I definitely forgot something else here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30/11/12 03:17, Andrey Borzenkov wrote:
В Thu, 29 Nov 2012 17:22:50 -0800 Linda Walsh <suse@tlinx.org> пишет:
You can trace a windows boot -- there is no preload of a memory-resident copy of windows, that then loads windows. The drivers for the hardware are on the disk in /windows/system32/drivers.
On Windows, it reads their boot managager, which then loads 'winload' which *demand*-loads drivers and services from disk -- they aren't all bound in to the kernel in order for it too boot.
To load drivers from \windows\system32\drivers winload needs to include filesystem driver.
To be able to read filesystem it must be able to access it first. So either it must include LDM drivers or it must demand that system drive be contained in single partition, even though you converted it to LDM.
Functionally intermediate binary that is loaded during boot and includes filesystem and possibly volume manager drivers and logic to load additional drivers on demand is initrd. With the primary difference that initrd supports more than one filesystem, more than one volume manager, places no restrictions on ondisk format, can be used to mount filesystem across networks, can be used to cleanly tear down filesystems during shutdown, ... I definitely forgot something else here.
Full disk encryption is what you forgot to list! :) It can unlock all your partitions before starting to read from them. That doesn't work without some form of ramdisk. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Peter Hanisch wrote:
Functionally intermediate binary that is loaded during boot and includes filesystem and possibly volume manager drivers and logic to load additional drivers on demand is initrd. With the primary difference that initrd supports more than one filesystem, more than one volume manager, places no restrictions on ondisk format, can be used to mount filesystem across networks, can be used to cleanly tear down filesystems during shutdown, ... I definitely forgot something else here.
You can cleanly tear down FS's w/o initrd, and with lilo, you can support all the file systems. Be careful not to add the limitations of grub -- which needs considerable OS support, to restrictions placed on a disk-boot. In fact, generally, since lilo doesn't go through the file system, file system corruption doesn't create a problem as it would in grub -- and since it doesn't have to follow chains of FS directory and inode lookups, it would also run faster. So you've only pointed out a reason to use initrd is to use a slower and less reliable (though more flexible in some circumstances, that are generally rare), boot manager.
Full disk encryption is what you forgot to list! :) It can unlock all your partitions before starting to read from them. That doesn't work without some form of ramdisk.
Works on windows just fine. Better actually, since if you have full disk encryption -- how can the BIOS read the encrypted boot sector to execute it? (on windows, presuming you are using a HW based encryption). w/sw based, your boot manager has to handle it -- which is likely able to be included in either lilo or grub (or could be)... Anything else you think initrd is needed for when it isn't in windows? Why would linux be crippled compared to windows? Should it be? What does it buy linux? I consistently have more problems booting linux than windows due to ill-tested, incompatible and ongoing mangling of the boot process. This isn't something a professional, corporate supporting company should want under any circumstance, yet it is being fought for out of knee-jerk reactions because it is how it has "always been done" (and because I, a female, am suggesting something different). Heaven forbid a female would have any input into the linux boot process, let alone an outspoken one like me]. How could any woman have any ideas about linux that wouldn't be inferior to anything men come up with? (wasn't going to throw in the last, because it inevitably is seen as whining...but always by those who have vested interests in discounting it -- it's like the "new" revelation about age-bias in silicon valley -- this was known 15 years ago. It's funny how each generation has to rediscover the wheel and truths already known before -- yet thrown away due to institutional Alzheimer's). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 30 Nov 2012 13:10:13 -0800, Linda Walsh <suse@tlinx.org> wrote:
You can cleanly tear down FS's w/o initrd, and with lilo, you can support all the file systems.
You must be joking! Lilo has no support what so ever as it uses block numbers. The drawback is that you have to run lilo everytime you modify or replace the kernel/
Be careful not to add the limitations of grub -- which needs considerable OS support,
Rubbish. Grub has its own file system drivers which are also its achilles heel as you can't boot from filesystems it desn't support.
Heaven forbid a female would have any input into the linux boot process, let alone an outspoken one like me]. How could any woman have any ideas about linux that wouldn't be inferior to anything men come up with?
That's making it too easy by simply discarding all critique as being based on sexism. That totally neglects that there could be other, possibly more prominent reasons why your ideas are rejected. At least I do not care about gender in a discussion (though I very possibly do make gender based decisions without realising) but I *do* care about the way a discussion is made. That's why *I* would argue exactly the same way would you be a man. Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Philipp Thomas wrote:
On Fri, 30 Nov 2012 13:10:13 -0800, Linda Walsh <suse@tlinx.org> wrote:
You can cleanly tear down FS's w/o initrd, and with lilo, you can support all the file systems.
You must be joking! Lilo has no support what so ever as it uses block numbers. The drawback is that you have to run lilo everytime you modify or replace the kernel/
You need to reread what I said. With lilo all the file systems can be supported. I didn't say lilo does anything w/the file systems. I said all can be supported, including the ones Grub doesn't support -- since it uses block numbers directly, no file system drivers are needed.
Be careful not to add the limitations of grub -- which needs considerable OS support,
Rubbish. Grub has its own file system drivers which are also its achilles heel as you can't boot from filesystems it desn't support.
---- It has to considerable OS support -- namely all the drivers for all the file systems you want to support. Unlike, say the kernel which can insert them as needed, if I want to support a new fs, a grub driver has to be written and grub has to be rebuilt. Mirroring your issue above -- every time you add or remove a file system, you have to rebuild grub -- a far more complex task than an automated run of lilo which takes about 1/100th the time as it does to build a kernel. You make it sound like running it is a problem. If you add it as part of your kernel build, you don't have to run it. It simply becomes part of installing a new kernel. If you want to add a new fs, updating grub involves writing or adapting the kernel driver (more OS support). I have have been told people have problems getting grub to use a built-in, text-mode, screen and that it defaults to a frame-buffer requiring basic graphics support. It doesn't seem it is possible to use linux device names, and to get disk-label support, it needs an OS so it can get udev support.
Heaven forbid a female would have any input into the linux boot process, let alone an outspoken one like me. How could any woman have any ideas about linux that wouldn't be inferior to anything men come up with?
That's making it too easy by simply discarding all critique as being based on sexism. That totally neglects that there could be other, possibly more prominent reasons why your ideas are rejected.
I wasn't talking so much about my ideas, specifically, but more the structure of the ideas and how decisions are made. Gender gets used as a 'short-hand' for a host of gender-related issues even though the issue themselves may have no ostensible gender connection. Note: a non-trivial percentage of either gender favors "styles" of the 'opposite' gender, and a majority of either sex is capable of using either. However, the male-centric bias appears stronger in the technical computer arena. Open-source projects seem to be more heavily biased along those lines for various reasons (fewer layers of managers, doc and test writing that tend to to force more retrospection of code and development, as one example). I believe you will find more males used to win/lose discussions and fewer who would be more committed to finding win-win scenarios. Very often I see dominance used to force their ideas down other people's throats: "This is the way we are doing things, get over it", etc... s -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 11, 2012 at 11:36 AM, Linda Walsh <suse@tlinx.org> wrote:
You need to reread what I said. With lilo all the file systems can be supported.
How is it relevant for initrd which you complaint about?
If you want to add a new fs, updating grub involves writing or adapting the kernel driver (more OS support). I have have been told people have problems getting grub to use a built-in, text-mode, screen and that it defaults to a frame-buffer requiring basic graphics support. It doesn't seem it is possible to use linux device names, and to get disk-label support, it needs an OS so it can get udev support.
Again, how all of this is related to initrd or lack thereof? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Andrey Borzenkov
-
Carlos E. R.
-
Greg KH
-
Linda Walsh
-
Peter Hanisch
-
Philipp Thomas