Miles Nordin wrote:
>>>>>> "jcm" == James C McPherson <[EMAIL PROTECTED]> writes:
>
> jcm> Can I assume that my "2008-07-26 post" was in fact two
> jcm> messages that were sent to you and cc'd to zfs-discuss:
> jcm>
> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/049605.html
> jcm> and
> jcm>
> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-July/049607.html
>
> Yeah, the second. I thought your second message was saying there's no
> source for mega_sas. In context, we were following up to an osnews
> forum posting in which some angry person was saying there was no
> source for mega_sas, which you didn't deny and then offered the
> alternate BSD driver, so I got confused.
Ah, ok. That explains things. I remember that posting, and
really not wanting to get involved :)
[snip]
> jcm> I don't know why you would think it might be a shim.
>
> nothing personal about Solaris. people everywhere are getting
> screwed (or at least confused) by shim drivers. Now that free
> software is more mainstream, the attacks on it have become incredibly
> creative, and to my view often very effective.
True, true. To the best of my knowledge, we just don't do
stunts like that with OpenSolaris (or Solaris, for that matter).
Personally, I find the shim concept to be inelegant and almost
always The Wrong Way To Do It(tm).
> jcm> And finally, no, you won't get source for the version which is
> jcm> integrated into a Solaris 10 Update. It shouldn't be too
> jcm> different from the version which is in OpenSolaris, but nobody
> jcm> has ever claimed otherwise. Is this the heart of the problem?
>
> I think it's important, and good that you brought it up. So, the
> source in hg & src.opensolaris.org never includes the Sol10 stable
> branch? I've always wondered that and never been able to figure out
> out. At some point, not necessarily disclosed, the sources currently
> on mercurial will be taken back inside the wall where they'll have the
> bugs thrashed out of them before they become the next release of
> stable Solaris?
Ummm ... kinda yes kinda no. It's more like a fishbone diagram:
(use a monospace font here)
NV builds..X..............Y..............Z..............
\ \ \
S10 Update A S10 Update B S10 Update C
In very general terms, at certain points we take changes
that have appeared in an NV build (X, Y or Z), and backport
some or all of them to the Solaris 10 Update gate. Generally
those changes will be bugfixes, but there are some RFEs
which get backported as well. I wouldn't say that the sources
are "taken back inside the wall" as such, because to me that
implies trying to Close previously Opened code - which we
don't do. Oh, and we thrash out the bugs in NV first - that's
the Release Currently Under Development(tm, etc).
> On Linux, the GPL ensures that you can always get source even for the
> stable version of the OS on which you've bought support, not just the
> development version. Nothing can be ``taken back inside.'' The
> difference is no big deal if your goal is to work on big bugs, or
> contribute new drivers and subsystems to Sun. If your goals are those
> of a modest sysadmin, to fix your own small bugs locally, or disable
> some ZFS sanity check to recover a pool that won't import, no source
> for the stable version does matter.
Yeah, different story to how we're doing things with OpenSolaris,
due mainly to the engineering history and methodology.
> But that wasn't what I was thinking in this thread. I just thought
> there was no source for mega_sas. so... great!
:-)
> I guess the comparison I settled on was Solaris mega_sas vs. Solaris
> domU/Linux {anychip,Sil3124}. I had some other concerns, most
> resolved by other posters' reports and a few not, but no need to
> repeat them.
righto. Personally, I'd go with mega_sas - I've been involved with
the project for quite a while so I've got a bit of bias :)
> If one's been burned enough though, he can always imagine more
> concerns---if it turns out this card has some 1MByte ROM chip running
> a whole proprietary vxworks image, so that even with a free software
> driver you're separated from the SATA interface so much that you can't
> implement new QoS ideas or NCQ or PMP support or fix USCSI/smartctl or
> make a comstar Target Mode, while on cheaper junky chips you can do
> those things....well, at least there's still Sil3124 source too.
True enough. Does VxWorks fit in 1Mb? I've truly got no idea
about it.
> I would say about all my speculative concerns, ``try it and see,'' but
> part of the point I see in this process, is that mainstream users
> should exercise some vigilance to keep space open for a few others on
> the fringe who may be particularly brilliant, motivated, and creative,
> but without others' vigilance hamstrung by having no truly free
> platform. And by the time you've ``tried it and seen,'' you've
> already been fooled into handing over the cash, wasted a bunch of time
> doing work for free without achieving freedom, gotten burned, and the
> OEM's have moved on to the next chip.
Agreed. I've been burnt by that myself - most recently with the
Marvell 88e8040 chip on the motherboard of my Dell laptop.
> I only really want one card that works well and includes source and is
> obtainable in the ballpark of <motherboard cost> * 3, so if this card
> is it, great.
I do think it could fit your requirements.
cheers,
James
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
