FrankH. wrote:
>And the implementation in usr/src/uts/common/contract/process.c is an
>"always success" one (returns 0), while the one in
>usr/src/uts/common/contract/device.c is an "always fail" one (returns
>ENOTSUP). One wonders - what's the point ? Or what does the original
>poster attempt to
Darren J Moffat wrote:
>But it is:
>
>usr/src/lib/libcontract/common/libcontract.c#200
>
>makes an ioctl call and we end up in:
>
usr/src/uts/common/fs/ctfs/ctfs_ctl.c#208
>
>208 case CT_CNEWCT:
>209 error = contract_newct(ct);
>210 break;
>
>usr/src/uts/common/os/contract.c#contract_newct
>
>582 c
On Tue, 1 Jul 2008, Darren J Moffat wrote:
> Sushant Nirwan wrote:
>> Hi All,
>> I am working on the API(function) of libcontract library libcontract.so.1
>> Testing of the function ct_ctl_newct() and ct_ctl_qack() are always sucess,
>> even when I pass a buggy input to the function it's success
Sushant Nirwan wrote:
> Hi All,
> I am working on the API(function) of libcontract library libcontract.so.1
> Testing of the function ct_ctl_newct() and ct_ctl_qack() are always sucess,
> even when I pass a buggy input to the function it's success.
>
> When i go though the source code I come kno
Hi All,
I am working on the API(function) of libcontract library libcontract.so.1
Testing of the function ct_ctl_newct() and ct_ctl_qack() are always sucess,
even when I pass a buggy input to the function it's success.
When i go though the source code I come know that the implementation of these
