Re: [9fans] bonjour mDNS?
that would not work, because of how dns(1) presents its interface. if the file server presented a directory of files then you can merge them. however dns has a single file that you open, write a request to, and then later read a reply from. in this later form you merge the directories you just have two request files, rather than one request file which offers the service of moth files. I am not sure I have explained this very well, I hope you understand. -Steve > On 2 Jan 2016, at 05:17, Marc Boschma wrote: > > Still getting my head around Plan9 but wouldn’t mounting the unicast and > multicast DNS file servers over the top of each other work? (I assume the > order of the mount (bind) would lead to resolution order… but maybe no > unified responses. > > Marc > >> On 2 Jan 2016, at 2:42 pm, erik quanstrom wrote: >> >> On Fri Jan 1 19:32:25 PST 2016, m...@boschma.cx wrote: >>> On 2 Jan 2016, at 7:05 am, Steve Simon wrote: anyone done any work to implement mDNS / bonjour on plan9? >>> >>> No, but I have an interest; just starting out with Plan9 :) >>> my rough plan is to write a file server which generates /lib/ndb/mdns which can be included into your /lib/ndb/local. I fear the biggest hassle is the clash of UDP port use may mean mDNS must become part of dns(1) rather than a separate file server. >>> >>> Shouldn’t dns(1) only bind to unicast UDP port and thus mDNS could bind to >>> the multicast UDP port? >>> >>> Are you only considering resolution or also publishing services? >> >> it would make sense to me to make a dnsudp request file server that manages >> requests, and >> fork (ha!) that task off to it. this file server would not care if it's >> querying normal dns, >> or mdns. >> >> - erik >
[9fans] mDNS
, I am confused, are you talking of replacing the interface to dns(1)? I had no real plan, maybe to just make mDNS accumulate broadcast and multicast mDNS messages into a virtual file in /lib/ndb format. more importantly I really need a publish system, which would be just based off /lib/ndb/local, just a static spec. my target is porting shairport, and maybe Dnla at a later date. -Steve > On 2 Jan 2016, at 03:42, erik quanstrom wrote: > >> On Fri Jan 1 19:32:25 PST 2016, m...@boschma.cx wrote: >> >>> On 2 Jan 2016, at 7:05 am, Steve Simon wrote: >>> anyone done any work to implement mDNS / bonjour on plan9? >> >> No, but I have an interest; just starting out with Plan9 :) >> >>> my rough plan is to write a file server which generates /lib/ndb/mdns >>> which can be included into your /lib/ndb/local. >>> >>> I fear the biggest hassle is the clash of UDP port use may mean >>> mDNS must become part of dns(1) rather than a separate file server. >> >> Shouldn’t dns(1) only bind to unicast UDP port and thus mDNS could bind to >> the multicast UDP port? >> >> Are you only considering resolution or also publishing services? > > it would make sense to me to make a dnsudp request file server that manages > requests, and > fork (ha!) that task off to it. this file server would not care if it's > querying normal dns, > or mdns. > > - erik
Re: [9fans] bonjour mDNS?
That makes perfect sense… So dns(1) should probably be patched then…? Marc > On 2 Jan 2016, at 8:21 pm, Steve Simon wrote: > > that would not work, because of how dns(1) presents its interface. > > if the file server presented a directory of files then you can merge them. > > however dns has a single file that you open, write a request to, and then > later > read a reply from. > > in this later form you merge the directories you just have two request files, > rather than one request file which offers the service of moth files. > > I am not sure I have explained this very well, I hope you understand. > > -Steve >
Re: [9fans] need a REAL WORKING iso
hello, I have recently reinstalled 9pi. -rw-r-@ 1 arisawa staff 127695824 1 1 18:38 9pi.img.gz which is downloaded from plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz the img works fine with 8GB sd card (4GB is OK?) I don’t experience your problem. in 9front distribution we can also have 9pif, compile is required though. I have compiled but not tried yet. > /dev/keymap probably /dev/kbmap > 9fs sources works for me Kenji Arisawa > 2016/01/01 20:54、Francois Pussault のメール： > > hello all > > where can i get a iso file for 9front or plan9 for raspberry pi > > > I have the bell-labs./contrib/miller one but it is all > stuck/restricted. even writting to /dev/keymap is impossible... > neither mounting 9fs sources and so on.just unusable at all no inst dir > ... etc so it is just a brick > > I ve allready had one about one year ago that permitted to call inst/textonly > to have a real plan9 station on the RPI fullfeatured and fonctionnal... > > do you have a link that or simillar iso file ? > > thanks > > Cordialement > Francois Pussault > 10 chemin de négo saoumos > apt 202 - bat 2 > 31300 Toulouse > +33 6 17 230 820 +33 5 34 365 269 > fpussa...@contactoffice.fr >
[9fans] Install: root file system
Hello, As explained in a previous message, I try to install Plan9 on a new node (previous one defunct). I have tried the usb Bell Labs and 9 atom flavours, and none works on my node. The Bell Labs iso works (I mean it boots and the install starts) but 9pcflop doesn't recognize my disks (while 9load lists them correctly). So I'm back to what I had already done: I sketch a Plan9 partition from NetBSD, setting a bootable FAT and populate it. 9pcdisk recognizes my disk but there is the problem of the root file system---an initial one, so that I can make the install from 9pcdisk and not 9pcflop. I have populated the 9fat with what is indicated in the proto. But there are binaries not in the iso image (bargraph, tailfsrv and a few others). So I have extracted the embedded root.bz2 from 9pcflop (found in bootdisk.img on the ISO) with the help of grep, od (because there are nulls to have the correct offset) and dd. The problem is that this is not only bzip2'ed, but previously bflz'ed. I can even not add the bflz binary to the FAT, since there is no such binary on the ISO. The questions are the following: 1) Is it possible to specify as bootargs the 9fat as the root filesystem? If yes, what is the plan9.ini syntax (I tried local!#S/sdE2/9fat, but this is not it...); 2) Is it possible to give the root.bz2 as a filesystem to a vanilla kernel (here 9pcdisk)? Does it have the code to load it in memory, or can I cat 9pcdisk with the root.bz2 (with the sentry "bzfilesystem") like what is done with 9pcflop? 3) Can such a root file be served, if nothing local work, as a root file system for a DHCP request? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Install problem: disks not listed
On Fri, Jan 01, 2016 at 01:25:20PM +0100, tlaro...@polynum.com wrote: > > I have a new node and I'm trying to install Plan9 on it (it is a > multiboot node, with already NetBSD and Windows). > > When booting (from Bell Labs' iso), the disks are found as sdE[12], the > CD driver as sdE0 that are all on SATA. > Replying to myself: sdiahci is commented out in pcflop, hence the AHCI SATA are inaccessible from 9pcflop. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] mDNS
On Sat Jan 2 01:31:36 PST 2016, st...@quintile.net wrote: > > , > > I am confused, are you talking of replacing the interface to dns(1)? > > I had no real plan, maybe to just make mDNS accumulate broadcast and > multicast mDNS messages into a virtual file in /lib/ndb format. > > more importantly I really need a publish system, which would be just based off > /lib/ndb/local, just a static spec. > > my target is porting shairport, and maybe Dnla at a later date. that wasn't what i had in mind at all. dns(1) does a whole bunch of things, including. - answering queries via /net/dns - answering queries via udp, and tcp, - maintence of database ndb files - resursive resolution via udp or tcp - caching of results currently these functions are all in ndb/dns, and there isn't even threading. that seems like a hard structure to maintain. - erik
Re: [9fans] Pi updates
On Fri Jan 1 21:15:03 PST 2016, blstu...@bellsouth.net wrote: > On Fri, 1/1/16, erik quanstrom wrote: > > i'm looking @ the gpio interface, and i wonder what the recommended > > technique for sampling a pin might be from a shell script? > > I haven't really used it in shell scripts, but if I were going to do > so, I'd probably write up a little utility to take a hex string and > a bit number and do the 'and' on it. Then feed that with the > result of dd to get exactly one sample from devgpio. On the > other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk) > have some bit-wise operators I'm forgetting, use that. the (atom) aux/number program does do that; none of the others do for fairly fundamental reasons: as awk and hoc are really floating point, and bc and dc are mp, and the mp library has no bit operations. i believe acid can as well, but only with great pain. perhaps just using base 2 for the encoding would make life a lot easer. so 00010 for bit 27 active. with this format there's no limit to the number of bits one could represent. also, mightn't there be some value in presenting the full state of the device to allow it to be restored directly from the status file, so perhaps 3 lines could be added, one each for up/down/float settings? 00010 00010 0 0 might represent bit 27 set, with the pull up resistor active. (perhaps float ≡ (pullup | pulldown) == 0? and could be elimitated. i'm sure a little tinkering with this idea can make it a lot more useful. - erik
Re: [9fans] Pi updates
FWIW, when I was looking at doing a gpio drive I was thinking of something like the following. Devices: #G/gpio/ctl #G/gpio/$pin/ctl #G/gpio/$pin/data #G/gpio/$pin/event ... bing -a '#G' /dev A pin must be configured before use (and only if neither of its data & event file is open). For example: echo 'in rising edge high' > /dev/gpio/10/ctl Syntax reset # reset to default in [async][rising|falling][edge] [high|low] [init $value] [buf $value] out [pullup|pulldown] [init $value] [strength $value] alt [0..5] # pi specific You can use the same syntax to configure multiple pins by writing to /dev/gpio/ctl and appending pin numbers. echo 'out pullup 4 12 17' > /dev/gpio/ctl You can *gang* multiple pins into a single port. For example: echo 'create 100 1 2 5 10' > /dev/gpio/ctl This creates a new "pin" 100 (number must be >= # of physical pins) and creates a new entry in /dev/gpio. This succeeds only if the pins can actually be ganged (this is device dependent). You can now configure the port: echo 'in rising edge low' > /dev/gpio/100/ctl To delete a port echo 'delete 100' > /dev/gpio/ctl All constituent pins revert to their default state. Reading /dev/gpio/N/data returns a sample of the present value. [The following needs more work] Reading /dev/pio/N/event blocks the caller until something changes. Returns value and timestamp (in case of "async" inputs, events are handled in the interrupt handler and buffered). Random notes: An "in" pin has an init value since some pins can be bidirectional. "alt" may create other devices as a side-effect such as SPI, I2C, I2S, PWM, UART etc. Configs are sticky and persist across device opens, which is why there is a "reset" command. While this may be easy to use, its implementation would be somewhat complex Ideally one would break this into a small core kernel mode driver and a fancier user mode one for configuring. I stopped at this point for various reasons and never got back to it. On Sat, 02 Jan 2016 10:06:31 PST erik quanstrom wrote: > On Fri Jan 1 21:15:03 PST 2016, blstu...@bellsouth.net wrote: > > On Fri, 1/1/16, erik quanstrom wrote: > > > i'm looking @ the gpio interface, and i wonder what the recommended > > > technique for sampling a pin might be from a shell script? > > > > I haven't really used it in shell scripts, but if I were going to do > > so, I'd probably write up a little utility to take a hex string and > > a bit number and do the 'and' on it. Then feed that with the > > result of dd to get exactly one sample from devgpio. On the > > other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk) > > have some bit-wise operators I'm forgetting, use that. > > the (atom) aux/number program does do that; none of the others do > for fairly fundamental reasons: as awk and hoc are really floating > point, and bc and dc are mp, and the mp library has no bit operations. > i believe acid can as well, but only with great pain. > > perhaps just using base 2 for the encoding would make life a lot easer. so > > 00010 > > for bit 27 active. with this format there's no limit to the number of bits > one could represent. > > also, mightn't there be some value in presenting the full state of the device > to allow it to be restored directly from the status file, so perhaps 3 lines > could be added, one each for up/down/float settings? > > 00010 > 00010 > 0 > 0 > > might represent bit 27 set, with the pull up resistor active. (perhaps > float =E2=89=A1 (pullup | pulldown) =3D=3D 0? and could be elimitated. > > i'm sure a little tinkering with this idea can make it a lot more useful. > > - erik
Re: [9fans] Install: root file system
i'm not sure what the root cause of your problem is, due to not enough data, but it does remind me of a limitation that has been bugging me. to boot from usb cleanly, i added a bit to the boot process that creates a loopback sd device /dev/sdu0 that points to the usb disk device. i've been booting my auth server this way for some time. it seems to me that i really screwed this up. what i really want is a sd device that always points to the boot drive, the one bios refers to as 0x80. givem this, one can then put something like "bootargs=local!#S/sdB0/fs" in plan9.ini. this will allow the 9atom usb install image to run off any bootable media (for which we have drivers). so, i'm preparing a patch that will present the boot device as /dev/sdB0 regardless of what underlying disk driver or protocol is being used. here's the output from my test machine. it's been booted over the network, but even so bios has assigned a 0x80 drive, and it's been found and configured: >> sdB loop #S/sdF0/data sdE ahci ahci port 0xfe00fb538000 pci 0.17.4: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 8002 isr 0 pi f 0-3 ver 10300 sdF ahci ahci port 0xfe00fb532000 pci 0.31.2: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 8002 isr 0 pi 3f 0-5 ver 10300 sdN nvme port 0xfe00fb41 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 stride 1 to 2 fatal 0 sdO nvme port 0xfe00fb30 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 stride 1 to 3 fatal 0 - erik
[9fans] rpi emmc
in diffing bls' version and sources, i see some significant differences, but
it's not clear which one is more up-to-date.
anyone?
- erik
; 9diff emmc.c
/n/sources/plan9/sys/src/9/bcm/emmc.c:178,184 - emmc.c:178,188
static int
datadone(void*)
{
- return emmc.datadone;
+ int i;
+
+ u32int *r = (u32int*)EMMCREGS;
+ i = r[Interrupt];
+ return i & (Datadone|Err);
}
static int
/n/sources/plan9/sys/src/9/bcm/emmc.c:310,318 - emmc.c:314,322
if((c & Respmask) == Resp48busy){
WR(Irpten, Datadone|Err);
tsleep(&emmc.r, datadone, 0, 3000);
- i = emmc.datadone;
- emmc.datadone = 0;
WR(Irpten, 0);
+ emmc.datadone = 0;
+ i = r[Interrupt];
if((i & Datadone) == 0)
print("emmcio: no Datadone after CMD%d\n", cmd);
if(i & Err)
/n/sources/plan9/sys/src/9/bcm/emmc.c:380,390 - emmc.c:384,396
&r[Data], buf, len);
if(dmawait(DmaChanEmmc) < 0)
error(Eio);
+ if(!write)
+ cachedinvse(buf, len);
WR(Irpten, Datadone|Err);
tsleep(&emmc.r, datadone, 0, 3000);
- i = emmc.datadone;
- emmc.datadone = 0;
WR(Irpten, 0);
+ emmc.datadone = 0;
+ i = r[Interrupt];
if((i & Datadone) == 0){
print("emmcio: %d timeout intr %ux stat %ux\n",
write, i, r[Status]);
/n/sources/plan9/sys/src/9/bcm/emmc.c:407,419 - emmc.c:413,423
mmcinterrupt(Ureg*, void*)
{
u32int *r;
- int i;
-
r = (u32int*)EMMCREGS;
- i = r[Interrupt];
- r[Interrupt] = i & (Datadone|Err);
- emmc.datadone = i;
- wakeup(&emmc.r);
+ if(r[Interrupt]&(Datadone|Err)){
+ WR(Irpten, 0);
+ wakeup(&emmc.r);
+ }
}
SDio sdio = {
Re: [9fans] using tls-psk cipher suits vs roll our own handshake
> I could never work up much enthusiasm for TLS because it is needlessly big > and complex, but still got important things wrong. > I never saw the advantage of TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA as opposed > to exchanging a few bits of text, > allowing easy extension of the protocol to the occasional new protocol. if you dont want negotiation, then we need to come up with new default encryption scheme that will work perfectly for a long time. i cannot promise that. with negotiation, stuff will get more complex but at least we can fix and upgrade one machine at a time and get the best possible option for each conversation. what would you do? -- cinap
Re: [9fans] rpi emmc
> in diffing bls' version and sources, i see some significant
> differences, but it's not clear which one is more up-to-date.
Brian Stuart's version is more up-to-date.
Brian Stuart based his changes on the latest changes from Richard Miller,
available in /n/sources/contrib/miller/9/bcm.
term% ape/diff -Nru /n/sources/plan9/sys/src/9/bcm/emmc.c
/n/sources/contrib/miller/9/bcm/emmc.c
--- /n/sources/plan9/sys/src/9/bcm/emmc.c Tue Jan 29 22:07:37 2013
+++ /n/sources/contrib/miller/9/bcm/emmc.c Wed Mar 11 12:23:33 2015
@@ -178,7 +178,11 @@
static int
datadone(void*)
{
- return emmc.datadone;
+ int i;
+
+ u32int *r = (u32int*)EMMCREGS;
+ i = r[Interrupt];
+ return i & (Datadone|Err);
}
static int
@@ -310,9 +314,9 @@
if((c & Respmask) == Resp48busy){
WR(Irpten, Datadone|Err);
tsleep(&emmc.r, datadone, 0, 3000);
- i = emmc.datadone;
- emmc.datadone = 0;
WR(Irpten, 0);
+ emmc.datadone = 0;
+ i = r[Interrupt];
if((i & Datadone) == 0)
print("emmcio: no Datadone after CMD%d\n", cmd);
if(i & Err)
@@ -380,11 +384,13 @@
&r[Data], buf, len);
if(dmawait(DmaChanEmmc) < 0)
error(Eio);
+ if(!write)
+ cachedinvse(buf, len);
WR(Irpten, Datadone|Err);
tsleep(&emmc.r, datadone, 0, 3000);
- i = emmc.datadone;
- emmc.datadone = 0;
WR(Irpten, 0);
+ emmc.datadone = 0;
+ i = r[Interrupt];
if((i & Datadone) == 0){
print("emmcio: %d timeout intr %ux stat %ux\n",
write, i, r[Status]);
@@ -407,13 +413,11 @@
mmcinterrupt(Ureg*, void*)
{
u32int *r;
- int i;
-
r = (u32int*)EMMCREGS;
- i = r[Interrupt];
- r[Interrupt] = i & (Datadone|Err);
- emmc.datadone = i;
- wakeup(&emmc.r);
+ if(r[Interrupt]&(Datadone|Err)){
+ WR(Irpten, 0);
+ wakeup(&emmc.r);
+ }
}
SDio sdio = {
--
David du Colombier
Re: [9fans] rpi emmc
On Sat, 1/2/16, David du Colombier <0in...@gmail.com> wrote: > > in diffing bls' version and sources, i see some significant > > differences, but it's not clear which one is more up-to-date. > > Brian Stuart's version is more up-to-date. > > Brian Stuart based his changes on the latest changes from Richard > Miller, available in /n/sources/contrib/miller/9/bcm. I'm pretty sure that file is unchanged from Richard's latest version on contrib. BLS
Re: [9fans] rpi emmc
> I'm pretty sure that file is unchanged from Richard's latest version > on contrib. Yes, it is unchanged. -- David du Colombier
Re: [9fans] rpi emmc
On Sat Jan 2 21:23:12 PST 2016, blstu...@bellsouth.net wrote: > On Sat, 1/2/16, David du Colombier <0in...@gmail.com> wrote: > > > in diffing bls' version and sources, i see some significant > > > differences, but it's not clear which one is more up-to-date. > > > > Brian Stuart's version is more up-to-date. > > > > Brian Stuart based his changes on the latest changes from Richard > > Miller, available in /n/sources/contrib/miller/9/bcm. > > I'm pretty sure that file is unchanged from Richard's latest version > on contrib. ok. i got confused with all the versions floating around. - erik
