Just a heads-up to 9fans that the Go build for Plan 9 (386 or ARM) now
expects the underlying platform to be updated with the 21-bit runes
fixes from Bell Labs, the pertinent submission has been accepted and
processed.
Being up to date may not improve the build as much as one may wish,
but not bei
> uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with
> the loader. The exynos5 port that I am working on (Arndale Board, Samsung
> Chromebook) relies on this exclusively.
this is in 9atom. also note, that the kw kernel is bootable without uimage
support.
- erik
> Regarding the latter, Plan 9 does not allow floating point
> instructions to be executed within note handling, but erring on the
> side of caution also forbids instructions such as MOVOU (don't ask me)
> which is part of the SSE(2?) extension, but hardly qualifies as a
> floating point instructio
> Regarding the latter, Plan 9 does not allow floating point
> instructions to be executed within note handling, but erring on the
> side of caution also forbids instructions such as MOVOU (don't ask me)
> which is part of the SSE(2?) extension, but hardly qualifies as a
> floating point instructio
> or GO could just stop using *OMG-OPTIMIZED* SSE memmove() in the note
> handler.
But it would not stop users from doing so, so at minimum we'd have to
detect the abuse and report it, rather than crash.
Saving the entire register space would be expensive for all
well-behaved processes and avoidi
> movou (movdqu in the manual) is a sse2 data movement instruction.
> not all sse2 instructions require that sse be turned on (pause, for example),
> but movou uses at least one xmm register so is clearly using the sse
> unit, thus requiring that it be turned on.
I see Erik answers my question: xm
the saving isnt the problem. the kernel already flushes the fp registers
to the process fpsave area on notify. its just that we do *not* copy
the registers to the user stack, but save them in the process fpsave
area.
as theres just just one fpsave area in the process, and not one for
notes and one
> also note, that the kw kernel is bootable without uimage
> support.
... and so is any other Plan 9 arm kernel, as long as you
have access to u-boot's console or config variables.
See booting(8).
> then the note handler does memmove itself modifying XMM0 itself loading
> it with something completely different. then note handler finishes
> continuing the original programm, then XMM0 would contain the garbage
> from the note handler! it would look for the program like if registers
> randomly
> This paragraph has more qualifiers than your average winter olympics
If you prefer snarky insinuations rather than an attempt to convey
accurate information, I think you're reading the wrong mailing list.
On Sun, Jun 02, 2013 at 05:54:14PM +0200, lu...@proxima.alt.za wrote:
> I should not be doing it rather than give me an incorrect answer that
> I then use to fire a ballistic missile at the wrong target?
I knew Google was up to something.
khm
On Sun, Jun 02, 2013 at 04:55:59PM +0100, Richard Miller wrote:
> > This paragraph has more qualifiers than your average winter olympics
>
> If you prefer snarky insinuations rather than an attempt to convey
> accurate information, I think you're reading the wrong mailing list.
>
I disagree.
> I disagree.
Yes.
> I knew Google was up to something.
Google? Who's Google?
++L
it takes no skill to make snarky comments.
i have two file servers that have been continuously and reliably operating
since 2003 and 2010 -- a ken fs since 2003, and a venti-backed fossil fs
since 2010. I have a third which is currently pickled -- an fs64 that ran
from the time geoff created it in
On Jun 2, 2013, at 12:41, Skip Tavakkolian wrote:
> it takes no skill to make snarky comments.
Khm brought trolling back to the intelligent man. His work is truly an art.
Veety
my guess is that it's a mutated gene.
On Sun, Jun 2, 2013 at 9:45 AM, Matthew Veety wrote:
> On Jun 2, 2013, at 12:41, Skip Tavakkolian
> wrote:
>
> > it takes no skill to make snarky comments.
>
> Khm brought trolling back to the intelligent man. His work is truly an art.
>
> Veety
>
On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote:
> my guess is that it's a mutated gene.
>
Ah, a Chomskyite.
but was probably abused as a child.
On Sun, Jun 2, 2013 at 9:53 AM, Kurt H Maier wrote:
> On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote:
> > my guess is that it's a mutated gene.
> >
>
> Ah, a Chomskyite.
>
>
>
On Sun, Jun 02, 2013 at 10:01:12AM -0700, Skip Tavakkolian wrote:
> but was probably abused as a child.
>
This is a perfect counterexample to "it takes no skill to make snarky
comments." You clearly need practice; this one was clumsy.
the feeding hours are over for the day; back to your cave.
On Sun, Jun 2, 2013 at 10:13 AM, Kurt H Maier wrote:
> On Sun, Jun 02, 2013 at 10:01:12AM -0700, Skip Tavakkolian wrote:
> > but was probably abused as a child.
> >
>
> This is a perfect counterexample to "it takes no skill to make snar
Back in april I wrote:
> Plan 9 works just as well on the model A as on the model B, except for
> some problems with low-speed usb devices connected directly to the pi.
> If you use a hub it should be fine.
I've finally found the cause of this and supplied a patch to fix it.
If you pull and bui
cinap_len...@gmx.de once said:
> or GO could just stop using *OMG-OPTIMIZED* SSE memmove()
> in the note handler.
This is exactly what I did in my patch. This was just
a regression. Someone changed memmove a few weeks ago.
Nothing to see here.
Anthony
> If you prefer snarky insinuations rather than an attempt to convey
> accurate information, I think you're reading the wrong mailing list.
hahahahaha
its /n/sources/patch/testolder, also leaks dir in the case:
if(rel)
n = time(0) - n;
if(n < 0)
return 0; <- HERE
r = dir->mtime < n;
free(dir);
return r;
--
cinap
> dedicate a machine to the file server.
This must be the best way to keep the plebeian hands off the artwork:
museums that are only open to curators.
This certainly also provided for my technical contribution to this mailing list.
>> > my guess is that it's a mutated gene.
> but was probably abu
On 1 June 2013 04:56, Matthew Veety wrote:
> You have more sack than I could ever say I have for putting anything
> mildly important on fossil.
!ls /n/dump
/n/dump/2004
/n/dump/2005
/n/dump/2006
/n/dump/2007
/n/dump/2008
/n/dump/2009
...
This is fossil on venti, on file server hardware that h
a while ago, libc's gmtime() was changed like this:
- hms = tim % 86400L;
- day = tim / 86400L;
+ hms = (ulong)tim % 86400L;
+ day = (ulong)tim / 86400L;
if(hms < 0) {
...
i asked what this change tried to intend here:
http://9fans.net/archive/2013
Hello everyone,
maybe this can be of interest to someone.
I have downloaded from 9legacy the old 9spirit iso (the newest uses bell's
9load, doesn't it?)
I have installed the system selecting a fat partition with bell's iso. All went
right, and I reboot.
First thing happens:
MBR...PBS1...Bad for
arg, screwed up... that should'v been (long) not (vlong)... too
drunk, too late...
--
cinap
> on the topic, i thought about how to handle the 2038 problem
> in general with 9p which uses unsigned 32bit integers for atime
> and mtime fields.
on the one hand one could just expect long to be always 64-bits
by 2038. but that seems timid.
i'd rather see the time base switched to nanoseconds
On Sun, Jun 2, 2013 at 2:58 PM, hiro <23h...@gmail.com> wrote:
> > dedicate a machine to the file server.
>
> This must be the best way to keep the plebeian hands off the artwork:
> museums that are only open to curators.
> This certainly also provided for my technical contribution to this mailing
On Sun Jun 2 17:59:16 EDT 2013, 23h...@gmail.com wrote:
> > dedicate a machine to the file server.
>
> This must be the best way to keep the plebeian hands off the artwork:
> museums that are only open to curators.
> This certainly also provided for my technical contribution to this mailing
> li
On Sun Jun 2 17:31:05 EDT 2013, cinap_len...@gmx.de wrote:
> its /n/sources/patch/testolder, also leaks dir in the case:
>
> if(rel)
> n = time(0) - n;
> if(n < 0)
> return 0; <- HERE
> r = dir->mtime < n;
>
> free(dir);
> return r;
> > also note, that the kw kernel is bootable without uimage
> > support.
>
> ... and so is any other Plan 9 arm kernel, as long as you
> have access to u-boot's console or config variables.
> See booting(8).
the rpi doesn't use u-boot by default, though, does it?
i certainly don't see any indica
> I see Erik answers my question: xmm registers may be clobbered. I
> suppose they could be saved in the Go runtime, if absolutely
> essential?
no, they can not. saving registers is something that is done on
context switch by the scheduler, and the go runtime is not
involved in context switching
you'll need the uboot sd image that Richard put together
(/n/sources/contrib/miller/uboot.img)
that's what i use to boot the 9Pi cluster from the file server.
On Sun, Jun 2, 2013 at 8:53 PM, erik quanstrom wrote:
> > > also note, that the kw kernel is bootable without uimage
> > > support.
> >
> there are things that could be done. but before getting radical in a
> hurry, is there any place other than runtime·memmove() that
> would use sse in a note handler?
I presumed, perhaps incorrectly, that users are allowed to write their
own signal handlers and are not prohibited from using floa
On Sun, Jun 2, 2013 at 6:09 AM, erik quanstrom wrote:
> also note, that the kw kernel is bootable without uimage
> support.
>
Sure, though supporting uImage means you get a few things for free, not to
mention it isn't ELF. This deserves a proper write up - I'll probably do
something for IWP9 if I
I have applied Anthony's CL 9796043 together with some tweaks to
pkg/runtime/sys_plan9_386.s which I will pass on to Anthony as soon as
I can; this has made it possible to complete the first set of run.rc
tests without the major incidents I used to see. Some tests still
fail, but I wasn't expectin
40 matches
Mail list logo
