Re: [osol-discuss] VMware published under GPL

> Would it help to ask for a joint Opensolaris.org/VMware project to > port the host OS kernel modules to Opensolaris? The biggest hurdle isn't porting the kernel modules, but rather the gazillion components that make up the UI, daemons, etc. Since these components need to build under the VMware

Re: [osol-discuss] Project proposal: 64k kernel project

Frank Hofmann wrote: How would this work with network I/O? Do the IOMMUs support 64k pages? AFAIK yes Yes. I remember I/O (both the ingraindness of MAXBSIZE in segmap and the segmap needs to die a slow, miserable death. exposure of PAGESIZE via VOP_GETPAGE) was a big killer argument agai

[osol-discuss] QEMU project is open for business

The QEMU project is live and open for business. http://www.opensolaris.org/os/project/qemu/ The QEMU project provides a centralized place for documentation, support, and further OpenSolaris-related development of the QEMU virtual machine. For those of you who don't know what it is, QEMU is a

[osol-discuss] Project proposal: DMA Memory Infrastructure project

I propose a virtual memory project, DMA Memory Infrastructure (DMI for short). This project will provide infrastructure to: - Allocate physical memory in contiguous [1], large page [1], or small page-size chunks within device address constraints - Lock and unlock the allocated memory pages and

[osol-discuss] Re: Community Proposal: Gardeners

> I would like to propose a new community called > "Gardeners" based on > some recent discussions on opensolaris-code. [1,2] ... I think this is great. +1 > - Care and feeding of the build process Any improvements in this area would be greatly appreciated. In particular, my personal nit is

Re: [osol-discuss] Project proposal: qemu

Someone please yes yes ... get Martin involved. The guy rocks. Also .. has anyone heard from Ben Taylor ? Yep, I had a thread offline, he's buried right now after coming back from an extended vacation. - Eric ___ opensolaris-discuss mailing list

Re: [osol-discuss] Project proposal: qemu

Martin Bochnig wrote: History: .. Wow this is great information, I'll be sure to archive this. Though the sparc host support currently in qemu's cvs still misses a few things. I will release a new patch as soon as I come to that (after certain other public launches). As well as upgrading my

Re: [osol-discuss] Project proposal: qemu

Dennis Clarke wrote: However, here comes the tough part, is anyone upstairs in the corner office doing anything to get VMWare running on Solaris 10 ? I know that Andy Tucker has shuffled over to VMWare and he must be doing some sort of magic there. Or is it a Windows and Linux club only? I jus

[osol-discuss] Project proposal: qemu

I propose a qemu project. This project will contribute and support on an on-going basis: - A kernel accelerator module for kqemu - Support for building 64-bit qemu out of the box (kernel accelerator requires this on AMD64) - Support for building qemu with Sun Studio 10 and 11 compilers - Support

Re: [osol-discuss] ONNV -> ON community renaming proposal

Danek Duvall wrote: I'd like to propose that we rename the "onnv" community to be the "on" community. The original name is more suitable for a project (a proposal for which is to be made shortly), but we didn't have the infrastructure at the time to do the right thing. +1 And while you're at

Re: [osol-discuss] missing process/system metric?

[EMAIL PROTECTED] wrote: I think we need a clearer definition of the problem and whether we, given the constraints of the current VM system, can actually achieve knowing this metric; and if not, what alternative metric we do want. And whether we want the new VM system to do such accounting prope

Re: [osol-discuss] Ultra 20 CD/DVD burning probs

Rich Teer wrote: This is a weird one: burning CDs and DVDs in my Ultra 20 is a crapshoot. Sometimes it works, and sometimes it doesn't. The Ultra 20 is using the DVD-RW drive that Sun shipped with it, and I'm using the latest BIOS and b42a of Nevada. The media I'm trying to burn is brand new M

Re: [osol-discuss] Re: [ufs-discuss] Generic "filesystem code" list/community for opensolaris ?

Joerg Schilling wrote: Does this mean you don't like the generic fs community because the current comunity structure is wrong and you cannot change that? Let me try to articulate my concerns a little better. I'm 100% in favor of having an FS community. I've also mentioned many times I would l

Re: [osol-discuss] Re: [ufs-discuss] Generic "filesystem code" list/community for opensolaris ?

Rainer Orth wrote: * Therefore, an alternative model would be to use the storage community (given that block and object based storage are getting closer recently, cf. the object storage devices work for SCSI) as an umbrella for both block-based storage (e.g. iscsi, svm projets, maybe others?) and

Re: [osol-discuss] Re: [ufs-discuss] Generic "filesystem code" list/community for opensolaris ?

Rainer Orth wrote: Alternatively, the following more general proposal http://www.opensolaris.org/jive/thread.jspa?messageID=28219渻 might be worth consideration. The ultimate outcome of that discussion was that it was decided that opensolaris-code would not be removed as was planned,

Re: [osol-discuss] Re: [ufs-discuss] Generic "filesystem code" list/community for opensolaris ?

Frank Hofmann wrote: sorry opensolaris-discuss, this originally bounced. Trying again. We're proposing a generic "fs-discuss" for OpenSolaris. Any reason why we shouldn't have a generic filesystem community? You're proposing a discussion list, plus there is work afoot by yourself and possibl

Re: [osol-discuss] Sun ce port GLDV3 Drivers

Cathy Zhou wrote: Steven Sim wrote: Hello; I have pushed for the usage of dladm for link aggregation (trunking) at my customer's site only to have egg on my face when I discovered the only network port with GLDV3 interface (necessary for link aggregation) is bge. The ce port is extensively

Re: [osol-discuss] Network Device Drivers tosibha laptop m105-s3011

Rajeev wrote: Dear All, Does anybody know where to get the drivers for... 1. Intel(R) PRO/Wireless 3945ABG Net To my knowledge nobody has this working with ndisulator yet. I'm trying to hack ndisulator enough to get it working on my Sony SZ-140 since it has the same card, I've gotten close

Re: [osol-discuss] Project proposal: NFS/RDMA

Spencer Shepler wrote: I would like to propose the creation of an NFS/RDMA project to be affiliated with the OpenSolaris NFS community. The purpose of this project is to update the existing NFS/RDMA(Infiniband) support in OpenSolaris to match the most recent Internet Drafts on the topic. It wo

Re: [osol-discuss] Project proposal: NTP

Rainer Orth wrote: We propose the creation of an NTP project on OpenSolaris.ORG, affiliated with the Nevada and Device Driver communities. Seconded. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Distributed File System for Solaris

Andrew Watkins wrote: I don't see why CacheFS can not work in this situation, so that if there is a local version of the file use it and not just hang... I don't think CacheFS is a good match here. There is a "disconnected mode" where the server isn't consulted, but in my experience you ca

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

Moazam Raja wrote: I guess the reference to "[EMAIL PROTECTED] " in the announcement left some people confused and thinking that this was the new list previously being discussed in this thread. Wow...even that sounds confusing. I suppose the confusion isn't surprisin

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

Dan Price wrote: You said: "as long as everybody knows to go there for technical questions, spec posts, and RFC submissions". That sounds like you're spreading your project's wings out over the charter of other communities and projects. That certainly wasn't the intent. I haven't seen complain

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

Dan Price wrote: On Tue 18 Apr 2006 at 08:32AM, Eric Lowe wrote: 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

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

[EMAIL PROTECTED] wrote: I believe it adds a barrier to entry for those willin gto participate and not knowing where to look. It seems as if a lot of high technical, interesting, content may be hidden under the muskoka cloak. A name is just a name; we could change it to something less hidden l

Re: [osol-discuss] [Fwd: OpenSolaris attacked by Novell]

__ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Eric Lowe Solaris Kernel Development Austin, Texas Sun Microsystems. We make the net work. x40577/+1(512)366-9080 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org

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

To specifically address your question: Also, the project seems to have mixed together the idea of a discussion, virtual memory changes, and a library. Wouldn't it make more sense to have a library project which is separate, and a VM project which is also separate? The muskoka project is meant

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

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

Re: [osol-discuss] Re: Re: Build times for Open Solaris....

Michael Pogue wrote: Do you think it's possible to change the build, such that more can go on in parallel? Or, are there some limiting steps that are hard to eliminate (if so, where do you think they are?)? Our build system does the dependency analysis depth-first. Let's say I want to do an i

Re: [osol-discuss] Infrastructure clarification request, 4/13

Al Hopper wrote: On Thu, 13 Apr 2006, Nils Nieuwejaar wrote: On Thu 04/13/06 at 09:13 AM, [EMAIL PROTECTED] wrote: There are a couple of requests I need to get more specific instructions on. Specifically, unassociated mailing lists are expensive for support (because we hadn't intende

Re: [osol-discuss] However, the zfs file system /export/zfs_0 must be shared ?? What ?

Darren J Moffat wrote: So I setup the share manually in /etc/dfs/dfstab thus : # vi /etc/dfs/dfstab "/etc/dfs/dfstab" 1 lines, 97 characters share -F nfs -o ro=isis,root=isis -d "jumpstart" /export/zfs_0/jumpstart/s10/SXCRb35 So why did you do that rather than what it suggested you should do w

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

Al Hopper wrote: On Tue, 11 Apr 2006, Eric Lowe wrote: Peter Buckingham wrote: There was some discussion about having a more technical mailing list/community ala freebsd hackers/lkml/... Was there any progress made on that? I'm definitely interested in discoverying/learning more abou

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

Peter Buckingham wrote: There was some discussion about having a more technical mailing list/community ala freebsd hackers/lkml/... Was there any progress made on that? I'm definitely interested in discoverying/learning more about the internals of Solaris. It has been discussed, but there is

Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize

Hi, Roland Mainz wrote: serious cycles on this though we'd like to, and the folks who were in involved in 64K simply don't have any interest in working on this in the open. Why ? What do they fear ? Being swamped&overburned with too many emails or what ? This is a community -- it's up to the

Re: [osol-discuss] Re: RFE: /etc/system tuneabletosetthedefaultpagesize

Roland Mainz wrote: ... delay the project proposal until it is clear that Sun actually releases the patches for their work. Starting from scratch without help from Sun will be much harder. Just a quick note to say I haven't dropped this on the floor. Please give me some time to look into this. N

Re: [osol-discuss] Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Just a quick note to say I haven't dropped this on the floor. Please give me some time to look into this. Nobody else on the VM team wanted to help look into this right now and I'm buried in other stuff through next week. - Eric Holger Berger wrote: On 3/24/06, Eric Lowe <[EM

[osol-discuss] Muskoka project proposal

The Muskoka project is a collaborative technical bulletin board for contributors to post and archive any technical content which otherwise does not have a logical home on OpenSolaris.org. Currently, this content lives mostly in blog-space or on wikis; we believe a centralized repository will be

Re: [osol-discuss] Re: RFE: /etc/system tuneabletosetthedefaultpagesize

We really ought to ship a debugging C library people could run for development purposes, a C library which: Yep, the equivalent of kmem_flags for userland. I like it. - dies if the qcmp function passed to qsort() isn't correct. - doesn't have any of the backward compatibility w

Re: [osol-discuss] Re: RFE: /etc/system tuneabletosetthedefaultpagesize

David S. Miller wrote: The filesystem issues are the worst part of a larger default page size, for sure. You can waste more than half of your ram when doing something as simple as grepping around in a big source tree with 64K vs 8K pages. I posted some example numbers for doing that in the Linu

Re: [osol-discuss] Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Roland Mainz wrote: Aside from the apps that broke the next largest drawback seen with the 64K prototype kernels was that when you have only 64K pages, if you touch 8K in the middle of a mmap() region you end up writing back 64K to the backing store. If you do this enough (which some apps do) you

Re: [osol-discuss] Re: RFE: /etc/system tuneable to set thedefaultpagesize

Roland Mainz wrote: That's correct, though there were some pretty sticky issues with MAXBSIZE since the filesystems (UFS, probably others) assume (wrongly) that MAXBSIZE is PAGESIZE. Obviously when you up the PAGESIZE this isn't true anymore, so some code had to be added to make the filesystem un

Re: [osol-discuss] Re: RFE: /etc/system tuneabletosetthedefaultpagesize

It's great to see this thread still living on. Clearly there is a lot of interest here, which is exciting in a geeky-sort of way. :) AFAIK such applications (with statically linked system libraries) are not supported on Solaris since a while so we do not have this problem anymore. Neither does

Re: [perf-discuss] Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Eric Lowe wrote: Holger Berger wrote: I wasn't directly involved in the 64K prototype but only 64K and larger were used for user applications, and the page_t was 64K in span (PAGESIZE=65536). There may have been some 8K mappings in the kernel due to OBP handing off translation lists

Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Holger Berger wrote: I wasn't directly involved in the 64K prototype but only 64K and larger were used for user applications, and the page_t was 64K in span (PAGESIZE=65536). There may have been some 8K mappings in the kernel due to OBP handing off translation lists with holes -- I don't remember

Re: [osol-discuss] Features found in other OS you'd like to see in Solaris

okay, we've just seen some strange problems without swap. i haven't had time to look into why, so we are just going to use swap anyway for now. Please let us know you perceive to be "strange issues" are. Solaris virtual memory is designed to work just fine without swap space. It's not pretty w

Re: [osol-discuss] Re: Features found in other OS you'd like to see in Solaris

Eric Boutilier wrote: I'd like to have "virtual consoles" like the ones Linux has (at least on x86). Of course one could use "screen", but generally CTRL+A hotkey interferes with e.g. bash hotkey to move to the first character in the cmd-line (yes, ctrl+a, a is a workaround - but nothing mor

Re: [osol-discuss] Re: Re: Re: Features found in other OS you'd like to see in Solaris

Having general memory protection in the kernel (such that a "crashed" driver can be known not to have damaged anything else) sounds like an interesting project, but nowhere near where we are today. .. and on some architectures like SPARC (sun4u at least) it's virtually impossible to pull off an

Re: [osol-discuss] maxphys and sd_max_xfer_size

Steven Sim wrote: Hello all; I have always wondered why Sun's default value for maxphys is only 128Kbyte. ... The fact that we still have kernel tunables for things like this makes me want to check myself into the looney bin. We could up them now, but how do we know the values are optimal

Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Holger Berger wrote: I wasn't directly involved in the 64K prototype but only 64K and larger were used for user applications, and the page_t was 64K in span (PAGESIZE=65536). There may have been some 8K mappings in the kernel due to OBP handing off translation lists with holes -- I don't remember

[osol-discuss] Re: [request-sponsor] Re: Contributing Code

> Would there be a way to get a list of bugs that are > older than some number (say a year or so), getting > basically no attention, and are likely to be > relatively > manageable? If there is a particular area you are interested in contributing, you could request that someone who works in that a

Re: [osol-discuss] opensolaris-{code, rfe, bugs} (was Community proposal: solaris-internals)

Al Hopper wrote: On Thu, 16 Mar 2006, Mike Kupfer wrote: I think opensolaris-code can just go away. It was originally created Agreed. during the Pilot program, when there was a single consolidation and a lot fewer people. When I proposed it, I thought of it as a stopgap measure to deal wi

Re: [osol-discuss] Community proposal: solaris-internals

Rainer Orth wrote: Eric Lowe <[EMAIL PROTECTED]> writes: What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? Speaking of which, it occured to me recently, when I po

Re: [osol-discuss] Community proposal: solaris-internals

Jim, Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe "Core OS" or something? Even at that, I think it's really quite vague and likely implicitly refers to inter

Re: [osol-discuss] Re: Community proposal: solaris-internals

> I disagree about the project docs. I think project docs should live with > the projects. That's where the conversations and collaboration are > taking place. I do agree that there should be a top-level link to docs > from the opensolaris.org home page. As one of the proposers let me add my tho

Re: [osol-discuss] Community proposal: solaris-internals

Then you'ld have to define "OS." The official definition of the Solaris Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe "Core OS" or something? Yes, core OS -

[osol-discuss] Re: opensolaris-{code, rfe, bugs} (was Community proposal: solaris-internals)

Mike Kupfer wrote: I think opensolaris-code can just go away. It was originally created .. I'd like to see opensolaris-bugs and opensolaris-rfe go away, too. Bugs and RFEs should get posted to the bug database, not mailing lists. Agreed. - Eric _

Re: [osol-discuss] Community proposal: solaris-internals

So let me propose: - Rename and refactor the 'onnv' community into 'os-net' or some such. Remove its logical binding to the nevada release train. There is already a separate community for networking, so if we go that route I think this community should just be for the OS par

Re: [osol-discuss] Community proposal: solaris-internals

Things were setup that way before projects existed and everything had to be a community. The "Nevada" community (which is misnamed to begin with), should become a ONNV project of an ON community which could also host your internals information. ... and proposed discussion list(s). Agreed,

Re: [osol-discuss] Community proposal: solaris-internals

nals documentation and provide a one-stop shop for system internals (aside from buying the book). -- Eric Lowe Solaris Kernel Development Austin, Texas Sun Microsystems. We make the net work. x40577/+1(512)366-9080 ___ op

Re: [osol-discuss] Unifying configuration files management / use

Yann POUPET wrote: why not having a lib function that would help3 parsing/reading/writing such a file ? With a configuration file such as the example above, one could think about a function that would return the value of arg1 arg = cfgfile_readparam("/file/location",param1) We could also have a

Re: [osol-discuss] Re: RFE: /etc/system tuneable to set the defaultpagesize

Holger Berger wrote: To make matters worse, Solaris (unlike many other OS's) ties page_t structures to particular physical addresses, and there is plenty of code that assumes p_pagenum can't change even if the page isn't locked. This complicates the issues of separating out the "page size" the us

Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Holger Berger wrote: US3 only has one TLB set with 512 entries for 8k pages. US3+ improved this by the addition of another TLB set with 512 entries for 4M pages - anything between these points - 64k and 512k pages - was ignored. Today this design shows it's drawbacks as "automatic" MPSS has only

Re: [osol-discuss] Re: Re: RFE: /etc/system tuneable tosetthedefaultpagesize

Hello, [...] Comparing SF68k/SF15k with Niagara is problematic. The broken MMU design in the US3/4 CPU models used in these machines is not able to use a significant amount of 64k pages. If you still got a small performance win there then this would prove that an all-64k kernel has significant pe

Re: [osol-discuss] Re: RFE: /etc/system tuneable tosetthedefaultpagesize

latforms with better cache associativity and larger memory. This approach may be tenable. I also disagree with Eric Lowe about the usefulness of increasing the base page size. It's very useful, and that's why we have several platforms under Linux which have moved up to a default pa

Re: [osol-discuss] Re: RFE: /etc/system tuneable to setthedefaultpagesize

Roland Mainz wrote: This could be very unfortunate since it limits future development (at least for Solaris... other operating systems like Linux are likely not affected, right ?). The decision may be acceptable today - but in twenty years it _may_ become a real problem - assuming the "optimum" p

Re: [osol-discuss] Re: RFE: /etc/system tuneable to set thedefaultpagesize

be any deviation from these page sizes in the forseeable future. -- Eric Lowe Solaris Kernel Development Austin, Texas Sun Microsystems. We make the net work. x40577/+1(512)366-9080 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org

[osol-discuss] Re: RFE: /etc/system tuneable to set the defaultpagesize

> > but there's too much code out there that just breaks. The >> programmers made implicit assumptions about the approximate >> size of a page, and that was that. > > Which code breaks ? Userland or kernel code ? Was Userland. The problem is that mmap() exposed too much detail and as a result a

Re: [request-sponsor] Re: [osol-discuss] Contributing Code

y done by the gatekeepers after the close of the build as noted earlier. One other problem that I've noticed is that for bugs which have an external contributor assigned you can't see the external contributor in the bug report view. Instead you have to search the list of sponsored bu