James Carlson wrote:
> Garrett D'Amore writes:
>
>> Okay, I'm taking the two-functions approach. The following is the
>> revised specification, which addresses all of the issues that you've
>> pointed out so far (I hope).
>>
>
> +1 (with the understanding that there's _no_ commitment to b
Garrett D'Amore writes:
> Okay, I'm taking the two-functions approach. The following is the
> revised specification, which addresses all of the issues that you've
> pointed out so far (I hope).
+1 (with the understanding that there's _no_ commitment to backport).
--
James Carlson, Solaris Netw
James Carlson wrote:
> Garrett D'Amore writes:
>
>> Frankly, this last approach seems the cleanest to me.
>>
>> Any strong opinions one way or the other?
>>
>
> I like the -1 answer, but the two-functions approach works fine as
> well. I don't think either really has architectural implicat
Garrett D'Amore writes:
> Frankly, this last approach seems the cleanest to me.
>
> Any strong opinions one way or the other?
I like the -1 answer, but the two-functions approach works fine as
well. I don't think either really has architectural implications.
--
James Carlson, Solaris Networkin
James Carlson wrote:
>
Drivers that have PPA == ddi_get_instance() may just supply 0 for the
instance.
>>> So you can't override and specify (otherwise legal) instance 0?
>>>
>>>
>> No. I've never seen a situation where this was desireable. Every case
Garrett D'Amore writes:
> James Carlson wrote:
> > Ah, ok. As long as none of the registers can ever legitimately have
> > 0x in them, I guess it's ok.
> >
>
> Well, I suppose some register *could*, but I've yet to see it. The spec
> say that unimplemented registers should return this va
Garrett D'Amore writes:
> > It might be a good idea to return a value outside the 0-0x range
> > for error. I'd use 'int' as the return type and -1 for error.
> >
>
> I could do that. The problem is that usually an error is reported by
> the hardware as 0x. (E.g. if you try to read
Garrett D'Amore - sun microsystems wrote:
> ...
> We're seeking Minor binding at the moment, as we have concrete plans
> to backport this.
If you have concrete plans to backport it, shouldn't you be asking for
patch/micro?
Or did you mean to say that you don't have concrete plans?
I'm not exact
James Carlson wrote:
> Garrett D'Amore writes:
>
>>> It might be a good idea to return a value outside the 0-0x range
>>> for error. I'd use 'int' as the return type and -1 for error.
>>>
>>>
>> I could do that. The problem is that usually an error is reported by
>> the hardware
James Carlson wrote:
> Garrett D'Amore - sun microsystems writes:
>
>> We're seeking Minor binding at the moment, as we have concrete plans
>> to backport this. We do believe that at some point in the future it
>>
>
> As Darren noted, there's a 'not' missing somewhere.
>
>
>> struct mii
Darren Reed wrote:
> Garrett D'Amore - sun microsystems wrote:
>> ...
>> We're seeking Minor binding at the moment, as we have concrete plans
>> to backport this.
>
> If you have concrete plans to backport it, shouldn't you be asking for
> patch/micro?
>
> Or did you mean to say that you don't hav
Garrett D'Amore - sun microsystems writes:
> We're seeking Minor binding at the moment, as we have concrete plans
> to backport this. We do believe that at some point in the future it
As Darren noted, there's a 'not' missing somewhere.
> struct mii_ops {
>int mii_version;
>uint16
[...]
> We're seeking Minor binding at the moment, as we have concrete plans
> to backport this. We do believe that at some point in the future it
[...]
I assume you meant "_no_ concrete plans".
--
This message posted from opensolaris.org
I'm sponsoring this on my own behalf. I think it qualifies for a fast track,
but it might be pushing the limits. I won't be offended if a member
decides otherwise and derails. :-) (Just don't expect *me* to derail it. :-)
And to answer any questions: Yes, I do have a working prototype of this
14 matches
Mail list logo
