2013/4/15 Christopher Nielsen
>
> A small caveat, I had to use mercurial on x86 (my cpufsauth server is an x86
> vmware instance), since there wasn't an arm binary. Other than that, it was
> all pretty painless.
One may '9fs sources && fcp /n/sources/contrib/yk/5.python
/arm/bin/python' to add
i needed a bit more than the script pci(8) could
give me, such as pci capability info. msi vector
info, &c. here's the result.
http://www.quanstro.net/magic/man2html/8/pci
the code and executable is here
srv $nflag -q tcp!atom.9atom.org atom &&
mount $nflag /srv/atom /n/
On Apr 17, 2013, at 5:15, Yaroslav wrote:
> 2013/4/15 Christopher Nielsen
>>
>> A small caveat, I had to use mercurial on x86 (my cpufsauth server is an x86
>> vmware instance), since there wasn't an arm binary. Other than that, it was
>> all pretty painless.
>
>
> One may '9fs sources && f
On 17 April 2013 17:36, Matthew Veety wrote:
> How do you get python to build without the VFP instructions?
the existing arm kernel emulates the older ARM7500 fp instructions, which
5l generates by default.
> How do you get python to build without the VFP instructions?
don't pass 5l the -f flag.
- erik
In a few cases, the kernel will use pprint to put a diagnostic on the
standard error (file descriptor 2).
One of those is a warning that the process has used more than 100 file
descriptors.
That message is possibly obsolete and could be removed, but there are
others, such as
notifying an uncaught t
> In a few cases, the kernel will use pprint to put a diagnostic on the
> standard error (file descriptor 2).
What's wrong with kprint (or logging) for this?
++L
On Wed Apr 17 13:38:02 EDT 2013, lu...@proxima.alt.za wrote:
> > In a few cases, the kernel will use pprint to put a diagnostic on the
> > standard error (file descriptor 2).
>
> What's wrong with kprint (or logging) for this?
that's what pprint() does. it prints info about
the current (offendin
> there is no kprint in plan 9. neither can one
> syslog from the kernel.
I was going to be clearer, then got lazy:
-lr--r- c 0 lucio lucio 0 Mar 21 20:44 /dev/kprint
that's the console, I've never investigated how the kernel writes to
it, but it sounds like the right place for diagn
The user is intended to see these messages: that's the point of pprint. The
messages refer to a program the user is running. It produces diagnostics
from the kernel to the user, and thus correctly uses standard error.
On 17 Apr 2013 18:54, wrote:
> > there is no kprint in plan 9. neither can one
its not just pprint(). stuff like sysfatal() will also write to
fd 2... or abort()... having the kernel write to your std error
has some practical value imho.
having errors from listeneres appear on the cpu server console
(or a logfile?) instead in the middle of some unknown protocol
stream makes
> having errors from listeneres appear on the cpu server console
> (or a logfile?) instead in the middle of some unknown protocol
> stream makes sense as a default for aux/listen.
a logfile would be better. i have a system that gets
attacked occasionally, and spamming the console
would only make
12 matches
Mail list logo
