Neat, thanks!
I wonder if a similar approach could be used to move some device drivers
out of kernel...

Btw, I did read the sample in segment(3) but I was looking for a real world
example.
What I'm trying to understand is not *how* to use devsegment, but *when* to
use it.
Which problems is it designed to solve?

Moreover, Zinq's graphics use a very smart approach, but it's specific to
9front evolution of the device with the "fixed" type.
I'm also looking for the general use case, when segments are not used for
DMA, as designed in the original Plan9.


Giacomo

2016-08-31 12:40 GMT+02:00 <cinap_lenrek@felloff.net>:

> > Hi, I'm looking for an usage example of devsegment.
> >
> > I cannot find anything neither in bhro's plan9 nor in 9front.
> >
> > Can anybody share a real usage world example?
> >
> >
> > Giacomo
>
> its just creating named segments of some shared memory.
>
> segment(3) has an example. read it.
>
> on 9front, you can also allocate physically continuous segments *and*
> get the physical base address for it :)
>
> one application for it is on the zynq. the displayport graphics is
> implemented using the fpga and userspace uses devsegment
> to allocate 5MB of physically continous memory for the framebuffer:
>
> #!/bin/rc
> rfork en
> bind -c '#g' /mnt/segment
> if(! test -d /mnt/segment/fb){
>         mkdir /mnt/segment/fb
>         echo 'va 0x00500000 0x00500000 fixed' > /mnt/segment/fb/ctl
> }
>
> bind -b '#P' /dev
> audio/pcmconv -i 'c1u32r1' -o 'c1U32r1' < ./build/out.bin > /dev/pl
>
> then some c code programs the graphics register and hands the
> loaded core the physical address for DMA.
>
> --
> cinap
>
>