From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Giacomo Tesio Date: Wed, 31 Aug 2016 14:57:14 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1144131cf2bc0e053b5da2ce Subject: Re: [9fans] devsegment usage examples Topicbox-Message-UUID: 9aaee166-ead9-11e9-9d60-3106f5b1d025 --001a1144131cf2bc0e053b5da2ce Content-Type: text/plain; charset=UTF-8 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 : > > 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 > > --001a1144131cf2bc0e053b5da2ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 ex= ample.
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 sma= rt approach, but it's specific to 9front evolution of the device with t= he "fixed" type.
I'm also looking for the gener= al use case, when segments are not used for DMA, as designed in the origina= l 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){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mkdir /mnt/segment/fb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 echo 'va 0x00500000 0x00500000 fixed' &= gt; /mnt/segment/fb/ctl
}

bind -b '#P' /dev
audio/pcmconv -i 'c1u32r1' -o 'c1U32r1' < ./build/out.bi= n > /dev/pl

then some c code programs the graphics register and hands the
loaded core the physical address for DMA.

--
cinap


--001a1144131cf2bc0e053b5da2ce--