> david (0intro) tested the driver on GCE a few months ago, and
> reported that it did *not* work. i don't recall what exactly
> happened, but the virtio device in GCE seems to differ from qemu's.
I haven't tried for a while, since the debugging process is
a bit time consuming.
As far I remember,
also,
MSS really looks out of place. i would expect MTU. MSS is a TCP concept.
- erik
4.1.5.1.4.1 of the spec does say that a page is 4096 for the purposes of legacy
virtio, but 2.4.2 just talks about pages. you think i should just use an
explicit 4096 instead of PGROUND/BY2PG here?--- Begin Message ---
On Mon Dec 1 20:17:56 PST 2014, misch...@9.offblast.org wrote:
> hello,
>
>
On Mon Dec 1 20:17:56 PST 2014, misch...@9.offblast.org wrote:
> hello,
>
> if anyone is interested in using or reviewing my ethervirtio driver, here it
> is.
>
> http://9.offblast.org/stuff/ethervirtio.c
>
> this driver was written for 386 and amd64 9front, but according to a short
> test i
> I took Steve's point to be that I don't get to have an opinion
> because he's never seen me in his playground before, but I figured
> it would be more productive to focus on the fact that uboot sucks
> rather than an exercise in disregarding personal experience because
> Steve told me to.
i didn
On Mon Dec 1 20:17:56 PST 2014, misch...@9.offblast.org wrote:
> hello,
>
> if anyone is interested in using or reviewing my ethervirtio driver, here it
> is.
>
> http://9.offblast.org/stuff/ethervirtio.c
>
> this driver was written for 386 and amd64 9front, but according to a short
> test i
hello,
if anyone is interested in using or reviewing my ethervirtio driver, here it is.
http://9.offblast.org/stuff/ethervirtio.c
this driver was written for 386 and amd64 9front, but according to a short test
i did a few months ago, it should work in the labs' kernel. it would be
interesting
Quoting erik quanstrom :
while i don't agree that u-boot is nice, i do agree with steve's point,
which i understood to be that hardware is messy, and it's hard to write
software that isn't a tad messy to deal with this. steve has a lot
of experience
with hardware, and knows what he's talkin
> > But, IMHO, this is precisely the difference between Unix and Plan9.
> >
> > In Unix, the console or X11 are dumb terminals. There are only
> > no-computing-capabilities devices to interact; they are no terminals as
> > in Plan9.
>
> Okay, than that's perhaps what I'm missing yet.
>
> To mimi
On Mon Dec 1 20:00:59 PST 2014, k...@sciops.net wrote:
> Quoting Steven Stallion :
>
> > Clearly you've never worked on hardware.
>
> No, thank Christ, my conscience is clean. Instead I work on
> software, and uboot is a fine example of "well it builds on my
> laptop" development paradigms. Pl
Quoting Steven Stallion :
Clearly you've never worked on hardware.
No, thank Christ, my conscience is clean. Instead I work on
software, and uboot is a fine example of "well it builds on my
laptop" development paradigms. Plenty glad I don't have to
screw with such nonsense any more, and even
On 01.12.2014 11:38, tlaro...@polynum.com wrote:
Hi,
> But, IMHO, this is precisely the difference between Unix and Plan9.
>
> In Unix, the console or X11 are dumb terminals. There are only
> no-computing-capabilities devices to interact; they are no terminals as
> in Plan9.
Okay, than that's p
On Mon, Dec 1, 2014 at 8:42 PM, Bakul Shah wrote:
> On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion wrote:
>>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Do you think it is worth
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.
i don't think this is a full accounting of the situation.
u-boot has several drawbacks that have hindered my development
(a) there are many of
On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion wrote:
>
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.
Do you think it is worth adding support for "flattened device
tree" (a data structur
Where is the +1 on this whatchamajig?
Sent from my iPhone
> On Dec 1, 2014, at 6:16 PM, Steven Stallion wrote:
>
>> On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier wrote:
>> Quoting Steven Stallion :
>>
>>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>>> boot significantly
On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier wrote:
> Quoting Steven Stallion :
>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Instead, I'll recommend eschewing hardware that require
Quoting Steven Stallion :
FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
boot significantly - there is zero reason to eschew the functionality
it brings.
Instead, I'll recommend eschewing hardware that requires circus tricks to
load a kernel.
khm
On Tue, Dec 2, 2014, at 03:24 AM, Steven Stallion wrote:
> They do. In fact, I contributed a patch a while back to add u-boot
> image support to 5l a while back. U-boot has also been patched to
> expect these binaries. You can take a look at what has been done in
> the Chromebook port (http://code.
They do. In fact, I contributed a patch a while back to add u-boot
image support to 5l a while back. U-boot has also been patched to
expect these binaries. You can take a look at what has been done in
the Chromebook port (http://code.google.com/p/9chrome), but I've been
stalled due to demands at th
I do not remember getting this error in the Labs version. But on 9atom
with kfs, I get a build error while compiling golang 1.3.3 from the
source:
go tool dist: create
/usr/ram/src/go/src/pkg/runtime/zruntime_defs_plan9_amd64.go:
'/usr/ram/src/ amd64.go' name too long
I remember getting this
On Mon, Dec 1, 2014, at 07:37 PM, erik quanstrom wrote:
> On Mon Dec 1 06:01:58 PST 2014, r...@rkrishnan.org wrote:
> > Hi,
> >
> > I did a fresh install of 9atom today on a spare hard disk connected to
> > my AMD64 machine. The installation went fine. On bootup, I get this
> > error message on a
> Thanks. IMX6 documentation is freely available. There is a version of
> u-boot. The manufacturer (Solid Run) also has made the board schematics
> etc available.
>
> From the reading of booting(8), I am assuming that the ARM devices in
> plan9 use the u-boot for booting the kernel up?
some do.
On Mon Dec 1 06:01:58 PST 2014, r...@rkrishnan.org wrote:
> Hi,
>
> I did a fresh install of 9atom today on a spare hard disk connected to
> my AMD64 machine. The installation went fine. On bootup, I get this
> error message on a black window (mouse is active):
>
> lib/profile: rc: /rc/lib/rcmai
Hi,
I did a fresh install of 9atom today on a spare hard disk connected to
my AMD64 machine. The installation went fine. On bootup, I get this
error message on a black window (mouse is active):
lib/profile: rc: /rc/lib/rcmain:23 .: can't open: '/bin/lib' directory
entry not found
init: rc exit st
> The guy in front of the console should authenticate as a normal user
But you do authenticate to Plan 9 as a normal user. On one node you're
the hostowner, but to the *system* you authenticate as a normal user.
One guy on here lately was actually attaching to his fileserver as
none.
A "system" is
> But, IMHO, this is precisely the difference between Unix and Plan9.
The important difference is that in Unix the "terminal", specially
graphics terminals like X servers, have to be trusted to be in good
hands - which cannot be enforced. When you look at NFS, for example,
a trusted network node
On Mon, Dec 01, 2014 at 09:00:46AM +0200, lu...@proxima.alt.za wrote:
> > The guy in front of the console should authenticate as a normal user
> > and then only be allowed to access his own environment (no direct
> > control over hw, etc).
>
> The guy is not in front of the "console", he has physi
and I sometimes don't
save them in a guide file
Kinda off-topic, acme(1) from Plan9 man has section about guide files.
p9p acme(1) hasn’t that, but I see rudimentary code in acme.c and win.c dealing
with ‘/guide’ Rune in p9p repo. What’s the reason of this code? Can I use guide
files
> i can try it on rpi's, plugs and BBBs
My Sheevaplug has died on me and the Olimex Olinuxino is a bit
underpowered. I'm not sure if either will ever be viable.
Olimex have some exciting new hardware coming up, but a builder is a
bit of a tall order on ARM.
Ideally, I should use my Galaxy S5,
i can try it on rpi's, plugs and BBBs
On Sun, Nov 30, 2014 at 12:37 PM, Anthony Martin wrote:
> minux once said:
> > On Nov 30, 2014 3:10 PM, "Mats Olsson" wrote:
> > > Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
> > >
> > > So it seems that it's supported.
> > go on
On Mon, Dec 1, 2014, at 11:14 AM, erik quanstrom wrote:
> > Surprisingly I didn't see a paper on porting Plan9 to new architectures
> > in the plan9 paper collection. Any help and pointers on how to get
> > started with the porting effort will be highly appreciated.
>
> it's all about the documen
32 matches
Mail list logo
