[osol-discuss] Re: Proposal to remove /usr/sfw and its dependencies from the base O/S...

2006-03-19 Thread J. Estes
I would have them be completely divorced from the core O/S, such that core utilities like pkgadd/pkgrm are not dependent on 3rd party software, such as libopenssl.so, nor libgcc_s.so. Both /opt/sfw _and_ /usr/sfw should be configurable to be not installed at all, if the person installing it so

[osol-discuss] OpenSolaris Weekly News #4

2006-03-19 Thread Glynn Foster
Hi, Here's OpenSolaris Weekly News #4. As always feedback, or content [from the missing represented communities] welcome. Glynn == John Cui posted [1] about a problem he had hit while trying to get st_ino from stat using DTrace. Chris Gerhard replied [2] that it was because he was trying to co

[osol-discuss] Re: Driver Porting Question

2006-03-19 Thread Artem Kachitchkine
> What, are you kidding me? ;) > > http://lwn.net/Articles/173209/ > > "Stable: Interfaces classified as stable will not break 'for at least > two years', and probably quite a bit longer. The Linux system call > interface is classified in this way" > > [see the ABI stability documentation section]

Re: [osol-discuss] Driver Porting Question

2006-03-19 Thread Erast Benson
On Mon, 2006-03-20 at 12:16 +1200, Glynn Foster wrote: > Hi, > > On Thu, 2006-03-16 at 14:40 -0800, Erast Benson wrote: > > > ALl the more reason for those driver developers to abandon Linux and > > > target OpenSolaris! > > > > Indeed! The question is what we can do to speed up the "conversion"?

Re: [osol-discuss] Driver Porting Question

2006-03-19 Thread Glynn Foster
Hi, On Thu, 2006-03-16 at 14:40 -0800, Erast Benson wrote: > > ALl the more reason for those driver developers to abandon Linux and > > target OpenSolaris! > > Indeed! The question is what we can do to speed up the "conversion"? > > I feel like not all of Linux kernel folks even understand the b

Re: [osol-discuss] About GNOME 2.14 from the JDS team

2006-03-19 Thread Glynn Foster
Hey, On Fri, 2006-03-17 at 17:19 -0800, Rich Teer wrote: > On Fri, 17 Mar 2006, ken mays wrote: > > > Ref: http://dlc.sun.com/osol/jds/downloads/current/ > > > > This is one of those great achievements I like seeing > > within the community when even Sun engineers are > > whipping out the latest

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

2006-03-19 Thread Mike Gerdts
On 3/8/06, Karyn Ritter <[EMAIL PROTECTED]> wrote: > Would something like the table I've just created at > http://www.opensolaris.org/os/bug_reports/oss_bite_size/ help? I need to Very nice view of what is out there. > Please provide comments ideas about this and other ways we can help make > th

[osol-discuss] Re: [powerpc-discuss] OpenBoot on non-SPARC systems?

2006-03-19 Thread Shudong Zhou
There are various projects aiming to replace the BIOS. The following URL provides a very nice summary: http://www.kernelthread.com/publications/firmware/ The article is probably biased toward EFI, but I do think EFI has the momentum and the most powerful backing (Intel and MS). OpenBIOS is att

Re: [osol-discuss] maxphys and sd_max_xfer_size

2006-03-19 Thread Eric Lowe
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

2006-03-19 Thread Eric Lowe
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] Re: Red Hat vs. Sun processor number war: 64:21 - RH wins!

2006-03-19 Thread Bill Walker - Sun Principal Engineer
UNIX admin wrote: ... unfortunately some interviews with AMD staff inidcate that there will be quadcore CPUs from AMD available soon... And where exactly will you get that motherboard that has 8 CPU sockets, > to hit the 32-bit CPU number? Getting even dual socket motherboards for dual cor

[osol-discuss] Re: Red Hat vs. Sun processor number war: 64:21 - RH wins!

2006-03-19 Thread UNIX admin
> ... unfortunately some interviews with AMD staff > inidcate that there > will be quadcore CPUs from AMD available soon... And where exactly will you get that motherboard that has 8 CPU sockets, to hit the 32-bit CPU number? Getting even dual socket motherboards for dual core Opterons is difficu

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

2006-03-19 Thread Holger Berger
On 3/9/06, Eric Lowe <[EMAIL PROTECTED]> wrote: > >> The performance > >> analysis was, as I recall, done mostly using US-III+. > > > > Did this include the concept that dwarfpages (8k) are no longer > > available to both kernel and user land applications? > > I wasn't directly involved in the 64K

[osol-discuss] Re: Red Hat vs. Sun processor number war: 64:21 - RHwins!

2006-03-19 Thread UNIX admin
> Also, ACPI will always be compiled in statically, and > is activated > early > on at boottime, so the number of CPUs is determined > early on. There's an idea: since the Solaris kernel consists of `unix` and `genunix`, why can't the ACPI interpreter be built into the `unix` portion of the ker

[osol-discuss] maxphys and sd_max_xfer_size

2006-03-19 Thread Steven Sim
Hello all; I have always wondered why Sun's default value for maxphys is only 128Kbyte. In these days of EMC and other fibre related storages, it seemingly does not make sense. This above is especially so when sd_max_xfer_size is set to 1 Mbyte by default. Shouldn't the above values all be

Re: [osol-discuss] Red Hat vs. Sun processor number war: 64:21 - RHwins!

2006-03-19 Thread Ian Collins
Andrei Dorofeev wrote: Hi Roland, I didn't try this on a laptop, but here are some numbers from a 2-way AMD system running in 64-bit mode showing how much memory gets used by the kernel in each case. NCPUmax_ncpus kernel 64 2 227MB 21 21 231MB -

Re: [osol-discuss] Red Hat vs. Sun processor number war: 64:21 - RHwins!

2006-03-19 Thread Casper . Dik
>I didn't try this on a laptop, but here are some numbers from a 2-way >AMD system running in 64-bit mode showing how much memory gets used by >the >kernel in each case. > >NCPUmax_ncpus kernel >64 2 227MB >21 21 231MB - stock Nevada bits >64 3