Re: [9fans] [GSOC] plan9 which arch code to use?
You just have to apply the following patches (from Nix): Thank you, that worked well (so far, the build is still running), although I have a spim (0) object type in my mkfile.proto that threw a (small) spanner in the works. ++L
[9fans] [GSOC] plan9 which arch code to use?
Out of curiosity is there a reason that the patches for a 64bit install never ended up in the main plan9 codebase?
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 06:14, lu...@proxima.alt.za wrote: 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. I did not know that. I've attached a tar file, of what I'm using. I'll compare it to the patches that David posted. Clearly it would help to push the files into sources. amd64.tgz Description: GNU Zip compressed data
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 09:38, Riddler riddler...@gmail.com wrote: Out of curiosity is there a reason that the patches for a 64bit install never ended up in the main plan9 codebase? The full story is much more complicated, but briefly, the switch to 64 bits offered a chance to revisit the kernel implementation, but the version that was closest to plan 9 was incomplete on amd64, and never released except for powerpc where most of the work was done, and the other forks that were released for amd64 were more experimental (eg, Nix). A year or two back a further attempt was made to retrace and set out again, because so much old crud had got added back in, but that stalled when several of us ran out of time or got too busy. At the time, none of us was interested in adding yet more unfinished or unpolished software to the big cloudy bitbuckets. I'm sure at least one of those will be back soon. There was, however, a parallel effort to allow a more conventional licence, which did finally prosper.
Re: [9fans] [GSOC] plan9 which arch code to use?
+++ /sys/src/ape/lib/ap/amd64/atom.s @@ -0,0 +1,75 @@ +TEXT ainc(SB), $0 /* long ainc(long *); */ + MOVLaddr+0(FP), BX the comment is wrong. it's int ainc(int*) further down the definition of casp, cas64 is really wrong. (it only considers the low 32-bits) also why have atom.s in ape? - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote: the comment is wrong. it's int ainc(int*) h% grep ainc /sys/include/libc.h long ainc(long*); h% grep ainc /n/sources/plan9/sys/include/libc.h long ainc(long*);
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 04:47:05 EDT 2014, charles.fors...@gmail.com wrote: On 7 May 2014 06:14, lu...@proxima.alt.za wrote: 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. I did not know that. I've attached a tar file, of what I'm using. I'll compare it to the patches that David posted. Clearly it would help to push the files into sources. alternately, the source is available on sources.9atom.org. /n/atom/plan9/... is there a reason for /amd64/include/gnu/*? - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote: the comment is wrong. it's int ainc(int*) h% grep ainc /sys/include/libc.h long ainc(long*); h% grep ainc /n/sources/plan9/sys/include/libc.h long ainc(long*); shouldn't that be aincl? these definitions were added to libc.h very late in the game (2013), and iirc, the only place ainc was actually used was the 64-bit kernel, and its definition was int ainc(int*). - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
I see that I had better explain. I am yan cui's mentor for GSoC on a particular project that is starting with some code that I wrote, and it will greatly assist me initially if he and I are using the same basic source code for the system and the kernel. Sources provides a conservative base for the former, and I am providing the latter, which will end up on googlecode as a working environment, but one step at a time.
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 05:21:03 EDT 2014, charles.fors...@gmail.com wrote: I see that I had better explain. I am yan cui's mentor for GSoC on a particular project that is starting with some code that I wrote, and it will greatly assist me initially if he and I are using the same basic source code for the system and the kernel. Sources provides a conservative base for the former, and I am providing the latter, which will end up on googlecode as a working environment, but one step at a time. that makes sense. and good luck. it's an interesting project. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
also why have atom.s in ape? This is what was done on 386. /n/sources/plan9/sys/src/ape/lib/ap/386/atom.s -- David du Colombier
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 05:24:00 EDT 2014, 0in...@gmail.com wrote: also why have atom.s in ape? This is what was done on 386. /n/sources/plan9/sys/src/ape/lib/ap/386/atom.s that begs the question. why put the atom functions in ape for any architecture? - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
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 I should have commented further. The first patch is a copy from the original Nix files written by jmk. The second is an attempt to synchronize with the changes made in Plan 9 on September 2013. -- David du Colombier
Re: [9fans] [GSOC] plan9 which arch code to use?
!/bin/upas/marshal -s 'Re: [9fans] [GSOC] plan9 which arch code to use?' -R /mail/fs/mbox/1815 9fans@9fans.net On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote: the comment is wrong. it's int ainc(int*) h% grep ainc /sys/include/libc.h long ainc(long*); h% grep ainc /n/sources/plan9/sys/include/libc.h long ainc(long*); shouldn't that be aincl? these definitions were added to libc.h very late in the game (2013), and iirc, the only place ainc was actually used was the 64-bit kernel, and its definition was int ainc(int*). sent too soon. so this allows a reference count to be just an int. i also felt int ainc(int*) fit better with the other atom(2) functions, which have a suffix of 32, 64, l or p added when the argument is not an int. so what i did assumes that there could be an aincl, aincp, ainc32, ainc64, but there just isn't. the definition long ainc(long*) seems to assume there is only one ainc. and i can't see why the argument should be a long. that would make it 64-bits in an lp64 model, which may not be what was intended. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
I should have commented further. The first patch is a copy from the original Nix files written by jmk. The second is an attempt to synchronize with the changes made in Plan 9 on September 2013. Based entirely on these patches, plus a little tweaking because I've updated APE to be closer to NetBSD for sys/socket.h, lib/bsd/connect.c, lib/bsd/getpeername.c and lib/bds/getsockname.c, I get pretty far along, failing on: inittraps: undefined: sigemptyset in inittraps while building pdksh. I'm sure I can track this down, but perhaps somebody has already taken care of this issue? I haven't yet checked Charles' posting. ++L
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 12:13, lu...@proxima.alt.za wrote: I haven't yet checked Charles' posting. that won't have anything to do with wider APE support.
Re: [9fans] [GSOC] plan9 which arch code to use?
Quoting Charles Forsyth charles.fors...@gmail.com: I see that I had better explain. I am yan cui's mentor for GSoC on a particular project that is starting with some code that I wrote, and it will greatly assist me initially if he and I are using the same basic source code for the system and the kernel. Sources provides a conservative base for the former, and I am providing the latter, which will end up on googlecode as a working environment, but one step at a time. Sorry, wasn't aware this is an SP9SSS affair. Might be useful to mention that fact when you're telling your junior initiates things that mere mortals aren't allowed to fathom. khm
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 13:59, Kurt H Maier k...@sciops.net wrote: Sorry, wasn't aware this is an SP9SSS affair. nothing secret; just what happened.
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 07:15:46 EDT 2014, lu...@proxima.alt.za wrote: I should have commented further. The first patch is a copy from the original Nix files written by jmk. The second is an attempt to synchronize with the changes made in Plan 9 on September 2013. Based entirely on these patches, plus a little tweaking because I've updated APE to be closer to NetBSD for sys/socket.h, lib/bsd/connect.c, lib/bsd/getpeername.c and lib/bds/getsockname.c, I get pretty far along, failing on: inittraps: undefined: sigemptyset in inittraps while building pdksh. I'm sure I can track this down, but perhaps somebody has already taken care of this issue? I haven't yet checked Charles' posting. from my perspective, it's hard to see this patch issue. 9atom is my attempt at bringing the system together with a amd64 port. it's not perfect, but that's why i've always encouraged patches. i don't want it to be a solo effort; it should be a community project. (9atom is actually incorporated as a non profit in the US.) could explain why these patches made sense for you rather than the atom stuff? - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 09:37:51 EDT 2014, charles.fors...@gmail.com wrote: On 7 May 2014 13:59, Kurt H Maier k...@sciops.net wrote: Sorry, wasn't aware this is an SP9SSS affair. nothing secret; just what happened. so, asking myself as well as the list, what steps can we take to prevent working so much at cross purpose in the future? i'm not interested in whatever water went under the bridge. it is assuredly wet. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
could explain why these patches made sense for you rather than the atom stuff? Mostly just a mixture of arrogance and ineptitude that says I want to do this my way? For real, I can't resist a convergence challenge. The image I had in my mind was of an amd64 environment within the Bell Labs release (i386) that would allow me to build either 9atom or 9front releases with minimal adjustments. It probably needs one additional layer above the conventional Bell Labs /sys/src, but it seems feasible. I confess I did not think very hard about it, but the instructions just look so temptingly simple... ++L
Re: [9fans] [GSOC] plan9 which arch code to use?
Mostly just a mixture of arrogance and ineptitude that says I want to do this my way? For real, I can't resist a convergence challenge. The image I had in my mind was of an amd64 environment within the Bell Labs release (i386) that would allow me to build either 9atom or 9front releases with minimal adjustments. if everybody does their own thing, perhaps we spend all our collective time doing the same thing, and no progress is made? just an observation. and obviously there are tradeoffs. i'll give you that i love to do things my self. let me know if you see anything in atom that causes issues. certainly a goal is to keep these to a minimum. the atom stuff of course came about for three reasons that were not solved elsewhere at the time: working with certain hardware, 21-bit runes, and production amd64 support. i think all of these are at least to some extent still valid. there are gaps in the distribution's 21-bit rune support, and the hardware support gap may have increased. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
if everybody does their own thing, perhaps we spend all our collective time doing the same thing, and no progress is made? Most of the duplicated effort never seems to make it out to the public, so for users, the point is often moot. The forks of Plan 9 exist mainly because people want to run Plan 9 on their computers. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 14:33:08 EDT 2014, s...@9front.org wrote: if everybody does their own thing, perhaps we spend all our collective time doing the same thing, and no progress is made? Most of the duplicated effort never seems to make it out to the public, so for users, the point is often moot. right, perhaps because it is duplicated and there is no one version. The forks of Plan 9 exist mainly because people want to run Plan 9 on their computers. would be nice to put all the hardware support together. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
The forks of Plan 9 exist mainly because people want to run Plan 9 on their computers. would be nice to put all the hardware support together. It's all available for anyone to take from the public repositories. I don't think any of the forks have placed additional restrictions on what can be done with their changes. Enjoy. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
would be nice to put all the hardware support together. It's all available for anyone to take from the public repositories. I don't think any of the forks have placed additional restrictions on what can be done with their changes. Enjoy. you're missing my point. it's not particularly useful as a tinker-toy set. especially when there are 10 wheels and 1 stick. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
you're missing my point. it's not particularly useful as a tinker-toy set. especially when there are 10 wheels and 1 stick. What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote: you're missing my point. it's not particularly useful as a tinker-toy set. especially when there are 10 wheels and 1 stick. What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sure that's fine. but if everyone does that, plan 9 will fall into disrepair, because nobody's willing to do the work. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
Who would you like to volunteer to do all of this work, that's what it seems like you're trying to do. On May 7, 2014 4:09 PM, erik quanstrom quans...@quanstro.net wrote: On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote: you're missing my point. it's not particularly useful as a tinker-toy set. especially when there are 10 wheels and 1 stick. What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sure that's fine. but if everyone does that, plan 9 will fall into disrepair, because nobody's willing to do the work. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sure that's fine. but if everyone does that, plan 9 will fall into disrepair, because nobody's willing to do the work. What are you talking about? If everyone fixes Plan 9 to work on their computers then Plan 9 will fall into disrepair? What has changed is this: Code is being made available because some people decided to make their code available. Notice the key phrase: make their code available. Anyone can take that code and do with it whatever they want. The major result is that now Plan 9 now runs on more computers. Some bugs got fixed. Some new (useful) programs got written. These things only happened because those people made their changes available. Otherwise, we wouldn't even know it had been done. I have trouble seeing this as a net loss. On the other hand, innuendo about code that may or may not ever be released doesn't help anyone, and at this point serves as little more than the traditional way to end a conversation. By now this tradition is decades old. Feels great! I agree with you that over 9,000 private projects that don't communicate with each other and keep their results secret don't result in progress. You can tell because the definition says that the results are kept secret. The difference between that and what is happening with the forks is that the changes made by the forks (including your own) are available for anyone to read, use, adopt -- or not -- at their own discretion. The important morsel to digest here is that the code is out there for people to evaluate. It's not just a legend. Not just a rumor. You can read it, compile it, run it; then decide what to do with it. Again, I have trouble seeing why this is a problem, or how it makes the situation worse than what we have already lived with since long before the forks came into existence. I hope everyone gets good use out of whatever Plan 9 code they manage to load onto their computers. I enjoy using Plan 9 and I enjoy talking to people who are still working on Plan 9. If you want to keep secrets, keep them. But nothing done by any of the forks is secret. Just take the code and do with it what you will. Why is this controversial? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
[Without picking on or singling out anyone ...] Who would you like to volunteer to do all of this work, that's what it seems like you're trying to do. It is this ongoing level of petty pissiness that has led to the fragmentation of the community. It's also the reason the folks at the Labs quit following the mailing list. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] [GSOC] plan9 which arch code to use?
Why is this controversial? Because you're missing the point, and arguing against a position nobody holds. Absolutely nobody here is suggesting that everyone going off and doing their own thing and keeping the results to themselves is better than everyone going off and doing their own thing and releasing the results. What some folks are suggesting is that some coordination would yield better results; that we can do better than the everyone going off and doing their own thing part of the above scenarios. I believe Erik's point about falling into disrepair is that if everyone is spending time fixing the same issues, each on their own without any coordination, is that the resulting system will increasingly fail to keep up with the evolution of the surrounding world. Even if the code for all the parts I need to drive exist, that's not the same as having a running system. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] [GSOC] plan9 which arch code to use?
On May 7, 2014, at 2:17 PM, Anthony Sorace a...@9srv.net wrote: What some folks are suggesting is that some coordination would yield better results; that we can do better than the everyone going off and doing their own thing part of the above scenarios. I believe Erik's point about falling into disrepair is that if everyone is spending time fixing the same issues, each on their own without any coordination, is that the resulting system will increasingly fail to keep up with the evolution of the surrounding world. Even if the code for all the parts I need to drive exist, that's not the same as having a running system. I do think there is an analogy to be made with the 4.x BSD releases. They were few and far between, but they were also the prescriptive reference points for that UNIX fork. There was a lot of development that branched off from the UCB code base. But much of what was of benefit to all (device drivers, VM enhancements, apps) was folded back into the core. The CSRG encouraged that. And with the CSRG releases as a reference, it wasn't that difficult to share local modifications between sites. But the Labs are not the CSRG. There is no longer a central focus point for the code base. Not in the community sense – the Labs are no longer interested. We are losing the 'reference implementation' from which the branches can be compared. Without an anchor we will drift off in many incompatible directions, to the point where code sharing will become so annoying it just won't happen (in the kernel at least, and in the /dev/* user space as a side effect). --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] [GSOC] plan9 which arch code to use?
Why is this controversial? Because you're missing the point, and arguing against a position nobody holds. The original post (in its way) was asking for advice about an amd64 kernel that is not publicly available. Some people (not knowing the full situation) offered advice about publicly available amd64 kernels and were shot down. Everything else follows from that. I agree, it's a bit muddled at this point, but I've been responding directly to things people have said. The mailing lists for each fork are open to the public. E-mail addresses of principles are all known. The only people who aren't at the party are the ones who haven't bothered to show up. Again, where is the problem? Are we supposed to hire professional coordinators to make the process seem more official? It seems to me the sort-of-articulated complaint is that all of this work is not being conducted under the watchful eye of a centralized authority. Do you mean something like patch(1)? With work being coordinated by staff at Bell Labs? What some folks are suggesting is that some coordination would yield better results; that we can do better than the everyone going off and doing their own thing part of the above scenarios. People working on the forks are in constant contact. How could the situation be improved? My observation was that secret code helps no one. Maybe the code is not really secret, but is instead held up somewhere in the coordination process. For years, and years, and years at a time. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 22:38, s...@9front.org wrote: . Some people (not knowing the full situation) offered advice about publicly available amd64 kernels and were shot down. they weren't shot down, but saying use MY distribution over here, or use MY distribution over here, didn't directly help with the problem of starting from sources (which was actually closer to the original question). normally, it wouldn't really matter, and i'd have kept out of it, but in this case it did. i'm fairly sure nothing warranted the subsequent comments that owe more to dan brown than reality. (come to mention it, i did Dan Brown a favour last year, unwittingly.)
Re: [9fans] [GSOC] plan9 which arch code to use?
Dan Brown low blow
Re: [9fans] [GSOC] plan9 which arch code to use?
(come to mention it, i did Dan Brown a favour last year, unwittingly.) There you go again. More secrets :-)
Re: [9fans] [GSOC] plan9 which arch code to use?
sl said: The original post (in its way) was asking for advice about an amd64 kernel that is not publicly available. No, it wasn't. There was some confusion over the point that Plan 9, unlike some other systems, selects the arch based entirely on the running kernel (no 386 binaries running on amd64 machines). Some people (not knowing the full situation) offered advice about publicly available amd64 kernels and were shot down. Again, that's not what happened. Erik and cinap pointed out one can use 9atom or 9front; Charles gave instructions for building the amd64 userland. He then, later, pointed out that there are things other than just the 64-bit kernels in 9atom and 9front. It's at that point some folks seem to have felt compelled to dredge up the old mess of the original amd64 kernel, which was not what Charles was talking about and was not otherwise at issue here. I'm not sure who in this conversation you think is not knowing the full situation; I'm fairly confident that all the salient points on this topic have been discussed on 9fans ad nauseam. Everything else follows from that. From two faulty premises. Got it. You should re-read the thread. You may think you've been responding to what people are actually saying, but the bunker-mentality defensiveness you repeatedly exhibit has caused you to misinterpret much. As for how the situation could be improved: well, there's lots of potential answers to that question. This has nothing to do with hiring professional project managers or whatever you seem to think is required for actual coordination, but taking some care for your upstream sources is a really effective first step common among open source projects. Try starting there. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] [GSOC] plan9 which arch code to use?
On 7 May 2014 22:38, s...@9front.org wrote: Maybe the code is not really secret, but is instead held up somewhere in the coordination process. For years, and years, and years at a time. It's worth remembering that the only reason there was ANY available code for the amd64, and initial kernel code to boot, was because (1) the amd64 compiler suite, (2) the source for the amd64-specific bits of the library, (3) the modifications to make the whole source compile and run in 64 bits (and not just amd64 but any one), (4) the source for the prototype amd64 kernel, (5) the source for the several versions of the experimental development nix, and a lot more besides was published. in the 6a/6c/6l/libc case, i did the initial initial compiler suite and libraries, and a chunk of the 64-bit clean-up, andthat was indeed available years and years and years ago (about 2005/6, i think). others contributed the other things on the list. i can't help think that availability helped the other projects along a bit.
Re: [9fans] [GSOC] plan9 which arch code to use?
No, it wasn't. There was some confusion over the point that Plan 9, unlike some other systems, selects the arch based entirely on the running kernel (no 386 binaries running on amd64 machines). Do you recall the reason this guy is even trying to install Plan 9? Kernel hacking. Once he builds the amd64 userland, what does he do with it? What would be the next step in making use of that userland? Obviously, not booting a 386 kernel. My comments followed the context of the conversation from its inception and were relevant to the replies therein. The back-and-forth with Erik (and later, you, Charles, etc.) branched out into other territory, but this whole thread is based on a new guy being given weirdly cryptic responses in reply to very basic confusion that is easy to clear up if we just put together words in an obvious manner and speak clearly. If it's silly to suggest one of the forks, then it's equally silly to pretend an amd64 kernel is on the table at all. The chain was this: prospective kernel hacker asks about amd64 - receives accurate answer - someone says no, no - explanation of building amd64 userland (with non-Labs code) - last minute revelation of relevant facts - someone points out that secrets, by definition, are not generally known - someone denies the obvious, casts aspersions on the forks - weird accusations - denials - arguing - complaints - this message When did anyone plan on telling this guy that an amd64 kernel is not even on the table? Remember: The argument against investigating one of the forks was that he should stick close to the Labs distribution, right? When I said that people weren't aware of the full situation, I was referring to the fact that nobody seemed to be aware this guy had made prior arrangements to do work on Charles' non-Labs code. He asked a common question about amd64 (ignoring for a moment the confusion about the difference between VM host and guest CPU as seen by the guest OS) so people gave him relevant answers. Then we stepped on the apparent land mine. Now it's the fault of forks for existing. All because nobody could just say: Hack on the 386 kernel because nothing else is in the official distribution yet. Why is this stuff always so difficult? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
It's worth remembering that the only reason there was ANY available code for the amd64, and initial kernel code to boot, was because Thank you Charles, and everyone else involved. Because of your contributions I'm able to run cinap's pc64 kernel on my x86_64 machines. I'll say this again just because it seems to keep getting missed: That work was only available to us because you made it available. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
Why is this stuff always so difficult? because on the internet nobody does relax.
Re: [9fans] [GSOC] plan9 which arch code to use?
(1) the amd64 compiler suite, (2) the source for the amd64-specific bits of the library, (3) the modifications to make the whole source compile and run in 64 bits (and not just amd64 but any one), (4) the source for the prototype amd64 kernel, (5) the source for the several versions of the experimental development nix, and a lot more besides was published. in the 6a/6c/6l/libc case, i did the initial initial compiler suite and libraries, and a chunk of the 64-bit clean-up, andthat was indeed available years and years and years ago (about 2005/6, i think). others contributed the other things on the list. i can't help think that availability helped the other projects along a bit. yes, and it was very good work. thank you. i'm glad it was baked in so long ago. it's always been a pleasant surprise to find a uintptr in some code that hasn't been touched for years. - erik
Re: [9fans] [GSOC] plan9 which arch code to use?
Quoting Charles Forsyth charles.fors...@gmail.com: they weren't shot down, but saying use MY distribution over here, or use MY distribution over here, haha you said exactly the same thing
Re: [9fans] [GSOC] plan9 which arch code to use?
I have every intention of making my efforts available to everyone, should I have even just a remote chance of success. More importantly, what I'm trying to do is to reduce differences, rather than increase them. Now, I note that by adding the amd64 stuff to an already modified version of the Bell Labs distribution, I'm complicating thing rather than simplify them, but that is the only approach that has caught my attention. And I am listening to the limited discussion on this forum and, no, I am not paying attention to other discussions that may be taking place elsewhere and to which I either have not been invited or from which I have been explicitly been expelled. Now, bear with me for a minute. David has some good stuff lying around that, like much other stuff, needs to be reviewed before it is incorporated with the Bell Labs distribution. Like me, I believe that David's preferrence is to remain with the Bell Labs stuff, whatever his motives. Mine, in passing, are to secure portability for Plan 9 across architectures, idiotic as that may be (I despise the Intel 8088 and all its progeny). Then there is 9atom and 9front that I am aware of, neither of which I am really familiar with, but both of which I respect, greatly, the genesis of. Now, I am human and not a particularly clever specimen of my species, therefore I am picking familiarity over features as my foundations: I know that - bar DNS glitches - the Bell Labs distribution is robust and also the most conservative of the options out there, or maybe just the slowest moving, so it makes a good rock to build a castle on. What's missing in this picture is the tool chest to add walls to this rock, as 9atom (you, Erik, with few assistants) and 9front (cinap and what seems like a superb, youthful team) have already done in their own way. So we have plenty of bricks, some master masons and a community that, at least in small ways, is no doubt willing to contribute. But there is no code review facility (unless you call patch a code review tool - I'm afraid the real thing has spoiled me rotten, despite some shortcomings) and no trusted code review board to push along deserving fixes. Perhaps we can also have a team that takes on ideas that either have no corresponding code or where implementation does not pass review and makes the necessary adjustments, subject to review as well as cooperation from the original submitter(s). I know I can make the time to participate in such an effort, I'm not sure who else might be willing. I also know that there are personality problems as well as ideology problems, but I always believed that these can be overcome in a technological environment where financial incentives are not dominating. Anyway, the elections in South Africa are distracting me, so I'm not going to take this further now, but I'd be delighted to hear from like-thinking developers as well as from those who may want to approach this problem from a very different perspective. ++L ---BeginMessage--- Mostly just a mixture of arrogance and ineptitude that says I want to do this my way? For real, I can't resist a convergence challenge. The image I had in my mind was of an amd64 environment within the Bell Labs release (i386) that would allow me to build either 9atom or 9front releases with minimal adjustments. if everybody does their own thing, perhaps we spend all our collective time doing the same thing, and no progress is made? just an observation. and obviously there are tradeoffs. i'll give you that i love to do things my self. let me know if you see anything in atom that causes issues. certainly a goal is to keep these to a minimum. the atom stuff of course came about for three reasons that were not solved elsewhere at the time: working with certain hardware, 21-bit runes, and production amd64 support. i think all of these are at least to some extent still valid. there are gaps in the distribution's 21-bit rune support, and the hardware support gap may have increased. - erik---End Message---
[9fans] why u.h, why qid?
Hi, I was wondering what was the reasons for the name u.h? Is it because it has lots of uxxx type in it? Also what is the meaning of Qid. What the Q stands for?
