Re: [9fans] VCS on Plan9
Hi 9fans Il 18 Aprile 2024 22:41:50 CEST, Dan Cross ha scritto: > > Git and Jujitsu are, frankly, superior out of curiosity, to your knowedge, did anyone ever tried to port fossil scm to Plan9 or 9front (even through ape)? <https://fossil-scm.org/home/doc/trunk/www/index.wiki> Also (tangential) did anybody tried to port Tiny-CC? Giacomo -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M85b3f817edeaf49c1634b730 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation
Hi hiro. History is full of counter examples that contraddict your thesis. At least since neolithic, human organization has been determinated by technology. The most recent (and most directly related to informatics) were Gutemberg's movable-type printing press, Meucci's telephone, the general purpose CPU and obviously the Internet. But ancient sailing tech, the steam engine, the car, the H bomb, are few among thousands of examples of technological innovation that enabled new (and always more complex) kind of human organizations. Actually one could argue that technology is the most powerful political force in human society. On January 27, 2022 9:02:29 PM UTC, hiro <23h...@gmail.com> wrote: > the majority of "hackers" have already failed to be political, when > they sold their souls to the big corps like google and amazon. You are confusing hackers with engineers. Most hackers ARE politically aware. They pursuit knowledge instead of power, money or prestige, but they are aware of the consequences of their hack. Yet they might align with power anyway. Some are blind enough or careless enough or individualistic enough to only care about their own fun hacks. Take Pike or Thompson: they were pioneers, invented C, Plan9 and all the stuff we love but now they work in Google (afaik). Were they hacker? I can't say if they were or they were just great engineers, but for sure they now align with Google interests and approve its business model based on surveillance capitalism. On the other hand, RMS, Terry A. Davis or Phineas Fisher, Ola Bini are all very politically aware hackers, each in his own way. Sure, since ever, Power system try to get control of hackers. Sometime they manage to jail us. Sometime we escape. [1] Giacomo [1] http://www.tesio.it/2020/09/03/not_all_hackers_are_americans.html -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-M2da0005ff460750189129b1e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation
Hi raingloom, mycroftiv and 9fans, As you might know I'm pretty heretic in Plan 9 (as much that my for is called Jehanne) and I'm also very sympathetic with SJW victims, mostly because SJW basically try to impose worldwide a US-workplace ethos that is compatible with US-styled corporate management. More often than not, they are in good faith. But ultimately they become tools of US colonialism, spreading their cultural hegemony. The trick is basically: convince everybody that they have your problems (eg, systemic racism, lgtqmi+ phobics, gender bias and so on) so that they will accept your corporate-friendly solutions (eg CoCs...) In Europe being inclusive doesn't mean to be hypocrital, and that's why I'd really like to know what "sin" Nemo did to cause all this debate. More often than not, SJW raise their swords after fictional issues that amount to nothing and could be basically settled with a honest conversation between openminded adults. More often than not, what a SJW consider outragous and evil, is said in a completely different cultural context and environment, so much that they simply can't (or don't care to) interpret it as intended and understood in that context. Finally, more often than not, SJW inclusiveness stops before weird people, (like hackers often are) that do NOT belong to the demographic groups that populate US's remorse, like blacks, women and so on. Not to mention that often they are plain blind with the harm their corporations cause worldwide (think of the Facebook's SJW that obtained the removal of RMS from GCC Steering Committee). On January 27, 2022 4:35:16 AM UTC, raingloom wrote: > > Side note: technology is political. Deal with it. Software that helps > no one is of no use and who you choose to help with software and count > as a stakeholder (which includes but is not limited to users) is an > inherently political question. Ignoring that just means that you prefer > the status quo. I totally agree with this. [1] Since neolithic, technology is a prosecution of politics by other means. I agree so much that all my free software projects include a POLITICS.txt that explicitly declares the political goals they have. However, thanks God, not all politics is based on cancel culture, yet. Hackers do not cancel, we create. If you feel the need to cancel Nemo's great influence over Plan 9, I'm not interested. If you want to update his great books, eg to describe 9front, I'd really like to help. But I'd love to work WITH Nemo, not against him. I might disagree with Nemo's view on general politics (I really do not know his takes on anything) but I think I might well work with him on a well defined political goal (say "document 9front internals so that anybody can more easily hack it"). Or maybe he doesn't like 9front and prefer to stick to plan9foundation's code, in which case I would't partecipate because I can't trust several of the founders [2]. Sure, as you say, deciding who your project serves and how is a political choice. But it has nothing to do with who you cancel. Technology is Politics. But Politics, to me, is to build bridges, not walls. Cancelling Nemo is not a political achievement. Building on the great work he donated to this community, is. My 2 cents. Giacomo [1] http://www.tesio.it/2019/06/03/what-is-informatics.html [2] http://www.tesio.it/2018/02/14/what-i-wish-i-knew-before-contributing-to-open-source.html -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-Mfc760e8816936706c934d544 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] p9f licensing question (u9fs)
Thanks David, On Sun, 11 Apr 2021 20:55:33 +0200 David du Colombier wrote: > > browsing the 9p.io's sources of plan9 I have noticed that u9fs have > > a specific LICENSE file that is not MIT, while the page header says > > "Distributed under the MIT License". > > > > What's the actual license under which u9fs is distributed by the > > Plan 9 Foundation? > > I suppose you are referring to this: > > https://9p.io/sources/plan9/sys/src/cmd/unix/u9fs/LICENSE Yes I am. Sorry, I should have liked the page. > This is an old license that was used by Lucent to share software > such as AWK, sam, u9fs, etc. as part of the Netlib collection. > > This license was quite permissive and similar to the MIT license. It looks so, but the wording is wierd (to my untrained eye): ``` Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, ... ``` the fact is that "without fee" comes before "is hereby granted", not after, so that it looks as a condition to the distribution grant. Indeed the canonical MIT license does not mention fees and the "free of charges" is clearly referred to the permission: https://opensource.org/licenses/MIT > You can ignore this file and consider u9fs is distributed under MIT. Thanks! But I think that to avoid future issues, the Plan 9 Foundation should either remove the file or complement it with an explicit statement about the new MIT licensing. Giacomo -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7af5000e9aa9f587-Mf9e3729b6ba12e43297e212b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] p9f licensing question (u9fs)
Hello 9fans, browsing the 9p.io's sources of plan9 I have noticed that u9fs have a specific LICENSE file that is not MIT, while the page header says "Distributed under the MIT License". What's the actual license under which u9fs is distributed by the Plan 9 Foundation? Giacomo -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7af5000e9aa9f587-Meb06d9ef91c0fe95cd859e9f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Git/fs: Possibly Usable
On April 3, 2019 4:02:49 PM UTC, o...@eigenstate.org wrote: >Don't particularly care. At some point I'd like to commit it to 9front, >but I can relicense it then. > >Do you have a preference? Probably MIT or a BSD. But I can also live with any copyleft of your choice. Giacomo
Re: [9fans] Git/fs: Possibly Usable
protocols: git:// and git+ssh://. If someone >implements others, I'll gladly accept patches. > >TODOs: > git/mkpatch:Generate a 'git am' compatible patch. > git/apply: Apply a diff. > git/diff: Wrapper wrapper around git/walk that > diffs the changed files. > git/merge: Yup, what it says on the label. Should > also be a script around git/fs. > git/log:Need to figure out how to make it filter > by files. > /n/git/HEAD:add /n/git/head subtree which points > to the current commit. > >...And a whole bunch more. Impressive! I didn't imagine one could implement git in so few lines of C! Thanks for challenging my assumptions! I'd like to port it to Jehanne but I cannot find a license in the repository, so in theory it's "all rights reserved" under most jurisdictions. What's your take on this? Did you intend to put it under public domain instead? Maybe MIT? Or LPL? Giacomo
Re: [9fans] Plan 9 64-bit?
Not sure if anybody cares, but Jehanne's kernel derives from a version of Charles https://bitbucket.org/forsyth/plan9-9k cherry picked from 2015. Giacomo
Re: [9fans] A heartfelt thanks... :-)
Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener ha scritto: > Please forgive my laziness in not reading the code, but how do you actually > implement sleep? Does the process read a file guaranteed to block forever, > or what? No problem. Actually sleep is very short: https://github.com/JehanneOS/jehanne/blob/master/sys/src/lib/c/9sys/sleep.c#L23 The blocking system call used in sleep is rendezvous that, in Jehanne, can never occur at tag ((void*)~0). Giacomo
Re: [9fans] A heartfelt thanks... :-)
Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin ha scritto: > I'm interested in reading about your awake system call and the changes > you've made to rendezvous and the variuos locks in libc. Hi Anthony, sorry for the 2 years delay, but I've finally wrote about awake. http://jehanne.io/2018/11/15/simplicity-awakes.html Feel free to ask any question! Giacomo
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Il giorno dom 14 ott 2018 alle ore 19:39 Ole-Hjalmar Kristensen ha scritto: > > OK, that makes sense. So it would not stop a client from for example first > read an index block in a B-tree, wait for the result, and then issue read > operations for all the data blocks in parallel. If the client is the kernel that's true. If the client is directly speaking 9P that's true again. But if the client is a userspace program using pread/pwrite that wouldn't work unless it fork a new process per each read as the syscalls blocks. Which is what fcp does, actually: https://github.com/brho/plan9/blob/master/sys/src/cmd/fcp.c Giacomo
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Il giorno mar 9 ott 2018 alle ore 05:33 Lucio De Re ha scritto: > > On 10/9/18, Bakul Shah wrote: > > > > One thing I have mused about is recasting plan9 as a > > microkernel and pushing out a lot of its kernel code into user > > mode code. It is already half way there -- it is basically a > > mux for 9p calls, low level device drivers, > > > There are religious reasons not to go there Indeed, as an heretic, one of the first things I did with Jehanne was to move the console filesystem out of kernel. Then I moved several syscalls into userspace. Or turned them to files or to operation on existing files. More syscall/kernel services will move to user space as I'll have time to hack it again. You know... heretics ruin everything! I'm not going to turn Jehanne to a microkernel, but I'm looking for the simplest possible set of kernel abstractions that can support a distributed operating system able to replace the mainstream Web+OS mess. You know... heretics are crazy, too! Giacomo
Re: [9fans] 9n
2018-05-02 19:24 GMT+02:00 Fran. J Ballesteros <n...@lsub.org>: > I just learned to love absolute paths. > Actually they kind of emerge from my design by themselves. > IIRC, there was no deadlock caused that you should be aware of. > I'ts been a long time and quite a few protocols since then, I can look for > the source; there must be also some docs in the web. > Well, actually I'm pretty curious about the implementation. I'd like to see how you did isolated the changes, since to me they seem rather huge (but my protocol diverge more from 9P2000 than 9P2000.ix). Also, I welcome any suggestion for further documents to read about the topic. > Also, I'm more in favor of prefix mount tables, that they are very > different from what 9 does and they would lead to a very different system. > Can you elaborate? What differences this approach would produce? I can foresee some (eg bind semantics) but maybe I'm missing some of them. > Good luck and have fun. > Thanks! :-) Giacomo > > > On 2 May 2018, at 19:14, Giacomo Tesio <giac...@tesio.it> wrote: > > > > 2013-06-17 21:06 GMT+02:00 Nemo <nemo.m...@gmail.com>: > > You should ask if anyone else did that before doing it, instead of saying > > they are un-spined life forms. > > > > Here I am, finally! :-) > > > > I'm designing yet another file protocol for my toy/research os (whose > kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a > look at your prior art. > > > > Some of my design decisions lead to a management of mount tables that is > pretty similar to what you describe in your paper about the integration of > 9P2000.ix. > > > > Given you already walked this path, I'd like to know what you have > learnt and if you faced issues I should be aware. > > For example, the slight difference in bind semantics seems to reduce the > risk of accidental loops in the namespace, but I would expect it would > break related userspace assumptions. > > Also, resolving the dot of each process in the Pgrp each time a mount is > done, seems pretty complex and prone to deadlocks. > > > > > > Don't you have a tricorder? > > > > No... but usually I can get away with my sonic screwdriver... :-) > > > > > > Giacomo > > > >
Re: [9fans] 9n
2013-06-17 21:06 GMT+02:00 Nemo <nemo.m...@gmail.com>: > You should ask if anyone else did that before doing it, instead of saying > they are un-spined life forms. > Here I am, finally! :-) I'm designing yet another file protocol for my toy/research os (whose kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a look at your prior art. Some of my design decisions lead to a management of mount tables that is pretty similar to what you describe in your paper about the integration of 9P2000.ix. Given you already walked this path, I'd like to know what you have learnt and if you faced issues I should be aware. For example, the slight difference in bind semantics seems to reduce the risk of accidental loops in the namespace, but I would expect it would break related userspace assumptions. Also, resolving the dot of each process in the Pgrp each time a mount is done, seems pretty complex and prone to deadlocks. > Don't you have a tricorder? > No... but usually I can get away with my sonic screwdriver... :-) Giacomo
Re: [9fans] There is no fork
2018-02-12 17:13 GMT+01:00 <tlaro...@polynum.com>: > 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>: >> That's the marketing blurb, I've heard it a thousand times before. [...] >> So, for the last 10-12 years, maybe more, mountains of software have been >> produced on the assumption that it will be easy to find and install all >> their dependencies. That's only true for users of big 'distributions' which >> have lots of people, a large professional team or many contributors, to >> create and maintain the package tree. > > From a different point of view, the problem is also that the developers, > using some developing tools (for example the GNU automake and autoconf), > don't really know what they are using, or, since "GNU is not Unix", > don't verify that their code is POSIX compliant (and to what level etc.; > when I began using Unix by discovering Linux, I remember reading a book > explaining that for C programming, when linking, you will add always > the Glib library because "there are probably things you will need in > it!"...). I might be proven wrong, but I doubt that developers not understanding their tools can build useful software. Or, if the software they build is useful, it may get enough traction to be rewritten after learning from mistakes. I cannot fix people linking glib just because it exists. Just like I cannot fix people writing a new JS framework/library/wtf. In general I cannot fix people. But, whenever I have to hack on something that depends on cmake, instead of autotools, I know it will take twice as much to get the task done. > > The amount of dependencies of some packages is simply appaling. (One > example is TeXlive, because using some macros involve using an amount > not necessarily kwown of "other" macros, for a lot of people it is > simpler to "take it all" just in order not to "fail"; and this is > when you need only a part of it that you discover that this "all" > depends on things that you do not have on your system---a C++ > compiler and so on). My bet is that, when Jehanne will be the one true OS everybody will hate, people will not install macro packages, but mount a remote file server through a caching file server, including the C++ compiler. Now before going crazy about security, consider that the shell running TeXlive will only see a limited namespace, containing only the file it has to work with and nothing else. But this is not going to happen soon... People do not hate Javascript enough, yet... :-D Giacomo
Re: [9fans] There is no fork
2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>: > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote: >> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>: >>> linux-style package managers and bsd-style port trees facilitate and enable >>> coupling. >> >> What a package manager really facilitate is version management. >> That is when you want to use/update a software at version X that depends on >> libraries at version Y and Z. > > That's the marketing blurb, I've heard it a thousand times before. [...] > So, for the last 10-12 years, maybe more, mountains of software have been > produced on the assumption that it will be easy to find and install all their > dependencies. That's only true for users of big 'distributions' which have > lots of people, a large professional team or many contributors, to create and > maintain the package tree. True, but part of cost here is the complexity of the package manager. > >> The use of dynamic linking make this complex and cumbersome. Also a single >> filesystem hierarchy does not help > > Dynamic linking is probably the largest, most visible part of the problem, > but your saying this makes me think you haven't tried to compile very much > software -- certainly not on anything other than Debian or a similarly large > distro where, these days, you can get all the dependencies by pasting a line > the package author provided. Well, I use Debian from Potato, but I've got my headaches with pinning, backports, conflicts and broken upgrades. Also, I think I've compiled my amount of software. As a rather recent example, automating the compilation of the gcc cross-compiler for Jehanne took its time since I had to compile and install locally specific versions of autotools and binutils, without forcing users to install texinfo. I think I have an idea of what I'm doing, but I'm pretty open to suggestions and criticisms: the best time for them is now, since I did no real work on the matter. > The painful ones particularly included dependencies for otherwise nice > programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos! > [...] > Thinking about this stuff makes me bitter, so I ought to stop now. It's > possible the things you want won't intersect with the things which caused me > trouble, but I think I have considerable reason for pessimism. Well, obviously I'm naive enough to try to do something better! :-D I think the problem is really tied to the nature of software development... just because bugs are. To my money you have an alternative: - to be mostly self contained (as Plan 9/9front does), which is the optimal solution to the problem - to leverage outside softwares which evolve outside your control Both solution have to cope with bugs: - in Plan 9/9front you fix them - in other systems you can still fix them but if you contribute back the fix things turn "complex"... Versioning, dependency trees (or sometime even graphs) and all these monsters comes from this problem. The self-contained approach is way more efficient... and simpler. Thus it's very attractive to me. But, my insight is that these monsters need to be faced, and defeated. :-) Since you can't stop (or control) the evolution of software you do not code yourself, there's no way to avoid versioning and using that software. But again my insight is that using static linking and namespaces, packages can be way easier to maintain. Still, I'd really like to know details about your concerns and your painful experiences, since they could put me on the right track. > I'd like to think there are enough people who don't want to be tied up in all > this pain to create some semblance of a software ecosystem outside it, but > when you consider that few people want to start from the ground up, and how > poettering and fd.o have their tentacles in crucial parts of the > posix-related ecosystem, it looks impossible. Well, actually there are several hobby OSes that do not support posix and package management. (and some have interesting ideas too...) But the problem with your approach is not just posix compliance. For example, in Jehanne most tools you are used in Plan 9 are not part of the core system. For example, porting Plan 9/9front games to Jehanne is trivial (could even be automated), but their changes should not cause the core system to "evolve". So the solution, again, is installing them as packages, with their own versions. And this is the reason why there are no games in Jehanne: they are waiting for a package manager. The problem, as always, is to get the axes right. An OS core system should evolve as a whole. But since its usefulness depend on the amount of things people can do with it, it should also be able to run exogenous software.
Re: [9fans] There is no fork
2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>: > linux-style package managers and bsd-style port trees facilitate and > enable coupling. > > What a package manager really facilitate is version management. That is when you want to use/update a software at version X that depends on libraries at version Y and Z. The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help Plan 9 does not suffer of this problems because of several reasons: - it does not support dynamic linking - it is developed as a whole "batteries included" - few external packages have being ported to it, and people who use them know their stuff very well Plan 9 (and 9atom/9front) is developed and distributed as "a whole system": there is conceptually only one version for all the software and libraries included. Technically it's the simplest and optimal solution to the versioning problem. Indeed 9front uses a single mercurial repository (which is a versioning system) to manage both development and system updates. I carefully considered this approach for Jehanne too, but decided to try an alternative design. Obviously no dynamic linking will ever land in Jehanne, but I want to enable more external softwares to run on it. This way I reduce the responsibilities of the project and size it to the stable workforce (that is: I, me and myself). It might seem counter intuitive to say that using gcc instead of ken-c simplify the system. It's true that it increase the complexity of the system during compilation, but it reduce the scope of Jehanne itself. So Jehanne's core system can follow the whole system development approach of Plan 9, but it's a minimal system and an included package manager will allow the installation of other useful software. The problem is that the perfect package manager does not yet exists for the Jehanne design. Probably the nearest thing is BSD's pkgsrc, but it doesn't get advantage of namespaces. And which language should I use to code an alternative? Probably C. But I wonder if a more high level language could make the job easier without increasing too much the project scope. So far candidates alternatives (that I still need time to evaluate deeply) are Wirth's Oberon-07 and Obi's Myrddin. Giacomo
Re: [9fans] There is no fork
2018-02-12 0:48 GMT+01:00 Benjamin Huntsman <bhunts...@mail2.cu-portland.edu>: > Or, if one wants NIX but to stay a little closer to the original > distribution, are there options, or is Harvey the only way? Out of curiosity, what's your use case for the NIX kernel? @Lyndon: https://bitbucket.org/forsyth/plan9-9k @Rui: Jehanne diverged a lot from Plan 9, in a pursuit for my vision of simplicity. While it's in no way a Unix, many won't even consider it a Plan 9 system. Still for anyone interested: http://jehanne.io Giacomo
Re: [9fans] There is no fork
To my knowledge this is the set of active projects based on Plan 9: 9atom and 9front are both actively maintained. Both stick strongly to the original Plan 9 from Bell Labs design. AFAIK, 9front introduce more innovations, both in kernel and in user space, but what make it unique is the #cat-v community. 9legacy is not a really fork, but an organized collection of patches, and is still actively maintained. Another non-fork active project is Plan 9-ANTS (http://www.9gridchan.org/ ) which also provides a 9front-based amd64 iso and a free 9P grid online. Harvey's kernel is based on NIX, and AFAIK, it's the only project where NIX development is active. Forsyth's Plan-9k had some development in mid 2017. It's 2015 version was the starting point of Jehanne's kernel, which is my own research operating system (that also includes several of 9front's improvements). Jehanne is the project that diverged most from the original Plan9 design, with its own set of crazy decisions, but currently it's an unstable toy. Giacomo 2018-02-10 3:48 GMT+01:00 Benjamin Huntsman <bhunts...@mail2.cu-portland.edu>: > Just curious as to the state of the union. Is 9front pretty much the de > facto "official" Plan 9 these days, or does anyone still use or maintain any > of the following: > > > 9atom > > NIX > > 9legacy > > The original Bell Labs distribution > > > Thanks for your input! > > > -Ben > >
Re: [9fans] Talk by Charles Forsyth on Feb 1st at Imperial College London, 13:00 -14:00
Please share a link here, when ready! Giacomo 2018-01-29 11:36 GMT+01:00 Hugues Evrard <h.evr...@imperial.ac.uk>: > Yes it should be recorded, and made available online later on (I needed > confirmation before answering here). > Thanks, > Hugues > > > On 24/01/18 09:32, Fran. J Ballesteros wrote: > > will it be avail online, somehow? > thanks. > > El 24 ene 2018, a las 10:16, Hugues Evrard <h.evr...@imperial.ac.uk> > escribió: > > Hi all, > > On Thursday Feb. 1st (next week), Charles Forsyth will kindly give an > introduction talk to plan9 and inferno at Imperial College in London. If > you are in the London area, don't hesitate to join and to relay this > announce! > > Here is the abstract: > Plan 9 and Inferno are two operating systems (originally developed by the > Bell Labs centre that produced Unix decades earlier). Both were designed > to allow systems to be composed from smaller cooperating systems performing > specific tasks. They provide structural support for distribution, at the > operating system level. Their defining novelty is the representation of > all distributable resources as hierarchical name spaces. There are > conventional names for certain resources, but no global name space. > Instead, the kernel provides operations that compose name spaces of local > and remote resources, at per-process granularity, to build a unique space > to suit a given application. That can aid design, development, testing > and integration. I'll give brief summaries of the two operating systems, > and present examples of their use, with an emphasis on naming. > > The talk is at 13:00-14:00 in amphitheatre 311 of the Huxley building, > whose entrance is at 180 Queen’s Gate, London SW7 2AZ. It is part of the > iPr0gram talk series ( https://www.doc.ic.ac.uk/~rbc/iPr0gram/ ), where > people external to Imperial College are warmly welcome, please just get in > touch with Robert ( https://www.doc.ic.ac.uk/~rbc/ ) beforehand if you > plan to join. > > As most of you already know, Charles has made numerous contributions to > plan9 and inferno, and was instrumental in open-sourcing inferno. For more > info, check out his homepage: http://www.terzarima.net/ > Please get in touch with me if you would like to have a chat with Charles > in the afternoon, I can arrange a meeting room. > Thanks, > Hugues > > >
Re: [9fans] Spectre and Meltdown
2018-01-10 17:59 GMT+01:00 <cinap_len...@felloff.net>: > wait and see if all these scrambled together mitigations actually work. Sorry if this is a dumb question, but the descriptions I read of the mitigations taken in Linux for Meltdown (in particular kernel page-table isolation) sound really familiar to my poor understanding of how plan 9 and 9front already manage user memory. As far as I can remember plan9 flush tables very often and clearly separate kernel memory pages and user space memory. So my dumb question is: are plan9/9front and friends actually vulnerable to Meltdown? Giacomo
[9fans] truly hidden files!
Hi, while debugging a 9P2000 file server I realized that it's very easy to hide file or folders in Plan 9: just don't include them in the Rreads of the parent directory. Given the protocol, I know I'm stating the obvious, but the effect still surprises me. Such files/folder would be accessible to programs knowing their exact names but not visible to the poor user who ignore them. I wonder if this can be turned to a security issue. Eg an invisible pipe named "null" and bound before to /dev could receive top secret data you wanted to destroy. Giacomo PS: knowing a program that use these hidden files, /proc/n/fd would still reveal their path, but the path could still appear legitimate like the case of /dev/null.
Re: [9fans] Backgrounding a task
Here it is: https://github.com/JehanneOS/jehanne/commit/320e6e6f35bfbc2e37dbd079c8d6a9124bd9ac6c The simple test attached confirms that it works as expected: https://github.com/JehanneOS/jehanne/blob/master/qa/kern/nsclone.c Now it's just matter of modifying the plumber to use this facility and add a ns/clone command that take a pid and a command to run so that ns/clone 256 rc would start a new rc in a copy of the name space of the process with pid 256. Giacomo 2017-10-24 21:18 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > 2017-10-24 16:21 GMT+02:00 Alex Musolino <a...@musolino.id.au>: >> Creating a child process is something that a process explicitly >> controls and the RFNOTEG flag of rfork(2) allows a process to control >> whether or not it shares its namespace with its children. Allowing >> other, unrelated processes to fiddle with your namespace is quite >> different. >> >> Think about multiple processes owned by multiple users running on a >> cpu server. Which processes should be allowed to join which >> namespaces? >> >> Perhaps allowing only the hostowner to join namespaces for debugging >> and administration purposes would be acceptable. > > I like this idea a lot. I will give it a try in Jehanne. > > However I'm going to use a slightly different design: writing "clone" > to /proc/$pid/ns will cause the current process to replace its own > name space with a *copy* of that of $pid. > If the owner of $pid is different from that of the current process or > if $pid is not running on the same machine as the current process, the > write will fail with an error. > > However any change to the name space after the clone does not impact > the original process. > > As for the plumber, I will add a message that make the plumber clone > the name space of a target process. > > This should address both use-cases without issues for the processes > running in the original name space. > > > Giacomo
Re: [9fans] Backgrounding a task
2017-10-24 16:21 GMT+02:00 Alex Musolino <a...@musolino.id.au>: > Creating a child process is something that a process explicitly > controls and the RFNOTEG flag of rfork(2) allows a process to control > whether or not it shares its namespace with its children. Allowing > other, unrelated processes to fiddle with your namespace is quite > different. > > Think about multiple processes owned by multiple users running on a > cpu server. Which processes should be allowed to join which > namespaces? > > Perhaps allowing only the hostowner to join namespaces for debugging > and administration purposes would be acceptable. I like this idea a lot. I will give it a try in Jehanne. However I'm going to use a slightly different design: writing "clone" to /proc/$pid/ns will cause the current process to replace its own name space with a *copy* of that of $pid. If the owner of $pid is different from that of the current process or if $pid is not running on the same machine as the current process, the write will fail with an error. However any change to the name space after the clone does not impact the original process. As for the plumber, I will add a message that make the plumber clone the name space of a target process. This should address both use-cases without issues for the processes running in the original name space. Giacomo
Re: [9fans] rc: $* != '/env/*'
2017-10-19 6:48 GMT+02:00 Skip Tavakkolian <skip.tavakkol...@gmail.com>: > i think 'rfork e' in lc will fix this; i'm not sure if it breaks anything > else. Actually 'rfork e' in lc fixes this. I did not even tried because I assumed that /env/* was written at rc startup, before reading the input script. I was wrong, actually, but now I wonder when it's written... probably just before the first exec. > i can't tell if this was an oversight or done on purpose. lc itself doesn't > seem all that useful or necessary. As for lc, I use it pretty often :-) But actually I asked about the "dirty" /env/* because I thought it could have had a purpose I was missing. Giacomo
Re: [9fans] rc: $* != '/env/*'
Pretty clear, thanks! :-) So, to "fix" this rc would need an option to know to rfork(RFENVG) before doing anything else. Something like: -f [nNeEsfFm] Start as a new process group using rfork(flags) This way lc would produce not surprises by simply adding "-f e" to the first line. It shouldn't be an hard fix, but I wonder if it's actually worth the effort. Also, probably -f is not the best flag here as it usually mean "file"... -r would be a better choice, but it's taken for debugging output. I might use -d for debugging output since -d is a no-op (why?) and -r for this early rfork, but I have no idea of what it would broke. Giacomo 2017-10-18 19:25 GMT+02:00 Skip Tavakkolian <skip.tavakkol...@gmail.com>: > yes. lc -- an rc script -- shares the environment with the rc that starts > it; so env is updated with arglist of lc. $* is the arglist that parent > (interactive) rc was started with. rc(1) says: > > $* Set to rc's argument list during initialization. >Whenever a . command or a function is executed, the >current value is saved and $* receives the new >argument list. The saved value is restored on com- >pletion of the . or function. > > if lc was a function, there would be no surprises: > > % cat /bin/lc > #!/bin/rc > ls -p $* | mc > % fn LC { ls -p $* | mc } > % echo $* > > % cat '/env/*' > % LC >/dev/null > % echo $* > > % cat '/env/*' > % > > On Wed, Oct 18, 2017 at 9:02 AM Antons Suspans <an...@ml.lv> wrote: >> >> On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote: >> > I have been a bit surprised to see that $* does not always contains >> > the same as '/env/*': >> > >> > % echo $* >> > >> > % cat '/env/*' >> > % lc >> > bin/ lib/ tmp/ >> > % echo $* >> > >> > % cat '/env/*' >> > /bin/lc% >> > >> > Not really an issue, but why this happens? >> >> I guess... >> >> When starting a command from rc, execforkexec() does fork(), which >> is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply RFENVG. >> >> As lc(1) is a shell script, its shell instance sets /env/'*'. >> >> Hope this helps. >> >> -- >> Antons >> >
[9fans] rc: $* != '/env/*'
I have been a bit surprised to see that $* does not always contains the same as '/env/*': % echo $* % cat '/env/*' % lc bin/ lib/ tmp/ % echo $* % cat '/env/*' /bin/lc% Not really an issue, but why this happens? Giacomo
Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?
2017-10-17 18:00 GMT+02:00 Skip Tavakkolian <skip.tavakkol...@gmail.com>: > On Tue, Oct 17, 2017, 8:05 AM Giacomo Tesio <giac...@tesio.it> wrote: > >> Really? Just aesthetics? :-o >> > > >> This would flips the question a bit: I wonder why the same designers >> chose uppercase variable names while designing Unix... :-) >> > > Programs can evolve, why not names? There was no expectation that sh > scripts would work in rc. > They can! For sure! But usually they evolve towards a goal... and I'm a curious person.. :-) Also this is not about sh scripts run by rc, but sh script run by an sh shell started by rc. Or, rc scripts run by an rc shell invoked by an sh. Just to explain, for example, you could have an sh script that changes $USER and then invoke psu that would keep using the previous $user. Giacomo
Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?
Also, why NPROC has been left uppercase? :-) Giacomo 2017-10-17 17:45 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > In *rc* you use quotation marks when you want a syntax character to >> appear in an argument, or an argument that is the empty string, and at no >> other time. IFS is no longer used, *except in the one case where it was >> indispensable*: converting command output into argument lists during >> command substitution. > > > So, I undestood: it used to use IFS in that one case. > > I got it now: the fact that IFS was named ifs was not a relevant for the > discourse, and thus omitted. > > Still I'm a bit surprised that such change in the conventions provides no > practical advantage: the taste changes with age, but costs accumulate... :-) > > > BTW, thanks for your answers! > > > Giacomo > > > 2017-10-17 17:18 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: > >> since for example the original Rc paper still referred to $IFS. >> >> >> really? the only references to IFS I can find are in comparisons of $ifs >> to the Bourne shell's $IFS >> >> On 17 October 2017 at 16:05, Giacomo Tesio <giac...@tesio.it> wrote: >> >>> Really? Just aesthetics? :-o >>> I supposed it had some practical goal I was missing, since for example >>> the original Rc paper still referred to $IFS. >>> >>> This would flips the question a bit: I wonder why the same designers >>> chose uppercase variable names while designing Unix... :-) >>> >>> >>> Giacomo >>> >>> 2017-10-17 16:39 GMT+02:00 Dan Cross <cro...@gmail.com>: >>> >>>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it> >>>> wrote: >>>> > Out of curiosity, do anybody know why Plan9 designers chose lowercase >>>> > variables over uppercase ones? >>>> > >>>> > At first, given the different conventions between rc and sh (eg $path >>>> is an >>>> > array, while $PATH is a string), I supposed Plan 9 designers wanted to >>>> > prevent conflict with unix tools relying to the older conventions. >>>> > >>>> > However, I'm not sure this was the main reason, as this also open to >>>> subtle >>>> > issues: if a unix shell modifies $IFS and then invoke an rc script, >>>> such >>>> > script will ignore the change and keep using the previous $ifs. >>>> > >>>> > >>>> > As far as I can see, APE does not attempt any translation between the >>>> two >>>> > conventions, so maybe I'm just missing something obvious... >>>> > >>>> > >>>> > Do anyone know what considerations led to such design decision? >>>> >>>> Aesthetics. >>>> >>>> >>> >> >
Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?
> > In *rc* you use quotation marks when you want a syntax character to > appear in an argument, or an argument that is the empty string, and at no > other time. IFS is no longer used, *except in the one case where it was > indispensable*: converting command output into argument lists during > command substitution. So, I undestood: it used to use IFS in that one case. I got it now: the fact that IFS was named ifs was not a relevant for the discourse, and thus omitted. Still I'm a bit surprised that such change in the conventions provides no practical advantage: the taste changes with age, but costs accumulate... :-) BTW, thanks for your answers! Giacomo 2017-10-17 17:18 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: > since for example the original Rc paper still referred to $IFS. > > > really? the only references to IFS I can find are in comparisons of $ifs > to the Bourne shell's $IFS > > On 17 October 2017 at 16:05, Giacomo Tesio <giac...@tesio.it> wrote: > >> Really? Just aesthetics? :-o >> I supposed it had some practical goal I was missing, since for example >> the original Rc paper still referred to $IFS. >> >> This would flips the question a bit: I wonder why the same designers >> chose uppercase variable names while designing Unix... :-) >> >> >> Giacomo >> >> 2017-10-17 16:39 GMT+02:00 Dan Cross <cro...@gmail.com>: >> >>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it> >>> wrote: >>> > Out of curiosity, do anybody know why Plan9 designers chose lowercase >>> > variables over uppercase ones? >>> > >>> > At first, given the different conventions between rc and sh (eg $path >>> is an >>> > array, while $PATH is a string), I supposed Plan 9 designers wanted to >>> > prevent conflict with unix tools relying to the older conventions. >>> > >>> > However, I'm not sure this was the main reason, as this also open to >>> subtle >>> > issues: if a unix shell modifies $IFS and then invoke an rc script, >>> such >>> > script will ignore the change and keep using the previous $ifs. >>> > >>> > >>> > As far as I can see, APE does not attempt any translation between the >>> two >>> > conventions, so maybe I'm just missing something obvious... >>> > >>> > >>> > Do anyone know what considerations led to such design decision? >>> >>> Aesthetics. >>> >>> >> >
Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?
Really? Just aesthetics? :-o I supposed it had some practical goal I was missing, since for example the original Rc paper still referred to $IFS. This would flips the question a bit: I wonder why the same designers chose uppercase variable names while designing Unix... :-) Giacomo 2017-10-17 16:39 GMT+02:00 Dan Cross <cro...@gmail.com>: > On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it> wrote: > > Out of curiosity, do anybody know why Plan9 designers chose lowercase > > variables over uppercase ones? > > > > At first, given the different conventions between rc and sh (eg $path is > an > > array, while $PATH is a string), I supposed Plan 9 designers wanted to > > prevent conflict with unix tools relying to the older conventions. > > > > However, I'm not sure this was the main reason, as this also open to > subtle > > issues: if a unix shell modifies $IFS and then invoke an rc script, such > > script will ignore the change and keep using the previous $ifs. > > > > > > As far as I can see, APE does not attempt any translation between the two > > conventions, so maybe I'm just missing something obvious... > > > > > > Do anyone know what considerations led to such design decision? > > Aesthetics. > >
[9fans] Why Plan 9 uses $ifs instead of $IFS?
Out of curiosity, do anybody know why Plan9 designers chose lowercase variables over uppercase ones? At first, given the different conventions between rc and sh (eg $path is an array, while $PATH is a string), I supposed Plan 9 designers wanted to prevent conflict with unix tools relying to the older conventions. However, I'm not sure this was the main reason, as this also open to subtle issues: if a unix shell modifies $IFS and then invoke an rc script, such script will ignore the change and keep using the previous $ifs. As far as I can see, APE does not attempt any translation between the two conventions, so maybe I'm just missing something obvious... Do anyone know what considerations led to such design decision? Giacomo
Re: [9fans] The Case for Bind
2017-09-14 16:58 GMT+02:00 Marshall Conover <marzhal...@gmail.com>: > ...but enthusiasm for the concept seems lukewarm, and I'm coming to the > point where I feel I'm going to need to make a strong argument for... > 2017-09-15 2:53 GMT+02:00 Marshall Conover <marzhal...@gmail.com>: > It is detrimental to not have this feature, and not having it, in sum, > will waste millions of man-hours for the people who use this operating > system, the same way it's wasted lifetimes not being in Mac or Windows. > IMHO, there is a wise suggestion hidden in khm jokes. It's pretty naive to think that contributing to open source projects leaded by a large company (even just informally, by its employees) you can pursue these kind of values. Your contributions might be welcomed for a while, if they align with their current objectives. But you are not your contributions, and since you freely agreed to donate your time for free, they don't owe you anything. As long as they lead the project, the choice of open source license is just marketing: there's neither openness nor freedom there. Think about this for a while: if Google (or Microsoft, or...) would care about wasted man-hours (or wasted gigawatts) do you think they would have turned HTML browsers to what they are now? If you want to contribute to Fuchsia (or any similarly leaded project), start by writing tests, reviewing code, fixing small bugs, implementing the interfaces they designed and so on... they will thanks you a lot for your free and (really) useful work. And as long as you align with their purposes they will threat you as a peer. It's not that those developers are evil but there's a large amount of politics inside these companies they have to cope with. And ultimately, the companies that pay them are not pursuing values, just long term profits. Giacomo
[9fans] double lock in proc.c
In /sys/src/9/port/proc.c a comment state: /* * Expects that only one process can call wakeup for any given Rendez. * We hold both locks to ensure that r->p and p->r remain consistent. * Richard Miller has a better solution that doesn't require both to * be held simultaneously, but I'm a paranoid - presotto. */ (see https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887) I'd like to know a bit more about Miller's solution as I'd like to simplify postnote. Any hint or source code? Giacomo
Re: [9fans] Blocking on write
In Jehanne, I decided to test both: if the queue is not closed there's no need to check up->errstr. Thanks for your help! Giacomo 2017-05-15 18:12 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 15 May 2017 at 16:46, Giacomo Tesio <giac...@tesio.it> wrote: > >> Shouldn't the waserror code check that the queue has been actually closed? > > > Either that or check errstr against Ehungup, since that's the exact error > it incurred. > The latter has the advantage of not obscuring a different error if the > pipe is closed > between the write and waserror, but with pipes there's not much except > interrupt, I suppose, > so it seems a minor race and perhaps the qclosed check is adequate. >
Re: [9fans] equality sign in Rc
Il 16 Maggio 2017 19:11:33 CEST, Kurt H Maier <k...@sciops.net> ha scritto: >On Mon, May 15, 2017 at 03:32:09PM -0400, s...@9front.org wrote: >> Honestly, the equality sign is never a problem for me. >> What is the purpose again of making this change? >> >> sl > >Why won't anyone answer this question? Rc run commands ;-) Giacomo
Re: [9fans] equality sign in Rc
Tonight I've tried this little hack, but I do not have a comprehensive test suite (does any exists?) https://github.com/JehanneOS/jehanne/commit/003141901af25f0bb3556be40b7ff963f57ced32 I thought that there's no reason to mimic sh for this since if you need sh to run a script rc won't work anyway. So this is just a little syntactic sugar, that for the joy of sl is not compatible with sh, but imho it can also increases the readability of scripts. Indeed I agree with sl that expliitness is an advantage of the current quotation rules. The idea is to use a single $ to mark the end of variable declarations, so that what's left can't do assignments, and equality is always quoted. Here some examples: % a=1 echo b=$a rc: #d/0: token '=': syntax error % a=1 $ echo b=$a b=1 % $ eval prefix=$home/foo && echo $prefix /usr/glenda/foo % $ eval prefix=$home/foo; echo ./configure --prefix=$prefix rc: #d/0: token '=': syntax error % $ eval prefix=$home/foo; $ echo ./configure --prefix=$prefix ./configure --prefix=/usr/glenda/foo % inf=/dev/random out=/dev/null $ echo dd if=$inf of=$out dd if=/dev/random of=/dev/null The mini-syntax should extend till the end of a single command: ; & && and || should stop it. Note that it's the first time I use yacc, so probably there is a better way to code this and there are probably bugs. For example I was unable to make this works: % $ echo ./configure --prefix=`{cat /env/prefix} Giacomo 2017-05-16 17:59 GMT+02:00 Erik Quanstrom <quans...@quanstro.net>: > by doing it in the grammar, the redirection issue is avoided. > > - erik > > > On May 16, 2017 2:24 AM, Charles Forsyth <charles.fors...@gmail.com> > wrote: > > > On 15 May 2017 at 17:44, trebol <trebol55...@yandex.ru> wrote: > > > = is part of rc syntax, like {} and (), and it interprets it, not the > > > i'd forgotten about the = in >[2=1], so you'd need another exception ... > rc would interpret that, but then in [a-b=] it presumably wouldn't again... > > >
Re: [9fans] equality sign in Rc
Ok, sorry... :-) However what about disallowing '-' as variable's name starting character? It would be a breaking change, but probably more in theory than in practice. However options like -Da=1 and --foo=bar could then work unquoted. To my untrained eye, the gain seems larger than the loss. Am I missing an obvious use case? Or maybe the changes to rc's code would be too complex? Giacomo Il 15/Mag/2017 18:39, "Charles Forsyth" <charles.fors...@gmail.com> ha scritto: > > On 15 May 2017 at 17:30, Giacomo Tesio <giac...@tesio.it> wrote: > >> % echo "$--fu" >> rc: null list in concatenation >> > > wrong quotes. try echo $'--fu' > > h% --x=hello > h% echo $'--x' > hello > >
Re: [9fans] equality sign in Rc
Actually a --fu variable is not that useful in Plan 9: % --fu=bar % echo $--fu rc: null list in concatenation % echo "$--fu" rc: null list in concatenation % ls /env '/env/*' /env/--fu ... So rc can create a variable starting with more than one '-', but can't use it. So I wonder if there is a definition of "the right thing" that can fix this incongruence and also allow the UNIX usage. Giacomoec 2017-05-15 17:59 GMT+02:00 Charles Forsyth: > > On 15 May 2017 at 16:54, Erik Quanstrom wrote: > >> if we implement the right thing, then arguments like --fu=bar will be >> 'eaten silently' from the perspective of the (human) operator. sure gigo, >> but this seems extra hard o get right in a Unix environment. > > > It would be better then to leave things as they are. > = is part of rc syntax, like {} and (), and it interprets it, not the > commands, unless quoted. >
Re: [9fans] Blocking on write
I've just noticed a strange behaviour in devpipe that occurs on both 9front and Plan 9. When the write blocks, if a note interrupt the process, the waserror in pipewrite and pipebwrite will post another note that says "sys: write on a closed pipe ..." However the pipe is actually open, and still works, as you can see in the attached test. Shouldn't the waserror code check that the queue has been actually closed? Giacomo 2017-05-15 15:36 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > Thanks Charles! > > > Giacomo > > 2017-05-15 12:32 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: >> >> On 15 May 2017 at 11:05, Giacomo Tesio <giac...@tesio.it> wrote: >>> >>> Is there any fs/device in Plan9 that can easily provide such behaviour? >> >> >> Bind #| to a name and fill up one of the data files (blocks at 256k on my >> system, might be 32k on small ones). #include #include int writeTillBlock(int fd) { int i = 0; char buf[1024]; memset(buf, 1, sizeof(buf)); while(i < 300){ if(write(fd, buf, sizeof(buf)) < 0) break; print("%d\n",i); ++i; } return i; } int continueOnAlarm(void *v, char *s) { if(strncmp(s, "alarm", 5) == 0) return 1; if(strncmp(s, "sys: write on closed pipe", 25) == 0) return 1; return 0; } void main(void) { int fds[2], res; char buf[1024]; pipe(fds); atnotify(continueOnAlarm, 1); alarm(1); res = writeTillBlock(fds[0]); if(res < 256){ while(res > 1){ read(fds[1], buf, sizeof(buf)); --res; } if(write(fds[0], buf, sizeof(buf)) < 0){ print("FAIL: can't write after reads: %r\n"); exits("FAIL"); } print("PASS\n"); exits(nil); }else{ print("FAIL: written %d kb\n", res); exits("FAIL"); } }
Re: [9fans] Blocking on write
Thanks Charles! Giacomo 2017-05-15 12:32 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 15 May 2017 at 11:05, Giacomo Tesio <giac...@tesio.it> wrote: >> >> Is there any fs/device in Plan9 that can easily provide such behaviour? > > > Bind #| to a name and fill up one of the data files (blocks at 256k on my > system, might be 32k on small ones).
[9fans] Blocking on write
Hi, to write a test I'm looking for an easy way to have a write() blocking forever. Is there any fs/device in Plan9 that can easily provide such behaviour? Giacomo
Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)
Il 06/Mag/2017 10:22, "Francisco J Ballesteros" <n...@lsub.org> ha scritto: considering as the HW all the machines I use, including their OS as the new “HW”. I'm afraid it's what they are trying to achieve with webassebly. And in a way Inferno was doing the same, wasn't it. I agree that in a network, several different os should be able to work together seemlessy. But despite my efforts in Jehanne I don't think the key to achieve this is a os, nor a language. IMHO the key is a better general purpose protocol, as simple as 9p but able to replace http. Giacomo
Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)
You might find https://lsub.org/ls/clive.html interesting. Giacomo 2017-05-05 15:25 GMT+02:00 Dave MacFarlane <driu...@gmail.com>: > On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber <s...@stanleylieber.com> wrote: >> >> Plan 9 has not yet been re-implemented in Go. >> >> sl >> > > I started trying to do that at one point, but never got my kernel much > farther than booting just enough to run "Hello, world!" compiled with > 6c on a FAT filesystem in ring 0 and then crashing the system before > deciding I don't have the time to finish it or get it somewhere > useable. If anyone who has the time is interested in picking it up, > contact me off-list and I'll send you a link to my (horribly written > and designed) code. > > I'm more of a userspace kinda guy anyways.. > > - Dave
[9fans] NSAVE/NRSTR use case in libap
Reading notify(2) I've noticed that I do not understand POSIX signals enough to grasp the problem NSAVE/NRSTR are designed to solve. Initially I supposed they where supposed to allow nested signals, so that a note occurred during the execution of a signal handler wont need to wait for NCONT. Thus I suppose that I'm missing something: I can't imagine a (non real-time) program requiring to handle a signal while handling a signal. So my questions are: - why Plan 9 needs NSAVE/NRSTR? Which ANSI/POSIX semantics are they designed to help with? - can you point me to an application actually using such semantics (either ported to Plan9 or not). Giacomo
Re: [9fans] Why getenv replaces \0 with spaces in the returned value?
Yes that would be a plausible explanation but actually rc does not use getenv: it reads /env/ files directly. I've tried to remove the loop and I can't see any issue. Giacomo 2017-01-18 21:13 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > Yes, it's the lists. Nothing will cope with \0 in a C string, so it's a good > choice as list of string element separator. > > On 18 January 2017 at 19:21, Fran. J Ballesteros <n...@lsub.org> wrote: >> >> rc lists? >> >> > El 18 ene 2017, a las 17:45, Giacomo Tesio <giac...@tesio.it> escribió: >> > >> > Hi, last night I noticed this strange post processing in 4th edition's >> > getenv: >> > https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41 >> > >> >seek(f, 0, 0); >> >r = read(f, ans, s); >> >if(r >= 0) { >> >ep = ans + s - 1; >> >for(p = ans; p < ep; p++) >> >if(*p == '\0') >> >*p = ' '; >> >ans[s] = '\0'; >> >} >> > >> > Anybody know why this replacement is done? >> > It does not seem a good fix to read/write or read/truncate races, but >> > I can't find a better explanation. >> > >> > >> > Giacomo >> > >> >> >
[9fans] Why getenv replaces \0 with spaces in the returned value?
Hi, last night I noticed this strange post processing in 4th edition's getenv: https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41 seek(f, 0, 0); r = read(f, ans, s); if(r >= 0) { ep = ans + s - 1; for(p = ans; p < ep; p++) if(*p == '\0') *p = ' '; ans[s] = '\0'; } Anybody know why this replacement is done? It does not seem a good fix to read/write or read/truncate races, but I can't find a better explanation. Giacomo
Re: [9fans] memory leaks in libmp
Oh, well, I'm sorry, I should have clarified the context a bit more. Here it is. The link I provided here are Jehanne issues, not Plan 9 or 9front bug reports. After fixing a few of them I realized that, an year from now, I won't be able to remember why I did the change. Also, coverity could shut down and I would have no hint. So I started coping the coverity scan comments, as a sort of note to a future self wondering "Why the hell I changed this code?". The coverity comments in the Jehanne issues are NOT a proof of anything, they are just quick reminders for Jehanne's developers. Given that, I thought: why not share these with 9fans and 9front since they use that code too but cannot access coverity? Now, for Jehanne these issues were already marked as "worth considering" (and in this case "worth fixing"). And I'm fine if you consider them false positive or even use a different fix, since that force me to challenge my assumptions, to review the code more and even learn from better programmers than me. Indeed I really like your feedbacks, because you are very deep in the code base and it usually take you seconds to understand issues that require me days to figure out. But these are still **Jehanne's issues**, they are shared in the hope they helps but with no warranty! ;-) As you note, I could do it test-driven, providing a failing test and then fixing the test. You are right, it would be much more useful to Jehanne and maybe to the Plan 9 ecosystem too. But, unfortunately, I'm working alone and I do not have the energy to do this every single time. And I'm one of those few weird people thinking that you should not care about code coverage if you don't want to pay for a full one. Thus I cannot share patches that you can blindly apply, sorry. As for the issue in question, I think it's a actually a bug. mp(2) states that > > Mptobe and mptole convert an mpint to a byte array. The > former creates a big endian representation, the latter a > little endian one. If the destination buf is not nil, it > specifies the buffer of length blen for the result. If the > representation is less than blen bytes, the rest of the > buffer is zero filled. If buf is nil, then a buffer is > allocated and a pointer to it is deposited in the location > pointed to by bufp. Sign is ignored in these conversions, > i.e., the byte array version is always positive. To my eye it should only consider bufp if buf is nil. And bufp should be not nil in that case. Thus the fix was simply to add an assert to make if fail fast instead of leaking memory. The simple reasoning I did during triage was: consider a pointer to a struct holding both buf and its length: mptole(num, s->buf, s->len, nil) it will cause the leak if the struct was just zeroed. In this case I prefer the assert fail to the leak, so that I, as a dumb guy, would notice the issue more rapidly. Giacomo 2017-01-18 3:31 GMT+01:00 <cinap_len...@felloff.net>: > > Still a lot of coverity defects are actually false positives. > > I try to signal here only the actual bugs but I might be wrong, thus let > me > > know if you find these report useless and I will stop to annoy the list. > > i cannot predict the future nor tell you how to spend your time. i'm *not* > claiming that using static code analysis to find bugs is "useless" per se. > > but consider the context in which problems would occur, maybe even describe > how a bug would manifest itself in some code (thats what takes the time or > wastes our time when you do not do this), and not just blindly present the > coverty output as a proof. > > -- > cinap > >
[9fans] memory leaks in libmp
Hi, these other two defects identified from Coverity scan that you might find interesting: https://github.com/JehanneOS/jehanne/issues/5 https://github.com/JehanneOS/jehanne/issues/6 NOTE: 9front's guys consider these a false positive, since both mptole(n, nil, 0, nil); and mptobe(n, nil, 0, nil); are stupid bugs in the caller. Since, I do stupid errors often, I prefer to fix the leak. Still a lot of coverity defects are actually false positives. I try to signal here only the actual bugs but I might be wrong, thus let me know if you find these report useless and I will stop to annoy the list. Giacomo
[9fans] out of bound access in libsec
Hi, running coverity scan on libsec it reported two defects that do not seem false positives: 1. an out of bound access to aesXCBCmac (see https://github.com/JehanneOS/jehanne/issues/3 ) 2. an out of bound access in msgRecv, tlshand.c:1809 (see https://github.com/JehanneOS/jehanne/issues/4 ) I verified that the code is more or less the same on 9front. I "fixed" the first with an assert, but I'm not sure wherther passing sizeof(m->u.finished.verify) to memset in the second is the correct solution. Am I missing something? Giacomo
Re: [9fans] Porting Idris to 9front
2017-01-13 15:05 GMT+01:00 Joe M <joe9m...@gmail.com>: > > > > Don't you need GHC to compile Idris? > > http://docs.idris-lang.org/en/latest/faq/faq.html#when-will- > idris-be-self-hosting > > I have the posix version of the rts working on 9front. The default C > backend generated code compiled and runs on 9front. I generated the c > code on linux though. > Can you detail the process? I'd like to give it a try on Jehanne (which is built with gcc). Giacomo
Re: [9fans] A heartfelt thanks... :-)
2017-01-06 10:34 GMT+01:00 Anthony Martin <al...@pbrane.org>: > Ciao Giacomo, > Ciao Anthony, ottime domande! :-) Let's start from the easy ones: > Oh, and where are the man pages? /doc/hacking is missing. Man pages in Jehanne will be readable in source form. Cat should be enough to render them. This means that I have to port them from troff to something like markdown or commonmark (or something even better if possible). Whatever will be the format, it must be readable in source form. /doc/hacking/ is just waiting to be filled. I know it's important, but so far I gave priority to hacking itself, instead of documentation. The state of the web site is a sad effect of this choice. I will try to scratch something in the next week. > I'm interested in reading about your awake system call and the changes > you've made to rendezvous and the variuos locks in libc. > Well awake is the complement of sleep: instead of blocking for a number of ms, it wakes up a process blocked on a syscall after a number of ms. Actually right now the only syscall that can be awaken is rendezvous, but I will add support for it to all others blocking syscalls. As for it's impact on libc I will write something asap. Why did you choose to create devself? Everything it does seems > better suited to devproc. If I was going that route, I'd instead > create a QTDIR file in devproc called #p/self that is just another > view into #p/$pid. Then brk and chdir would be control messages > written to #p/self/ctl. Same with seg^(attach detach free). You > could also make those be control messages written to #p/self/segment > instead. > I evaluated that option and actually devself and devproc are related, but different: - in Jehanne you cannot access #p after an rfork(RFNOMNT), but you can still access #0/segment - in Jehanne you cannot access #c after an rfork(RFNOMNT), but you can access #0/null or #0/pid - wdir is present in both #p and #0 so that chdir first try to open /proc/$pid/wdir and only on failure try with #0/wdir. This allows a process to intercept changes to the working directory of another (that want to cooperate). Guess what's the first use case for this (still to be implemented, actually)? Note that both devices are still work in progress! For example this state of things poses some security concern, but it's part of an overall design that will include a new flag to rfork to limit the process visible in #p to children and other security related changes to its working. > > Also, I think it's a mistake to overload the return value of the > remove system call for passing arbitrary integers out of the kernel. > I understand why you want something like that, however. Moving > system calls into reads and writes of various files increases the > number of context switches since you have to open and close the > files. Why not do exactly what you want and make a new system > called readint or something? > No, well... actually it's not a just matter of performance. Remove is not the only "overloaded" system call in Jehanne, it's just the easy to catch! :-D Again this is a rather large topic strictly linked to the file protocol that I'm designing. Devices and file servers will allowed to assign custom semantics to values that are not used by the operating system. For remove and close this just means all the possible return values except ~0 that is used for errors. For open, pread and pwrite it means all negative values of long arguments and return values (again except ~0). Giacomo
[9fans] A heartfelt thanks... :-)
Hi, I've just published a summary of my last year of experiments with Jehanne with a thanks to these communities and to their members: http://jehanne.io/2017/01/06/a-year-with-jehanne.html It's worthless to say that I couldn't have done anything without your code and your help. Thanks. Giacomo
Re: [9fans] create/create race
Thanks Charles! This is exactly the kind of info I was looking for. Giacomo 2016-11-30 22:53 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 30 November 2016 at 21:51, Charles Forsyth <charles.fors...@gmail.com> > wrote: > >> that the whole path name is re-evaluated 3 times > > > That doesn't happen with the current implementation, because it walks to > the parent directory, does the create/open etc at that point with a > reference held. >
Re: [9fans] create/create race
2016-11-30 16:08 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 30 November 2016 at 15:02, Giacomo Tesio <giac...@tesio.it> wrote: > >> >> But reading that thread I can't actually see why the OEXCL path has been >> taken instead of eliminating the race mapping the syscall to the 9p message. >> I mean except backward compatibility. >> > > I suppose you'll find out, but I'd expect that all but a handful of > instances want the existing effect and are untroubled by any potential race. > Given that OEXCL then seems to handle the handful, it seems a reasonable > approach. > The ocreate would just put the race in a different place, wouldn't it? > Well not exactly: I will use the new create syscall (without OEXCL support) when I need such level of control and use ocreate with OEXCL when I do not care about the race and want a "create or truncate" default behaviour. But actually, I cannot see a use case where the create(2) default behaviour can be *wanted*. I just see many use case where it can be tollerated: the create can fail anyway for other reasons so it does not add much complexity to the client... But I'm probably missing something obvious: can you provide an example where not having the truncate fallback in the syscall actually break the program or introduce a bug. It's exactly what I'm looking for. Giacomo
Re: [9fans] create/create race
David it seem you walked my road already... :-) I'm actually on a research project, so I do not care too much about the issues on existing programs. I'm going to change/break them anyway. Also, as far as I can foresee, it should be viable to fix such programs in a partially automated way (eg via sed and a new "ocreate" library function that mimic the current behaviour). But reading that thread I can't actually see why the OEXCL path has been taken instead of eliminating the race mapping the syscall to the 9p message. I mean except backward compatibility. Maybe it was found a performance issue in some more common use case? Or a worse race prevented by the current semantic? For example I've found pretty cryptic this message from David: http://marc.info/?l=9fans=111558704718797=2 I'm surprised I haven't yet seen "What about union directories?" > > If create(2) is changed then it could succeed even though a > file with that name exists in the union. Then the above: > > if ((fd = create(file, mode, perm)) < 0) { > error... > } > > Would need to become: > > if ((fd = open(file, mode|OTRUNC)) < 0 || > (fd = create(file, mode, perm)) < 0 || > (fd = open(file, mode|OTRUNC)) < 0 || > error... > } > > This is precisely the current create(2) call and the nasty > race is clear. > > Why the initial open() would be needed if create(2) always send a Tcreate? Giacomo 2016-11-30 14:53 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 30 November 2016 at 13:32, <cinap_len...@felloff.net> wrote: > >> interesting, the thread starts here: >> >> http://marc.info/?l=9fans=111558704718788=2 >> > > > I suspect the discussion predated 9P2000 and the introduction of the OEXCL > option. >
Re: [9fans] create/create race
Hi guys, I know this is a noob question, but I'd really like to understand this aspect of the kernel design. I'm planning to experiment on the topic, modifying chan.c so that the semantics of create(2) match those of create(5) about existing files. I guess that the number of callers to fix is manageable. But since I can't see any good reason for the race being there in the first place (except maybe backward compatibility with unix, but that was not a problem for Plan 9 designers), I'm pretty sure I'm missing something obvious. So, please, do you know why the create syscall does not simply return an error if the file already exists? You might save me a few headache... Thanks for your help! Giacomo 2016-05-24 23:25 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > I'm pretty curious about the create(2)/create(5) race described in a > comment in namec (see https://github.com/brho/plan9/ > blob/master/sys/src/9/port/chan.c#L1564-L1603) > > Does anyone know or remember the reasoning behind this design? > > What was wrong about using the create(5) semantics for the create(2) > syscall? > > > Giacomo >
Re: [9fans] devsegment usage examples
Neat, thanks! I wonder if a similar approach could be used to move some device drivers out of kernel... Btw, I did read the sample in segment(3) but I was looking for a real world example. What I'm trying to understand is not *how* to use devsegment, but *when* to use it. Which problems is it designed to solve? Moreover, Zinq's graphics use a very smart approach, but it's specific to 9front evolution of the device with the "fixed" type. I'm also looking for the general use case, when segments are not used for DMA, as designed in the original Plan9. Giacomo 2016-08-31 12:40 GMT+02:00 <cinap_len...@felloff.net>: > > Hi, I'm looking for an usage example of devsegment. > > > > I cannot find anything neither in bhro's plan9 nor in 9front. > > > > Can anybody share a real usage world example? > > > > > > Giacomo > > its just creating named segments of some shared memory. > > segment(3) has an example. read it. > > on 9front, you can also allocate physically continuous segments *and* > get the physical base address for it :) > > one application for it is on the zynq. the displayport graphics is > implemented using the fpga and userspace uses devsegment > to allocate 5MB of physically continous memory for the framebuffer: > > #!/bin/rc > rfork en > bind -c '#g' /mnt/segment > if(! test -d /mnt/segment/fb){ > mkdir /mnt/segment/fb > echo 'va 0x0050 0x0050 fixed' > /mnt/segment/fb/ctl > } > > bind -b '#P' /dev > audio/pcmconv -i 'c1u32r1' -o 'c1U32r1' < ./build/out.bin > /dev/pl > > then some c code programs the graphics register and hands the > loaded core the physical address for DMA. > > -- > cinap > >
[9fans] devsegment usage examples
Hi, I'm looking for an usage example of devsegment. I cannot find anything neither in bhro's plan9 nor in 9front. Can anybody share a real usage world example? Giacomo
Re: [9fans] The Plan 9/"right" way to do Facebook
2016-04-03 6:42 GMT+02:00 <lu...@proxima.alt.za>: > > We are already trained to be suspicious about the truth even when it's > > clearly evident, now we can even start to ignore the information from the > > physical world, while accepting the virtual information that someone else > > feed us. > > For an Italian inheriting the legacy of Galileo Galilei, you sure > approach Science from an odd angle. "suspicious about the truth" is > good, scientific behaviour. "clearly evident" is not. > Theoretically, this is a very good point! :-D But what is good for scientific research will work very badly for social behavior and politics. As an Italian, I also inherit the legacy of Macchiavelli and believe me: uncertainty, indifference and divisions (and fear) are among the most powerful tool to gain and preserve power. I'm not afraid of people challenging mainstream opinions (this is Plan9, isn't it? :-D), I'm afraid of people doubting about evident facts or simply ignoring them: climatic changes? unsustainable distribution of wealth? parents negating their kids misbehavior? inadequate legal systems for the current world? and so on... Giacomo entirely off topic, sorry
Re: [9fans] The Plan 9/"right" way to do Facebook
While funny in it's visionary shape, I'm seriously scared about this matter. Take for example Google's material design: any software that successfully mimic the physical world (paper layers in particular) is going to bland our perception of its "virtuality". Our mind is going to accept it as a physical tool. Now, we "know that a programmable computer is no more and no less than an extremely handy device for realizing any conceivable mechanism without changing a single wire", but are we sure we really want to remove the awareness of the wires? Google glasses scare me even more: we are going to look the world through some one else eyes. In the long run, our brain will start to accept the virtual baloons like the other physical entities that really exists. We are already trained to be suspicious about the truth even when it's clearly evident, now we can even start to ignore the information from the physical world, while accepting the virtual information that someone else feed us. Giacomo 2016-04-01 22:00 GMT+02:00 <cigar562hfsp952f...@icebubble.org>: > lu...@proxima.alt.za writes: > > > I don't even remember the name of the feature, but I used a tool way > > back in the very early days of a public Internet (it was called a MOO, > > > Given a browser-style interface with 3D capabilities, it would address > > social networking considerably better than Facebook (with which I have > > > For that is what social media provide: a world-wide stage on which you > > perform selections from your real life and any fantasy life you choose > > Very interesting. I was envisioning a system which would (at least on > its GUI side) present information in the form of a Web page, like > Facebook, LinkedIn, etc. I hadn't thought of abandoning the Web page, > altogether, for some other kind of "social space" browser. I wonder > what that might be like. > > [Disclaimer: This is NOT a formal or serious proposal for a new Plan 9 > file system. (Not yet, at least.) It's just an exploration of some > potentially possible possibilities.] > > For a social network to be useful, it must provide some intuitive > mapping between information in the virtual world and its real-life > referents. (In contemporary social networks, these take the form of > person/place names, mugshots, and interactive maps with balloon icons.) > The space which humans are most familiar with navigating, of course, is > meatspace - the physical, brick-and-mortar world. It makes sense, then, > that the most intuitive interface would offer some kind of three- > dimensional virtual reality. The simplest, most intuitive mapping > between virtual space and meatspace would probably be to visually > "overlay" information from the virtual space onto meatspace. Technology > (mostly in the form of various head-mounted glasses or goggles) already > exists which allows a person to see what's around them, while projecting > information ontop of what they see. A device such as this has generally > been called an "eye tap". But it has a problem: when you turn your > head, the display turns with it. In order for the UI to be as intuitive > as the physical world, it would have to maintain orientation with its > physical environment. Tracking motion of the user's head could be done > using accellerometers, a la Oculus Rift. Imagine a Rift with two video > cameras on its front (to provide a binocular view on the physical world) > that overlays a digital world ontop of the real world you see. Virtual > arrows could guide you where you need to go without needing directions. > When you get near your favorite Chinese restaurant, a balloon could > appear in your view, giving you access to information about it. When > GPS magic detects that a friend of yours is nearby, an friendly-looking > arrow appears, indicating the general direction and approximate distance > to him or her. > > In order for a virtual world to be useful, however, simply mimicking the > physical world won't do; its physics must differ from the physics of the > real world in some useful way. If your favorite restaurant is two miles > from your present location, for example, you won't want to walk two > miles to find its virtual balloon. :) Navigating the virtual space > would require some way to stretch/pan space and time, allowing the user > to "fly" about and move forward/backward in time within the virtual > world, before restoring the overlay to match normal space/time. You > would, for example, be able to hike the trail I hiked yesterday, even > after I got back from hiking it. If I recorded GPS waypoints and/or > stereoscopic video along the way, you could hike right along with me, > having a conversation with my avatar ab
Re: [9fans] Libc locks documentation
Thanks Charles! Giacomo 2016-03-25 17:38 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > If you look for "condition variables" for event notification, > you'll find relevant material, such as this paper > https://www.cs.berkeley.edu/~brewer/cs262/Mesa.pdf > which has a few references in it too. There's a little evolutionary > history of them somewhere. > > On 24 March 2016 at 19:56, Giacomo Tesio <giac...@tesio.it> wrote: > >> Hi, I'm a bit ignorant but I cannot recognise the algorithms in qlock.c. >> >> Where I can find more documentation about them? Any paper I can read? >> >> For example the rsleep/rwakeup always look a bit magic in its coupling >> with qlocks. I'd really like to know more about these algorithms, but given >> their use of rendezvous I can't find anything related. >> >> Can you provide me some references? >> >> Giacomo >> > >
[9fans] Libc locks documentation
Hi, I'm a bit ignorant but I cannot recognise the algorithms in qlock.c. Where I can find more documentation about them? Any paper I can read? For example the rsleep/rwakeup always look a bit magic in its coupling with qlocks. I'd really like to know more about these algorithms, but given their use of rendezvous I can't find anything related. Can you provide me some references? Giacomo
[9fans] startboot signature
Out of curiosity, why the startboot function in port/initcode.c is `void startboot(char *argv0, char **argv)` given the argv0 is ignored? I see that this simplify various main() in init9.s but I wonder why not simply use `void startboot(char **argv)` Giacomo
[9fans] FP register usage in Plan9 assembler
I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler programming, so sorry if my question is too dumb... I cannot understand the FP pseudo register usage. The cpuid function, for example, is implemented as /* * The CPUID instruction is always supported on the amd64. */ TEXT cpuid(SB), $-4 MOVLRARG, AX/* function in AX */ CPUID MOVQinfo+8(FP), BP MOVLAX, 0(BP) MOVLBX, 4(BP) MOVLCX, 8(BP) MOVLDX, 12(BP) RET What I miss is where "info" comes from. I cannot Apparently the GAS equivalent is: .align 4 .globl cpuid cpuid: mov%ebp,%eax cpuid mov0x10(%rsp),%rbp mov%eax,0x0(%rbp) mov%ebx,0x4(%rbp) mov%ecx,0x8(%rbp) mov%edx,0xc(%rbp) retq Thus apparently info+8(FP) becomes 0x10(%rsp) Why? I know that FP is a pseudo register, but shouldn't it be different from SP? And why info's value is 8? Is it the pointer size? Another example: TEXT insb(SB), 1, $-4 MOVLRARG, DX/* MOVLport+0(FP), DX */ MOVQaddress+8(FP), DI MOVLcount+16(FP), CX CLD REP;INSB RET should be equivalent to .align 4 .globl insb insb: mov%ebp,%edx mov0x10(%rsp),%rdi mov0x18(%rsp),%ecx cld rep insb retq Again I cannot find a definition of address and count, but both seem to be be valued as 8, why? Giacomo
Re: [9fans] FP register usage in Plan9 assembler
Thanks for the explainations! I did read in the Pike's paper about the syntax name+offset(FP), but I did understood that name had to be a symbol already defined, and I was looking for it in the c code. Sorry for the noise! This led me to another question, however: I've read before that the plan9 compilers use the stack for va_list, but here the assembler is using it also for explicit parameters, right? Is it correct to say that this means that the Plan9 compiler suite *never* follows the sysV calling convention documented at section 3.2.3 of AMD64 ABI http://www.x86-64.org/documentation/abi.pdf and always pushes parameters to the stack? Giacomo 2016-02-01 23:48 GMT+01:00 <cinap_len...@felloff.net>: > FP is a translated to a varying offset to SP depending on where in the > program > you are. arguments on the stack are padded to 8 bytes on amd64, the first > argument > is not passed on the stack on function entry, but passed in BP register > (RARG is an > alias for that), however the slot on the stack for first arg is still > reserved > so we have a save place to splill it. so 0(FP) is first function argument > on the > stack, 8(FP) second argument 16(FP) third ect... > > -- > cinap > >
Re: [9fans] FP register usage in Plan9 assembler
I kinda agree, but I'm too incompetent in the matter. :-) However, I was simply asking if, on amd64, kencc uses the 6 registers that the abi deserves to the parameters. As far as I've understood only BP is used (for the first argument, if integer). Can you confirm? Giacomo 2016-02-02 1:36 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 1 February 2016 at 23:34, Giacomo Tesio <giac...@tesio.it> wrote: > >> >> Is it correct to say that this means that the Plan9 compiler suite >> *never* follows the sysV calling convention documented at section 3.2.3 of >> AMD64 ABI http://www.x86-64.org/documentation/abi.pdf and always pushes >> parameters to the stack? > > > On amd64, the first parameter, if an integer, is passed in RARG, which is > actually BP. > The RISC machines generally pass the first parameter, if an integer, in a > register. > > In general, the compiler suite never follows conventions prescribed by > apparent maniacs. > In particular, varargs/stdargs should (in 2000, let alone 2016) be really > easy: lay down the ... parameters on the stack as an array in memory. > Done. Instead ABIs give pages of filth that try to work out where things > are for the va_x macro calls, > because the ABI insists on following the same calling convention > for vararg/stdarg functions as might be used for other functions with > fixed parameters: parameter passing in registers, special rules for > structs, special rules for structs that fit in the parameter registers, > special rules for floating-point values. Absurd. >
[9fans] segbrk(2) vs friends
I'm trying to understand the reason behind the introduction of segbrk(2). I cannot find a use case in the codebase. The manual <http://man.cat-v.org/plan_9/2/segbrk>page states that: The segbrk system call may go away or be re-implemented to give more general segment control, sub- suming the functions of brk(2) <http://man.cat-v.org/plan_9/2/brk>, segflush(2) <http://man.cat-v.org/plan_9/2/segflush> and segfree insegattach(2) <http://man.cat-v.org/plan_9/2/segattach>. But given the manpage itself is pretty cryptic, I wonder if it's outdated. Or if it is actually deprecated. Do you know any paper that can explain its design and intent? Giacomo
Re: [9fans] Compiling ken-cc on Linux
2015-11-27 13:42 GMT+01:00 <tlaro...@polynum.com>: > On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote: > > > > I know nothing about compilers, but actually gcc and clang dimension and > > complexity is astonishing. > > It's not astonishing: it's research. They want to prove that a black > hole does exist. > Funny, but actually I was wondering if there is any subtle issue in the standards of the C language that makes it somehow hard to implement. For example I've met a few times weird implementations of libraries and frameworks dictated by broken standards: once they are in, they can never be removed due to backward compatibility. I thought that Charles (that also implemented the Limbo compiler) might have referenced these kind of issues in his pun. Giacomo
Re: [9fans] Compiling ken-cc on Linux
2015-11-27 0:21 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 26 November 2015 at 23:08, Ryan Gonzalez <rym...@gmail.com> wrote: > >> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't >> think it used that much. I only have 6 GB right now! > > > You have to remember that a C compiler is one of the largest, most complex > software components that human beings have ever had to produce. > The original C reference manual made it look deceptively easy, but really > there's a ton of stuff going on in there, as you can see. > How they ever got it going on a system with 64Kbytes of address space, > I'll never know. > I'd love to read more about this, Charles. :-) I know nothing about compilers, but actually gcc and clang dimension and complexity is astonishing. I've always thought that this is due to their desire to compile many different language optimized for many different OS and architectures on many different OS and architecture. Alternative compilers, like tcc, only build C on very few architectures / os with almost no optimization: they are much smaller, but still not standard compliant. How can it be? Giacomo
Re: [9fans] off topic - a good Git reference
2015-10-12 19:00 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>: > > On 12 October 2015 at 17:49, Álvaro Jurado <elbingm...@gmail.com> wrote: > >> what ensures sha key is in fs. > > > The reason many of us are a little sceptical about it being fsync as such > preventing the data appearing > is that if the git function that writes the key does a write or pwrite, > the key will be in the file system on Plan 9: there's no need for an fsync > just to get it there. > In fact, in Linux there's no need for an fsync just to get it there: it > only matters in the case of a crash. > > If the file system fails or you reset the machine, the intention of the > fsync will be frustrated, but > it shouldn't affect normal operation where no file server crash occurs. > > As it happens, a wstat that changes nothing can be interpreted by a file > server to have a similar effect as fsync (see stat(5)). > Thus Plan9 HAS fsync! :-o And it also has server-defined semantics! Very impressive! Giacomo
Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
2015-09-05 20:47 GMT+02:00 erik quanstrom <quans...@quanstro.net>: > > May be my problem is that p is global in my case? > > global variables are in the bss, and thus shared. p will have > the same value in each thread, but *p should point into the > stack, and thus the same virtual address will be mapped to > different physical pages of memory. > > however, if *p is assigned to a non-zero value before the process > is created, the new page allocated for the new process' stack will > have a copy of the old value, and thus not be 0. > > - erik > > That's exactly what happened. I misread privalloc(2), and assumed that privalloc()ed addresses were somehow reset on rfork. This is probably something to explicitly state the man page. Thanks you all! Giacomo
Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
... and given getpid(2) implementation, a pid based table could be quite expensive, since MyStruct is accessed very very often. 2015-09-05 16:03 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > 2011-05-20 3:30 GMT+02:00 erik quanstrom <quans...@quanstro.net>: > >> one note is that while i'm aware of privalloc(2), i didn't use it. the >> implementation doesn't appear correct for shared-memory procs. >> i think there are two issues >> - locking is unnecessary. the only preemptable unit of execution is >> a process and each process is guarenteed to have its own instance >> of _privates and _nprivates. >> - for shared-memory procs, we will run out of privates because >> the static privinit will be falsely shared. privinit should be replaced >> by using a private entry. >> > > In a set of processes that share memory, I need a single per-process > location to store the address of structure (which is in turn allocated in > the global memory space). > > Privalloc(2) seemed what I need, but seem that I can't use it properly. > > In the parent process I do: > > 1) initialialize a global variable p = (MyStruct **)privalloc(); > 2) allocate a MyStruct for every process I'm going to spawn > 3) spawn processes with rfork(RFMEM|RFPROC) > > The spawn() function that call rfork takes a MyStruct* as argument and > assign it to *p in the new process. > For extra safety I added an assert(*p == nil) just after rfork, and after > a few (apparently?) successful spawns, the assert fails. > > What I need is a sort of thread-local storage for the MyStruct*, so that > each child process can find it's own dedicated MyStruct. > I know that could get this with an hashtable based on the pid, but I'd > prefer to avoid the book keeping if possible. > > > Giacomo >
[9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
2011-05-20 3:30 GMT+02:00 erik quanstrom <quans...@quanstro.net>: > one note is that while i'm aware of privalloc(2), i didn't use it. the > implementation doesn't appear correct for shared-memory procs. > i think there are two issues > - locking is unnecessary. the only preemptable unit of execution is > a process and each process is guarenteed to have its own instance > of _privates and _nprivates. > - for shared-memory procs, we will run out of privates because > the static privinit will be falsely shared. privinit should be replaced > by using a private entry. > In a set of processes that share memory, I need a single per-process location to store the address of structure (which is in turn allocated in the global memory space). Privalloc(2) seemed what I need, but seem that I can't use it properly. In the parent process I do: 1) initialialize a global variable p = (MyStruct **)privalloc(); 2) allocate a MyStruct for every process I'm going to spawn 3) spawn processes with rfork(RFMEM|RFPROC) The spawn() function that call rfork takes a MyStruct* as argument and assign it to *p in the new process. For extra safety I added an assert(*p == nil) just after rfork, and after a few (apparently?) successful spawns, the assert fails. What I need is a sort of thread-local storage for the MyStruct*, so that each child process can find it's own dedicated MyStruct. I know that could get this with an hashtable based on the pid, but I'd prefer to avoid the book keeping if possible. Giacomo
Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
Nice example thanks. May be my problem is that p is global in my case? Giacomo Il 05/Set/2015 18:50, "erik quanstrom" <quans...@quanstro.net> ha scritto: > by the way, the following program runs without asserting for me > with or without the waits. > > - erik > > --- > > #include > #include > > void > task(void **p) > { > assert(*p == nil); > *p = (void*)(uintptr)getpid(); > } > > void > spawn(void (*t)(void**), void **p) > { > int pid; > > switch(pid = rfork(RFMEM|RFPROC)){ > case -1: > sysfatal("spawn: rfork: %r"); > case 0: > t(p); > exits(""); > default: > USED(pid); > return; > } > } > > void > main(void) > { > int i, k; > void **p; > Waitmsg *w; > > p = privalloc(); > k = 0; > for(i = 0; i < 1024; i++){ > spawn(task, p); > for(k++; k > 16; k--){ > if((w = wait()) == nil) > break; > free(w); > } > } > exits(""); > } > >
Re: [9fans] u9fs sources
2015-09-02 6:38 GMT+02:00 <lu...@proxima.alt.za>: > > I don't think it is currently maintained, but Plan 9 ships with a copy > > of it under /sys/src/cmd/unix. I used that as the basis of the OpenBSD > > port. > > I have it on my list of urgent tasks to fix u9fs. The more recent > copy (details need investigating) fails on NetBSD when encountering > group IDs that don't have a matching value in /etc/group as well as > under more mysterious circumstances. The older copy works adequately > (very similar platform, not identical), but it seems to care much less > about group IDs and it seems a waste that somebody would have done a > lot of work in vain. > Nice! Actually, I'm going to need the NetBSD port up and running in the relatively near future. A very useful thing to do is to list the known issues. Even more useful would be to setup a set of failing shell scripts that reproduces the issues, so that we can use them as tests. > > I can find out more about each, but if someone else is willing to > help, I'd also like to apply similar expertise to add ownership and > permission settings to NetBSD's variation of v9fs which I presume is > an analogous problem? > I did not know of a v9fs version for NetBSD... Any link? Actually, I don't care about neither 9p2000.U nor 9p2000.L. So, feel free to nudge me, if you can add to my rather limited skills, > the hardware can be made available for development and testing. > > Lucio. > I shouldn't need any hardware (a Xen domU should be enough), but in case I'll write you when I'm ready to work on this. Can you share links to the most updated sources for NetBSD? Giacomo
Re: [9fans] pthreads
2008-12-16 23:16 GMT+01:00 Steve Simon <st...@quintile.net>: > I have a distant memory that somone implemented some of POSIX pthreads > on plan9, i.e. I want to compile programs that use pthreads under APE. > > anyone got any pointers? > Hi Steve, did you find anything (even incomplete) back then? Giacomo
[9fans] u9fs sources
Hi, anybody knows where the u9fs sources are currently maintained? I have just found https://bitbucket.org/plan9-from-bell-labs/u9fs but it's only linked by an old googlecode repo: I was unable to find any official link in the bell labs pages. Giacomo
Re: [9fans] read9pmsg usage
2015-08-12 9:25 GMT+02:00 David du Colombier 0in...@gmail.com: This comment is indeed pretty old. It was already present in the Second Edition. So that check is based on pre 9p2000 code? If so, Charles have probably explained it: 2015-08-10 17:40 GMT+02:00 Charles Forsyth charles.fors...@gmail.com: As a further historical note, originally 9P required a stream that preseved record boundaries, and the reliable datagram protocol IL/IP and pipes did that. So, seem that ignoring zeros is simply wrong. A residual from the past... Giacomo
Re: [9fans] read9pmsg usage
2015-08-11 17:48 GMT+02:00 Charles Forsyth charles.fors...@gmail.com: On 10 August 2015 at 15:11, Giacomo Tesio giac...@tesio.it wrote: /* * reading from a pipe or a network device * will give an error after a few eof reads. * however, we cannot tell the difference * between a zero-length read and an interrupt * on the processes writing to us, * so we wait for the error. */ it's doubly odd, because there's no reason for an interrupted writer to go to the lengths of writing an empty record as a consequence of being interrupted. it will waserror out in the writer, so why should an empty Block end up on the underlying Queue? Ah, if only git existed when that comment was written! :-D When I read that comment I though of a remote user space writer, whose kernel (an old plan9 version?) on process interrupt gracefully send EOFs to all chan open for write. However I wasn't able to find anything concrete prove of this behavior in the codebase (but maybe I looked at the wrong places) In fact, an interrupted writer in devmnt will start the flush(5) protocol, so it will be writing Tflush, not empty records. This is interesting too: I thought that Tflush were for requests that had not yet been completed. But the interrupted writer could be just waiting. I mean the chan is open, but its last Twrite has already been replied with a Rwrite. In this case, sending a EOF on behalf of a process could have sense... or not? Probably depends on the interrupt. Giacomo
Re: [9fans] read9pmsg usage
2015-08-10 16:54 GMT+02:00 Charles Forsyth charles.fors...@gmail.com: Zero conventionally means end-of-file, but record boundaries are preserved on capable streams, so if a writer writes zero, the reader reads zero. However this two requirements do not seem reconcilable. Zero can either mean EOF or I'm alive but boring. I can't see how a reliable communication (a cpu connection for example) can survive this mismatch. I'm probably missing something. Giacomo
[9fans] read9pmsg usage
Hi, I've a probably naive question that I can't figure out. I've just noticed that fcall(2) states Read9pmsg calls read(2) multiple times, if necessary, to read an entire 9P message into buf. The return value is 0 for end of file, or -1 for error; it does not return partial messages. but I've noticed that a few client does not interpret a 0 return value as a EOF, eg https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606 https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891 https://github.com/brho/plan9/blob/master/sys/src/cmd/aux/searchfs.c#L613-L615 https://github.com/brho/plan9/blob/master/sys/src/cmd/lnfs.c#L547-L551 https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937 The comment there states that /* * reading from a pipe or a network device * will give an error after a few eof reads. * however, we cannot tell the difference * between a zero-length read and an interrupt * on the processes writing to us, * so we wait for the error. */ However many other fs just handle errors and eof together, for example here: https://github.com/brho/plan9/blob/master/sys/src/cmd/ip/ftpfs/ftpfs.c#L273-L279 I'm a bit confused about this. What's the proper use of the 0 return value? Giacomo
Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9
Il 27/Lug/2015 23:47, Skip Tavakkolian 9...@9netics.com ha scritto: you are aware of the 9fans' fetish for movies and rabbits ...and feticists. ;-)
Re: [9fans] small VFD display
2015-06-09 20:34 GMT+02:00 Ethan Grammatikidis eeke...@fastmail.fm: search the web for EWD898. it's a good read; fascinating how little has really changed. I know it's off-topic, but it's funny to compare that Dijkstra's paper with this video https://www.youtube.com/watch?v=qlRTbl_IB-s (and this site http://2045.com/ !) I've just found it, and suddenly I realized that all the crazy ideas I've got in the past were quite realistic, after all. :-D Giacomo
Re: [9fans] using git
Ah, a small addendum: obviously we also use tags a lot to give a specific commit (and related history) a name. This is done automatically by build servers for the official tags, and manually by developers whenever they want in their own repository (often with tags like, workedhere, shittorefactortomorrow and so on). Giacomo 2015-03-30 11:48 GMT+02:00 Giacomo Tesio giac...@tesio.it: As I use both git and hg, I really miss the feature-branching in hg (obviously, you can, if you try hard enough, use feature branching with hg too, but git makes it so easy that it became my default process whenever I can use git for development, even on solo projects): Suppose you have a team of 3 or more people and a central git server that can be used for facility of share (company server, github, bitbucket, gitorious...): each person start working on a issue (let it be a bug to fix or a new feature to implement) by doing on his working copy git checkout -b feature-nickname than it change anything that he consider relevant, committing whenever he decides that a change can be described in a sensible way: git commit -am 'OptimizingVisitor applies DeMorgan laws' ... a few work after... git commit -am 'OptimizingVisitor detects constants predicates' At any time, each developer can push the changes to the central server, to share his progresses and without the pain to merge them until the full issue has been addressed. The next day, a different developer could continue his work if it's really required (rarely, but it happened). When the feature has been fully implemented, the dev can merge it into the shared branch (master, or development when a human-driven test process is required before the production deployment). We do not use rebase: we want to keep track of which code the dev was seeing while writing his changes. At any time, we can see what features have been released, looking at which branches have been merged in the shared branch. On medium to large projects (5 to 20 people) this process allows a fast, painless collaboration. Still, whenever I can use git, I use it for my solo projects too, and I find it quite good to keep track of the progress of the project. My two cents. Giacomo 2015-03-28 15:00 GMT+01:00 Paul Lalonde paul.a.lalo...@gmail.com: I'd like to hear it too - much to learn from others' process. Paul On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth charles.fors...@gmail.com wrote: On 19 March 2015 at 18:26, arn...@skeeve.com wrote: Charles Forsyth charles.fors...@gmail.com wrote: On 19 March 2015 at 16:09, arn...@skeeve.com wrote: There is definitely some learning curve and mindset change Just what I want from a little servant that's supposed to help me manage some file changes. Git is intended for something completely different than RCS. I really, REALLY, don't want to start a flame war, although this being 9fans, it's probably not possible. More's the pity. And again, I AM NOT trying to proselytize. But, if you are curious as to what value I personally found in git for gawk development, I will be happy to discuss it in personal email. Unfortunately, switching between different devices I missed this reply. I wasn't really comparing it to RCS although I can see that was a reasonable conclusion from my wording. It might be worthwhile sending a brief description of what you use and what you find valuable to the list. There isn't much traffic at the moment.
Re: [9fans] using git
As I use both git and hg, I really miss the feature-branching in hg (obviously, you can, if you try hard enough, use feature branching with hg too, but git makes it so easy that it became my default process whenever I can use git for development, even on solo projects): Suppose you have a team of 3 or more people and a central git server that can be used for facility of share (company server, github, bitbucket, gitorious...): each person start working on a issue (let it be a bug to fix or a new feature to implement) by doing on his working copy git checkout -b feature-nickname than it change anything that he consider relevant, committing whenever he decides that a change can be described in a sensible way: git commit -am 'OptimizingVisitor applies DeMorgan laws' ... a few work after... git commit -am 'OptimizingVisitor detects constants predicates' At any time, each developer can push the changes to the central server, to share his progresses and without the pain to merge them until the full issue has been addressed. The next day, a different developer could continue his work if it's really required (rarely, but it happened). When the feature has been fully implemented, the dev can merge it into the shared branch (master, or development when a human-driven test process is required before the production deployment). We do not use rebase: we want to keep track of which code the dev was seeing while writing his changes. At any time, we can see what features have been released, looking at which branches have been merged in the shared branch. On medium to large projects (5 to 20 people) this process allows a fast, painless collaboration. Still, whenever I can use git, I use it for my solo projects too, and I find it quite good to keep track of the progress of the project. My two cents. Giacomo 2015-03-28 15:00 GMT+01:00 Paul Lalonde paul.a.lalo...@gmail.com: I'd like to hear it too - much to learn from others' process. Paul On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth charles.fors...@gmail.com wrote: On 19 March 2015 at 18:26, arn...@skeeve.com wrote: Charles Forsyth charles.fors...@gmail.com wrote: On 19 March 2015 at 16:09, arn...@skeeve.com wrote: There is definitely some learning curve and mindset change Just what I want from a little servant that's supposed to help me manage some file changes. Git is intended for something completely different than RCS. I really, REALLY, don't want to start a flame war, although this being 9fans, it's probably not possible. More's the pity. And again, I AM NOT trying to proselytize. But, if you are curious as to what value I personally found in git for gawk development, I will be happy to discuss it in personal email. Unfortunately, switching between different devices I missed this reply. I wasn't really comparing it to RCS although I can see that was a reasonable conclusion from my wording. It might be worthwhile sending a brief description of what you use and what you find valuable to the list. There isn't much traffic at the moment.
Re: [9fans] using git
Actually, Jeff I appreciate a lot your work on mercurial. I know I could use the bookmarks extension to achieve a similar process with hg (never tried darcs and bzr seriously, sorry). but I still prefer git to mercurial, since it has been designed around the features that I like (when working alone) or need (when working in large team over years long projects). But this is personal taste, and I'm not a git evangelist. I just replied to Charles asking for the features we use in git. Btw, ever heard of http://libgit2.org ? Plain c89. No external dependencies. In theory, one could implement a native gitfs over that, in C, using the network fs available in Plan9. Compared to hgfs, a bit more design of the fs structure would probably be needed to capture the concept of branch in a hierarchical filesystem. How much you would estimate such development? Giacomo 2015-03-30 18:16 GMT+02:00 Jeff Sickel j...@corpus-callosum.com: On Mar 30, 2015, at 4:55 AM, Giacomo Tesio giac...@tesio.it wrote: Ah, a small addendum: obviously we also use tags a lot to give a specific commit (and related history) a name. This is done automatically by build servers for the official tags, and manually by developers whenever they want in their own repository (often with tags like, workedhere, shittorefactortomorrow and so on). All of those features are available in hg, darcs, and other dscm tools. But to get back on topic, unless I’ve overlooked a contrib package somewhere, how about we begin with the requirements to get a fully working git installed on Plan 9. For example, ## the dependencies required for git on a bare-bones FreeBSD install: # pkg install git Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 18 packages will be affected (of 0 checked): New packages to be INSTALLED: git: 2.3.4 expat: 2.1.0_2 p5-Authen-SASL: 2.16_1 p5-GSSAPI: 0.28_1 perl5: 5.18.4_11 p5-Digest-HMAC: 1.03_1 p5-Net-SMTP-SSL: 1.01_3 p5-IO-Socket-SSL: 2.012 p5-Mozilla-CA: 20141217 p5-Net-SSLeay: 1.68 p5-Socket: 2.018 p5-IO-Socket-IP: 0.37 python27: 2.7.9 libffi: 3.2.1 p5-Error: 0.17023 curl: 7.41.0 ca_root_nss: 3.18 cvsps: 2.1_1 I’m not sure what cvsps is for, that seems to have cropped up on the fbsd pkg sometime between git versions 2.3.1 and 2.3.4. It’s been years^wdecades since I’ve tinkered with perl, and I’m fairly certain the perl 5.8 version available on Plan 9 won’t support the modules included in the above list. So Plan 9 needs a modern perl to run git effectively with specific attention to the additional modules. Expat is the “eXpat XML parser library”. Libffi is something maintained on sources.redhat.com. Many of those modules depend on OpenSSL, so add that to the list. It’s also possible a recent port of bash will also be required as the git support scripts may not work with our ape/sh or ape/psh. We’ve got python 2.7.8 [.9 soon] covered. Piece of cake, all that should fit on a coaster. -jas
Re: [9fans] jas' cpython
Thanks David! 2015-03-25 12:12 GMT+01:00 David du Colombier 0in...@gmail.com: How should I extract files from an .arch archive? disk/mkext -d / cpython-src.arch -- David du Colombier
[9fans] jas' cpython
I feel a bit dumb, but I can't grasp how to extracts file from http://plan9.bell-labs.com/sources/contrib/jas/cpython-src.arch.bz2 and http://plan9.bell-labs.com/sources/contrib/jas/hg-src.arch.bz2 tar(1), gzip(1) and ar(1) did not helped. How should I extract files from an .arch archive? Giacomo
Re: [9fans] Very old bug in db(1)
I could be wrong, but looks like nobody cares about such small fixes. A few days ago, I've found some very old small errors (one in the 2c(1) man page and one in col(1) that affects man pages' visualization in variable width fonts) but had no feedback. I guess that the most effective way to cope with such old and small bugs, is to report them on 9fans (and other related mailing lists), possibly with a patch. This way, any other user that hit the bug (and find your email) can apply the patch and fix them in his $home/bin (or somewhere else) and then bind -b it to /bin. Giacomo 2015-03-19 7:41 GMT+01:00 Roberto E. Vargas Caballero k...@shike2.com: I was doing some experiments with db(1), when I tried something like: main:b *argv/X and it gave me an error. I debugged it and I found that is a bug in the code due to a mix between char* and Rune*. I have created a patch in sources with the name unicode-db. The funny thing is this error must be at least 20 years old, because clearly its origin is the unicode translation of old unix tools. I have checked labs, 9front and plan9port and all of them have the error (in some moment someone realized about a warning of the compiler about different pointer types and simply put a cast, that is not present in the code of plan9port). I send this mail here, first because I think is the error is funy, second because is my first patch send to plan9 and I'm not sure about the process, and third because it affects to all the versions of plan9 and I'm not sure if all of them take this bug fixes from sources. Regards,
Re: [9fans] Very old bug in db(1)
Oh, I completely missed patch(1). And actually it was just when one should look up for at first... man pages. Sorry. Thanks for the tip! It's a fragmented small community and that is just sad. It is not likely that things will get better in the foreseeable future, so pick your side :-) To pick a side, one should knows the contenders enough. :-) It's very hard to find clear statements about the differences between the various plan9 flavours, or clear descriptions of the vision driving the development of each fork (at least I wasn't able to find them). This is particularly true for plan9 forks that bet on Plan9 evolution outside bell labs (9atom and 9front), while it's easy to get the differences between 9legacy, Inferno, Nix-os etc... More than 15 years ago, when I started using linux, it was easy to see how Debian was different from RedHat or Suse. In the Plan9 ecosystem, while looks that some are quite upsets about such differences, it's hard to grasp them from the outside. Giacomo
Re: [9fans] 2c(2) error
Ehm... obviously I was talking about 2c(1)... Too much coffe, today... :-D 2015-03-10 16:53 GMT+01:00 Giacomo Tesio giac...@tesio.it: 2c(2) states: Array initializers can specify the indices of the array in square brackets, as int a[] = { [3] 1, [10] 5 }; which initializes the third and tenth elements of the eleven-element array a. This is somewhat confusing: the third and the tenth element should have index 2 and 9. Moreover if the tenth element is actually referred by index 10, why the array should hold eleven elements? A simple check shows that actually the array has 11 elements and the one initialized are the forth and the eleventh. Giacomo
[9fans] 2c(2) error
2c(2) states: Array initializers can specify the indices of the array in square brackets, as int a[] = { [3] 1, [10] 5 }; which initializes the third and tenth elements of the eleven-element array a. This is somewhat confusing: the third and the tenth element should have index 2 and 9. Moreover if the tenth element is actually referred by index 10, why the array should hold eleven elements? A simple check shows that actually the array has 11 elements and the one initialized are the forth and the eleventh. Giacomo diff -r 51285ae4f545 sys/man/1/2c --- a/sys/man/1/2c Thu Mar 05 10:17:23 2015 +0100 +++ b/sys/man/1/2c Tue Mar 10 16:52:03 2015 +0100 @@ -250,7 +250,7 @@ .EX int a[] = { [3] 1, [10] 5 }; .EE -which initializes the third and tenth elements of the eleven-element array +which initializes the forth and eleventh elements of the eleven-element array .BR a . .TP \-
[9fans] col.c: one line fix for variable-width font
I gave a look at col.c and found a better fix for the tabs issue. We simply need that col check for the previous char being a space, before adding any tab. That is, at /sys/src/cmd/col.c:251 replace if ((++ncp 7) == 0 !xflag) { with if ((++ncp 7) == 0 !xflag *(p-2) == ' ') { This is a better fix that redefining col in /rc/bin/man since this way col correctly replace spaces with tabs when appropriate. It just stops to replace single spaces at positions multiple of 8 with tabs. Giacomo PS: col.c ignores $tabstop. This could be something to add in the man page. Or to fix in col.c (a really trivial fix, btw)
Re: [9fans] col.c: one line fix for variable-width font
Actually I'm using drawterm, as a sort of remote desktop connection. But I can't see the problem you are talking about. The clients (either windows or linux) don't have the font installed, but still it seem working pretty well (except for the spacing issues in man pages). I don't have a real monitor attached to the xen server, so I can't try it without drawterm. col.c just ignores $tabstop in it's source code. It use a Tabstop = 8 constant instead (and a 7 value to check for position). Changing the code to use $tabstop is trivial, and I even tried it, but it neither fixed the initial problem nor decreased the man output size enough to justify it's proposal. I'm going to write a sed script to remove the leading margin (but not every space or tab at the beginning of each line) from nroff output so that (with my font and my 14inches monitor) I can use a 3 column acme to browse /sys/src/ read the code browse man pages. This should also reduce the man output size more than col. Giacomo 2015-03-06 17:33 GMT+01:00 erik quanstrom quans...@quanstro.net: On Fri Mar 6 04:57:18 PST 2015, giac...@tesio.it wrote: if ((++ncp 7) == 0 !xflag) { with if ((++ncp 7) == 0 !xflag *(p-2) == ' ') { that solves it. you have a problem with $tabstop. if you've cpu'd or ssh'd somewhere, make sure the $tabstop is set properly, and that the font you are using is available on the remote host, and $font is pointing to it. - erik
Re: [9fans] col.c: one line fix for variable-width font
ehm... well... actually I could try with vnc... :-) Giacomo 2015-03-06 18:22 GMT+01:00 Giacomo Tesio giac...@tesio.it: Actually I'm using drawterm, as a sort of remote desktop connection. But I can't see the problem you are talking about. The clients (either windows or linux) don't have the font installed, but still it seem working pretty well (except for the spacing issues in man pages). I don't have a real monitor attached to the xen server, so I can't try it without drawterm. col.c just ignores $tabstop in it's source code. It use a Tabstop = 8 constant instead (and a 7 value to check for position). Changing the code to use $tabstop is trivial, and I even tried it, but it neither fixed the initial problem nor decreased the man output size enough to justify it's proposal. I'm going to write a sed script to remove the leading margin (but not every space or tab at the beginning of each line) from nroff output so that (with my font and my 14inches monitor) I can use a 3 column acme to browse /sys/src/ read the code browse man pages. This should also reduce the man output size more than col. Giacomo 2015-03-06 17:33 GMT+01:00 erik quanstrom quans...@quanstro.net: On Fri Mar 6 04:57:18 PST 2015, giac...@tesio.it wrote: if ((++ncp 7) == 0 !xflag) { with if ((++ncp 7) == 0 !xflag *(p-2) == ' ') { that solves it. you have a problem with $tabstop. if you've cpu'd or ssh'd somewhere, make sure the $tabstop is set properly, and that the font you are using is available on the remote host, and $font is pointing to it. - erik
Re: [9fans] unexpected tabs in man pages after font change
Which font are you using? With all mono-spaced (fixed-width) fonts everything works fine. The problem occurs just with variable spaced fonts. Btw I noted that the fix is not perfect: the table at the end of man(1) is misaligned, with or without the fix. Even without calling col at all. This could be due to troff assuming fixed with font and inserting spaces instead of tabs. And its a pity, because probably libframe would align tabs properly. But this is just a guess, I had no time to check the troff code for this second issue. Giacomo Il 05/Mar/2015 15:23 erik quanstrom quans...@quanstro.net ha scritto: Interestingly enough the problem disappears with a mono font. I suspect that troff is inserting such tabs instead of spaces when it thinks they are the same. Indeed libframe (as far I could understand from the manual and the sources) properly handles such variable width fonts. Looks like I've to inform troff about the glyphs sizes... but how? i don't use a mono font so i don't like your col -x solution, and this works for me regardless. if $font is set correctly, i believe all this should work out. make sure that $tabstop=acme tabstop as well. the default for acme is 4, but it is imported by $tabstop, and overridden with Tab. cpu'ing can screw with your $font. - erik
[9fans] unexpected tabs in man pages after font change
Hi, I've just installed a compact sans font (from http://input.fontbureau.com/ ) and manual pages started to look broken. As you can see in the screenshot (man 2 control), there are white spaces that looks like tabs in the middle of the text with apparently no reason. Even in the troff source (why the hell we still use troff for manual pages? :-D) I can see no command that explain this behaviour. Any tip to fix them? Giacomo [image: Immagine in linea 1]
Re: [9fans] unexpected tabs in man pages after font change
Interestingly enough the problem disappears with a mono font. I suspect that troff is inserting such tabs instead of spaces when it thinks they are the same. Indeed libframe (as far I could understand from the manual and the sources) properly handles such variable width fonts. Looks like I've to inform troff about the glyphs sizes... but how? Giacomo 2015-03-04 17:13 GMT+01:00 Giacomo Tesio giac...@tesio.it: Hi, I've just installed a compact sans font (from http://input.fontbureau.com/ ) and manual pages started to look broken. As you can see in the screenshot (man 2 control), there are white spaces that looks like tabs in the middle of the text with apparently no reason. Even in the troff source (why the hell we still use troff for manual pages? :-D) I can see no command that explain this behaviour. Any tip to fix them? Giacomo [image: Immagine in linea 1]
Re: [9fans] unexpected tabs in man pages after font change
Well... docx, obviously! :-D Seriously, a markdown/asciidoc like language would be far easier to write and update. We could even compile it to troff, we we had to print it. However, this is not a rant specific to plan9. Linux is not better from this point of view. Giacomo 2015-03-04 22:31 GMT+01:00 Aram Hăvărneanu ara...@mgk.ro: On Wed, Mar 4, 2015 at 5:13 PM, Giacomo Tesio giac...@tesio.it wrote: why the hell we still use troff for manual pages? What do you propose we use instead? -- Aram Hăvărneanu