site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- Terry -- Chris 15 maj 2006 kl. 21.55 skrev Terry Lambert: On May 15, 2006, at 12:41 PM, Christer Bernérus wrote: Hi. In what context? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This is somewhat problematic, because you mentioned the cred structure. I assume that the reason it wants this is that it's squirreling away data in the cr_groups list, like AFS does? In general, this information is technically dereferenceable out of the proc structure itself, which has a p->p_pgrp pointer. In practice, it would probably be better, at least until a later release, to pass the PID itself back, and then use the KERN_PROC sysctl from user space to obtain the information on the basis of the PIS of the requesting process. On May 15, 2006, at 2:19 PM, Christer Bernérus wrote: This is within the coda file system kernel extension when the kernel code expects to build a callback message to the userland cache manager. That message is expected to contain an opcode, an unique number, a process ID, a process group id, a session ID and a creds struct. I don't do any userland coding, so I'd like to stick to the already defined protocol. The functions that wants the pgid are typical file system open and close routines. In a kext, it seems like the proc structure is opaque these days. How do I get hold of the pgrp given a proc pointer ? If you are writing a tty driver (for example), it's passed in as part of your context due to the tty line discipline. If you need it for some other reason, can you tell us the reason and the context in which it is needed / will be used? -- Terry This email sent to site_archiver@lists.apple.com