date:20060418

Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation

2006-04-18 Thread Tom Erickson

Sounds like fun.  I'm the Chime project owner, and I think Chime is a
good fit for a student who likes programming in Java.  It's a new
project, so there's lots of ways it can be improved :-)  For example

- A student interested in data visualization could gain experience with
  JFreeChart, a SourceForge project used by Chime, and design some new
  display types besides the existing bar and line graphs.
- There's a client/server prototype optionally used by Chime that
  someone could replace with JMX or cacao or something that supports
  user authentication, etc.
- Chime needs a wizard or Netbeans-style property editor for creating
  new displays (a good chance to get familiar with XML).
- Chime needs a way to playback XML recordings without having to decode
  an entire file into memory all at once.
- Someone might want to make Chime run in a web browser.
- A new set of displays designed specifically to answer questions about
  one aspect of the system could be an interesting project, possibly
  resulting in a new tool separate from Chime.
- More ways to rearrange D programs (or create new D programs) in
  response to GUI gestures could make Chime better at answering
  questions.  Specific dtrace(1M) use cases could provide a useful
  starting point for someone to make Chime follow the same steps more
  easily.
  
The Chime project will be a good introduction to DTrace.  Some of the
ideas above may require expertise from the community or a more specific
problem statement.  Anyone who has tried the tool and has a suggestion,
please share it.

Another idea: Peter Tribble in the observability community has done some
cool work with kstats: http://www.petertribble.co.uk/Solaris/jkstat.html
Someone could build on that to solve a specific observability problem.

Let me know if you'd like me to mock up a Summer of Code page under the
Chime project.

Thanks,

Tom

On Mon, Apr 17, 2006 at 12:19:13PM -0700, Jim Grisanzio wrote:
 hey, guys.
 
 Google has announced its 2006 Summer of Code:
 http://code.google.com/summerofcode.html
 
 This is the second summer where Google has engaged student developers 
 worldwide to participate on a variety of open source projects under this 
 mentoring program. OpenSolaris has applied to be one of those mentoring 
 communities. It's a great way for us to contribute to the greater open 
 source community, while at the same time providing us the opportunity to 
 meet new developers -- especially students -- in new areas. See the 
 details (especially question #2) about mentoring: 
 http://code.google.com/soc/mentorfaq.html
 
 With more than 40 communities and more than 20 projects I think we have 
 more than enough to offer as this point. I'd like to get a thread 
 started here for possible project ideas. We need to act quickly if we 
 want to participate, though.
 
 My initial thought: I think the easiest way to participate is for the 
 OpenSolaris project owners http://www.opensolaris.org/os/projects to be 
 mentors (or identify mentors) to these new student developers. Perhaps 
 we could flush out some ideas in this thread and then the interested 
 projects/owners can mock up their project pages with a Summer of Code 
 section with some items the students can work on. We can then add a box 
 to the front page directing Summer of Code students to those 
 participating projects.
 
 That part is easy. The question is this, though: are there any 
 OpenSolaris projects interested in engaging these students in Google's 
 Summer of code? If so, let's talk about what we could offer. I'll 
 collect the ideas and feed them into our application process.
 
 Please feel free to forward to any list you think appropriate.
 
 Best,
 
 Jim
 -- 
 Jim Grisanzio, Community Manager, OpenSolaris
 http://blogs.sun.com/jimgris/
 ___
 opensolaris-discuss mailing list
 opensolaris-discuss@opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re[2]: [osol-discuss] Project proposal: Nevada Companion Software

2006-04-18 Thread Robert Milkowski

Hello Philip,

Monday, April 17, 2006, 7:19:44 PM, you wrote:

PB On Sat, Apr 15, 2006 at 03:35:52AM +0200, Robert Milkowski wrote:
 
 Saturday, April 15, 2006, 2:27:45 AM, PB writes...
 
 PB Basically, blastwave packages are set up to be binary distributions, not
 PB developer distributions.
 PB If you want to compile other stuff against our packages, you are 
 encouraged
 PB to become a maintainer and add to the collection, using our nice clean
 PB build servers ;-)
 
 Sorry, internal software only.


PB fair enough...


 [...]
 
 What if I want to compile our own software linked with Solaris OpenSSL
 (to get Niagara HW acceleration for example) and linked with other
 open source libraries provided by Blastwave? What if then these
 libraries depend on openssl provided by Blastwave... and things get
 messy here.

PB That does indeed get messy.But the thing is... in a way, this is sun's
PB fault :-) it should provide patches to openssl to enable niagra
PB acceleration, and then blastwave can use those patches, and then blastwave
PB ssl will have that acceleration too.

PB [really, it should give the patches to openssl.org. but barring that,
PB  it would be nice to see a patch set just posted somewhere, like
PB   opensolaris.org]


http://cvs.opensolaris.org/source/xref/on/usr/src/common/openssl/

?

Then Blastwave's OpenSSL is compilled without frame pointers which
makes using DTrace harder...

And I don't know who's fault it is - the point is that Blastwave is
not always a best choice and some kind of competition won't hurt it.
Then I like to have an access to sources (and all things I need to
compile given application the same way it was compiled - I don't know
how it looks right now but it wasn't possible with Blastwave).

ps. and hey, Blastwave is great anyway!

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Re: Re: Re: Solaris on Intel Macs??

2006-04-18 Thread Jürgen Keil

  Hmm, the Intel ICH7 chipset in the Intel iMac seems to suffer from the 
  cntrl sharing DMA engine between channels problem, so that Solaris 
  refuses to use DMA with the HDD:
  
  
  PCI Express-device: pci8086,[EMAIL PROTECTED], pci_pci0
  pci_pci0 is /[EMAIL PROTECTED],0/pci8086,[EMAIL PROTECTED]
  pcplusmp: ide (ata) instance 0 vector 0xe ioapic 0x1 intin 0xe is bound to 
  cpu 1
  pcplusmp: ide (ata) instance 0 vector 0xe ioapic 0x1 intin 0xe is bound to 
  cpu 1
 ATAPI device at targ 0, lun 0 lastlun 0x0
  model MATSHITADVD-R   UJ-846
  ATA/ATAPI-6 supported, majver 0x78 minver 0x0
  IDE device at targ 1, lun 0 lastlun 0x0
  model WDC WD2500JS-40NGB2
  ATA/ATAPI-7 supported, majver 0xfe minver 0x0
  ata_set_feature: (0x66,0x0) failed
  PCI Express-device: [EMAIL PROTECTED], ata2
  ata2 is /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED]
  ATA DMA off: cntrl sharing DMA engine between channels
  PIO mode 4 selected
  Disk0:  Vendor 'Gen-ATA ' Product 'WDC WD2500JS-40N'
  cmdk0 at ata2 target 1 lun 0
  cmdk0 is /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED]/[EMAIL 
  PROTECTED],0
  
  
  Reading from the HDD is killing GUI performance on the iMac, it seems...
   
 
 There's an (supposedly dangerously) hacked ata driver floating around
 hat makes this work OK. Please contact me off-line if you'd like a
 copy of it. The bug that covers this is:
 
 5031379 Toshiba MK6021GAS falls back to pio on HP  Pavilion ze5385us

After reading the relevant parts in the Intel ICH3/4/5/6/7 chipset specs
I found the root cause:

Starting with the ICH4/ICH5, Intel isn't using the PCIIDE_BMISX_SIMPLEX
bit 7 in the ide bus master status register any more.  And starting with the
ICH5(SATA) and ICH6, bit 7 is reused as an additional interrupt status register.
This confuses Solaris' simplex ata controller test, in ata_init_pciide():

http://cvs.opensolaris.org/source/xref/on/usr/src/uts/intel/io/dktp/controller/ata/ata_common.c#2058


For the ICH7 IDE controller device we have (15.2.2):
Bit 7: PRD Interrupt Status (Set when the host controller completes execution
of a PRD that has its interrupt bit set).


For the ICH7 SATA controller (12.2.2):
Bit: PRD Interrupt Status (This bit is set when the host controller execution
of a PRD that has its PRD_INT bit set)

For the ICH5, ICH4,. Intel describes BM IDE status register, bit 7 as
Reserved. Returns 0.
And for the ICH5/SATA controller only: Bit 7 is the PRD Interrupt status.



There is already code in the ata driver to ignore a false pci-ide controller
simplex bit.  For the Intel Mac, we can work around the issue by adding
the following pci-ide-blacklist entry to /platform/i86pc/kernel/drv/ata.conf

pci-ide-blacklist=0x8086,0x,0x27c4,0x,0x20;
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: Re[2]: [osol-discuss] Project proposal: Nevada Companion Software

2006-04-18 Thread ken mays

What many people forget is about the historical trend
of the software development during the last five to
support the latest open source software initiatives
and challenges.

Take for example:

http://www.sun.com/software/star/gnome/

versus

http://dlc.sun.com/osol/jds/downloads/current/

This is the evolution of JDS/GNOME in which the older
Sun GNOME 2.0 supports Solaris 8  9 customers and the
new JDS/GNOME 2.14 supports OpenSolaris Nevada build
34 and above users (not Solaris 8/9/10 users).

A similar thing happened with the KDE for Solaris
project in which maintainers spun off GCC/Sun Studio
versions of KDE and then picked whether they support
SPARCv7/v8/v9 users or UltraSPARC platforms and above
only. Some people were limited by existing build
environments available to them.

So, many things happened for many reasons and
developers grew tired of scouring the Earth looking
for updated Mesa libraries or GNU libraries found on
the BSD/Linux counterparts. So these various
repositories exist for their own reasons - whether due
to 'secret six' pacts or tribal wars.

Nexenta seems to have a nice idea about doing things
the Debian way. I don;t think we should take away from
anyone's 'package store' yet provide a common
'Debian-like' infrastructure focused on porting open
source software to Sun Solaris.

~ Ken Mays



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Re: technical (kernel?) discussion list progress?

2006-04-18 Thread Eric Lowe

Shawn Walker wrote:

I thought the same thing. The first thing I did when I saw the name muskoka being thrown around
was to search for it on wikipedia. While it's cute and all, I relaly think that mailing lists
should have a blindingly obvious title :) The suggested name of, Solaris Kernel Mailing List;
seems rather appropriate.

There is no hidden meaning. I picked muskoka for the project because there
is an internal machine within Sun which serves a similar purpose for
engineering, it has slideware, home pages, etc. - various random things -
hosted there. The name is purposely obscure. It's just meant to be a
hodge-podge repository of random techno-babble. :)

As for the technical discussion list, as I've said before, I don't care
about the means as long as we accomplish the ends. For all I care we can
call it [EMAIL PROTECTED], and as long as everybody knows to go there
for technical questions, spec posts, and RFC submissions.

[EMAIL PROTECTED] does not fit the bill, sorry. Neither does
SKML. The intent was to have a broader-reaching technical discussion list.
Linux is a kernel; OpenSolaris is an *os*. I would like the mailing list
to reflect that difference in reality, although the mission is certainly
similar.

I suggest that, if folks really want a kernel mailing list, we should add
a kernel community. There is plenty of innovation going on in core kernel
infrastructure; I've seen everything from research on queued spinlocks and
mutexes to a suggestion of a dispatcher redesign to a complete virtual
memory system overhaul.

50 matches

Mail list logo