November 2004 - Darwin-dev - lists.apple.com

Re: BOM format and Open Source
by David Leimbach 22 Nov '04

22 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=efKd9AtayxbOsHUWgzcRMTUKTyLu7+SSXMVgmDRLMKyG0TIwftKteJfr/t8SCveIbt0Uhgu7UZPL/RuP6vHhYZkVShHTeECT8exoEWYz/F7hbcH0Zoqw8HzPwqoktlNJqUQOrlOpn17a097T8n1IndZ1flyDaX80VGUPelblxNE= > ><http://developer.apple.com/bugreporter/> > > Of course apple is known to be working on XAR, which is a (as I understand it) likely medium term replacement for BOM. They probably aren't going to waste time opensourcing BOM/adding enhancements if they are working on the (probable) replacement. > > DarwinPorts is also hoping (as per the last discussion I remember) to use XAR if/when it matures. > > Michael Hi Michael, I actually work on xar :). Along with Rob Braun and Kevin Van Vechten and others. It's actually a library known to work on BSD, Linux, Mac OS X and a driver program known as "xar" that can archive and unarchive files and preserves things like resource forks and extended attributes [things tar doesn't do currently]. It's actually currently possible to archive up a Carbon application like MS Word and unpack it later and have it look like it did in Finder before you moved it and it will actually function. I don't know how this affects the BOM list format. Our Table of Contents in XAR is an XML document. I have no idea if Apple wants to use this stuff or not... We've not managed to freeze the development for a 1.0 on xar yet either but we've worked out quite a few bugs. It'd be great if people would give it a try anyway :). Dave > -- > Dr Michael A. Maibaum > internet: mike(a)maibaum.org | http://mike.maibaum.org/ > voice: [h] 07958 604025 | [w] (020) 7631 6725 > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/leimy2k%40gmail.com > > This email sent to leimy2k(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: BOM format and Open Source
by Michael Maibaum 22 Nov '04

22 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Mail-followup-to: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.5.1i On Nov 21, 2004, at 1:34 PM, Damien Bobillot wrote: Le 21 nov. 04, ? 22:17, St?phane Sudre a ?crit : Of course apple is known to be working on XAR, which is a (as I understand it) likely medium term replacement for BOM. They probably aren't going to waste time opensourcing BOM/adding enhancements if they are working on the (probable) replacement. DarwinPorts is also hoping (as per the last discussion I remember) to use XAR if/when it matures. On Mon, Nov 22, 2004 at 09:04:51AM -0800, Shawn Erickson wrote: Any sign of progress on the open sourcing of the BOM format since Kevin Van Vechten's request a long time ago? I wonder why Apple don't provide at least a public API for the Bom framework. It may be very useful to develop custom installer makers. Apple's one (and the mkbom command) is hard to use in automatic tasks and not very flexible. File a request with Apple, the more they hear the more likely it will be so. <http://developer.apple.com/bugreporter/> Michael -- Dr Michael A. Maibaum internet: mike(a)maibaum.org | http://mike.maibaum.org/ voice: [h] 07958 604025 | [w] (020) 7631 6725 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: BOM format and Open Source
by Shawn Erickson 22 Nov '04

22 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 21, 2004, at 1:34 PM, Damien Bobillot wrote: Le 21 nov. 04, à 22:17, Stéphane Sudre a écrit : <http://developer.apple.com/bugreporter/> -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Any sign of progress on the open sourcing of the BOM format since Kevin Van Vechten's request a long time ago? I wonder why Apple don't provide at least a public API for the Bom framework. It may be very useful to develop custom installer makers. Apple's one (and the mkbom command) is hard to use in automatic tasks and not very flexible. File a request with Apple, the more they hear the more likely it will be so. This email sent to site_archiver(a)lists.apple.com

1 0

Re: BOM format and Open Source
by Damien Bobillot 21 Nov '04

21 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 21 nov. 04, à 22:17, Stéphane Sudre a écrit : -- Damien alias Schmurtz aim:goim?screenname=schmuuurtz _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Any sign of progress on the open sourcing of the BOM format since Kevin Van Vechten's request a long time ago? I wonder why Apple don't provide at least a public API for the Bom framework. It may be very useful to develop custom installer makers. Apple's one (and the mkbom command) is hard to use in automatic tasks and not very flexible. This email sent to site_archiver(a)lists.apple.com

1 0

BOM format and Open Source
by Stéphane Sudre 21 Nov '04

21 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Any sign of progress on the open sourcing of the BOM format since Kevin Van Vechten's request a long time ago? This email sent to site_archiver(a)lists.apple.com

1 0

Re: simultaneous debuggers?
by Skip Levens 19 Nov '04

19 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com It's possible - http://www.allinea.com/index.php?page=48 (used to be Streamline) UI presentation is QT based - should be on Mac OS X soon... -Skip On Nov 17, 2004, at 4:08 PM, Eric Ocean wrote: Best, Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/slevens%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… essentially takes output from multiple machines' gdb output and collects it into one debugging environment - nice graphical tools too. Etnus Totalview were also telling vistitors at their booth at Supercomputing 2004 that they'd have their parallel debugger on Mac OS X hopefully Q1 2005... Is it possible for multiple debuggers to attach themselves simultaneously to a single, running executable? (I'm not familiar enough with command-line GDB to try this myself.) This email sent to slevens(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re[4]: Intercepting file system calls (read, write, open, close, etc)
by Igor Shmukler 19 Nov '04

19 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Make, I want to point out following: this discussion is simlar to "is it possible to develop a high-performance OS in C++" I do not think it's relevant to darwin-dev any longer. Stacking is a very powerful obstraction. It enables a more flexible construction of a data flow. In some instances this comes in very handy. If a cost can be kept under 1-2% per layer for a random access, it is usually worth it. However to take advantage of a stackable design one has to explicitly exploit its benefits. I have some data to support my opinions. Please contact me directly if you would like to talk about this. Igor. -----Original Message----- From: Mike Smith <msmith(a)freebsd.org> To: Igor Shmukler <shmukler(a)mail.ru> Date: Thu, 18 Nov 2004 21:42:49 -0800 Subject: Re: Re[2]: Intercepting file system calls (read, write, open, close, etc) > > > On Nov 18, 2004, at 6:28 PM, Igor Shmukler wrote: > > >>>> 1. Try VFS Stacking ? Or over-riding V-node ops ? > >>> > >>> Was support for VFS stacking removed? I was warned of such a year or > >>> two ago, and stopped my VFS efforts at that point (also trying to > >>> intercept file system calls). > >> > >> Stacking filesystems in the BSD model doesn't work very well. It gets > >> expensive very quickly, and locking can become a nightmare. It's also > >> often not really what you want; the above is a good example of that. > > > > The above being - ? > > "also trying to intercept file system calls" > > > SunOS is a proof that BSD model and stackable VFS do work well > > together. > > Opinions on that differ to a considerable degree. > > > The reason locking in an operating system such as a BSD would > > problematic is because VFS is very complex. > > It needed flattening back in 1998 right after VM became stable. Now to > > support MP kernel locking is more complex than ever. That does not > > mean that things ought to be this way. Implementing a stackable FS is > > relatively straightforward if you start from the right place - vnode > > interface. If done correctly stackable does not create any problems > > with locking that would not be present in a leaf design. > > These are interesting assertions, but without any real application in > the current > context. I would caution anyone else reading this that your opinions > are certainly > not widely held. > > In particular, fan-in, fan-out and partial unwinds are all necessary > for stacking > filesystems (if you don't want unwinds, you need reservations which are > arguably > worse). Locking these is painful at best, and nesting vnodes is never > not expensive. > > = Mike > > http://Mail.Ru - лучшая почта с неограниченным объемом почтового ящика! _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Re[2]: Intercepting file system calls (read, write, open, close, etc)
by Mike Smith 19 Nov '04

19 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 18, 2004, at 6:28 PM, Igor Shmukler wrote: Was support for VFS stacking removed? I was warned of such a year or two ago, and stopped my VFS efforts at that point (also trying to intercept file system calls). Stacking filesystems in the BSD model doesn't work very well. It gets expensive very quickly, and locking can become a nightmare. It's also often not really what you want; the above is a good example of that. "also trying to intercept file system calls" Opinions on that differ to a considerable degree. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 1. Try VFS Stacking ? Or over-riding V-node ops ? The above being - ? SunOS is a proof that BSD model and stackable VFS do work well together. The reason locking in an operating system such as a BSD would problematic is because VFS is very complex. It needed flattening back in 1998 right after VM became stable. Now to support MP kernel locking is more complex than ever. That does not mean that things ought to be this way. Implementing a stackable FS is relatively straightforward if you start from the right place - vnode interface. If done correctly stackable does not create any problems with locking that would not be present in a leaf design. These are interesting assertions, but without any real application in the current context. I would caution anyone else reading this that your opinions are certainly not widely held. In particular, fan-in, fan-out and partial unwinds are all necessary for stacking filesystems (if you don't want unwinds, you need reservations which are arguably worse). Locking these is painful at best, and nesting vnodes is never not expensive. This email sent to site_archiver(a)lists.apple.com

1 0

Re[2]: Intercepting file system calls (read, write, open, close, etc)
by Igor Shmukler 19 Nov '04

19 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com > >> 1. Try VFS Stacking ? Or over-riding V-node ops ? > > > > Was support for VFS stacking removed? I was warned of such a year or > > two ago, and stopped my VFS efforts at that point (also trying to > > intercept file system calls). > > Stacking filesystems in the BSD model doesn't work very well. It gets > expensive very quickly, and locking can become a nightmare. It's also > often not really what you want; the above is a good example of that. The above being - ? SunOS is a proof that BSD model and stackable VFS do work well together. The reason locking in an operating system such as a BSD would problematic is because VFS is very complex. It needed flattening back in 1998 right after VM became stable. Now to support MP kernel locking is more complex than ever. That does not mean that things ought to be this way. Implementing a stackable FS is relatively straightforward if you start from the right place - vnode interface. If done correctly stackable does not create any problems with locking that would not be present in a leaf design. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: trying to find right list
by Steven J Abner 18 Nov '04

18 Nov '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Thursday, November 18, 2004, at 03:46 PM, Matt Watson wrote: static const char _lowerhexstr[] = "0123456789abcdef0x"; int main(void) { struct timeval mytimeval; char *result; int i; gettimeofday(&mytimeval, NULL); result = ctime((const time_t *)&mytimeval.tv_sec); printf("%s", result); { char buffer[64]; for (i = 0; i < (1<<27); i++) { gettimeofday(&mytimeval, NULL); result = ctime((const time_t *)&mytimeval.tv_sec); printf("%s", result); return 0; } Test 400Mhz G3 vs 400Mhz G4 with GCC 3.3 XCode and indexed run identical but value assign runs slower on G4 than indexing and value assign runs faster on G3 than indexing _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Even better would be a "recipe" to reproduce. Something like: char *strBuf = buffer, *strPtr; unsigned long val_ul; strPtr = &strBuf[64]; val_ul = -999999; // do *--strPtr = _lowerhexstr[(val_ul & 7)]; while ((val_ul >>= 3)); do *--strPtr = ((val_ul & 7) + 48); while ((val_ul >>= 3)); } } This email sent to site_archiver(a)lists.apple.com

1 0