Re: [9fans] Hosted Inferno on Raspberry Pi
Not all the Linux VT interface ioctls are supported by the video driver so a little work is needed to incorporate the framebuffer device. To run inferno in fullscreen mode, would it be feasible to mmap the framebuffer address into the inferno address space and just write to it?
Re: [9fans] Hosted Inferno on Raspberry Pi
To run inferno in fullscreen mode, would it be feasible to mmap the framebuffer address into the inferno address space and just write to it? yep, the standard fb mmap code works but just needs a little tweaking for the input event handling devices and removal of a few unimplemented ioctls
Re: [9fans] Hosted Inferno on Raspberry Pi
yep, the standard fb mmap code works I've got HDMI video working in Plan 9 too - it turned out to be fairly simple to tell the GPU to set the resolution and divulge the framebuffer address. Putting console output on video frees up the serial port for more interesting purposes ...
Re: [9fans] Hosted Inferno on Raspberry Pi
I've got HDMI video working in Plan 9 too Plan9 runs on the rasberry-PI? -Steve
Re: [9fans] Hosted Inferno on Raspberry Pi
Plan9 runs on the rasberry-PI? /n/sources/contrib/miller/9/rpi It's a work in progress - no usb yet, and therefore no keyboard, mouse or ethernet.
[9fans] a strange time stamp
Hello, 9fans. I noticed a strange time stamp in /n/9fat. term% cat /adm/timezone/local; date; touch /tmp/x; ls -l /tmp/x; 9fat:; touch /n/9fat/x; ls -l /n/9fat/x JST 32400 JST 32400 Fri Aug 3 22:55:31 JST 2012 --rw-rw M 11 arisawa web 0 Aug 3 22:55 /tmp/x --rw-rw-rw- M 95 bill trog 0 Aug 4 07:55 /n/9fat/x term% Why /n/9fat/x is Aug 4 07:55. Is is only for me? Kenji Arisawa
Re: [9fans] a strange time stamp
On Fri Aug 3 10:27:26 EDT 2012, aris...@ar.aichi-u.ac.jp wrote: Hello, 9fans. I noticed a strange time stamp in /n/9fat. term% cat /adm/timezone/local; date; touch /tmp/x; ls -l /tmp/x; 9fat:; touch /n/9fat/x; ls -l /n/9fat/x JST 32400 JST 32400 Fri Aug 3 22:55:31 JST 2012 --rw-rw M 11 arisawa web 0 Aug 3 22:55 /tmp/x --rw-rw-rw- M 95 bill trog 0 Aug 4 07:55 /n/9fat/x term% Why /n/9fat/x is Aug 4 07:55. Is is only for me? it's for everybody. dosfs is evidently saving in gmt, (incorrect) and then reading in local time (correct). this means that your tz offset gets applied twice. since i'm gmt-4, the round trip to dosfs will give gmt-8. if you're gmt+9, then the round trip would yield gmt+18, i think. - erik
Re: [9fans] Hosted Inferno on Raspberry Pi
graham.gallag...@gmail.com (Graham Gallagher) writes: The gcc flags: -march=armv6 -mfloat-abi=softfp -mfpu=vfp, will let you compile the standard Inferno emu-g on the Raspberry Pi first go. Not all the Linux VT interface ioctls are supported by the video driver so a little work is needed to incorporate the framebuffer device. I have been able to build the X11 version, which does not work with the default depth of 16 bit due to lacking 16bit-16bit bitblt code, and when you force the Pi into 32bit mode, everything is monochrome-green. ;) It works fine with X11 forwarding however. -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org
[9fans] Multi-dimensional filesystem
Hello, This is mainly a theoretical question. While playing with the representation of mathematical definitions as a file hierarchy (at dot you find a DESC or whatever named file with the description, and the subdirs are simply more restrictive instances of the thing; say : collection - magma - monoïde - group etc.), it is soon obvious that a filesystem is a one dimension thing: you only follow one string. Multiple parents at the same level are not there. One could trick partly using hard or soft links. But with always the same problem: who is dot-dot, in a case where multiple parents are here? And multiple parents are not, to my knowledge, supported by kernel filesystem code. Manipulating the namespace is not the same. Has someone ever played with the notion of a multidimensional filesystem, where '/' is the origin, the nodes would be some representation of (a, b, c,...) (even negatives perhaps), each node having a name (user defined one by the way), and if a node is, say (3, 0, 1,...) this means that it is to be found as the third subdir of the (1, 0, 0,...) path etc., (In this scheme, if there is no link (no path) from another notion, it is another dimension). Just for intellectual curiosity. Best, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Multi-dimensional filesystem
if i understand correctly, this is one way it could be done (i think): * built a graph representing the structure * create a file server that given a graph and a root node, synthesizes a hierarchy, AND * on every walk to a node launches a copy of itself with the same graph but the new node as the root AND * mounts the newly launched copy of it self under that node (like exportfs). -Skip On Fri, Aug 3, 2012 at 10:18 AM, tlaro...@polynum.com wrote: Hello, This is mainly a theoretical question. While playing with the representation of mathematical definitions as a file hierarchy (at dot you find a DESC or whatever named file with the description, and the subdirs are simply more restrictive instances of the thing; say : collection - magma - monoïde - group etc.), it is soon obvious that a filesystem is a one dimension thing: you only follow one string. Multiple parents at the same level are not there. One could trick partly using hard or soft links. But with always the same problem: who is dot-dot, in a case where multiple parents are here? And multiple parents are not, to my knowledge, supported by kernel filesystem code. Manipulating the namespace is not the same. Has someone ever played with the notion of a multidimensional filesystem, where '/' is the origin, the nodes would be some representation of (a, b, c,...) (even negatives perhaps), each node having a name (user defined one by the way), and if a node is, say (3, 0, 1,...) this means that it is to be found as the third subdir of the (1, 0, 0,...) path etc., (In this scheme, if there is no link (no path) from another notion, it is another dimension). Just for intellectual curiosity. Best, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Multi-dimensional filesystem
On Fri, Aug 03, 2012 at 11:58:08AM -0700, Skip Tavakkolian wrote: if i understand correctly, this is one way it could be done (i think): * built a graph representing the structure * create a file server that given a graph and a root node, synthesizes a hierarchy, AND * on every walk to a node launches a copy of itself with the same graph but the new node as the root AND * mounts the newly launched copy of it self under that node (like exportfs). Interesting. I guess the children/parents problem could be tricked by this translation (changing the origin on each node, and in fact presenting parents as one subdirs tree [reverse hierarchy] and the real children classically the other part (the negative could be precisely parents)). But in this case the equivalent of cd .. on root would indeed goes in a subdir, unless root is absolute root... What is typical is that n 9P, walk takes whether a subdir or the previous, that is the .. is really a local variable meaning whatever was before and not something hard encoded in the current file. The problem of implementing something efficient for the storage (not serving it) is another matter. The lack of links (whether hard or symbolic) on Plan9 could seem to suppress some facilities. But since this does not give all, even not a lot (this does not address multidimensional), it happens that it could be easier to implement something like this in a Plan9 world... Thanks! -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Multi-dimensional filesystem
Has someone ever played with the notion of a multidimensional filesystem David Korn did some research on a 3d file system called 3d: David G. Korn, Eduardo Krell, The 3-D File System, pp147-156, USENIX Conference Proceedings, Summer 1989, Baltimore, MD And also at behind a paywall: http://onlinelibrary.wiley.com/doi/10.1002/spe.4380201304/abstract I seem to remember it being available through ast: http://www2.research.att.com/sw/download/ -- Burton Samograd This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.
Re: [9fans] Multi-dimensional filesystem
On Fri, Aug 03, 2012 at 05:08:52PM -0400, Burton Samograd wrote: This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide. Are you kidding
Re: [9fans] Multi-dimensional filesystem
It's automatically added to my mails. Sorry, I forget about it because I don't add it, the mail server does. -Original Message- From: 9fans-boun...@9fans.net [mailto:9fans-boun...@9fans.net] On Behalf Of Kurt H Maier Sent: Friday, August 03, 2012 3:13 PM To: Fans of the OS Plan 9 from Bell Labs Subject: Re: [9fans] Multi-dimensional filesystem On Fri, Aug 03, 2012 at 05:08:52PM -0400, Burton Samograd wrote: This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide. Are you kidding This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.
[9fans] bind /net
Recently helped debugging a strange plan9 server problem. The machine being a cpu/auth/file server basicly doing everything from serving http with rc-httpd, accepting mail, serving dns and running a bunch of cronjobs doing various things. the machine is quite busy. It worked quite well for a some time. Then, it would stop accepting cpu logins. The clients cpu process would just hang there. Http would continue serve fine for a while until that will stop working too and finally, the machine will lockup and reboot. This happend like every 2 days or so. After some time, we where able to get a picture of what seemed to going on. There would be many processes blocked opening /mnt/factotum/rpc. Trying to ls /mnt will hang the ls... The machine would slowly accumulate locked up processes until it reached the 2k process limit... Problem was that factotum seemed busy in some auth protocol. (this really sucks. factotum is mounted directly on /mnt instead of /mnt/factotum and is single threaded so when its doing some auth business, noone can walk /mnt... this can even cause deadlock with authsrv which tries to access /mnt/keys on the same machine... but thats a different thing...) But there was no tcp567 or authsrv processes arround (the machine is itself an auth server). Netstat showed 2 established port 567 (ticket) connections. one for the outgoing one (to itself) and a incoming one (from itself). So where was that authsrv process? We greped for these 2 tcp connections in /proc/*/fd and turned out that the incoming one was showing up in the filedescriptor table of *exportfs* processes that where used to import /net from that machine instead of any authsrv. How was this possible? A terminal that was importing /net from this machine used to run aux/listen1 -t to run some local service prior importing /net in the same namespace. Why is this a problem? Well, the -t option causes listen1 to not fork its namespace so it will notice when we later overmount /net. On startup, it will succeed announcing the port on the original /net and start listening. Then, the parent process will change the /net under its foot. If a new connection comes in and listen1 will try to accept it and open its data file, it will grab some random connection on the *servers* /net instead of the one it was originaly listening on! We greped for the mysterious ticket connection path on the terminal and found it as the stdin of the completly unrelated local service on that terminal. And its /proc/xxx/ns file confirmed it was using the remote /net. Killing that process immidiately made the server unblock itself and continue normal operation. So dont do this at home kids. use /net.alt or face the consequences. -- cinap
