No Michael, it's not a bug. It's a design limitation. All designs have them. Our design will too. I'm quite weary of people using the word "bug" to describe any consequence they don't like. It waters down the meaning to the point that it's no longer useful. A true bug is when the software fails to meets the expectations for the environment it was intended for. The main reason I dislike people using the term "bug" so generally is that it puts an unspoken pressure on programmers to figure out all future contingencies that will occur with their software. That is absolutely impossible to do. The desire to try, however, wastes a lot of time and generally produces code bloat. Jeez, we haven't even hit this design limitation yet (how many users have 1 gig+ RAM at the moment?) and it's already called a bug. Don't get me wrong, this memory limitation is a problem and it will start affecting users in the next year or two. It does need to be addressed in the design of OpenBeOS. The real lesson here is that every design decision made has consequences. Document those decisions! Inevitably, one of more of them will turn out to prove limiting and will have to be re-engineered. > >Maybe you are not aware of to whom you speak. >JBQ was an employee of Be. >An excellent engineer and a person who has a very advanced >knowledge of kernel engineering and issues. > >>> The memory bug that keeps BeOS from using more than 1 gig >> >>It's not a bug. > >It is a huge bug. I am learning what caused this right now, as I look at the >kernel issues. And it is a bug. No question. Now - Be knew about it and probably >didn't care because up until the last year or so memory was not cheap. A >gig was beyond the realm of most people. > >>Physical memory limitations in BeOS have nothing to do with memory model >>but with address space management policies. > >That is not true. Very simply, Be chose a physical memory model that has limitations. > >> Address space != Physical Memory Size >> >> >>> *plus* with some additional virtual paging code the model can be extended >>to >>> super-pages or 4 gig blocks (or parts of blocks) swapped from the HD. >>> Depends on how big everyone thinks things will get in 2 years. >> >>This full paragraph makes me think that you don't fully understand VM >>management. > >Trust me - you are wrong here. > >>> Just make sure to use 64 bit counters in all your structs so that when >>BeOS >>> requires porting to wider architecture the underlying framework can >>support >>> the move. >> >>That's the wrong policy... you must make sure that all your scalar types >>are properly typedef'ed instead of using shorts, ints, longs all over >>the place. Forcing them to be 64 bits imposes unrequired overhead. >>Properly typedefing allows you to move to another architecture without >>putting unrequired overhead. > >What he is saying is that anything that would need to be larger on a different >machine is 64 bit. Not that every number you ever use is 64 bit. > >>manuel, [ back to lurk mode ] >> >>> (ie: 64 bit MPU) >>> >>> Peter >>> >> >> >> > > > >