Re: support for larger memory
Julian Elischer wrote: > One presumes that the BSDI binaries fail without the diff? :-) Yes, that's been confirmed by lots of people, myself included. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
One presumes that the BSDI binaries fail without the diff? :-) julian On Wed, 31 Mar 1999, Thomas Stephens wrote: > John Polstra wrote: > >In article <199903302319.paa43...@apollo.backplane.com>, > >Matthew Dillon wrote: > >> > >> Has anyone tried implementing the %ebx solution yet? > > > >Not as far as I know. I was hoping that somebody who cared about > >BSD/OS compatibility would pick up the description of the fix, test > >it, and submit diffs. No takers, so far. :-( > > I'll bite. I tried your fix this morning, and it's worked without a > problem so far. I've just upgraded the world (had only built a kernel > earlier), and haven't done any rigorous testing, but it looks good. I > use the AT&T ksh for BSD/OS as my standard shell, which should be a > reasonable test, but haven't got access to BSD/OS itself, so don't have > much to test beyond the AT&T tools. > > Unless something goes wrong, I'll probably submit the diffs within the > next day or so. > > Thomas Stephens > t...@stephens.org > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
Thomas Stephens wrote: > I tried your fix this morning, and it's worked without a problem > so far. I've just upgraded the world (had only built a kernel > earlier), and haven't done any rigorous testing, but it looks good. > I use the AT&T ksh for BSD/OS as my standard shell, which should be > a reasonable test, but haven't got access to BSD/OS itself, so don't > have much to test beyond the AT&T tools. > > Unless something goes wrong, I'll probably submit the diffs within > the next day or so. Hey, thanks a million! If you'd like to send your diffs to me when they're ready, I'll be happy to review them and commit them for you. I have some BSD/OS binaries I can try here, too. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
John Polstra wrote: >In article <199903302319.paa43...@apollo.backplane.com>, >Matthew Dillon wrote: >> >> Has anyone tried implementing the %ebx solution yet? > >Not as far as I know. I was hoping that somebody who cared about >BSD/OS compatibility would pick up the description of the fix, test >it, and submit diffs. No takers, so far. :-( I'll bite. I tried your fix this morning, and it's worked without a problem so far. I've just upgraded the world (had only built a kernel earlier), and haven't done any rigorous testing, but it looks good. I use the AT&T ksh for BSD/OS as my standard shell, which should be a reasonable test, but haven't got access to BSD/OS itself, so don't have much to test beyond the AT&T tools. Unless something goes wrong, I'll probably submit the diffs within the next day or so. Thomas Stephens t...@stephens.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
In article <199903302319.paa43...@apollo.backplane.com>, Matthew Dillon wrote: > > Has anyone tried implementing the %ebx solution yet? Not as far as I know. I was hoping that somebody who cared about BSD/OS compatibility would pick up the description of the fix, test it, and submit diffs. No takers, so far. :-( John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
David Greenman wrote: > BSD/OS compatibility for v2.0 static binaries can be had again with a >few modifications. Someone with access to BSD/OS v2.0 binaries, time, and >appropriate knowledge, just needs to make them. > The brokeness actually comes from a design screwup that BSDI made in >the v2.0 crt0 which they apparantly later fixed in v3.0. We should be able >to run v3 and later static binaries. We've never had support for any >version of their shared binaries. Speaking of which, are there any plans to support BSD/OS 4.0 ELF binaries, either static or shared? I expect most binaries for BSD/OS will eventually be distributed in ELF format, but the likelihood that they'll use dynamic linking complicates things. I'd be willing to make an effort to contribute, but haven't got access to BSD/OS 4.0 (don't know if I've got the requisite knowledge either). None of the BSD/OS binaries I use have been converted to ELF yet, but I'll certainly miss them if they are (though, if they use shared libraries, it may not matter anyway). Thomas Stephens t...@stephens.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
:> So, I'm curious, why is it that we needed to break BSDI compatibility in :>order to support large memory configurations. It would seem that the two :>shouldn't be mutually exclusive. : :Or, perhaps, we broke BSDI compatibility for a lot of people (?) at the :expense of those few people who are running > 1GB... : : : :Brian Has anyone tried implementing the %ebx solution yet? -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
On Tue, 30 Mar 1999, Brian Handy wrote: > [Grumbling about BSDI compatibility] I take all that back. Well, all except the part about grumbling about my own network here, I'm just feeling grumpy and took it out on random passerby. :-) Happy trails, Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
> So, I'm curious, why is it that we needed to break BSDI compatibility in >order to support large memory configurations. It would seem that the two >shouldn't be mutually exclusive. Or, perhaps, we broke BSDI compatibility for a lot of people (?) at the expense of those few people who are running > 1GB... Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
> Time and time again we have all seen people get bit in the rear because >BSDI compatibility was broken. Broken for a good cause, mind you, because >FreeBSD seemed to lose a little of that "power to serve" when it died >horribly on newer servers :) > So, the good news is, we can now support large memory configurations >(and I recall that 4G might not be that far off). The bad news is, the >fairly decent number of programs which are available for BSDI but not >FreeBSD won't run on FreeBSD now. > > Anyway, we all know that. But what I would like to know is: how does >BSDI support large memory configurations? I'm confused on how it is that >the $1000+ commercial BSD derivative can't handle running on newer >servers (although it is pleasing to think a $0 BSD derivative can :) ) >Surely, this cannot be the case, though. > > So, I'm curious, why is it that we needed to break BSDI compatibility in >order to support large memory configurations. It would seem that the two >shouldn't be mutually exclusive. BSD/OS compatibility for v2.0 static binaries can be had again with a few modifications. Someone with access to BSD/OS v2.0 binaries, time, and appropriate knowledge, just needs to make them. The brokeness actually comes from a design screwup that BSDI made in the v2.0 crt0 which they apparantly later fixed in v3.0. We should be able to run v3 and later static binaries. We've never had support for any version of their shared binaries. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
Kelly Yancey wrote: > > Time and time again we have all seen people get bit in the rear because > BSDI compatibility was broken. Broken for a good cause, mind you, because > FreeBSD seemed to lose a little of that "power to serve" when it died > horribly on newer servers :) > So, the good news is, we can now support large memory configurations > (and I recall that 4G might not be that far off). The bad news is, the > fairly decent number of programs which are available for BSDI but not > FreeBSD won't run on FreeBSD now. > > Anyway, we all know that. But what I would like to know is: how does > BSDI support large memory configurations? I'm confused on how it is that > the $1000+ commercial BSD derivative can't handle running on newer > servers (although it is pleasing to think a $0 BSD derivative can :) ) > Surely, this cannot be the case, though. > > So, I'm curious, why is it that we needed to break BSDI compatibility in > order to support large memory configurations. It would seem that the two > shouldn't be mutually exclusive. > > Thanks, > > Kelly > ~kby...@posi.net~ > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message The problem is that in the default configuration the two address spaces, (kernel and user) are arranged to use non-intersecting address spaces. This allows the kernel to directly read from the user's space, and also means that the address space need not be changed when the process goes to kernel mode, saving valuable TLB flushes etc. Unfortunatly as memory has grown, the kernels 'sparse' method of allocating addresses within it's space has required more and more space to keep track of potentially larger and larger structures. Eventually the space needed grew more that that 'left over' above the user space. This required shrinking the 'address space' seen by the application program which is, unfortunatly, not completely transparent to the user application binary. One answer would be to allow the kernel space and user space to overlap. THis is what the original Unix systems did, making use of the PDP11-60's ability to hold separate address spacess for the executinve and application programs. The use of copyin() and copyout(), rather than direct copies, is both a throwback to this time, and at the same time "insurance" that BSD will be able to run pretty much without modification on architectures where such separation is mandated, or, should the situation arise, we decide to split the tow spaces, even on architectures where it is presently not done (e.g. PC). In the specific case of BSDI compatibility, I believe that there is a patch available that allows BSDI binaries to run in the smaller addres space. (I vaguely remember it involving the initial value of a register at exec time). This suggests that the BSDI runtime libraries were written with an eye to the future where they may themselves need to do a similar thing. Knowing the people involved, I'd say that this is not unlikely. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
support for larger memory
Time and time again we have all seen people get bit in the rear because BSDI compatibility was broken. Broken for a good cause, mind you, because FreeBSD seemed to lose a little of that "power to serve" when it died horribly on newer servers :) So, the good news is, we can now support large memory configurations (and I recall that 4G might not be that far off). The bad news is, the fairly decent number of programs which are available for BSDI but not FreeBSD won't run on FreeBSD now. Anyway, we all know that. But what I would like to know is: how does BSDI support large memory configurations? I'm confused on how it is that the $1000+ commercial BSD derivative can't handle running on newer servers (although it is pleasing to think a $0 BSD derivative can :) ) Surely, this cannot be the case, though. So, I'm curious, why is it that we needed to break BSDI compatibility in order to support large memory configurations. It would seem that the two shouldn't be mutually exclusive. Thanks, Kelly ~kby...@posi.net~ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
