Just out of curiousity, has anyone documented how much of a performance
hit there is with the i386 code enabled in the kernel?
Regards,
Glen Gross
On Thu, 18 Jan 2001, Mike Smith wrote:
> > > That's one of the big reasons that we're 4.x based right now rather
> > > than 3.x based, despite 4
On Thu, Jan 18, 2001 at 11:44:18AM -0800, Mike Smith wrote:
> You have a very vivid imagination.
It's not easy to replace imagination with experience. This takes years,
which I have yet to come upon. :-)
> Unfortunately, imagination isn't very helpful here; the whole idea is to
> do stuff tha
On 18-Jan-01 Will Andrews wrote:
> Well, Warner, I've never done embedded systems. So, tell me, do they
> actually use any C++ code in embedded systems? C++ has a rather high
> overhead as far as disk space & memory goes. I would imagine that 99%+
> of embedded systems do not use C++ code exce
> > That's one of the big reasons that we're 4.x based right now rather
> > than 3.x based, despite 4.x's slightly larger memory footprint. That
> > and 4.x's much better c++ compiler.
>
> Well, Warner, I've never done embedded systems. So, tell me, do they
> actually use any C++ code in embedd
> Will Andrews <[EMAIL PROTECTED]> writes:
> > Well, Warner, I've never done embedded systems. So, tell me, do they
> > actually use any C++ code in embedded systems? C++ has a rather high
> > overhead as far as disk space & memory goes.
>
> That's a myth.
>
> >
Will Andrews <[EMAIL PROTECTED]> writes:
> Well, Warner, I've never done embedded systems. So, tell me, do they
> actually use any C++ code in embedded systems? C++ has a rather high
> overhead as far as disk space & memory goes.
That's a myth.
> I
In message <[EMAIL PROTECTED]> Will Andrews writes:
: Well, Warner, I've never done embedded systems. So, tell me, do they
: actually use any C++ code in embedded systems? C++ has a rather high
: overhead as far as disk space & memory goes. I would imagine that 99%+
: of embedded systems do not
how about to have in a distribution two version of GENERIC kernel
(and modules of course) and let sysinstall choose right set ?
In article <[EMAIL PROTECTED]> you wrote:
> On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote:
>> On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wa
On Wed, Jan 17, 2001 at 11:34:09PM -0700, Warner Losh wrote:
> That's a red herring. The new features thing is what I mean. If I
> were creating a product, I'd want one that is supported. So even if I
> don't *NEED* a feature in 5.x, I might migrate my product to 5.x so
> that I can continue to
In message <[EMAIL PROTECTED]> Greg Lehey writes:
: > Of course. But of these people, which really need 5.x's features over
: > 4.x?
:
: I thought about that, too. I came to the conclusion "probably not",
: but 4.x won't be maintained for ever.
Compiler technology maybe? But maintainence and
In message <[EMAIL PROTECTED]> Will Andrews writes:
: Of course. But of these people, which really need 5.x's features over
: 4.x? Plus they can still compile I386_CPU by itself, which I'm sure
: they already do to keep the kernel size as small as possible.
That's a red herring. The new featur
In message <[EMAIL PROTECTED]> Greg Lehey writes:
: Don't forget that the i386 is still a popular CPU for embedded work.
: Of course, embedded people will have less of an issue with sysinstall.
We have basically an embedded environment and we don't use sysinstall
at all for building our CF. And
On Wednesday, 17 January 2001 at 19:16:18 -0500, Will Andrews wrote:
> On Wed, Jan 17, 2001 at 04:21:15PM +1100, Greg Lehey wrote:
>> Don't forget that the i386 is still a popular CPU for embedded work.
>> Of course, embedded people will have less of an issue with sysinstall.
>
> Of course. But o
On Wed, Jan 17, 2001 at 04:21:15PM +1100, Greg Lehey wrote:
> Don't forget that the i386 is still a popular CPU for embedded work.
> Of course, embedded people will have less of an issue with sysinstall.
Of course. But of these people, which really need 5.x's features over
4.x? Plus they can st
On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote:
> On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote:
>> Wont this make installing using sysinstall a bit hard? I know the generic
>> kernel includes all the CPU lines, so that all cpu's are recognized... so
>> ar
I'm sorry guys, I haven't been really "up-to-date" on this thread, but I was
wondering: can config be made to define I386_CPU 0 if any other cpus are
defined (or the inverse behavior)? (Maybe this was already done?) In the
sysinstall case, I think it's safe to just exclude all other processors and
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: I've requested a change for UPDATING:
It is in my queue... I have a few other entries I need to dust off.
I'll try to do that today.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
OH ok, just curious how that was going to work.
=
| Kenneth Culver | FreeBSD: The best NT upgrade|
| Unix Systems Administrator | ICQ #: 24767726 |
| and student at The | AIM: muythaibxr
OK, but it makes sense to me that for certain applications, it makes sense
to utilize the old hardware since it is still readily available and cheap.
In particular, why not install FreeBSD on i386 for use in routers? In
many cases there is a negligible performance advantage from using faster
CPU
Will Andrews <[EMAIL PROTECTED]> writes:
> I don't think it's worth the effort. By the time 5.0-RELEASE goes out,
> the 386 will have been around for over 10 years (actually I think it has
> already reached that point and gone beyond).
It's already more than 15 years old - Intel introduced the 8
On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote:
> Wont this make installing using sysinstall a bit hard? I know the generic
> kernel includes all the CPU lines, so that all cpu's are recognized... so
> are you going to just take this line out of the generic kernel, and have a
Wont this make installing using sysinstall a bit hard? I know the generic
kernel includes all the CPU lines, so that all cpu's are recognized... so
are you going to just take this line out of the generic kernel, and have a
special kern.flp disk with a generic kernel that only has the i386 support
I've requested a change for UPDATING:
The kerrnel option I386_CPU is now mutually exclusive with the
other cpu types. If you have an i386 system, be sure that it
only had this line. Remove it for all other configurations.
Note that this does not remove i386 support. The
23 matches
Mail list logo