Re: [9fans] Miller's 9pi image (rpi4) problems
> The usb subsystem is known to be pretty rudimentary, and indeed with respect > to power management /sys/src/cmd/usb/usbd/usbd.c:/^portattach is headed by > this comment: > * BUG: does not consider max. power avail. > > Having said that, "It is impossible to use any usb disk" is possibly an > overstatement. Of course! I was talking about _me_ and _my_disks_. > Some disks will work, some won't. That's not necessarily > a power management problem. They are only recognized when powering them externally, and with risk of freezing the system. Note also that usb3 devices are not recognized on the usb3 ports (again... I mean my usb3 devices). > Some modern disks use the "UASP" > protocol in preference to the traditional bulk-only mass storage protocol > supported by the Plan 9 usbdisk driver. Even if the disk also supports > bulk-only, the existing driver won't try to pick an alternate configuration > to force the disk to fall back to that protocol. Below is a patch (tested on > only one drive, as far as I know) which will make it do that. Thanks, I'll give it a try. > As for your reported problem with webfs: > > webfs: tlsClient: fd out of range or not open > what exactly did you do which raised this error? I don't usually use webfs, > but > I've just tried it and made a successful tls connection to github with abaco. I can connect to github too, and some other places. But if you surf the web you'll end up with this error. Just a few If you want to do a test: https://developer.arm.com https://wikipedia.org https://marc.info https://www.perseus.tufts.edu http://mars.jpl.nasa.gov Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M3f483ca41f647ce8f0ff0d0a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
> > Some modern disks use the "UASP" > > protocol in preference to the traditional bulk-only mass storage protocol > > supported by the Plan 9 usbdisk driver. Even if the disk also supports > > bulk-only, the existing driver won't try to pick an alternate configuration > > to force the disk to fall back to that protocol. Below is a patch (tested on > > only one drive, as far as I know) which will make it do that. > > Thanks, I'll give it a try. No luck!, although the end points appear now after manually executing usb/disk. kprint when attaching the disk: usb/disk... usb/hub... /boot/usbd: disk: disk: endpoints not found usb/disk... ; cat /dev/usb/ctl ep1.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 port 0 rootport 0 addr 0 busy roothub csp 0x09 ports 1 xhci ep2.0 enabled control rw speed super maxpkt 512 pollival 0 samplesz 0 hz 0 hub 0 port 0 rootport 0 addr 0 busy roothub csp 0x09 ports 4 xhci ep3.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 port 1 rootport 1 addr 1 busy hub csp 0x010009 ports 4 none xhci ep8.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 port 3 rootport 1 addr 6 busy hub csp 0x020009 ports 4 'VIA Labs, Inc. ' 'USB2.0 Hub ' xhci ep5.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 port 4 rootport 1 addr 3 busy hub csp 0x010009 ports 4 'USB Device ' 'USB 2.0 Hub' xhci ep6.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 port 1 rootport 1 addr 4 busy hid csp 0x020103 vid 0x1c4f did 0x0078 SIGMACHIP 'SG 2.4G Wireless Mouse' xhci ep6.2 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 port 1 rootport 1 addr 4 busy ep7.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 port 2 rootport 1 addr 5 busy hid csp 0x010103 csp 0x03 vid 0x0c45 did 0x9510 S U xhci ep7.1 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 port 2 rootport 1 addr 5 busy ep9.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 6 port 3 rootport 1 addr 8 idle storage csp 0x500608 csp 0x620608 vid 0x0bc2 did 0xaa14 Seagate Basic xhci ; usb/disk -dD /dev/usb/ep9.0 usb/disk: fsioproc pid 332 <- Tversion tag 65535 msize 8216 version '9P2000' -> Rversion tag 65535 msize 8216 version '9P2000' <- Tauth tag 12 afid 394 uname adr aname -> Rerror tag 12 ename permission denied <- Tattach tag 12 fid 394 afid -1 uname adr aname -> Rattach tag 12 qid ( 0 d) usb/disk: startdevs: opening #0 /dev/usb/ep9.0 usb/disk: opendev 0x4e5d8 /dev/usb/ep9.0 usb/disk: /dev/usb/ep9.0 csp storage.6.80 vid 0xbc2 did 0xaa14 refs 1 Seagate Basic NABC5SSF conf: cval 1 attrib 80 500 mA iface csp storage.6.80 alt 0 attr 2 ival 0 disk: ep ids: in 1 out 2 usb/disk: opendev 0x50d98 /dev/usb/ep9.1 usb/disk: /dev/usb/ep9.1: maxpkt 512 usb/disk: /dev/usb/ep9.1: ntds 1 usb/disk: opendev 0x50e58 /dev/usb/ep9.2 usb/disk: /dev/usb/ep9.2: maxpkt 512 usb/disk: /dev/usb/ep9.2: ntds 1 disk: ep in /dev/usb/ep9.1 out /dev/usb/ep9.2 disk: /dev/usb/ep9.0: maxlun 0 disk: cmd: tag 0x1: 12 00 00 00 ff 00 datalen: 255 disk: data: 76 bytes disk: status: 00 residue: 179 disk: cmd: tag 0x2: 1b 00 00 00 01 00 datalen: 0 disk: status: 00 residue: 0 disk: cmd: tag 0x3: 25 00 00 00 00 00 00 00 00 00 datalen: 8 disk: data: 8 bytes disk: status: 00 residue: 0 disk: cmd: tag 0x4: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 datalen: 32 disk: data: 32 bytes disk: status: 00 residue: 0 disk: logical block size 512, # blocks 7814037167 usb/disk: fsadd sdU9.0 ; ls /dev/sd* /dev/sdM0/ctl /dev/sdM0/data /dev/sdM0/dos /dev/sdM0/fossil /dev/sdM0/nvram /dev/sdM0/plan9 /dev/sdM0/raw /dev/sdctl -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M8ba5098a8a830998e7df9632 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
On Fri, Jun 11, 2021 at 05:26:46PM +0100, Richard Miller wrote: > > No luck!, although the end points appear now after manually executing > > usb/disk. > > ... > > disk: logical block size 512, # blocks 7814037167 > > usb/disk: fsadd sdU9.0 > > Once you've reached that point, it looks like the driver is handling the disk > ok. > But despite the message you won't see it in /dev/sdU9.0 when starting usb/disk > manually, because the usb device namespace appears someplace else ... I can't > recall where just now. (9front does this in a different and better way.) > > What I would do is update /$objtype/bin/usb/usbd from the patched source and > rebuild the kernel with that. I did it, now the sd disk appears in /dev, but I can't set up the plan9 partitions: ; diskparts /dev/sdU0.0 ; ls /dev/sdU0.0 /dev/sdU0.0/ctl /dev/sdU0.0/data /dev/sdU0.0/raw ; fdisk /dev/sdU0.0/data cylinder = 8225280 bytes p1 0 50(50 cylinders, 392.21 MB) FAT32 p2 50 219051(219001 cylinders, 1.63 TB) PLAN9 empty 219051 486401(267350 cylinders, 2.00 TB) ; fdisk -p /dev/sdU0.0/data part dos 63 803250 part plan9 803250 3519064769 ; fdisk -p /dev/sdU0.0/data >/dev/sdU0.0/ctl ; ls /dev/sdU0.0 /dev/sdU0.0/ctl /dev/sdU0.0/data /dev/sdU0.0/raw Thanks anyway. adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mfef8a206570c443d88f25eaf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
Now all is making sense. The tricky part will be configuring it at boot time to make it the root file system... Thanks a lot to both of you for the help, specially to you Richard. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-Mb753391a9ced7ec824874c59 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Miller's 9pi image (rpi4) problems
> The biggest problem to me is the usb code.
>
> First I'm using a kvm switch so there are a lot of attachments-detachments.
> At a certain point it will end with "No slots available" and the
> usb will became unusable. For me is a labyrinth, but I'm pretty sure
> someone with more experience with the system could fix it.
I found how 9front fixed this:
--- /n/sources/contrib/miller/9/bcm/devusb.cWed Sep 18 16:02:39 2019
+++ devusb.cSun Jun 13 16:21:28 2021
@@ -389,6 +389,10 @@
if(ep->ep0 != ep){
putep(ep->ep0);
ep->ep0 = nil;
+ } else if(d != nil){
+ if(d->free != nil)
+ (*d->free)(d->aux);
+ free(d);
}
free(ep->info);
free(ep->name);
I can't understand the code yet, but my impression is that the
original intention was to not free the slot by default when a device
is detached, not allocate a new one if the same device is reconnected
but reused the old one, and free the unused slots when some time
has passed or if there is no one available. But what the code is
doing is allocating a new slot every time a new device is attached
and what this hack does is free the corresponded slot every time
a device is detached.
Regards,
adr.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M5713a1f8ec63663d9aeae58e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] rc: <{command} and > mess with exit status
; if(grep a <{echo a}) echo true
a
true
; if(echo a | grep a >/tmp/1) echo true
true
But now:
; if(grep a <{echo a} >/tmp/1) echo true
;
Is this expected?
Regards,
adr.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tad6cf6b7414c1847-M3c9f2f564a2513558ec2e075
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] rc: <{command} and > mess with exit status
Thanks, it looks like a bug. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad6cf6b7414c1847-Me2445f0e132fd2e7da654a5e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9legacy patches dependency & future releases
Hello, I was importing rc-line-split.diff from 9legacy and I realized that it is applied after rc-badrunes.diff. How are the dependencies of the patches noticed? Also I saw in https://plan9foundation.org "The sources for the Plan 9 operating system can be found at p9f.org/dl where new releases will be maintained into the future." I would preffer to wait to send diffs if there is going to be an active repository (I mean a tradicional one, no a patch queue) in the future. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1d655e15673a9e4c-M8c9687f46c53955edf007450 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] rc: <{command} and > mess with exit status
Thanks for the patch! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad6cf6b7414c1847-Ma7401221faeb5647bc8bec13 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy patches dependency & future releases
On Wed, Jun 16, 2021 at 03:55:07PM +0200, David du Colombier wrote: > > I was importing rc-line-split.diff from 9legacy and I realized that > > it is applied after rc-badrunes.diff. > > > > How are the dependencies of the patches noticed? > > The patches apply in order. Some are independent, > but some are depending on other patches. I see, then is more easy than I thought. I was going to ask you if you wanted to include the rc patch sent to the list from 9front, but I saw just now that is already there, that was fast! Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1d655e15673a9e4c-Mfd82250ab6636baede6beb2f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy patches dependency & future releases
I noticed that you rearranged the patches so the rc ones are now consecutive. Do you serve a 9p or there is another way to list the patches by date? I'm going to use 9legacy as a base distribution so this would be handy. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1d655e15673a9e4c-M646d2bd94d895f4d864dc5c1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
On Thu, Jun 17, 2021 at 04:05:15PM +0100, Steve Simon wrote: > I must appologise, though I sent a reply at the time, an out of date x509 > certificate meant the email never reached my ISP. Hi Steve, thanks anyway. > What I tried to say was... > > > I wonder if the abaco problem you are seeing is the global move to > > stronger TLS algorithms. I have backported libcrypt from 9front which > > was fairly straightforward - a it needed wider (but justified IMHO) changes > > than i hoped but it was an afternoon's work. Excuse my ignorance, but you mean libsec? I've already done that, I'm in the process of converting my system to 9legacy and and I'll share a diff then. I started importing ciphers and adding functions when needed, but soon I realized that it was silly because the code was written in a really conservative way, I copied the entire libsec/port dir and made only the needed changes when needed, it was easiest and fastest. The only major changes to the api were in okThumbprint() and initThumbprints() with an extra parameter for hash length and tag respectively. As I said I'll share it when it's clean, I think everybody would benefit sharing the same code in such an evolving field, I'll put a big patch somewhere and let the people decide. > > I use webfs from 9front too to - cinap pretty much rewrote it and his code > > is much cleaner (again IMHO). It needs only a couple of tiny tweeks to work. I think I didn't have to change webfs, I can connect to almost every site, but I still have some trouble with some of them, I want to debug it but now I'm using some free time trying to decide my fossil and venti partitions and settings... piece of cake... Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M18dc604cddfe579ad072e5df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Miller's 9pi image (rpi4) problems
> Some modern disks use the "UASP" protocol in preference to the > traditional bulk-only mass storage protocol supported by the Plan > 9 usbdisk driver. Even if the disk also supports bulk-only, the > existing driver won't try to pick an alternate configuration to > force the disk to fall back to that protocol. Below is a patch > (tested on only one drive, as far as I know) which will make it do > that. Richards that patch makes other devices to not work, have you tested it after compiling all usb and kernel? The test for storage and bulk is done in usb/disk.c. Adding Protouas to the test solve the problem. This is done also in 9front. Regards, adr. diff -urP /n/img/sys/src/cmd/usb/disk/disk.c /sys/src/cmd/usb/disk/disk.c --- /n/img/sys/src/cmd/usb/disk/disk.c Tue Dec 13 23:35:47 2011 +++ /sys/src/cmd/usb/disk/disk.cSat Jun 19 10:45:37 2021 @@ -663,7 +663,7 @@ continue; csp = ep->iface->csp; sc = Subclass(csp); - if(!(Class(csp) == Clstorage && (Proto(csp) == Protobulk))) + if(!(Class(csp) == Clstorage && (Proto(csp) == Protobulk || Proto(csp) == Protouas))) continue; if(sc != Subatapi && sc != Sub8070 && sc != Subscsi) fprint(2, "disk: subclass %#ulx not supported. trying anyway\n", sc); diff -urP /n/img/sys/src/cmd/usb/disk/ums.h /sys/src/cmd/usb/disk/ums.h --- /n/img/sys/src/cmd/usb/disk/ums.h Wed Feb 13 21:22:23 2013 +++ /sys/src/cmd/usb/disk/ums.h Sat Jun 19 10:44:13 2021 @@ -13,6 +13,7 @@ Protocbi = 0, /* control/bulk/interrupt; mainly floppies */ Protocb = 1, /* " with no interrupt; mainly floppies */ Protobulk = 0x50, /* bulk only */ + Protouas = 0x62, /* USB-attached SCSI */ Subrbc =1, /* reduced blk cmds */ Subatapi = 2, /* cd/dvd using sff-8020i or mmc-2 cmd blks */ -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M3f0383a01a6fdeb9cd22a303 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] full fossil follies
On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > it just becomes difficult > > to do anything when no fossil blocks can be allocated > > Thinking a bit further about this: intuitively one might expect to be > able to reboot using a local file system which is completely full, and > use du and ls to find big files and rm to delete them, without the need > to allocate new blocks. Something in the way fossil works, makes this > impossible at present. I wonder how much work it would be to investigate > and fix? I haven't studied how fossil works, so excuse this light chat. Couldn't fossil have reserved blocks so when it starts and it's full it can add those block and present the user to a recovery session? Just a console session printing the last file modified? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M386580fb9170872f973a9995 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] full fossil follies
On Fri, Jun 25, 2021 at 05:17:39PM +0200, tlaro...@polynum.com wrote: > On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote: > > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > > > it just becomes difficult > > > > to do anything when no fossil blocks can be allocated > > > > > > Thinking a bit further about this: intuitively one might expect to be > > > able to reboot using a local file system which is completely full, and > > > use du and ls to find big files and rm to delete them, without the need > > > to allocate new blocks. Something in the way fossil works, makes this > > > impossible at present. I wonder how much work it would be to investigate > > > and fix? > > > > I haven't studied how fossil works, so excuse this light chat. > > Couldn't fossil have reserved blocks so when it starts and it's > > full it can add those block and present the user to a recovery > > session? Just a console session printing the last file modified? > > I don't think I will tell anybody a scoop, but it is what is present in > traditional Unix filesystems where there is a percent of the storage > preserved... but for root, user under which you are not supposed to > log to the system in normal operation. This is probably the problem: > since there is no privileged user, for "whom" to preserve/reserve these > blocks? I don't think there is need of superuser concept here. What I'm imagining, again, without having seen the source code, is something like this: The file system is formatted and data representing the structure of the file system are stored normally. At execution time, the file server check a flag stored in some place to see if the system is full. If not, the data is changed so the blocks are "hidden" and execution continues. If the system is full, the file system starts a console session presenting the last file edited. At the end of the session, if the number of free blocks is bigger than the reserved blocks, the blocks are "hidden" and execution continues. If not, the console session gives an error and continues. The flag can be turn on at the same place the error of file system full is triggered. Again, easy talk, I haven't studied the source and a lot of people have said in this list that fossil is very complex. Some times the complexity of a task results in a complex implementation. You can't screw 1000 screws in a minute without a mechanical tool. What I don't know jet is if the complexity of fossil match its features. At least I can df all partitions... adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M010365538d976d3e3c89f274 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] full fossil follies
I don't think there is need of superuser concept here. What I'm imagining, again, without having seen the source code, is something like this: The file system is formatted and data representing the structure of the file system are stored normally. At execution time, the file server check a flag stored in some place to see if the system is full. If not, the data is changed so the blocks are "hidden" and execution continues. If the system is full, the file system starts a console session presenting the last file edited. At the end of the session, if the number of free blocks is bigger than the reserved blocks, the blocks are "hidden" and execution continues. If not, the console session gives an error and continues. The flag can be turn on at the same place the error of file system full is triggered. In a multi-user environment you can make the file system do something similar when the system is full, but instead of starting a console session, delete the last file modified and presenting the user an error. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M4987d580aea7ace04872c584 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9legacy venti-p9p, etc
venti-9p9, fossil-libventi, fossil-libventi-p9p, anyone with some experience with this? It's worthy? Thanks, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tac4d36dfa36d502c-M3dbeef3ea8045b3e74c40a0e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy venti-p9p, etc
On Sun, Jun 27, 2021 at 12:04:09AM +0200, David du Colombier wrote: > > venti-9p9, fossil-libventi, fossil-libventi-p9p, anyone with some > > experience with this? It's worthy? > > I highly recommend the fossil-libventi patch. The purpose > of this change is to get rid of the old liboventi and use > the new libventi and libthread. liboventi can be removed > after this patch. > > On the other side, the venti-p9p patch includes more experimental > changes, like the support of blocks larger than 56 KB. I wouldn't > recommend this patch. > > -- > David du Colombier Thanks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tac4d36dfa36d502c-Mfe01839a240ea853900a0ec6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] ape function args not checked|mixed ansi/old function declaration
Hi, let see if someone can put me in the right direction. I'm having now this issue compiling ape/lib/sec (/sys/src/libsec is modified): pcc -FTVw -c -+ -D_POSIX_SOURCE -D_PLAN9_SOURCE -I../../../../libmp/port -I. -I/sys/include/ape -I/sys/include ../../../../libsec/port/tlshand.c /sys/src/ape/lib/sec/port/../../../../libsec/port/tlshand.c:2896[stdin:5401] function args not checked: setrealloctag So I thought setrealloctag is not been declared, so I added it to the local libc.h (/sys/src/ape/lib/sec/port/libc.h): [...] extern voidsetmalloctag(void*, ulong); extern voidsetrealloctag(void*, uintptr); extern ulong getcallerpc(void*); [...] But now: pcc -FTVw -c -+ -D_POSIX_SOURCE -D_PLAN9_SOURCE -I../../../../libmp/port -I. -I/sys/include/ape -I/sys/include ../../../../libsec/port/des.c /sys/src/ape/lib/sec/port/./libc.h:173[stdin:1533] mixed ansi/old function declaration: setrealloctag I'm missing something about how ape is importing the headers, any hint? Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5d3998509603ebde-Mccca41b19d6ae0ccc0c716b5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: ape function args not checked|mixed ansi/old function declaration
Ok, the first error was that I used uintptr as in /sys/include/libc.h,
not uintptr_t as in /sys/include/ape/inttypes.h, that's the reason
of the ansi/old mix definition error.
I saw that setrealloctag.c is implemented in 9front's /sys/src/ape/lib/9/
the same way as setmalloctag.c, an empty definition. I added it to
my ape/lib/9/, the SUSV2 dance is taken from ape/lib/mp for
consistency:
mkfile:
[...]
setrealloctag.$O\
[...]
libc.h:
[...]
#ifndef _SUSV2_SOURCE
#define _SUSV2_SOURCE
#include
#undef _SUSV2_SOURCE
#else
#include
#endif
[...]
extern voidsetrealloctag(void*, uintptr_t);
[...]
setrealloctag.c:
#ifndef _SUSV2_SOURCE
#define _SUSV2_SOURCE
#include
#undef _SUSV2_SOURCE
#else
#include
#endif
void
setrealloctag(void*, uintptr_t)
{
}
Maybe just use #include "libc.h" here?
It compiles, and now after making similar changes my ape/port/sec
compiles too.
If someone is asking what is all of this about, is about importing
9front libsec to 9legacy. As I said before, the code is written on
top of the contributions I've seen in the 9legacy patches in a very
conservative way, after adding back aesCTR the impact is minimal.
This was the last piece... I'll put in some place the patches I
used from 9legacy and the steps to get a working base src from the
4th distribution, then my changes.
I used almost all the patches listed as included in the 9legacy
image so the common base is wider, even when some of them are of
not use to me. The only patches I didn't use were one that didn't
exist, the multiline tag acme patch (glitches) and two or three
which couldn't be applied.
Regards,
adr.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Ta3a6ef4d223738a9-M325536ac295e33bbad90bc0d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] mkfs
Hi, I was hacking libdisk/proto.c to accept quoted strings, when I noticed that mkfs is not using libdisk.h. The problem modifying mkfs.c is that the code taking care of kfs obliges me to keep functions duplicated on proto.c. The easiest solution is to remove kfs support and just extract protoenum() from copyfile(). Other approach is to make these functions needed by the kfs code available at disk.h, another one is to keep mkfs.c as it is for compatibility and clone another program, mktree without mkfs support and using disk.h. I'd like to be as compatible with the labs|9legacy distribution as possible, without breaking things other people can be using. Some thoughts from users? adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te2c67c4bc489fa54-M7335a5aacfe0f1462601e5e9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mkfs
On Mon, 5 Jul 2021, cinap_len...@felloff.net wrote:
thats what we did in 9front (just so you dont need to do it all
over again in case you commit to that approach).
Maybe you are interested in this then. The default bsize and the
"-8" thing is only for kfs as Erik Quanstrom noticed here (I miss
this guy on the list...)
https://www.mail-archive.com/9fans@9fans.net/msg31636.html
I've experimented and in my case too 8192 is the best value.
You don't need these variables any more:
int sfd;
int setuid; /* on Fs: set uid and gid? */
char*user;
You can delete the assignments and the code related to options that use them.
In your code, it seem that option '-a' can be used after '-d', I
just reused the variable i like this:
i = 0;
ARGBEGIN{
case 'a':
if(i == 1) {
fprint(2, "cannot use -a with -d\n");
usage();
}
fskind = Archive;
newroot = "";
Binits(&bout, 1, OWRITE, boutbuf, sizeof boutbuf);
break;
case 'd':
if(fskind == Archive) {
fprint(2, "cannot use -d with -a\n");
usage();
}
i = 1;
fskind = Fs;
newroot = ARGF();
break;
I got frustrated with proto.c. The implementation doesn't much the
description in proto(2) and the way recursion is exploited makes it
hard to fix it. Instead of rethinking the implementation, the code
has been extracted from mkfs.c and hacked to make it work when is
needed. There are places like "lets put a '\' here and see what
happens..." Files in the 4th field only work when the path matches
the source path, not the namespace as said in the manual. You can't
use files in the dest root directly as in
1 - - - /tmp/a/z/1
With the version using proto.c it works (only if the src is /!)
but I don't know if it is for the changes I made, you can test it
with yours.
I don't like how the interface is done. I would prefer something
simpler, for example call a function giving proto file, position
on the proto file, a structure for the new file with its permissions,
owner, etc, a place to store the source path and may be flags for
operations where performance can be improved, like copying entire
directories. This function could return the position of the next
entry in the proto file. Functions to do common operations, like
copying entire directories could be provided in disk.h.
Sorry for the runt,
adr.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Te2c67c4bc489fa54-Ma488a88e1c7c138aa329464a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] pngread: alloc chunk's length
Hi,
Png is using a fix size to allocate space for the chunks. I noticed
it because it couldn't open some png files (the chunk size was
bigger than IDATSIZE).
This patch removes IDATSIZE and instead makes png to allocate the
size of the chunk before reading it.
--- sys/src/cmd/jpg/readpng.c Thu Jan 24 23:39:55 2013
+++ /sys/src/cmd/jpg/readpng.c Sat Jul 10 13:09:13 2021
@@ -10,8 +10,6 @@
enum
{
- IDATSIZE = 100,
-
/* filtering algorithms */
FilterNone =0, /* new[x][y] = buf[x][y] */
FilterSub = 1, /* new[x][y] = buf[x][y] + new[x-1][y] */
@@ -51,7 +49,6 @@
struct ZlibR
{
Biobuf *io; /* input buffer */
- uchar *buf; /* malloc'ed staging buffer */
uchar *p; /* next byte to decompress */
uchar *e; /* end of buffer */
ZlibW *w;
@@ -94,19 +91,26 @@
}
static int
-getchunk(Biobuf *b, char *type, uchar *d, int m)
+chunklen(Biobuf *b)
{
- uchar buf[8];
+ uchar buf[4];
+
+ if(Bread(b, buf, 4) != 4)
+ return -1;
+ return get4(buf);
+}
+
+static int
+getchunk(Biobuf *b, char *type, uchar *d, int n)
+{
+ uchar buf[4];
ulong crc = 0, crc2;
- int n, nr;
+ int nr;
- if(Bread(b, buf, 8) != 8)
+ if(Bread(b, buf, 4) != 4)
return -1;
- n = get4(buf);
- memmove(type, buf+4, 4);
+ memmove(type, buf, 4);
type[4] = 0;
- if(n > m)
- sysfatal("getchunk needed %d, had %d", n, m);
nr = Bread(b, d, n);
if(nr != n)
sysfatal("getchunk read %d, expected %d", nr, n);
@@ -117,7 +121,7 @@
crc2 = get4(buf);
if(crc != crc2)
sysfatal("getchunk crc failed");
- return n;
+ return 0;
}
static int
@@ -129,25 +133,31 @@
if(z->p >= z->e){
Again:
- z->p = z->buf;
+ n = chunklen(z->io);
+ if(n < 0)
+ return -1;
+ z->p = pngmalloc(n, 0);
z->e = z->p;
- n = getchunk(z->io, type, z->p, IDATSIZE);
- if(n < 0 || strcmp(type, "IEND") == 0)
+ getchunk(z->io, type, z->p, n);
+ if(strcmp(type, "IEND") == 0){
+ free(z->p);
return -1;
+ }
z->e = z->p + n;
if(!strcmp(type,"PLTE")){
if(n < 3 || n > 3*256 || n%3)
sysfatal("invalid PLTE chunk len %d", n);
memcpy(z->w->palette, z->p, n);
z->w->palsize = 256;
+ free(z->p);
goto Again;
}
- if(type[0] & PropertyBit)
+ if(type[0] & PropertyBit){
+ free(z->p);
goto Again; /* skip auxiliary chunks fornow */
- if(strcmp(type,"IDAT")){
- sysfatal("unrecognized mandatory chunk %s", type);
- goto Again;
}
+ if(strcmp(type,"IDAT"))
+ sysfatal("unrecognized mandatory chunk %s", type);
}
return *z->p++;
}
@@ -383,18 +393,23 @@
{
char type[5];
int bpc, colorfmt, dx, dy, err, n, nchan, nout, useadam7;
- uchar *buf, *h;
+ uchar *buf, *mag, *h;
Rawimage *image;
ZlibR zr;
ZlibW zw;
- buf = pngmalloc(IDATSIZE, 0);
- if(Bread(b, buf, sizeof PNGmagic) != sizeof PNGmagic ||
- memcmp(PNGmagic, buf, sizeof PNGmagic) != 0)
+ mag = pngmalloc(sizeof PNGmagic, 0);
+ if(Bread(b, mag, sizeof PNGmagic) != sizeof PNGmagic ||
+ memcmp(PNGmagic, mag, sizeof PNGmagic) != 0)
sysfatal("bad PNGmagic");
+ free(mag);
- n = getchunk(b, type, buf, IDATSIZE);
- if(n < 13 || strcmp(type,"IHDR") != 0)
+ n = chunklen(b);
+ if(n < 0)
+ sysfatal("missing IHDR chunk");
+ buf = pngmalloc(n, 0);
+ getchunk(b, type, buf, n);
+ if(strcmp(type,"IHDR") != 0)
sysfatal("missing IHDR chunk");
h = buf;
dx = get4(h);
@@ -460,7 +475,7 @@
memset(&zr, 0, sizeof zr);
zr.w = &zw;
zr.io = b;
- zr.buf = buf;
+ free(buf);
memset(&zw, 0, sizeof zw);
if(useadam7)
@@ -483,7 +498,6 @@
if(err)
sysfatal("inflatezlib %s\n", flateerr(err));
- free(buf);
free(zw.scan);
free(zw.lastscan);
return image;
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Mdb82973047397d68fdedb7c3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
Checking the sent mail I noticed that I forgot to remove mag...
--- sys/src/cmd/jpg/readpng.c Thu Jan 24 23:39:55 2013
+++ /sys/src/cmd/jpg/readpng.c Sat Jul 10 13:09:13 2021
@@ -10,8 +10,6 @@
enum
{
- IDATSIZE = 100,
-
/* filtering algorithms */
FilterNone =0, /* new[x][y] = buf[x][y] */
FilterSub = 1, /* new[x][y] = buf[x][y] + new[x-1][y] */
@@ -51,7 +49,6 @@
struct ZlibR
{
Biobuf *io; /* input buffer */
- uchar *buf; /* malloc'ed staging buffer */
uchar *p; /* next byte to decompress */
uchar *e; /* end of buffer */
ZlibW *w;
@@ -94,19 +91,26 @@
}
static int
-getchunk(Biobuf *b, char *type, uchar *d, int m)
+chunklen(Biobuf *b)
{
- uchar buf[8];
+ uchar buf[4];
+
+ if(Bread(b, buf, 4) != 4)
+ return -1;
+ return get4(buf);
+}
+
+static int
+getchunk(Biobuf *b, char *type, uchar *d, int n)
+{
+ uchar buf[4];
ulong crc = 0, crc2;
- int n, nr;
+ int nr;
- if(Bread(b, buf, 8) != 8)
+ if(Bread(b, buf, 4) != 4)
return -1;
- n = get4(buf);
- memmove(type, buf+4, 4);
+ memmove(type, buf, 4);
type[4] = 0;
- if(n > m)
- sysfatal("getchunk needed %d, had %d", n, m);
nr = Bread(b, d, n);
if(nr != n)
sysfatal("getchunk read %d, expected %d", nr, n);
@@ -117,7 +121,7 @@
crc2 = get4(buf);
if(crc != crc2)
sysfatal("getchunk crc failed");
- return n;
+ return 0;
}
static int
@@ -129,25 +133,31 @@
if(z->p >= z->e){
Again:
- z->p = z->buf;
+ n = chunklen(z->io);
+ if(n < 0)
+ return -1;
+ z->p = pngmalloc(n, 0);
z->e = z->p;
- n = getchunk(z->io, type, z->p, IDATSIZE);
- if(n < 0 || strcmp(type, "IEND") == 0)
+ getchunk(z->io, type, z->p, n);
+ if(strcmp(type, "IEND") == 0){
+ free(z->p);
return -1;
+ }
z->e = z->p + n;
if(!strcmp(type,"PLTE")){
if(n < 3 || n > 3*256 || n%3)
sysfatal("invalid PLTE chunk len %d", n);
memcpy(z->w->palette, z->p, n);
z->w->palsize = 256;
+ free(z->p);
goto Again;
}
- if(type[0] & PropertyBit)
+ if(type[0] & PropertyBit){
+ free(z->p);
goto Again; /* skip auxiliary chunks fornow */
- if(strcmp(type,"IDAT")){
- sysfatal("unrecognized mandatory chunk %s", type);
- goto Again;
}
+ if(strcmp(type,"IDAT"))
+ sysfatal("unrecognized mandatory chunk %s", type);
}
return *z->p++;
}
@@ -388,13 +398,18 @@
ZlibR zr;
ZlibW zw;
- buf = pngmalloc(IDATSIZE, 0);
+ buf = pngmalloc(sizeof PNGmagic, 0);
if(Bread(b, buf, sizeof PNGmagic) != sizeof PNGmagic ||
memcmp(PNGmagic, buf, sizeof PNGmagic) != 0)
sysfatal("bad PNGmagic");
+ free(buf);
- n = getchunk(b, type, buf, IDATSIZE);
- if(n < 13 || strcmp(type,"IHDR") != 0)
+ n = chunklen(b);
+ if(n < 0)
+ sysfatal("missing IHDR chunk");
+ buf = pngmalloc(n, 0);
+ getchunk(b, type, buf, n);
+ if(strcmp(type,"IHDR") != 0)
sysfatal("missing IHDR chunk");
h = buf;
dx = get4(h);
@@ -460,7 +475,7 @@
memset(&zr, 0, sizeof zr);
zr.w = &zw;
zr.io = b;
- zr.buf = buf;
+ free(buf);
memset(&zw, 0, sizeof zw);
if(useadam7)
@@ -483,7 +498,6 @@
if(err)
sysfatal("inflatezlib %s\n", flateerr(err));
- free(buf);
free(zw.scan);
free(zw.lastscan);
return image;
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Mee347a801f72833f6f766ff2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Mon, 12 Jul 2021, o...@eigenstate.org wrote:
Why not make getchunk allocate? Somethign like:
---
//.git/fs/object/e8259861da3a55c03491904e4d11c5c15b7577c5/tree/sys/src/cmd/jpg/readpng.c
+++ sys/src/cmd/jpg/readpng.c
@@ -94,7 +94,7 @@
}
static int
-getchunk(Biobuf *b, char *type, uchar *d, int m)
+getchunk(Biobuf *b, char *type, uchar **d)
{
uchar buf[8];
ulong crc = 0, crc2;
@@ -103,11 +103,10 @@
if(Bread(b, buf, 8) != 8)
return -1;
n = get4(buf);
+ *d = pngmalloc(n, 0);
memmove(type, buf+4, 4);
type[4] = 0;
- if(n > m)
- sysfatal("getchunk needed %d, had %d", n, m);
- nr = Bread(b, d, n);
+ nr = Bread(b, *d, n);
if(nr != n)
sysfatal("getchunk read %d, expected %d", nr, n);
crc = blockcrc(crctab, crc, type, 4);
@@ -131,7 +130,7 @@
Again:
z->p = z->buf;
z->e = z->p;
- n = getchunk(z->io, type, z->p, IDATSIZE);
+ n = getchunk(z->io, type, &z->p);
if(n < 0 || strcmp(type, "IEND") == 0)
return -1;
z->e = z->p + n;
Hi Ori,
I thought that it would be a good idea to have a separate function
to just get the size without squeezing the fs through all the chunk,
it could be useful in the future. getchunk() could call it, but I
didn't see the point. I imagine that this is not a complete patch
but a suggestion, but anyway remember that you don't need z->buf
any more, and don't forget to free z->p for the next iteration.
By the way after revisiting readpng.c I noticed that I checked for
a negative value of the IHDR chunk length, better do like in the
original code:
[...]
n = chunklen(b);
if(n < 13)
sysfatal("missing IHDR chunk");
[...]
Regards,
adr.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-M36acff490ae45918672f52bd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Mon, 12 Jul 2021, o...@eigenstate.org wrote: Do you have an example? I could upload it in some place but you don't need it, really. The specification is clear, the length of a data chunk must be less than 2^31 - 1, and the complete image data is represented by a single zlib datastream that is stored in "some" number of IDAT chunks. That's all. A decoder can't make any other assumptions about the size or the boundaries of the chunks, of course correct me if I'm wrong. Anyway if you are curious they were music scores extracted from a pdf using mutool (mupdf). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Me409a3585b63dd2fc735d4b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Mon, 12 Jul 2021, hiro wrote: Date: Mon, 12 Jul 2021 20:04:23 +0200 From: hiro <23h...@gmail.com> Reply-To: 9fans <9fans@9fans.net> To: 9fans <9fans@9fans.net> Subject: Re: [9fans] pngread: alloc chunk's length it's always useful to have the testcase available, for others and for possible future regressions There is nothing to test, really, the length of an IDAT chunk can't be fixed (At least you want to allocate more than 2GB...) If a png file has a IDAT bigger than your constant, you are screwed. You haven't noticed because the majority of encoders use small chunks, but that doesn't mean that the code is right, is not. If you want to test with a png file anyway, take a big image and use some tool like http://optipng.sourceforge.net The resulting file will be possibly smaller, but the data stream will be encoded in one IDAT chunk to save space and reduce the overhead of processing numerous IDAT chunks. But you'll just get getchunk needed , had 100 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Mcaf942981401d70c27d13d7e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Mon, 12 Jul 2021, adr via 9fans wrote: [...] the length of a data chunk must be less than 2^31 - 1 [...] can't be fixed (At least you want to allocate more than 2GB...) [...] Well... to be exact here, it can't be bigger than 2^31 - 1, so there are "almost" 2GB. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Md3f857b8a239314394f2a9db Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Tue, 13 Jul 2021, hiro wrote: are you saying this is a purely synthetic error, it doesn't happen in the wild bec. these sizes are normally more sane? No, no... you got it wrong. You have to follow the specification of the format, unless you want to have surprises like this one. The file you'll obtain with the example I gave you will be as correct as any other png file. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-M1c74c38625f5a5b11071043e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Tue, 13 Jul 2021, hiro wrote: you seem to propose that if the png tells us to then we should allocate 2GB per chunk, just bec. the spec allows it even if the spec doesn't tell us a limit, we might want to have a limit. No. The system should constrain the allocation. If you have enough memory you should be allowed to open a _correct_ png file. Of course we could (I wont) discuss how to change the implementation to allow systems without enough ram to process files with large chunks, but I doubt it would be a problem in real life. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-M58cd1dfaefcf10ef70868139 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
By the way, the lenght should be checked to not exceed 0x7FFF
so a corrupt chunk can be detected early.
--- /n/dump/2021/0627/sys/src/cmd/jpg/readpng.c Thu Jan 24 23:39:55 2013
+++ /sys/src/cmd/jpg/readpng.c Tue Jul 13 11:16:50 2021
@@ -10,8 +10,6 @@
enum
{
- IDATSIZE = 100,
-
/* filtering algorithms */
FilterNone =0, /* new[x][y] = buf[x][y] */
FilterSub = 1, /* new[x][y] = buf[x][y] + new[x-1][y] */
@@ -51,7 +49,6 @@
struct ZlibR
{
Biobuf *io; /* input buffer */
- uchar *buf; /* malloc'ed staging buffer */
uchar *p; /* next byte to decompress */
uchar *e; /* end of buffer */
ZlibW *w;
@@ -94,19 +91,28 @@
}
static int
-getchunk(Biobuf *b, char *type, uchar *d, int m)
+chunklen(Biobuf *b)
+{
+ ulong n;
+
+ uchar buf[4];
+
+ if(Bread(b, buf, 4) != 4 || (n=get4(buf)) > 0x7FFF)
+ return -1;
+ return n;
+}
+
+static int
+getchunk(Biobuf *b, char *type, uchar *d, int n)
{
- uchar buf[8];
+ uchar buf[4];
ulong crc = 0, crc2;
- int n, nr;
+ int nr;
- if(Bread(b, buf, 8) != 8)
+ if(Bread(b, buf, 4) != 4)
return -1;
- n = get4(buf);
- memmove(type, buf+4, 4);
+ memmove(type, buf, 4);
type[4] = 0;
- if(n > m)
- sysfatal("getchunk needed %d, had %d", n, m);
nr = Bread(b, d, n);
if(nr != n)
sysfatal("getchunk read %d, expected %d", nr, n);
@@ -117,7 +123,7 @@
crc2 = get4(buf);
if(crc != crc2)
sysfatal("getchunk crc failed");
- return n;
+ return 0;
}
static int
@@ -129,25 +135,31 @@
if(z->p >= z->e){
Again:
- z->p = z->buf;
+ n = chunklen(z->io);
+ if(n < 0)
+ return -1;
+ z->p = pngmalloc(n, 0);
z->e = z->p;
- n = getchunk(z->io, type, z->p, IDATSIZE);
- if(n < 0 || strcmp(type, "IEND") == 0)
+ getchunk(z->io, type, z->p, n);
+ if(strcmp(type, "IEND") == 0){
+ free(z->p);
return -1;
+ }
z->e = z->p + n;
if(!strcmp(type,"PLTE")){
if(n < 3 || n > 3*256 || n%3)
sysfatal("invalid PLTE chunk len %d", n);
memcpy(z->w->palette, z->p, n);
z->w->palsize = 256;
+ free(z->p);
goto Again;
}
- if(type[0] & PropertyBit)
+ if(type[0] & PropertyBit){
+ free(z->p);
goto Again; /* skip auxiliary chunks fornow */
- if(strcmp(type,"IDAT")){
- sysfatal("unrecognized mandatory chunk %s", type);
- goto Again;
}
+ if(strcmp(type,"IDAT"))
+ sysfatal("unrecognized mandatory chunk %s", type);
}
return *z->p++;
}
@@ -388,13 +400,18 @@
ZlibR zr;
ZlibW zw;
- buf = pngmalloc(IDATSIZE, 0);
+ buf = pngmalloc(sizeof PNGmagic, 0);
if(Bread(b, buf, sizeof PNGmagic) != sizeof PNGmagic ||
memcmp(PNGmagic, buf, sizeof PNGmagic) != 0)
sysfatal("bad PNGmagic");
+ free(buf);
- n = getchunk(b, type, buf, IDATSIZE);
- if(n < 13 || strcmp(type,"IHDR") != 0)
+ n = chunklen(b);
+ if(n < 13)
+ sysfatal("wrong IHDR chunk length");
+ buf = pngmalloc(n, 0);
+ getchunk(b, type, buf, n);
+ if(strcmp(type,"IHDR") != 0)
sysfatal("missing IHDR chunk");
h = buf;
dx = get4(h);
@@ -460,7 +477,7 @@
memset(&zr, 0, sizeof zr);
zr.w = &zw;
zr.io = b;
- zr.buf = buf;
+ free(buf);
memset(&zw, 0, sizeof zw);
if(useadam7)
@@ -483,7 +500,6 @@
if(err)
sysfatal("inflatezlib %s\n", flateerr(err));
- free(buf);
free(zw.scan);
free(zw.lastscan);
return image;
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-M13a5098cf3af92b1671aa59c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] pngread: alloc chunk's length
On Wed, 14 Jul 2021, o...@eigenstate.org wrote: Yes, but your patch doesn't apply cleanly to 9front, and it would be useful to check whether I fuck up porting it manually. Ok, but I told you already how to create one. http://adr.freeshell.org/files/turner_ovid_banished_from_rome.png -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a714ed14c50767a-Mc0426d011a67f1ff1400cc2b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Command to set samterm label
Hi,
I was hacking sam to set /dev/label to 'sam filename' when one is
given to be opened but then I thought that it would be better to
make samterm do it, so it'll work when using sam remotely.
This patch adds a command 'l' to set the label, and sets it at
startup as described above.
Regards,
adr.
--- sys/src/cmd/sam/cmd.c Wed Apr 24 00:06:05 2013
+++ /sys/src/cmd/sam/cmd.c Sun Jul 18 18:23:06 2021
@@ -17,6 +17,7 @@
'g',0, 1, 0, 'p',aDot, 0, 0, g_cmd,
'i',1, 0, 0, 0, aDot, 0, 0, i_cmd,
'k',0, 0, 0, 0, aDot, 0, 0, k_cmd,
+ 'l',0, 0, 0, 0, aNo,0, linex, l_cmd,
'm',0, 0, 1, 0, aDot, 0, 0, m_cmd,
'n',0, 0, 0, 0, aNo,0, 0, n_cmd,
'p',0, 0, 0, 0, aDot, 0, 0, p_cmd,
--- sys/src/cmd/sam/mesg.h Fri Mar 18 22:33:33 2005
+++ /sys/src/cmd/sam/mesg.h Sun Jul 18 18:25:36 2021
@@ -67,6 +67,7 @@
Hack, /* request acknowledgement */
Hexit,
Hplumb, /* return plumb message to terminal - version 1 */
+ Hlabel, /* change /dev/label */
HMAX,
}Hmesg;
typedef struct Header{
--- sys/src/cmd/sam/parse.h Thu Oct 27 15:36:34 2005
+++ /sys/src/cmd/sam/parse.hSat Jul 17 19:55:51 2021
@@ -55,13 +55,12 @@
int nl_cmd(File*, Cmd*), a_cmd(File*, Cmd*), b_cmd(File*, Cmd*);
int c_cmd(File*, Cmd*), cd_cmd(File*, Cmd*), d_cmd(File*, Cmd*);
-intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*);
-intf_cmd(File*, Cmd*), g_cmd(File*, Cmd*), i_cmd(File*, Cmd*);
-intk_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
-intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*);
-ints_cmd(File*, Cmd*), u_cmd(File*, Cmd*), w_cmd(File*, Cmd*);
-intx_cmd(File*, Cmd*), X_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*);
-inteq_cmd(File*, Cmd*);
+intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*), f_cmd(File*, Cmd*);
+intg_cmd(File*, Cmd*), i_cmd(File*, Cmd*), k_cmd(File*, Cmd*);
+intl_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
+intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*), s_cmd(File*, Cmd*);
+intu_cmd(File*, Cmd*), w_cmd(File*, Cmd*), x_cmd(File*, Cmd*);
+intX_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*), eq_cmd(File*, Cmd*);
String*getregexp(int);
--- sys/src/cmd/sam/sam.c Tue Dec 6 17:05:45 2005
+++ /sys/src/cmd/sam/sam.c Sat Jul 17 17:01:44 2021
@@ -98,6 +98,8 @@
seq++;
if(file.nused)
current(file.filepptr[0]);
+ if(curfile)
+ outTS(Hlabel, &(curfile->name));
setjmp(mainloop);
cmdloop();
trytoquit();/* if we already q'ed, quitok will be TRUE */
--- sys/src/cmd/sam/xec.c Tue Jun 6 02:55:54 2000
+++ /sys/src/cmd/sam/xec.c Sat Jul 17 20:20:41 2021
@@ -154,6 +154,14 @@
}
int
+l_cmd(File *f, Cmd *cp)
+{
+ USED(f);
+ outTS(Hlabel, cp->ctext);
+ return TRUE;
+}
+
+int
m_cmd(File *f, Cmd *cp)
{
Address addr2;
--- sys/src/cmd/samterm/mesg.c Thu Mar 29 19:35:49 2012
+++ /sys/src/cmd/samterm/mesg.c Sat Jul 17 20:28:26 2021
@@ -97,6 +97,7 @@
int i, m;
long l;
Flayer *lp;
+ char *str, c;
m = inshort(0);
l = inlong(2);
@@ -106,6 +107,16 @@
default:
fprint(2, "type %d\n", type);
panic("rcv unknown");
+
+ case Hlabel:
+ str = (char *)indata;
+ if((i = open("/dev/label", OWRITE)) >= 0){
+ while((c=*str) == ' ' || c=='\t')
+ str++;
+ fprint(i, "%s %s", "sam", str);
+ close(i);
+ }
+ break;
case Hversion:
hversion = m;
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tf1e211daf823c0e0-M6011c83bf34acbf24c11966a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Command to set samterm label
On Mon, 19 Jul 2021, umbrati...@prosimetrum.com wrote: This patch adds a command 'l' to set the label, and sets it at startup as described above. meh; you can already run !label blah from inside sam That's run by sam, not samterm. not sure the label-on-startup adds much? It's for using multimple instances of sam. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf1e211daf823c0e0-M1b37b0e9f704fadce4e61f64 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Command to set samterm label
Ok, Let me explain this a little. I don't like this "One X to rule them all" concept, recreating complete interfaces. I would prefer to use one gui, and make the programs integrate in it, rethinking some concepts if necessary. Been able to modify the label is fundamental for this. It's a way to identify the program and show its state. Just the same sam does inside its own duplicated interface. The correct way to do this is respecting the program design. That's why the label must be changed in the samterm side. This little change allows you to open a file with one instance of sam, another file with another instance (just not use plumb to edit...) and be able to identify them, using the gui you already have, rio. And if for example you open another file because you need them stuck side by side (but this should be done by gui, not by the editor...) you still can rename the label manually to reflect the change. The next step is add an option (or better an environment variable) to use the rio snarf buffer directly. If you don't see the point of this, just ignore this thread. I'm sharing this patch just in case someone is so frustrated as me with this design, nothing more. By the way, sam -r allows you to edit remotely a file in a unix system, not only with p9p sam, samterm will drive even the old sam from pkgsrc. Running samterm locally is way more efficient than using X forwarding. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf1e211daf823c0e0-M4075dd8b5bd996932f445643 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] sam label and rio snarf buffer
Hi,
I changed the last patch so sam wont change the label at startup.
I added a new option '-l' to set the label, it's more flexible and
doesn't chage the normal behavior. If samriosnarf is in /env, sam will
use rio's snarf buffer instead of the internal one.
This patch should apply to 9legacy, if you use the lab's distro
apply first sam-wheel.diff from 9legacy.
Regards,
adr.
--- sys/src/cmd/sam/cmd.c Wed Apr 24 00:06:05 2013
+++ /sys/src/cmd/sam/cmd.c Sun Jul 18 18:23:06 2021
@@ -17,6 +17,7 @@
'g',0, 1, 0, 'p',aDot, 0, 0, g_cmd,
'i',1, 0, 0, 0, aDot, 0, 0, i_cmd,
'k',0, 0, 0, 0, aDot, 0, 0, k_cmd,
+ 'l',0, 0, 0, 0, aNo,0, linex, l_cmd,
'm',0, 0, 1, 0, aDot, 0, 0, m_cmd,
'n',0, 0, 0, 0, aNo,0, 0, n_cmd,
'p',0, 0, 0, 0, aDot, 0, 0, p_cmd,
--- sys/src/cmd/sam/mesg.c Fri Jan 12 17:02:55 2007
+++ /sys/src/cmd/sam/mesg.c Tue Jul 20 12:10:43 2021
@@ -1,4 +1,5 @@
#include "sam.h"
+#include
Headerh;
uchar indata[DATASIZE];
@@ -348,17 +349,26 @@
f = whichfile(inshort());
p0 = inlong();
journaln(0, p0);
- for(l=0; lBLOCKSIZE)
- m = BLOCKSIZE;
- bufread(&snarfbuf, l, genbuf, m);
- loginsert(f, p0, tmprstr(genbuf, m)->s, m);
+
+ if(*(char*)inp != 0){
+ str = tmpcstr((char*)inp);
+ m = str->n;
+ loginsert(f, p0, str->s, m);
+ freetmpstr(str);
+ }else{
+ for(l=0; lBLOCKSIZE)
+ m = BLOCKSIZE;
+ bufread(&snarfbuf, l, genbuf, m);
+ loginsert(f, p0, tmprstr(genbuf, m)->s, m);
+ }
+ m = snarfbuf.nc;
}
if(fileupdate(f, FALSE, TRUE))
seq++;
f->dot.r.p1 = p0;
- f->dot.r.p2 = p0+snarfbuf.nc;
+ f->dot.r.p2 = p0+m;
f->tdot.p1 = -1; /* force telldot to tell (arguably a BUG) */
telldot(f);
outTs(Hunlockfile, f->tag);
--- sys/src/cmd/sam/mesg.h Fri Mar 18 22:33:33 2005
+++ /sys/src/cmd/sam/mesg.h Sun Jul 18 18:25:36 2021
@@ -67,6 +67,7 @@
Hack, /* request acknowledgement */
Hexit,
Hplumb, /* return plumb message to terminal - version 1 */
+ Hlabel, /* change /dev/label */
HMAX,
}Hmesg;
typedef struct Header{
--- sys/src/cmd/sam/parse.h Thu Oct 27 15:36:34 2005
+++ /sys/src/cmd/sam/parse.hSat Jul 17 19:55:51 2021
@@ -55,13 +55,12 @@
int nl_cmd(File*, Cmd*), a_cmd(File*, Cmd*), b_cmd(File*, Cmd*);
int c_cmd(File*, Cmd*), cd_cmd(File*, Cmd*), d_cmd(File*, Cmd*);
-intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*);
-intf_cmd(File*, Cmd*), g_cmd(File*, Cmd*), i_cmd(File*, Cmd*);
-intk_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
-intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*);
-ints_cmd(File*, Cmd*), u_cmd(File*, Cmd*), w_cmd(File*, Cmd*);
-intx_cmd(File*, Cmd*), X_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*);
-inteq_cmd(File*, Cmd*);
+intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*), f_cmd(File*, Cmd*);
+intg_cmd(File*, Cmd*), i_cmd(File*, Cmd*), k_cmd(File*, Cmd*);
+intl_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
+intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*), s_cmd(File*, Cmd*);
+intu_cmd(File*, Cmd*), w_cmd(File*, Cmd*), x_cmd(File*, Cmd*);
+intX_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*), eq_cmd(File*, Cmd*);
String*getregexp(int);
--- sys/src/cmd/sam/sam.c Tue Dec 6 17:05:45 2005
+++ /sys/src/cmd/sam/sam.c Tue Jul 20 12:23:28 2021
@@ -25,6 +25,7 @@
int termlocked;
char *samterm = SAMTERM;
char *rsamname = RSAM;
+char *samtermlabel = nil;
File *lastfile;
Disk *disk;
long seq;
@@ -57,6 +58,9 @@
case 's':
rsamname = EARGF(usage());
break;
+ case 'l':
+ samtermlabel = EARGF(usage());
+ break;
default:
dprint("sam: unknown flag %c\n", ARGC());
usage();
@@ -82,6 +86,11 @@
startup(machine, Rflag, termargs, argv);
notify(notifyf);
getcurwd();
+ if(samtermlabel){
+ t=tmpcstr(samtermlabel);
+ outTS(Hlabel, t);
+ freetmpstr(t);
Re: [9fans] sam label and rio snarf buffer
On Tue, 20 Jul 2021, Skip Tavakkolian wrote: what problem did this fix for you? all the changes seem like bad ideas for general use; e.g. would hiding a sam window show a name other than sam? This is for using different instances of sam... Is not for your "general use". I've explained this before. Anyway, this add the posibility of changing the label, it not forces you to do it. If you don't use the -l option, don't define samriosnarf and you are unaware of the 'l' command, sam will behave exactly the same, you will not notice, that's something I really like of this patch. regarding snarf, couldn't you get what you need by manipulating the namespace with an rc script wrapper? I really don't know what on earth are you talking about. Sam's snarf buffer is an internal buffer (defined in sam/mesg.c), it isn't presented in a file system. But even if that were the case, it will not work if samter and sam were in different machines. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mad061fe322c02394d56d259c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
I don't want to add noise to the list, but it seem that some people are confused about what I'm doing with this. You start in rio to work in some project. You open sam in a big window because all the files will be opened inside. You start opening files and changing the focus using the menu, and the text selected in one window can be pasted easily in another, beautiful. Now you need to open a pdf, for example with the specification of some image format. Beautiful? no, horrible, because now you have to arrange the big sam window and the windows inside of it so you can keep editing some file while the pdf is at sight. And now you have to consult some information in a website related to other file you are working on, and you want to copy a selection to sam... well you have the idea. The problem (for me, it seem other people are happy with this) is the design concept of one editor to edit all the files, recreating another windows environment inside the windows environment you already have, rio. This patch allows you to use sam in another way, without breaking nor changing anything when used "normally". I have plumbing rules to open a file with a new instance of sam with the label "sam /file/path". I can exchange selections easily with other sam instances or other applications that use rio's snarf buffer. I can't identify the file I'm editing using winwatch or the menu when hidden, and so on. I hope all is clear now. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M22f1441f0287b54e19a5f95c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
On Tue, 20 Jul 2021, adr via 9fans wrote: buffer. I can't identify the file I'm editing using winwatch or the menu when hidden, and so on. Oh my... is "I can identify..." and I wanted to make things clear... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M034dd1bb3ac6bfaa1b679c71 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
You'll need to reinvent (or change, at least) plumbing if you want multiple editors, be it one per file or one per project. I'll make sam create allways the named pipe with the pid in the name so I can identify wich one I want to talk with. There are a lot of possibilities. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M7399c12fd69d9910d71248d0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
In case someone was playing with this, last patch was really naive
(and buggy). I tried different approaches while learning more about
how the two parts of the editor interact with each other and after
some back-and-forths it's working now.
I enabled again the menu item when samriosnarf is defined,
so the internal buffer can be used as a temporal storage.
I've to think about the plumber and the the named pipe to be able
to plumb a file and bring to the front a sam instance if it has
the file open, moving the file's window to the front with dot set at
the address, if one is given.
If you don't set samriosnarf you wont notice anything, this
patch doesn't change the normal behavior of sam.
I've to revise the code and test it more, but I don't like the idea
of a buggy patch floting on the list, even if no one is using it.
Regards,
adr.
--- sys/src/cmd/samterm/main.c Sat Jun 26 21:12:44 2021
+++ /sys/src/cmd/samterm/main.c Fri Jul 23 21:49:09 2021
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,7 @@
long modified = 0; /* strange lookahead for menus */
char hostlock = 1;
char hasunlocked = 0;
+char riosnarf = 0;
int maxtab = 8;
int autoindent;
@@ -35,6 +37,8 @@
Rectangle r;
Flayer *nwhich;
+ if(getenv("samriosnarf"))
+ riosnarf = 1;
getscreen(argc, argv);
iconinit();
initio();
@@ -250,10 +254,27 @@
snarf(Text *t, int w)
{
Flayer *l = &t->l[w];
+ int fd;
+ int n;
+ long p;
if(l->p1>l->p0){
snarflen = l->p1-l->p0;
- outTsll(Tsnarf, t->tag, l->p0, l->p1);
+ if(riosnarf){
+ if((fd=open("/dev/snarf", OWRITE)) < 0){
+ fprint(2, "samterm:snarf: can't open /dev/snarf for
writing");
+ return;
+ }
+ t = l->user1;
+ for(p=l->p0; pp1; p+=n){
+ n = l->p1-p>BLOCKSIZE? BLOCKSIZE : l->p1-p;
+ rload(&t->rasp, p, p+n, nil);
+ if(fprint(fd, "%.*S", n, scratch) < 0)
+ break;
+ }
+ close(fd);
+ }else
+ outTsll(Tsnarf, t->tag, l->p0, l->p1);
}
}
@@ -280,14 +301,75 @@
hcheck(t->tag);
}
+#define HSIZE 3
+#define MAXCSTR (DATASIZE-HSIZE-sizeof(int)-2*sizeof(long)) /* Max cstring
allowed by outTsllS */
void
paste(Text *t, int w)
{
- if(snarflen){
- cut(t, w, 0, 0);
- t->lock++;
- outTsl(Tpaste, t->tag, t->l[w].p0);
+ Rune *rstr, *rp;
+ Biobuf *bp;
+ int rstrsize;
+ int len; /* size in bytes of current rstr converted to UTF */
+ int m, n; /* n: number of runes already on rstr */
+ long offset, last;
+
+ if(!riosnarf){
+ if(snarflen){
+ cut(t, w, 0, 0);
+ t->lock++;
+ outTsllS(Tpaste, t->tag, 0, t->l[w].p0, L"");
+ }
+ return;
+ }
+ rstrsize = MAXCSTR;
+ if((bp=Bopen("/dev/snarf", OREAD)) == 0){
+ fprint(2, "samterm:paste: can't open /dev/snarf");
+ return;
+ }
+ offset = t->l[w].p0;
+ rp = rstr = alloc(rstrsize);
+ len = n = 0;
+ if((last=Bgetrune(bp)) <= 0)
+ return;
+ cut(t, w, 0, 0);
+ while((long)(*rp=last?last:Bgetrune(bp)) > 0){
+ last = 0;
+ if((len+=runelen(*rp)) > MAXCSTR){
+ Bungetrune(bp);
+ --n;
+ last = *(rp-1); /* can't Bungetrune again... */
+ *(rp-1) = 0;
+ if(t->lock == 0)
+ t->lock = 1;
+ if(Bgetrune(bp) <= 0){ /* Last chunk */
+ outTsllS(Tpaste, t->tag, t->l[w].p0, offset,
rstr);
+ break;
+ }
+ Bungetrune(bp);
+ outTsllS(Tpaste, t->tag, -1, offset, rstr);
+ offset += n;
+ rp = rstr;
+ n = len = 0;
+ continue;
+ }
+ if(RUNESIZE*(rp-rstr+2) > rstrsize){
+ m = rp - rstr;
+ rstr = realloc(rstr, rstrsize+=MAXCSTR);
+ if(!rstr)
+ panic("realloc");
+
[9fans] Re: Learning C the hard way
Hi, plan6? Your newlines are feeding the next getchar. You don't want to read chars, you want to read strings. Read the documentation, don't use stdio.h, explore the 9 way... Regards, adr -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcb666367f7ec3af5-Me54e289c46e8d4a3f30e66dc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: 9legacy: '/boot/kfs' does not exist
Hi Antonio, I replaced boot for an rc script time ago, but if I recalled correctly, this is because boot can't find fossil's configuration in any hard drive, so it tries to find a kfs, but the default kernel configuration doesn't include kfs in bootdir, so it gives you that error. Boot from the live CD and try using fossil/conf in your fossil partition to see if there is a configuration stored or not. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9732b4657cb10d19-M3d50c113b8c6b4c6a21f4959 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: 9legacy: '/boot/kfs' does not exist
Oh, by the way, if you are using a usb hard disk, boot will screw with partfs and the usb disk's partitions will not be exposed. That's the main reason I replaced it. If that's the case, take a look in the mailing list archive, Richard Miller gave some workaround storing the config in the first sectors of the disk. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9732b4657cb10d19-M53455d6976babf70e561d78b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
> I've put a script in contrib/miller/build-9pi.rc which shows the complete process of building (almost) the 9pi image from the 4th edition ISO. You can look at that to see what 9legacy patches are applied. Hi Richard. I'm surprised by the small number of 9legacy patches you are using. Any reason in particular that you could share? I'm preparing a new installation and this is a good time to choose the starting point. > The actual 9pi.img.gz on contrib is a "golden" copy which I've been updating with individual patches since about 2012 Do you mean other patches than the ones you shared with 9legacy? Regards, adr -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M274ad663cccfc3a3db43b78f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
I see, thanks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M0fe5284a21a2266220ee5409 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Go arm builder's image
Last thing about your rpi image Richard, Is this the one used in the go arm builders? Can I asume that these are the only patches needed to have a working go? Regards, adr
Re: [9fans] Go arm builder's image
Ok, thanks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3dbd3cda56f638ee-M16e29431130bbf818b28 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
