May 2005 - Darwin-kernel - lists.apple.com

Re: receiving data with soreceive
by Justin Walker 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 14, 2005, at 15:22, Bijoy Thomas wrote: Are you calling soreceive in an so upcall? If so, try setting MSG_DONTWAIT in the flags, and that should give you everything that is in the so buf at that point. MSG_DONTWAIT tells the socket not to block. For the auio resid, use M_COPYALL. Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- If you're not confused, You're not paying attention -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… What do you mean by so upcall? An "upcall" is techno-speak for a procedure call that, in a sense, reverses the usual flow of control in, say, a network stack. It's also known as a callback, and is a procedure call initiated on the occurrence of an event, e.g., an incoming packet. The procedure to call is usually registered with some kind of call; it's part of the new KPI for sockets, for example. This is an alternative, but keep in mind that using this means that your code has to make sure all the data you need is in place, essentially by reconstructing the incoming packet byte-by-byte (i.e., you need to make sure enough bytes are present to form a valid header so you can read the length, so you can make sure enough bytes are present to process the rest of the packet, ....). It also means you are polling for data, which may not be the best idea. This email sent to site_archiver(a)lists.apple.com

1 0

Re: receiving data with soreceive
by Bijoy Thomas 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Regards, Bijoy Thomas. On May 14, 2005, at 6:23 PM, Justin Walker wrote: On May 14, 2005, at 14:36, Bijoy Thomas wrote: Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- "Weaseling out of things is what separates us from the animals. Well, except the weasel." - Homer J Simpson -------- This email sent to bijoyjth(a)bluebottle.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I am using SOCK_STREAM. What i am trying to do is set up a connection with an ftp server. I call soconnect and then soreceive to get the welcome message. I then send the username and call soreceive to get the message asking for the passwd. Then i send the passwd and call soreceive to get the login message. Each time, the data send by the server varies. How can i tell soreceive to get me whatever data has come upto a maximum length. I am trying to receive data from a server and the maximum length of data it can send is 100 bytes. If i specify auio.uio_resid = 100 and the server sends less than 100 bytes, the soreceive blocks. If i give a small value like 50 and the server sends 75 bytes, i miss out on the remaining 25 bytes. The flag is am using is MSG_WAITALL and I am using mbufs to receive my data. Should i try a soreceive with MSG_PEEK, get the length of data and then use that length to call soreceive? Although you don't say, I gather you are using a SOCK_DGRAM socket, correct? MSG_PEEK is a reasonable way to do this, if your "protocol" gives you the packet length up front. In case no one has mentioned it, you should consider an investment in W. Richard Stevens' books (Unix Network Programming, V1; and TCP/IP Illustrated, V2). They deal with just this kind of issue, the former at user level, the latter in the kernel (although the latter is a "code walkthrough" of an early BSD networking stack, rather than a programming guide). _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/ bijoyjth%40bluebottle.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: receiving data with soreceive
by Justin Walker 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 14, 2005, at 14:36, Bijoy Thomas wrote: Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- "Weaseling out of things is what separates us from the animals. Well, except the weasel." - Homer J Simpson -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… How can i tell soreceive to get me whatever data has come upto a maximum length. I am trying to receive data from a server and the maximum length of data it can send is 100 bytes. If i specify auio.uio_resid = 100 and the server sends less than 100 bytes, the soreceive blocks. If i give a small value like 50 and the server sends 75 bytes, i miss out on the remaining 25 bytes. The flag is am using is MSG_WAITALL and I am using mbufs to receive my data. Should i try a soreceive with MSG_PEEK, get the length of data and then use that length to call soreceive? Although you don't say, I gather you are using a SOCK_DGRAM socket, correct? MSG_PEEK is a reasonable way to do this, if your "protocol" gives you the packet length up front. In case no one has mentioned it, you should consider an investment in W. Richard Stevens' books (Unix Network Programming, V1; and TCP/IP Illustrated, V2). They deal with just this kind of issue, the former at user level, the latter in the kernel (although the latter is a "code walkthrough" of an early BSD networking stack, rather than a programming guide). This email sent to site_archiver(a)lists.apple.com

1 0

Re: receiving data with soreceive
by Bijoy Thomas 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com What do you mean by so upcall? Are you calling soreceive in an so upcall? If so, try setting MSG_DONTWAIT in the flags, and that should give you everything that is in the so buf at that point. MSG_DONTWAIT tells the socket not to block. For the auio resid, use M_COPYALL. HTH. Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2130) iQA/AwUBQoZ0vXnR2Fu2x7aiEQLP8QCeM2wsh6mIbDi514BBMV4MkJtSR/kAoOxB eBJFV8TZ3sJqlN1UzwXqcNW2 =30xf -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: receiving data with soreceive
by Brian Bergstrand 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 14, 2005, at 4:36 PM, Bijoy Thomas wrote: > Hi, > > How can i tell soreceive to get me whatever data has come upto a > maximum length. I am trying to receive data from a server and the > maximum length of data it can send is 100 bytes. If i specify > auio.uio_resid = 100 and the server sends less than 100 bytes, the > soreceive blocks. If i give a small value like 50 and the server > sends 75 bytes, i miss out on the remaining 25 bytes. The flag is > am using is MSG_WAITALL and I am using mbufs to receive my data. > Should i try a soreceive with MSG_PEEK, get the length of data and > then use that length to call soreceive? > Are you calling soreceive in an so upcall? If so, try setting MSG_DONTWAIT in the flags, and that should give you everything that is in the so buf at that point. MSG_DONTWAIT tells the socket not to block. For the auio resid, use M_COPYALL. HTH. Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2130) iQA/AwUBQoZ0vXnR2Fu2x7aiEQLP8QCeM2wsh6mIbDi514BBMV4MkJtSR/kAoOxB eBJFV8TZ3sJqlN1UzwXqcNW2 =30xf -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

receiving data with soreceive
by Bijoy Thomas 14 May '05

14 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, Thanks, Bijoy Thomas. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… How can i tell soreceive to get me whatever data has come upto a maximum length. I am trying to receive data from a server and the maximum length of data it can send is 100 bytes. If i specify auio.uio_resid = 100 and the server sends less than 100 bytes, the soreceive blocks. If i give a small value like 50 and the server sends 75 bytes, i miss out on the remaining 25 bytes. The flag is am using is MSG_WAITALL and I am using mbufs to receive my data. Should i try a soreceive with MSG_PEEK, get the length of data and then use that length to call soreceive? This email sent to site_archiver(a)lists.apple.com

1 0

Re: argument defs for vnode scope callbacks
by Nicolas Berloquin 13 May '05

13 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 11, 2005, at 11:26 AM, Quinn wrote: At 22:49 +0200 10/5/05, Nicolas Berloquin wrote: Is it documented ? Toga Party ! oooooooooooooooooh thanks ^_^ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… We don't yet have any formal documentation. However, I cooked up a quick summary during the Tiger pre-release cycle, and I've included it at the end of this email. I plan to convert this to formal documentation eventually. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tiger kextcache command
by Kevin Van Vechten 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Gilles, - Kevin On May 12, 2005, at 9:08 AM, Garth Cummings wrote: On May 12, 2005, at 1:23 AM, Gilles Vayssié (TRI-EDRE) wrote: Hi, i encounter a problem with the kextcache command under Tiger (8A428). The supported way to do this is: sudo touch /Volumes/ExternalDisk/System/Library/Extensions _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I too ran into this issue while making the Darwin 8.0.1 CDs, where it won't work to simply touch the Extensions directory, since while booting from a CD, the mkext cannot be written back out =). The issue is that kextcache puts a temporary file in /tmp and then attempts to rename it (using rename(2)) to the destination. I assume this is done so that the mkext will be replaced atomically. As you found, this doesn't work so well when the destination is not the root device. The workaround is to set the TMPDIR environment variable prior to running kextcache. Make sure TMPDIR points to a path that is on the same volume as the destination. Also, be sure to specify the correct kernel to use (-K) when you're targetting another volume. Using your example: $ export TMPDIR=/Volumes/ExternalDisk/private/var/tmp $ sudo kextcache -l -K /Volumes/ExternalDisk/mach_kernel -m /Volumes/ ExternalDisk/System/Library/Extensions.mkext /Volumes/ExternalDisk/ System/Library/Extensions I would like to update cache on an external volume. Why? Because on startup, the volume is read online, so the caches can't be updated. So i need to update the cache before booting on this volume, from an "alive" system. Here is how i did under Panther, and it worked well: sudo kextcache -l -m /Volumes/ExternalDisk/System/Library/ Extensions.mkext /Volumes/ExternalDisk/System/Library/Extensions When the volume is next booted, the boot loader will notice that the KEXT caches are out of date and rebuild them. The problem with manually tweaking the caches is that each version of Mac OS X implements a different set of caches, and how they work is considered an implementation detail that developers shouldn't care about. Touching the Extensions directory will assure that the proper caches are rebuilt on all versions of Mac OS X. This email sent to site_archiver(a)lists.apple.com

1 0

Re: argument defs for vnode scope callbacks
by Mike Smith 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 11, 2005, at 6:06 AM, Quinn wrote: At 14:55 +0200 11/5/05, Nicolas Berloquin wrote: Is this completely undocumented, or did I miss a piece of doc ? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… One more question, though : Is it possible to have more specific informations about the auth request, like the real VNOP that was issued and which generated the request ? Not as far as I know. Authorisation happens above, not below the VNOP layer. There's no way of obtaining any sort of "why am I being called" information; authorisation is limited to the actions. This prevents inconsistencies from cropping up if more sources of decisions are added later; the scope of the decision is completely defined. Note that you can get a request with more than one action defined in the vnode scope; this is why they're bitmasked. vnode_if.h lists all kinds of VNOPs that seem to be more finegrained than the bits passed to the callback. I logged the bitfield for each call, and I wasn't able to see when a file gets created for example... You should have seen a write authorization request for the parent directory. However, I should stress that (apart from for the KATH_SCOPE_FILEOP), Kauth is not a notification mechanism, it's an authorization mechanism. Hence you get information about the action being authorized, not the higher-level operation that caused it. Also note that there's no guarantee that there will be an authorisation request for every operation. If a particular credential is granted SEARCH permission on a directory, it may perform many lookups in that directory without the callback being invoked for every one. Be careful with KAUTH_SCOPE_FILEOP too; handlers must behave very cautiously in this scope. In particular, they must not block behind anything that may involve filesystem or paging activity (this includes roundtripping to userspace). One last thing : You say that "There are many other things you can use with VATTR_WANTED." It's not documented, per se, but there's a list in the <sys/ vnode.h> header in the Kernel framework. ... If you look at the VATTR_WANTED macro, you'll see that it ends up referencing these constants by concatenating VNODE_ATTR_ and its argument (eg va_nchildren). These correspond to the field names in the vnode_attr structure; you don't need to stare at those definitions, just look at the structure. This email sent to site_archiver(a)lists.apple.com

1 0

Re: proc_ucred() temporary? What's permanent?
by Mike Smith 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On May 11, 2005, at 5:12 PM, Kevin Brock wrote: Use the kauth interfaces to get credential information: /* for the current context */ extern uid_t kauth_getuid(void); extern uid_t kauth_getruid(void); extern gid_t kauth_getgid(void); extern gid_t kauth_getrgid(void); /* for an arbitrary credential */ extern uid_t kauth_cred_getuid(kauth_cred_t _cred); extern gid_t kauth_cred_getgid(kauth_cred_t _cred); = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… The comment in sys/proc.h above the declaration of proc_ucred() says that it's a temporary API. Getting this information is pretty important to what we're doing... Does anyone know if this is really a temporary API? If it is, does anyone know what the permanent API will look like? /* to get/release a credential */ extern kauth_cred_t kauth_cred_get(void); /* current context, does not take a reference */ extern kauth_cred_t kauth_cred_get_with_ref(void); /* current context, takes a reference */ extern kauth_cred_t kauth_cred_proc_ref(proc_t procp); /* arbitrary proc, takes a reference */ extern void kauth_cred_rele(kauth_cred_t _cred); Note that credentials are immutable; don't mess with their contents or very bad things will happen. The system uniques credentials such that there's only ever one copy of a given cred; if you mung it, you don't just change it for your reference, you change it for everything else that holds the same cred. So don't do it. 8) Also note, since you don't explain why you want the credential, that you shouldn't make any assumptions about the group list in the credential. It doesn't always mean what you think it means. Use the membership functions to test for group membership; this will make you > 16 groups and nested-groups aware. Don't count on being able to get a list of all the groups a uid is a member of; this list isn't available in the kernel, and may be arbitrarily large. This email sent to site_archiver(a)lists.apple.com

1 0