Re: [9fans] [GSOC] fast kernel compile
On 6 May 2014 03:19, Charles Forsyth charles.fors...@gmail.com wrote: the kernel source is less than the size of their include files also, quite a bit that is unaccountably still in other kernels (because Unix did it exactly that way in the 1970s on a PDP-11) is in user space or across a network in Plan 9. of course, that's balanced by browsers now easily rivalling the kernels you mention for complexity and certainly size, with their brutalist programming architectures.
Re: [9fans] [GSOC] fast kernel compile
also, quite a bit that is unaccountably still in other kernels (because Unix did it exactly that way in the 1970s on a PDP-11) I think that unaccountably is a bit harsh. There is A L O T of old Unix software that still just compiles and works out of the box on Linux, Solaris, *BSD. There is a lot of value to that, when what you care about is getting your work done (KTBR - Keep The Business Running). I well understand that this community is less concerned about that, but this community should also be open minded enough to understand those kinds of concerns. Arnold
Re: [9fans] [GSOC] fast kernel compile
Charles Forsyth charles.fors...@gmail.com wrote: On 6 May 2014 09:38, arn...@skeeve.com wrote: I think that unaccountably is a bit harsh. I was talking about kernels and kernel mechanisms. Fair enough then. Thanks, Arnold
Re: [9fans] [GSOC] fast kernel compile
On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote: On 6 May 2014 03:19, Charles Forsyth charles.fors...@gmail.com wrote: Of course, that's balanced by browsers now easily rivalling the kernels you mention for complexity and certainly size, with their brutalist programming architectures. And it is even not a problem reserved to Plan9. On a NetBSD, I tried to compile chrome. The PC had even not enough _memory_ to link the thing... -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] [GSOC] fast kernel compile
On Tue, May 06, 2014 at 11:39:03AM +0200, tlaro...@polynum.com wrote: On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote: On 6 May 2014 03:19, Charles Forsyth charles.fors...@gmail.com wrote: Of course, that's balanced by browsers now easily rivalling the kernels you mention for complexity and certainly size, with their brutalist programming architectures. And it is even not a problem reserved to Plan9. To explain in my answer the link with the Plan9: browsers are so huge beast nowadays, that the lack of a modern browser on Plan9 will rapidly become a problem for others than Plan9 since these things are so huge and complex and need so many pieces than even on Unix like systems, one may not be even able to link the thing. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] [GSOC] fast kernel compile
On 6 May 2014 10:52, tlaro...@polynum.com wrote: like systems, one may not be even able to link the thing. Recently I saw that the source of the underlying engine for (I think) Chrome had roughly halved in size. I'm not sure if that's the same version as the you've got. They'd done trendy things like devise and implement suitable abstractions for different parts of the graphics/browsing model, and implemented those in a modular way, and surprisingly, it got simpler and smaller. It's actually quite hard to do with the browser, because the standard specifications are not well-suited for either writing HTML or implementing it, so it's hard to see what abstractions might actually be needed or would work.
Re: [9fans] [GSOC] fast kernel compile
On Tue May 6 04:39:11 EDT 2014, arn...@skeeve.com wrote: also, quite a bit that is unaccountably still in other kernels (because Unix did it exactly that way in the 1970s on a PDP-11) I think that unaccountably is a bit harsh. There is A L O T of old Unix software that still just compiles and works out of the box on Linux, Solaris, *BSD. There is a lot of value to that, when what you care about is getting your work done (KTBR - Keep The Business Running). my experience is the opposite. basic c library functions have been built into the compiler, and the types have changed. - erik
Re: [9fans] [GSOC] fast kernel compile
Recently I saw that the source of the underlying engine for (I think) Chrome had roughly halved in size. I'm not sure if that's the same version as the you've got. They'd done trendy things like devise and implement suitable abstractions for different parts of the graphics/browsing model, and implemented those in a modular way, and surprisingly, it got simpler and smaller. It's actually quite hard to do with the browser, because the standard specifications are not well-suited for either writing HTML or implementing it, so it's hard to see what abstractions might actually be needed or would work. that, and they gave up on being compatable with apple's webkit. - erik
Re: [9fans] [GSOC] fast kernel compile
Plan 9 compilers are fast, Unix compilers are slow. Plan 9 compilers compile less because the philosophy regarding #include files is different. Plan 9 programs (including the kernel) are small, Unix programs are large. The Plan 9 kernel has less lines of code than Unix configure scripts. The question is not why does Plan 9 compile so quickly, is what catastrophe happened in Unix making everything so slow and large. -- Aram Hăvărneanu
Re: [9fans] [GSOC] fast kernel compile
On 05/06/2014 05:24 PM, Aram Hăvărneanu wrote: The question is not why does Plan 9 compile so quickly, is what catastrophe happened in Unix making everything so slow and large. Well, you know there is a lot of noise for linux kernel about keeping it compatible for even very old versions of apps binaries, while in reality, linux apps binaries are very rare to be executed even from one distro to another... Same story that happens to ms to keep compatibility for dos, then for first win apis, then for second, then oops 640KB is not enough ;)
Re: [9fans] [GSOC] fast kernel compile
that, and they gave up on being compatable with apple's webkit. It's not just about compatibility: they shrunk the scope of the problem they're trying to solve by quite a bit. WebKit aims to be a sort of general-purpose web rendering engine; Blink (Google's fork) is much more closely targeting Chrome friends. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] [GSOC] fast kernel compile
Well, you know there is a lot of noise for linux kernel about keeping it compatible for even very old versions of apps binaries, while in reality, linux apps binaries are very rare to be executed even from one distro to another... most of the 2ed binaries still run on modern 386 kernels. (that's what 20 years?) i'd be curious if anyone can find a linux binary from that time frame that can be run on a 3.x kernel. double super bonus for dynamicly linked executables. - erik
[9fans] teg2 kbd
does anyone know why the teg2 keyboard code has these two extra scan code tables? case 5: *r = kbtabctrlesc1[*sc]; return 1; case 6: *r = kbtabshiftesc1[*sc]; return 1; - erik
Re: [9fans] [GSOC] fast kernel compile
plan9 also has /n/dump, which is great to find out if and when suff has regressed. :) having self contained program binaries is great. -- cinap
[9fans] [GSOC] plan9 which arch code to use?
Dear all, I was confused by one experiment which is done today. My machine is x86_64 and I run Plan9 inside KVM. According to my understanding, operating system should detect which hardware platform it is running (x86, sparc, etc) and automatically invoke corresponding arch-dependent codes. But, when I echo $cputypes, it is 386! I also browse some kernel config file in /sys/src/9/pc, it seems that plan9 forces to use 386 for Intel cpus (right?). Please tolerate if I made stupid mistakes, I just wonder how to make a amd64 kernel? (My hardware already supports that.) Thanks, Yan -- Think big; Dream impossible; Make it happen.
Re: [9fans] [GSOC] plan9 which arch code to use?
official plan9 has no amd64 kernel in the distribution. use 9atom or 9front. -- cinap
Re: [9fans] teg2 kbd
yep, that was for me. weird uk usb keyboards. nearly all the keyboard works but the pipe/backslash key is a special. the patch appeared twice, once in the pc keyboard driver and once for the raspberry pi (shared with omap). there is also someone who had a similar problem with german keyboards in the archives, though their fix was a little crude (sorry). i worried at the time that adding two entire pages of lookup table seemed silly to support one key with three functions, but memory is cheap enough that 2 x 256 bytes is not outrageous. the 8042 is dead (ish) steve On 6 May 2014, at 17:06, erik quanstrom quans...@quanstro.net wrote: does anyone know why the teg2 keyboard code has these two extra scan code tables? case 5: *r = kbtabctrlesc1[*sc]; return 1; case 6: *r = kbtabshiftesc1[*sc]; return 1; - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
On 6 May 2014 22:00, yan cui ccuiy...@gmail.com wrote: But, when I echo $cputypes, it is 386! where the hardware can do either, the kernel you boot chooses the cputype to suit itself. /sys/src/9/pc is only 386 (ie, 32-bit x86). another directory is used for amd64 (ie, 64-bit x86). you can use the 386 kernel to compile and install the /amd64 environment though, which you'll need to do before running an amd64 kernel.
Re: [9fans] [GSOC] plan9 which arch code to use?
Got it, Thanks Cinap! 2014-05-06 17:33 GMT-04:00 cinap_len...@felloff.net: official plan9 has no amd64 kernel in the distribution. use 9atom or 9front. -- cinap -- Think big; Dream impossible; Make it happen.
Re: [9fans] [GSOC] plan9 which arch code to use?
OK, I will try to do that. 2014-05-06 17:47 GMT-04:00 Charles Forsyth charles.fors...@gmail.com: On 6 May 2014 22:00, yan cui ccuiy...@gmail.com wrote: But, when I echo $cputypes, it is 386! where the hardware can do either, the kernel you boot chooses the cputype to suit itself. /sys/src/9/pc is only 386 (ie, 32-bit x86). another directory is used for amd64 (ie, 64-bit x86). you can use the 386 kernel to compile and install the /amd64 environment though, which you'll need to do before running an amd64 kernel. -- Think big; Dream impossible; Make it happen.
Re: [9fans] [GSOC] plan9 which arch code to use?
On 6 May 2014 22:47, Charles Forsyth charles.fors...@gmail.com wrote: you can use the 386 kernel to compile and install the /amd64 environment though, which you'll need to do before running an amd64 kernel. more precisely, do cd /sys/src objtype=amd64 mk install
Re: [9fans] [GSOC] plan9 which arch code to use?
On 6 May 2014 22:56, Charles Forsyth charles.fors...@gmail.com wrote: more precisely, do cd /sys/src objtype=amd64 mk install actually, i use cd /sys/src; objtype=amd64 mk -k install so that if something's broken, it will build as much as it can.
Re: [9fans] [GSOC] plan9 which arch code to use?
nobody expects the spanish inquisition :) -- cinap
Re: [9fans] [GSOC] plan9 which arch code to use?
Quoting yan cui ccuiy...@gmail.com: My machine is x86_64 and I run Plan9 inside KVM. The architecture of the hypervisor has little bearing on the architecture of the KVM guest environment. Check your kvm configuration (or the options passed to the qemu process) to see which cpu has been specified for the guest. khm
Re: [9fans] [GSOC] plan9 which arch code to use?
On Tue May 6 18:26:58 EDT 2014, ccuiy...@gmail.com wrote: Dear all, I was confused by one experiment which is done today. My machine is x86_64 and I run Plan9 inside KVM. According to my understanding, operating system should detect which hardware platform it is running (x86, sparc, etc) and automatically invoke corresponding arch-dependent codes. But, when I echo $cputypes, it is 386! I also browse some kernel config file in /sys/src/9/pc, it seems that plan9 forces to use 386 for Intel cpus (right?). Please tolerate if I made stupid mistakes, I just wonder how to make a amd64 kernel? (My hardware already supports that.) good question. /sys/src/9/pc is a 386 kernel. it runs 386 code on anything that at least supports a 386 regardless of the hardware support. if you think about it, supporting more than one instruction set with a single kernel has some added difficulties. as cinap mentions, for a 64-bit kernel, your options are 9atom or 9front. since i work with 9atom, i'll speak to it. you can just install 64-bit with no muss or fuss, if the hardware is supported. let me know if there are issues. if you already have something working, then nevermind. :-) - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 01:40, erik quanstrom quans...@quanstro.net wrote: your options are 9atom or 9front. well no, no they aren't.
Re: [9fans] [GSOC] plan9 which arch code to use?
Quoting Charles Forsyth charles.fors...@gmail.com: On 7 May 2014 01:40, erik quanstrom quans...@quanstro.net wrote: your options are 9atom or 9front. well no, no they aren't. exactly what value is that comment supposed to add to anyone's day
Re: [9fans] [GSOC] plan9 which arch code to use?
your options are 9atom or 9front. well no, no they aren't. What are the other options? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 02:12, Kurt H Maier k...@sciops.net wrote: well no, no they aren't. exactly what value is that comment supposed to add to anyone's day sorry, i meant that isn't the full set of relevant choices.
Re: [9fans] [GSOC] plan9 which arch code to use?
mkdir -p /amd64/bin/^(ape auth aux bitsy dial disk fossil fs games ip ndb oventi pub replica upas usb venti aux/jot aux/style ip/httpd) /amd64/lib/ape The Bell Labs distribution does not seem to have a libc/amd64. It's a bit of a show stopper. I could also be mistaken and a different amd64 is being looked for. ++L
Re: [9fans] [GSOC] plan9 which arch code to use?
The Bell Labs distribution does not seem to have a libc/amd64. You just have to apply the following patches (from Nix): hget http://www.9legacy.org/9legacy/patch/amd64.diff | ape/patch -p0 hget http://www.9legacy.org/9legacy/patch/amd64-fix.diff | ape/patch -p0 -- David du Colombier
