August 2005 - Darwin-kernel

Re: using bless to change boot device
by Justin C. Walker 20 Aug '05

20 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 19, 2005, at 22:28 , Herbert wrote: HTH. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- When LuteFisk is outlawed, Only outlaws will have LuteFisk -------- _______________________________________________ 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.… No, I'm not root, it's an admin account. I had hoped you didn't need to be root to do it. Ah, nope...the admin account only gives you the opportunity to become root, to do things like this. To be clear: when using an admin account: - GUI (Aqua) apps will give you the option to do admin things, and this is generally indicated by the presence of the lock. - command line apps can be executed as root, but only if you use 'sudo' (or 'su'). There is (generally) no connection between the admin state of GUI apps and the command line. In addition, note that when you have been authenticated in a GUI app, the actual operations are carried out not by the app, but by another process (a daemon or faceless app). This email sent to site_archiver(a)lists.apple.com

1 0

Re: using bless to change boot device
by Herbert 20 Aug '05

20 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 19, 2005, at 9:29 PM, Justin C. Walker wrote: On Aug 19, 2005, at 21:03 , Herbert wrote: bless -mount "/Volumes/My iPod/" -setBoot nvram: Error (-1) setting variable - 'boot-device' /usr/sbin/nvram returned non-0 exit status Can't set Open Firmware Regards, Justin -- Justin C. Walker, Curmudgeon-at-Large /~\ The ASCII \ / Ribbon Campaign X Help Cure HTML Email / \ This email sent to herbylovebug(a)shaw.ca _______________________________________________ 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.… No, I'm not root, it's an admin account. I had hoped you didn't need to be root to do it. I'm trying to use bless to change the boot device. Below is what I get. A shot in the dark: are you doing this as root (sudo bless ...)? In order to write the nvram, you do need to be root. The Lock is set (closed) in System Utilities, so I have to click on it and enter my password. I tried unlocking it before using bless but no joy. I think the lock in this case just controls what you can do with the "System Utilities" (you mean the Startup Disk panel in System Prefs??). It has no effect on what happens on the command line. I think this may be the problem but I'm not sure. I can't remember how to turn that lock to "off" permanently. Can anyone else? The lock is 'open' for me (on the few panels I checked). I don't know how to control that, though. _______________________________________________ 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/herbylovebug% 40shaw.ca This email sent to site_archiver(a)lists.apple.com

1 0

Re: using bless to change boot device
by Justin C. Walker 20 Aug '05

20 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 19, 2005, at 21:03 , Herbert wrote: bless -mount "/Volumes/My iPod/" -setBoot nvram: Error (-1) setting variable - 'boot-device' /usr/sbin/nvram returned non-0 exit status Can't set Open Firmware Regards, Justin -- Justin C. Walker, Curmudgeon-at-Large /~\ The ASCII \ / Ribbon Campaign X Help Cure HTML Email / \ _______________________________________________ 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'm trying to use bless to change the boot device. Below is what I get. A shot in the dark: are you doing this as root (sudo bless ...)? In order to write the nvram, you do need to be root. The Lock is set (closed) in System Utilities, so I have to click on it and enter my password. I tried unlocking it before using bless but no joy. I think the lock in this case just controls what you can do with the "System Utilities" (you mean the Startup Disk panel in System Prefs??). It has no effect on what happens on the command line. I think this may be the problem but I'm not sure. I can't remember how to turn that lock to "off" permanently. Can anyone else? The lock is 'open' for me (on the few panels I checked). I don't know how to control that, though. This email sent to site_archiver(a)lists.apple.com

1 0

using bless to change boot device
by Herbert 20 Aug '05

20 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I'm trying to use bless to change the boot device. Below is what I get. bless -mount "/Volumes/My iPod/" -setBoot nvram: Error (-1) setting variable - 'boot-device' /usr/sbin/nvram returned non-0 exit status Can't set Open Firmware The account I'm doing it from is an admin account. Open Firmware does not have a password set. Any ideas? _______________________________________________ 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 device I'm trying to set it to is an iPod, but it's got Tiger installed on it, and it does indeed boot from it when I use the system preferences panel. The Lock is set (closed) in System Utilities, so I have to click on it and enter my password. I tried unlocking it before using bless but no joy. I think this may be the problem but I'm not sure. I can't remember how to turn that lock to "off" permanently. Can anyone else? This email sent to site_archiver(a)lists.apple.com

1 0

Re: kern_control question
by Terry Lambert 19 Aug '05

19 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Peter, Because: - it will just not work - the missing API will be listed in the list of missing symbols On the other side: - the kernel will load So you can: (b) get try-time notification, and do a lazy-fallback (d) not use the extension and not worry about it -- Terry _______________________________________________ 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.… On Aug 19, 2005, at 2:33 AM, Stephane Sudre wrote: On 19 août 05, at 1:15, Terry Lambert wrote: On Aug 18, 2005, at 2:18 AM, Stephane Sudre wrote: On 17 août 05, at 22:16, Vincent Lubet wrote: In fact, starting with Mac OS X 10.4.2, a call to getsockopt() on a kernel control socket will copy the user data into the kernel buffer. This should provide for the read/write behavior you're looking for. I'm not sure to fully understand the logic in changing the getsockopt behavior instead of just introducing a new API. I mean: what is the purpose of the KPIs if you still need to hack the APIs? - this introduces incompatibilities with previous release of the OS. It's working on 10.4.2 but not on 10.4. So adding a new API would have just been fine. If we add a new API to the KPIs in 10.4.2 and it's not in 10.4.0 or 10.4.1, then any KEXT using the new API will not run on 10.4.0 or 10.4.1 because of link errors when it is attempted to be loaded. [...] I think we're seeing the problem from 2 different sides: you're seeing it from the point of view of a person who knows a specific behavior only works from a specific release of the OS while I'm seeing it from the one of a person who would not know about it and consider that the behavior available on a specific release is available to previous releases. >From my side, if the kernel does not load, then it quite clearly indicates where the problem lies as: - there's no fast way to know where a problem lies if something bad happens. Since it's working on 10.4.2, why would someone automatically suspect where the problem is? I agree to the first statement: there's no fast way, unless the kext checks the soft version number and fails to load itself. As to the question: the KEXT gets an error return from a function call, and handles it properly... I do agree on the version restriction. But this is somehow an egg and chicken problem as how would you know you need a restriction when there's no way to know there is one? Because there isn't a restriction unless you use an undocumented interface extension. 8-). (a) get load-time notification so the kext can go into fall-back mode without having to "try it first" (c) get a load-refusal if the version isn't high enough, and you don't have a fallback Actually, the worst thing that's been said in this whole thread is documentation of an undocumented interface extension -- you should have had to contact DTS for the information, and been told about your options on using it so this whole thing wouldn't show up in a search engine some place, where people don't read the whole discussion, and decide to use it, not knowing the restrictions. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kernel panic - freeing free mbuf
by Michael Cashwell 19 Aug '05

19 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.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.… This email sent to site_archiver(a)lists.apple.com

1 0

kernel panic - freeing free mbuf
by Russell Seehafer (RIT Student) 19 Aug '05

19 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcWk3lC+20u00xhwQbWHCn7nCA0zPg== Thread-topic: kernel panic - freeing free mbuf _______________________________________________ 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: kern_control question
by Stephane Sudre 19 Aug '05

19 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 19 août 05, at 1:15, Terry Lambert wrote: Peter, Because: - it will just not work - the missing API will be listed in the list of missing symbols On the other side: - the kernel will load _______________________________________________ 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.… On Aug 18, 2005, at 2:18 AM, Stephane Sudre wrote: On 17 août 05, at 22:16, Vincent Lubet wrote: In fact, starting with Mac OS X 10.4.2, a call to getsockopt() on a kernel control socket will copy the user data into the kernel buffer. This should provide for the read/write behavior you're looking for. I'm not sure to fully understand the logic in changing the getsockopt behavior instead of just introducing a new API. I mean: what is the purpose of the KPIs if you still need to hack the APIs? - this introduces incompatibilities with previous release of the OS. It's working on 10.4.2 but not on 10.4. So adding a new API would have just been fine. If we add a new API to the KPIs in 10.4.2 and it's not in 10.4.0 or 10.4.1, then any KEXT using the new API will not run on 10.4.0 or 10.4.1 because of link errors when it is attempted to be loaded. [...] I think we're seeing the problem from 2 different sides: you're seeing it from the point of view of a person who knows a specific behavior only works from a specific release of the OS while I'm seeing it from the one of a person who would not know about it and consider that the behavior available on a specific release is available to previous releases. >From my side, if the kernel does not load, then it quite clearly indicates where the problem lies as: - there's no fast way to know where a problem lies if something bad happens. Since it's working on 10.4.2, why would someone automatically suspect where the problem is? I do agree on the version restriction. But this is somehow an egg and chicken problem as how would you know you need a restriction when there's no way to know there is one? This email sent to site_archiver(a)lists.apple.com

1 0

Re: kern_control question
by Terry Lambert 18 Aug '05

18 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Peter, Because: -- Terry _______________________________________________ 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.… On Aug 18, 2005, at 2:18 AM, Stephane Sudre wrote: On 17 août 05, at 22:16, Vincent Lubet wrote: In fact, starting with Mac OS X 10.4.2, a call to getsockopt() on a kernel control socket will copy the user data into the kernel buffer. This should provide for the read/write behavior you're looking for. I'm not sure to fully understand the logic in changing the getsockopt behavior instead of just introducing a new API. I mean: what is the purpose of the KPIs if you still need to hack the APIs? - this introduces incompatibilities with previous release of the OS. It's working on 10.4.2 but not on 10.4. So adding a new API would have just been fine. If we add a new API to the KPIs in 10.4.2 and it's not in 10.4.0 or 10.4.1, then any KEXT using the new API will not run on 10.4.0 or 10.4.1 because of link errors when it is attempted to be loaded. The entire intent of the KPIs is to ensure binary compatibility for KEXTs. Adding a new API breaks this. Adding new behaviour to an existing API doesn't break this, unless someone insists on using the new behaviour. If we went around adding APIs willy-nilly, then there would be no reason to have the KPIs ins the first place, and there would be no guarantees for KEXT authors, and we'd be back in the same boat we were in before the KPIs, which would not be a Good Thing(tm) for most KEXT developers - or us. However - adding behaviours to an existing API, and then not documenting them except to people who have need of the new behaviours, works around the problem with the least overall impact: the KEXTs still load because they don't have symbol set mismatches that would prevent them from being linked into the kernel, and KEXTs that don't use the new behaviour stay forward-compatible. KEXTs which *do* use the new behaviour can protect themselves, either by checking the error code and using fall-back code to do the same thing, or by insisting that the kernel version be 10.4.2 or later (or whatever version the new behaviour surfaced in). Thinks like sockopt, ioctl, fcntl, etc., especially lend themselves to this type of change because they effectively MUX points that de-MUX based on command value, and can return an error code if the command us unimplemented. - this is not documented in the latest available documentation or headers. If this is not documented, this does not exist. You should generally treat it as if it didn't exist, unless there is *no other way* to solve your problem. If you choose to use the new behaviour because of performance, you should check the error code and provide a fallback path that, even if it's not as performant, will not cause your software to stop working. If you choose to use the new behaviour because there's no other way to solve your problem, then you should ensure that your KEXT insists on a more stringent than normal version number match, and you should ship separate KEXTs for 10.4.2 and pre-10.4.2 (or resign yourself to support calls in which you tell your users to upgrade to 10.4.2 or later). This email sent to site_archiver(a)lists.apple.com

1 0

Re: DHCP
by Justin C. Walker 18 Aug '05

18 Aug '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 18, 2005, at 14:12 , matt jaffa wrote: Hi, I was wondering where in the darwin open source code is the source for the DHCP client. Wanting to know what options the Mac OS X client support. Most of that stuff is in the bootp project. 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.… This email sent to site_archiver(a)lists.apple.com

1 0