Matt Dillon wrote:
> :> and preferably on more than the i386 platform. If we are going to
> :> be serious about supporting more hardware platforms, then we have
> :> to start treating them more seriously when major changes like this
> :> come along. If we can't get some broader testing of this done in
> :> the next few weeks, then the changes should probably wait until
> :> after "5.0".
> :
> :
> :I believe that I read in an earlier thread that the archetecture-specific changes
>are minimal, and that majority of the changes are
> :in high-level constructs in the kernel. Of course, I could be recalling this
>incorrectly, but I don't think I am...
> :
> :jim
>
> Yes, this is correct. The assembly changes are just structural
> indirections for things that were broken off from the proc structure.
> The scheduler now messes with 'threads' rather then 'processes' for
> the most part. That part of the diff set is involved but straight
> forward. Julian also add KSTACK_PAGES to allow the kernel stack to
> be specified in a more controlled manner.
>
> Here is an excerpt so you can see what I mean:
>
> ...
> -
> - movl P_VMSPACE(%ecx), %edx
> + movl TD_PROC(%ecx), %eax
> + movl P_VMSPACE(%eax), %edx
> movl PCPU(CPUID), %eax
> btrl %eax, VM_PMAP+PM_ACTIVE(%edx)
>
> - movl P_ADDR(%ecx),%edx
> + movl TD_PCB(%ecx),%edx
> ...
>
> See? not much too it.
>
> -Matt
That's about what I thought it would be...
If the other archetectures are so flaky right now under FreeBSD, then maybe some
people are barking up the wrong tree when it comes
to opposing KSE integration using the other archetectures as the crux of their
argument. Sounds like they need to be kicking some
butts to catch up with the pack!
Testing should be across the board, but I don't see any reason why, if the maintainers
of the other archetectures are so behind on
other tasks that they can't have a seperate, later, 5.0-RELEASE for them. We
shouldn't sacrifice intel functionality for timetable
slippage on the other archetectures, and honestly, that's how I'm reading the
arguments against... Again, I could be wrong, but...
Of course, we could always end up like NetBSD, with a development cycle that makes
FreeBSD's current cycle look fast, only because
of support for all of the different archetectures. No offense to the NetBSD'ers out
there, NetBSD is a fine OS, but my point is
that FreeBSD is [or was] a different paradigm, primarily [but not exclusively] intel.
jim
--
ET has one helluva sense of humor!
He's always anal-probing right-wing schizos!
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
