On Mon, Jan 04, 2010 at 01:27:06AM -0800, Bhaktavatsalam Nallanthighal wrote: > Hi, > > Thanks for the elaborate reply and for the pointer. I've been reading > various parts of an old Linux kernel, Minix and Unix V 6.0. This is > along the lines of writing my own kernel. You said that conditional > compilation is used for various architecture specific features. As > you've suggested, this is evident from the kernel's coding if it is > supporting a wide range of processors [the preprocessing] But, the > more confusing point to me is how the kernel is able to consistently > do this across varying architectures. For example, if linux kernel > supports a processor that has no protection features or atleast not as > many as Intel processors have, how would the overall impact be > managed. > > For Instance, say that the linux kernel is using the protection > features of the Intel processor to keep user-space programs from > affecting the kernel [which seems to me as the most natural way to do. > If otherwise, please mention]. If the kernel is able to run on some > other architecture that does not have these features, does it mean > that it offers no protection? Or does it mean that protection is > implemented in software for that processor. > > Another Instance, say that the linux kernel supports multitasking > using the hardware features of the Intel processors[TSSes etc. Please > correct me if this is not the way, again.] How is this able to port > across some other architecture that does not have these features in > hardware? Is it implemented in software? > > Apart from this, I would be helpful if more clarification can be > provided on the issue with supporting higher level datatypes and > different sized-processors. The exact issue is with how linux supports > higher types during RUNTIME. A best example to represent the issue, is > with ZFS. I heard somewhere that ZFS[from Sun] is supported on linux. > But, it is well known that ZFS is a 128-bit file system. If the > processor is able to only manipulate data in 32-bit, how are 128-bit > operations like addition, subtraction done? Are there any cascadable- > instructions that provide a carry/borrow/etc. so that each 128-bit > operations require four 32-bit operations? If so, isn't this very > inefficient? > > You also said that the system calls provide a unified layer to other > parts of the kernel. Do you mean that each system call is differently > implemented for each kind of processor? For example, consider kmalloc > () function. Is kmalloc() implemented differently for each processor? > > I'm just few steps away from diving into a linux book. I'm just trying > to avoid it as much as possible, through asking people due to time > restrictions. Additionally, the website you provided is nice. Good > article on Portable device drivers. > > Bhaktavatsalam Nallanthighal > > On Jan 4, 2:11 am, Sid <[email protected]> wrote: > > On Jan 4, 5:34 am, Bhaktavatsalam Nallanthighal > > > > <[email protected]> wrote: > > > Hello, > > > > > Can anyone explain in a clear way, how linux deals with > > > portability across architectures. The main points I'm getting confused > > > are: > > > > > - Does a single linux kernel support processors of varying size? I > > > mean, will the same linux kernel give me the ability to compile it for > > > various sized processors[8-bit, 16-bit, 32-bit, 64-bit]? > > > > Yes, linux kernel supports different processors. Although I am not > > sure if it supports an 8 bit one, as linux was first made for 80386 > > microprocessor. > > If you configure and compile the kernel yourself, you'll see that > > there are options that allow you to compile it for different > > processors. These options are nothing but conditional compilation > > statements like #ifdef in the kernel code, so, according to the > > processor you select, the coressponding code for that very processor > > is compiled. > > > > > If so, how > > > does it deal with the datatypes consistently? > > > > There is definition for different datatypes and again conditional > > compilation is used for the same. If you go through the kernel code > > you'll see that there are various directories for different > > architectures. e.g. for x86 machines, you'll find the code in arch/ > > x86/. > > > > > And how does it provide > > > a unified layer to applications that use processor specific > > > functionality? > > > > System Calls, and the library functions help you do that. > > > > >Also, how does it manupilate datatypes that the > > > processor does not inherently support. For example, if I am able to > > > compile for a 16-bit processor, how does it support the uint32 > > > datatype used in other areas of the kernel [addition, subtraction, > > > byte ordering]? > > > > I guess gcc does that for you. Please let me know if I am wrong here. > > > > > > > > > - Does the Linux kernel implement "Protected Mode" and other kinds > > > of features also in other architectures that do not support them? > > > If so, how? If not, how is it made possible that one feature is present > > > in one compilation and is not present in another? How does this effect > > > the other areas of the kernel that depend on this features > > > > No it doesn't on other processors. And once again conditional > > compilation is used for that. > > > > > > > > > Thanks in advance. If possible please send me your replies to > > > [email protected]. The digests I get fill my inbox! > > > > > Bhaktavatsalam Nallanthighal > > > > Also, if you've already not done it, configure and compile the kernel > > yourself, you'll know how things actually work. Also read the kernel > > sources. If you're interested to know about the Linux kernel a great > > place to start ishttp://kernelnewbies.org/. > > -- > You received this message because you are subscribed to the Linux Users Group. > To post a message, send email to [email protected] > To unsubscribe, send email to [email protected] > For more options, visit our group at > http://groups.google.com/group/linuxusersgroup
Well, you're confusing instruction size with address space. The instructions use a 32-bit instruction, while the address space (although 32 bit) can be manipulated to 128 bits. While it is technically less efficient to access 128-bit addresses with 64 or 32 bit address spaces, it is quite possible and the performance hit isn't *that* bad. It's not a matter of using 4 32-bit instructions to fire one 128-bit instruction, it's a matter of using 4 32-bit cpu registers to hold one 128-bit address, and using clever techniques to efficiently address the data. You should look into memory segmentation in assembler to get a better idea for how this works. -- You received this message because you are subscribed to the Linux Users Group. To post a message, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit our group at http://groups.google.com/group/linuxusersgroup
