Prev: Packet.dll and which wpcap.dll
Next: Keyboard re-mapping
From: Sidney Lambe on 27 Dec 2009 17:08
On comp.os.linux.setup, Aragorn <aragorn(a)chatfactory.invalid>
wrote:

> On Sunday 27 December 2009 04:43 in comp.os.linux.setup,
> somebody identifying as annalissa wrote...
>
>> Hi all,
>>
>> I have recently rewad in some tutorials that structure/layout
>> of a linux partition is as shown here :-
>>
>> http://i529.photobucket.com/albums/dd339/aarklon/partition.png
>>
>> now is this same layout/structure used for both primary and
>> logical partitions ?
>
> Yes, they have the same layout. The only difference between a
> primary and logical partition is that a primary partition has
> its partition table entries - i.e. the beginning and end of
> the partition - listed in the partition table of the master
> boot record of the hard disk it sits on, while a logical
> partition has its partition table entries listed in an extended
> partition container, which itself is a (special kind of)
> primary partition.
>
> The Linux kernel doesn't care about whether a partition is
> either primary or logical, or whethr it's an LVM logical volume
> for that matter. (Note: LVM "Logical Volume Management") is an
> abstraction layer on top of the existing partitioning layer.)
>
> See, the distinction between primary partitions and logical
> partitions in an extended partition container is a construct of
> the legacy real mode[1] BIOS and of DOS, because originally,
> the IBM PC and all derivative machines did not have (or
> support) hard disks, and DOS did not support them either. Then,
> with the IBM XT ("eXtended Technology") and as of DOS 3.00,
> support for hard disks was added to both the legacy BIOS and to
> DOS, but the original hard disks for such machines were rather
> small, e.g. 5 MB, 10 MB, 20 MB, 30 MB. The BIOS supported four
> primary partitions, of which one had to be marked "active",
> because the bootloader was a BIOS routine that would select
> the operating system to boot from one of the four possible
> partitions, and the "active" flag was the indicator to the
> BIOS which partition's bootsector to load into memory and pass
> control of the machine onto. The "active" primary partition
> was thus the one holding the operating system selected to
> boot at machine power-up, while the other primary partitions
> could eventually hold another operating system, and selecting
> which one to boot was then only a matter of marking the proper
> partition as "active".
>
> It was only later, with the introduction of the IBM AT
> ("Advanced Technology") and hard disks beyond 32 MB in capacity
> that the support for logical partitions in an extended
> partition container was added, because DOS could only handle a
> partition size of 32 MB - this would later be partly remedied
> in DOS 4.0 via a special trick, and would more appropriately
> be resolved in DOS 5.0. Logical partitions in the extended
> partition container cannot be marked "active", but the
> construct allowed DOS to use a primary partition - i.e. only
> the "active" one, as it could not access the other primary
> partitions on the same disk - plus an additional number of
> logical partitions in the extended partition container.
>
> Windows still abides by the legacy partitioning scheme and the
> concept of an "active" primary partition, in that Windows still
> makes use of the legacy BIOS bootloader code which reads the
> partition table of the first hard disk in the system - i.e.
> the hard disk marked in the BIOS as "bootable" - and then, via
> this partition table, locates the "active" primary partition
> and loads its bootsector (or "boot block", if you will) into
> memory, and then passes all control over the machine onto that
> piece of code, which is then the Windows NT bootloader. At that
> stage, the x86 processor[2] is still in real mode, and this
> is how real mode operating systems like DOS worked, i.e. by
> loading a piece of code into memory and passing all control of
> the machine onto that segment of code. The Windows bootloader
> program will then load another piece of code into memory, which
> would then be the bootstrap code of the Windows NT kernel, and
> it is only this bootstrap code that sets up the pagetables and
> switches the processor into protected mode.
>
> GNU/Linux on the other hand works quite differently. Although
> the real mode BIOS mechanism of loading an "active" primary
> partition's bootsector into memory can still be used - e.g.
> in the event that the GNU/Linux bootloader would reside
> inside a partition's bootsector, as opposed to the normal and
> recommended way of setting up a GNU/Linux system by having
> its bootloader reside in the master boot record of the hard
> disk marked in the BIOS set-up program as "bootable", hereby
> overwriting the legacy BIOS bootloader code which looks for an
> "active" primary partition. The GNU/Linux bootloader - itself
> also still a real mode program - will then directly load a
> kernel image into memory without looking at the partition type.
> This kernel image consists of real mode bootstrapping code and
> a compressed image of a protected mode kernel, and the real
> mode bootstrapping code then sets up the pagetables, switches
> the processor into protected mode and decompresses the actual
> protected mode kernel.
>
> And as such, the legacy principles which were only invented so
> as to allow a real mode operating sytem such as DOS or CP/M to
> boot on an x86 processor do not apply to GNU/Linux, nor to most
> other UNIX systems I know of - Minix and Microsoft's or SCO's
> Xenix would be exceptions since they were written for the 8086
> architecture.
>
>
> [1] "Real mode" is the 8086-compatible mode of all x86
> processors as of the 80286 on. All x86 processors are by design
> in real mode at power-up for DOS-compatibility, and as such,
> the legacy BIOS was still written as real mode code as well.
> XT and AT were only extensions to that old 16-bit real mode
> BIOS code. There are however protected mode BIOS versions[3]
> which already set up protected mode on the boot processor
> from within the BIOS - e.g. EFI, CoreBoot (formerly known as
> LinuxBIOS) - but these require a special version of the GRUB
> or LILO bootloaders[4], and a modified kernel image (without
> real mode bootstrapping code). However, at machine power-up,
> the processor is still in real mode by design, so the BIOS must
> first initialize protected mode.
>
> [2] During boot-up, only one processor is active - i.e. one
> CPU core on multi-core processor chips - and it is the kernel
> which, once protected mode has been entered, initializes the
> other processors and sets up the symmetric multiprocessing or
> NUMA[5].
>
> [3] EFI ("Extensible Firmware Interface") and CoreBoot also
> allow for a different partitioning system, where you can have
> up to 128 primary partitions per hard disk, and where the
> special protected mode versions of LILO or GRUB actually become
> extensions to the BIOS. However, due to limitations in the
> Linux kernel, Linux can only handle 63 partitions in total on
> IDE disks accessed via the older ATA code or 15 partitions on
> SAS, SCSI, SATA and USB disks, and on IDE disks accessed via
> the newer /libata/ code. Among the computers which use an EFI
> BIOS are the Intel-based Apples and all machines with an Intel
> Itanium processor. Some motherboard manufacturers also support
> EFI or CoreBoot - Tyan used to support it but seems to have
> dropped that support again a few years ago - but only very few
> GNU/Linux distributions are actually built to be used with such
> firmware. Most are simply built for systems with a legacy BIOS.
> (Remember, you need a different version of either LILO or GRUB,
> and you need a different Linux kernel image.)
>
> [4] Non-x86 machines like the IBM PPC, Sun (Ultra)SPARC, SGI
> MIPS, Hewlett-Packard Alpha and PA-RISC, Intel Itanium et al
> already use such special versions of LILO or GRUB, since those
> processor architectures do not have a real mode. (Itanium does,
> but only via an x86-32 emulation mode, which must be explictly
> selected at boot time and/or enabled in the EFI firmware.)
>
> [5] NUMA stands for "Non-Uniform Memory Access" and is (on x86)
> the kind of multiprocessing found on AMD's 64-bit processors
> and on the newer Intel i7 systems, where you have multiple
> processor sockets with each socket having its own memory
> controller. As such, each socket - which houses a single- or
> multi-core processor chip - has its own local memory, while
> still being able to see all of the installed memory via access
> through the other processor sockets. This principle avoids
> the bottleneck of having a single memory controller for all
> processor sockets on the motherboard.
>
> -- *Aragorn* (registered GNU/Linux user #223157)


Wow! That's what you call an _answer_!

Sid


From: Ryan McCoskrie on 28 Dec 2009 03:52
Sidney Lambe wrote:

> On comp.os.linux.setup, Aragorn <aragorn(a)chatfactory.invalid>
> wrote:
> [snip long discription of low level information]
>
> Wow! That's what you call an _answer_!
>
> Sid

Are you the same Sid we usually get? You just said something nice about
Aragorn!

--
Quote of the login:
An Ada exception is when a routine gets in trouble and says 'Beam me up,
Scotty'.
From: Sidney Lambe on 28 Dec 2009 04:47
On comp.os.linux.setup, Ryan McCoskrie <ryan.mccoskrie(a)invalid.invalid> wrote:
> Sidney Lambe wrote:
>
>> On comp.os.linux.setup, Aragorn <aragorn(a)chatfactory.invalid>
>> wrote:
>> [snip long discription of low level information]
>>
>> Wow! That's what you call an _answer_!
>>
>> Sid
>
> Are you the same Sid we usually get? You just said something nice about
> Aragorn!

I say nice things about people when they do nice things and bad
things about them when they do bad things.

That is, if they aren't among the 99.999999999999% of the
population whom I simply ignore as individuals, just keeping a
casual eye on their collective behavior.

Make sense to you?


Sid



From: Peter Köhlmann on 28 Dec 2009 04:51
Sidney Lambe wrote:

> On comp.os.linux.setup, Ryan McCoskrie <ryan.mccoskrie(a)invalid.invalid>
> wrote:
>> Sidney Lambe wrote:
>>
>>> On comp.os.linux.setup, Aragorn <aragorn(a)chatfactory.invalid>
>>> wrote:
>>> [snip long discription of low level information]
>>>
>>> Wow! That's what you call an _answer_!
>>>
>>> Sid
>>
>> Are you the same Sid we usually get? You just said something nice about
>> Aragorn!
>
> I say nice things about people when they do nice things and bad
> things about them when they do bad things.
>
> That is, if they aren't among the 99.999999999999% of the
> population whom I simply ignore as individuals, just keeping a
> casual eye on their collective behavior.
>
> Make sense to you?
>
>
> Sid

No, Alan Connor, it does not. It simply serves to describe you as the
nutter you really are

And just forget about your nymshifting tricks. You are way to incompetent
to show up here as that phoney "Sidney Lambe"
--
I refuse to have a battle of wits with an unarmed person.

From: Aragorn on 28 Dec 2009 20:25
On Monday 28 December 2009 09:52 in comp.os.linux.setup, somebody
identifying as Ryan McCoskrie wrote...

> Sidney Lambe wrote:
>
>> On comp.os.linux.setup, Aragorn <aragorn(a)chatfactory.invalid>
>> wrote:
>> [snip long discription of low level information]
>>
>> Wow! That's what you call an _answer_!
>>
>> Sid
>
> Are you the same Sid we usually get? You just said something nice
> about Aragorn!

Well, I am pleased that even Alan Connor/Sidney Lambe can appreciate my
technical verbosity, albeit that I too am surprised that he actually
does. :-)

--
*Aragorn*
(registered GNU/Linux user #223157)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Packet.dll and which wpcap.dll
Next: Keyboard re-mapping