The ./Documentation/i386/boot.txt written by HPA is a nice start about the
boot processes, but yes, I found that very few people on this list have the
time to explain generalized concepts. Makes it hard to wade in and
contribute.. My struggles with INITRD_START reporting has so far only got 3
helpful souls to respond... (Ooops 4, how could I forget Alan :-))
In general, I see it takes a long time for a thread to develop, but when it
does, and it gets everyone involved.
For the most part, I see answers to the easy questions, because there are
more people that might feel in the mood to respond. The guys that REALLY
know the stuff, all have real jobs, and keeping up with the questions on the
list is real time consuming.. Unless someone is working on a similar
problem, or has, there is very little response.
My experience seems to be that other than a few noble souls, who are
undoubtably overworked, there are very few people who have the time to deal
with explaining the workings of the kernel architecture, and most people
involved seem to use this channel to correspond about their CURRENT interests
and projects.
And I have to admit, I fall into that category, with a business to run, when
I am not FORCED into getting my hands dirty, I have little time to be
involved in the discussion lists.
And don't forget, most people work on a part of the kernel, and not all if
it. They only thing is, that I think many people are doing the same work as
others without realizing it.
There should be some forum that encourages more kernel developers. I know
for one that if our distro didn't need this issue resolved I would never be
wandering through the assembler code to see how it all fits together.
BTW, with the syslinux package, there is a great ldlinux.lst file that is
really a great asset to learning the boot sequences.
But for a person who wants to get in and help with the kernel, if you asked
questions in general about the workings of the different parts of the kernel,
frankly you get VERY little response from the list.
Should there be another list dedicated to kernel intricasies vs one list to
deal with problems?? What about a kernel developers list? vs a kernel
problems list. (The NTFS streams debate filled this list for a couple of
weeks) Thoughts?? Suggestions?? We should get more people playing with the
kernel, but those people trying to get their hands dirty for the first time
tend to hit stumbling blocks where they can't get past, and turn to other
pursuits, (Unless they are forced to learn it :-0)
And also, to let everyone know, we are starting up some linux support chat
rooms, that will be ready by the end of the week. Any suggestions for topics
that should be featured?
On Mon, 28 Aug 2000, Tigran Aivazian wrote:
> Hi,
>
> it is interesting to observe that many questions that deal with _details_
> are answered quickly but questions related to fundamental concepts related
> to how Linux is designed, baffle all of us (since 0 people answered). So,
> is there really nobody in the whole world who can answer this? I would
> like to know the answer (about global kernel memory layout - i.e. what
> goes into PSE pages and what goes into normal ones, and how does PAE mode
> change the picture?) myself...
> >
> > The reason I ask is that I'm confused as to what happens when a user
> > process or tries to allocate memory. I assume that the VM uses 4KB pages
> > for this allocatation. So do we end up with two virtual addresses
> > pointing the same physical memory?
> >
> > What happens if I use ioremap_nocache() on normal memory? Is that memory
> > cached or uncached? If I use the pointer obtained via phys_to_virt(),
> > the memory is cached. But if I use the pointer returned from
> > ioremap_nocache(), the memory is uncached. My understanding of x86 is
> > that caching is based on physical, not virtual addresses. If so, it's
> > not possible for a physical address to be both cached and uncached at the
> > same.
> >
> > Could someone please straighten me out?
> >
-- -------------------------------------------------------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com -------------------------------------------------------- (604) 589-0037 Beautiful British Columbia, Canada -------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:22 EST