> why you all have so many time on Plan9 ?
> is it very interest in researching plan9 ?
> You are all not busy in working , right ?
> and you all have much many to do your own things in spare time, right ?
> Do you think it is very cool to program in plan9 ?
all your time are belong to us!
HA HA
Uriel wrote:
The classic T22 with the SXGA+ screen seem to still be the best (you
should get an orinoco pcmcia card for wifi, which is the only one
supported anyway). And they can be found quite cheaply (around 300$ I
think). Of course, if you also want to run a recent lunix version or
vista, or
Richard Miller wrote:
I am surprised that there are people out there
with 4+ year old servers. You take very good care
of your disks.
An arena can be older than the disk it's on -- you can copy
arenas verbatim from an old disk to a new one without changing
the timestamps.
1756289
Richard Miller wrote:
the VIA machine is the one that got me lots of trouble
with the
SATA until i hacked a bruteforce retry-n-reset-loop in the ide driver,
Me too. Maybe one of us should submit a patch?
this is the driver that works for me:
http://9hal.ath.cx/usr/cinap_lenrek/viamo
ron minnich wrote:
futex?
http://en.wikipedia.org/wiki/Futex
so do we need a futtocks device?
i think this can be implemented without
any additional devices... wtf?!
ron
cinap
Uriel wrote:
On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
<[EMAIL PROTECTED]> wrote:
i can't agree with this label "research os" if you mean
to imply that it's not stable or somehow unfinished.
Not at all. Just meant that one doesn't run their company's Oracle database on
it.
Iruata Souza wrote:
On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
<[EMAIL PROTECTED]> wrote:
Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
only for the fun of it, I'm slowly trying to port it to my SGI O2.
nice! whats the status of your port? have
Charles Forsyth wrote:
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or ought
to be),
because the trap path and fault recovery must do more work than syscall
(perhaps much more).
it's also difficult then to optimis
Paweł Lasek wrote:
A much more important reason might be the fact that memory mapping of
files is only one function of mmap() and company. Basically when you
have mmap() and munmap() you can write your own allocator (which might
be very useful, especially for databases). I won't delve into using
sqweek wrote:
On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
Also, public 9grids. Though judging by gdiaz's experiences with
sirviente, there's a bit of work to be done in that area - I get the
impression things are fairly unstable once the machine gets under
memor
Joel C. Salomon wrote:
On Wed, Jul 30, 2008 at 11:29 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
I run into an interesting problem with linuxemu.
The problem *seems* to be that traps can be
enqueued in the process note array *after* some
other note causing notify() to kill us.
Please correct me if i miss(understand) something
here. It just hit my mind after hours of late night
debugging.
T
erik quanstrom wrote:
it looks like you get the second trap while
you are still in your notify handler, since
i think this test
(up->notified || up->notify==0)
is for a proc in a notify handler getting a system
trap (or a proc with no notify handler).
right, the problem is, my note ha
erik quanstrom wrote:
it would also be interesting to know if you are
seeing this randomly or if you can reliable reproduce
this condition.
i can reproduce it with this:
http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
8c test.c
8a int80.s
8l test.8 int80.8
./8.out
8.out 1249
Kernel Panic wrote:
http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
8c test.c
8a int80.s
8l test.8 int80.8
./8.out
8.out 12490667: suicide: sys: trap: general protection violation
pc=0x1333
the parent process loops and does "fake" syscalls while
the child post
erik quanstrom wrote:
Are these limitations listed in some document?
I don't believe they are.
It might bve nice to think there are no arbitary limits in plan9
as the GNU mantra, however there are not many and personally,
working with remote servers with very long paths, I have never
(kn
[EMAIL PROTECTED] wrote:
A thought ...
Shared libraries do 2 possibly useful things:
1) save space
2) stop you having to re-link when a new library is released.
Now 2) doesn't really happen anyway, due to .so versioning hell,
so we're left with 1) ...
I know it's kind-of hacky and unstructured
I put the photos in my contrib on sources yesterday.
The http file listing on sources seems broken currently...
so here are the urls:
http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0181.jpg
http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/ds
Roman Shaposhnik wrote:
On Nov 6, 2008, at 3:01 AM, Kernel Panic wrote:
http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0213.jpg
This one is truly awesome!
yeah :-)
Thanks,
Roman.
erik quanstrom wrote:
d'oh! the return value from catchalarm looks reversed. from notify(2)
[...] A handler must
return a non-zero number if the note was recognized (and
resolved); otherwise it must return zero. When the system
i think you're getting into some
I see linux code doing SSE instructions. Has anyone started SSE support
for plan9 kernel yet? Will the AMD64 port contain SSE support?
--
cinap
in the ehci driver, it uses:
Tdmaxpkt = 0x5000, /* max buffer for a Td */
a td has 5*4K pages giving the 20K above, but i think this only applies if the
first pointer is page aligned (page offset = 0) so all the pages can be filled
completely.
The EHCI spec says this:
"The buffer point
yes, that would work too.
--
cinap
> Gesendet: Donnerstag, 11. April 2013 um 15:05 Uhr
> Von: "erik quanstrom"
> An: 9fans@9fans.net
> Betreff: Re: [9fans] Tdmaxpkt in usbehci (no html)
>
> > in the ehci driver, it uses:
> >
> > Tdmaxpkt = 0x5000, /* max buffer for a Td */
> >
> > a td has 5
this td->buffer[i] access makes no sense.
static void
isohsinit(Ep *ep, Isoio *iso)
{
int ival, p;
long left;
ulong frno, i, pa;
Itd *ltd, *td;
iso->hs = 1;
ival = 1;
if(ep->pollival > 8)
ival = ep->pollival/8;
left =
go is using switch on vlongs. support for this was backported to plan9 c compiler
some time ago. just update the compilers from sources.
Von: "Skip Tavakkolian"
/usr/fst/Go1/src/cmd/gc/reflect.c:1022[/usr/fst/Go1/src/cmd/gc/reflect.c:3400] switch _expression_ must be integer
yes. you are right, it doesnt work for 5c.
--
cinap
Gesendet: Montag, 15. April 2013 um 10:43 Uhr
Von: "Gorka Guardiola"
An: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Betreff: Re: [9fans] Go Plan9 ARM Dreamplug
On Mon, Apr 15, 2013 at 10:31 AM, k
> Gesendet: Montag, 29. April 2013 um 21:34 Uhr
> Von: "Richard Miller" <9f...@hamnavoe.com>
> An: 9fans@9fans.net
> Betreff: Re: [9fans] 5l bug
>
> > following up, theres my naive fix for this. instead of
> > emiting conditional division instruction by 5c... dont and
> > keep the branch. does t
i is not ovious to me why that would work without adding a conditiona branch.
maybe my assumptions are wrong. can you show the resulting assembly for the
testcase?
> Gesendet: Dienstag, 30. April 2013 um 11:07 Uhr
> Von: zephyr.pelle...@gmail.com
> An: 9fans@9fans.net
> Betreff: Re: [9fans] 5l bug
when the hex numbers count in (2), it means its reading
the kernel file from the disk into memory.
9fronts 9boot loader uses the bios for all device access.
to read a single 512 byte block of data from a harddrive
(or usb flash drives as they are emulated as harddrives by
the bios), we switch from
29 matches
Mail list logo
