Re: [9fans] equality sign in Rc
Il 16 Maggio 2017 19:11:33 CEST, Kurt H Maier 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] Git/fs: Possibly Usable
the next commit. > walk: `du`, but for git status. > > >Supported 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] 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] Plan 9 on Xen 3.0
> virtualization is fine. But my recommendation is that you use lguest > or kvm -- not xen. Xen is painful to set up and run. > > ron Any problem with intel x86_64? I knew lguest could guest linux only! Giacomo
[9fans] Plan 9 on Microsoft Virtual PC
Hello 9fans! I've tried to install Plan 9 on a 64 bit Windows 7 using Virtual PC, since I've read that a related bug was fixed and noone tried it. Actually, after the fourth tentative (after creating a fossil partition a bit smaller than the fixed size hd) I got rc starting by logging with the glenda user. BUT, after the rio start I got the attached error. I'll use QEMU as I read it should work, but I hope this feedback could help. Giacomo <>
Re: [9fans] Plan 9 on Microsoft Virtual PC
I've tried again and it worked by using a dynamically sized hd of 3 GB ad using a 2 GB fossil partition starting at cylinder 1 Don't ask me why it worked for a while (some minutes) and than crashed with similar messages. I suppose I've done it right, but I'm not sure. A similar procedure worked on QEMU, but it's by far slower. If you managed to get a Plan9 working Microsoft Virtual PC please tell me the procedure you used, the hd settings, the partitions and how you configured the mbr... Thanks a lot! Giacomo On Fri, Jan 29, 2010 at 4:46 PM, Patrick Kelly wrote: > > On Jan 29, 2010, at 6:44 AM, Giacomo Tesio wrote: > > Hello 9fans! >> >> I've tried to install Plan 9 on a 64 bit Windows 7 using Virtual PC, since >> I've read that a related bug was fixed and noone tried it. >> > I just announced it worked like 2 weeks ago. > > >> Actually, after the fourth tentative (after creating a fossil partition a >> bit smaller than the fixed size hd) I got rc starting by logging with the >> glenda user. >> >> BUT, after the rio start I got the attached error. >> > I never had any problems starting up Plan 9 with rio, heck I never had any > trouble at all. You sure you have everything set up right on your end? > >> >> >> I'll use QEMU as I read it should work, but I hope this feedback could >> help. >> >> >> >> Giacomo >> >> > > >
[9fans] A few questions about 9p
Hi, I'm coding a small .NET library to connect 9p2000 services and I have a few questions about things that the manual doesn't explain (or I was not able to find). What's the meaning of qids? I see that responses often include them but request messages do not. What's the proper message sequence to delete a file? And to delete a non empty directly? Is it possible to move a file between different directories atomically? I can't find details on the file execution permission: looks like a malicious client could just ignore it on files and execute anything that it can read (obviously I'm just talking about single files, not directory). When I should clunk the afid? What about encryption? Is it completely delegated to the transport layer? Thanks for your help! Giacomo
Re: [9fans] A few questions about 9p
Il 29/Gen/2015 11:12 "Charles Forsyth" ha scritto: > > > On 29 January 2015 at 09:04, Giacomo Tesio wrote: >> >> What's the meaning of qids? I see that responses often include them but request messages do not. > > see intro(5) or intro(9P) depending on system. They identify a file on a server; they are a value provided by the server to the client, > so they only appear in replies. Thanks Charles for your answer. Actually I can't imagine it's usage in the client. I mean: clients should use path to identify files, shouldn't them? >> >> What's the proper message sequence to delete a file? And to delete a non empty directly? > > You point a fid at the file, then remove it:Twalk* ... Tremove > A non-empty directory can't be removed. > Tremove implies Tclunk Ehm... I didn't saw the Tremove message.. sorry. >> >> I can't find details on the file execution permission: looks like a malicious client could just ignore it on files and execute anything that it can read (obviously I'm just talking about single files, not directory). > > It's not malicious, just incorrect. Obviously you can't execute a remote image or script unless you read it. By malicious I mean that the client could execute a script that it wasn't allowed to. Actually if we separate storage and execution, that's probably inevitable. >> >> When I should clunk the afid? > > When the client closes it. Ok but when should the client close it? Is it still valid to Tattach after the afid has been closed? How many times? I'm thinking about potential security issues allowing an attacker to attach a file server just guessing the afid provided by another user. Thanks again for your help! Giacomo
Re: [9fans] A few questions about 9p
Actually I wasn't able to understand when the afid was supposed to be clunk reading attach 5. I was in doubt that the afid had to be the last fid clunked. Giacomo Il 29/Gen/2015 15:56 ha scritto: > size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s] > size[4] Rattach tag[2] qid[13] > > you have to provide the afid in the Tattach, so clunking it before > attach makes no sense. you can pass NOFID to Tattach when when the > fileserver doesnt support authentification. > > you can also reuse the afid, so keeping it arround after Tattach > works just fine. > > if you only want todo a single attach, you can clunk it after the > Tattach. > > its all documented and better worded in attach(5). > > -- > cinap > >
[9fans] wstat and atomic directory change
Hi, I'm wondering about the validity of an interpretation of intro(5) and stat(5) that could allow a server to atomically change the directory of a file. >From intro(5) <http://man.cat-v.org/9front/5/intro> The notation string[s] (using a literal s character) is shorthand for s[2] followed by s bytes of UTF-8 text. (Systems may choose to reduce the set of legal characters to reduce syntactic problems, for example to remove slashes from name compo- nents, *but the protocol has no such restriction*. Plan 9 names may contain any printable character (that is, any character outside hexadecimal 00-1F and 80-9F) except slash.). wstat(5) <http://man.cat-v.org/9front/5/stat> on the other hand does not say much about the name field of Fcall: The name can be changed by anyone with write permission in the parent directory; it is an error to change the name to that of an existing file. Now, since the protocol does not restrict names (even if Plan 9 does it), I'm wondering if setting the name to a full path starting from root could be used to change atomically the directory of a file (given the write permission on both original and target directory). Obviously I'm not referring to Plan 9 file servers (I guess this would be a non retrocompatbile change), but I'm considering if such interpretation would be wrong (according to the official specifications). A server supporting such behaviour could be considered a 9p2000 conformant server? Giacomo
Re: [9fans] wstat and atomic directory change
It surely would not be conformant to Plan 9 systems, but to the protocol? As far as I can read intro(5), it explicitly excludes slash as a valid character for the Plan 9 OS, but it also explicitly states that "the protocol has no such restriction". Be patient: I'm asking because this could be a typo in the intro(5) man page, or in my understanding of its phrasing. Still, using this protocol "feature" to enable atomic directory change could be useful in my use cases, but I don't want to build yet another 9p2000 extension. Giacomo 2015-01-30 15:13 GMT+01:00 erik quanstrom : > > Now, since the protocol does not restrict names (even if Plan 9 does it), > > I'm wondering if setting the name to a full path starting from root could > > be used to change atomically the directory of a file (given the write > > permission on both original and target directory). > > > > Obviously I'm not referring to Plan 9 file servers (I guess this would > be a > > non retrocompatbile change), but I'm considering if such interpretation > > would be wrong (according to the official specifications). > > > > A server supporting such behaviour could be considered a 9p2000 > conformant > > server? > > it would not be conformant. the intro explicitly excludes slash as a > valid character. > (unlike a dns zone.) and its more detailed explinations are meant to hold > for the > entire section. > > but you could still do it, as long as the file servers were the same. > > - erik > >
Re: [9fans] wstat and atomic directory change
Ok, got it. This annoing thread (sorry) was due to the fact that the only messages that actually contains the "/" marker are Tauth and Tattach (in the aname). I still think that using wstat with such marker to atomically move files among accessible folders would not violate the protocol specification, but actually it would break existing servers and that's is probably enough to define it as an extension to the protocol (say 9P2000.a) so that clients can know if the server supports this semantic or not. However, as I previously said, I don't think that the world need a new 9p variant :-D Now, what's the proper 9p way that a client could use to tell a syntetic server to atomically move a syntetic file between syntetic folders? I bet that the answer is a control file receiving rc like commands (or any other custom, human readable protocol). Would it be correct? Something like this: Given mountpoint/ + first/ + moveme.txt + second/ + atomically Doing echo mv /first/moveme.txt /second/ > mountpoint/atomically We optain either the following or a Rerror: mountpoint/ + first/ + second/ + moveme.txt + atomically Is it the proper way to achieve such kind of operations? Thanks for your patience... :-) Giacomo 2015-01-30 23:49 GMT+01:00 Anthony Sorace : > > > On Jan 30, 2015, at 10:59 , Giacomo Tesio wrote: > > > > It surely would not be conformant to Plan 9 systems, but to the protocol? > > No. Joel has it right. Writing a server which allows / in names would mean > that the "/" you're slipping into a name wouldn't always be a directory > indicator or name separator. Think of it as the protocol accommodating > systems which use some other marker. > > The relevant point is that the "name" in question (which, as you noticed, > the protocol allows to contain / even though plan9 doesn't) is the name > *within a directory*, not a full path name. walk(5) probably gives the best > explanation of this, or perhaps the discussion of create in open(5). > > >
[9fans] 9p2000 agent supporting multiple clients on a single connection
While reading intro(5) I noticed these very interesting lines: Fids are chosen by the client. All requests on a connection share the same fid space; when several clients share a connection, the agent managing the sharing must arrange that no two clients choose the same fid. And later: A client can send multiple T-messages without waiting for the corresponding R-messages, but all outstanding T-messages must specify different tags. The server may delay the response to a request and respond to later ones; this is sometimes necessary, for example when the client reads from a file that the server synthesizes from external events such as keyboard characters. This is a very interesting feature, allowing a sort of proxing at connection level. Such a proxy could accept 9P connections on a socket and forward them to a remote server (after modifying fids and tags so that they are kept unique), largely improving scalability. If available, I'd really like to read such code. BTW, is there any client library that actually enables consumers to send multiple T-messages without waiting the corresponding R-messages and then consume responses when they arrive? All the 9p implementations that I saw were synchronous, allowing only one client per connection. Where can I find an implementation of these features? I guess it would be a really instructive read. Giacomo
Re: [9fans] wstat and atomic directory change
2015-02-04 4:51 GMT+01:00 erik quanstrom : > On Tue Feb 3 01:01:02 PST 2015, st...@quintile.net wrote: > > > the control file idea is a neat way of doing atomic moves. > > > > control files are a good way of dealing with all kinds of exceptional > behavior. > > but ... > > to be fair, this goes against the unix ideal of having uniform file > operations. > You are right. But since protocol customizations goes against that same ideal, what's the plan9 way of dealing with a feature X (in this specific case atomic file moves)? > this requires delving into the namespace to tell that the directories are > still under the > same mount, and some non-uniform operations. > Good point. But thus, what are the alternatives? Giacomo
Re: [9fans] wstat and atomic directory change
And unfortunately I cannot figure out any alternative, either. :-( An interesting point is: why directory entries can be read but cannot be written? I mean we use Tcreate to create a new file in a dir, while to be uniform with files, we should use a Twrite, appending a corresponding stat structure at the end of a directory entry. However this solution probably has not been adopted to enable safe concurrency in the file creation and removal. However this asymmetry shows that directories cannot be (pratically) handled in the same way of files. Giacomo 2015-02-04 15:06 GMT+01:00 erik quanstrom : > > You are right. > > But since protocol customizations goes against that same ideal, what's > the > > plan9 way of dealing with a feature X (in this specific case atomic file > > moves)? > > > > > > > this requires delving into the namespace to tell that the directories > are > > > still under the > > > same mount, and some non-uniform operations. > > > > > > > Good point. But thus, what are the alternatives? > > i wasn't holding out. i don't have any suggestions. > > - erik > >
Re: [9fans] wstat and atomic directory change
Useless? No I did not mean this. (and sorry, I wasn't in any way sarcastic, I'm just trying to understand 9p's design a bit deeper) I mean that to realize a truly uniform interface, directories should be writable with Twrite, so that we would not need messages like Tcreate and Tremove (and possibly Twstat) and Tstat would just be an efficient shortcut (like it actually already is, since we can obtain the same info reading the parent directory). We could add a file by appending a stat entry to the parent directory and we could remove it by removing such entry. We could modify permissions, names and so on overwriting the entry. The problem would be: how to do such basic operations atomically and concurrently? That's why (I suppose) we have Tcreate, Tremove and Twstat. For praticality. But why we don't have Tmove for example? Probably the answer is in the distributed nature of Plan 9: as you said, namespaces would be at odds with such a message, complicating the library functions. However having to read and write a 10 GB file one msize after the other just to change its directory looks a bit costly, if both the origin and the destinations are in the same phisical disk. Moreover (if I've understood properly the protocol) to move a 10 GB file between two directories on a disk, you should have 10 GB free on that disk! All this reflections arise from the search for an orthodox way to change the tree structure of a synthetic filesystem. Moving large real files is not my actual issue here. I'm wondering for a synthetic filesystem in which, when you move a folder in a special directory, something magic happens. As far as I can see, it is not possible with a 9p2000 fileservice, is it? Giacomo 2015-02-04 20:23 GMT+01:00 erik quanstrom : > > you can consider doing it out of band; e.g. a new fossil console command. > > On Wed, Feb 4, 2015 at 6:30 AM Giacomo Tesio wrote: > > > > > And unfortunately I cannot figure out any alternative, either. :-( > > > > > > An interesting point is: why directory entries can be read but cannot > be > > > written? I mean we use Tcreate to create a new file in a dir, while to > be > > > uniform with files, we should use a Twrite, appending a corresponding > stat > > > structure at the end of a directory entry. > > > > > > However this solution probably has not been adopted to enable safe > > > concurrency in the file creation and removal. > > > > > > However this asymmetry shows that directories cannot be (pratically) > > > handled in the same way of files. > > right. directories are not the same as files. you're right that reading a > directory is useless. > > - erik > >
Re: [9fans] wstat and atomic directory change
2015-02-05 5:26 GMT+01:00 : > > But why we don't have Tmove for example? > > http://9front.org/img/tmove.jpg > > ROFTL! :-D
Re: [9fans] wstat and atomic directory change
2015-02-05 5:13 GMT+01:00 : > > > But why we don't have Tmove for example? > > Because its semantics are much, much more complex and the users need > to be aware of the difference. This shouldn't be so hard to obtain. I mean we could simply introduce a new command "rename oldpath newpath" that only works when both path share the same mount point. This way the mv commands would keep the old "safe" semantic, while the new command would protect the user to accidentally disclosure his data to the world via the cloud. > Imagine a Tmove that transfers your > entire disk contents to the cloud: would you like it to be perceived > as trivial? What happens if you interrupt it? Worse, what happens if > you can't interrupt it? I won't be drammatic: you can always unplug the enthernet! :-D Btw, I see the point. Giacomo
Re: [9fans] wstat and atomic directory change
Actually I've found a 9 years old mail about Tmove: http://comp.os.plan9.narkive.com/xYi8Vg5d/9fans-fuse-bashing#post40 I'm not an advocate of Tmove in any way, but I can't really grasp the cons. I'm sure that its omission was an explicit design choise, but where I can read about the arguments that lead to such decision? Giacomo 2015-02-05 9:21 GMT+01:00 Giacomo Tesio : > 2015-02-05 5:13 GMT+01:00 : >> >> > But why we don't have Tmove for example? >> >> Because its semantics are much, much more complex and the users need >> to be aware of the difference. > > This shouldn't be so hard to obtain. > > I mean we could simply introduce a new command "rename oldpath > newpath" that only works when both path share the same mount point. > This way the mv commands would keep the old "safe" semantic, while the > new command would protect the user to accidentally disclosure his data > to the world via the cloud. > >> Imagine a Tmove that transfers your >> entire disk contents to the cloud: would you like it to be perceived >> as trivial? What happens if you interrupt it? Worse, what happens if >> you can't interrupt it? > > I won't be drammatic: you can always unplug the enthernet! :-D > > Btw, I see the point. > > > Giacomo
Re: [9fans] wstat and atomic directory change
Il 05/Feb/2015 17:26 "erik quanstrom" ha scritto: > > I'm wondering for a > > synthetic filesystem in which, when you move a folder in a special > > directory, something magic happens. > > As far as I can see, it is not possible with a 9p2000 fileservice, is it? > > i don't see why you can't make a magic directory that works that way. > How? Which 9p message would trigger the magic? I just see 2 options: 1. Have a control file 2. Use custom wstat with full path to move But if both are wrong, I'm lost. Giacomo
[9fans] telnet to port (and webfs debug)
Hi, I'm having an hard time to debug a problem with http clients in plan9/qemu (actually 9front, but I guess my questions apply to all plan9 versions). DNS and ping works properly, just http fails. I suspect it's a proxy issue. I have set httpproxy environment variable but with no success: both hget and mothra doesn't works. I can connect to the qemu host webserver on port 80 and receive the proper page, but for any other address I can't obtain a response. The proxy does not log any access. Now, to debug this issue, I'd like to telnet the proxy port and manually forge an http request. However I can't understand hot to specify a port reading man telnet. What's plan9 equivalent of telnet www.google.com 80 Giacomo
Re: [9fans] telnet to port (and webfs debug)
Yes hget is an rc script running on webfs. Giacomo Il 12/Feb/2015 13:14 "Quintile" ha scritto: > I have s feeling that get is a script that accesses webfs, and maybe the > 9front mothers does the same. are you running webfs? > > -Steve > > > > > > > On 12 Feb 2015, at 11:02, Giacomo Tesio wrote: > > > > Hi, I'm having an hard time to debug a problem with http clients in > > plan9/qemu (actually 9front, but I guess my questions apply to all > > plan9 versions). > > > > DNS and ping works properly, just http fails. > > > > I suspect it's a proxy issue. I have set httpproxy environment > > variable but with no success: both hget and mothra doesn't works. > > > > I can connect to the qemu host webserver on port 80 and receive the > > proper page, but for any other address I can't obtain a response. > > > > The proxy does not log any access. > > > > Now, to debug this issue, I'd like to telnet the proxy port and > > manually forge an http request. > > > > However I can't understand hot to specify a port reading man telnet. > > > > What's plan9 equivalent of > > > > telnet www.google.com 80 > > > > > > > > Giacomo > >
Re: [9fans] telnet to port (and webfs debug)
I did already tried this, but without success, but I tried it again
just to be sure, still without success.
I tried to telnet the proxy with telnet tcp!host!port and it worked as
expected ("GET http://www.google.com"; printed its bloated html).
This limit the issue boundaries to webfs (since, as far as I can see,
hget is "just" a wrapper of it), since both squid and the tcp stack
proved to work properly.
The problem is, I can't figure out how to debug webfs. Any tip?
Note that it worked once, a few days ago, when I managed to sysupdate
(setting http_proxy.host in /usr/glenda/.hgrc).
Giacomo
2015-02-12 17:27 GMT+01:00 :
> the httpproxy variable is read by webfs on startup only. webfs is usually
> started in your $home/lib/profile to provide http client service.
>
> just setting httpproxy before running hget or mothra has no
> effect on the proxy setting unless you start a new webfs instance.
>
> so try:
>
> httpproxy=http://proxy:port
> webfs
> hget http://www.google.com/
>
> when that works, set the httpproxy variable at the top of your
> $home/lib/profile before webfs is started to make it permanent.
>
> --
> cinap
>
Re: [9fans] telnet to port (and webfs debug)
Ok fixed. The problem was plain stupid: I did not prepended "http://"; to httpproxy, setting it to just proxy:port. However, I noted that webfs -d option is not documented. Nor is the need to prepend http:// to httpproxy (I suppose however that this could be taken as default). Whenever I'll find my way to acme and plan9 I'll send you a patch... Thanks you all for your help! Giacomo 2015-02-13 10:11 GMT+01:00 : > heres how it should look like (tuttle.9hal: is my proxy servr): > > term% httpproxy=http://tuttle.9hal: webfs -d; hget http://google.com > clientctl: url http://google.com > http(0): GET http://google.com/ > hdial [1] tcp!tuttle.9hal! > -> GET http://google.com/ HTTP/1.1 > Host: google.com > User-Agent: Mozilla/5.0 (compatible; hjdicks) > Connection: keep-alive > Referer: http://google.com/ > Accept: */* > > <- HTTP/1.1 302 Found > > -- > cinap >
Re: [9fans] telnet to port (and webfs debug))
For future reference: hg (and thus sysupdate) simply ignores $httpproxy variable, it honors $http_proxy instead. Thus if you are using plan9 behind a proxy you need to set term% httpproxy=http://proxy.hostname:port # (don't forget "http://";!) term% http_proxy=proxy.hostname:port Once it works, you can add it at the beginning of your lib/profile. Note that, strangely enough, hg ignores the .hgrc in your home directory. The hgrc(8) speak about Unix (and Windows) but since GNU is Not U... ehm... Plan9 is not Unix (:-D), I can't say where to write it. Giacomo 2015-02-13 10:59 GMT+01:00 Giacomo Tesio : > Ok fixed. The problem was plain stupid: I did not prepended "http://"; > to httpproxy, setting it to just proxy:port. > > However, I noted that webfs -d option is not documented. Nor is the > need to prepend http:// to httpproxy (I suppose however that this > could be taken as default). > Whenever I'll find my way to acme and plan9 I'll send you a patch... > > > Thanks you all for your help! > > > Giacomo > > > 2015-02-13 10:11 GMT+01:00 : >> heres how it should look like (tuttle.9hal: is my proxy servr): >> >> term% httpproxy=http://tuttle.9hal: webfs -d; hget http://google.com >> clientctl: url http://google.com >> http(0): GET http://google.com/ >> hdial [1] tcp!tuttle.9hal! >> -> GET http://google.com/ HTTP/1.1 >> Host: google.com >> User-Agent: Mozilla/5.0 (compatible; hjdicks) >> Connection: keep-alive >> Referer: http://google.com/ >> Accept: */* >> >> <- HTTP/1.1 302 Found >> >> -- >> cinap >>
[9fans] pkg(1) and tbz2
Hi, with the hope to port a (complex) tool to plan9 I've found this interesting repo with an updated ape + gcc + some other useful tools... http://marcus.biz.tm/files/ I tried to set the pkgpath to that url but pkg/list only show the two packages named ".tbz2" (lighthttp and m4). I noted that all files in http://9front.org/pkg/386/ are tbz. I'd like to know if (and how) I could install the tar.gz and tar.bz2 packages from that repo or I have to manually download them, repackage as with pkg/create and then install from a local pkgpath. Thanks for your help! Giacomo
Re: [9fans] pkg(1) and tbz2
So have I any hope to compile them? Giacomo 2015-02-19 12:24 GMT+01:00 Álvaro Jurado : > I don't think it can work with pkg. > Note that it isn't a "repo" and has only 72 KB/s max uploading rate. So it > means that will be very slow and > none of that packages was set to work with pkg tool. In most cases they are > only sources. > And I think gcc bootstrap will be more complicated that a simple pkg/create. > > Álvaro Jurado Cuevas > > 2015-02-19 12:01 GMT+01:00 Giacomo Tesio : >> >> Hi, with the hope to port a (complex) tool to plan9 I've found this >> interesting repo with an updated ape + gcc + some other useful >> tools... >> >> http://marcus.biz.tm/files/ >> >> I tried to set the pkgpath to that url but pkg/list only show the two >> packages named ".tbz2" (lighthttp and m4). >> >> I noted that all files in http://9front.org/pkg/386/ are tbz. >> >> I'd like to know if (and how) I could install the tar.gz and tar.bz2 >> packages from that repo or I have to manually download them, repackage >> as with pkg/create and then install from a local pkgpath. >> >> >> Thanks for your help! >> >> >> Giacomo >> >
Re: [9fans] pkg(1) and tbz2
Ops. Sorry I thought I was writing to 9front. Thanks for your help! Giacomo Il 19/Feb/2015 12:49 "Álvaro Jurado" ha scritto: > First, you need a gcc to compile gcc. There is a complete set here > <https://drive.google.com/folderview?id=0B6YNt0aHfaA0am1oNGNSR3pXU1U&usp=sharing#list> > (get > more recent), and a clue about configures here > <http://marcus.biz.tm/files/configure.txt>. > But I'm sure that 9fans list don't want any noise about this. So ask there > where you found that soft. > > > Álvaro Jurado Cuevas > colmenar.biz.tm > > 2015-02-19 12:30 GMT+01:00 Giacomo Tesio : > >> So have I any hope to compile them? >> >> Giacomo >> >> 2015-02-19 12:24 GMT+01:00 Álvaro Jurado : >> > I don't think it can work with pkg. >> > Note that it isn't a "repo" and has only 72 KB/s max uploading rate. So >> it >> > means that will be very slow and >> > none of that packages was set to work with pkg tool. In most cases they >> are >> > only sources. >> > And I think gcc bootstrap will be more complicated that a simple >> pkg/create. >> > >> > Álvaro Jurado Cuevas >> > >> > 2015-02-19 12:01 GMT+01:00 Giacomo Tesio : >> >> >> >> Hi, with the hope to port a (complex) tool to plan9 I've found this >> >> interesting repo with an updated ape + gcc + some other useful >> >> tools... >> >> >> >> http://marcus.biz.tm/files/ >> >> >> >> I tried to set the pkgpath to that url but pkg/list only show the two >> >> packages named ".tbz2" (lighthttp and m4). >> >> >> >> I noted that all files in http://9front.org/pkg/386/ are tbz. >> >> >> >> I'd like to know if (and how) I could install the tar.gz and tar.bz2 >> >> packages from that repo or I have to manually download them, repackage >> >> as with pkg/create and then install from a local pkgpath. >> >> >> >> >> >> Thanks for your help! >> >> >> >> >> >> Giacomo >> >> >> > >> >> >
[9fans] rc: pwd in $prompt
Hi, I'm a bit dumb, but reading rc(1) I can't grasp how I can have the current dir printed in prompt. Is it possible at all? Giacomo
Re: [9fans] rc: pwd in $prompt
Ops... Thanks! :-) Giacomo 2015-02-26 11:08 GMT+01:00 Álvaro Jurado : > http://www.plan9.bell-labs.com/wiki/plan9/Tip_o%27_the_day/index.html > > "To set your prompt in rc to reflect your current directory add this to your > profile" part. > > Álvaro Jurado Cuevas > colmenar.biz.tm > > 2015-02-26 10:59 GMT+01:00 Giacomo Tesio : >> >> Hi, I'm a bit dumb, but reading rc(1) I can't grasp how I can have the >> current dir printed in prompt. >> >> Is it possible at all? >> >> >> Giacomo >> >
[9fans] drawterm sources
Hi, to ease my usage of drawterm from my hp chromebook I'm using xbindkeys + xdotool to send mouse events on a few keyboard's events. In particular AltGr + Left = mouse 1 AltGr + Up = mouse 2 AltGr + Right = mouse 3 This way I can choord even without a 3 button mouse. This works quite well, but I had to disable X autorepeat with `xset -r` before starting drawterm but it's quite annoing out of drawterm. So I'm going to use xdotool behaviours to disable autorepeat when the mouse enter drawterm and enable it again when it leaves. However a better approach (for my usecase) would be to have drawterm ignoring autorepeated events just for these key combinations. So I'm wondering how hard is to hack drawterm. Here my questions: - where I can find the most updated sources of drawterm? (links from http://swtch.com/drawterm/ seem to be broken) - Is there any simpler solution? Buying a three-button mouse is quite hard in Italy, and above all its usage is not viable on my couch... :-) Thanks for your help! Giacomo
Re: [9fans] drawterm sources
Thanks a lot! :-D Giacomo 2015-03-02 11:55 GMT+01:00 yy : > On 2 March 2015 at 11:06, Giacomo Tesio wrote: >> - where I can find the most updated sources of drawterm? (links from >> http://swtch.com/drawterm/ seem to be broken) > > https://bitbucket.org/rsc/drawterm > >> - Is there any simpler solution? Buying a three-button mouse is quite >> hard in Italy, and above all its usage is not viable on my couch... >> :-) > > I like to use the wheel for chording (patched acme in contrib). This > works well with the trackpad in my laptop too. YMMV. > > > -- > - yiyus || JGL . >
[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 : > 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 : > On Wed, Mar 4, 2015 at 5:13 PM, Giacomo Tesio wrote: >> >> why the hell we still use troff for manual pages? > > What do you propose we use instead? > > -- > Aram Hăvărneanu >
Re: [9fans] unexpected tabs in man pages after font change
Well, while a bit offtopic... what do you mean by "programmatically". And btw, programs don't write man pages... yet. Giacomo 2015-03-04 23:39 GMT+01:00 Stanley Lieber : > troff is great. easy to maintain programmatically. > > sl >
Re: [9fans] unexpected tabs in man pages after font change
2015-03-05 0:56 GMT+01:00 : > > And btw, programs don't write man pages... yet. > > Are you familiar with the conventions that power godoc? > No, but I know quite well it's predecessors (Docstrings, Javadoc etc...). They are great for API, but IMHO not every unix man page can be generated from code. They are a specialized kind of prose. What I can't undestand I why we still need troff for them. It's almost like using a teletype to chat! :-) Giacomo
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" 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] 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 :
> 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 :
> 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 :
>
>> 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] 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 :
> 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
\-
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 : > 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
[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] 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 > >
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 : > 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 > wrote: > >> >> On 19 March 2015 at 18:26, wrote: >> >>> Charles Forsyth wrote: >>> >>> > On 19 March 2015 at 16:09, 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
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 : > 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 : > >> 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, wrote: >>> >>>> Charles Forsyth wrote: >>>> >>>> > On 19 March 2015 at 16:09, 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 : > > > On Mar 30, 2015, at 4:55 AM, Giacomo Tesio 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] small VFD display
2015-06-09 20:34 GMT+02:00 Ethan Grammatikidis : > 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] 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. ;-)
[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] read9pmsg usage
2015-08-10 16:22 GMT+02:00 erik quanstrom : > on plan 9 systems 0 writes are not discarded. > Interesting! Is this "by design"? And what is the intended usage of 0 writes? BTW, so fcall(2) is misleading, a 0 read can not be used to identify an EOF, right? Giacomo
Re: [9fans] read9pmsg usage
2015-08-10 16:54 GMT+02:00 Charles Forsyth : > 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
Re: [9fans] read9pmsg usage
2015-08-11 17:48 GMT+02:00 Charles Forsyth : > > On 10 August 2015 at 15:11, Giacomo Tesio 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-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 : > 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] pthreads
2008-12-16 23:16 GMT+01:00 Steve Simon : > 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] u9fs sources
2015-09-02 6:38 GMT+02:00 : > > 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
[9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
2011-05-20 3:30 GMT+02:00 erik quanstrom : > 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)
... 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 : > 2011-05-20 3:30 GMT+02:00 erik quanstrom : > >> 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" 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] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)
2015-09-05 20:47 GMT+02:00 erik quanstrom : > > 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] off topic - a good Git reference
2015-10-12 19:00 GMT+02:00 Charles Forsyth : > > On 12 October 2015 at 17:49, Álvaro Jurado 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] Compiling ken-cc on Linux
2015-11-27 0:21 GMT+01:00 Charles Forsyth : > > On 26 November 2015 at 23:08, Ryan Gonzalez 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] Compiling ken-cc on Linux
2015-11-27 13:42 GMT+01:00 : > 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
[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
[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 : > 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 : > > On 1 February 2016 at 23:34, Giacomo Tesio 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] 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] 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
Re: [9fans] Libc locks documentation
Thanks Charles! Giacomo 2016-03-25 17:38 GMT+01:00 Charles Forsyth : > 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 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 >> > >
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 : > 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 w
Re: [9fans] The Plan 9/"right" way to do Facebook
2016-04-03 6:42 GMT+02:00 : > > 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
[9fans] create/create race
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
[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] 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 :
> > 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
>
>
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 : > 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] 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&m=111558704718797&w=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 :
>
> On 30 November 2016 at 13:32, wrote:
>
>> interesting, the thread starts here:
>>
>> http://marc.info/?l=9fans&m=111558704718788&w=2
>>
>
>
> I suspect the discussion predated 9P2000 and the introduction of the OEXCL
> option.
>
Re: [9fans] create/create race
2016-11-30 16:08 GMT+01:00 Charles Forsyth : > > On 30 November 2016 at 15:02, Giacomo Tesio 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
2016-11-30 16:40 GMT+01:00 : > this makes no sense to me. the whole point of create with OEXCL is that > it is atomic and it will *NOT* try to truncate-open the file when it > already > exist. OEXCL means just sending the Tcreate and nothing else. why is that > not > already what you try todo with your new create syscall? > > can you please state the problem that you are trying to fix? > Well, describing the whole picture would take a while (and would move the thread topic to other unusual aspects of its design), but one of the reason that can explain my question is that I want to simplify the kernel code as much as possible, moving to user space all that can be moved without affecting the system security. In the end I'd like to get few orthogonal syscalls, so that you cannot obtain the exact effect of one in term of 2 or more other. I know that this seem a bit theoretical, but it's just a starting point and has a lot of really pragmatic implications in my research project. Stated in a different way, I want to keep it simple, and user space code is usually simpler than kernel space code. Btw, actually, I'm not proposing a change to Plan 9 or debating about its design. I'm just asking about the reasoning behind this specific choice, because I guess that it's deeper than it seem (so much that I cannot grasp it by reading the code). Also I'm looking for "instances that *want* the existing effect", as Charles perfectly described them, something that break without it, so that I can dive deeper into the matter. 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 : > > On 30 November 2016 at 21:51, Charles Forsyth > 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. >
[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] A heartfelt thanks... :-)
2017-01-06 10:34 GMT+01:00 Anthony Martin : > 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
Re: [9fans] Porting Idris to 9front
2017-01-13 15:05 GMT+01:00 Joe M : > > > > 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
[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
[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
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 : > > 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] 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] 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 :
> 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 wrote:
>>
>> rc lists?
>>
>> > El 18 ene 2017, a las 17:45, Giacomo Tesio 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] 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] 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 : > On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber 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
Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)
Il 06/Mag/2017 10:22, "Francisco J Ballesteros" 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
[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] Blocking on write
Thanks Charles! Giacomo 2017-05-15 12:32 GMT+02:00 Charles Forsyth : > > On 15 May 2017 at 11:05, Giacomo Tesio 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).
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 :
> Thanks Charles!
>
>
> Giacomo
>
> 2017-05-15 12:32 GMT+02:00 Charles Forsyth :
>>
>> On 15 May 2017 at 11:05, Giacomo Tesio 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] 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] 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" ha scritto: > > On 15 May 2017 at 17:30, Giacomo Tesio wrote: > >> % echo "$--fu" >> rc: null list in concatenation >> > > wrong quotes. try echo $'--fu' > > h% --x=hello > h% echo $'--x' > hello > >
