cvs commit: src/sys/i386/conf GENERIC
Jordan Hubbard
> waterline a fair bit on -current.
Modulo giving developers and the user community a few weeks to comment
on the matter and make any last convincing cases for keeping it, I
agree. That's not to say that I want to see two weeks worth of i386
bike-shedding and highly emotional arguments for keeping it purely on
general principle, I'm saying that we need to let a couple of weeks go
by so that along with the emotional bike sheds, anyone with a
*technical* argument for retaining support has a chance to be heard.
As an example, one technical argument I've heard in the past is that
only the 386 is available in radiation-hardened packaging and people
wishing to send FreeBSD into orbit have no choice but to deploy 386
processors. I've also heard that the 486 is also now available in
rad-hard form which sort of negates that argument, not to mention the
fact that even 386-bound users will always have the older bits
available, but it still points up the fact that such arguments have
existed in the past and might still. All we need are some serious
users who have a compelling need to use 386s AND need something which
we're only going to have in 5.0 to give us grounds for pause, and I
don't think we're in such a compelling hurry to do this that we can't
give them a couple of weeks to pop up and say something. All we need
to do is announce our intention to do this more formally first.
- Jordan
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Warner Losh
: The bottom line is that I feel the time is just about right to yank i386
: entirely, not just taking it out of GENERIC. But I wont push for that
: (yet :-). But ending the expensive runtime cost of i386 support in
: GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout()
: etc is just not worth it.
We at Timing Solutions run FreeBSD in an embedded way. We usually
burn CF "disks" with a custom script, and then boot from there. We've
found 4.x performs really well on 486 class of hardware (we're using
AMD 133MHz parts). We've also run it on 386 hardware fairly
successfully as well, but that SBC is giving way to a 486 one so I
don't know if we'll have a requirement for continuing 386 support or
not.
On those products that we have that don't need it, we certainly do try
to remove it from the kernel configs. Then again, we also tend to
remove everything we don't absolutely need for the product from the
config as well, given the contrained nature of the hardware that we
run on.
So I guess this is a long way of saying that I'd help resist 386
support being removed completely, but I have no problems with it out
of GENERIC.
Warner
Alexander Langer
> >Does it make any sense at all to make 80386 a separate platform
> >a'la pc98/alpha/ia64? Do enough people care about it?
> No it doesn't. I think you'll find that running 5.x in less than
> 32MB is going to be painfull or impossible in the first place.
A little bit of the ramainding mystique of free open-source UNIX-like
operating system for me is the fact, that you still can run it on i386
machines with usable speed (e.g. small private home mail-servers).
Given the fact that we usually stop supporting releases that are too
old (e.g. the 2.x branch and I suppose RELENG_3 soon), I somehow
dislike the idea of not supporting the i386 any more.
I think you really can trim 5.x down to work w/o pain on a i386 once
installed.
A decision must be made. If removing support for the i386 has
gradious performance or memory advantages for the ramainding platforms,
I second removing the code.
On the other hand, if we only remove it from GENERIC, we could provide
a trimmed down i386 kernel, which doesn't include support for PCI and
PCCARD devices. This kernel should work on small machines with better
speed and less memory usage.
Alex
--
cat: /home/alex/.sig: No such file or directory
Andrea Campi
> >> waterline a fair bit on -current.
> >
> >a'la pc98/alpha/ia64? Do enough people care about it?
>
> No it doesn't. I think you'll find that running 5.x in less than
> 32MB is going to be painfull or impossible in the first place.
Sorry Poul, I think the question here is: "if we decide to remove i386 support
BUT a few people still want to use it and can maintain it as a separate
platform port, is it an option to do so, from a technical point of view?"
Personally, I don't care about i386 support in -current, but if it's possible
to keep it in parallel, then why not?
My Euro 0.02
Bye,
Andrea
--
I believe the technical term is "Oops!"
Alexander Langer
> On the other hand, if we only remove it from GENERIC, we could provide
> a trimmed down i386 kernel, which doesn't include support for PCI and
> PCCARD devices. This kernel should work on small machines with better
> speed and less memory usage.
I hate to follow up myself, but:
I obviously missed Peter Wemm's email, where he already gave the
reasons against this.
Well, in this case - though I have emotional problems with this of
course - I second the removal of all 386 specific code.
Alex
--
cat: /home/alex/.sig: No such file or directory
Peter Wemm
> > It would be trivial to add i386 to the install kernel, and
> > probably worthwhile.
>
> Both the installation AND the bindist kernel, right? Otherwise you
> could install, but you wouldn't be able to boot the installed system.
> That basically argues for putting it back into GENERIC, which
> is (I believe) the item in contention here.
If somebody wants to make an i386-capable installation, what we should do
is something like this:
1: have a boot floppy with an i386 specific kernel. That means no PCI, no
pci drivers, more of the older ISA drivers reactivated, kernel tuned
down for low memory, etc.
2: Have the bindist have a kernel.i386 or something that is built similarly.
3: Have sysinstall "activate" the kernel.i386 instead of kernel.GENERIC
Then installing on an i386 becomes a matter of booting a different set
of floppies (remember, no CDROM boot support on i386 and most i486), and
letting sysinstall detect the i386 support and set the boot kernel on
the installed system appropriately.
Cheers,
-Peter
--
Peter Wemm - pe...@FreeBSD.org; pe...@yahoo-inc.com; pe...@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
Jordan Hubbard
> is something like this:
Agreed, and this sounds like a very straight-forward approach. Now
those who still care about the i386 simply need to find that
somebody. :)
- Jordan
Will Andrews
--h3LYUU6HlUDSAOzy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 14, 2001 at 03:54:22PM -0800, Kris Kennaway wrote:
> No we're not. Some committers have merged individual security fixes,
> but there are many which have not, and likely will not, be merged.
I didn't mean we were still doing it in practice; just that it *is*
still happening.
--=20
wca
--h3LYUU6HlUDSAOzy
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6Yj+PF47idPgWcsURAnKwAJwKEmXGElXU2Yu7oSVosqxLJHAuvwCfQDvl
EcCf90kGMoA5EJAXxOJY6pw=
=h7Vw
-----END PGP SIGNATURE-----
--h3LYUU6HlUDSAOzy--
Warner Losh
: > If somebody wants to make an i386-capable installation, what we should do
: > is something like this:
:
: Agreed, and this sounds like a very straight-forward approach. Now
: those who still care about the i386 simply need to find that
: somebody. :)
Like I said in a different message, our company still cares about the
i386 as a platform to deploy on (the future of that caring and the
timing of 5.x is unknown, however). However, we care nothing for
being able to install on a i386 box.
Warner
Kris Kennaway
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sun, Jan 14, 2001 at 12:38:24PM -0500, Will Andrews wrote:
> Heck, we're still MFC'ing security fixes into 2.2.x, even though the
> last time a release on that branch was done about two and a half years
> ago. *SO* I think you can depend on 4.x being a good branch for 386's
No we're not. Some committers have merged individual security fixes,
but there are many which have not, and likely will not, be merged.
Kris
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6YjwuWry0BWjoQKURAnbqAJ9z6/xa+g+qUOmIDqZroL8kH/dhUwCfVymf
veyPWfjdYclFgyI8gHFwqBc=
=grLs
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
Warner Losh
: I didn't mean we were still doing it in practice; just that it *is*
: still happening.
It is still happening, but anybody that cares about security won't be
running 2.x. Too many holes in the several years since it came out
have not been MFC'd.
In no way could one consider 2.2.x alive at this point.
Warner
Bruce Evans
That's because 5.0 serious sucks on all hardware :-). Developers should
occasionally develop on 386's so that it runs well on all systems.
> In fact, it was near impossible to run on a 486-33 w/ 12MB ram when I tried
> it about 12 months ago on what was then -current. I was eventually able to
Hmm. Matt and I fixed running with 5-6MB about 12 months ago. vfs_bio.c
had rotted sizing heuristics that prevented even booting with about 8MB.
I tested -current on a 486 with 16MB a couple of months ago. It was "only"
about 40% slower than it used to be for cpu-intensive things in the kernel.
> The bottom line is that I feel the time is just about right to yank i386
> entirely, not just taking it out of GENERIC. But I wont push for that
> (yet :-). But ending the expensive runtime cost of i386 support in
> GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout()
> etc is just not worth it.
The cost of slowing down copyin()/copyout() is essentially zero, since it is
just the cost of an indirect jump. The only significant slowdown used to be
from not using bswap. The "slowdowns" in the i386 mutex code seem to be
negative since the code is simplistic and uses plain movl's instead of
cmpxchg's. Maintaining this code working is the main cost.
Bruce
Daniel C. Sobral
>
> Wilko Bulte wrote:
> > On Sun, Jan 14, 2001 at 03:15:11AM -0800, Peter Wemm wrote:
> [..]
> > > The bottom line is that I feel the time is just about right to yank i386
> > > entirely, not just taking it out of GENERIC. But I wont push for that
> >
> > in with a commit to GENERIC. Or ?
>
> I dont make policy. I just said what I think. While I agree with the
> commit John did, if I had my way (which I do not) I would have gone
> further. :-)
And, btw, how about editing HARDWARE.TXT and making clear that support
for 386 is tricky, and further adding a FAQ session about FreeBSD 5.x+
and 386?
--
Daniel C. Sobral (8-DCS)
d...@newsguy.com
d...@freebsd.org
ca...@a.crazy.bsdconspiracy.net
"There is no spoon." -- Kiki
Adam
>Jordan Hubbard wrote:
>> > It would be trivial to add i386 to the install kernel, and
>> > probably worthwhile.
>>
>> Both the installation AND the bindist kernel, right? Otherwise you
>> could install, but you wouldn't be able to boot the installed system.
>> That basically argues for putting it back into GENERIC, which
>> is (I believe) the item in contention here.
>
>If somebody wants to make an i386-capable installation, what we should do
>is something like this:
>
>1: have a boot floppy with an i386 specific kernel. That means no PCI, no
> pci drivers, more of the older ISA drivers reactivated, kernel tuned
> down for low memory, etc.
>2: Have the bindist have a kernel.i386 or something that is built similarly.
>3: Have sysinstall "activate" the kernel.i386 instead of kernel.GENERIC
>
>Then installing on an i386 becomes a matter of booting a different set
>of floppies (remember, no CDROM boot support on i386 and most i486), and
>letting sysinstall detect the i386 support and set the boot kernel on
>the installed system appropriately.
>
>Peter Wemm - pe...@FreeBSD.org; pe...@yahoo-inc.com; pe...@netplex.com.au
But its simpler for us than that. Plop 386 support in the install kernel
and document that users wanting to install 5.0 on 386 systems must install
kernel source and compile a slightly custom kernel before rebooting. Its
fairly easy to do if you know how to compile a kernel at all, and you will
have a system containing at least bin+ssys to work with at the prompt. I
had to do it 4 years ago when FreeBSD didn't have dpt enabled in GENERIC
yet, but a dpt-enabled install floppy was available.
John Baldwin
On 15-Jan-01 Bruce Evans wrote:
> On Sun, 14 Jan 2001, Peter Wemm wrote:
>
> occasionally develop on 386's so that it runs well on all systems.
>
>> In fact, it was near impossible to run on a 486-33 w/ 12MB ram when I tried
>> it about 12 months ago on what was then -current. I was eventually able to
>
> Hmm. Matt and I fixed running with 5-6MB about 12 months ago. vfs_bio.c
> had rotted sizing heuristics that prevented even booting with about 8MB.
> I tested -current on a 486 with 16MB a couple of months ago. It was "only"
> about 40% slower than it used to be for cpu-intensive things in the kernel.
>
>> entirely, not just taking it out of GENERIC. But I wont push for that
>> GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout()
>> etc is just not worth it.
>
> The cost of slowing down copyin()/copyout() is essentially zero, since it is
> just the cost of an indirect jump. The only significant slowdown used to be
> from not using bswap. The "slowdowns" in the i386 mutex code seem to be
> negative since the code is simplistic and uses plain movl's instead of
> cmpxchg's. Maintaining this code working is the main cost.
So are you ready to write the code in trap() to handle an illegal instruction
fault in userland that decodes and executes all variants of cmpxchg? The new
threading code in libc will be using atomic_cmpset() from userland, which is
going to be the main hurdle to get over.
> Bruce
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Justin T. Gibbs
>fault in userland that decodes and executes all variants of cmpxchg? The new
>threading code in libc will be using atomic_cmpset() from userland, which is
>going to be the main hurdle to get over.
This is the wrong way to handle it. Have atomic_cmpset() perform a fixup
of the calling code on first entry and the result will be code as optimized
as possible for the processor type the code is running on. If the user
decides to write their own code that uses cmpxchg, they get what they
deserve, but the primitives should not require a *fault* to work correctly.
This is not a new idea and it honestly surprises me that everyone in
this discussion seems to be avoiding the obvious and time tested solution
for this kind of problem.
BTW, this type of thing gives you the oportunity to optimize for any
type of CPU, so the benefit is not necessarily i386 specific.
--
Justin
Peter Jeremy
>>So are you ready to write the code in trap() to handle an illegal instruction
>>fault in userland that decodes and executes all variants of cmpxchg? The new
>>threading code in libc will be using atomic_cmpset() from userland, which is
>>going to be the main hurdle to get over.
>
>This is the wrong way to handle it.
I tend to agree.
> Have atomic_cmpset() perform a fixup
>of the calling code on first entry and the result will be code as optimized
>as possible for the processor type the code is running on.
The other approach (at least for dynamically linked programs) is the
one Solaris uses: linking against libX.so has an implied linkage
against machine/libX.so (if the latter exists). This allows `generic'
functions to be replaced with ones that are optimised for a particular
processor.
> If the user
>decides to write their own code that uses cmpxchg, they get what they
>deserve, but the primitives should not require a *fault* to work correctly.
The only way a user is going to get a cmpxchg in their code is if
they write one in assembler. If a user is writing assembler code,
they should be expected to know what they are doing.
Peter
John Baldwin
On 15-Jan-01 Justin T. Gibbs wrote:
>>So are you ready to write the code in trap() to handle an illegal instruction
>>fault in userland that decodes and executes all variants of cmpxchg? The new
>>threading code in libc will be using atomic_cmpset() from userland, which is
>>going to be the main hurdle to get over.
>
> of the calling code on first entry and the result will be code as optimized
> decides to write their own code that uses cmpxchg, they get what they
> deserve, but the primitives should not require a *fault* to work correctly.
*sigh*
Go look at the 386 version of atomic_cmpset in atomic.h:
#if defined(I386_CPU)
static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
int res = exp;
__asm __volatile(
" pushfl ; "
" cli ; "
" cmpl %1,%3 ; "
" jne 1f ; "
" movl %2,%3 ; "
"1: "
" sete %%al; "
" movzbl %%al,%0 ; "
" popfl ; "
"# atomic_cmpset_int"
: "=a" (res) /* 0 (result) */
: "0" (exp), /* 1 */
"r" (src), /* 2 */
"m" (*(dst)) /* 3 */
: "memory");
return (res);
}
See those 'cli' and 'popfl' instrucitons? Those are _privileged_. Userland
can't disable/enable interrupts, so we have to trap into the kernel to do this
no matter what. If you want to patch the code to do a syscall instead of a
cmpxchg instruction, fine. However, emulating atomic_cmpset in userland on a
386 requires a trap into the kernel. Please assume for at least 1 minute that
the SMPng guys are not complete bumbling idiots and that we may have actually
thought about this for at least 5 minutes.
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Justin T. Gibbs
>can't disable/enable interrupts, so we have to trap into the kernel to do this
>no matter what.
All that is required in the userland implementation is the setting of a
flag so the userland thread scheduler does not perform a thread switch.
Having an interrupt fire does not have the same consequences on a userland
program as it does for the kernel.
>If you want to patch the code to do a syscall instead of a
>cmpxchg instruction, fine. However, emulating atomic_cmpset in userland on a
>386 requires a trap into the kernel. Please assume for at least 1 minute that
>the SMPng guys are not complete bumbling idiots and that we may have actually
>thought about this for at least 5 minutes.
I don't think your idiots at all, I just think that you are interested
in making a case of deprecation of the i386 because it is the quickist
path from A->B. If we decide to deprecate the i386 on technical ground,
so be it, but I haven't seen such a case presented yet.
--
Justin
John Baldwin
On 15-Jan-01 Justin T. Gibbs wrote:
>>can't disable/enable interrupts, so we have to trap into the kernel to do
>>this
>>no matter what.
>
> All that is required in the userland implementation is the setting of a
> flag so the userland thread scheduler does not perform a thread switch.
> Having an interrupt fire does not have the same consequences on a userland
> program as it does for the kernel.
Actually, the process needs to not be switched. This is part of KSE, so you
would have to set a kernel flag in the kse for this, but yes, that would work.
Granted, it pessimizes the non-i386 case, but not that badly. The kernel trap
to emulate only pessimizes the i386 case (though the 386 could do without extra
pessimizations, and it is a bigger pessimization.)
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Justin T. Gibbs
>> flag so the userland thread scheduler does not perform a thread switch.
>> Having an interrupt fire does not have the same consequences on a userland
>> program as it does for the kernel.
>
>Actually, the process needs to not be switched. This is part of KSE, so you
>would have to set a kernel flag in the kse for this, but yes, that would work.
>
>Granted, it pessimizes the non-i386 case, but not that badly. The kernel trap
>to emulate only pessimizes the i386 case (though the 386 could do without extr
I suppose I haven't read enough of the KSE stuff to understand why
you need to not change processes (or is a process the "unit" used
to represent a KSE?). Doesn't the userland scheduler decide what
to do with any KSE it is given?
Anyway, if you use the "patch up the atomic operation" approach, you
don't pessimize anyone except on the first run through a particular
atomic operation.
--
Justin
Daniel Eischen
>
> On 15-Jan-01 Justin T. Gibbs wrote:
> >>See those 'cli' and 'popfl' instrucitons? Those are _privileged_. Userland
> >>can't disable/enable interrupts, so we have to trap into the kernel to do
> >>this
> >>no matter what.
> >
> > flag so the userland thread scheduler does not perform a thread switch.
> > Having an interrupt fire does not have the same consequences on a userland
> > program as it does for the kernel.
>
> Actually, the process needs to not be switched. This is part of KSE, so you
> would have to set a kernel flag in the kse for this, but yes, that would work.
> Granted, it pessimizes the non-i386 case, but not that badly. The kernel trap
> to emulate only pessimizes the i386 case (though the 386 could do without extra
> pessimizations, and it is a bigger pessimization.)
I wouldn't want to set anything that tells the kernel not to switch
the process (or KSE). That shouldn't be allowed from userland, at
least without proper permissions.
--
Dan Eischen
John Baldwin
On 15-Jan-01 Justin T. Gibbs wrote:
>>> All that is required in the userland implementation is the setting of a
>>> flag so the userland thread scheduler does not perform a thread switch.
>>> Having an interrupt fire does not have the same consequences on a userland
>>> program as it does for the kernel.
>>
>>Actually, the process needs to not be switched. This is part of KSE, so you
>>would have to set a kernel flag in the kse for this, but yes, that would
>>work.
>>
>>Granted, it pessimizes the non-i386 case, but not that badly. The kernel
>>trap
>>to emulate only pessimizes the i386 case (though the 386 could do without
>>extr
>
> I suppose I haven't read enough of the KSE stuff to understand why
> you need to not change processes (or is a process the "unit" used
> to represent a KSE?). Doesn't the userland scheduler decide what
> to do with any KSE it is given?
KSE doesn't have a userland scheduler. It's all in the kernel. But yes, you
are right, it is just the KSE, and not the process switch that needs to be
prevented.
> Anyway, if you use the "patch up the atomic operation" approach, you
> don't pessimize anyone except on the first run through a particular
> atomic operation.
Actually, the easiest way I can think of to do this would be to have an
internal cmpset() function:
int
cmpset(dst, exp, src)
{
if (on_a_386) {
set_no_switch_flag;
if (*dst == exp) {
*dst = src;
return 1;
} else
return 0;
} else
return atomic_cmpset(dst, exp, src);
}
Then change ast() in the kernel to check the per-KSE flag.
> --
> Justin
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Justin T. Gibbs
>the process (or KSE). That shouldn't be allowed from userland, at
>least without proper permissions.
It doesn't tell it not to switch to any other KSE, but rather
not to switch to another KSE within the same "process" (process
group? I don't know the correct terminology). I don't see
why this would be a security problem. Of course, this would
only be available for UP, i386 configurations.
--
Justin
John Baldwin
On 14-Jan-01 David O'Brien wrote:
> On Sun, Jan 14, 2001 at 12:38:24PM -0500, Will Andrews wrote:
>> > name for the architecture if the 386 itself is dropped. :-)
>>
>> I think 'ia32' is a good name. :-)
>> David? :-)
>
> I prefer "x86" as that is what the arch was known as until just
> recently. Another reason is to have a little more difference between
> this an "ia64" just to make reduce mis-reading and to help command-line
> completion. :-) Not to mention the code will be shared for the x86-64,
> and making a non-Intel designed called "Intel Architecture" is just yucky.
IA32 is what the actual processor manuals from Intel call it.
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Will Andrews
--UFRfxei4j9xfgtfb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jan 15, 2001 at 02:17:18PM -0800, John Baldwin wrote:
> IA32 is what the actual processor manuals from Intel call it.
Sounds good to me. But I'm not touching the kernel code. :P
--=20
wca
--UFRfxei4j9xfgtfb
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6Y3f9F47idPgWcsURAmdEAJ9TMHh0OrNcxprHPeCAVU4DXpHt4gCfXSE6
5sg15EQAa6NC1ELC0e6HOqE=
=eCG6
-----END PGP SIGNATURE-----
--UFRfxei4j9xfgtfb--
Peter Jeremy
> On Sun, Jan 14, 2001 at 12:38:24PM -0500, Will Andrews wrote:
>> > Just remember to change all the places that refer to 'i386' as the generic
>> > name for the architecture if the 386 itself is dropped. :-)
>>
>> I think 'ia32' is a good name. :-)
>> David? :-)
>
> I prefer "x86" as that is what the arch was known as until just
> recently. Another reason is to have a little more difference between
> this an "ia64" just to make reduce mis-reading and to help command-line
> completion. :-) Not to mention the code will be shared for the x86-64,
> and making a non-Intel designed called "Intel Architecture" is just yucky.
IMHO, changing the name "i386" to something else is a severe violation
of POLA. Who wants to answer -questions after 5.0-RELEASE appears with
no /usr/src/sys/i386?
In any case, I see no reason why we should totally drop 80386 support
(though I agree it should be dropped from the GENERIC kernel). In which
case, there's no reason not to stick with the term `i386'.
Peter
Daniel Eischen
> >I wouldn't want to set anything that tells the kernel not to switch
> >the process (or KSE). That shouldn't be allowed from userland, at
> >least without proper permissions.
>
> It doesn't tell it not to switch to any other KSE, but rather
> not to switch to another KSE within the same "process" (process
> group? I don't know the correct terminology). I don't see
> why this would be a security problem. Of course, this would
> only be available for UP, i386 configurations.
OK, I didn't read it that way.
--
Dan Eischen
Tony Finch
>
>KSE doesn't have a userland scheduler. It's all in the kernel.
Surely not. The current threads implementation doesn't require the
kernel to get involved in a thread switch; if the scheduler were
purely in the kernel this would not be true and KSE would not be much
better than LinuxThreads.
Tony.
--
f.a.n.finch fa...@covalent.net d...@dotat.at
"You realize there's a government directive stating
that there is no such thing as a flying saucer?"
John Baldwin
On 16-Jan-01 Tony Finch wrote:
> John Baldwin <j...@FreeBSD.org> wrote:
>>
>>KSE doesn't have a userland scheduler. It's all in the kernel.
>
> Surely not. The current threads implementation doesn't require the
> kernel to get involved in a thread switch; if the scheduler were
> purely in the kernel this would not be true and KSE would not be much
> better than LinuxThreads.
I've since been corrected that it will still be userland of sorts.
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Peter Wemm
Modified files:
sys/i386/conf GENERIC
Log:
At great personal risk to my sanity, turn off COMPAT_OLDISA and the
two drivers that depend on it - ie and le. The compat code has not been
disabled.
Revision Changes Path
1.299 +3 -4 src/sys/i386/conf/GENERIC
Warner Losh
: At great personal risk to my sanity, turn off COMPAT_OLDISA and the
: two drivers that depend on it - ie and le. The compat code has not been
: disabled.
There are still about a dozen drivers in the tree that depend on
OLDISA, so it is premature to kill it completely.
However, this is a good first step on that road.
Warner
John Baldwin
On 19-Jan-01 Warner Losh wrote:
> In message <200101191306...@freefall.freebsd.org> Peter Wemm
> writes:
>: At great personal risk to my sanity, turn off COMPAT_OLDISA and the
>: two drivers that depend on it - ie and le. The compat code has not been
>: disabled.
>
> There are still about a dozen drivers in the tree that depend on
> OLDISA, so it is premature to kill it completely.
Didn't stop the killing of OLDPCI. :-P
> However, this is a good first step on that road.
Agreed.
> Warner
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Warner Losh
: Didn't stop the killing of OLDPCI. :-P
That was a mistake. I understand why it happened, but it left LINT
broken for a long time because it was incompletely done :-(
Warner
Scott Long
Modified files: (Branch: RELENG_4)
sys/i386/conf GENERIC
Log:
Add the aac driver to GENERIC.
Revision Changes Path
1.246.2.21 +2 -1 src/sys/i386/conf/GENERIC
John Baldwin
Modified files:
sys/i386/conf GENERIC
Log:
Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes
performance on other x86 processors. Custom kernels can still be built
that will run on the 386.
Revision Changes Path
1.296 +2 -2 src/sys/i386/conf/GENERIC
John Baldwin
Modified files:
sys/i386/conf GENERIC
Log:
Argh, remove a local customization that snuck in here.
Noticed by: jasone
Revision Changes Path
1.297 +1 -2 src/sys/i386/conf/GENERIC
Wilko Bulte
> jhb 2001/01/14 02:11:10 PST
>
> Modified files:
> sys/i386/conf GENERIC
> Log:
> performance on other x86 processors. Custom kernels can still be built
> that will run on the 386.
Does this mean installation won't run on 386 anymore?
--
| / o / / _ Arnhem, The Netherlands email: wi...@freebsd.org
|/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl
Poul-Henning Kamp
>On Sun, Jan 14, 2001 at 02:11:11AM -0800, John Baldwin wrote:
>> jhb 2001/01/14 02:11:10 PST
>>
>> Modified files:
>> sys/i386/conf GENERIC
>> Log:
>> Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes
>> performance on other x86 processors. Custom kernels can still be built
>> that will run on the 386.
>
>Does this mean installation won't run on 386 anymore?
It would be trivial to add i386 to the install kernel, and
probably worthwhile.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Peter Wemm
> In message <2001011411...@freebie.demon.nl>, Wilko Bulte writes:
> >On Sun, Jan 14, 2001 at 02:11:11AM -0800, John Baldwin wrote:
> >> jhb 2001/01/14 02:11:10 PST
> >>
> >> Modified files:
> >> sys/i386/conf GENERIC
> >> Log:
> >> Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes
> >> performance on other x86 processors. Custom kernels can still be built
> >> that will run on the 386.
> >
> >Does this mean installation won't run on 386 anymore?
>
> It would be trivial to add i386 to the install kernel, and
> probably worthwhile.
No, because simply doing that leaves you with an unbootable machine.
Anyway, I defy anybody to do a standard CDROM or boot floppy install on a
386 and stay sane. Everybody that I know of that does this sort of thing
does one of the following type things:
1: cross builds from a fast machine to a small image and dd's it to disks.
Remember, 99% of 386's cannot handle more than 528MB IDE disks.
2: install on a fast machine using sysinstall, and strip the hell out of
the kernel, world etc. Then transport the disk to a 386. Building
a 5.0 kernel on a *486* takes forever these days, let alone a 386.
Remember, 386's were essentially ISA-only. I think we should send people
to 2.2.x if they want to run on an ISA-only i386. 5.0 will *seriously
suck* on typical 386 hardware. My personal experience is that it
*seriously sucks* on a 486 right now (yes, I have one running right now,
and a 486DX33 w/ 64M of ram is **painful**).
In fact, it was near impossible to run on a 486-33 w/ 12MB ram when I tried
it about 12 months ago on what was then -current. I was eventually able to
tune things down enough (maxusers 5, 2 gettys, etc) to get it to the point
that it didn't lock up the VM system during a compile. i386 *pc* hardware
that supports more than 16MB was pretty rare if I recall. Embedded systems
are a different issue, but I doubt many people use the FreeBSD cdrom and
sysinstall to set up an embedded micro-OS install... Heck, even picobsd
uses its own kernel configs.
Yes, we could make an alternate 386 kernel, and a 386 boot disk etc. But
I really dont think it is worth while. The user experience would be rather
uninspiring - I think we'd be far better pointing them to 2.2.x. In fact,
another net-only point release of 2.2.x to fix the known security holes
would probably be less cumulative effort than it would take to keep i386
a viable 'GENERIC' option for the SMPng kernel over the next 6-12 months.
The bottom line is that I feel the time is just about right to yank i386
entirely, not just taking it out of GENERIC. But I wont push for that
(yet :-). But ending the expensive runtime cost of i386 support in
GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout()
etc is just not worth it.
Cheers,
-Peter
--
Peter Wemm - pe...@FreeBSD.org; pe...@yahoo-inc.com; pe...@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
Wilko Bulte
> Poul-Henning Kamp wrote:
> > In message <2001011411...@freebie.demon.nl>, Wilko Bulte writes:
> > >On Sun, Jan 14, 2001 at 02:11:11AM -0800, John Baldwin wrote:
> > >> jhb 2001/01/14 02:11:10 PST
> > >>
> > >> Modified files:
> > >> sys/i386/conf GENERIC
> > >> Log:
> > >> Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes
> > >> performance on other x86 processors. Custom kernels can still be built
> > >> that will run on the 386.
> > >
> > >Does this mean installation won't run on 386 anymore?
> >
> > It would be trivial to add i386 to the install kernel, and
> > probably worthwhile.
>
> No, because simply doing that leaves you with an unbootable machine.
>
> Anyway, I defy anybody to do a standard CDROM or boot floppy install on a
> 386 and stay sane. Everybody that I know of that does this sort of thing
> does one of the following type things:
...
> The bottom line is that I feel the time is just about right to yank i386
> entirely, not just taking it out of GENERIC. But I wont push for that
Fine with me, but a change of policy as I see it. So, not something to sneak
in with a commit to GENERIC. Or ?
--
| / o / / _ Arnhem, The Netherlands email: wi...@freebsd.org
|/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl
Peter Wemm
> On Sun, Jan 14, 2001 at 03:15:11AM -0800, Peter Wemm wrote:
> > The bottom line is that I feel the time is just about right to yank i386
> > entirely, not just taking it out of GENERIC. But I wont push for that
>
> Fine with me, but a change of policy as I see it. So, not something to sneak
> in with a commit to GENERIC. Or ?
I dont make policy. I just said what I think. While I agree with the
commit John did, if I had my way (which I do not) I would have gone
further. :-)
Cheers,
-Peter
Erik Trulsson
> > In message <2001011411...@freebie.demon.nl>, Wilko Bulte writes:
> > >On Sun, Jan 14, 2001 at 02:11:11AM -0800, John Baldwin wrote:
> > >> jhb 2001/01/14 02:11:10 PST
> > >>
> > >> Modified files:
> > >> sys/i386/conf GENERIC
> > >> Log:
> > >> Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes
> > >> performance on other x86 processors. Custom kernels can still be built
> > >> that will run on the 386.
> > >
> > >Does this mean installation won't run on 386 anymore?
> >
> > It would be trivial to add i386 to the install kernel, and
> > probably worthwhile.
>
> No, because simply doing that leaves you with an unbootable machine.
>
> Anyway, I defy anybody to do a standard CDROM or boot floppy install on a
> 386 and stay sane. Everybody that I know of that does this sort of thing
> does one of the following type things:
>
My experience with doing a normal install on a 386 is that it isn't too bad.
Granted, last time I did a normal install (as opposed to build/installworld)
was with 3.2 but anyway.
> 1: cross builds from a fast machine to a small image and dd's it to disks.
> Remember, 99% of 386's cannot handle more than 528MB IDE disks.
Most (all?) 386's can handle large IDE disks just fine. The BIOS might not
be able to handle anything above the 528MB limit, but that just means that
the / partition must be within the 528 MB limit.
(Yes, I have a 386 whose BIOS can't handle large disks with a 1.2 GB IDE
disk. Works like a charm.)
>
> 2: install on a fast machine using sysinstall, and strip the hell out of
> the kernel, world etc. Then transport the disk to a 386. Building
> a 5.0 kernel on a *486* takes forever these days, let alone a 386.
>
> Remember, 386's were essentially ISA-only. I think we should send people
> to 2.2.x if they want to run on an ISA-only i386. 5.0 will *seriously
> suck* on typical 386 hardware. My personal experience is that it
> *seriously sucks* on a 486 right now (yes, I have one running right now,
> and a 486DX33 w/ 64M of ram is **painful**).
>
> In fact, it was near impossible to run on a 486-33 w/ 12MB ram when I tried
> it about 12 months ago on what was then -current. I was eventually able to
Huh? I am running 4.2-stable on a 386 with 8MB RAM right now and it works
fine. It is not a speed demon exactly but as gateway/firewall it it works
fine. It doesn't even need to use any swap during boot/login. (The kernel is
quite stripped down but anyway.)
(Alright, world/kernel builds are done on a faster machine and then
installed over NFS.)
> tune things down enough (maxusers 5, 2 gettys, etc) to get it to the point
> that it didn't lock up the VM system during a compile. i386 *pc* hardware
> that supports more than 16MB was pretty rare if I recall. Embedded systems
> are a different issue, but I doubt many people use the FreeBSD cdrom and
> sysinstall to set up an embedded micro-OS install... Heck, even picobsd
> uses its own kernel configs.
>
> Yes, we could make an alternate 386 kernel, and a 386 boot disk etc. But
> I really dont think it is worth while. The user experience would be rather
> uninspiring - I think we'd be far better pointing them to 2.2.x. In fact,
> another net-only point release of 2.2.x to fix the known security holes
> would probably be less cumulative effort than it would take to keep i386
> a viable 'GENERIC' option for the SMPng kernel over the next 6-12 months.
2.2.x ? Why not at least 3.x ? (3.2 was AFAIK the last release that could
be installed on a machine with 8MB RAM or less.)
>
> The bottom line is that I feel the time is just about right to yank i386
> entirely, not just taking it out of GENERIC. But I wont push for that
> (yet :-). But ending the expensive runtime cost of i386 support in
> GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout()
> etc is just not worth it.
>
I don't agree. Removing 386 support from GENERIC I can live with (although I
don't like it much) but removing 386 support entirely would be a bad idea
IMNSHO.
I don't have any experience with -current but -stable works fine on 386 and
I don't see any reason not to use those old computers for something useful.
Better to have separate configs for 386 and 486-and-above.
--
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
David O'Brien
> I don't agree. Removing 386 support from GENERIC I can live with (although I
> don't like it much) but removing 386 support entirely would be a bad idea
> IMNSHO.
> I don't have any experience with -current but -stable works fine on 386 and
Please try -current on a i386 before voicing an opinion. I don't know
why you think experience with one counts for the other.
-stable and -current are now very different beasts.
src/release/scripts/dokern.sh (which strips things out of the GENERIC
kernel for the boot floppy) cuts out a lot more on -current than -stable.
Erik Trulsson
> On Sun, Jan 14, 2001 at 01:00:17PM +0100, Erik Trulsson wrote:
> > I don't agree. Removing 386 support from GENERIC I can live with (although I
> > don't like it much) but removing 386 support entirely would be a bad idea
> > IMNSHO.
> > I don't have any experience with -current but -stable works fine on 386 and
>
> Please try -current on a i386 before voicing an opinion. I don't know
> why you think experience with one counts for the other.
>
> -stable and -current are now very different beasts.
> src/release/scripts/dokern.sh (which strips things out of the GENERIC
> kernel for the boot floppy) cuts out a lot more on -current than -stable.
Point taken. I was mainly (knee-jerk) reacting to the statements that
a 386 was unsuitable for running anything above 2.2.x which is not true.
(Note to self: Think things through a bit more before replying next time.)
Alright, there might be good reasons to drop 386 support from -current. I
don't like it, but I can live with it.
Just remember to change all the places that refer to 'i386' as the generic
name for the architecture if the 386 itself is dropped. :-)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
To Unsubscribe: send mail to majo...@FreeBSD.org
Mario Sergio Fujikawa Ferreira
> On Sun, Jan 14, 2001 at 01:00:17PM +0100, Erik Trulsson wrote:
> > I don't agree. Removing 386 support from GENERIC I can live with (although I
> > don't like it much) but removing 386 support entirely would be a bad idea
> > IMNSHO.
> > I don't have any experience with -current but -stable works fine on 386 and
>
> Please try -current on a i386 before voicing an opinion. I don't know
> why you think experience with one counts for the other.
>
> -stable and -current are now very different beasts.
> src/release/scripts/dokern.sh (which strips things out of the GENERIC
> kernel for the boot floppy) cuts out a lot more on -current than -stable.
To voice a different direction on this.
I believe that by the time current comes out as release (a
year or so), only a few users will say that 386 is a MUST and that
it should be maintained. I myself require 386 support for some
console terminals at Univ, but aware of the compromise necessary
to keep supporting this platform: I would stick with 4.x for this.
Just consider the additional number of platforms that will
be supported when current comes out: sparc, ... It is only predictable
that some oldies will have to be left out; or, otherwise, left in
but without maintainance for sheer lack of time.
Therefore, as long as the 386 removal is not MFCed into
4.x, I don't mind it at all. Dishing out platforms should be left
out as a major number release exercise.
However, if leaving this in won't hurt (improvements,
performance) and there is ppl available/willing to support it. What is
the matter too? :)
Just my 2 cents,
ps: I'll go back into my hibernation tank, my back hurts. Cya.
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved dev...@someotherworldbeloworabove.org
Wilko Bulte
> Wilko Bulte wrote:
> > On Sun, Jan 14, 2001 at 03:15:11AM -0800, Peter Wemm wrote:
> > > The bottom line is that I feel the time is just about right to yank i386
> > > entirely, not just taking it out of GENERIC. But I wont push for that
> >
> > in with a commit to GENERIC. Or ?
>
> I dont make policy. I just said what I think. While I agree with the
Neither do I, or have any desire to do so :)
> commit John did, if I had my way (which I do not) I would have gone
> further. :-)
As I read the various comments, I think the idea that starting with 5.0
dropping support for 386 is a sensible idea that is easily defendable as good
policy. I personally don't think 4.x should go down that road.
cheers,
Wilko
--
| / o / / _ Arnhem, The Netherlands email: wi...@freebsd.org
|/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl
Will Andrews
--11Y7aswkeuHtSBEs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 14, 2001 at 01:30:19PM +0100, Erik Trulsson wrote:
> Point taken. I was mainly (knee-jerk) reacting to the statements that
> a 386 was unsuitable for running anything above 2.2.x which is not true.
> (Note to self: Think things through a bit more before replying next time.)
That makes sense, if there is some realistic proportion to your
assertions that 386 can run up to 4.x just fine. :-)
> Alright, there might be good reasons to drop 386 support from -current. I
> don't like it, but I can live with it.
Of course you can live with it. 3.x support lasted well until about 4.1
or 4.2-RELEASE (within the Project, anyway, and this isn't counting
ports, which still has a few 3.x-isms and is likely to stay that way for
some time longer). Hence, you can assume 4.x will still be supported as
far as bugfixes, security fixes, etc. for another 2 years or so perhaps.
Heck, we're still MFC'ing security fixes into 2.2.x, even though the
last time a release on that branch was done about two and a half years
ago. *SO* I think you can depend on 4.x being a good branch for 386's
(providing of course that they can still run them :-). It will be a
loooong time before support for that branch is dropped (by the Project,
BSDI, and other commercial consultants).
> Just remember to change all the places that refer to 'i386' as the generic
> name for the architecture if the 386 itself is dropped. :-)
I think 'ia32' is a good name. :-)
David? :-)
--=20
wca
--11Y7aswkeuHtSBEs
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6YeQOF47idPgWcsURAgx5AJ9sAIHaVsgi2tTXEsE4QkuL3dWcpQCfSHEK
0WrguhE275fbuSjym1XjYj8=
=akg2
-----END PGP SIGNATURE-----
--11Y7aswkeuHtSBEs--
David O'Brien
> > name for the architecture if the 386 itself is dropped. :-)
>
> I think 'ia32' is a good name. :-)
> David? :-)
I prefer "x86" as that is what the arch was known as until just
recently. Another reason is to have a little more difference between
this an "ia64" just to make reduce mis-reading and to help command-line
completion. :-) Not to mention the code will be shared for the x86-64,
and making a non-Intel designed called "Intel Architecture" is just yucky.
--
-- David (obr...@FreeBSD.org)
GNU is Not Unix / Linux Is Not UniX
Disclaimer: Not speaking for FreeBSD, just expressing my own opinion.
Jordan Hubbard
> probably worthwhile.
Both the installation AND the bindist kernel, right? Otherwise you
could install, but you wouldn't be able to boot the installed system.
That basically argues for putting it back into GENERIC, which
is (I believe) the item in contention here.
- Jordan
Poul-Henning Kamp
>> It would be trivial to add i386 to the install kernel, and
>> probably worthwhile.
>
>Both the installation AND the bindist kernel, right? Otherwise you
>could install, but you wouldn't be able to boot the installed system.
>That basically argues for putting it back into GENERIC, which
>is (I believe) the item in contention here.
Right, that was pointed out to me in "that other channel".
Considering that, I'm in favour if killing the i386 cpu support
entirely in -current.
There is at least a full year until the first semi-reliable 5.0
release is a possibility.
4.x-stable as at least two years in it yet.
I think it's the time to throw i386 over the railing and lower the
waterline a fair bit on -current.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Mark Murray
> release is a possibility.
>
> 4.x-stable as at least two years in it yet.
>
> I think it's the time to throw i386 over the railing and lower the
> waterline a fair bit on -current.
Does it make any sense at all to make 80386 a separate platform
a'la pc98/alpha/ia64? Do enough people care about it?
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
Poul-Henning Kamp
>> There is at least a full year until the first semi-reliable 5.0
>> release is a possibility.
>>
>> 4.x-stable as at least two years in it yet.
>>
>> I think it's the time to throw i386 over the railing and lower the
>> waterline a fair bit on -current.
>
>Does it make any sense at all to make 80386 a separate platform
>a'la pc98/alpha/ia64? Do enough people care about it?
No it doesn't. I think you'll find that running 5.x in less than
32MB is going to be painfull or impossible in the first place.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Erik Trulsson
> > Point taken. I was mainly (knee-jerk) reacting to the statements that
> > a 386 was unsuitable for running anything above 2.2.x which is not true.
> > (Note to self: Think things through a bit more before replying next time.)
>
> That makes sense, if there is some realistic proportion to your
> assertions that 386 can run up to 4.x just fine. :-)
As I said, I am running 4.2 on a 386 that does gateway/firewall duty.
For that purpose it works fine and with minimal swapping. I wouldn't recommend
running Mozilla on it though. :-)
As long as what you are doing isn't too hungry for CPU/memory then 4.2 is
quite usable on a 386 IMO.
--
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
To Unsubscribe: send mail to majo...@FreeBSD.org