Date: Thu, 23 Feb 95 10:02:05 MST From: terry@cs.weber.edu (Terry Lambert) To: rmallory@wiley.csusb.edu (Rob Mallory) Cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE Message-ID: <9502231702.AA03135@cs.weber.edu> In-Reply-To: <199502230225.AA01350@wiley.csusb.edu> from "Rob Mallory" at Feb 22, 95 06:25:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> question: When I put the cdrom in to install, what the hell am I going to > do with all this VME-bus crap in my /sys tree? I dont think I will > ever be compiling something with VLIW's on my 386! [ ... ] > What about the people who want only an arch-specific /sys tree? > What if I want the whole enchilada so I can compile a new kernel for > my lonely 486 on my 250Mhz Alpha? The second question will probably be answered "it's in there!". The first question is tougher. I think one of the major mistakes that USL made in the SVR4.2 ES/MP source tree (hmmm... did that ever get put anywhere but UnixWare?) was that you extracted a buildable tree from a combination of three source repositories, two of them dependent on the actual machine you would be building for. Think about this a second. There was no reliable reverse-index mechanism for getting problem fixes back into an overall tree. One of my biggest complaints with UnixWare was that it didn't meet SVID III (I've bitched about this before). Basically, any UNIX as fo SVR4 was no longer SVID compliant and therefore no longer "System V" because of the distinction between "system clock frequency" and "clock update frequency". In other words, the getitimer(RT), setitimer(RT), and gettimeofday(RT) functions were screwed because interval timers had only a 10ms resoloution instead of 1sec/"system clock frequency" resoloution (if you don't think this is bad, then please consider the concept "double click" and then consider the concept "select timeout"). Finally I got it working on my personal machine with an extracted tree containing only Intel processer components. To get back to the point, fixing this would have required an interface change, but with a buildable tree an interface change was not possible; you could only do an interface change with the whole tree (and if you didn't have that you were screwed). And even if you had one, you were in for a 36 hour process of the extraction a full build necessary to see if the change worked, and you would only have verification on your personal architecture anyway: There was the assumption that all supported hardware would be available to whoever was doing this sort of work. And people call the *BSDs elitest now! I think FreeBSD should *run* the other direction from this type of partitioning. If it doesn't, there will be no way to get the changes needed for support of a particular architecture rolled back into the tree. Integration is a real (manual labor) bitch in this type of setup. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502231702.AA03135>