once 64-bit plan 9 (in whatever guise) is stable, you might just as
well use that for SSE.
i did think about putting the 6c changes back into 8c, but there are
still x86-32 systems that offer
only 387s. mind you, with an SSE [subset] emulator to replace fp387.c,
those systems might
just as well use
fixed for my hw. the really key bit was setting the endianness
properly. this may have been set up by your pxe hardware or bios,
if your bcm chip was built-in.
i've updated 9atom with this driver.
- erik/*
* Broadcom BCM57xx
* Not implemented:
* proper fatal error handling
* multiple ring
> BTW I'am not sure if I emphasised enough how grateful I am for all your
> patient work in getting SSE working.
really it's no problem. it's something that i'd worked on before,
and had to leave behind.
ideally, i'd like to be able to use sse with 8[acl]. but that means
that i (a) have to figu
re: etherbcm.c
thanks,
Again it will have to wait till monday for me to try.
BTW I'am not sure if I emphasised enough how grateful I am for all your
patient work in getting SSE working.
Its great to make progress on this, though the performance of opera +
linuxemu + equis (fgb's X11 server) is
still not working; doesn't even reset.
i've taken a pass at cleaning up the code. the biggest change
is using style(6) formatting. also, coherence() is missing when
entering ring entries, since the posted write of the ring ptr can
pass the memory writes of the ring entry, from the perspective
of
On Fri, Nov 25, 2011 at 7:55 AM, erik quanstrom wrote:
>> (I know Erik has adopted at least the BCM57xx driver for 9atom). I'm
>
> although it's in there, it doesn't work with the bcm57xx hardware i have.
> so cavet emptor.
You might want to re-synch. Recent changes have caused the BCM5755 in
my
On Fri Nov 25 01:47:12 EST 2011, cinap_len...@gmx.de wrote:
> drivers should be pretty portable.
>
> there are more drastic changes like the eqlock function
> that touched many places. its basicly a normal qlock()
> that can error() out when the process gets a note or
> gets killed.
ha! i've wr
> A timely discussion before producing any code is usually more profitable.
>
Unarguably. But a code review system makes sure that lack of
discussion is corrected before it is too late. And prior discussion
seems pretty scarce around Plan 9. Unless of course IRC is where it
all happens, in whic
> surely it only makes sense that when forks appear the knives come out.
I guess this is part of the reason I follow 9fans so avidly :-)
++L
> (I know Erik has adopted at least the BCM57xx driver for 9atom). I'm
although it's in there, it doesn't work with the bcm57xx hardware i have.
so cavet emptor.
- erik
surely it only makes sense that when forks appear the knives come out.
A timely discussion before producing any code is usually more profitable.
On 25 November 2011 08:06, Lucio De Re wrote:
> And Code Review ought to be at the core of it.
> That's what I was saying. We are working in nix in such a way that we
> hope the code we are working on could be used by the stock Plan 9
> in the future. So, it's a fork, but we are still trying to cooperate with
> everyone else.
Branching seems to be a black hole, though: there is no easy way
On Fri, Nov 25, 2011 at 9:06 AM, Lucio De Re wrote:
> hereas any changes to
> the original Plan 9 distribution affects my working environment
> directly, which makes it trivial to submit changes if I develop them.
>
That's what I was saying. We are working in nix in such a way that we
hope the co
> Also, we are trying to make our changes in a way that they could
> help the stock distribution, which is, again, what I said would be
> better than doing them in incompatible ways.
I understand this is going to be difficult, I don't expect anyone to
take this on right now, but I still maintain t
I'd like to say here that I'm sorry if my mail in this thread
did hurt any feelings. That was not my aim, again.
I know all of us keep a local copy in one way or another,
but I'd like to suggest that all of us keep on sending patches and
code to bell labs; that's the least we can do, considering t
drivers should be pretty portable.
there are more drastic changes like the eqlock function
that touched many places. its basicly a normal qlock()
that can error() out when the process gets a note or
gets killed.
--
cinap
> theres a new miniport originaly based on the ac97 driver for the
> audio devices.
>
> sb16 driver was rewritten mainly to get interrupt free output
> [... snip ...]
Yeow!
>
> no #P/realmode anymore. no 16bit code in kernel, e820 scan
> done by bootloader.
>
> thats all i can remember for hard
theres a new miniport originaly based on the ac97 driver for the
audio devices.
sb16 driver was rewritten mainly to get interrupt free output
in emulators like qemu and bochs. required minimal changes to
the legacy dma controller code.
hda driver was written from scratch.
all audio drivers suppo
> A handful of device drivers have been written from scratch. Some
> devices started working when their PCI IDs were added to existing
> drivers.
A bit like pulling teeth, isn't it? It is natural to become defensive
of one's efforts, but that also leads to categorising those against
whom defenses
On Thu, Nov 24, 2011 at 9:33 PM, Lucio De Re wrote:
> Out of curiosity: 9front makes high claims about device drivers, are
> these compatible with Plan 9 (and NIX)? If so, is there a list?
A handful of device drivers have been written from scratch. Some
devices started working when their PCI IDs
> I'm impressed by the work Geoff, and others do on Plan9, and I'm not
> talking about 9front at all.
> Jim, Charles, and others made an excellent port for amd64,
> which is cleaner that any other system I've seen. We used that
> as a starting point for nix.
Out of curiosity: 9front makes high cla
22 matches
Mail list logo
