On 03/31/10 01:26 PM, Eric Davis wrote:
>
> Hi Mark,
>
> I work for an IHV and am developing an FCoE driver for a 10Gb converged nic.
> The driver will eventually become part of Solaris but for now we have to
> develop it. :-)
>
> Thanks for the info.
> - e
Ok, if the "will eventually become p
On 03/31/10 12:59 PM, Eric Davis wrote:
>
> For now I've just copied over the entire "include/sys/fibre-channel"
> directly from onnv to my
> live system so I can proceed with development.
>
> Anyone know why these headers aren't installed with the base? Are they
> not officially exposed
> yet o
Guy wrote:
No I downloaded the on-src archive (and also SUNWonbld and on-closed)
For what it's worth, I'm fixing this with
6815619 More informative error when SCM_TYPE is not set
(but not using the suggested fix from the submitter; I plan to roll
together the functionality of "ws" and "bld
> Hi!
>
>
>
> Is there anything like a "wx patch" functionality which applies a patch
> (e.g. the output of "diff -u") to a SCCS/WX-controlled tree and does
> automatically all the add-files/delete-files/change-files operations ?
>
>
>
> Bye,
> Roland
No.
Nothing to keep you from using
>> Okay, thanks for the explanation
>> So I'm still wonder what scripts mentioned by Mark.J.Nelson can setup
>> environment
>> to fix PATH issue for ON building.
>
> I think he meant the ones you pass to nightly(1):
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/env/
Yes.
>> I suspect we still need to change the default PATH environment to use
>> UNIX tool chain instead of gnu tool chain. Otherwise, due to different
>> nm output, libdtracestubs.so will not be correctly created.
> Plus the default of gnu make in the path causes problems as well.
But this stuff (
> I'm very surprised that mercurial is not part of opensolaris 2008.05
Maybe not as surprising when you consider size/download time constraints,
but you're right that it's useful, and must be installed separately.
> Not only is it not a part of opensolaris, it's not even in the package
> dat
> Does this mean that there is no problem with files from portable software that
> are only apparently unreferenced when checking the Solaris platform variant
> but
> ignoring other platforms?
Just to clarify, we're not talking about "apparently" unreferenced files
here. We're talking about fi
> > What about tests that are in ON (e.g. usr/src/cmd/dtrace/test)?
> Interesting question. Tests are currently a "common" exception, but in
> general, if tests are not built, how do we ensure they don't rot? Thus,
> is it prohibitive or otherwise unreasonable to have them be "built" as
> part
>> To have "qfe" devices properly represented by the "qfe" driver, while
>> allowing for "hme" devices to be seen by the "hme" driver, we need some
>> code. The only differences between these two devices are:
>>
>> 1) qfe has a specific parent PCI bridge
>> 2) different Fcode
>>
>> The
"GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
GD> The reason it doesn't lend itself well to short build times, is that
GD> the ruleset requires that make stat() pretty much all possible
GD> locations for the source file (where *any* module might have a
GD> source file) until it finds one
Actually, simple file removals like this occur automatically and don't
require manual package history intervention.
Well, it looks like SUNWtnamd and SUNWtnamr are getting obsoleted, so yes,
we will need a pkghistory file.
Not sure about a package history file, but they'll need a pkgrti.
On Tue, 20 Feb 2007, Dan Price wrote:
Hi folks, I'd like to start codereview for the following wad:
PSARC/2007/045 I2O EOL and EOF
4863632 Hey Hey! Ho Ho! I2O Has Got to Go!
Codereview materials and pointers to the ARC case are posted at:
http://cr.grommit.com/~dp/i2o-del
All relevant
13 matches
Mail list logo
