Tail-call reference (was: CPUTYPE warning)
tl == Terry Lambert wrote: tl FWIW: tail-call optimization is when I have a function tl that, as it's last thing (perhaps after reordering by tl the compiler, as well) calls another function, such tl that the return value of the other function is its tl return value. See also: Debunking the ``Expensive Procedure Call'' Myth or, Procedure Call Implementations Considered Harmful or, LAMDBA: The Ultimate GOTO By Guy Lewis Steele, Jr. AI memo 443, October 1977, 23 pages ftp://publications.ai.mit.edu/ai-publications/0-499/AIM-443.ps Regards, Koshy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linux ls fails on DEVFS /dev
Michael Reifenberger wrote: linux ls fails on DEVFS /dev because linux_getdents fails because linux_getdents uses VOP_READDIR( ..., ncookies, cookies ) instead of VOP_READDIR( ..., NULL, NULL ) because it seems to need the offsets for linux_dirent and sizeof(dirent) != sizeof(linux_dirent)... If I eliminate the usage of cookies, then a ls on at least a cd9660 mounted dir fails with not finding all direntries. So the question is if all filesystems are expected to implement the cookies != NULL case? The problem is that the interface is broken by design; for it to be correct, it actually needs to be split into two pieces: one to snapshot the directory entry block, and a second one to do the copy out from the on disk format to the wire format, which is the NFS externalized version of the structure (cookies came in when the on disk directory entry structure changed from the representation that was historically used for NFS, to its current form; they basically exist to provide glue between internal and external representation). Basically, cookies assume that the client of their services will be the NFS server. They are actually a kludge, and there is a better way to do the same thing, which avoids the problem, at least as much as it is possible to avoid the problem, if the directory is changing out from under your server (or in this case, the Linux consumer). BTW: Wy doesn't a call to fstat on a directory set a st_blksize != 0? Do directories have no preferred blocksize? Directories aren't files, per se. Directory entries are stored in physical disk blocks, to ensure atomicity of the directory operations. That said, this does seem to be a compatability issue with the Linux ABI (see below) that should be addressed in the Linux ABI implementation, and not the FreeBSD generic stat implementation. I ask because getdents(2) explicitly states one should use stat(2) to get the minimum buffersize... By getdents(2), I assume that you are talking about the Linux system call man page, not the FreeBSD one. The correct thing to do is to use opendir/readdir/closedir, and not call getdents(2) directly yourself. In general, as a compatability hedge, I suppose we could make the stat call behave for directories as it does on Linux. In reality, the buffer size should be large, since the standard directory reading code caches a snapshot of the directory blocks, externalized into the neutral format. For NFS clients of VFS', and for the Linux system call code, which is also a VFS client, the correct thing to do is probably to return a large number, and then short change the result by backing off on the copy out, if it can't be done on a full directory entry block boundary internal to the FS. This is true because the cookies are really there to permit an arbitrary restart on a non-directory block boundary; you could achieve the same thing for NFS by traversing the block entries to the entry following the offset; if it was not on an offset boundary, then you back up one entry (i.e. you are trying to restart based on a snapshot that has changed out from under you). It's up to the client to perform duplicate suppression. If you did the short change trick, then you would always be guaranteed that you could copy out one or more full directory entry blocks, and stop on an alignment boundary, which would eliminate the need to restart in the middle of a block, which would mean that NULL, NULL would be the correct thing to pass. The only place this would fail unexpectedly is when the buffer passed in to the linux_getdents(2) call was too small to hold all the entries that could occur in a single FreeBSD directory block. You code would have to be very badly behaved (intentionally so) to do that. Still, you can fake up the restart by copying out a FreeBSD-normal block into a transition buffer, and then traversing from there to do the restart (the other trick mentioned above). This would probably be best, since it would avoid the problem recurring with any future FS's. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Er. Interesting. Doing some reading up on the M1533, I notice that the power management component isn't actually listed here: ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA atapci0@pci0:15:0:class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA There should be a device at pci0:3:0, something like: none0@pci0:3:0: class=0x?? card=0x chip=0x710110b9 rev=0x?? hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M7101 PCI PMU Power Management Controller' ... Check that you have ACPI/power management turned on in your BIOS setup; that's typically responsible for enabling/disabling this device... Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
msdosfs borked ?
Hi. Just upgraded my system today to the latest -current, after my last venture into -current in May. Has MS-Dos filesystem support been broken ? I can't see any commits or notes in UPDATING, and hadn't read anything in -current about it. I am running devfs. Debugging output below : FreeBSD bofh.fw.uunet.co.za 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Aug 7 12:21:52 SAST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BOFH4 i386 ad0: 4126MB ST34311A [8944/15/63] at ata0-master UDMA33 ad1: DMA limited to UDMA33, non-ATA66 compliant cable ad1: 19574MB IBM-DPTA-372050 [39770/16/63] at ata1-master UDMA33 The disk I'm interesting in mounting is ad1. 2=[root@bofh] ~# ls -al /dev/ad* crw-r- 1 root operator 116, 0x00010002 Aug 7 13:00 /dev/ad0 crw-r- 1 root operator 116, 0x0002 Aug 7 15:00 /dev/ad0s1a crw-r- 1 root operator 116, 0x00020001 Aug 7 13:00 /dev/ad0s1b crw-r- 1 root operator 116, 0x00020004 Aug 7 15:00 /dev/ad0s1e crw-r- 1 root operator 116, 0x00020005 Aug 7 15:00 /dev/ad0s1f crw-r- 1 root operator 116, 0x00020006 Aug 7 15:00 /dev/ad0s1g crw-r- 1 root operator 116, 0x0001000a Aug 7 13:00 /dev/ad1 crw-r- 1 root operator 116, 10 Aug 7 13:00 /dev/ad1c Fdisk reports : 3=[root@bofh] ~# fdisk ad1 *** Working on device /dev/ad1 *** parameters extracted from in-core disklabel are: cylinders=2495 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=2495 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 12,(DOS or Windows 95 with 32 bit FAT, LBA) start 63, size 40082112 (19571 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED 5=[root@bofh] ~# mount_msdosfs /dev/ad1 /mnt/mnt mount_msdosfs: /dev/ad1: Invalid argument 6=[root@bofh] ~# kldstat Id Refs AddressSize Name 1 10 0xc010 262588 kernel 21 0xc1571000 7000 if_fxp.ko 31 0xc1579000 14000miibus.ko 41 0xc15c1000 4nfs.ko 51 0xc1625000 1a000usb.ko 61 0xc1657000 4000 logo_saver.ko 71 0xc1663000 4000 md.ko 81 0xc166d000 8000 cd9660.ko 111 0xc17db000 d000 msdosfs.ko Khetan Gajjar. --- [EMAIL PROTECTED]* Direct - +27 21 658 8723 UUNET South Africa * Mobile - +27 82 416 0105 http://www.za.uu.net* CSC- 08600 UUNET (88638) Systems Team* PGP Key- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Missing '()' in aac.c
Hello, () are missing around the KASSERT format string in aac.c and compilation fails (if KASSERTS are enabled). The following patch fixes the problem. Regards, harti Index: aac.c === RCS file: /usr/ncvs/src/sys/dev/aac/aac.c,v retrieving revision 1.20 diff -r1.20 aac.c 1302c1302 aac_sync_fib: datasize to large); --- (aac_sync_fib: datasize to large)); -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Welcome to the freebsd-lists-for-dayan-only group
Hello, I've added you to my freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. As a member of this group, you may send messages to the entire group using just one email address: [EMAIL PROTECTED] eGroups also makes it easy to store photos and files, coordinate events, and more. Here's a description of the group: This list is subscribed to various FreeBSD lists only for Dayan. Here's my introductory message for you: Hello, Welcome to the freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. Please take a moment to review this message. To start sending messages to members of this group, simply send email to [EMAIL PROTECTED] If you do not wish to belong to freebsd-lists-for-dayan-only, you may unsubscribe by sending an email to [EMAIL PROTECTED] You may also visit the eGroups web site to modify your subscriptions: http://www.egroups.co.uk/mygroups Regards, Moderator, freebsd-lists-for-dayan-only TO START SENDING messages to members of this group, simply send email to [EMAIL PROTECTED] If you do not wish to belong to the freebsd-lists-for-dayan-only group, you can unsubscribe by replying to this message, or by sending an email to [EMAIL PROTECTED] Regards, Moderator, freebsd-lists-for-dayan-only SPECIAL NOTE FROM eGroups: Because eGroups values your privacy, it is a violation of our service rules for moderators to add subscribers to a group against their wishes. If you feel this has happened, please notify us at [EMAIL PROTECTED] P.S. If you would like to learn more about the freebsd-lists-for-dayan-only group, please visit http://www.egroups.co.uk/group/freebsd-lists-for-dayan-only and enter the following sign-in information: Email address: [EMAIL PROTECTED] Password: onaqljinwaatmqs This password has been randomly generated for you. Once you have signed in, you should change your password by visiting http://www.egroups.co.uk/myprofile To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lost password
Hello, Thanks for using eGroups, home to free, easy, email groups. We have received your request for information about a forgotten password. * If you requested this notice and still don't remember your password, please follow these steps to create a new password: 1. In your web browser, go to: http://www.egroups.co.uk/lostpassword?[EMAIL PROTECTED] 2. Enter this reauthorisation number: 14409 3. You will be asked to create a new permanent password. Your new password cannot be the reauthorisation number. * If you did not request this notice, please ignore this message. Your eGroups account and current password have not been affected and you can continue using our free service as usual. If you believe someone is attempting to misuse your email account, please forward this message to [EMAIL PROTECTED] Regards, eGroups Customer Support To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kill -s does not work.
While reading the exports(5) manpage, near the bottom is an example kill -s HUP `cat /var/run/mountd.pid` does kill -s causes this error: # kill -s HUP s: Unknown signal; kill -l lists signals. However, reading the kill(1) manpage, -s is documented. So, I am thinking this is a bug in kill(1). Does anyone have any comments? - David Hill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kill -s does not work.
On Tue, Aug 07, 2001 at 03:12:08PM -0400, David Hill wrote: # kill -s HUP s: Unknown signal; kill -l lists signals. However, reading the kill(1) manpage, -s is documented. So, I am thinking this is a bug in kill(1). I bet you are using csh, and running the kill builtin instead of kill(1). -- Matthew Hunt [EMAIL PROTECTED] * Clearly there are more things in the http://www.pobox.com/~mph/ * heavens than anyone anticipated. -enp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kill -s does not work.
On Tue, 07 Aug 2001 15:12:08 -0400, David Hill wrote: However, reading the kill(1) manpage, -s is documented. So, I am thinking this is a bug in kill(1). Does anyone have any comments? Read the kill(1) manual page: Some shells may provide a builtin kill command which is similar or iden tical to this utility. Consult the builtin(1) manual page. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kill -s does not work.
At 3:12 PM -0400 8/7/01, David Hill wrote: While reading the exports(5) manpage, near the bottom is an example kill -s HUP `cat /var/run/mountd.pid` does kill -s causes this error: # kill -s HUP s: Unknown signal; kill -l lists signals. However, reading the kill(1) manpage, -s is documented. So, I am thinking this is a bug in kill(1). Does anyone have any comments? The short answer is, use /bin/kill -s HUP `cat /var/run/mountd.pid` for now. Here's the bug report and patch I submitted on this issue in June: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28109 It'll be fixed in the next release of tcsh. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB Microtech CameraMate CF/CF+/CF+II/Microdrive/SmartMedia reader
I did an archive search of this list, and found a post from April from a guy who had some diffs to scsi_da.c and the umass driver to get this thing working. I sent him an email a couple of weeks ago, but haven't heard back yet. He said he had it working under -current. Does anyone have a copy of these diffs? There was at least one other subscriber to -current that asked him for these diffs... Also, I may be a little behind the times, as this is my first USB device to play with, so some tips on how to get it working with the drivers once patched would help too... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: Er. Interesting. Doing some reading up on the M1533, I notice that the power management component isn't actually listed here: ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA atapci0@pci0:15:0:class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA There should be a device at pci0:3:0, something like: none0@pci0:3:0: class=0x?? card=0x chip=0x710110b9 rev=0x?? hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M7101 PCI PMU Power Management Controller' ... Check that you have ACPI/power management turned on in your BIOS setup; that's typically responsible for enabling/disabling this device... One page in the BIOS setup is dedicated for Power Management (standard AWARD BIOS 4.51). Power Management is set to Enable Second option is PM control by APM I tried both option (Yes/No), but no difference. Most other options are set to Disable (HDD power down, Wake Up events, etc.) Maybe this is an early revision of the chipset. The board is from mid 1998. I try to find an unused disk drive and install Windows on it to run the ACPI validation test suite. But this will take some time - you may expect results at the end of this week. The installed BIOS version was specificially released to allow a Windows 2000 ACPI mode installation. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 and USB devices
Now, this _used_ to work -- some time back in February or even in spring. But not anymore... usbd is running, the usb device, with the uhci are compiled into the kernel, and the controller is reported on boot: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1c00-0x1c1f irq 5 at device 18.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 But nothing happens when I connect USB devices, like Palm's craddle or a digital camera... No new /dev/ugen* created, no messages logged by usbd, nothing... The OS is FreeBSD 5.0-CURRENT #0: Sun Jul 15 12:50:23 EDT 2001 ... i386 Any clues? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Missing '()' in aac.c
In article [EMAIL PROTECTED], Harti Brandt [EMAIL PROTECTED] wrote: () are missing around the KASSERT format string in aac.c and compilation fails (if KASSERTS are enabled). The following patch fixes the problem. Index: aac.c === RCS file: /usr/ncvs/src/sys/dev/aac/aac.c,v retrieving revision 1.20 diff -r1.20 aac.c 1302c1302 aac_sync_fib: datasize to large); --- (aac_sync_fib: datasize to large)); And too is misspelled. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Random Lockups
I'm surry I don't have much data to provide, but... I've been experiencing random lockups on a -CURRENT kernel from the August 5th source. I've gotten it a lot when running screen and ssh on two different terminals at the same time, but that is not the only time it happens. Hardware is a 1.2ghz Thunderbird on an ABIT KT7-RAID I'd attach dmesg output or tracebacks, but there are none. It's just a solid lockup. I'm getting no lockups with a kernel built on July 16th... Anybody else seeing this or have ideas how I can debug it further? I'm not sure how to debug a full lockup. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject send pgp key PGP signature
Deadline for .biz .info approaches!!
Dear Registrant, The most anticipated event since the first release of the dotcoms is here! If you haven't already done so it's time to pre-register your .biz and .info 'Top Level Domain Names' and stake your claim in what is fast becoming a LAND RUSH, larger than the .com phenomena. With the deadline to pre-register your .biz Sept 17, 2001 and Sept 12, 2001 for .info domains approaching (your only real opportunity to secure a great .biz and/or .info) you must act now secure your trading or generic name(s). At the close of these periods all pre-registrations will be processed first. Up for grabs are names like; news.biz, show.biz and adult.info because of the 'Round Robin' [Not First Come First Serve] selection method adopted by ICANN, the release has effectively become The Worlds Largest Lottery. We offer you [but only until September 18th 2001] to pre-register your selection of great names with three of the largest biz .info registrars [Our Channel Partners] in a 3-5 minute process for one low price [as low as US$3.50 per name] this is the lowest price available anywhere including The Registrars Themselves. Heres how it works! Pre-register with one, two or all three of our channel partners at the same time and increase your chances of securing names like 'show.biz or easy.info' up to 300%. Pre-register as many names as you like and save up to 50% with volume discounts. Free.biz! Want to pre-register names like adult.biz for FREE. Easy.biz, simply go to www.drawcard.com enter in your email address at our affiliate page and I will send you an email, with your unique ID that can be forward to all in your address book then all who enter the site by way of that link will earn you US$1.00 per pre-registration. We have people registering 100+ names at a time. Now that's a good.biz! Any and all names you decide to register can come directly off your earnings or if you prefer I will send you a cheque! More_Free.info · For every 20 names or more you pre-register we will give you free for one year a sub-domain name from the very best of our 'channels partners' like '[EMAIL PROTECTED]', '[EMAIL PROTECTED]'. · Free home page with every account. · Free email with every account. This is your very best opportunity to secure 'yourfuture.biz'. But you must Pre-Register and you must do it NOW. Want to see more: http://www.drawcard.com (If this link is not working please cut and paste the link into your browser) If you have received this mailing in error, or do not wish to receive any further mailings from us, simply click here put in your email address and add Remove to the subject line: http://www.drawcard.com/index.cfm?fuseaction=CompanyInfo Damian Andrews MD Drawcard.com
Re: KSE/threads progress report
On 07-Aug-01 Paul Saab wrote: Kenneth D. Merry ([EMAIL PROTECTED]) wrote: diff2 output, on the other hand, won't run through patch properly. You have to run it through a fixup script to get it right. p4 diff -u -b branch p4 diff2 -u -b branch ^ -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
p4 diff notes..
On 07-Aug-01 Julian Elischer wrote: I have pushed the thread pointers down through most of the code though there are still many many places that assume that there is only one thread per process. (no multithreading yet, but getting closer..) At this stage diffs must be pushing close to 1MB (maybe more) (I don't know as I don't know yet how to get p4 to generate diffs :-) It's not too hard. I have the smpng and jhb_preemption batches updating diff's on freefall via cron. :) To do a diff of files against files you have checked out, you use 'p4 diff' such as 'p4 diff -du ...' to get a unified diff. Unfortunately, p4's diff format isn't too patch friendly. There is also a 'p4 diff2' which does a diff of files in the depot. p4 diff2 has an undocumented (well, it's documented in 'p4 help undoc') option -u that will produce a unified diff that patch can grok (albeit, it has the full depot path, so you'll have to use -p6 or some such to apply it). If you had a julian_kse branch off of the kse branch you would use 'p4 diff2 -u -b julian_kse' to get a diff of the entire branch. You can use 'p4 diff2 -u -b kse' to get a diff of the kse branch against the head, but unfortunately it does a diff against the head of the -current vendor import rather than against the latest files you last integrated from. To make the diff relative to when you last branched, you can use a revision specification to refer to the state of the -current tree when you last did your integrate. To do this, look up the change number of your last integrate from -current, (right now 448 was your last MFC for example). You then generate a diff between -current as of that change number and the head revision of your branch (see 'p4 help revisions' or the revisions section of the quickstart guide) like so: p4 diff2 -u -b kse @448 #head However, having to look up the change number for diff's is a minor pain, and makes it harder to automate things (like generating diff's in crontabs). What you can do is create a label that tracks -current and is the last branch point. First, you want to create a label whose View is the same as the files your branch branches from. For example: p4 branch -o smpng ... Branch: smpng ... View: //depot/vendor/freebsd/sys/... //depot/projects/smpng/sys/... p4 label -o smpng_base Label: smpng_base ... Description: Label that tracks the smpng branch's 'base', i.e. the last change imported from the FreeBSD current branch. ... View: //depot/vendor/freebsd/sys/... You use 'p4 label' to create a label (set its View, description, etc.) You use 'p4 labelsync' to actually determine what revisions of what files the label applies to. If you created a kse_base label, then you would start off by specifying it as the last change you integrated from (448) like so: p4 labelsync -l kse_base @448 You can then do diff's like so: p4 diff2 -u -b kse @kse_base #head Keeping the label up to date is fairly easy. When you want to do an integrate, simply follow these steps: p4 labelsync -l kse_base #head p4 integrate -b kse @kse_base p4 resolve -a p4 resolve p4 submit Note that you can update the label of individual files as well if you wish. For example, my last integrate into smpng just brought across a commit to sys/i386/isa/ipl.s rather than updating the entire tree: p4 integrate -b smpng sys/i386/isa/ipl.s p4 resolve -a p4 submit I then updated the label on just that file like so: p4 labelsync -l smpng_base //depot/vendor/freebsd/sys/i386/isa/ipl.s#head I usually keep my work trees off of the smpng branch up to date with the smpng branch, so I don't have to bother with label's on those. This allows you to get things working on a stable snapshot of current, and later do an integrate to catch up. Note that you could of done the MFC of one file as so: p4 labelsync -l smpng_base //depot/vendor/freebsd/sys/i386/isa/ipl.s#head p4 integrate -b smpng @smpng_base p4 resolve -a p4 submit HTH. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: p4 diff notes..
On Tue, Aug 07, 2001 at 09:36:01 -0700, John Baldwin wrote:
On 07-Aug-01 Julian Elischer wrote:
I have pushed the thread pointers down through most of the code
though there are still many many places that assume that there is only one
thread per process. (no multithreading yet, but getting closer..)
At this stage diffs must be pushing close to 1MB (maybe more)
(I don't know as I don't know yet how to get p4 to generate diffs :-)
It's not too hard. I have the smpng and jhb_preemption batches updating
diff's on freefall via cron. :)
To do a diff of files against files you have checked out, you use 'p4 diff'
such as 'p4 diff -du ...' to get a unified diff. Unfortunately, p4's diff
format isn't too patch friendly. There is also a 'p4 diff2' which does a
diff of files in the depot. p4 diff2 has an undocumented (well, it's
documented in 'p4 help undoc') option -u that will produce a unified diff that
patch can grok (albeit, it has the full depot path, so you'll have to use -p6
or some such to apply it). If you had a julian_kse branch off of the kse
branch you would use 'p4 diff2 -u -b julian_kse' to get a diff of the entire
branch. You can use 'p4 diff2 -u -b kse' to get a diff of the kse branch
against the head, but unfortunately it does a diff against the head of the
-current vendor import rather than against the latest files you last integrated
from.
According to the docs, p4 diff2 -u only produces diffs on files that are in
both paths and differ. So files that are added in one branch won't be
shown.
Attached is an awk script that was originally written by Justin (hacked up
by me somewhat) that I use on my zero copy branch to fix up the perforce
diff output. It will produce diffs for files that are only in one branch.
So basically I use it like this:
p4 diff2 -dc //depot/FreeBSD-current/src/... //depot/FreeBSD-zero/src/... foo
cat foo | awk -f awkdiff.zero diffs.fixed
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
$1 == {
last_line = $0
last_filename = $2
gsub(/\/\/depot\/FreeBSD-zero\/src/, src, last_filename)
gsub(/\/\/depot\/FreeBSD-current\/src/, src, last_filename)
gsub(/#[0-9]*$/, , last_filename)
did_sub = 0
}
$1 == $2 == $3 == none $4 == {
new_file = $6
gsub(/\/\/depot\/FreeBSD-zero\/src/, src, new_file)
gsub(/\/\/depot\/FreeBSD-current\/src/, src, new_file)
# gsub(/\/usr\/home\/ken\/perforce\/cam/, src, new_file)
gsub(/#[0-9]*$/, , new_file)
old_sep=OFS
OFS=
print #!/bin/sh /tmp/make_diff
print p4 print , $6, | sed '/^\\/\\/depot/d' /tmp/foo
/tmp/make_diff
print diff -c /dev/null /tmp/foo | sed s@/tmp/foo@, new_file, @
/tmp/make_diff
close(/tmp/make_diff)
OFS=old_sep
system(sh /tmp/make_diff)
# print $0
}
$1 != {
if (!did_sub $1 == ***) {
print ***, last_filename .orig
print ---, last_filename
print $1
did_sub = 1
} else {
print $0
}
}
