[9fans] Plan9 commercial licenses

[9fans] Plan9 commercial licenses

[Scott]

eld@jewel.ucsd.edu (Eric Dorman) writes:
| Of course, might be slicker to have bitblt code in a userprocess,
| but would there a performance hit?  Might not matter that much.

QNX does that, and apparently works well.  Microkernel, anyone?

 

[9fans] Plan9 commercial licenses

[elliott]

Eric Dorman wrote:
> vsta is very raw, and graphics are nothing compared to anything 'modern'

Neither were Plan 9's, last time I looked.

--
Elliott Hughes - GeneData AG, Postfach 254, CH-4016 Basel, Switzerland
mailto:elliott.hughes@genedata.com  http://users.ch.genedata.com/~enh/

[9fans] Plan9 commercial licenses

[Eric]

> From: jmk@plan9.bell-labs.com
> Date: Tue, 30 Sep 1997 17:19:28 -0400
> Subject: Re: [9fans] Plan9 commercial licenses
> 
> 	[ I'll have to think hard about hacking mmu.c :) .. You're probably
> 	[ right about it being good to force the cards to some base address
> 	[ rather than accepting what PCI autoconf gave us.
> 
> i know this doesn't do you any good (i wish it did) but 10 minutes ago
> i finished hacking the mmu code to let us map the pci devices where the
> bios leaves them. you're pretty much forced to do that if you have pci
> bridges. 

Actually it's good food for thought.  I hadn't thought about bridges
and how they are referred to.  I've been (perhaps unwisely) avoiding
staring real hard at pci as it seems one has to pay for a copy of
the spec.  If it were $25us it wouldn't bug me, but the only thing
i've seen is $100, which is enough to slow me down a bit :)

> the brazil code also has to deal with synchronising the changes to the
> kernel mappings for multiple processors and it still doesn't use 
> interprocessor interrupts.

? Hmm thot one would have to force the cpus to reload their page
tables when they were changed by other cpus, but I'm not sure how 
much table state the average P5 or P6 keeps on-chip.

> --jim
> 

[9fans] Plan9 commercial licenses

[jmk]

	[ I'll have to think hard about hacking mmu.c :) .. You're probably
	[ right about it being good to force the cards to some base address
	[ rather than accepting what PCI autoconf gave us.

i know this doesn't do you any good (i wish it did) but 10 minutes ago
i finished hacking the mmu code to let us map the pci devices where the
bios leaves them. you're pretty much forced to do that if you have pci
bridges. the old code just started allocating unbacked memory after the
end of physical memory for framebuffers and that works ok and is fairly
easy to do.

the brazil code also has to deal with synchronising the changes to the
kernel mappings for multiple processors and it still doesn't use interprocessor
interrupts.

--jim

[9fans] Plan9 commercial licenses

[Eric]

> From: David Hogan <dhog@lore.plan9.cs.su.oz.au>
> Date: Wed,  1 Oct 1997 05:09:50 +1000

[ I'll have to think hard about hacking mmu.c :) .. You're probably
[ right about it being good to force the cards to some base address
[ rather than accepting what PCI autoconf gave us.

> Do you have aux/vga working with the Matrox Millenium?  I'd
> be interested in that, I have one of these cards at work.

Not really; It seemed to me to be pointless to run the card
in VGA emulation (vice native) but then I got stuck on the 
base address problem.  One should, howver, be able to get 1024x768x8
on the card (or whatever fits in exactly 1Mb) by frobbing regs; after 
that it seems you have to go native since you can't map more than 1Mb 
of the framebuffer into the vga aperture; not enough bits in the page reg.

I hope to steal my MGA back soon; I want to get a bit furthur than
I did last time I plinked around with it.  The docs are a tome
but pretty complete at least.

eric

[9fans] Plan9 commercial licenses

[Eric]

> From: jmk@plan9.bell-labs.com
> To: 9fans@cse.psu.edu
> Date: Tue, 30 Sep 1997 15:56:42 -0400
> Subject: Re: [9fans] Plan9 commercial licenses
> 
> 	>Of course, might be slicker to have bitblt code in a userprocess,
> 	>but would there a performance hit?  Might not matter that much.
> 
> % ps | grep bitblt
> jmk          60    1:55   0:45  1304K Read     bitblt
> jmk          61    0:04   0:02  1304K Read     bitblt
> % 

That's nice, but it doesn't do _me_ any good, now does it :)

eld

[9fans] Plan9 commercial licenses

[jmk]

	>Of course, might be slicker to have bitblt code in a userprocess,
	>but would there a performance hit?  Might not matter that much.

% ps | grep bitblt
jmk          60    1:55   0:45  1304K Read     bitblt
jmk          61    0:04   0:02  1304K Read     bitblt
% 

[9fans] Plan9 commercial licenses

[David]

> I got wedged trying to scribble into the Matrox MGA from a user process
> because I couldn't figure out how to wire a user page to a physical
> address that was higher than KZERO (0x8000000).. the PCI bios tends to
> wire my MGA framebuffer to 0xe800000 and segattach won't allow physaddrs 
> that high.  I *could* change the MGAs framebuffer addr but I'd prefer
> to let PCI bios set it up where it thinks is ok (as if pci bioses always
> worked right, heh).

Probably better to set the PCI base addrs yourself -- it's either that,
or else hack around with mmu.c.  I think that the current implementation
only maps 128M of physical space to KZERO; this costs 128K for the pte
mappings.  I think I might have read somewhere that you can map
``big pages'' with a single pte on the intel arch (at least with
recent versions thereof).  Either way, it seems advantageous to
keep the physical address allocation as contiguous as possible
(which means not going with the PCI BIOS allocations).

I have some code which allocates addresses for PCI and PnP
cards, but it's a bit of a mess.  I made this "/dev/cards"
interface which allows accessing the device registers from
user mode; not efficiently, though, you need segattach for
that.  FWIW, I have heard that Brazil has some ``improved
PCI support''.

Do you have aux/vga working with the Matrox Millenium?  I'd
be interested in that, I have one of these cards at work.

[9fans] Plan9 commercial licenses

[Eric]

 
> Date: Tue, 30 Sep 1997 14:20:47 EDT
> From: Scott Schwartz <schwartz@finch.cse.psu.edu>
> 
> eld@jewel.ucsd.edu (Eric Dorman) writes:
>  | sort of arrangement before.
> | Actually I have some of the 16b/32b color fixed: a compiling blit that
> | works for 16b/32b, hooks in devvga, etc.  Have to examine the other
> | parts of libgnot, cope with the colormap stuff, and steal my Matrox MGA
> | back :) .. probably integrate the softscreen and hardscreen somehow..
> 
> Speaking of that, has anyone thought about building chipset specific
> versions of /dev/bitblt?  (i.e. bind /dev/ark2000 /dev/bitblt)
> In a lot of cases you might be able to avoid software bitblt entirely, 
> and use the wizzy hardware instead.

Yes; that's my next thing on the long list of Things I'll Probably
Be Too Tired to Do :)   Another way of doing it (rather than redo
all of bitblt for every hw) would be to have brains in devvga that
knew about chipset features, then make gbitblt() into (*gbitblt)()
(and others for gbline(?), etc) so bitblt will drop into the hw-specific
code instead.

Of course, might be slicker to have bitblt code in a userprocess,
but would there a performance hit?  Might not matter that much.

I got wedged trying to scribble into the Matrox MGA from a user process
because I couldn't figure out how to wire a user page to a physical
address that was higher than KZERO (0x8000000).. the PCI bios tends to
wire my MGA framebuffer to 0xe800000 and segattach won't allow physaddrs 
that high.  I *could* change the MGAs framebuffer addr but I'd prefer
to let PCI bios set it up where it thinks is ok (as if pci bioses always
worked right, heh).

eric

[9fans] Plan9 commercial licenses

[Scott]

eld@jewel.ucsd.edu (Eric Dorman) writes:
 | sort of arrangement before.
| Actually I have some of the 16b/32b color fixed: a compiling blit that
| works for 16b/32b, hooks in devvga, etc.  Have to examine the other
| parts of libgnot, cope with the colormap stuff, and steal my Matrox MGA
| back :) .. probably integrate the softscreen and hardscreen somehow..

Speaking of that, has anyone thought about building chipset specific
versions of /dev/bitblt?  (i.e. bind /dev/ark2000 /dev/bitblt)
In a lot of cases you might be able to avoid software bitblt entirely, 
and use the wizzy hardware instead.

[9fans] Plan9 commercial licenses

[Eric]

> Date: Tue, 30 Sep 1997 10:14:58 -0500
> From: "G. David Butler" <gdb@dbSystems.com>
> To: 9fans@cse.psu.edu
> 
> I have found out that Lucent will not license Plan9 for
> distribution any longer (Inferno is king).

That is sad.  Would've been nice to see Plan9 exploited
in a field app.  I wish I had money to throw at it but my bosses
are pretty much hung up on junk you can buy off-the-shelf and satisfies
the 80/20 solution (eech).

>  As far as commercial
> use goes, they are thinking of either a subscription charge or the
> same terms as before (25,000 +100 per server) without distribution
> rights.

What exactly is a 'subscription charge'?  I've not heard that
sort of arrangement before.

> With that kind of pricing, I'm going to something else.  Any ideas?
> VsTA? FreeBSD? RTEMS? QNX?

vsta is very raw, and graphics are nothing compared to anything 'modern'

I think my problem with the *BSDs is they're still reinventing the 
wheel.  Again.  I'll probably end up using FreeBSD somewhere in my
work (sort-of like ATM machines for healthcare information and imagery), 
mostly 'cuz it's what my boss knows, but also as Plan9 lacks 16b/32b color.

Actually I have some of the 16b/32b color fixed: a compiling blit that
works for 16b/32b, hooks in devvga, etc.  Have to examine the other
parts of libgnot, cope with the colormap stuff, and steal my Matrox MGA
back :) .. probably integrate the softscreen and hardscreen somehow..

> Thanks
> David Butler
> gdb@dbSystems.com

Regards,

Eric Dorman
University of California at San Diego
School of Medicine
edorman@ucsd.edu

[9fans] Plan9 commercial licenses

[Frank]

On Tue, 30 Sep 1997, G. David Butler wrote:

> I have found out that Lucent will not license Plan9 for
> distribution any longer (Inferno is king). 

All that excitement about a program for ordering pizza.
Go figure.

frankg@halycon.com

[9fans] Plan9 commercial licenses

[G.David]

I would like any company that has distribution rights to Plan9
to contact me for license availability.  I want to buy some
licenses to use Plan9 on file and cpu servers.

I have found out that Lucent will not license Plan9 for
distribution any longer (Inferno is king).  As far as commercial
use goes, they are thinking of either a subscription charge or the
same terms as before (25,000 +100 per server) without distribution
rights.

With that kind of pricing, I'm going to something else.  Any ideas?
VsTA? FreeBSD? RTEMS? QNX?

Thanks

David Butler
gdb@dbSystems.com