Re: [9fans] VCS on Plan9
One thing i did was sometimes to create a skeletron directory tree and bind *before* each single directory in /sys/src/9. when i needed to modify a file, you copy it in your "overlay" tree. not exactly version control, but a primitive way to prepare a change. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Mff38b7f62f2352e3fcb7d0b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9front nvram setup
> It was that nvrlen setting. Apparently that needs to be something like 256 > or it gets mad. It didnt like 0. all right! good catch :D iirc these are optional, i usually just set nvram= and nothing else. nvr is fixed size anyway. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M09cc8d488b6c432d2308165f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9front nvram setup
> I am setting up a CPU server on 9front, and have been getting the following > errors that I just can't seem to work around. > can't write to nvram: i/o error > I have set my nvram in plan9.ini to > nvram=#S/sdE2/nvram > nvroff=0 > nvrlen=0 You can break into rc shell at the bootargs prompt by typing !rc then you can inspect the state of the sata drive. cd /dev/sdE2 ls cat ctl Check if the nvram partition is here. I'm curious as it complains only on write? -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M35df4b4e9c81c47f5598053d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VMX Cores
for the kernel part, a devvmx vm *IS* a core basically and the physical memory that core sees is passed as a segment to the device. so having multiple cpu support should be fine without having even to change the kernel part, you just have multiple vmx instances share a memory segment. however, to be practical, you'd need to add emulation code for the apic interrupt controller as well provide acpi or mp tables... reason is a core is started with a inter processor interrupt thru the apic. the kernel discoveres the apics thru eigther MP tables or ACPI tables. and the processor comes up in real-mode, which might have some limitations in what hardware will emulate for us so a interpreter might be needed. (tho i'm not fully sure on this) (note, right now vmx has no BIOS and it implements each OS bootloader itself so it starts executing the kernel in 32 bit mode directly). i dont see vmx causing kernel crashes for me. however, i think the author meant to express is lack of confidence in the air-tightiness of vmx giving the zillions of architectual registers you have to setup to contain a guest. it is easy to forget to set some bit and everything works until someone manages to exploit that. patches welcome. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc08115552282a0a2-M6ac623797c50743cf9de92ad Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9front: fossil broken in Humanbiologics rel.
i tried it, downloading 9legacy, compiling fossil and using the following script from ori to format a fossil file-system: ori → http://okturing.com/src/17908/body <-- there's the script and fossil successfully starts up and is mounted: term% cat fossiltest.rc #!/bin/rc fossil/flfmt $1 fossil/conf -w $1 < /tmp/test.fossil 100+0 records in 100+0 records out term% ./fossiltest.rc /tmp/test.fossil fs file is mounted via devmnt (is not a kernel device); are you sure? [y/n]: y fsys: dialing venti at net!$venti!venti warning: connecting to venti: cs: file does not exist: '/lib/ndb/dnschallenge.ip' nuser 5 len 84 term% ls /n/fossil /n/fossil/adm term% du -a /n/fossil 1 /n/fossil/adm/users 1 /n/fossil/adm 1 /n/fossil -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tac8d983292c826c1-M5faadbe20043e8e93b23e61e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9front: fossil broken in Humanbiologics rel.
does the old kernel with fossil binary still work? -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tac8d983292c826c1-Me0f499bebe92c1d19ddb6066 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] drawterm problems after susupdate
I think it would be better to direct 9front specific questions
to the 9front mailinglist unless you understand the scope
well enougth that it might as well apply to plan9 in general.
Anyway here you go (yes, this is 9front specific answer):
This is likely due to the removal of devssl from the kernel.
The cpu (and import) porotocols have been removed from 9front
for a while now (but the binaries would still remain on your
file-system) and replaced by rcpu(1), which uses devtls.
The cpu/import programs where the only ones still using devssl.
A drawterm exist that is maintained and supports both the
previous cpu as well as the new rcpu protocols.
https://git.9front.org/plan9front/drawterm/HEAD/info.html
The new rcpu service (also handling rimport/rexport and rx)
has the following listen script: /rc/bin/service/tcp17019
#!/bin/rc
if(~ $#* 3){
netdir=$3
remote=$2!`{cat $3/remote}
}
fn server {
~ $#remote 0 || echo -n $netdir $remote >/proc/$pid/args
rm -f /env/'fn#server'
. <{n=`{read} && ! ~ $#n 0 && read -c $n} >[2=1]
}
exec tlssrv -a /bin/rc -c server
I fear a bit that given you where still be using cpu protocol
with an old drawterm that you probably havnt even upgraded your
authentication server to the new dp9ik key as well.
P9sk1 is still supported in 9front (factotum and authserver),
but has long been disabled in the authserver listen script by
default (passing -N to auth/authsrv).
So please make sure you have set a new key as well as have the
-N flag passed in /rc/bin/service.aith/tcp567 like:
#!/bin/rc
exec /bin/auth/authsrv -N $3
--
cinap
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Te0c7fa564759b89c-Mc8862432d943dea5b65423b9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] the practicality of plan 9
https://felloff.net/usr/cinap_lenrek/wircrc -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6c4be6d8502dbd0-M342927299fb96dc37f06043b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
i dont really get your problem. my understanding is that the idea of the gpl is that if you derive work from a gpl licensed project is that that change will also be under gpl and you make the sourcecode available. no? whenever we bugfix something in ghostscript, that change will also be under gpl. and you make the source available for that change. on the other hand, calling the ghostscript interpreter as a external program, i dont think that would force your program kiosk to be gpl licensed (for example page(1) would be in the same situation... it calls all kinds of external image converters, including ghostscript). so why not just have the source of everything available? for me, your project isnt any different from a specialized plan9 distribution, consisting of a mix of differently licensed projects, including your kisok program. as long as you provide the source to the gpl components (or just everything, much easier) you should be fine, no? -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M73f4a2cc39790881812134c4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] building blocks speaking 9p
> Ok, sorry for the triple-post, but since I can't seem to find that man > page or usb/ether on my 9front install, I should probably provide my source: /sys/src/cmd/nusb/ether/ -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mebc09381f92048e13648c6bb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
RE: [9fans] Unable to load page in Abaco
of course, DNSSERVER= is consumed by ndb/dns, not webfs. passing it before webfs has no effect. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1be0869af45e66b9-M5422f56ea07e94b9bf92cbd5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
sdvirtio handles both block and scsi type devices. -- cianp -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-Mbd3ba5c81eb0397f27674ee2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
could it be that it is using virtio1.0? see pc/sdvirtio10.c /* * virtio 1.0 disk driver * http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html * * In contrast to sdvirtio.c, this driver handles the non-legacy * interface for virtio disk which uses mmio for all register accesses * and requires a laborate pci capability structure dance to get working. * * It is kind of pointless as it is most likely slower than * port i/o (harder to emulate on the pc platform). * * The reason why this driver is needed it is that vultr set the * disable-legacy=on option in the -device parameter for qemu * on their hypervisor. */ -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-Me558f02595a3f17cf54ed39e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] more devtls bugs
https://git.9front.org/plan9front/plan9front/a4c1f3cc18df6fddd548f4df9f209695c4eb7263/commit.html -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta091580c163a19c7-M316281ed1d5312d529154e64 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] devtls memory leak bug
just tracked down kernel memory leak in devtls, might be of interested to other forks: http://git.9front.org/plan9front/plan9front/1cff923af4dbcaaab515cc04ea40c559eab7830f/commit.html -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1607df5b216c4983-M87f406ba2a054291d48b9e12 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
> I can't think how Plan 9 would work as a server (as in, the machine > with the mouse plugged in) for this (either for Synergy or an > invented-here thing). /dev/mouse doesn't emit when you're off the > screen. Maybe this is even the reason cinap never did a server, only > a client. doesnt matter, you can run like a filter on /dev/mouse before starting rio... -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M2ea5a7fd524a4bf3b4851b54 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mkfs
> The easiest solution is to remove kfs support and just extract > protoenum() from copyfile(). thats what we did in 9front (just so you dont need to do it all over again in case you commit to that approach). -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te2c67c4bc489fa54-M72d3e7059f5ddf806c37d8cc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Foundation new releases question
> Yep. I might be able to understand that change, but less so the later > breaking change to 9p auth. What 9p change for auth are you talking about? The dp9ik implementation in 9front just uses p9any to negotiate it and p9sk1 is still supported; tho by default we have p9sk1 disabled at the authentication server now to prevent the offline dictionary attack on the DES encrypted tickets that p9sk1 uses (tho it can be enabled by a flag in the authservers startup script). The code changes to have both auth protocols work concurrently was actually the thing that took the most work and it took over a year of transition period until we could disable p9sk1 by default. I'm not aware of anyone changing 9p. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc472e4a0c0b6f084-M611da16b4751d70c9cefd61d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] NFS suicide on RPi3 and RPi4 9front, but works on RMiller's Plan9.
> > Anyawys, the faulting address is > >addr=0x100061fa0 pc=37930 sorry to reply here as i never got the original mail. i could reproduce this and it turns out to be a arm64 compiler bug expanding the -1 offset in the array index to a 32 bit unsigned constant but instruction issued is a 64 bit addition. i commited a work around for libsunrpc avoiding this case. changeset: 8382:fbff57e70e76 tag: tip user:cinap_len...@felloff.net date:Mon Mar 29 17:13:50 2021 +0200 summary: libsunrpc: work around arm64 compiler bug in sunStringUnpack() diff -r 87d8e72ffb5c -r fbff57e70e76 sys/src/libsunrpc/rpc.c --- a/sys/src/libsunrpc/rpc.c Tue Mar 23 16:33:32 2021 -0700 +++ b/sys/src/libsunrpc/rpc.c Mon Mar 29 17:13:50 2021 +0200 @@ -428,8 +428,9 @@ goto Err; /* slide string down over length to make room for NUL */ memmove(dat-1, dat, n); - dat[-1+n] = 0; - *s = (char*)(dat-1); + dat--; + dat[n] = 0; + *s = (char*)dat; return 0; Err: return -1; -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T995ec2230d16bd0b-M7a648db117dd9b3b65e26b9b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] qemu sound, only one side/speaker working
just tested with QEMU 5.1.0 (v5.1.0-11824-g8699890d91-dirty) under windows 10. it works just fine for me. i doubt this is a bug in the hda driver. the left and right channels are submitted as one stream. the fix of last year was about command completions requiering the interrupt driven method in qemu, while the driver was just implementing a simple polling scheme. so i suspect it to be a problem with your specific qemu version or pulseaudio. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T17c9d28c18e0a4cf-M0d40be11db52d63990a00a81 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9front kernel panic on bootstrap on rpi
yes, this is a known issue in this release and it has already been fixed here: https://code.9front.org/hg/plan9front/rev/cc5c37116d5e i did not have the time to schedule a new binary release. if you want you can try the "unofficial" kernels linked below and copy them on the sdcard. raw kenrel: http://felloff.net/usr/cinap_lenrek/9pi a.out with symbols: http://felloff.net/usr/cinap_lenrek/s9pi or you can build them yourself on any 9front installation following the fqa instructions, which basically buils down to: objtype=arm mk install in /sys/src and mk: 'CONF=pi' in /sys/src/9/bcm good luck. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td646dc8a14a94c8a-Mfa9fc31011fe6662abb3e3e8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] libdate
in the Tmd struct: >vlongabs; /* seconds since Jan 1 1970, GMT */ in the description of tmtime(): > Tmtime converts the millisecond-resolution timestamp 'abs' > into a Tm struct in the requested timezone. the example: > if(tmtime(, here.abs, zp) == nil) should Tmd.abs not be documented as milliseconds instead of seconds? -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5b9f56a5fac852c2-M26d9ae5c62cd81e9faa187d1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Git and heritage (Was: Software preservation in the post-hg era)
> I've attached the two patch sets, I make no claim to being a great
> coder, the focus was to make the changes (a) as clear as possible, (b)
> as unintrusive as possible.
- if(port == nil){
- port = "ssh";
- s = strchr(host, ':');
- if(s != nil){
- *s = '\0';
- port = s+1;
- }
- }
this breaks for ipv6 addresses. i'd suggest you at least check for ] first
and then look for the colon. example: "[::1]:22".
then the big question is what should be put in the thumb file to identify
the host, if you start messing with the network addresses. there can be
different ssh servers per port. for example: gerrit.
--
cinap
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T0cc6edbc13d3e92c-M7f81cd380693f5bdc8956d42
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> But where I only partially agree is where Plan 9 concepts contradict > what may be "common practice". A URL is a well defined object and > adopting it as a standard, as quite a few services have done (I'm > thinking PostgreSQL and OpenLDAP, for example) rather than pursue the > '!' convention seems worth it. i find plan9 dialstrings much easier to deal with than urls that have all kinds of escapes and encodings depending on which part in the url stuff appears in. they carry alot of baggage arround. urls might appear in ASCII context, then you need to punicode the domain name if it happens to contain non-ascii characters while plan9 dial strings are guaranteed to work consistently. the resolution process is done by ndb/cs and it can accept unicode just fine. plus picking the "!" as a separator works with ipv6 while using ":" needs v6 literal escapes like: [2001:1:2:3:4::]:22 this was a huge mistake. in plan9 we are lucky not to be affected by this too much and we can handle these things without much pain and without touching every program. dialstrings also let you pick the protocol and also the ip stack to use. programs that do not accept dialstrings sabotage a usefull plan9 capability and break consistency. i'm pretty sure the original plan9 ssh1/ssh2 also accept dial strings just fine. thats just like, my opinion, man. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M48e08819ec859259f6714dcf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
> user@host:port is not a valid syntax in openssh, and neither in plan9. it has to be handled by the code that parses the *URL* and converts it into ssh arguments with a dialstring. ssh does not know anything about URL's. > user@host syntax is certainly useful, but i think that's already there. correct. by using netmkaddr() so proto and port are optional. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M1f9edac6b1b687291a00932d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Newbie Question
ok, never mind. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-M2425616a037a16c94ec7afd1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Newbie Question
makes sense. you need to configure the fileserver to listen on the network by specifying bootargs on the fs like: local!/dev/sdXX/fscache -a tcp!*!564 you can verify this with the netstat command on the fs console looking for 9fs service in Listen state. or use "tcp" instead of "tls" on the netbooting client's bootargs. tls is handled by a helper service that terminates the tls connection and relays the paintext to its fileserver. if that fileserver is not listening for network connections that it will fail like this. it is probably a good idea to put fs= and auth= attributes in your ndb ipnet entry, so you do not need to specify this information in plan9.ini and dhcpd will supply this information to the client. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mfb338473b81d385622c100d7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Newbie Question
i believe that this is due to running a with service=terminal. this causes factotum to be started as a client with no keys in it. the p9any auth protocol starts by the server presenting a set of keys, auth domains and protocols, which you wont have in this case (no keys there). which is most likely the reason the whole thing fails. if you boot your fileserver with service=cpu, then when factotum starts it will prompt you for authid and password which will be the credentials of the hostowner (of the fileserver) which should have to match what you have on the authentication server. this information can be stored in nvram to avoid the prompt on boot. even if it doesnt match the auth key for (that user) on the authserver, the fileserver should be able to boot and mount its root filesystem as factotum talks to itself in this scenario and having the same keys on both sides. its just about to fail when there are no keys at all. i hope this makes sense. -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mb737a8ba8068f0aae3e426d0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] banishment of nuisance IP addresses
seems tricky with listeners that run as none, no? so your banish files would need to be world writable in this case, no? that means everyone can just lock you out of your box by writing a line there... -- cinap -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te00ed62cf5d85d9e-M71fd0fcdfeb1568ca1a2d4a3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] raspberry pi 4 arm64 test image
made new image and kernels if anyone wants to test. http://gabe.felloff.net/usr/cinap_lenrek/9front-7341.7789bbc91c22.pi3.img.gz http://gabe.felloff.net/usr/cinap_lenrek/9pi3 http://gabe.felloff.net/usr/cinap_lenrek/9pi4 sha1sums: 1b493439cbdff6aa6e0403cc0bda158841ebac40 9front-7341.7789bbc91c22.pi3.img.gz b5e199a9ee2890929e096b29b6310bc12bbe00a89pi3 abc4a73cdffb5d1e0ddc4d86a20b5f2f0509ced09pi4 -- cinap
Re: [9fans] raspberry pi 4 arm64 test image
new kernel that should be able to deal with the two regions: http://felloff.net/usr/cinap_lenrek/9pi4 sha1sum: 0222a824ec04c672955560ea120fa4d8de848e79 -- cinap
Re: [9fans] raspberry pi 4 arm64 test image
> The device tree has two entries. > > offset:0 > lenght:0x3c40 > > offset:0x4000 > length:0xbc00 excellent! that explains it. -- cinap
Re: [9fans] raspberry pi 4 arm64 test image
> The firmware on a pi4 with 2GB or 4GB RAM will only report 1GB. > I believe you need to look at the board id (or probe for invalid > addresses as in the teg2 kernel) to find out the real amount. oh dear. i dont even know the expected physical memory map... i guess that ram is continuous block at [0-0xfc00). but some memory might be reserved... on what method does it report only 1GB? i know of 3 methods so far: - atags - device tree /memory/reg property - firmware property request (getramsize() in vcore.c) for me getramsize() returns zero for both base and limit so its completely useless. i'm currently using device tree method, but the code assumes that there is a single block entry. lets see if that lies as well with the debug kernel. -- cinap
Re: [9fans] raspberry pi 4 arm64 test image
ok, i prepared a kernel with debug prints. (i basically buffer the debug outputs in kmesg and dump them on the serial console and screen once they get initialized). http://felloff.net/usr/cinap_lenrek/9pi4 i suspect that the device tree /memory/reg property might not be a single 12 byte entry. and thats why theres no *maxmem variable in #ec. i also added some prints to fbinit() just to make sure... on my pi4, i get: /memory/reg[12]: 3E60 confinit: *maxmem=0x3e60 confinit: memsize=0x3e60 confinit: getramsize() => confinit: mem[0] => 3e60 127 holes free 0x0067 0x1931 415891456 415891456 bytes free fbinit: 1280x1024x16 fbinit: base=fed7b000 fbinit: va=1ed7b000 Plan 9 ... -- cinap
Re: [9fans] raspberry pi 4 arm64 test image
thank you! i believe its just starting rio so you dont get any more output. interestingly, the framebuffer was set up without error as far as the kernel is concerned. otherwise we would get an error when trying to attach devdraw. on the bootargs prompt, enter: !rc then on the rc shell: cat '#ec/*maxmem' that should be the end of ram that the loader passes to us in the device tree. i'll prepare a kernel that you can copy into the sdcard image with more debug output... -- cinap
[9fans] raspberry pi 4 arm64 test image
i'v made a sdcard image for the new raspberry pi 4 (also works on 3). http://gabe.felloff.net/usr/cinap_lenrek/9front-7336.bb28fe19fe44.pi3.img.gz this has support for most of the new hardware: sdcard, ethernet and usb3.0 can someone please test this on the 2GB and 4GB ram variants for me? -- cinap
Re: [9fans] Trying to make 9front work on QWERTZ
on my t23, which has physical german keyboard layout, the scancode
for the [<>|] key left to the [Y] key is 0x56 (86 decimal), which
is not mapped with us layout.
tho this is mapped in german keyboard layout:
term% grep '86' /sys/lib/kbmap/de
0 86 '<
1 86 '>
2 86 0
3 86 '|
4 86 0
running the following on my t23 maps it.
term% echo '0 0x56 ''<' > /dev/kbmap
term% echo '1 0x56 ''>' > /dev/kbmap
term% echo '3 0x56 ''|' > /dev/kbmap
maybe your keyboard produces a different scancode?
you can attach ratrace to kbdfs [scanproc] pid and look what
it reads back from /dev/scancode for a ps2 keyboard.
usb keyboards work differently.
you can bring back that scancode debug thing with F11/F12
with the following patch which should work for both ps2 and usb
keyboards.
--- a/sys/src/cmd/aux/kbdfs/kbdfs.c Thu Jul 25 17:44:47 2019 +0200
+++ b/sys/src/cmd/aux/kbdfs/kbdfs.c Sat Jul 27 11:12:20 2019 +0200
@@ -43,6 +43,7 @@
int alt;
int altgr;
int leds;
+ int debug;
};
struct Qtab {
@@ -337,6 +338,9 @@
{
Key key;
+ if(scan->debug)
+ fprint(2, "kbdputsc %#p sc %x esc1 %d esc2 %d\n", scan, c,
scan->esc1, scan->esc2);
+
/*
* e0's is the first of a 2 character sequence, e1 and e2 the first
* of a 3 character sequence (on the safari)
@@ -390,6 +394,13 @@
if(scan->ctl && scan->alt && key.r == Kdel)
reboot();
+ if(key.down){
+ if(key.b == (KF|11))
+ scan->debug = 1;
+ if(key.b == (KF|12))
+ scan->debug = 0;
+ }
+
if(key.b)
send(keychan, );
after applying that change, run mk install in /sys/src/cmd/aux/kbdfs
and then rebuild the kernel (as kbdfs gets included into the kernel image).
--
cinap
Re: [9fans] Plan 9 C compiler for Xtensa CPUs
nope. charles is your man. -- cinap
Re: [9fans] Raspberry Pi 4
arrg! and i forgot the clean BEFORE the issuing dma. -- cinap
Re: [9fans] Raspberry Pi 4
> Your dmaflush code doesn't look to me like it will do the right > thing if the dma buffer isn't cache aligned. (Could this ever be > the case in the 9front kernel?) Suppose dma starts, cpu prefetches > some old data into the cache line overlapping the start of the dma > buffer, then dma completes. > Your dmaflush then calls cachedwbse which writes back the pre-fetched > data, overwriting the new data which dma wrote to memory. what? where? it should call dmaflush with the clean parameter set to zero after the hardware has completed the dma: dma.c:228: dmaflush(0, ctlr->flush, ctlr->len); dmaflush() then calls cachedwbinvse() on the partial cache lines which should just invalidate IFF the lines are clean. the write back should only happen when the lines are dirty. in that case the damage has already been done and the wb at least makes sure we wont loose the dirty data from the cache. so the underlying assumption here is that a cache clean operation writes back only when the line is dirty. correct me if i'm wrong here. so yes, it will not work correctly for an invalidate when the buffer is not cache line size aligned and the partial start or end gets modified while the dma operation is in flight. -- cinap
Re: [9fans] Raspberry Pi 4
> Thanks, I'll take a look at this. Have you seen any pi4 h/w docs > or have you been working just from linux drivers? no, i wish. only reading linux source and deciphering device tree mazes. :( > I've been stalled on getting ether4330 to initialise. Putting > some coherence() calls into emmc.c helped (I don't like > out-of-order cpus) but I keep getting spurious interrupt 1023 > followed by watchdog reboot. i dont know anything about the 4330. i think theres a bug with the dma code tho. you actually need to invalidate caches *AFTER* the hw completed because the core can speculatively prefetch memory and bring it into the cache before the hardware is done writing memory. iirc the code just cleans/invalidates BEFORE issuing the dma operation. > Do you have the sdcard working? According to a pi engineer, > the new emmc controller is sdhci compliant so it shouldn't > be hard. i have not tried sdcard yet. -- cinap
Re: [9fans] Raspberry Pi 4
i just commited everything i got for the raspberry pi 4. sorry that this took so long. i was trying to get the ethernet reliable but this has some bizzare issue that i was unable to resolve. http://code.9front.org/hg/plan9front/rev/889b634159e5 http://code.9front.org/hg/plan9front/rev/55d93e47a2de http://code.9front.org/hg/plan9front/rev/686cdda01118 http://code.9front.org/hg/plan9front/rev/4dbf2522f668 http://code.9front.org/hg/plan9front/rev/db3e8d004b27 http://code.9front.org/hg/plan9front/rev/5afd2605d0f3 http://code.9front.org/hg/plan9front/rev/6e8b95bccec4 http://code.9front.org/hg/plan9front/rev/234f51ace8cd http://code.9front.org/hg/plan9front/rev/406bef7018a8 http://code.9front.org/hg/plan9front/rev/386fe43162b4 http://code.9front.org/hg/plan9front/rev/f3966b67adc9 note, this is a arm64 kernel, but the drivers should be portable. - interrupts, uart, multicore, graphics and /dev/reboot works - pcie and xhci works - genet works somewhat (good enougth for /dev/reboot netbooting) but causes bizzare 42 second bus stalls with bursty bidirectional ethernet traffic which hangs all gisb devices (pcie/xhci) i'll write you the details and what i tried about that ethernet issue offlist, maybe we can figure this out together. -- cinap
Re: [9fans] Someone made a Wayland compositor based on Rio, Wio
> (Incidentally, does 9ants support Go as robustly as 9legacy does? Go > is critical to my work and so is SSH - sshnet, was it, that provided > port forwarding? That's another critical feature, so may be OpenVPN, > but so far that has been too slow on Linux, so it's not a priority.) recently resurrected sshnet(4). yes, it supports listening connections now. openvpn is an absolute kitchensink of options, while still not doing very much for you. however, theres a native tinc vpn client (see http://tinc-vpn.org ) i use it to get ipv6 and fixed ipv4 addresses to my home network from a server, as residential isp's here are unable to offer full internet service. -- cinap
Re: [9fans] Someone made a Wayland compositor based on Rio, Wio
type !rc at the bootargs prompt to get a shell, then run: grep '^02' '#$/pci/'*ctl which prints the pci information for all network cards. that should get us closer to why the probing code fails. -- cinap
Re: [9fans] Someone made a Wayland compositor based on Rio, Wio
> Next plan9.ini's "rootdir". It is no longer documented in > plan9.ini(8), but the little code that uses it in bootrc is odd as > well as at odds with the legacy documentation. yes! we got it all wrong! it all makes sense in the /lib/namespace what should happen, but bootrc does it wrong. > My hope was to give it "9front" as a value and have Fossil serve > that as the root for a diskless 9front workstation, as in > bind -b $rootdir / > Instead, I find "mount -c /srv/boot $rootdir" which is definitely not > it. you are absolutely correct. this is wrong. here is the fix: http://code.9front.org/hg/plan9front/rev/1209e04a3af9 > I'm not sure under what circumstances one target a different > location for the ROOT directory, I would be interested to hear. Of > course, this conflict needs to be resolved. > This is starting to get interesting. yeah. thank you very much! :-) > Lucio. -- cinap
Re: [9fans] Someone made a Wayland compositor based on Rio, Wio
> I have a fun issue where 9front resolution depends on EFI boot method. Via > firmware interface, I get 1600x900 but via bootloader (EFI file copied to > esp) I get low resolution. not so surprising. pure EFI without legacy CSP does not have a VESA BIOS. all you get is what the bootloader could figure out about the framebuffer that the firmware set up for us. thats is what we have to work with until you invoke a native driver to set up a proper mode. > I can not set resolution via aux/vga so the resolution at boot is the one > that sticks. what graphics card is this? when its intel, we have a native driver. it might just not know about your specific card yet. > btw: is anyone working on additional WiFi firmware (for example atheros) > support? not that i know of. -- cinap
Re: [9fans] Someone made a Wayland compositor based on Rio, Wio
> It's the 3Com that baffles me. I suspect the two-stage boot (I know > dangerously little about 9front's boot process) somehow fails to pick > up a supported device (3c905b - etherelink3). is this the amd64 kernel or 386 one? the amd64 one does not include the etherelnk3 driver. the reason is that the amd64 kernel shares its drivers with the pc kernel, but not all drivers might be ready for 64 bit pointers. so we only include what we can test and verify. you can try to add the etherelnk3 line to the pc64 config and rebuild. if you have this issue with the 386 kernel, then knowing the pci device id would be a start. the boot process is nothing special. we have a bootloader that loads the kernel. the loader uses BIOS/EFI calls to get the kernel from the boot media so that it does not need drivers. once the kernel is taking over, it needs a driver. -- cinap
Re: [9fans] 9front installer misses /lib/news directory
done. -- cinap
Re: [9fans] Regarding GUID partitioning
its documented in prep(8) -- cinap
Re: [9fans] The lost (9front) boot menus ...
yes, patches are welcome. if you prefer longer timeout, you know what code to change now. -- cinap
Re: [9fans] The lost (9front) boot menus ...
> Given a working fileserver config, I want something that does > 'user=foo; nobootpromt=bar', but with a (say) five second timeout. > This is different from the current scheme that provides an escape, > but which requires manual intervention. What I'm looking for is a > timed-out option from the 'nobootprompt=' config, that lets me > override, but only if I'm right there. > It's the same as how (e.g. FreeBSD) lets you interrupt the boot > process and muck about. But if you don't, it times out and boots > the 'default' configuration. err... thats precisely how it works. the ONLY difference is that the timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 so your plan9.ini is the default config. and you hit any key during that timeout window, you get to the bootloader console where you can edit the plan9.ini variables (in ram). you can remove variables with the clear command, so you can get rid of nobootprompt. its all documented in 9boot(8). -- cinap
Re: [9fans] The lost (9front) boot menus ...
the bootloader has a console where you can change any plan9.ini parameter, including bootfile=. read 9boot(8). if you really want menus in the bootloader, you can also load the kernel directly with some other multiboot capable bootloader. or you start the kernel from another kernel using the reboot!kernelpath!method... on the bootargs prompt. -- cinap
Re: [9fans] 9front dhcpd installer buglet
noted. its missing in the proto file. -- cinap
Re: [9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
typo. illegal register *ADDRESS*. -- cinap
Re: [9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
bit 7 is "illegal register access". try to print the pc from the ureg passed to the first argument in lapicerror() in /sys/src/9/pc/apic.c. -- cinap
Re: [9fans] Git/fs: Possibly Usable
excellent work! thank you! -- cinap
Re: [9fans] cifs buglet - take 2
do you have a recent copy arround somewhere?
theres more stuff that needs merging like:
-from_cache:
fi = (FInfo *)(a->cache + (off - a->off));
npath = smprint("%s/%s", mapfile(a->path), fi->name);
- I2D(d, a->sp, npath, fi);
+ I2D(d, a->sp, npath, realmtime(npath), fi);
--
cinap
Re: [9fans] cifs buglet - take 2
thanks!
> while(got > 0 && strcmp(fi[0].name, ".") == 0 ||
> strcmp(fi[0].name, "..") == 0){
that looks like a bug to me. you ment to write the following instead?
while(got > 0 && (strcmp(fi[0].name, ".") == 0 || strcmp(fi[0].name, "..") ==
0)){
--
cinap
Re: [9fans] [PATCH 1/3] Add swapip read in lookupip()
yeah, rootserver makes much more sense. -- cinap
Re: [9fans] [PATCH 2/3] Send vendor ndb attribute if available
all looks good. except that "swap" is kind of crazy name to mean the nfs server. -- cinap
Re: [9fans] Plan 9 DNS server and dnsflagday
we do not support edns at all. the Topt rr type is just ignored. -- cinap
Re: [9fans] Raspberry Pi 3 B+ image of 9front
oh yeah. sorry. just do this before: bind / /n/src9 i missed this because that step is implied by sys/lib/rootbind that i use when building iso from a separate clean repository. -- cinap
Re: [9fans] Raspberry Pi 3 B+ image of 9front
richard miller did a very fine job with the image. 9front used to have a image to download based on it for the raspi1, but it is quite old and nobody updated it. in the last release, we updated the kernel from richards code and made the /sys/lib/dist/mkfile able to produce a bootable sdcard image with hjfs filesystem. documentation in the fqa is under way. you can build a bootable sdcard image by running: # build arm userspace objtype=arm cd /sys/src mk install # build kernel cd /sys/src/9/bcm # pi1 kernel (optional) mk 'CONF=pi' install # pi2/3 kernel # mk 'CONF=pi2' install (pi2 is default) mk install # download firmware cd /sys/src/boot/bcm mk # build bootable hjfs sdcard image cd /sys/lib/dist mk /tmp/mysdcard.pi.img # copy to sdcard cat /tmp/mysdcard.pi.img > /dev/sdM0/data -- cinap
Re: [9fans] Plan 9 potential target ports (Was: PDP11 (Was: Re: what heavy negativity!))
the complains where about the *HDMI*. which is the work of DRM mafia. displayport at is a standard with available documentation. -- cinap
Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)
> Fundamentally zero-copy requires that the kernel and user process > share the same virtual address space mapped for the given operation. and it is. this doesnt make your point clear. the kernel is always mapped. (you ment 1:1 identity mapping *PHYSICAL* pages to make the lookup cheap?) the difference is that *USER* pages are (unless you use special segments) scattered randomly in physical memory or not even realized and you need to lookup the pages in the virtual page table to get to the physical addresses needed to hand them to the hardware for DMA. now the *INTERESTING* thing is what happens to the original virtual address space that covered the I/O when someone touches into it while the I/O is in flight. so do we cut it out of the TLB's of ALL processes *SHARING* the segment? and then have the pagefault handler wait until the I/O is finished? fuck your go routines... he wants the D. > This can't always be done and the kernel will be forced to perform a > copy anyway. explain *WHEN*, that would be an insight in what you'r trying to explain. > To wit, one of the things I added to the exynos kernel > early on was a 1:1 mapping of the virtual kernel address space such > that something like zero-copy could be possible in the future (it was > also very convenient to limit MMU swaps on the Cortex-A15). That said, > the problem gets harder when you're working on something more general > that can handle the entire address space. In the end, you trade the > complexity/performance hit of MMU management versus making a copy. don't forget the code complexity with dealing with these scattered pages in the *DRIVERS*. > Believe it or not, sometimes copies can be faster, especially on > larger NUMA systems. -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hahahahahahahaha -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
> But the reason I want this is to reduce latency to the first > access, especially for very large files. With read() I have > to wait until the read completes. With mmap() processing can > start much earlier and can be interleaved with background > data fetch or prefetch. With read() a lot more resources > are tied down. If I need random access and don't need to > read all of the data, the application has to do pread(), > pwrite() a lot thus complicating it. With mmap() I can just > map in the whole file and excess reading (beyond what the > app needs) will not be a large fraction. you think doing single 4K page sized reads in the pagefault handler is better than doing precise >4K reads from your application? possibly in a background thread so you can overlap processing with data fetching? the advantage of mmap is not prefetch. its about not to do any I/O when data is already in the *SHARED* buffer cache! which plan9 does not have (except the mntcache, but that is optional and only works for the disk fileservers that maintain ther file qid ver info consistently). its *IS* really a linux thing where all block device i/o goes thru the buffer cache. -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
oh! you wrote a nvme driver TOO? where can i find it? maybe we can share some knowledge. especially regarding some quirks. i dont own hardware myself, so i wrote it using an emulator over a weekend and tested it on a work machine afterwork. http://code.9front.org/hg/plan9front/log/9df9ef969856/sys/src/9/pc/sdnvme.c -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
> To address Hiro's comments, I have no benchmarks on Plan 9, because > the SDR code I run does not exist there. But I do have experience > with running SDR on Linux and FreeBSD with hardware like the HackRF > One. That hardware can easily saturate a USB2 interface/driver on > both of those operating systems. Given my experience with USB on > Plan 9 to date, it's a safe bet that all the variants would die > when presented with that amount of traffic. why? the *HOST CONTROLLER* schedules the data transfers. if the program doesnt do a read() theres nothing to schedule... (unless its isochronous endpoint, in which case the controller dma's for you in the background at the specified sampling rate). > (I can knock down a Plan9 system with 56 Kb/s USB serial traffic.) that sounds seriously scewed up. i have no issues here reading a usb stick on my x230 with xhci at 32MB/s, not using any fancy streaming optimization. no load at all. and this is just some garbage from the supermarket. > I can see about > twisting up some code that would read the raw I/Q data from the SDR > via USB and see how it stands up. But the real question is what > kind of delay, latency, and jitter will there be, getting that raw > I/Q data from the USB interface up to the consuming application? is this a isochronous endpoint? in that case you would not have to worry much as the controller does all the timing for you in hardware. > Eliminating as much of the copy in/out WRT the kernel cannot but > help, especially when you're doing SDR decoding near the radios > using low-powered compute hardware (think Pies and the like). a! we'r talking about some crappy raspi here... probably with all caches disabled... never mind. > --lyndon -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
also, i wonder how much is the actual copy overhead you claim is the issue. maybe the impact for copying is more dominated by the memory allocator used for allocb(). have you measured? -- cinap
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
> The big one is USB. disk/radio->kernel->user-space-usbd->kernel->application. > Four copies. that sounds wrong. usbd is not involved in the data transfer. it mainly is just responsible to enumerating devices and instantiating drivers and registering the endpoints in devusb. after that you access the endpoint files from devusb which goes directly to the kernel. devusb also allows you to create a alias for a endpoint file which then appears directly under /dev. usb audio uses this mechanism. the usb driver just activates the device and provides the ctl/volume files, while audio data is handled by the kernel's devusb. on another remark regarding zero copy. the reason plan9 drivers are small comes from NOT doing these "optimizations". identity mapping the low part of memory in the kernel avoids alot of trouble and allows you to get DMA capable memory with just wrapping a pointer in PADDR(va). no page lists needed. no MMU tricks needed in the drivers. you can use any kernel memory va for DMA... even your kernel stack! its never paged out. you can be sure it is not changed while the device looks at it ect. do not underestimate the impact of this "simplification". linux block layer is broken in that regard btw. it just hands user pages into the drivers without making sure they do not change while the i/o is in flight, which results in all kinds of false-negatives when you actually start verifying your raid arrays as different snapshots in time got written out to the raid members. they know about this and ignore it because benchmarks are more important. -- cinap
Re: [9fans] 9P or better file services for multiple platforms
this has little chance to get into linux imho. theres nobody in charge. supporting foreign protocols in plan9 is doable as done with ntlm for example. the best authentication infrastructure linux has is ssh with ssh-agent imho. so we might as well let linux users authenticte against plan9 using ther existing ssh rsa keys (for stuff like 9p mounts, drawterm). -- cinap
Re: [9fans] question about #include_next directive
what are you intending to use libressl for in native plan9? plan9 already has a crypto library (libsec) which is a fraction of the size of openssl and works quite well. i'v been using it to implement many crypto protocols to talk to the outside world. for tls, plan9 uses devtls which allows you to wrap any file descriptor to make it a encrypted channel and then you get a filedescriptor back that you can pass arround, so the programs communicating actually dont even need to know the secret session keys. so adding tls support to programs is very trivial in plan9. one function call basically to wrap the fd. while in unix programs that want encryption have to change all ther read and wirte calls to use special libssl functions. also, plan9 has factotum to hold and work on secret keys. you can use factotum todo the public key operations like signing, encryption and decryption using the key for you so keys never have to leave factotum. even if you port programs from unix, it might be worth taking a step back and learn how plan9 does crypto, which is quite advanced compared to traditional unix. -- cinap
Re: [9fans] A compiler bug
> Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front > with https://code.9front.org/hg/plan9front/rev/7cf7079502a7 for 8c/6c only. but its not portable as charles pointed out. this needs a proper fix. -- cinap
Re: [9fans] What are you using Plan 9 for?
> That said, I would switch to 9front + vmx immediately. (I even > conceptualized an awk-based "suite" for audio montage for Acme, using > the "everything is a file" paradigm".) > > Unfortunately my Intel 2200bg wifi card doesn't seem to work in > 9front. Has somebody maybe finished rsc's driver in the meanwhile? well, thats mutually exclusive condition. to run vmx you need a modern machine with ept/vmm support. which usually wont have such an old wifi card. get an ivy bidge thinkpad x230 with intel wifi link card. case 0x0084:/* WiFi Link 1000 */ case 0x4229:/* WiFi Link 4965 */ case 0x4230:/* WiFi Link 4965 */ case 0x4232:/* Wifi Link 5100 */ case 0x4236:/* WiFi Link 5300 AGN */ case 0x4237:/* Wifi Link 5100 AGN */ case 0x4239:/* Centrino Advanced-N 6200 */ case 0x423d:/* Wifi Link 5150 */ case 0x423b:/* PRO/Wireless 5350 AGN */ case 0x0082:/* Centrino Advanced-N 6205 */ case 0x0085:/* Centrino Advanced-N 6205 */ case 0x422b:/* Centrino Ultimate-N 6300 variant 1 */ case 0x4238:/* Centrino Ultimate-N 6300 variant 2 */ case 0x08ae:/* Centrino Wireless-N 100 */ case 0x0083:/* Centrino Wireless-N 1000 */ case 0x0887:/* Centrino Wireless-N 2230 */ case 0x0888:/* Centrino Wireless-N 2230 */ case 0x0090:/* Centrino Advanced-N 6030 */ case 0x0091:/* Centrino Advanced-N 6030 */ case 0x088e:/* Centrino Advanced-N 6235 */ case 0x088f:/* Centrino Advanced-N 6235 */ -- cinap
Re: [9fans] Spectre and Meltdown
> As far as I can remember plan9 flush tables very often and clearly > separate kernel memory pages and user space memory. no. the kernel is mapped in each user process but with PTEUSER bits clear (owner bit) in the pte so user process cannot access it (but with meltdown, it can). -- cinap
Re: [9fans] Spectre and Meltdown
> all binaries on any repo (9p.io, 9front.org, bell-labs.com) are taken on > faith to be safe; but it applies there too. > does anyone read all the various rc scripts carefully? how's that comparable? the broken promise is that web code will be contained in the browser tab so nobody needs to trust that code. and we can just run it. that assumption is proven over and over again to not be true due to bugs in the interpreter and bugs in the massive libraries exposed to it and now theres a case where its broken even if there is no obvious flaw in the interpreter. nobody promised, or tried to do that with a plan9 process. code running in plan9 can do whatever you can do. and easily crash the whole system. so you obviouly need to be cautous about what you run. and yes, you should read the code. -- cinap
Re: [9fans] Spectre and Meltdown
yeah, and javascript was NEVER dangerous before. like it never would steal your passwords or exploit bugs in the monstrosity called a webbrowser. or ave bugs in the jit. all was perfectly safe until now :-) we can perfectly trust the dozens of megabytes injected from whoever pays the advertisement delivery network. 3d ads that is, because gpu drivers are bugfree. i can't wait for javacript crypto implementations that will totally be free of timing side channels... -- cinap
Re: [9fans] Spectre and Meltdown
wait and see if all these scrambled together mitigations actually work. 9front is not in the business of selling shared computing environments (or sell executable javascript ads) to untrusted strangers. that was never really safe to begin with. there will be bugs in software and hardware. and there will be side channels. if you are concerned about security and leaks then run your authentication server on a dedicated box and applications on your own terminal. -- cinap
Re: [9fans] truly hidden files!
the point is that *YOU* control where to bind stuff in your own namespaces. if you do not trust that directory, then do not bind it over /dev or /bin or any part where programs expect some sanity. the fact that you see or not see the files does not matter. say you take someones contrib directory and bind it before /bin. then the people controlling that directory can make files appear and disappear and replace your /bin/rc. you also need to trust the hostowner of the machines you do your computation on. -- cinap
Re: [9fans] truly hidden files!
what do you not understand about private namespaces? -- cinap
Re: [9fans] 9front issue: power shutdown
might be due to 9front not doing any power management at all. maybe theres even a watchdog set by the bios to shut the machine down after some time if acpi hasnt been taken over by the OS to prevent it from melting down spinning at the bios prompt (bios doesnt do interrupts, so they poll everything and busy-wait). could also be emergency shutdown if the machine overheats. i'd check the bios if there are any settings regarding power management or watchdogs. -- cinap
Re: [9fans] Multicore support ARM RaspberryPi
> Does (any flavour of) plan9 / inferno make use of several cores on > (any flavour of) ARM? yep. 9front zynq kernel runs fine with the two cores, all caches enabled. -- cinap
Re: [9fans] USB mouse not working
hard to say. i'd start by making sure the usb controller works. the most common issue is that interrupts do not work due to broken mp tables. 9front uses acpic interrupts by default, which can result in usb not working when bios mp tables are broken. the work arround for that is to specify *acpi= on boot which uses acpi tables instead. alternatively disable apic interrupts and switch to legacy PIC interrupt model with *nomp=1, (this used to be the default of the plan9 from bell labs live cd). second is that 9front uses different mouse usb mouse/keyboard driver that sets the mouse in non-compat mode and tries to parse the report data according to the hid descriptor. source: /sys/src/cmd/nusb/kb.c to debug that, run: ps -a | grep kb to get the nusb/kb processes program arguments (contains the usb address they are attached to) and then kill the process. then start another instance of nusb/kb, passing in the original usb address and the -d flag. good luck. -- cinap
Re: [9fans] TLS 2.x
you might want to update cc/5c/5l as well. arm supports 32*32 -> 64 multiplication and multiply-add instructions which come in handy with poly1305. also support for bit rotations (both chacha20 and poly1305). -- cinap
Re: [9fans] TLS 2.x
its called devtls. devssl is not used by anything but legacy cpu/import. yes, for tls1.1 and tls1.2, the record format has changed. (explicit iv and aead cipher construction (aes-gcm/chacha20-poly1305). theres no such thing as tls 2.x, the upcoming version is tls1.3. you probably also want to use mpc and update your libmp. -- cinap
Re: [9fans] DNS
yes. raising Maxretries to > 5 in dnresolve.c fixes it. this parameter limits the chain of cname redirects. -- cinap
Re: [9fans] SHA-1 collision and venti
couldnt you apply encryption before hashing? so to mount a collision attack you'd also need to know the encryption key used by the underlying storatge system (fossil, vac). so you dont just keep the the network address of your venti server but also the encryption key. just make it part of the dial string or something... -- cinap
Re: [9fans] memory leaks in libmp
> Still a lot of coverity defects are actually false positives. > I try to signal here only the actual bugs but I might be wrong, thus let me > know if you find these report useless and I will stop to annoy the list. i cannot predict the future nor tell you how to spend your time. i'm *not* claiming that using static code analysis to find bugs is "useless" per se. but consider the context in which problems would occur, maybe even describe how a bug would manifest itself in some code (thats what takes the time or wastes our time when you do not do this), and not just blindly present the coverty output as a proof. -- cinap
Re: [9fans] create/create race
> Well not exactly: I will use the new create syscall (without OEXCL support) > when I need such level of control and use ocreate with OEXCL when I do not > care about the race and want a "create or truncate" default behaviour. this makes no sense to me. the whole point of create with OEXCL is that it is atomic and it will *NOT* try to truncate-open the file when it already exist. OEXCL means just sending the Tcreate and nothing else. why is that not already what you try todo with your new create syscall? can you please state the problem that you are trying to fix? -- cinap
Re: [9fans] create/create race
> Wow, this is a sore subject. Check the archives of this list for a > long version of this discussion. > > David interesting, the thread starts here: http://marc.info/?l=9fans=111558704718788=2 -- cinap
Re: [9fans] create/create race
it is not clear to me what your issue is. the manual clearly states that you can pass OEXCL to create to get atomic create operation so in what way are you trying to change the system calls? Since create may succeed even if the file exists, a special mechanism is necessary for those applications that require an atomic create operation. If the OEXCL (0x1000) bit is set in the mode for a create, the call succeeds only if the file does not already exist; see open(5) for details. -- cinap
Re: [9fans] snprintf buffer overrun
theres a bug is in sclose() where it doesnt check if wp is beyond
the buffer. also wp was not updated after realloc().
--- a/sys/src/libstdio/sclose.c Sat Nov 19 16:47:21 2016 +0100
+++ b/sys/src/libstdio/sclose.c Sun Nov 27 21:07:48 2016 +0100
@@ -5,27 +5,35 @@
char *sclose(FILE *f){
switch(f->state){
default:/* ERR CLOSED */
+ Error:
if(f->buf && f->flags)
free(f->buf);
- f->flags=0;
- return NULL;
+ f->buf=0;
+ break;
case OPEN:
f->buf=malloc(1);
f->buf[0]='\0';
break;
case RD:
case END:
- f->flags=0;
break;
case RDWR:
case WR:
+ f->rp=f->buf+f->bufl;
if(f->wp==f->rp){
- if(f->flags)
- f->buf=realloc(f->buf, f->bufl+1);
- if(f->buf==NULL) return NULL;
+ if(f->flags){
+ char *t = realloc(f->buf, f->bufl+1);
+ if(t==NULL)
+ goto Error;
+ f->buf=t;
+ f->wp=t+f->bufl;
+ } else {
+ if(f->wp > f->buf)
+ *(f->wp-1) = '\0';
+ goto Error;
+ }
}
*f->wp='\0';
- f->flags=0;
break;
}
f->state=CLOSED;
--
cinap
Re: [9fans] How to take a portion of a screenshot
rc variables are lists, and $#var evalulates to the
length of the list... you can use that to make counters
by concatenating elements to a list:
term% a=() while(! ~ $#a 13){echo $#a $a; a=(1 $a);}
0
1 1
2 1 1
3 1 1 1
4 1 1 1 1
5 1 1 1 1 1
6 1 1 1 1 1 1
7 1 1 1 1 1 1 1
8 1 1 1 1 1 1 1 1
9 1 1 1 1 1 1 1 1 1
10 1 1 1 1 1 1 1 1 1 1
11 1 1 1 1 1 1 1 1 1 1 1
12 1 1 1 1 1 1 1 1 1 1 1 1
--
cinap
Re: [9fans] Plan 9 5th Edition
calling into firmware code is a big can of worms because firmware is full of bugs and only works with a small set of the major operating systems that the firmware authors tested it with. and theres not really an option for doing it from userspace. you need to call it from kernel mode ring zero and make sure the firmware has the same idea of the virtual memory mappings as your kernel plus work arround the unstated assumptions of the firmware. linux has a track record of bricked machines and firmware corrupting memory. it is just not worth it. in 9front, the kernel never calls firmware. it does interpret a limited set of acpi methods on boot to figure out pci interrupt mappings and and then frees the acpi environment never to return. all efi/bios calls are done by the bootloader *before* it enters the kernel so we never have to rely on efi/bios firmware assumptoins. the bootloader collects the information from efi and passes it to the kernel as plan9.ini variables. efi firmware has a boot manager were the user can add and modify entries. -- cinap
Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
you might take a look at 9front devtls and libsec. it does support tls1.1 and tls1.2. including ecdsa, ecdhe, both variants of chacha20-poly1305 and aes-gcm aead ciphers suits... i updated drawterm with the code and try to keep it in sync and should not be too difficult to port back to labs plan9. -- cinap
Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
> Is this the reason that it is actually possible to boot a combined > auth/cpu/file server at all? no. the reason this works is that the fileserver and authserver share the same key (authid and password) so factotum can make up auth tickets using the key it already knows, skipping the authentication server. this is expecially true if everything runs on a combined cpu/fs/auth, then factotum basically talks to itself thru the 9p auth file thru the fileserver :-) note this also happens when you boot off a cpu server from its own local fileserver. for a stand alone terminal with a local disk you wont neccesarily have a key so you have to disable authentication on your local disk fileserver in that case. this mechanism is also usefull when your authentication server is unreachable or offline. then you can still logon as the hostowner of the affected machine. the fact that the key comes from nvram is irrelevant. if it where not there factotum will prompt for the information on boot (cpu/file servers only). -- cinap
Re: [9fans] "The Name Game"
> https://youtu.be/3d1SHOCCDn0 thanks :-) -- cinap
[9fans] upas/send -r
i'v been getting emails send to my mailserver for random unknown accounts which produces bounce emails for the unsuspecting victims in the reply-to header. thinking if upas/send should reject mails instead when called from smtpd to avoid the backscatter. patched my local version so upas/send will never produce a bounce when passed the -r flag and print "mail rejected: " to standard error instead. this causes smtpd to return a 5.0.0 status. are there good reasons not to do this in general? -- cinap
Re: [9fans] IP Multicast - Results
> Btw, I noticed that the net manpage doesn't accurately describe the > format of /net/ipifc/x/status files. It says there are 9 columns but > mine has more than that and also some extra rows for assigned IP addresses. > Does anyone know if this is a 9front specific deviation or if the man page > is just way out of date? no, the manpage is out of date... the state printing code is the same as in official plan 9, see: /sys/src/9/ip/ipifc.c:/^ipifcstate -- cinap
