As others said, aux/kbdfs gets included in the kernel-image in a read-only
ram file-system so that the system can prompt you for your root-filesystem
and user-name on boot.
This is also true for alot of other file-servers like nusb/usbd, gefs...
So you need to also "mk install" the kernel and the
> I'm a newbie playing with 9front on laptop (in VirtualBox)
https://fqa.9front.org/fqa.html
> ... and would like to try to make it work with one mouse key and modifiers
> (similar to
> https://github.com/rsc/plan9/commit/5375b476e0d0119bcd85517e337e99b1d7a0b7e0
> ).
Keyboard scancode t
I'v taken a look at the linked repository's code:
https://github.com/tlaronde/nix
and wonder where that "new version" Mbi (multiboot info) struct
comes from, as it clearly doesnt comply with this:
https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
even tho, the multiboot header u
waiiit... i miscounted the syms[4] field. my mistake.
so it *IS* 0.6.96 spec.
what old version then are you talking about?
--
cinap
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb9ac567b4bcfa86e-M1b5656af9bc7dffcb3ff73fe
Delivery op
i had the same problem with the "vpn internal"
zones of my employer, and found ndb/dns already
has a mechanism to define a delegated zone:
dom=my.net soa=delegated ns=ns.my.net
when ns.my.net doesnt resolve, you can serve
that domain yourself like:
dom=ns.my.net ip=1.2.3.4 soa= ns=ns.my.net
hop
> If we're going down this route, we should copy the FPsave
> to the stack in notify as we do the Ureg. Then we wouldn't
> need the ofpregs file at all.
yeah. i'm not fond of it ofpregs-file solution eigther.
> This will require some thinking
> about backwards compatibility. There needs to be a
just for reference the work-in-progress implementation for this on 9front amd64
kernel:
https://felloff.net/usr/cinap_lenrek/pc64fpnote.patch
needs some work around the devproc access to the fpsave structs
and maybe find an alternative to the #ifdef code... but otherwise
the handler part was
Thank you for your answer.
> I believe that /proc/$pid/regs is the note registers during
> the note handler, and so .../fpregs should be the same. I don't think we
> need fpregs and ofpregs, since we don't have regs and oregs.
I think that is mistaken. /proc/n/regs gives you the registers
of the
good day.
i'v took a look at the patch:
https://github.com/rsc/plan9/commit/3715bf9b86a86ed6a3a857cabfc7dff5d70b409b
i spend some time yesterday trying to implement the
same behaviour in 9front kernels and it is not too
difficult, but the semantics would need to be clarified
and i'm not totally
> This binding has to be very early to be effective.
> It is done /sys/src/9/boot/bootrc. Why does it disappear when the filesystem
> is not local?
because the namespace from bootrc is not inherited.
init creates a complrely new namespace using
/lib/namespace from your root file-system:
i suppose the following is missing in your /lib/namespace:
bind -a #a /net
also... what?
--
cinap
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-Mf69109feaec59f33a9616fab
Delivery options: https://9fans.topicbox.com/
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
--
> 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: 9fan
> 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 ty
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
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/
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
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 ker
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
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 gp
> 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/T
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
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
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
*
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.topicb
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/9
> 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 matt
> 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://9f
> 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 authe
>
> 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
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
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 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(&there, here
> 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){
-
> 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 see
> 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.
ok, never mind.
--
cinap
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-M2425616a037a16c94ec7afd1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
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 netb
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 likel
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.top
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
new kernel that should be able to deal with the two regions:
http://felloff.net/usr/cinap_lenrek/9pi4
sha1sum:
0222a824ec04c672955560ea120fa4d8de848e79
--
cinap
> The device tree has two entries.
>
> offset:0
> lenght:0x3c40
>
> offset:0x4000
> length:0xbc00
excellent! that explains it.
--
cinap
> 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
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
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 '#
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 f
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
nope. charles is your man.
--
cinap
arrg! and i forgot the clean BEFORE the issuing dma.
--
cinap
> 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 complete
> 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
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/55d93e47a2d
> (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 resur
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
> 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 h
> 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 f
> 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 tha
done.
--
cinap
its documented in prep(8)
--
cinap
yes, patches are welcome. if you prefer longer timeout,
you know what code to change now.
--
cinap
> 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
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
rebo
noted. its missing in the proto file.
--
cinap
typo. illegal register *ADDRESS*.
--
cinap
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
excellent work! thank you!
--
cinap
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
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
yeah, rootserver makes much more sense.
--
cinap
all looks good. except that "swap" is kind of crazy name to mean
the nfs server.
--
cinap
we do not support edns at all. the Topt rr type is just ignored.
--
cinap
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
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
the complains where about the *HDMI*. which is the work
of DRM mafia. displayport at is a standard with available
documentation.
--
cinap
> 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 diff
hahahahahahahaha
--
cinap
> 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 re
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/sy
> 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 opera
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
> 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 acce
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 t
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
> 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
> 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
> 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
> 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
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
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 the
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 an
what do you not understand about private namespaces?
--
cinap
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
> 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
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=
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
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 us
yes. raising Maxretries to > 5 in dnresolve.c fixes it. this parameter
limits the chain of cname redirects.
--
cinap
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
> 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*
claimi
1 - 100 of 791 matches
Mail list logo
