Sushant Nirwan wrote:
> Hi,
>> Keep in mind that the contract information isn't "stored" in these
>> locations; they are simply two views of the same data.
>
> Thanks for the information but you means to say that contract information
> are not stored in the subdirectory of
> /system/contract/pr
Hi,
>Keep in mind that the contract information isn't "stored" in these
>locations; they are simply two views of the same data.
Thanks for the information but you means to say that contract information are
not stored in the subdirectory of
/system/contract/process/contact_id
So kindly tell me
Sushant Nirwan wrote:
> Hi all,
> I'm having a doubt in the storage structure of created contracts
> in a system. While working, I come to know that the details of the
> contract created are store at different places as below
>
> /system/contract/process/contact_id
> /proc/process_id/contract
Ooops, wrong URL, try this one:
http://cr.opensolaris.org/~gdamore/headers/
Garrett D'Amore wrote:
> I've posted a webrev at http://cr.opensolaris.org/~gd78059/headers
>
> This basically removes some ancient stuff from usr/include/sys/ which
> *nobody* can use, or is using. Most of the headers
I've posted a webrev at http://cr.opensolaris.org/~gd78059/headers
This basically removes some ancient stuff from usr/include/sys/ which
*nobody* can use, or is using. Most of the headers are not referenced
within ON source code at all. (Hmm.. .would be nice to have automatic
checks to find t
On Mon, Jun 02, 2008 at 07:45:04PM -0700, Garrett D'Amore wrote:
> If I had a device driver that, for reasons I won't go into here, needed
> to be STREAMS, could I then add a devmap(9E) entry point to additionally
> support mmap(2)?
>
off the top of my head, i can't think of any fundamental reason
Joerg Schilling wrote:
> "Garrett D'Amore" <[EMAIL PROTECTED]> wrote:
>
>
>> If I had a device driver that, for reasons I won't go into here, needed
>> to be STREAMS, could I then add a devmap(9E) entry point to additionally
>> support mmap(2)? (The problem is that for my project, I may have
James Carlson wrote:
> Garrett D'Amore writes:
>
>> If I had a device driver that, for reasons I won't go into here, needed
>> to be STREAMS, could I then add a devmap(9E) entry point to additionally
>> support mmap(2)? (The problem is that for my project, I may have to
>> support two differ
"Garrett D'Amore" <[EMAIL PROTECTED]> wrote:
> If I had a device driver that, for reasons I won't go into here, needed
> to be STREAMS, could I then add a devmap(9E) entry point to additionally
> support mmap(2)? (The problem is that for my project, I may have to
> support two different semant
Garrett D'Amore writes:
> If I had a device driver that, for reasons I won't go into here, needed
> to be STREAMS, could I then add a devmap(9E) entry point to additionally
> support mmap(2)? (The problem is that for my project, I may have to
> support two different semantics -- one which relie
James Carlson <[EMAIL PROTECTED]> wrote:
> Piotr Jasiukajtis / estibi writes:
> > >> Well, I think it's worse then lack of order in the GNU's parameters.
> > >
> > > Most command line utilities in (Open)Solaris, and other UNIXes will take
> > > arguments in any sequence; the only caveat to that i
Piotr Jasiukajtis / estibi <[EMAIL PROTECTED]> wrote:
> Sean Sprague pisze:
> > Piotr,
> >
> >> Well, I think it's worse then lack of order in the GNU's parameters.
> >
> > Most command line utilities in (Open)Solaris, and other UNIXes will take
> > arguments in any sequence; the only caveat to
Sean Sprague <[EMAIL PROTECTED]> wrote:
> Piotr,
>
> > Well, I think it's worse then lack of order in the GNU's parameters.
>
> Most command line utilities in (Open)Solaris, and other UNIXes will take
> arguments in any sequence; the only caveat to that is when an option
> takes a parameter (eg.
Rich Teer <[EMAIL PROTECTED]> wrote:
> On Fri, 30 May 2008, Piotr Jasiukajtis wrote:
>
> > Hello,
> >
> > $ uname -s
> > SunOS
> > $ /usr/sbin/zoneadm list -cvvv
> > ID NAME STATUS PATH BRAND
14 matches
Mail list logo
