From owner-freebsd-arch Sun Mar 10 0:17:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id DD96E37B400 for ; Sun, 10 Mar 2002 00:17:23 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2A8GwBo035228; Sun, 10 Mar 2002 09:16:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sat, 09 Mar 2002 14:42:54 PST." Date: Sun, 10 Mar 2002 09:16:58 +0100 Message-ID: <35227.1015748218@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >dev_t will not exist in 6.0 It's standards mandated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 0:18: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A102137B400 for ; Sun, 10 Mar 2002 00:18:05 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2A8HkBo035385; Sun, 10 Mar 2002 09:17:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sat, 09 Mar 2002 19:03:08 EST." Date: Sun, 10 Mar 2002 09:17:46 +0100 Message-ID: <35384.1015748266@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >>With DEVFS and properly written drivers, this field can be >>randomly assigned and will have no practical importance to the >>kernel. This is the direction we should move. >> >>The only argument I know for expanding it would be to make the >>slight hack used to hide the dictomy between the dev_t (a pointer) >>and the userland (u)dev_t (an integer) simpler on 64bit archs. > >I don't see how this would work for OpenAFS. By that I mean that >I do not know how the dev_t-pointer that you're talking about is >used when implementing something like OpenAFS or ARLA support. I have no idea what the problem would be, so you will have to tell me before I can answer you... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 1:10:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 01B1037B417; Sun, 10 Mar 2002 01:10:23 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2A99lj02920; Sun, 10 Mar 2002 01:09:47 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203100909.g2A99lj02920@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: Michael Smith , arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) In-reply-to: Your message of "Sat, 09 Mar 2002 22:43:10 PST." <20020309224310.A28779@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Mar 2002 01:09:47 -0800 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I am not claiming that bootdev gives the correct answer in 100% of > the cases. As you correctly notice, there is probably not a "perfect" > solution. This isn't really the issue. The issue is that one cannot tell whether it's giving you an accurate answer unless you already know what the answer is, in which case it's useless anyway. > However, _having tried_ to use it (with the sysctl patch that I > posted as a followup, which does essentially the same mapping that > is in boot/i386/boot2/boot2.c and presumably was in the ancient > i386/i386/autoconf.c), I have to disagree with you on the usefulness > of this number. It gives some reasonable information in some common > cases, e.g. when you boot off a floppy or a hard disk/CompactFlash > slice, and i think it is a big improvement over the current situation > where we can only do a blind guess having no information at all. Again, in these cases you already know what the boot device was, or you are otherwise in control of the process and don't need to be told. > I am not suggesting to use this method as a standard piece of /etc/rc, > just make this info available for those users who might have a need > for it (and know of its limitations). > As I said, if anyone has a better way to do this I'll be glad to > hear that. Since you already know the configuration, simply embed the requisite information in your configuration. > As for the cases I care about (booting PicoBSD, but that would also > apply to install disks to make another example), the root device > comes from MFS and it is obviously not the root device. ... ergo you don't need something that won't tell you what you really booted from anyway. > So, to summarise: comments received, thanks, we agree on some things, > disagree on some others (and I have shown you examples why), and > since the gist of my proposal was to export a single kernel variable > through sysctl which does not expose any security risk, I do not > believe that people should be too upset by this change. I'm extremely upset by this proposed change. It exports a bogus and unuseful datum which cannot be decoded in a meaningful fashion in anything other than a contrived situation where it is not necessary at all. The bootdev parameter is obsolete and ideally I should have diked it out several years ago. It was left there as a sop to people with old bootstraps or broken configurations. Your examples don't actually demonstrate how you plan to decode bootdev into anything meaningful in the BSD space; without this, your entire exercise is a waste of time, since you can't *do* anything with the value otherwise. > For what matters, we already export lots of stuff (such as > machdep.bootinfo, debug.boothowto, debug.sizeof.*). of questionable > usefulness (to me, but then others might have some use for this > information). The key difference here is that these and many other data are accurate and can be meaningfully decoded. The bootdev parameter is not, and cannot be, and exporting it in the general case is simply a Really Bad Idea. You're trying to hit something that isn't a nail with the sort of hammer best left to a toddler chasing the family cat. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 2: 0:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 41FCB37B416 for ; Sun, 10 Mar 2002 02:00:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020310100012.QFTN2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Sun, 10 Mar 2002 10:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA57482; Sun, 10 Mar 2002 01:55:19 -0800 (PST) Date: Sun, 10 Mar 2002 01:55:17 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <35227.1015748218@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I mean, not as a static permanent thing as it is now teh new dev_t will be meaningful only in the short term and need not be expanded. On Sun, 10 Mar 2002, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > >dev_t will not exist in 6.0 > > It's standards mandated. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 2: 3:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id F398C37B405; Sun, 10 Mar 2002 02:03:43 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2AA3hB30509; Sun, 10 Mar 2002 02:03:43 -0800 (PST) (envelope-from rizzo) Date: Sun, 10 Mar 2002 02:03:43 -0800 From: Luigi Rizzo To: Michael Smith Cc: arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020310020343.J28779@iguana.icir.org> References: <20020309224310.A28779@iguana.icir.org> <200203100909.g2A99lj02920@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203100909.g2A99lj02920@mass.dis.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 10, 2002 at 01:09:47AM -0800, Michael Smith wrote: > > I am not claiming that bootdev gives the correct answer in 100% of > > the cases. As you correctly notice, there is probably not a "perfect" > > solution. > > This isn't really the issue. The issue is that one cannot tell whether > it's giving you an accurate answer unless you already know what the > answer is, in which case it's useless anyway. "you" as a human being know the answer when you have the box in front of you and know where you have installed your code. But the system (which is booting the exact same image from either a floppy or a CF or from the net) does not. _This_ is the issue. Sure, you can embed the info in the configuration -- so i need to build one image for a floppy, four for IDE disks (slice 1, 2, 3, 4), another set of four for the SCSI disks... I'd rather keep the number of variants down, thank you. Basically, having bootdev (or equivalent) lets me say: Use this image for fd, ad*, da* when booted from BIOS. Do not use it in other cases. whereas now I have to say Use this image for fd only. when booted from BIOS. Do not use it in other cases. Sure there is room for mistakes, they occur if you run some code on a system where it is not meant to work. So what ? That is what instructions are for (and yes, engineers never read instructions, but then the failure modes of determining a device from bootdev or randomly guessing that it has to be /dev/fd0 look the same to me...) > Your examples don't actually demonstrate how you plan to decode bootdev > into anything meaningful in the BSD space; without this, your entire > exercise is a waste of time, since you can't *do* anything with the value > otherwise. It was in the followup message that I mentioned. I am attaching it at the end. The userland command (sysctl in this case, but it can be some other binary) produces a string that a script can parse. Something like this: dev=`sysctl machdep.bootdev` if [ -c $dev ] ; then # exists and is a char.special file, do something with it else echo "sorry, could not map bootdev to something sensible" fi > You're trying to hit something that isn't a nail with the sort of hammer > best left to a toddler chasing the family cat. oh yeah, i was worried that we were going to keep the discussion on purely technical terms :) Mom, I want my teddy bear, Mike says I am wrong!!! cheers luigi Date: Sat, 9 Mar 2002 08:26:08 -0800 From: Luigi Rizzo To: arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020309082607.I21016@iguana.icir.org> References: <20020309042728.A21016@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020309042728.A21016@iguana.icir.org> User-Agent: Mutt/1.3.23i Status: RO Content-Length: 2506 Lines: 91 And as a followup, attached is a patch for sysctl(8) to parse the information. Again it can be cleaned up a little bit by making machdep.bootdev opaque, but that is purely a stylistic issue -- in the end, finding the proper parsing routine always involves a string comparison. Note that this is only valid for the i386 so I will make this code conditionally compiled if it ever gets committed. cheers luigi On Sat, Mar 09, 2002 at 04:27:28AM -0800, Luigi Rizzo wrote: > Looking at a way to determine the boot device from userland, > I have come to the conclusion that the most reasonable way is to > export to userland whatever information the kernel has (and this > is machine dependent, sorry!), and let some userland program ... Index: sysctl.c =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.41 diff -u -r1.41 sysctl.c --- sysctl.c 25 Feb 2002 03:36:06 -0000 1.41 +++ sysctl.c 9 Mar 2002 15:20:52 -0000 @@ -404,6 +404,55 @@ } /* + * code to map a bootdev into a suitable string. + * Major numbers are mapped into names as in boot2.c + */ +struct _foo { + int majdev; + char *name; +} maj2name[] = { + 30, "ad", + 0, "wd", + 1, "wfd", + 2, "fd", + 4, "da", + -1, NULL /* terminator */ +}; + +#include +#include +static int +machdep_bootdev(u_long value) +{ + int majdev, unit, slice, part; + struct _foo *p; + + if (value & B_MAGICMASK != B_DEVMAGIC) { + printf("invalid (0x%08x)", value); + return 0; + } + majdev = B_TYPE(value); + unit = B_UNIT(value); + slice = B_SLICE(value); + part = B_PARTITION(value); + if (majdev == 2) { /* floppy, as known to the boot block... */ + printf("/dev/fd%d", unit); + return 0; + } + for (p = maj2name; p->name != NULL && p->majdev != majdev ; p++) ; + if (p->name != NULL) { /* found */ + if (slice == WHOLE_DISK_SLICE) + printf("/dev/%s%d%c", p->name, unit, part); + else + printf("/dev/%s%ds%d%c", + p->name, unit, slice - BASE_SLICE + 1, part + 'a'); + } else + printf("unknown (major %d unit %d slice %d part %d)", + majdev, unit, slice, part); + return 0; +} + +/* * This formats and outputs the value of one variable * * Returns zero if anything was actually output. @@ -496,6 +545,8 @@ if (!nflag) printf("%s%s", name, sep); fmt++; + if (!strcmp(name, "machdep.bootdev")) + return machdep_bootdev(*(unsigned long *)p); val = ""; while (len >= sizeof(long)) { if(*fmt == 'U') To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 2:42:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F61237B400; Sun, 10 Mar 2002 02:42:48 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2AAgCj03522; Sun, 10 Mar 2002 02:42:12 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203101042.g2AAgCj03522@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: Michael Smith , arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) In-reply-to: Your message of "Sun, 10 Mar 2002 02:03:43 PST." <20020310020343.J28779@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Mar 2002 02:42:12 -0800 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Sun, Mar 10, 2002 at 01:09:47AM -0800, Michael Smith wrote: > > > I am not claiming that bootdev gives the correct answer in 100% of > > > the cases. As you correctly notice, there is probably not a "perfect" > > > solution. > > > > This isn't really the issue. The issue is that one cannot tell whether > > it's giving you an accurate answer unless you already know what the > > answer is, in which case it's useless anyway. > > "you" as a human being know the answer when you have the box in > front of you and know where you have installed your code. > But the system (which is booting the exact same image > from either a floppy or a CF or from the net) does not. > > _This_ is the issue. No, it is not. The issue is that even *with* your hack, the system cannot tell from whence it booted without knowing more about the system's configuration. The loader guesses better than boot2, but you still can't trust the value. I was going to rant at greater length about this whole topic, but frankly it's rather pointless. What you're asking for is a nasty hack that's useless in most configurations, but I can see why in your special case you want it. If it's added as something like machdep.guessed_bootdev, then I'll probably just barf into a bag and forget about it. I can't promise that the code won't get cleaned out at some point, but it's been quietly rotting for a few years now, so I wouldn't consider it too much of a risk. Though frankly, if you want to find out where you booted from - just go look. You're unlikely to find your boot config on more than one of your potential booted-from vectors. And unlike trusting bootdev, if you search for it, you'll find it. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 9:56:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 2142A37B480 for ; Sun, 10 Mar 2002 09:56:51 -0800 (PST) Received: from pool0441.cvx21-bradley.dialup.earthlink.net ([209.179.193.186] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16k7Yt-00018D-00; Sun, 10 Mar 2002 09:56:47 -0800 Message-ID: <3C8B9E4F.BE3E3B3E@mindspring.com> Date: Sun, 10 Mar 2002 09:56:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > it will be a random unique number > that will be valid for that boot but may be completely different after the > next boot. Heh. Solaris does this. THe "random" value can be dereferenced out of /dev/kmem to read the device structure (it's the pointer to the device structure in the KVA). 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 10:24:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 92C4737B419; Sun, 10 Mar 2002 10:24:20 -0800 (PST) Received: from pool0441.cvx21-bradley.dialup.earthlink.net ([209.179.193.186] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16k7zX-0002iu-00; Sun, 10 Mar 2002 10:24:20 -0800 Message-ID: <3C8BA4C3.64993899@mindspring.com> Date: Sun, 10 Mar 2002 10:24:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) References: <200203101042.g2AAgCj03522@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > "you" as a human being know the answer when you have the box in > > front of you and know where you have installed your code. > > But the system (which is booting the exact same image > > from either a floppy or a CF or from the net) does not. > > > > _This_ is the issue. > > No, it is not. > > The issue is that even *with* your hack, the system cannot tell from > whence it booted without knowing more about the system's configuration. > > The loader guesses better than boot2, but you still can't trust the > value. An incredibly gross hack, which is similar to that used by Windows 95 to convert file handles from BIOS to protected mode values, is to read from the devices from both interfaces, and checksum them to the point where they can be uniquely identified as equal to each other and no other devices, after taking into account hints, so that image copied disks can (mostly) be identified as unique. In the worst case, a write to a known "scratch area" is used, and it looks for the result of the write. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 10:35:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9D27E37B433; Sun, 10 Mar 2002 10:35:14 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2AIYsnp047755; Sun, 10 Mar 2002 19:34:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, current@freebsd.org Subject: GEOM code ready for testing From: Poul-Henning Kamp Date: Sun, 10 Mar 2002 19:34:54 +0100 Message-ID: <47754.1015785294@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The GEOM code is now ready for early testing: http://phk.freebsd.dk/geom There is a known timing issue with ATA controllers with both a master and a slave disk, sos@ and I are looking into it. Apart from that it "should just work". Email all reports to me and don't annoy the lists yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 12:15:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 0EDA537B400 for ; Sun, 10 Mar 2002 12:15:36 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2AKFToX117568; Sun, 10 Mar 2002 15:15:29 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C8B002B.D42A8572@mindspring.com> References: <27966.1015713342@critter.freebsd.dk> <3C8B002B.D42A8572@mindspring.com> Date: Sun, 10 Mar 2002 15:15:27 -0500 To: Terry Lambert From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:41 PM -0800 3/9/02, Terry Lambert wrote: >Garance A Drosihn wrote: >> >By dev_t I guess you mean the userland version of it (udev_t): the >> >combined major and minor number. >> >> Yes. The field in the 'struct stat' returned from stat(). Userland, >> posix, etc. The struct is supposed to include fields named st_dev >> and st_ino, of type dev_t and ino_t. > >Note also that POSIX requires them to be atomic types. So >"long long" need not apply, FWIW. Oh. Good point. Not that I was pushing for that, but I would have missed this point if anyone else had wanted to push for it. >If you insist on going down this path, I'd like to see a >binary compatability strategy as the first output of the >project. Well, I am not insisting on much of anything, I am just making some observations which imply to me that 32-bit fields will not always be big enough. I also think it is a major enough change that we need to spend some time to "ease into" it, which is why I'm trying to drum up some support for the idea now. As to strategy, I guess we could start by adding two new fields to 'struct stat', which would be the 64-bit ones. We could truncate the 32-bit value and put that in the current fields. Some #define would govern whether a program sees st_dev and st_ino as the 32-bit values or the 64-bit values. That's the easy solution to the struct, but of course it doesn't address all the things which work with dev_t and ino_t. That's what we would have to work on over time. Or maybe we say that we're only going to do this on new 64-bit archs, and which implies we could make a more abrupt transition, and that binary-compatability isn't (yet) a big issue. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 12:18:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C0E6337B402 for ; Sun, 10 Mar 2002 12:18:44 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2AKIDnp065692; Sun, 10 Mar 2002 21:18:13 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sun, 10 Mar 2002 15:15:27 EST." Date: Sun, 10 Mar 2002 21:18:13 +0100 Message-ID: <65691.1015791493@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >Well, I am not insisting on much of anything, I am just making >some observations which imply to me that 32-bit fields will not >always be big enough. I also think it is a major enough change >that we need to spend some time to "ease into" it, which is why >I'm trying to drum up some support for the idea now. There isn't much change for these actually, since they do require two new syscalls and since very few programs even think about them. This is nowhere as troublesome as off_t was. >As to strategy, I guess we could start by adding two new fields to >'struct stat', which would be the 64-bit ones. We could truncate >the 32-bit value and put that in the current fields. Some #define >would govern whether a program sees st_dev and st_ino as the 32-bit >values or the 64-bit values. That's the easy solution to the struct, >but of course it doesn't address all the things which work with >dev_t and ino_t. That's what we would have to work on over time. No, we can't change the size of struct stat (binary compatibility!) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 13:16:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 880DE37B404 for ; Sun, 10 Mar 2002 13:15:58 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2ALFuoX034080; Sun, 10 Mar 2002 16:15:57 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <35384.1015748266@critter.freebsd.dk> References: <35384.1015748266@critter.freebsd.dk> Date: Sun, 10 Mar 2002 16:15:55 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:17 AM +0100 3/10/02, Poul-Henning Kamp wrote: >In message Garance A Drosihn writes: > >I don't see how this would work for OpenAFS. By that I mean that >>I do not know how the dev_t-pointer that you're talking about is >>used when implementing something like OpenAFS or ARLA support. > >I have no idea what the problem would be, so you will have to tell >me before I can answer you... Well, this will be an answer from the user-land perspective. It is only an observation of the number of "devices" involved, because I don't know the details of the underlying implementation. So, pick up a few grains of salt, and let's try the following... First, my starting assumption on the significance of the st_dev value. My take on that value is that if two files have the same value for their device, then you could remove one of those files and hardlink the other file to the name of the removed file. Hardlinks can not cross device boundaries, but if these two files have the same value for st_dev then that hard link would not be crossing a device boundry. Or, another way to think of it is that if two files have the same device-number, and if they both have an st_nlink count of 1, then removing one of those files will result in more space being available for the expansion of the other file. (perhaps after a reboot, to eliminate the question of open file descriptors keeping that first file around even though you have unlinked it). I do not know if the appropriate standards would agree with me on these views, but they seem like a logical premise. Otherwise, a st_dev value would have no special meaning at all. In afs/openafs/arla, the "device" (in the above sense of the word) is the AFS-volume. Disk quotas are applied at the AFS-volume-level. AFS also has the notion that the administrator can move a volume around between disk-partitions, or even disk-servers, without the user noticing. So, for disk-balancing purposes (among other things), it is ideal to have a lot of small-ish volumes instead of trying to cram as much as possible in each volume. There is also the concept of "read-only" vs "read-write" volumes. Every "read-only" cell would have a matching "read-write" cell, but they would be different devices as far as this st_dev value is concerned. Each read-write volume can also have a "backup volume", which is the snapshot of that read-write volume as it was at the time of the most recent backup (it is also read-only in nature). Thus, an AFS-cell tends to have a lot of volumes. In the AFS cell at RPI, there are over 12,000 user accounts, each of which has it's own AFS-volume (for disk-quota purposes), and each of which has a AFS-backup-volume. That's 24,000 volumes just for home directories, and I am sure we have well over 32K AFS-volumes in the AFS-cell at RPI. It's possible we have over 64K distinct AFS-volumes in the cell, but I don't know how to come up with the exact count for that. When running AFS, the machine effectively mounts all AFS cells that are defined in a file called 'CellServDB'. On our public unix machines, we define 163 different AFS-cells. Most of those AFS-cells are smaller than RPI's AFS-cell, but certainly all the volumes in those cells add even more unique devices. One way around all these devices would be to just create st_dev numbers on the fly, as each volume is referenced, and cache that value until the next reboot. That is probably workable, but I am a little uneasy about it because we (RPI) also had at least one professor who liked to do a 'find' of EVERYTHING in RPI's afs-cell, looking for any publicly-readable files, which he then provided in a file listing for anyone who was curious. What would happen to the machine he runs that 'find' command on? So, let's drop back and say my initial premise is wrong. Maybe the st_dev value is just an arbitrary number with absolutely no special meaning. We then have the question of how to map all of these AFS-volumes into st_dev values (where you might map multiple AFS-volumes into a single st_dev value, just so you have fewer unique st_dev values). Some care would have to be taken in how that mapping is done, just to be sure that two files which are in different AFS-volumes are recognized as different files even if they have the same value for st_ino. I have not looked into the openAFS source code yet, but from what I can see I would guess that what AFS uses for a volume ID (what *it* uses to keep track of each volume) is a 32-bit number. I'm seeing volume-id values like 537,315,825, for instance. At the same time that we have all these volumes, we can't assume that all volumes will have less than (say) 32K distinct inodes in them. The AFS-volumes for user's home directories are pretty small, but we (RPI) have other AFS-volumes which are hundreds of megabytes, and which thus can contain a lot of files. I *think* we even have a few AFS-volumes which are gigabyte-sized, but I know we try our best to discourage larger AFS-volumes. So, my basic observation is that with UFS2 we're probably going to want to increase the size of st_ino, but I would argue that we can't do that by *shrinking* the size of st_dev, and that I would also argue that it would make more sense to increase the size of st_dev at the same time we increase st_ino. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 13:52:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 67F4437B402 for ; Sun, 10 Mar 2002 13:52:15 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2ALqDoX079648; Sun, 10 Mar 2002 16:52:13 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <65691.1015791493@critter.freebsd.dk> References: <65691.1015791493@critter.freebsd.dk> Date: Sun, 10 Mar 2002 16:52:12 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:18 PM +0100 3/10/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > >>Well, I am not insisting on much of anything, I am just making >>some observations which imply to me that 32-bit fields will not >>always be big enough. I also think it is a major enough change >>that we need to spend some time to "ease into" it, which is why >>I'm trying to drum up some support for the idea now. > >There isn't much change for these actually, since they do require >two new syscalls and since very few programs even think about them. > >This is nowhere as troublesome as off_t was. > >>As to strategy, I guess we could start by adding two new fields to >>'struct stat', which would be the 64-bit ones. We could truncate >>the 32-bit value and put that in the current fields. Some #define >>would govern whether a program sees st_dev and st_ino as the 32-bit >>values or the 64-bit values. That's the easy solution to the struct, >>but of course it doesn't address all the things which work with > >dev_t and ino_t. > >No, we can't change the size of struct stat (binary compatibility!) Arg!! I keep forgetting that the routine which *calls* stat() is the one that gets the space for 'struct stat', and it only passes a pointer to that area into stat(). Okay, well, hmm. There are solutions for that, of course, but they're all a bit uglier. Start by adding the fields to the stat structure, but don't use them for anything. This will at least get it so applications obtain more space for the structure. This change could even be MFC'ed. Then I guess add a stat64() routine, and have a #define which causes the program to see 64-bit values for st_dev and st_ino, and to also call stat64 instead of just-plain-stat. And then maybe we could have 6.0-release move to using stat64 by default, and have a stat32 for backwards compatibility. I'm being vague here because I every specific way I think of doing this has some ugly corners to it... (particularly since we can not assume that the current userland dev_t and ino_t types are necessarily big enough to hold a pointer to some other information). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 14: 8:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 367F437B499 for ; Sun, 10 Mar 2002 14:07:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g2AM7tN11702; Sun, 10 Mar 2002 17:07:55 -0500 (EST) (envelope-from wollman) Date: Sun, 10 Mar 2002 17:07:55 -0500 (EST) From: Garrett Wollman Message-Id: <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu> To: arch@FreeBSD.org Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <3C8B002B.D42A8572@mindspring.com> References: <27966.1015713342@critter.freebsd.dk> Organization: MIT Laboratory for Computer Science Cc: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <3C8B002B.D42A8572@mindspring.com> Terry Lambert writes: >Note also that POSIX requires them to be atomic types. So >"long long" need not apply, FWIW. Methinks Terry would be well served by actually *reading* the POSIX standard some time. What POSIX says in this timeline is that dev_t shall be an ``arithmetic type of appropriate length''. (I.e., dev_t is allowed to be a complex if that is the implementor's desire.) POSIX goes on to require that ino_t be ``an unsigned integral type''. POSIX has absolutely no notion of ``atomic types'' other than sig_atomic_t. In other words, `long long' is a perfectly acceptable underlying type for both dev_t and ino_t. The only other advice POSIX gives on the subject is: # The st_ino and st_dev fields taken together uniquely identify the # file within the system. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 14: 8:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id CA0F637B41D for ; Sun, 10 Mar 2002 14:08:11 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2AM8AoX102586; Sun, 10 Mar 2002 17:08:10 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <35384.1015748266@critter.freebsd.dk> Date: Sun, 10 Mar 2002 17:08:09 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:15 PM -0500 3/10/02, Garance A Drosihn wrote: >In afs/openafs/arla, the "device" (in the above sense of the word) >is the AFS-volume. Disk quotas are applied at the AFS-volume-level. >[...] There is also the concept of "read-only" vs "read-write" >volumes. [...] Each read-write volume can also have a "backup >volume", which is the snapshot of that read-write volume as it >was at the time of the most recent backup (it is also read-only >in nature). The other thing about AFS-volumes is that any given AFS-volume can be mounted at multiple points in the afs file space. The AFS-volume is also the "mountable entity", except that the administrator of a cell will determine the initial layout of which volumes are mounted where. Ie, when administrator of a single machine decides to include some AFS-cell (by adding that cell to CellServDB), they are effectively specifying a list of tens-of-thousands of mounts which are all being done at one shot. The upshot of this is that our AFS cell as a specific volume (vid = 537315822) at /afs/rpi.edu/campus/lang/ruby/1.6. I (as a user) can type the command: cd ~/private fs mkmount myruby -vol 537315822 to get that exact same volume to show up at location ~drosehn/private/myruby So if I want to compare /afs/rpi.edu/campus/lang/ruby/1.6/README to ~drosehn/private/myruby/README then the stat call has to have the same st_dev for both of those files. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 17:10:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 761AC37B42A for ; Sun, 10 Mar 2002 17:10:18 -0800 (PST) Received: from pool0364.cvx22-bradley.dialup.earthlink.net ([209.179.199.109] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16kEKG-0003fU-00; Sun, 10 Mar 2002 17:10:08 -0800 Message-ID: <3C8C03DB.E673B495@mindspring.com> Date: Sun, 10 Mar 2002 17:09:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <65691.1015791493@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > >As to strategy, I guess we could start by adding two new fields to > >'struct stat', which would be the 64-bit ones. We could truncate > >the 32-bit value and put that in the current fields. Some #define > >would govern whether a program sees st_dev and st_ino as the 32-bit > >values or the 64-bit values. That's the easy solution to the struct, > >but of course it doesn't address all the things which work with > >dev_t and ino_t. That's what we would have to work on over time. > > No, we can't change the size of struct stat (binary compatibility!) I think the first thing we would change, wee we to "go hog wild" would be to make times in seconds 64 bits, anyway... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 17:22:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 84B0B37B404 for ; Sun, 10 Mar 2002 17:22:35 -0800 (PST) Received: from pool0364.cvx22-bradley.dialup.earthlink.net ([209.179.199.109] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16kEWH-0001T0-00; Sun, 10 Mar 2002 17:22:33 -0800 Message-ID: <3C8C06C6.5CEFF6AA@mindspring.com> Date: Sun, 10 Mar 2002 17:22:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: Increasing the size of dev_t and ino_t References: <27966.1015713342@critter.freebsd.dk> <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman wrote: > In article <3C8B002B.D42A8572@mindspring.com> Terry Lambert writes: > >Note also that POSIX requires them to be atomic types. So > >"long long" need not apply, FWIW. > > Methinks Terry would be well served by actually *reading* the POSIX > standard some time. Which POSIX? > What POSIX says in this timeline is that dev_t shall be an > ``arithmetic type of appropriate length''. (I.e., dev_t is allowed to > be a complex if that is the implementor's desire.) > > POSIX goes on to require that ino_t be ``an unsigned integral type''. > > POSIX has absolutely no notion of ``atomic types'' other than > sig_atomic_t. > > In other words, `long long' is a perfectly acceptable underlying type > for both dev_t and ino_t. The only other advice POSIX gives on the > subject is: I'm pretty positive that it was you who prevented us from switching over some values to time_t, based on the atomicity argument. Yes, I know "atomic" is not the correct POSIX adjective for this. > # The st_ino and st_dev fields taken together uniquely identify the > # file within the system. You can't both increase the size of the object and maintain binary compatability while satisfying this clause. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 17:53:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id A1EB337B402 for ; Sun, 10 Mar 2002 17:53:33 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2B1rVoX144060; Sun, 10 Mar 2002 20:53:31 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C8C03DB.E673B495@mindspring.com> References: <65691.1015791493@critter.freebsd.dk> <3C8C03DB.E673B495@mindspring.com> Date: Sun, 10 Mar 2002 20:53:30 -0500 To: Terry Lambert , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t + timestamps? Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 5:09 PM -0800 3/10/02, Terry Lambert wrote: >Poul-Henning Kamp wrote: >> >As to strategy, I guess we could start by adding two new fields to >> >'struct stat', which would be the 64-bit ones. We could truncate >> >the 32-bit value and put that in the current fields. Some #define >> >would govern whether a program sees st_dev and st_ino as the 32-bit >> >values or the 64-bit values. That's the easy solution to the struct, >> >but of course it doesn't address all the things which work with >> >dev_t and ino_t. That's what we would have to work on over time. >> >> No, we can't change the size of struct stat (binary compatibility!) > >I think the first thing we would change, wee we to "go hog >wild" would be to make times in seconds 64 bits, anyway... I meant to mention that too, as I believe UFS2 is also going to switch to 64-bit timestamps. I forget where we left the discussion of 64-bit time_t types though. I have a few messages saved away in a thread by Peter Wemm which suggest we could: 1: time_t assumptions in existing code should be fixed. 2: new platforms should start at time_t 64 bit 3: Once we've tested the water on the new platforms, *then* progress towards activating it on alpha and then x86. By then we'll have gathered enough *experience* on the new platforms to know how much pain the alpha and i386 will have, and we can judge whether its worth it. Until then, we're speculating. We have no hard data and no actual real experience. I don't know if we're really doing step #2 on the new platforms yet, although my interest-level increases now that sparc64 is getting to be a real port! :-) but at the very least, I do think we could add fields for 64-bit timestamps in 'struct stat' at the same time as we add 64-bit fields for dev_t and ino_t. The stat() routine doesn't have to fill them in, but we would just define them to increase the size of the struct so that room will be there down the road. Either that, or just give up on stat()/lstat() as being too hard to modify, leave them in stone forever, and provide some new stat-like routines which both fix the immediate issues and are more flexible when it comes to any future issues. Even if the new routines are just-like-stat except that they include a length-field so the called routine knows how big the stat-area is. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 22:29: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4737D37B402 for ; Sun, 10 Mar 2002 22:28:58 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2B6Swlv045555; Sun, 10 Mar 2002 22:28:58 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2B6RhBR045553; Sun, 10 Mar 2002 22:27:43 -0800 (PST) Date: Sun, 10 Mar 2002 22:27:42 -0800 From: "David O'Brien" To: Luigi Rizzo Cc: arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020310222742.A45475@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020309042728.A21016@iguana.icir.org> <20020309082607.I21016@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020309082607.I21016@iguana.icir.org>; from rizzo@icir.org on Sat, Mar 09, 2002 at 08:26:08AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Mar 09, 2002 at 08:26:08AM -0800, Luigi Rizzo wrote: > Note that this is only valid for the i386 so I will make > this code conditionally compiled if it ever gets committed. It didn't look like the commit to sysctl.c did that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 22:37:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C78F637B402 for ; Sun, 10 Mar 2002 22:37:43 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B6bHnp080531; Mon, 11 Mar 2002 07:37:18 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sun, 10 Mar 2002 17:09:47 PST." <3C8C03DB.E673B495@mindspring.com> Date: Mon, 11 Mar 2002 07:37:17 +0100 Message-ID: <80530.1015828637@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3C8C03DB.E673B495@mindspring.com>, Terry Lambert writes: >> No, we can't change the size of struct stat (binary compatibility!) > >I think the first thing we would change, wee we to "go hog >wild" would be to make times in seconds 64 bits, anyway... If there were one thing I'd like to change, it would be Terrys ability to preach on issues he hasn't quite grasped the full implications off. The change I'd want is to turn that ability off. Entirely off. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:16:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 09F1237B404 for ; Sun, 10 Mar 2002 23:16:36 -0800 (PST) Received: from pool0050.cvx40-bradley.dialup.earthlink.net ([216.244.42.50] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kK2c-0006qR-00; Sun, 10 Mar 2002 23:16:19 -0800 Message-ID: <3C8C59A9.7B102EAA@mindspring.com> Date: Sun, 10 Mar 2002 23:15:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <80530.1015828637@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <3C8C03DB.E673B495@mindspring.com>, Terry Lambert writes: > >> No, we can't change the size of struct stat (binary compatibility!) > > > >I think the first thing we would change, wee we to "go hog > >wild" would be to make times in seconds 64 bits, anyway... > > If there were one thing I'd like to change, it would be Terrys ability > to preach on issues he hasn't quite grasped the full implications off. > > The change I'd want is to turn that ability off. Entirely off. FWIW, and so that you understand what you have commented upon: "Hog wild" is an American expression which means "doing things which are inadvisable because one has thrown caution to the wind". In this case, it was a reference on the relative merits of reasons for destroying binary backward compatability. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:22: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7BF0437B402 for ; Sun, 10 Mar 2002 23:22:06 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B7Ljnp088791; Mon, 11 Mar 2002 08:21:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sun, 10 Mar 2002 23:15:53 PST." <3C8C59A9.7B102EAA@mindspring.com> Date: Mon, 11 Mar 2002 08:21:45 +0100 Message-ID: <88790.1015831305@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3C8C59A9.7B102EAA@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> In message <3C8C03DB.E673B495@mindspring.com>, Terry Lambert writes: >> >> No, we can't change the size of struct stat (binary compatibility!) >> > >> >I think the first thing we would change, wee we to "go hog >> >wild" would be to make times in seconds 64 bits, anyway... >> >> If there were one thing I'd like to change, it would be Terrys ability >> to preach on issues he hasn't quite grasped the full implications off. >> >> The change I'd want is to turn that ability off. Entirely off. > >FWIW, and so that you understand what you have commented upon: FWIW, and so that you understand what you have commented upon: I was referring to your ability to talk and talk and talk without ever checking your facts or submitting patches. The fact that we not only have to read your emails but also debunk them to avoid your misleading people with the 15% of facts you got wrong is an incredible waste of time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:30:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id D2B1037B405 for ; Sun, 10 Mar 2002 23:30:38 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B7UInp090336 for ; Mon, 11 Mar 2002 08:30:18 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: moving MAKEDEV + MAKEDEV.local to /etc From: Poul-Henning Kamp Date: Mon, 11 Mar 2002 08:30:18 +0100 Message-ID: <90335.1015831818@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I would like to move MAKEDEV and MAKEDEV.local to /etc instead of /dev in order to avoid trouble with DEVFS and various makefiles. Any objections ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:38:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 5AA5637B404 for ; Sun, 10 Mar 2002 23:38:08 -0800 (PST) Received: from pool0050.cvx40-bradley.dialup.earthlink.net ([216.244.42.50] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16kKNb-00074F-00; Sun, 10 Mar 2002 23:38:00 -0800 Message-ID: <3C8C5EBD.94E88534@mindspring.com> Date: Sun, 10 Mar 2002 23:37:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <88790.1015831305@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > FWIW, and so that you understand what you have commented upon: > > I was referring to your ability to talk and talk and talk without > ever checking your facts or submitting patches. I do both. Check the list archives. And unlike some people, I publically admit when I'm wrong. > The fact that we not only have to read your emails but also > debunk them to avoid your misleading people with the 15% of > facts you got wrong is an incredible waste of time. So what exactly were you debunking in my posting, again? Or is this a general mean-spirited comment because you're feeling hypersensitive any time anyone mentions a 64 bit time_t, because the discussion might get around to Kirk's posting of 26 Oct 2001? ] I left the spare space in the inode in anticipation of 64-bit ] time_t values. Unfortunately, it was coopted for other purposes. ] I am working on a major revision to UFS that uses 64-bit block ] pointers. I intend to put in 64-bit times as part of the revision. ] ] Kirk McKusick -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:41:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8705937B405 for ; Sun, 10 Mar 2002 23:41:12 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B7epnp092310; Mon, 11 Mar 2002 08:40:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sun, 10 Mar 2002 23:37:33 PST." <3C8C5EBD.94E88534@mindspring.com> Date: Mon, 11 Mar 2002 08:40:51 +0100 Message-ID: <92309.1015832451@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry, This is my procmail filter. .procmailrc send Terry to /dev/null. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:46:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0655E37B405; Sun, 10 Mar 2002 23:46:13 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id D3A6AAE25A; Sun, 10 Mar 2002 23:46:12 -0800 (PST) Date: Sun, 10 Mar 2002 23:46:12 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: moving MAKEDEV + MAKEDEV.local to /etc Message-ID: <20020311074612.GB63125@elvis.mu.org> References: <90335.1015831818@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90335.1015831818@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Poul-Henning Kamp [020310 23:30] wrote: > > I would like to move MAKEDEV and MAKEDEV.local to /etc instead of > /dev in order to avoid trouble with DEVFS and various makefiles. > > Any objections ? No problem, but wouldn't it be quite evil for devfs to fake a symlink to it? :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 10 23:53:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AF5CE37B432 for ; Sun, 10 Mar 2002 23:53:10 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B7qnnp094603; Mon, 11 Mar 2002 08:52:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: moving MAKEDEV + MAKEDEV.local to /etc In-Reply-To: Your message of "Sun, 10 Mar 2002 23:46:12 PST." <20020311074612.GB63125@elvis.mu.org> Date: Mon, 11 Mar 2002 08:52:49 +0100 Message-ID: <94602.1015833169@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020311074612.GB63125@elvis.mu.org>, Alfred Perlstein writes: >* Poul-Henning Kamp [020310 23:30] wrote: >> >> I would like to move MAKEDEV and MAKEDEV.local to /etc instead of >> /dev in order to avoid trouble with DEVFS and various makefiles. >> >> Any objections ? > >No problem, but wouldn't it be quite evil for devfs to fake a symlink >to it? :) What good would it be if you have DEVF mounted ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 0: 2:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id EE8CE37B41A for ; Mon, 11 Mar 2002 00:02:33 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B82Dnp096480; Mon, 11 Mar 2002 09:02:13 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sun, 10 Mar 2002 17:08:09 EST." Date: Mon, 11 Mar 2002 09:02:13 +0100 Message-ID: <96479.1015833733@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >So if I want to compare > /afs/rpi.edu/campus/lang/ruby/1.6/README >to > ~drosehn/private/myruby/README >then the stat call has to have the same st_dev for both of >those files. I'm missing something here, unless README is a device, st_dev has no meaning, no ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 0: 7: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id E704337B422 for ; Mon, 11 Mar 2002 00:06:57 -0800 (PST) Received: from pool0243.cvx21-bradley.dialup.earthlink.net ([209.179.192.243] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kKpZ-0002tu-00; Mon, 11 Mar 2002 00:06:54 -0800 Message-ID: <3C8C6581.B0300933@mindspring.com> Date: Mon, 11 Mar 2002 00:06:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <92309.1015832451@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Terry, This is my procmail filter. > > .procmailrc send Terry to /dev/null. Well, that certainly invalidates everything I say, if *you* never see it, doesn't it? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 0:11:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 6033E37B402 for ; Mon, 11 Mar 2002 00:11:21 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 3869EAE1FC; Mon, 11 Mar 2002 00:11:21 -0800 (PST) Date: Mon, 11 Mar 2002 00:11:21 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: moving MAKEDEV + MAKEDEV.local to /etc Message-ID: <20020311081121.GC63125@elvis.mu.org> References: <20020311074612.GB63125@elvis.mu.org> <94602.1015833169@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94602.1015833169@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Poul-Henning Kamp [020310 23:53] wrote: > In message <20020311074612.GB63125@elvis.mu.org>, Alfred Perlstein writes: > > > >No problem, but wouldn't it be quite evil for devfs to fake a symlink > >to it? :) > > What good would it be if you have DEVF mounted ? Stupid head cold.. bleh. Yeah, thanks. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 0:23:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 11BEA37B405 for ; Mon, 11 Mar 2002 00:23:42 -0800 (PST) Received: from pool0243.cvx21-bradley.dialup.earthlink.net ([209.179.192.243] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kL5e-0006V3-00; Mon, 11 Mar 2002 00:23:30 -0800 Message-ID: <3C8C6965.69DBA92A@mindspring.com> Date: Mon, 11 Mar 2002 00:23:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <96479.1015833733@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message , Garance A Drosihn writes: > >So if I want to compare > > /afs/rpi.edu/campus/lang/ruby/1.6/README > >to > > ~drosehn/private/myruby/README > >then the stat call has to have the same st_dev for both of > >those files. > > I'm missing something here, unless README is a device, st_dev > has no meaning, no ? It has meaning as part of a tuple that uniquely identifies the file. It's arguable whether or not the identification is permitted to be transient, or must be persistant. For example, AppleTalk requires that the 32 bit file identifier on a volume be non-transient, so that the identifier can be cached in the resource fork of another file, and used to look it up at an indeterminite future date. This was a significant issue in the NetWare for UNIX 4.x NXFS filesystem design I worked on at Novell in 1993/1994. The implication of this is that, for certain file sharing protocols, an identifier that was computed or otherwise derived from an expanded value (e.g. a 64 bit value) must be persistant, and not transiently derived (e.g. persistant only over the lifetime of a system uptime). For NFSv3 and NFSv2, for example, the recovery of file handles following a server failure requires that the value of the handles be persistant over a server reboot. A kernel AppleTalk server would have similar requirements, as would a kernel NetWare server. For user space, you could use an external database, but you would then end up with the common synchronization issues faced by hosted OS's, where the host OS doesn't go through the same enforcement code as the OS it is hosting. Of course, you don't have to take my word for it... ] Date: Sun, 10 Mar 2002 17:07:55 -0500 (EST) ] From: Garrett Wollman ] Message-Id: <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu> ] To: arch@FreeBSD.org ] Subject: Re: Increasing the size of dev_t and ino_t [ ... ] ] In other words, `long long' is a perfectly acceptable underlying type ] for both dev_t and ino_t. The only other advice POSIX gives on the ] subject is: ] ] # The st_ino and st_dev fields taken together uniquely identify the ] # file within the system. ] ] -GAWollman -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 1:28: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BAEFB37B404; Mon, 11 Mar 2002 01:28:02 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA16168; Mon, 11 Mar 2002 20:28:00 +1100 Date: Mon, 11 Mar 2002 20:29:17 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Smith Cc: Luigi Rizzo , Subject: Re: For review: machdep.bootdev sysctl (for i386) In-Reply-To: <200203101042.g2AAgCj03522@mass.dis.org> Message-ID: <20020311202346.K6034-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Mar 2002, Michael Smith wrote: [bootdev] > If it's added as something like machdep.guessed_bootdev, then I'll > probably just barf into a bag and forget about it. I can't promise that > the code won't get cleaned out at some point, but it's been quietly > rotting for a few years now, so I wouldn't consider it too much of a risk. I maintain this code locally but wouldn't commit my changes :-). Enough of it has been removed to break determining the root device from the boot device in some cases (the non-devfs case?). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 1:35:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 5BEC337B400 for ; Mon, 11 Mar 2002 01:35:07 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g2B9YuR10106; Mon, 11 Mar 2002 10:34:56 +0100 (MET) Date: Mon, 11 Mar 2002 10:34:55 +0100 (CET) From: Harti Brandt To: Garance A Drosihn Cc: Poul-Henning Kamp , Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: <20020311102511.M516-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Mar 2002, Garance A Drosihn wrote: GAD>First, my starting assumption on the significance of the st_dev GAD>value. My take on that value is that if two files have the same GAD>value for their device, then you could remove one of those files GAD>and hardlink the other file to the name of the removed file. GAD>Hardlinks can not cross device boundaries, but if these two files GAD>have the same value for st_dev then that hard link would not be GAD>crossing a device boundry. Or, another way to think of it is that GAD>if two files have the same device-number, and if they both have an GAD>st_nlink count of 1, then removing one of those files will result GAD>in more space being available for the expansion of the other file. GAD>(perhaps after a reboot, to eliminate the question of open file GAD>descriptors keeping that first file around even though you have GAD>unlinked it). I do not know if the appropriate standards would GAD>agree with me on these views, but they seem like a logical premise. GAD>Otherwise, a st_dev value would have no special meaning at all. There is an explicit requirement in POSIX: it requires a given st_ino/st_dev pair to uniqely identify a file. I take this to mean: if two files have the same st_ino/st_dev pair, they are the same file. If I mount the same volume in different places in the tree any file on that volume must have the same st_ino/st_dev pair in both mount points. As worded by POSIX the st_ino/st_dev pairs are not required to be persistant through reboots. It can, however, be hard to implement persistant file handles for NFS based on non-persistant st_info/st_dev pairs. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 1:36:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id AF7A937B41F for ; Mon, 11 Mar 2002 01:36:32 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g2B9aSR10322; Mon, 11 Mar 2002 10:36:28 +0100 (MET) Date: Mon, 11 Mar 2002 10:36:28 +0100 (CET) From: Harti Brandt To: Poul-Henning Kamp Cc: Garance A Drosihn , Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <96479.1015833733@critter.freebsd.dk> Message-ID: <20020311103513.M516-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Poul-Henning Kamp wrote: PK>In message , Garance A Drosihn writes: PK> PK>>So if I want to compare PK>> /afs/rpi.edu/campus/lang/ruby/1.6/README PK>>to PK>> ~drosehn/private/myruby/README PK>>then the stat call has to have the same st_dev for both of PK>>those files. PK> PK>I'm missing something here, unless README is a device, st_dev PK>has no meaning, no ? Because the two READMEs are the same file, the st_dev's (and st_ino's) of them must be the same. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 1:48:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6266B37B402 for ; Mon, 11 Mar 2002 01:48:22 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2B9lwnp017498; Mon, 11 Mar 2002 10:47:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Harti Brandt Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Mon, 11 Mar 2002 10:34:55 +0100." <20020311102511.M516-100000@beagle.fokus.gmd.de> Date: Mon, 11 Mar 2002 10:47:58 +0100 Message-ID: <17497.1015840078@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020311102511.M516-100000@beagle.fokus.gmd.de>, Harti Brandt write s: >There is an explicit requirement in POSIX: it requires a given >st_ino/st_dev pair to uniqely identify a file. I take this to mean: if two >files have the same st_ino/st_dev pair, they are the same file. If I mount >the same volume in different places in the tree any file on that volume >must have the same st_ino/st_dev pair in both mount points. As worded by >POSIX the st_ino/st_dev pairs are not required to be persistant through >reboots. It can, however, be hard to implement persistant file handles for >NFS based on non-persistant st_info/st_dev pairs. (Sorry, I confused st_dev and st_rdev earlier). Ok, I think we are on the same page now. I don't think any of the stuff headed for -current would give you trouble in this respect. Just because we _can_ assign a random st_dev doesn't mean we will shoot ourselves in the foot by doing so :-) And still, I see no pressure to increase the size of (u)dev_t on any platforms. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 1:55:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 48D0337B400 for ; Mon, 11 Mar 2002 01:55:07 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g2B9t1R12907; Mon, 11 Mar 2002 10:55:01 +0100 (MET) Date: Mon, 11 Mar 2002 10:55:01 +0100 (CET) From: Harti Brandt To: Poul-Henning Kamp Cc: Garance A Drosihn , Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <17497.1015840078@critter.freebsd.dk> Message-ID: <20020311105221.O516-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Poul-Henning Kamp wrote: PK>In message <20020311102511.M516-100000@beagle.fokus.gmd.de>, Harti Brandt write PK>s: PK> PK>>There is an explicit requirement in POSIX: it requires a given PK>>st_ino/st_dev pair to uniqely identify a file. I take this to mean: if two PK>>files have the same st_ino/st_dev pair, they are the same file. If I mount PK>>the same volume in different places in the tree any file on that volume PK>>must have the same st_ino/st_dev pair in both mount points. As worded by PK>>POSIX the st_ino/st_dev pairs are not required to be persistant through PK>>reboots. It can, however, be hard to implement persistant file handles for PK>>NFS based on non-persistant st_info/st_dev pairs. PK> PK>(Sorry, I confused st_dev and st_rdev earlier). PK> PK>Ok, I think we are on the same page now. PK> PK>I don't think any of the stuff headed for -current would give you PK>trouble in this respect. Just because we _can_ assign a random PK>st_dev doesn't mean we will shoot ourselves in the foot by doing so :-) PK> PK>And still, I see no pressure to increase the size of (u)dev_t on PK>any platforms. Given that (u)dev_t is 32 bit according to types(5) you are right. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 4:27:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id CC09537B402 for ; Mon, 11 Mar 2002 04:27:54 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id C39E01D169; Mon, 11 Mar 2002 12:06:12 +0000 (GMT) Subject: Re: moving MAKEDEV + MAKEDEV.local to /etc From: Paul Richards To: Alfred Perlstein Cc: Poul-Henning Kamp , arch@freebsd.org In-Reply-To: <20020311081121.GC63125@elvis.mu.org> References: <20020311074612.GB63125@elvis.mu.org> <94602.1015833169@critter.freebsd.dk> <20020311081121.GC63125@elvis.mu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 12:06:23 +0000 Message-Id: <1015848384.61331.1.camel@lobster.freebsd-services.com> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2002-03-11 at 08:11, Alfred Perlstein wrote: > * Poul-Henning Kamp [020310 23:53] wrote: > > In message <20020311074612.GB63125@elvis.mu.org>, Alfred Perlstein writes: > > > > > >No problem, but wouldn't it be quite evil for devfs to fake a symlink > > >to it? :) > > > > What good would it be if you have DEVF mounted ? > > Stupid head cold.. bleh. Yeah, thanks. :) I think /usr/share/ would be a better place, since this is a file that's really going away in future releases and I don't think cluttering /etc with it, just to keep it around for reference, is sensible. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 6:20:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C4E1637B41E for ; Mon, 11 Mar 2002 06:20:21 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g2BEKEr06720; Mon, 11 Mar 2002 09:20:14 -0500 (EST) (envelope-from wollman) Date: Mon, 11 Mar 2002 09:20:14 -0500 (EST) From: Garrett Wollman Message-Id: <200203111420.g2BEKEr06720@khavrinen.lcs.mit.edu> To: phk@critter.freebsd.dk Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <96479.1015833733@critter.freebsd.dk> References: Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <96479.1015833733@critter.freebsd.dk> you write: >I'm missing something here, unless README is a device, st_dev >has no meaning, no ? You're confusing st_dev and st_rdev. st_rdev is the device that the file *is* (iff the stat buffer represents a block or character special file); st_dev is the device (or more accurately, identifies the filesystem) that the file is *on*. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 8:14:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1CEAB37B416 for ; Mon, 11 Mar 2002 08:14:42 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2BGEdrT073368; Mon, 11 Mar 2002 11:14:40 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <17497.1015840078@critter.freebsd.dk> References: <17497.1015840078@critter.freebsd.dk> Date: Mon, 11 Mar 2002 11:14:38 -0500 To: Poul-Henning Kamp , Harti Brandt From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:47 AM +0100 3/11/02, Poul-Henning Kamp wrote: >(Sorry, I confused st_dev and st_rdev earlier). > >Ok, I think we are on the same page now. > >I don't think any of the stuff headed for -current would give >you trouble in this respect. Just because we _can_ assign a >random st_dev doesn't mean we will shoot ourselves in the foot >by doing so :-) Given what we (RPI) have with our present AFS cell, I am not sure how easy it will be to do this. If you follow my previous description of AFS, you realize that RPI (by itself) has over 33,000 unique AFS volumes. We also have users who will touch a large percentage of those volumes by typing in a single 'find' command. If FreeBSD comes up with a unique random number for each volume as it is referenced, and it has to cache all the mappings between unique-numbers and AFS-volumes (so it can tell when the same AFS volume is found at a different pathname in AFS space), then that strikes me as an unwieldy situation. Perhaps I should just explain it this way. Assume that a person can have an /etc/fstab which will mount >33,000 separate volumes. Do not debate whether you believe this will happen, because it is *already* happening with AFS at RPI. Given a situation where the system will have more than 33,000 separate mounts, can we come up with a good way to cache all those random numbers? Also note that the >33,000 number is only for the AFS cell at RPI, and the way AFS works any single workstation can be mounting volumes from more than 150 different AFS cells. AFS is trying to create a world-wide distributed file system, and as such it sees scaling issues that no one faces with NFS. >And still, I see no pressure to increase the size of (u)dev_t >on any platforms. My thinking is: 1) there will be a desire to increase (u)ino_t to 64-bits due to UFS2. 2) due to AFS, I don't want that to happen by *shrinking* the size of (u)dev_t (which had been suggested in some messages when I brought this up a year or two ago). 3) if we have to make the incompatible change for a 64-bit (u)ino_t, it would make some sense to also leave room in the new 'struct stat' for 64-bit timestamps and maybe even a 64-bit (u)dev_t, although I do agree that the 64-bit (u)dev_t is the least important change to consider... I am not completely certain that (u)dev_t needs to increase in size, but I am pretty close to adamant that it must not decrease in size. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 8:22:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7FA4937B402 for ; Mon, 11 Mar 2002 08:22:46 -0800 (PST) Received: from pool0620.cvx22-bradley.dialup.earthlink.net ([209.179.200.110] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kSZE-0000TS-00; Mon, 11 Mar 2002 08:22:33 -0800 Message-ID: <3C8CD9B8.53D6B36F@mindspring.com> Date: Mon, 11 Mar 2002 08:22:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <17497.1015840078@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > At 10:47 AM +0100 3/11/02, Poul-Henning Kamp wrote: > >(Sorry, I confused st_dev and st_rdev earlier). > > > >Ok, I think we are on the same page now. > > > >I don't think any of the stuff headed for -current would give > >you trouble in this respect. Just because we _can_ assign a > >random st_dev doesn't mean we will shoot ourselves in the foot > >by doing so :-) > > Given what we (RPI) have with our present AFS cell, I am not > sure how easy it will be to do this. If you follow my previous > description of AFS, you realize that RPI (by itself) has over > 33,000 unique AFS volumes. We also have users who will touch > a large percentage of those volumes by typing in a single 'find' > command. If FreeBSD comes up with a unique random number for > each volume as it is referenced, and it has to cache all the > mappings between unique-numbers and AFS-volumes (so it can > tell when the same AFS volume is found at a different pathname > in AFS space), then that strikes me as an unwieldy situation. Poul is a non-native English speaker, and this often leads to intepretation issues. The usage here is archaic English, and the "can"/"will" are paired, which isn't clear from the use of the predicate phrase "by doing so". You should read this as "Just because we _can_ ... doesn't mean we _will_ ...". > Also note that the >33,000 number is only for the AFS cell at > RPI, and the way AFS works any single workstation can be mounting > volumes from more than 150 different AFS cells. AFS is trying > to create a world-wide distributed file system, and as such it > sees scaling issues that no one faces with NFS. This is a seperate problem. As you note, the number is already larger than 2^15; it's going to face scaling issues, no matter how you look at it, due to the single volume identification space. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 8:23:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id D06AB37B402 for ; Mon, 11 Mar 2002 08:23:07 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2BGMinp092466; Mon, 11 Mar 2002 17:22:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Mon, 11 Mar 2002 11:14:38 EST." Date: Mon, 11 Mar 2002 17:22:44 +0100 Message-ID: <92465.1015863764@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >At 10:47 AM +0100 3/11/02, Poul-Henning Kamp wrote: >>(Sorry, I confused st_dev and st_rdev earlier). >> >>Ok, I think we are on the same page now. >> >>I don't think any of the stuff headed for -current would give >>you trouble in this respect. Just because we _can_ assign a >>random st_dev doesn't mean we will shoot ourselves in the foot >>by doing so :-) > >Given what we (RPI) have with our present AFS cell, I am not >sure how easy it will be to do this. If you follow my previous >description of AFS, you realize that RPI (by itself) has over >33,000 unique AFS volumes. We also have users who will touch >a large percentage of those volumes by typing in a single 'find' >command. If FreeBSD comes up with a unique random number for >each volume as it is referenced, and it has to cache all the >mappings between unique-numbers and AFS-volumes (so it can >tell when the same AFS volume is found at a different pathname >in AFS space), then that strikes me as an unwieldy situation. As I said: "Just because we can doesn't mean we will or should". >>And still, I see no pressure to increase the size of (u)dev_t >>on any platforms. > 3) if we have to make the incompatible change for a 64-bit > (u)ino_t, it would make some sense to also leave room > in the new 'struct stat' for 64-bit timestamps and > maybe even a 64-bit (u)dev_t, although I do agree that > the 64-bit (u)dev_t is the least important change to > consider... I don't mind reserving the space, and I may not even mind making udev_t larger, I just don't see a pressure to do so. >I am not completely certain that (u)dev_t needs to increase in >size, but I am pretty close to adamant that it must not decrease >in size. Don't worry, only people totally disconnected with reality would try that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 8:27:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 45EA037B404 for ; Mon, 11 Mar 2002 08:27:34 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g2BGRTR27388; Mon, 11 Mar 2002 17:27:29 +0100 (MET) Date: Mon, 11 Mar 2002 17:27:29 +0100 (CET) From: Harti Brandt To: Garance A Drosihn Cc: Poul-Henning Kamp , Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: <20020311172142.K1371-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Garance A Drosihn wrote: GAD>At 10:47 AM +0100 3/11/02, Poul-Henning Kamp wrote: GAD>>(Sorry, I confused st_dev and st_rdev earlier). GAD>> GAD>>Ok, I think we are on the same page now. GAD>> GAD>>I don't think any of the stuff headed for -current would give GAD>>you trouble in this respect. Just because we _can_ assign a GAD>>random st_dev doesn't mean we will shoot ourselves in the foot GAD>>by doing so :-) GAD> GAD>Given what we (RPI) have with our present AFS cell, I am not GAD>sure how easy it will be to do this. If you follow my previous GAD>description of AFS, you realize that RPI (by itself) has over GAD>33,000 unique AFS volumes. We also have users who will touch GAD>a large percentage of those volumes by typing in a single 'find' GAD>command. If FreeBSD comes up with a unique random number for GAD>each volume as it is referenced, and it has to cache all the GAD>mappings between unique-numbers and AFS-volumes (so it can GAD>tell when the same AFS volume is found at a different pathname GAD>in AFS space), then that strikes me as an unwieldy situation. I suppose the AFS volumes themself have some kind of unique identifier, otherwise there would be no way to tell that you are mounting the same volume in different places, there wouldn't even be the notion of 'the same volume'. Given that, it should be simple to map between those AFS volume identifiers and st_dev's. How this mapping is done depends on the kind of the volume id. If you have 33,000 mounts in you system, adding a uint32_t to each of these mounts will not be your main problem. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 8:40:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id B645037B405 for ; Mon, 11 Mar 2002 08:40:19 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g2BGeGA93090; Mon, 11 Mar 2002 17:40:16 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g2BGbwEL048633; Mon, 11 Mar 2002 17:37:58 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id g2BGbtN06745; Mon, 11 Mar 2002 17:37:55 +0100 (CET) (envelope-from ticso) Date: Mon, 11 Mar 2002 17:37:54 +0100 From: Bernd Walter To: Paul Richards Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: moving MAKEDEV + MAKEDEV.local to /etc Message-ID: <20020311163754.GJ4295@cicely8.cicely.de> References: <20020311074612.GB63125@elvis.mu.org> <94602.1015833169@critter.freebsd.dk> <20020311081121.GC63125@elvis.mu.org> <1015848384.61331.1.camel@lobster.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1015848384.61331.1.camel@lobster.freebsd-services.com> User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 11, 2002 at 12:06:23PM +0000, Paul Richards wrote: > On Mon, 2002-03-11 at 08:11, Alfred Perlstein wrote: > > * Poul-Henning Kamp [020310 23:53] wrote: > > > In message <20020311074612.GB63125@elvis.mu.org>, Alfred Perlstein writes: > > > > > > > >No problem, but wouldn't it be quite evil for devfs to fake a symlink > > > >to it? :) > > > > > > What good would it be if you have DEVF mounted ? > > > > Stupid head cold.. bleh. Yeah, thanks. :) > > I think /usr/share/ would be a better place, since this is a file that's > really going away in future releases and I don't think cluttering /etc > with it, just to keep it around for reference, is sensible. /usr/share should be platform independend - MAKEDEV is not. Plus /usr/share is possibly on a different partition. I personaly would prefer /sbin as its more an executeable than a config file, but /etc is also OK for me. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 9:19:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1051F37B404 for ; Mon, 11 Mar 2002 09:19:48 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2BHJkrT143102; Mon, 11 Mar 2002 12:19:46 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <92465.1015863764@critter.freebsd.dk> References: <92465.1015863764@critter.freebsd.dk> Date: Mon, 11 Mar 2002 12:19:45 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Harti Brandt , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 5:22 PM +0100 3/11/02, Poul-Henning Kamp wrote: > >As I said: "Just because we can doesn't mean we will >or should". Okay. I had misunderstood what you were saying in the earlier message. As long as it works for the AFS/ARLA case I'll be happy. I get a little uneasy about these things, because I expect that very few freebsd'ers work in an AFS world, and solutions which will be perfectly fine for NFS mounts might have scaling problems when used for AFS. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 9:24:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AAD1037B400 for ; Mon, 11 Mar 2002 09:24:17 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2BHNrnp004253; Mon, 11 Mar 2002 18:23:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Mon, 11 Mar 2002 12:19:45 EST." Date: Mon, 11 Mar 2002 18:23:53 +0100 Message-ID: <4252.1015867433@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >At 5:22 PM +0100 3/11/02, Poul-Henning Kamp wrote: >> >>As I said: "Just because we can doesn't mean we will >>or should". > >Okay. I had misunderstood what you were saying in the >earlier message. As long as it works for the AFS/ARLA >case I'll be happy. I get a little uneasy about these >things, because I expect that very few freebsd'ers work >in an AFS world, and solutions which will be perfectly >fine for NFS mounts might have scaling problems when >used for AFS. But you could do me a favour: Write up a piece of text which gives enough info for somebody like me to setup and test AFS/ARLA in my lab... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 10:47:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by hub.freebsd.org (Postfix) with ESMTP id AD3BD37B402 for ; Mon, 11 Mar 2002 10:47:32 -0800 (PST) Received: (from root@localhost) by hal-5.inet.it (8.11.1/8.11.1) id g2BIlVo364192 for ; Mon, 11 Mar 2002 19:47:31 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-5.inet.it via I-SMTP-4.0.5-100 id s-213.92.1.165-mYjNgd; Mon Mar 11 19:47:31 2002 Received: by acampi.inet.it (Postfix, from userid 1000) id 1802115537; Mon, 11 Mar 2002 19:47:31 +0100 (CET) Date: Mon, 11 Mar 2002 19:47:30 +0100 From: Andrea Campi To: Poul-Henning Kamp Cc: Garance A Drosihn , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020311184730.GA6282@webcom.it> References: <4252.1015867433@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4252.1015867433@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 11, 2002 at 06:23:53PM +0100, Poul-Henning Kamp wrote: > In message , Garance A Drosihn writes: > >At 5:22 PM +0100 3/11/02, Poul-Henning Kamp wrote: > >> > >>As I said: "Just because we can doesn't mean we will > >>or should". > > > >Okay. I had misunderstood what you were saying in the > >earlier message. As long as it works for the AFS/ARLA > >case I'll be happy. I get a little uneasy about these > >things, because I expect that very few freebsd'ers work > >in an AFS world, and solutions which will be perfectly > >fine for NFS mounts might have scaling problems when > >used for AFS. > > But you could do me a favour: Write up a piece of text > which gives enough info for somebody like me to setup > and test AFS/ARLA in my lab... Also note that ARLA is probably broken on -current right now. I sent a patch to the arla guys some time ago, but had to stop working on that and now the patch is badly outdated. If anybody wants to pick up the job, I'll be more than happy to send what I have. Bye, andrea > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 10:51:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 22B5B37B404 for ; Mon, 11 Mar 2002 10:51:22 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2BIownp021266; Mon, 11 Mar 2002 19:50:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Andrea Campi Cc: Garance A Drosihn , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Mon, 11 Mar 2002 19:47:30 +0100." <20020311184730.GA6282@webcom.it> Date: Mon, 11 Mar 2002 19:50:58 +0100 Message-ID: <21265.1015872658@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020311184730.GA6282@webcom.it>, Andrea Campi writes: >> But you could do me a favour: Write up a piece of text >> which gives enough info for somebody like me to setup >> and test AFS/ARLA in my lab... > >Also note that ARLA is probably broken on -current right >now. I sent a patch to the arla guys some time ago, but had >to stop working on that and now the patch is badly >outdated. If anybody wants to pick up the job, I'll be more >than happy to send what I have. Well, I won't promise to pick it up, but if it were working and there were a test-case or two, the chances of it breaking again would decrease. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 12: 0:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 4E27237B416 for ; Mon, 11 Mar 2002 12:00:26 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020311200025.QRPQ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 11 Mar 2002 20:00:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA64653; Mon, 11 Mar 2002 11:50:09 -0800 (PST) Date: Mon, 11 Mar 2002 11:50:07 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Garance A Drosihn wrote: > > Perhaps I should just explain it this way. Assume that a person > can have an /etc/fstab which will mount >33,000 separate volumes. > Do not debate whether you believe this will happen, because it > is *already* happening with AFS at RPI. Given a situation where > the system will have more than 33,000 separate mounts, can we > come up with a good way to cache all those random numbers? I suggest that we create such a number and store it in the filesystem superblock for filesystems in questions. maybe the time of creation in secs since the epoch. (is that already there?) it has the advantage of following the drive if it were renamed.. > > Also note that the >33,000 number is only for the AFS cell at > RPI, and the way AFS works any single workstation can be mounting > volumes from more than 150 different AFS cells. AFS is trying > to create a world-wide distributed file system, and as such it > sees scaling issues that no one faces with NFS. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 13: 6: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E255737B444 for ; Mon, 11 Mar 2002 13:05:53 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2BL5prT095728; Mon, 11 Mar 2002 16:05:51 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 11 Mar 2002 16:05:50 -0500 To: Julian Elischer From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:50 AM -0800 3/11/02, Julian Elischer wrote: >On Mon, 11 Mar 2002, Garance A Drosihn wrote: > > > Perhaps I should just explain it this way. Assume that a person >> can have an /etc/fstab which will mount >33,000 separate volumes. >> Do not debate whether you believe this will happen, because it >> is *already* happening with AFS at RPI. Given a situation where >> the system will have more than 33,000 separate mounts, can we > > come up with a good way to cache all those random numbers? > >I suggest that we create such a number and store it in the >filesystem superblock for filesystems in questions. maybe the >time of creation in secs since the epoch. (is that already there?) >it has the advantage of following the drive if it were renamed.. Unfortunately the idea of "the drive" is one which does not map well into an AFS filesystem. Each AFS-site is making thousands of volumes available, and you're running an AFS client. The AFS servers are scattered around the globe. There is zero chance that you can get everyone who runs an AFS server (sites which are literally scattered around the planet) to add a 32-bit number somewhere to each of those volumes. And your machine will not have write-access to those volumes, unless you are an authenticated user (at that site) who has write-access to the directory the file is in. Also note that a lot of sites make read-only repositories available to anyone in the AFS world, eg: /afs/athena.mit.edu/reference/rfc . So, users will want to reference AFS-sites and AFS-volumes that they have no write access to (and NOTHING on your machine -- not even root -- will have write-access to those remote files or remote volumes). I don't know if there is any useful value which is already available and which is *less than* 32-bits. (it would have to be less-than, because any such value is only going to be unique across a single AFS-site, and there are more than 150 such sites, plus you don't want to run into conflicts with the st_dev's that you come up with for non-AFS files). At any given site, an AFS volume can move across disks and indeed across server-machines without the user noticing. Whatever we pick as a value for st_dev is something that must not change when a file (well, the whole volume it is on) is moved around like that. Here at RPI we do such migrations all the time, to keep our disks balanced (wrt how much free space they have). AFS has a lot of cool things about it, actually. It is Very Nice in several ways. However, there are many assumptions which are perfectly valid when talking about non-AFS filesystems, but which break down when applied to AFS. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 13:17:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B7C2237B402 for ; Mon, 11 Mar 2002 13:17:11 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2BLGni47870; Mon, 11 Mar 2002 16:16:49 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Mar 2002 16:16:48 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Harti Brandt Cc: Garance A Drosihn , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <20020311172142.K1371-100000@beagle.fokus.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Harti Brandt wrote: > I suppose the AFS volumes themself have some kind of unique identifier, > otherwise there would be no way to tell that you are mounting the same > volume in different places, there wouldn't even be the notion of 'the > same volume'. Given that, it should be simple to map between those AFS > volume identifiers and st_dev's. How this mapping is done depends on the > kind of the volume id. If you have 33,000 mounts in you system, adding a > uint32_t to each of these mounts will not be your main problem. AFS, Coda, and various other "global scale" filesystems rely on a much larger unique identifier space than the traditional 64-bit (dev_t, ino_t) pair. Coda, for example, uses a 96-bit "Vice ID" which is per-realm. That is partitioned into volume ID's and individual file ID's, which are similar to "filesystems" and "inode numbers". However, the problem occurs because our mount system doesn't scale to the level required for Coda or AFS to function. As such, Coda and AFS have their own light-weight mounting scheme inside the filesystem implementation, so it appears to the kernel as though it's a single huge filesystem, rather than a composite of many filesystems. In AFS, these mountpoints are stored in symlinks identifying the realm and volume name of the target. The complicating factor comes when you try and map the 96-bit (plus realm) into the 32-bit inode number. FreeBSD runs fine, but some applications assuming the POSIX device number/inode number equality behave poorly. For example, gnu tar may find collisions and assume files are a hard link when they are not. Linux, on the other hand, uses the inode numbers within the kernel, and may panic if there is a collision. The "uniqueness" aspect for these numbers is a serious scaling problem: global filesystems can and will name trillions of file system objects. Squeezing them into a single 32-bit number, or even a pair, simply doesn't work. Moving to a 64-bit inode number in FreeBSD would reduce the chances of a collision dramatically, and probably enough that the risk would become acceptable. A preferred solution approximates the POSIX conventions but allows for a special call into the filesystem to check collision cases. I actually implemented this on FreeBSD at one point. The filesystem implementation attempts to maintain a unique inode number by hashing the vice ID. For applications maintaining tables, such as tar, a collision can be resolved by calling samefile() or fsamefile(), which compare the vnode pointers, or call into the individual filesystem to inquire using a VOP. In this manner, the efficiency gains are largely still present, except that the identical values are a hint as opposed to a guarantee. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 14: 3:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E1CE137B400 for ; Mon, 11 Mar 2002 14:03:29 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2BM3MrT099232; Mon, 11 Mar 2002 17:03:22 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <4252.1015867433@critter.freebsd.dk> References: <4252.1015867433@critter.freebsd.dk> Date: Mon, 11 Mar 2002 17:03:21 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Harti Brandt , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 6:23 PM +0100 3/11/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > >Okay. I had misunderstood what you were saying in the >>earlier message. As long as it works for the AFS/ARLA >>case I'll be happy. I get a little uneasy about these >>things, because I expect that very few freebsd'ers work >>in an AFS world, and solutions which will be perfectly >>fine for NFS mounts might have scaling problems when >>used for AFS. > >But you could do me a favour: Write up a piece of text >which gives enough info for somebody like me to setup >and test AFS/ARLA in my lab... Hmm. This is a very reasonable request, but I am not sure I have a good answer... Does your lab have reasonably-fast connectivity to the internet at large? If so, then I could see about writing something for setting up a machine as an AFS client and having it pretend it is part of some already-existing AFS cell. I do not actually use OpenAFS or ARLA on my freebsd systems, but I certainly do want to figure that out. If you do not have a fast network connection, then you would need to set up your own AFS server. I do not know how to do that, and I am pretty sure it is not something that someone could do in an afternoon. The AFS cell at RPI has 600-gigabytes of disk space in it, so I haven't had much of an urge to start my own server! On the other hand, I would really really like to get at that 600-gig from FreeBSD clients. There is a web site for openafs, at www.openafs.org. That has downloadable client installations forMacOS 10, some versions of Windows, Linux, Solaris, IRIX, AIX, and Tru64 Unix. That web site does not have a client for the Net,Open, or FreeBSD's. Most of the BSD's probably go with the ARLA port for their AFS client. Unfortunately, I noticed that someone else just mentioned that the ARLA port is broken on current -- and here I just switched to running current. Sigh... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 14: 9:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 2DF8537B402; Mon, 11 Mar 2002 14:09:49 -0800 (PST) Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2BM9mj03325; Mon, 11 Mar 2002 23:09:48 +0100 Date: Mon, 11 Mar 2002 23:09:48 +0100 From: Christoph Hellwig To: Robert Watson Cc: Harti Brandt , Garance A Drosihn , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020311230948.A2914@caldera.de> References: <20020311172142.K1371-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Mon, Mar 11, 2002 at 04:16:48PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 11, 2002 at 04:16:48PM -0500, Robert Watson wrote: > The complicating factor comes when you try and map the 96-bit (plus realm) > into the 32-bit inode number. FreeBSD runs fine, but some applications > assuming the POSIX device number/inode number equality behave poorly. For > example, gnu tar may find collisions and assume files are a hard link when > they are not. Linux, on the other hand, uses the inode numbers within the > kernel, and may panic if there is a collision. The only place Linux uses the inode number is the generic inode cache implementation, which may or may not be used by filesystems. Also there won't be panic because you can't read in two inodes having the same i_ino when using it.. Christoph -- Of course it doesn't work. We've performed a software upgrade. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 14:15:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EF9C337B402 for ; Mon, 11 Mar 2002 14:15:49 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2BMFXi48782; Mon, 11 Mar 2002 17:15:33 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Mar 2002 17:15:32 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Christoph Hellwig Cc: Harti Brandt , Garance A Drosihn , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <20020311230948.A2914@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Christoph Hellwig wrote: > On Mon, Mar 11, 2002 at 04:16:48PM -0500, Robert Watson wrote: > > The complicating factor comes when you try and map the 96-bit (plus realm) > > into the 32-bit inode number. FreeBSD runs fine, but some applications > > assuming the POSIX device number/inode number equality behave poorly. For > > example, gnu tar may find collisions and assume files are a hard link when > > they are not. Linux, on the other hand, uses the inode numbers within the > > kernel, and may panic if there is a collision. > > The only place Linux uses the inode number is the generic inode cache > implementation, which may or may not be used by filesystems. Also there > won't be panic because you can't read in two inodes having the same > i_ino when using it.. I may be dated: when we were working on the Coda port to Linux, once in a while the system would blow a fuse when there was an inode number collision. I remember some similar reports on Arla. However, that may have been 2.1.x or before, or/and I may have misunderstood the failure mode. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 14:59: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pericles.IPAustralia.gov.au (pericles.IPAustralia.gov.au [202.14.186.30]) by hub.freebsd.org (Postfix) with ESMTP id 8C78D37B43B; Mon, 11 Mar 2002 14:58:54 -0800 (PST) Received: (from smap@localhost) by pericles.IPAustralia.gov.au (8.11.3/8.11.1) id g2BMwrg93356; Tue, 12 Mar 2002 09:58:53 +1100 (EST) (envelope-from carl@xena.ipaustralia.gov.au) Received: from newton.aipo.gov.au(10.0.100.18) by pericles.IPAustralia.gov.au via smap (V2.1) id xma093348; Tue, 12 Mar 02 09:58:47 +1100 Received: (from carl@localhost) by newton.aipo.gov.au (8.11.6/8.11.6) id g2BMwlY78370; Tue, 12 Mar 2002 09:58:47 +1100 (EST) (envelope-from carl@xena.ipaustralia.gov.au) X-Authentication-Warning: newton.aipo.gov.au: carl set sender to carl@xena.ipaustralia.gov.au using -f Subject: Re: GEOM code ready for testing From: Carl Makin To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <47754.1015785294@critter.freebsd.dk> References: <47754.1015785294@critter.freebsd.dk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Mar 2002 10:58:47 +1200 Message-Id: <1015887527.74983.41.camel@newton.aipo.gov.au> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: > The GEOM code is now ready for early testing: Would GEOM support accessing a device via multiple paths? (ie could we write a method that would do that?) My current situation is that I have a couple of IBM ESS F20 Sharks each with 3 fibre channel cards hooked to 3 brocade switches. When I allocate a LUN out of either shark it appears as 3 separate devices. IBM ship software called "SDD" that provides a single virtual device "VPATH" on NT, Solaris and AIX and load balances. At the moment when I hook up a FreeBSD box I just select one of the devices and ignore the others. Mildly annoying and I have to bring down the FreeBSD boxes when we upgrade the microcode on the shark. Carl. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 15:11:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id DB85637B416 for ; Mon, 11 Mar 2002 15:11:23 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2BNBLrT147966; Mon, 11 Mar 2002 18:11:22 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 11 Mar 2002 18:11:20 -0500 To: Julian Elischer From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:50 AM -0800 3/11/02, Julian Elischer wrote: >I suggest that we create such a number and store it in >the filesystem superblock for filesystems in questions. >maybe the time of creation in secs since the epoch. >(is that already there?) it has the advantage of >following the drive if it were renamed.. I do like this idea for drives though, especially for removable-storage devices (which might include firewire hard drives, for instance)... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 16:14:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id A843C37B416 for ; Mon, 11 Mar 2002 16:14:37 -0800 (PST) Received: from pool0501.cvx40-bradley.dialup.earthlink.net ([216.244.43.246] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kZvt-0005IV-00; Mon, 11 Mar 2002 16:14:26 -0800 Message-ID: <3C8D4850.B12087C2@mindspring.com> Date: Mon, 11 Mar 2002 16:14:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Julian Elischer , Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > At 11:50 AM -0800 3/11/02, Julian Elischer wrote: > >I suggest that we create such a number and store it in > >the filesystem superblock for filesystems in questions. > >maybe the time of creation in secs since the epoch. > >(is that already there?) it has the advantage of > >following the drive if it were renamed.. > > I do like this idea for drives though, especially for > removable-storage devices (which might include firewire > hard drives, for instance)... Copying disks ends up still being a problem. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 16:30:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id DC3B237B400; Mon, 11 Mar 2002 16:30:48 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2C0UerT102974; Mon, 11 Mar 2002 19:30:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 11 Mar 2002 19:30:40 -0500 To: Robert Watson , Harti Brandt From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:16 PM -0500 3/11/02, Robert Watson wrote: >AFS, Coda, and various other "global scale" filesystems rely on >a much larger unique identifier space than the traditional 64-bit >(dev_t, ino_t) pair. Coda, for example, uses a 96-bit "Vice ID" >which is per-realm. [...] >The complicating factor comes when you try and map the 96-bit >(plus realm) into the 32-bit inode number. [...] >The "uniqueness" aspect for these numbers is a serious scaling >problem: global filesystems can and will name trillions of file >system objects. Squeezing them into a single 32-bit number, or >even a pair, simply doesn't work. Moving to a 64-bit inode >number in FreeBSD would reduce the chances of a collision >dramatically, and probably enough that the risk would become >acceptable. > >A preferred solution approximates the POSIX conventions but >allows for a special call into the filesystem to check collision >cases. [...] If we went with a 64-bit dev_t and 64-bit ino_t for userspace, would that be enough to hold a unquestionably-unique id for every file that currently exists in something like Coda or AFS? Say, 64-bits for inode, 32-bits for volume-identifier, 16-bits for realm (or AFS cell), and 16-bits left over for some sort of future expansion? If UFS2 requires a 64-bit (u)ino_t, then we're going to have to make some kind of change to the struct returned by stat(). We have also talked about wanting 64-bit fields for time values in that same struct. The more I think about it, the more I think we should just move towards a 64-bit field for (u)dev_t at the same time. Maybe we should wrap these all up into one major change, so we can have a st_dev+st_ino which can handle all existing filesystems (with some room for expansion). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 16:40:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id D85F137B420 for ; Mon, 11 Mar 2002 16:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020312004007.QCNC2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 12 Mar 2002 00:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA65989; Mon, 11 Mar 2002 16:23:48 -0800 (PST) Date: Mon, 11 Mar 2002 16:23:47 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Garance A Drosihn , Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <3C8D4850.B12087C2@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG that could be detected and fixed.. the last time I copied a disk exectly I was puting it on a differnet machine.. it only has to be unique for that machine. the network considers the machine as part of the device ID. If you have it on the same machine you probably are replacing a suspect drive in which case you are doing the right thing, if you want both drives on at once, just add 1 to one of them. (and write it back). On Mon, 11 Mar 2002, Terry Lambert wrote: > Garance A Drosihn wrote: > > At 11:50 AM -0800 3/11/02, Julian Elischer wrote: > > >I suggest that we create such a number and store it in > > >the filesystem superblock for filesystems in questions. > > >maybe the time of creation in secs since the epoch. > > >(is that already there?) it has the advantage of > > >following the drive if it were renamed.. > > > > I do like this idea for drives though, especially for > > removable-storage devices (which might include firewire > > hard drives, for instance)... > > Copying disks ends up still being a problem. 8-(. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 18:58:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 9333337B404; Mon, 11 Mar 2002 18:58:40 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2C2wcrT037172; Mon, 11 Mar 2002 21:58:38 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <65691.1015791493@critter.freebsd.dk> References: <65691.1015791493@critter.freebsd.dk> Date: Mon, 11 Mar 2002 21:58:37 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Terry Lambert , Harti Brandt , Robert Watson , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:18 PM +0100 3/10/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > > >I also think it is a major enough change that we > >need to spend some time to "ease into" it, which is why > >I'm trying to drum up some support for the idea now. > >There isn't much change for these actually, since they do >require two new syscalls and since very few programs even >think about them. > >This is nowhere as troublesome as off_t was. Hmm. How did freebsd handle that transition? is that where the ostat and nstat structs came from in stat.h? > >As to strategy, I guess we could start by adding two new > >fields to 'struct stat', which would be the 64-bit ones. We > >could truncate the 32-bit value and put that in the current > >fields. Some #define would govern whether a program sees > >st_dev and st_ino as the 32-bit values or the 64-bit values. > >No, we can't change the size of struct stat (binary >compatibility!) Now that I look at our present definition of struct-stat, I see that we do have two spare 64-bit fields. If we were only going to do the 64-bit ino_t, then we can do that without breaking binary compatibility. (as long as we fill in both a 32-bit and a 64-bit value). The struct does not have enough spare room to also go for a 64-bit dev_t, because there are two dev_t values in the struct and we only have one more 64-bit spare area to play with. So, as far as userland stat() goes, a 64-bit inode is pretty easy, but I would like to see us set the stage for the other things we keep talking about. All of those require a bigger struct-stat, and I can't think of any pretty way of doing that and also maintaining binary compatibility. Let us pretend that we "absolutely had to" increase the struct, *and* we could not break binary compatibility, *and* we would maintain posix compatibility for anything which was simply recompiled. If we had to do all three of those, how could we do it? Suggestion: 1) create a set of new routines. Call them stat64(), lstat64(), and fstat64(). 2) the new routines are exactly the same as the present routines, except that they expect a parameter of type 'struct stat64'. 3) (perhaps) provide duplicates of the present stat-routines, which are called stat32(), lstat64(), and fstat64(). 4) Initially create 'struct stat64' with all the same fields at all the same sizes, but with room to expand those fields to what we want to expand them to. Eg, change: __dev_t st_dev; /* inode's device */ ino_t st_ino; /* inode's number */ __dev_t st_rdev; /* device type */ time_t st_atime; /* time of last access */ long st_atimensec; /* nsec of last access */ to: uint_32 st_dev2; /* reserved */ __dev_t st_dev; /* inode's device */ uint_32 st_ino2; /* reserved */ ino_t st_ino; /* inode's number */ uint_32 st_rdev2; /* reserved */ __dev_t st_rdev; /* device type */ uint_32 st_atime2; /* reserved */ time_t st_atime; /* time of last access */ long st_atimensec; /* nsec of last access */ 5) via the magic of #define's, or maybe some loader tricks, have it so anything which is re-compiled will call these new routines instead of the present stat routines. They will obtain a larger stat area, but they won't need to make any other changes because none of the variables have a new type. (or if they *had* to have the smaller struct, they could call the stat32 routines) 6) over time, update the system to fill in the 64-bit versions of all those values. "old" programs will continue to use only the lower-order 32-bits of the newer 64-bit versions, but that should be good enough for most programs. If you think about the above for awhile, and you think about the new 64-bit architectures we are bringing up, then perhaps we could avoid some of these steps for the new ports. Just start out with a struct-stat which includes those extra fields for expansion. It is because of these new ports coming online that I want to think about this right now, and see what we could do before 5.0-release. If we can do some of this work now, we won't have binary-compatibility issues with FreeBSD/sparc64, FreeBSD/ppc, or FreeBSD/ia64. If we wait until after 5.0-release, then we do have that issue. Is the above too ugly to consider doing? I don't think it would be too much work to do (at least to get up to step 4). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 19:20:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 327BC37B402 for ; Mon, 11 Mar 2002 19:20:46 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2C3KZi53626; Mon, 11 Mar 2002 22:20:35 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Mar 2002 22:20:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn Cc: Poul-Henning Kamp , Terry Lambert , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Garance A Drosihn wrote: > So, as far as userland stat() goes, a 64-bit inode is pretty easy, but I > would like to see us set the stage for the other things we keep talking > about. All of those require a bigger struct-stat, and I can't think of > any pretty way of doing that and also maintaining binary compatibility. > Let us pretend that we "absolutely had to" increase the struct, *and* we > could not break binary compatibility, *and* we would maintain posix > compatibility for anything which was simply recompiled. If we had to do > all three of those, how could we do it? My personal feeling on this is that 5.0 is a good time to "take the leap". We know we need to roll the on-disk data structures to support UFS2, we're changing a number of other APIs (shortly including many of the SysV IPC APIs to properly support 32-bit uids and gids). We're completely replacing the threading mechanism, changing many of the APIs for library cals, we've added support for extended attributes, ACLs, etc. Now is the time. The longer the wait, the harder it gets. :-) As to the migration path: your suggestion sounds fine. I'd be tempted to simplify the approach: (1) Provide compatibility system calls in the style of ofoo() providing the 32-bit versions, and make sure that the compatibility libc (and so on) use those. (2) Modify inode.h to look like what we want it to end up looking like, and define new system calls using the native names (stat(), et al). Avoid providing source structure compatibility where it only serves to cause code to use the wrong types without warnings. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 22: 5:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8D26337B416; Mon, 11 Mar 2002 22:05:14 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2C64onp047306; Tue, 12 Mar 2002 07:04:52 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Carl Makin Cc: arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: GEOM code ready for testing In-Reply-To: Your message of "12 Mar 2002 10:58:47 +1200." <1015887527.74983.41.camel@newton.aipo.gov.au> Date: Tue, 12 Mar 2002 07:04:50 +0100 Message-ID: <47305.1015913090@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <1015887527.74983.41.camel@newton.aipo.gov.au>, Carl Makin writes: >Hi, > >On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: > >> The GEOM code is now ready for early testing: > >Would GEOM support accessing a device via multiple paths? (ie could we >write a method that would do that?) Yes, that would be possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 23:16: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AA2AB37B405; Mon, 11 Mar 2002 23:16:06 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2C7Fenp060374; Tue, 12 Mar 2002 08:15:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Terry Lambert , Harti Brandt , Robert Watson , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Mon, 11 Mar 2002 21:58:37 EST." Date: Tue, 12 Mar 2002 08:15:40 +0100 Message-ID: <60373.1015917340@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >So, as far as userland stat() goes, a 64-bit inode is pretty >easy, but I would like to see us set the stage for the other >things we keep talking about. All of those require a bigger >struct-stat, and I can't think of any pretty way of doing >that and also maintaining binary compatibility. ... as I keep telling you :-) A new size for struct stat is part of the UFS2 effort, in fact I'm on the ball to do that bit. The new struct stat will be big enough that we can expand all relevant fields. UFS2 is aimed at 5.0 if at all possible. So please relax, things are happening. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 11 23:20:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 3401B37B402; Mon, 11 Mar 2002 23:20:33 -0800 (PST) Received: from pool0134.cvx40-bradley.dialup.earthlink.net ([216.244.42.134] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16kgaD-0002FR-00; Mon, 11 Mar 2002 23:20:29 -0800 Message-ID: <3C8DAC19.B1ED58B@mindspring.com> Date: Mon, 11 Mar 2002 23:19:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Robert Watson , Harti Brandt , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > If UFS2 requires a 64-bit (u)ino_t, then we're going to have to > make some kind of change to the struct returned by stat(). We > have also talked about wanting 64-bit fields for time values in > that same struct. The more I think about it, the more I think > we should just move towards a 64-bit field for (u)dev_t at the > same time. Maybe we should wrap these all up into one major > change, so we can have a st_dev+st_ino which can handle all > existing filesystems (with some room for expansion). It's more complicated than just struct stat, I think. The "struct dirent" that's returned by getdirentries(2) contains a 32 bit file ID on the FS (d_fileno). This is actually equal to the value of st_ino from the stat, and the man page makes it clear that this is the case, at least as far as the st_ino semantics that Garrett Wollman quoted out of the POSIX spec. (more recent than my 1988 copy). The man page says: The d_fileno entry is a number which is unique for each distinct file in the filesystem. Files that are linked by hard links (see link(2)) have the same d_fileno. The struct dirent is actually a system version of the directory information, intended to be FS independent. It's externalized from the on disk directory structure. It's "coincidental" that it matches the FFS on disk structure. One of the issues here is that it *does not* match the externalized value that's sent over NFS; among other things, this is the reason for the "cookie" argument to the VOP_READDIR per VFS interface. A side issue (not worth discussing at this point, but worth keeping in mind) is that there is also a fundamental assumption in this interface that all directory entries within a directory are on the same volume. THis actually is not true for the entries which are directories which have been used as mount points, and may also not be true for a translucent FS with e.g. a CDROM and a seperate FFS image unioned to make the CDROM image writeable. It may also not be true on a per file basis, if the moral equivalent of symlinks are implemented in the lookup space, rather than in the FS namespace (e.g. folding of the namespace for various purposes). So it's probably a good idea to rethink this interface in any case, to externalize the per-file st_dev information, as well (if the interface is going to be changing anyway, it might as well be more correctly "a collection of stat information"). And that's one example of an exposure other than the "stat" interface. THe POSIX file locking semantics are another, though the translation (if any) would be internalized in a layer in the kernel. So you're not just talking a change to the "stat" structure, you are talking, minimally, either a conversion function, or a change to the system representation (to maintain the historical "coincidental" match between the on disk structure for UFS2 and the system structure). This has translational implications, both for the NFS mapping space and for the ABI modules (e.g. the Linux ABI). I'll suggest (again) that what wants to happen here is that the VOP_READDIR needs to be broken into two operations: one to get a block reference, atomically, and another, to take a block reference in native format, and convert entries on a case-by-case basis to an externalized format. I don't know the UFS2 intent on namespace, but it's likely that if it's well thought out, it will be two byte Unicode, so that fixed field length guarantees are maintained (UTF-7 or UTF-8 encoded data with escapes for the path component seperator "/" and the ASCII NUL character are unacceptable, both from the need to escape the character when it occurs in a valid multibyte character, and from the inability to make path component length guarantees, per POSIX). So to sum up: 1) It's not just struct stat 2) There are real client FS's in common use that will be impacted by such a change 3) There are FS consumers that aren't FS's that will also be impacted by such a change, including the ABI code I expect that we will see changes in these areas anyway, but it's a good idea to keep in mind that these changes are not as trivial as they might appear on casual inspection. It would be nice if the brekage were a single event that were not often repeated (everything at once), and if there were some backward compatability strategy well thought out before it became a dire need. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 1: 8:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hal-1.inet.it (hal-1.inet.it [213.92.5.20]) by hub.freebsd.org (Postfix) with ESMTP id 38EA137B417 for ; Tue, 12 Mar 2002 01:08:13 -0800 (PST) Received: (from root@localhost) by hal-1.inet.it (8.11.1/8.11.1) id g2C98B6431980 for ; Tue, 12 Mar 2002 10:08:11 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-1.inet.it via I-SMTP-4.0.5-100 id s-213.92.1.165-UCXrfs; Tue Mar 12 10:08:11 2002 Received: by acampi.inet.it (Postfix, from userid 1000) id C7CF615537; Tue, 12 Mar 2002 10:08:10 +0100 (CET) Date: Tue, 12 Mar 2002 10:08:10 +0100 From: Andrea Campi To: Poul-Henning Kamp Cc: Garance A Drosihn , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020312090810.GA8071@webcom.it> References: <20020311184730.GA6282@webcom.it> <21265.1015872658@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21265.1015872658@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 11, 2002 at 07:50:58PM +0100, Poul-Henning Kamp wrote: > > Well, I won't promise to pick it up, but if it were working > and there were a test-case or two, the chances of it breaking > again would decrease. It's currently not working I think; I cleaned it up a couple of months ago but I think some recent changes in API might have broken it again. It's a matter of solving the last breakages, having it committed into the arla -current repo, and then hopefully committing it to our own -current. I have the kernel infrastructure ready for building it both in the kernel and as a module. I even posted on -arch I think and the idea met a lukewarm favor. Note that I think the code still needs to be reviewed for the needed locks, but I was also suggested to get into the repo first (as long as it's working) and worry about that later. The only thing that stopped me at the time was that I definitely want to have it committed to the arla repo first and then import on a vendor branch, and keep it there by working with them for any and every future patch. I am sure that if a guy of your ability and experience would look at it, you could have it working in maybe half an hour. Setting up a client is very easy, and having Garance on board to help us test it would be a definite plus. Bye, Andrea > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 1:17:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by hub.freebsd.org (Postfix) with ESMTP id 42C3237B41B for ; Tue, 12 Mar 2002 01:17:14 -0800 (PST) Received: (from root@localhost) by hal-5.inet.it (8.11.1/8.11.1) id g2C9HDU26086 for ; Tue, 12 Mar 2002 10:17:13 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-5.inet.it via I-SMTP-4.0.5-100 id s-213.92.1.165-WlMyyk; Tue Mar 12 10:17:13 2002 Received: by acampi.inet.it (Postfix, from userid 1000) id BB47A15537; Tue, 12 Mar 2002 10:17:12 +0100 (CET) Date: Tue, 12 Mar 2002 10:17:12 +0100 From: Andrea Campi To: Garance A Drosihn Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020312091712.GB8071@webcom.it> References: <4252.1015867433@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > >But you could do me a favour: Write up a piece of text > >which gives enough info for somebody like me to setup > >and test AFS/ARLA in my lab... > > Hmm. This is a very reasonable request, but I am not > sure I have a good answer... > > Does your lab have reasonably-fast connectivity to the > internet at large? If so, then I could see about writing > something for setting up a machine as an AFS client and > having it pretend it is part of some already-existing AFS > cell. I do not actually use OpenAFS or ARLA on my freebsd > systems, but I certainly do want to figure that out. Sadly, now that there is interest my company has stopped its AFS pilot test so I don't have much time, and I no longer have an AFS server running. However, I could help you prepare this documentation. Either that or, if you (Poul) and I could "meet" online (IRC, ICQ, whatever) it would be probably easier to walk you through it. It's 20 minutes at most (with a working client and server). > If you do not have a fast network connection, then you > would need to set up your own AFS server. I do not know > how to do that, and I am pretty sure it is not something > that someone could do in an afternoon. The AFS cell at > RPI has 600-gigabytes of disk space in it, so I haven't > had much of an urge to start my own server! On the other > hand, I would really really like to get at that 600-gig > from FreeBSD clients. The server is still a problem, yes. Garance, don't you know of any anonymously accessible systems? I'm sure there are a few but don't think I wrote them down anywhere. :( That would save us quite a bit of time; it's something an experienced admin could set up in an afternoon with appropriate hardware at hand, but it would take you a couple of days starting from scratch, just to figure out all the messy documentation. Again, if you decided to just do that I could help. > There is a web site for openafs, at www.openafs.org. That > has downloadable client installations forMacOS 10, some > versions of Windows, Linux, Solaris, IRIX, AIX, and > Tru64 Unix. That web site does not have a client for the > Net,Open, or FreeBSD's. Most of the BSD's probably go with > the ARLA port for their AFS client. I never got OpenAFS working on -current but I heard someone is working on that. Note also that the kernel module is designed to be sort-of compatible between different implementation, so that you could use it witk either the OpenAFS or arla client. > Unfortunately, I noticed that someone else just mentioned > that the ARLA port is broken on current -- and here I just > switched to running current. Sigh... Yes, that's me. I think we should take this offline until we have something interesting to add ;-) > > -- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > Bye, Andrea > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 7:37: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 253C437B70F; Tue, 12 Mar 2002 07:33:14 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2CFCspu125180; Tue, 12 Mar 2002 10:12:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <60373.1015917340@critter.freebsd.dk> References: <60373.1015917340@critter.freebsd.dk> Date: Tue, 12 Mar 2002 10:12:53 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Terry Lambert , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:15 AM +0100 3/12/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > >>So, as far as userland stat() goes, a 64-bit inode is pretty >>easy, but I would like to see us set the stage for the other >>things we keep talking about. All of those require a bigger >>struct-stat, and I can't think of any pretty way of doing >>that and also maintaining binary compatibility. > >... as I keep telling you :-) Yeah, well, I kept hoping I could think up some super-clever magic, but it just wasn't happening... >A new size for struct stat is part of the UFS2 effort, in fact >I'm on the ball to do that bit. The new struct stat will be >big enough that we can expand all relevant fields. > >UFS2 is aimed at 5.0 if at all possible. > >So please relax, things are happening. Sounds good! Now for suggestion part #2: Once we get to a 64-bit (u)dev_t, we could reserve one byte of that for the "type of filesystem" (loosely speaking). A value of 0 for local hard disks 1 for NFSv2-mounted 2 for NFSv3-mounted (maybe this isn't necessary...) 3 for OpenAFS or ARLA mounted 4 for CODA-mounted 5 for something appletalk-ish, if we ever did that 6 for something netware-ish, if we ever did that This way, any one system could choose whatever method it wants to build the rest of the dev_t entry, and it knows it can not conflict with the dev_t values that would be generated by any other major filesystem type. I expect we could collapse the first three into a single value. It's mainly when we get to global filesystems that I think we want to be sure that we can use the "global ID" for a volume without worrying about conflicts with dev_t's generated by anything on the local machine. The local machine will have no control over those global ID's, and yet it would be nice to be able to directly use them. Yeah, this is probably another case of me stating the obvious, but still I wanted to mention it. This way Julian can pick whatever dev_t-generating method which works best for local hard disks, and not care what values might appear for OpenAFS or CODA. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 8:27:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A302737BFF2 for ; Tue, 12 Mar 2002 08:27:01 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2CGQdi07902; Tue, 12 Mar 2002 11:26:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 12 Mar 2002 11:26:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andrea Campi Cc: Poul-Henning Kamp , Garance A Drosihn , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <20020312090810.GA8071@webcom.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 12 Mar 2002, Andrea Campi wrote: > On Mon, Mar 11, 2002 at 07:50:58PM +0100, Poul-Henning Kamp wrote: > > > > Well, I won't promise to pick it up, but if it were working > > and there were a test-case or two, the chances of it breaking > > again would decrease. > > It's currently not working I think; I cleaned it up a couple of months > ago but I think some recent changes in API might have broken it again. > It's a matter of solving the last breakages, having it committed into > the arla -current repo, and then hopefully committing it to our own > -current. I have the kernel infrastructure ready for building it both in > the kernel and as a module. I even posted on -arch I think and the idea > met a lukewarm favor. Note that I think the code still needs to be > reviewed for the needed locks, but I was also suggested to get into the > repo first (as long as it's working) and worry about that later. The > only thing that stopped me at the time was that I definitely want to > have it committed to the arla repo first and then import on a vendor > branch, and keep it there by working with them for any and every future > patch. > > I am sure that if a guy of your ability and experience would look at it, > you could have it working in maybe half an hour. > > Setting up a client is very easy, and having Garance on board to help us > test it would be a definite plus. I'm very interested in seeing arlaxfs move into the source tree, especially if Arla people are willing to help with the inevitable cache coherency problem of it being there. Do you have in mind that this would be "contrib" code, or local code? Presumably local if we want to adapt it more to our locking model. The sooner we get it in the tree, the less work to do it later after more API sweeps go through. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 8:33:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1B95E37BC14 for ; Tue, 12 Mar 2002 08:32:34 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2CGUXi08143; Tue, 12 Mar 2002 11:30:33 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 12 Mar 2002 11:30:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andrea Campi Cc: Garance A Drosihn , Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <20020312091712.GB8071@webcom.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 12 Mar 2002, Andrea Campi wrote: > The server is still a problem, yes. Garance, don't you know of any > anonymously accessible systems? I'm sure there are a few but don't think > I wrote them down anywhere. :( That would save us quite a bit of time; > it's something an experienced admin could set up in an afternoon with > appropriate hardware at hand, but it would take you a couple of days > starting from scratch, just to figure out all the messy documentation. > Again, if you decided to just do that I could help. My impression was that many .edu cells are anonymously accessible to at least some extent, or some of the boot-strapping tricks wouldn't work. I could be wrong, however. > > There is a web site for openafs, at www.openafs.org. That > > has downloadable client installations forMacOS 10, some > > versions of Windows, Linux, Solaris, IRIX, AIX, and > > Tru64 Unix. That web site does not have a client for the > > Net,Open, or FreeBSD's. Most of the BSD's probably go with > > the ARLA port for their AFS client. > > I never got OpenAFS working on -current but I heard someone is working > on that. Note also that the kernel module is designed to be sort-of > compatible between different implementation, so that you could use it > witk either the OpenAFS or arla client. I've recently been exchanging e-mail with developers at CMU regarding the OpenAFS code, so there's certainly activity in that space. Also, OpenAFS was ported to Darwin and OS X. Although AFS isn't a big part of the FreeBSD community, there seems to be a lot of interest in FreeBSD on the AFS side of the world. > > Unfortunately, I noticed that someone else just mentioned > > that the ARLA port is broken on current -- and here I just > > switched to running current. Sigh... > > Yes, that's me. I think we should take this offline until we have > something interesting to add ;-) Unfortunately, I largely live in a network environment where I can't hook up AFS easily due to a proxy-model firewall, or I'd be interested in helping out. If the OpenAFS people make the server run happily and easily on FreeBSD, I can provide some help with the Arla client given enough time to set up a simply server. However, what we really need are maintainers who use AFS daily to make this work -- it's a complex system that will require extensive testing and careful tracking. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 8:43:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hal-1.inet.it (hal-1.inet.it [213.92.5.20]) by hub.freebsd.org (Postfix) with ESMTP id 641D837C0F6 for ; Tue, 12 Mar 2002 08:41:09 -0800 (PST) Received: (from root@localhost) by hal-1.inet.it (8.11.1/8.11.1) id g2CGf8684248 for ; Tue, 12 Mar 2002 17:41:08 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-1.inet.it via I-SMTP-4.0.5-100 id s-213.92.1.165-cHvL46; Tue Mar 12 17:41:08 2002 Received: from webcom.it (brian.inet.it [213.92.1.190]) by acampi.inet.it (Postfix) with SMTP id B949715537 for ; Tue, 12 Mar 2002 17:41:06 +0100 (CET) Received: (qmail 30543 invoked by uid 1000); 12 Mar 2002 15:21:27 -0000 Date: Tue, 12 Mar 2002 16:21:26 +0100 From: Andrea Campi To: Robert Watson Cc: Poul-Henning Kamp , Garance A Drosihn , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020312152126.GA309@webcom.it> References: <20020312090810.GA8071@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 12, 2002 at 11:26:38AM -0500, Robert Watson wrote: > > I'm very interested in seeing arlaxfs move into the source tree, > especially if Arla people are willing to help with the inevitable cache > coherency problem of it being there. Do you have in mind that this would > be "contrib" code, or local code? Presumably local if we want to adapt it > more to our locking model. The sooner we get it in the tree, the less > work to do it later after more API sweeps go through. The arla people seem to be interested in integrating any change we might send them. That said, I thought it would be contrib code, so that we could keep it in sync with *BSD and OS X. There is enough modularity in the code that it can accomodate our locking changes in the future without interfering with other *BSD code. That said, it's also true that having it as contrib code means we must strive to filter changes through them to avoid taking the code off the vendor branch, so this might be very inconvenient at times. Basically, I think it's the committer's choice... As I said, I did the bulk of the job but right now lack the time to properly maintain the patches. The reason I wanted to get them committed is to be sure they are not left out of future changes for locking, kse, whatever. I'm going to send them via private mail to whomever showed interest, and I'll be available to explain what I did and any missing detail. At this point, if you or Poul want to commit them as they are as local code and later sync back with arla, that would be fine for me. Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 8:49:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hal-1.inet.it (hal-1.inet.it [213.92.5.20]) by hub.freebsd.org (Postfix) with ESMTP id AC44537BC67 for ; Tue, 12 Mar 2002 08:47:41 -0800 (PST) Received: (from root@localhost) by hal-1.inet.it (8.11.1/8.11.1) id g2CGleb120950 for ; Tue, 12 Mar 2002 17:47:40 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-1.inet.it via I-SMTP-4.0.5-100 id s-213.92.1.165-h5lG7h; Tue Mar 12 17:47:40 2002 Received: from webcom.it (brian.inet.it [213.92.1.190]) by acampi.inet.it (Postfix) with SMTP id E6D6F1554D for ; Tue, 12 Mar 2002 17:47:39 +0100 (CET) Received: (qmail 37126 invoked by uid 1000); 12 Mar 2002 15:28:00 -0000 Date: Tue, 12 Mar 2002 16:28:00 +0100 From: Andrea Campi To: Robert Watson Cc: Garance A Drosihn , Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020312152800.GB309@webcom.it> References: <20020312091712.GB8071@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > My impression was that many .edu cells are anonymously accessible to at > least some extent, or some of the boot-strapping tricks wouldn't work. I > could be wrong, however. No bootstrap issues, or at least I had none: you don't even need to have connectivity to set up arla, the distro is self contained. > I've recently been exchanging e-mail with developers at CMU regarding the > OpenAFS code, so there's certainly activity in that space. Also, OpenAFS > was ported to Darwin and OS X. Although AFS isn't a big part of the > FreeBSD community, there seems to be a lot of interest in FreeBSD on the > AFS side of the world. arla is available for OS X, including a "preferences" panel. I wasn't able to check it out yet, as my Mac is at home waiting for my ADSL... > Unfortunately, I largely live in a network environment where I can't hook > up AFS easily due to a proxy-model firewall, or I'd be interested in > helping out. If the OpenAFS people make the server run happily and easily > on FreeBSD, I can provide some help with the Arla client given enough time > to set up a simply server. However, what we really need are maintainers > who use AFS daily to make this work -- it's a complex system that will > require extensive testing and careful tracking. As I said, you could test it even on a disconnected net. However, you can't currently run a server on FreeBSD. I would volunteer to be the maintainer, but AFS was just a pilot project here and we no longer have a server. If the server becomes available for OS X, I'll be able to run my own server at home, but until that time, it can't be me. I agree that we need somebody who uses it daily to work as maintainer, or at least tester. But we should probably commit the code nonetheless, or it will be a chicken-and-egg problem forever. Bye, Andrea -- Press every key to continue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 8:59:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id A778F37B449; Tue, 12 Mar 2002 08:59:20 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2CGxIpu168000; Tue, 12 Mar 2002 11:59:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Tue, 12 Mar 2002 11:59:17 -0500 To: Robert Watson , Andrea Campi From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , Harti Brandt , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:30 AM -0500 3/12/02, Robert Watson wrote: >On Tue, 12 Mar 2002, Andrea Campi wrote: > > > The server is still a problem, yes. Garance, don't you know of > > any anonymously accessible systems? I'm sure there are a few > > but don't think I wrote them down anywhere. > >My impression was that many .edu cells are anonymously accessible >to at least some extent, or some of the boot-strapping tricks >wouldn't work. I could be wrong, however. You can claim to be part of an AFS cell without having any passwords for that cell, but I don't know if there are any ip-based checks on the server side. You will only have access to directories which are permitted read to system:anyuser, but I imagine every AFS site has at least a few of those directories. For that matter, once we got some kind of OpenAFS server going on FreeBSD, we could add freebsd.org as an AFS cell. > > I never got OpenAFS working on -current but I heard someone is > > working on that. Note also that the kernel module is designed > > to be sort-of compatible between different implementation, so > > that you could use it witk either the OpenAFS or arla client. > >I've recently been exchanging e-mail with developers at CMU >regarding the OpenAFS code, so there's certainly activity in >that space. Also, OpenAFS was ported to Darwin and OS X. >Although AFS isn't a big part of the FreeBSD community, there >seems to be a lot of interest in FreeBSD on the AFS side of >the world. I must admit that I am really more interested in an "official" OpenAFS client than in ARLA, but just for political reasons. RPI has been running an AFS cell for at least ten years now, and everyone has already bought into the "wonderfulness" of OpenAFS. If I had OpenAFS for FreeBSD, then I have a chance of using FreeBSD instead of Linux for some of our servers (not our AFS servers, but for things like print and samba servers). If I try to do that with ARLA, then I have to convince them in *both* FreeBSD and ARLA, and I do not think I can do that. I was going to try ARLA because I thought it was already working, but if it is not then maybe I should concentrate on OpenAFS. >... However, what we really need are maintainers who use >AFS daily to make this work -- it's a complex system that >will require extensive testing and careful tracking. Well, after our last computer-center reorg, I am technically supposed to be the "backup person" for AFS. I also got to be the main person for samba, and I got to drop ... well, nothing. So, I haven't really had any time to learn much wrt AFS. I can certainly do client-side testing, but the server-side would probably be over my head. I'm also trying to convince some of my buddies over in RPI's CS dept to do some work on OpenAFS for FreeBSD. Everyone likes the idea, but so far no one has had the time to start working on it. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 12:41:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 131A137B400; Tue, 12 Mar 2002 12:41:17 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 724025346; Tue, 12 Mar 2002 21:41:14 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Cc: peter@freebsd.org, jake@freebsd.org Subject: dumpsys() rewrite From: Dag-Erling Smorgrav Date: 12 Mar 2002 21:41:14 +0100 Message-ID: Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As noted on -committers, dumpsys() & co. need a serious revamp, to support kernel dumps on sparc64 and reduce code duplication. The required changes fall into two categories: 1) centralization of the dumping logic to avoid duplicating it in each disk driver. 2) a new on-disk format for kernel dumps, from which savecore(1) can extract all the necessary information to construct a correct core file. Drawing on input from Peter, I suggest the following: a) drivers will implement three functions instead of one: - dump_init: readies the device for dumping the specified number of pages at the specified offset (dumplo). - dump_write: writes the specified number of pages from the specified address to the device - dump_done: cleans up once everything has been written. b) dumpsys() will call the appropriate dump_init function, then loop over physical memory, doing the appropriate pmap_kenter_temporary() magic and calling the appropriate dump_write function, then finish off by calling the appropriate dump_done function. c) the on-disk format will be as follows: - first, a chunk of metadata beginning with "DUMPINFO\n" and listing a number of parameters as key-value pairs, like this: DUMPINFO dumpinfo_size=0x1000 page_size=0x1000 dev_bsize=0x200 dumplo=0x6c0020 kernbase=0xc0000000 - this is immediately followed by a section listing the chunks of physical memory that were dumped, as pairs of numbers indicating starting (physical) address and size in pages: MAPPINGS 0x0 0x27ffc - follwed by "END\n": END - the dumpinfo_size listed earlier is the size in bytes of the entire metadata block, from "DUMPINFO" to "END", rounded up to some unspecified multiple of page_size, which is assumed to be a multiple of dev_bsize. - the actual dump begins at offset ((dumplo * dev_bsize) + dumpinfo_size). - savecore(1) will first read the metadata and construct an internal list of chunks that need reading. For every chunk, it will then seek to the specified offset in the core file and copy the specified number of pages, using the same algorithm it already uses to skip sequences of zeroes. Comments? Suggestions? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 12:54:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 8D01337B429; Tue, 12 Mar 2002 12:53:54 -0800 (PST) Received: from pool0291.cvx40-bradley.dialup.earthlink.net ([216.244.43.36] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ktH8-0000sy-00; Tue, 12 Mar 2002 12:53:38 -0800 Message-ID: <3C8E6AC0.A51444E1@mindspring.com> Date: Tue, 12 Mar 2002 12:53:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Poul-Henning Kamp , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <60373.1015917340@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > Now for suggestion part #2: > > Once we get to a 64-bit (u)dev_t, we could reserve one byte of > that for the "type of filesystem" (loosely speaking). A value > of 0 for local hard disks > 1 for NFSv2-mounted > 2 for NFSv3-mounted (maybe this isn't necessary...) > 3 for OpenAFS or ARLA mounted > 4 for CODA-mounted > 5 for something appletalk-ish, if we ever did that > 6 for something netware-ish, if we ever did that > > This way, any one system could choose whatever method it wants > to build the rest of the dev_t entry, and it knows it can not > conflict with the dev_t values that would be generated by any > other major filesystem type. man statfs. The answer is that it's possible to get the FS mount type already. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 13: 1:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AB6F437B405; Tue, 12 Mar 2002 13:01:05 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2CL0fnp014702; Tue, 12 Mar 2002 22:00:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-Reply-To: Your message of "12 Mar 2002 21:41:14 +0100." Date: Tue, 12 Mar 2002 22:00:41 +0100 Message-ID: <14701.1015966841@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >As noted on -committers, dumpsys() & co. need a serious revamp, to >support kernel dumps on sparc64 and reduce code duplication. The >required changes fall into two categories: > >1) centralization of the dumping logic to avoid duplicating it in each > disk driver. > >2) a new on-disk format for kernel dumps, from which savecore(1) can > extract all the necessary information to construct a correct core > file. > >Drawing on input from Peter, I suggest the following: `) Device driver or proxy for it register their ability to do dumps with the kernel, informing the kernel about the number of bytes they have room for (and the sector size of the media ?). With or without GEOM we need to be certain to hit the right spot on the disk. This includes tracking of "the right spot" gets moved or deleted due to disklabel/MBR modifications. >a) drivers will implement three functions instead of one: > > - dump_init: readies the device for dumping the specified number > of pages at the specified offset (dumplo). > > - dump_write: writes the specified number of pages from the > specified address to the device > > - dump_done: cleans up once everything has been written. These functions could profitably be registered in step `) above rather than pollute struct devsw. >c) the on-disk format will be as follows: Make it XML while we're at it ? All it costs in the kernel is a bit more text in the printfs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 13: 7:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C268637B400; Tue, 12 Mar 2002 13:07:40 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id C6EBE5346; Tue, 12 Mar 2002 22:07:38 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite References: <14701.1015966841@critter.freebsd.dk> From: Dag-Erling Smorgrav Date: 12 Mar 2002 22:07:38 +0100 In-Reply-To: <14701.1015966841@critter.freebsd.dk> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > `) Device driver or proxy for it register their ability to do dumps > with the kernel, informing the kernel about the number of bytes > they have room for (and the sector size of the media ?). Umm, no - it's simpler to just have a driver-provided helper for disk_dumpcheck(), rather than a system for registering dump-capable devices. BTW, this reminds me that the device should "know" that it's the current dump device, so it can clear dumpdev if it disappears (e.g. you 'camcontrol stop' the disk and remove it from the enclosure...) > > c) the on-disk format will be as follows: > Make it XML while we're at it ? All it costs in the kernel is > a bit more text in the printfs. It's not hierarchical, and therefore won't benefit from being expressed in XML. It'll just add unnecessary complexity to savecore(1). DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 13:11:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A7EEE37B404; Tue, 12 Mar 2002 13:11:24 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2CLB2np016770; Tue, 12 Mar 2002 22:11:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-Reply-To: Your message of "12 Mar 2002 22:07:38 +0100." Date: Tue, 12 Mar 2002 22:11:02 +0100 Message-ID: <16769.1015967462@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Poul-Henning Kamp writes: >> `) Device driver or proxy for it register their ability to do dumps >> with the kernel, informing the kernel about the number of bytes >> they have room for (and the sector size of the media ?). > >Umm, no - it's simpler to just have a driver-provided helper for >disk_dumpcheck(), rather than a system for registering dump-capable >devices. > >BTW, this reminds me that the device should "know" that it's the >current dump device, so it can clear dumpdev if it disappears (e.g. >you 'camcontrol stop' the disk and remove it from the enclosure...) That is what I am talking about. You need to leave the driver (or a proxy for it: GEOM or the mini disk-layer) say "I can dump you this many bytes should you need it" or "I can no longer dump for you" As for registration, just add them to an EVENTHANDLER and you're done. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 13:56:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id B003337B488; Tue, 12 Mar 2002 13:56:23 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2CLuLpu095490; Tue, 12 Mar 2002 16:56:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C8E6AC0.A51444E1@mindspring.com> References: <60373.1015917340@critter.freebsd.dk> <3C8E6AC0.A51444E1@mindspring.com> Date: Tue, 12 Mar 2002 16:56:20 -0500 To: Terry Lambert From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:53 PM -0800 3/12/02, Terry Lambert wrote: >Garance A Drosihn wrote: >> Now for suggestion part #2: >> >> Once we get to a 64-bit (u)dev_t, we could reserve one byte of >> that for the "type of filesystem" (loosely speaking). A value > > of 0 for local hard disks > > 3 for OpenAFS or ARLA mounted > > 4 for CODA-mounted [...etc...] > >man statfs. > >The answer is that it's possible to get the FS mount type >already. This would not be to get the fs mount type, it would be to avoid duplicate values for st_dev. By using one byte to explicitly indicate the "pool of numbers" one is picking values for, each "pool" can pick whatever values it wants for the remaining bits. Thus we could use the creation-date of a hard-disk filesystem for dev_t in the case of hard disks (if we wanted to), and not have to worry that it might be the same as some id in AFS-land. This is an implementation detail of how to ensure a unique value for st_dev, when we're talking about billions of such values (in the case of AFS or Coda). This is not something we would document for use in any userland-level code. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14: 1:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1811C37B423; Tue, 12 Mar 2002 14:01:21 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2CM0nnp026045; Tue, 12 Mar 2002 23:00:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Terry Lambert , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Tue, 12 Mar 2002 16:56:20 EST." Date: Tue, 12 Mar 2002 23:00:49 +0100 Message-ID: <26044.1015970449@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >At 12:53 PM -0800 3/12/02, Terry Lambert wrote: >>Garance A Drosihn wrote: >>> Now for suggestion part #2: >>> >>> Once we get to a 64-bit (u)dev_t, we could reserve one byte of >>> that for the "type of filesystem" (loosely speaking). A value >> > of 0 for local hard disks >> > 3 for OpenAFS or ARLA mounted >> > 4 for CODA-mounted [...etc...] >> >>man statfs. >> >>The answer is that it's possible to get the FS mount type >>already. > >This would not be to get the fs mount type, it would be to avoid >duplicate values for st_dev. By using one byte to explicitly >indicate the "pool of numbers" one is picking values for, each >"pool" can pick whatever values it wants for the remaining bits. You know, I find it rather theoretical what to do with the udev_t if(&when) it gets expanded to 64 bits, in particular considering that we appearntly have no active maintenance of AFS in FreeBSD at all... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14: 8: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 773D737B400 for ; Tue, 12 Mar 2002 14:07:59 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2CM7di30537; Tue, 12 Mar 2002 17:07:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 12 Mar 2002 17:07:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Garance A Drosihn , Terry Lambert , Harti Brandt , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: <26044.1015970449@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: > You know, I find it rather theoretical what to do with the udev_t > if(&when) it gets expanded to 64 bits, in particular considering that we > appearntly have no active maintenance of AFS in FreeBSD at all... That's actually not quite the case. The KTH Arla project actively maintains Arla for FreeBSD, but they do so against the -STABLE branch. I ran Arla for several years, I just don't live in an AFS-centric environment anymore. This is quite similar for KTH's support for Kerberos. Also, there has been an active porting project to bring OpenAFS to FreeBSD. Chasing -CURRENT and our VFS is just difficult :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14:38:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id C25FC37B405; Tue, 12 Mar 2002 14:37:28 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2CMbQpu075784; Tue, 12 Mar 2002 17:37:27 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <26044.1015970449@critter.freebsd.dk> References: <26044.1015970449@critter.freebsd.dk> Date: Tue, 12 Mar 2002 17:37:26 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Terry Lambert , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:00 PM +0100 3/12/02, Poul-Henning Kamp wrote: >You know, I find it rather theoretical what to do with the >udev_t if(&when) it gets expanded to 64 bits, in particular >considering that we appearntly have no active maintenance >of AFS in FreeBSD at all... I am checking into what I can do about that part... :-) I am very interested in seeing something happen wrt AFS clients for freebsd, and I believe several others are interested in being able to use freebsd for AFS servers. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14:39:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 3E25637B43E; Tue, 12 Mar 2002 14:39:11 -0800 (PST) Received: from pool0291.cvx40-bradley.dialup.earthlink.net ([216.244.43.36] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kuuq-0005rO-00; Tue, 12 Mar 2002 14:38:44 -0800 Message-ID: <3C8E8362.B95B74C@mindspring.com> Date: Tue, 12 Mar 2002 14:38:26 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Poul-Henning Kamp , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <60373.1015917340@critter.freebsd.dk> <3C8E6AC0.A51444E1@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > This would not be to get the fs mount type, it would be to avoid > duplicate values for st_dev. By using one byte to explicitly > indicate the "pool of numbers" one is picking values for, each > "pool" can pick whatever values it wants for the remaining bits. ((N&X) | (N&(X^0xffffffff)) := N You aren't going to get more bits by splitting up the number this way, any more than splitting something into majors and minors will do it for you. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14:40:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9C1B237B41C; Tue, 12 Mar 2002 14:39:15 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2CMclnp033058; Tue, 12 Mar 2002 23:38:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Terry Lambert , Harti Brandt , Robert Watson , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Tue, 12 Mar 2002 17:37:26 EST." Date: Tue, 12 Mar 2002 23:38:47 +0100 Message-ID: <33057.1015972727@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >At 11:00 PM +0100 3/12/02, Poul-Henning Kamp wrote: >>You know, I find it rather theoretical what to do with the >>udev_t if(&when) it gets expanded to 64 bits, in particular >>considering that we appearntly have no active maintenance >>of AFS in FreeBSD at all... > >I am checking into what I can do about that part... :-) > >I am very interested in seeing something happen wrt AFS >clients for freebsd, and I believe several others are >interested in being able to use freebsd for AFS servers. That would be most cool... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 14:48:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id E5FCA37B404; Tue, 12 Mar 2002 14:48:04 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g2CMlAe79893; Tue, 12 Mar 2002 22:47:11 GMT (envelope-from nik) Date: Tue, 12 Mar 2002 22:47:07 +0000 From: Nik Clayton To: Dag-Erling Smorgrav Cc: arch@freebsd.org, peter@freebsd.org, jake@freebsd.org Subject: Re: dumpsys() rewrite Message-ID: <20020312224707.I56358@canyon.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="C7PTD44AewjTsiSV" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@ofug.org on Tue, Mar 12, 2002 at 09:41:14PM +0100 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --C7PTD44AewjTsiSV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 12, 2002 at 09:41:14PM +0100, Dag-Erling Smorgrav wrote: > c) the on-disk format will be as follows: >=20 > - first, a chunk of metadata beginning with "DUMPINFO\n" and > listing a number of parameters as key-value pairs, like this: >=20 > DUMPINFO > dumpinfo_size=3D0x1000 > page_size=3D0x1000 > dev_bsize=3D0x200 > dumplo=3D0x6c0020 > kernbase=3D0xc0000000 phk already suggested XML, so I'll content myself with: 1. Is it worth putting a version field in there somewhere. =20 2. Is that the order of the fields above, or can they appear in any order? 3. To avoid ambiguity, it might be worth having an explicit "end of metadata" marker before the dump data. N=20 --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --C7PTD44AewjTsiSV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyOhWoACgkQk6gHZCw343VXcgCfQZIxU3lxr4ZZtlVPSOm5yltr PXcAnik3QsSoPAQHFkC4S6K/CsJRjkRz =08kE -----END PGP SIGNATURE----- --C7PTD44AewjTsiSV-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 15: 3:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AA50237B43B; Tue, 12 Mar 2002 15:02:35 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 3FCD25347; Wed, 13 Mar 2002 00:02:34 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Nik Clayton Cc: arch@freebsd.org, peter@freebsd.org, jake@freebsd.org Subject: Re: dumpsys() rewrite References: <20020312224707.I56358@canyon.nothing-going-on.org> From: Dag-Erling Smorgrav Date: 13 Mar 2002 00:02:33 +0100 In-Reply-To: <20020312224707.I56358@canyon.nothing-going-on.org> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik Clayton writes: > 1. Is it worth putting a version field in there somewhere. Sure. This wasn't meant to be an exhaustive list. > 2. Is that the order of the fields above, or can they appear in any > order? Any order, and you can add any fields you want; savecore(1) will ignore those it doesn't understand. > 3. To avoid ambiguity, it might be worth having an explicit "end of > metadata" marker before the dump data. Yep, that's what "END\n" is for, or didn't you catch that? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 12 16:19: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D482937B41A; Tue, 12 Mar 2002 16:19:02 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2635C5347; Wed, 13 Mar 2002 01:19:01 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Nik Clayton Cc: arch@freebsd.org, peter@freebsd.org, jake@freebsd.org Subject: Re: dumpsys() rewrite References: <20020312224707.I56358@canyon.nothing-going-on.org> From: Dag-Erling Smorgrav Date: 13 Mar 2002 01:19:00 +0100 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Yep, that's what "END\n" is for, or didn't you catch that? To follow up on this, I'm not sure if my initial mail was clear - the beginning of the dump will actually look like this: DUMPINFO dumpinfo_size=0x1000 page_size=0x1000 dev_bsize=0x200 dumplo=0x6c0020 kernbase=0xc0000000 MAPPINGS 0x0 0x27ffc END then zeroes (or garbage) all the way to the actual dump, which begins at offset (dumplo * dev_bsize + dumpinfo_size). In other words, the chunk list is *part* of the DUMPINFO block. I might actually remove "MAPPINGS\n" altogether and just prefix every chunk line with @ or something. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 1:38:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 5B72E37B400; Wed, 13 Mar 2002 01:38:54 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 5985B43E; Wed, 13 Mar 2002 09:38:05 +0000 (GMT) Date: Wed, 13 Mar 2002 09:38:05 +0000 From: Josef Karthauser To: Dag-Erling Smorgrav Cc: arch@freebsd.org, peter@freebsd.org, jake@freebsd.org Subject: Re: dumpsys() rewrite Message-ID: <20020313093805.GA29679@genius.tao.org.uk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 12, 2002 at 09:41:14PM +0100, Dag-Erling Smorgrav wrote: >=20 > Drawing on input from Peter, I suggest the following: >=20 > a) drivers will implement three functions instead of one: >=20 > - dump_init: readies the device for dumping the specified number > of pages at the specified offset (dumplo). >=20 > - dump_write: writes the specified number of pages from the > specified address to the device It would be fantastic to be able to compress the memory image as it is dumped to disk. That would speed it up a bit in most cases. If each dump_write reads memory directly rather than going through a common function this is never going to be easy to do. Joe --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyPHfwACgkQXVIcjOaxUBaMGACgoo+Pdya4v8XwnrLqWNRS7uQD Z+EAn3SIAqEFeVjWmECGsxPC4kytKszB =DrdV -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 2:16:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 736E437B405; Wed, 13 Mar 2002 02:16:40 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 6C5F75346; Wed, 13 Mar 2002 11:16:37 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Josef Karthauser Cc: arch@freebsd.org, peter@freebsd.org, jake@freebsd.org Subject: Re: dumpsys() rewrite References: <20020313093805.GA29679@genius.tao.org.uk> From: Dag-Erling Smorgrav Date: 13 Mar 2002 11:16:37 +0100 In-Reply-To: <20020313093805.GA29679@genius.tao.org.uk> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Josef Karthauser writes: > It would be fantastic to be able to compress the memory image as it is > dumped to disk. That would speed it up a bit in most cases. If each > dump_write reads memory directly rather than going through a common > function this is never going to be easy to do. dumpsys() controls what is written and when. It is perfetly conceivable for dumpsys() to do the same kind of hole compression that savecore(1) does, but it would be *much* slower and it would have to record information about every hole to disk, which would make savecore(1) slower as well. Currently, most drivers write 64 kB at a time when dumping, and savecore(1) reads 1 MB at a time. To perform hole compression, dumpsys() would have to scan through memory word by word *and* potentially write in far smaller increments than 64 kB. Remember the bad old days when it wrote only a sector at a time? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 4:56:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DF1D537B400 for ; Wed, 13 Mar 2002 04:56:25 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DFC7A5346; Wed, 13 Mar 2002 13:56:23 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Unmoronify CVS From: Dag-Erling Smorgrav Date: 13 Mar 2002 13:56:22 +0100 Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= Any objections to the attached patch? DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=cvs.diff Index: contrib/cvs/src/cvs.h =================================================================== RCS file: /home/ncvs/src/contrib/cvs/src/cvs.h,v retrieving revision 1.14 diff -u -r1.14 cvs.h --- contrib/cvs/src/cvs.h 15 Sep 2001 05:57:52 -0000 1.14 +++ contrib/cvs/src/cvs.h 13 Mar 2002 12:50:24 -0000 @@ -894,9 +894,15 @@ char *normalize_cvsroot PROTO((const cvsroot_t *root)); #endif /* AUTH_CLIENT_SUPPORT */ +#ifndef NO_VAL_TAGS extern void tag_check_valid PROTO ((char *, int, char **, int, int, char *)); extern void tag_check_valid_join PROTO ((char *, int, char **, int, int, char *)); +#else +#define tag_check_valid(a, b, c, d, e, f) do { /* nothing */ } while (0) +#define tag_check_valid_join(a, b, c, d, e, f) do { /* nothing */ } while (0) +#endif /* !NO_VAL_TAGS */ + #include "server.h" Index: contrib/cvs/src/mkmodules.c =================================================================== RCS file: /home/ncvs/src/contrib/cvs/src/mkmodules.c,v retrieving revision 1.11 diff -u -r1.11 mkmodules.c --- contrib/cvs/src/mkmodules.c 10 Aug 2001 09:53:06 -0000 1.11 +++ contrib/cvs/src/mkmodules.c 13 Mar 2002 12:49:10 -0000 @@ -949,6 +949,7 @@ chmod (info, 0666); } +#ifndef NO_VAL_TAGS /* Make an empty val-tags file to prevent problems creating it later. */ strcpy (info, adm); strcat (info, "/"); @@ -966,6 +967,7 @@ because xchmod() is too shy. */ chmod (info, 0666); } +#endif /* !NO_VAL_TAGS */ free (info); free (info_v); Index: contrib/cvs/src/tag.c =================================================================== RCS file: /home/ncvs/src/contrib/cvs/src/tag.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 tag.c --- contrib/cvs/src/tag.c 10 Aug 2001 09:43:21 -0000 1.1.1.8 +++ contrib/cvs/src/tag.c 13 Mar 2002 12:49:06 -0000 @@ -1032,6 +1032,7 @@ return (R_PROCESS); } +#ifndef NO_VAL_TAGS /* Code relating to the val-tags file. Note that this file has no way of knowing when a tag has been deleted. The problem is that there is no way of knowing whether a tag still exists somewhere, when we @@ -1300,3 +1301,4 @@ free (c); } +#endif /* !NO_VAL_TAGS */ Index: gnu/usr.bin/cvs/cvs/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/cvs/cvs/Makefile,v retrieving revision 1.36 diff -u -r1.36 Makefile --- gnu/usr.bin/cvs/cvs/Makefile 10 Aug 2001 11:24:23 -0000 1.36 +++ gnu/usr.bin/cvs/cvs/Makefile 13 Mar 2002 12:45:57 -0000 @@ -25,6 +25,7 @@ CFLAGS+= -I${.CURDIR} -I${.CURDIR}/../lib -DHAVE_CONFIG_H \ -I${CVSDIR}/src -I${CVSDIR}/lib -I${CVSDIR}/diff +CFLAGS+= -DNO_VAL_TAGS DPADD+= ${LIBCVS} ${LIBDIFF} ${LIBGNUREGEX} ${LIBMD} ${LIBCRYPT} ${LIBZ} LDADD+= ${LIBCVS} ${LIBDIFF} -lgnuregex -lmd -lcrypt -lz --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 6: 3: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.dmnshq.net (phoenix.dmnshq.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id E7CE537B402 for ; Wed, 13 Mar 2002 06:03:06 -0800 (PST) Received: (from eivind@localhost) by phoenix.dmnshq.net (8.11.6/8.11.6) id g2DE2sr96053; Wed, 13 Mar 2002 15:02:54 +0100 (CET) (envelope-from eivind) Date: Wed, 13 Mar 2002 15:02:54 +0100 From: Eivind Eklund To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313150254.A95884@phoenix.dmnshq.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@ofug.org on Wed, Mar 13, 2002 at 01:56:22PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 01:56:22PM +0100, Dag-Erling Smorgrav wrote: > Any objections to the attached patch? I'd prefer the replacements to be inline null functions with prototypes rather than #defines in order to preserve the type checking, but this is not a strong objection - I'd rather have it in the tree as it is than not have it at all. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 7:42:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 0E8AF37B416; Wed, 13 Mar 2002 07:42:47 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2DFghWZ169340; Wed, 13 Mar 2002 10:42:43 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20020313093805.GA29679@genius.tao.org.uk> Date: Wed, 13 Mar 2002 10:42:41 -0500 To: Dag-Erling Smorgrav , Josef Karthauser From: Garance A Drosihn Subject: Re: dumpsys() rewrite Cc: arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:16 AM +0100 3/13/02, Dag-Erling Smorgrav wrote: >Josef Karthauser writes: > > It would be fantastic to be able to compress the memory image > > as it is dumped to disk. That would speed it up a bit in most > > cases. If each dump_write reads memory directly rather than > > going through a common function this is never going to be easy > > to do. > >dumpsys() controls what is written and when. It is perfectly >conceivable for dumpsys() to do the same kind of hole compression >that savecore(1) does, but it would be *much* slower and ... Would it make any sense to compress it in the 'gzip' sense of the word (or some simpler algorithm)? Or does it already do some of that? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 7:46:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 251DF37B417; Wed, 13 Mar 2002 07:46:19 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 33B425346; Wed, 13 Mar 2002 16:46:17 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Garance A Drosihn Cc: Josef Karthauser , arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite References: <20020313093805.GA29679@genius.tao.org.uk> From: Dag-Erling Smorgrav Date: 13 Mar 2002 16:46:16 +0100 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > Would it make any sense to compress it in the 'gzip' sense of > the word (or some simpler algorithm)? Not really. The compression rate is not sufficiently predictable, and dumping would be s...l...o...w... > Or does it already do > some of that? savecore(1) does. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 8:18:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by hub.freebsd.org (Postfix) with ESMTP id 7ED1737B405 for ; Wed, 13 Mar 2002 08:18:52 -0800 (PST) Received: from CndymnBrks@aol.com by imo-r06.mx.aol.com (mail_out_v32.5.) id n.8f.18a35045 (17529) for ; Wed, 13 Mar 2002 11:18:44 -0500 (EST) From: CndymnBrks@aol.com Message-ID: <8f.18a35045.29c0d5e3@aol.com> Date: Wed, 13 Mar 2002 11:18:43 EST Subject: Replacement parts for the 1992 xjs6 To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_8f.18a35045.29c0d5e3_boundary" X-Mailer: AOL 7.0 for Windows US sub 256 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --part1_8f.18a35045.29c0d5e3_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi we would like to join the club. However at this paricular time we need an abs low pressure switch(Dual Function Switch). Thank you and we are hopeful. Ray and Deborah J. Burks --part1_8f.18a35045.29c0d5e3_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi we would like to join the club. However at this paricular time we need an abs
low pressure switch(Dual Function Switch).
Thank you and we are hopeful.
Ray and Deborah J. Burks --part1_8f.18a35045.29c0d5e3_boundary-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 8:58:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AFC3337B404; Wed, 13 Mar 2002 08:58:15 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4A7B35346; Wed, 13 Mar 2002 17:58:14 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Eivind Eklund Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020313150254.A95884@phoenix.dmnshq.net> From: Dag-Erling Smorgrav Date: 13 Mar 2002 17:58:13 +0100 In-Reply-To: <20020313150254.A95884@phoenix.dmnshq.net> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Eivind Eklund writes: > On Wed, Mar 13, 2002 at 01:56:22PM +0100, Dag-Erling Smorgrav wrote: > > Any objections to the attached patch? > I'd prefer the replacements to be inline null functions with prototypes Good idea. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 10:27:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id F1E8A37B405 for ; Wed, 13 Mar 2002 10:27:44 -0800 (PST) Received: from pool0082.cvx21-bradley.dialup.earthlink.net ([209.179.192.82] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lDTS-0001TM-00; Wed, 13 Mar 2002 10:27:42 -0800 Message-ID: <3C8F9A0C.843AB8D0@mindspring.com> Date: Wed, 13 Mar 2002 10:27:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Unmoronify CVS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Any objections to the attached patch? What's wrong with val tags, such that you want them dead in your local instance of CVS? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 11: 0:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E132237B405 for ; Wed, 13 Mar 2002 11:00:20 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020313190020.LUAH1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 13 Mar 2002 19:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA75696; Wed, 13 Mar 2002 10:56:05 -0800 (PST) Date: Wed, 13 Mar 2002 10:56:03 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Unmoronify CVS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG wellll, what is the AIM of this? On 13 Mar 2002, Dag-Erling Smorgrav wrote: > Any objections to the attached patch? > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 11:18: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6F6CC37B402 for ; Wed, 13 Mar 2002 11:18:02 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2045B5346; Wed, 13 Mar 2002 20:17:57 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Unmoronify CVS References: From: Dag-Erling Smorgrav Date: 13 Mar 2002 20:17:56 +0100 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > wellll, what is the AIM of this? Kill val-tags with extreme prejudice. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 11:35: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A354437B400 for ; Wed, 13 Mar 2002 11:35:04 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DJZ5lv005359; Wed, 13 Mar 2002 11:35:05 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DJXnrh005222; Wed, 13 Mar 2002 11:33:49 -0800 (PST) Date: Wed, 13 Mar 2002 11:33:49 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Unmoronify CVS Message-ID: <20020313113349.A4997@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 13, 2002 at 01:56:22PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 01:56:22PM +0100, Dag-Erling Smorgrav wrote: > Any objections to the attached patch? It would be more helpful if you would tell what itch this scratches and justify the patch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 11:35:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7BAD237B400 for ; Wed, 13 Mar 2002 11:35:42 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DJZelv005417; Wed, 13 Mar 2002 11:35:40 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DJYO1K005276; Wed, 13 Mar 2002 11:34:24 -0800 (PST) Date: Wed, 13 Mar 2002 11:34:24 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: Julian Elischer , arch@freebsd.org Subject: Re: Unmoronify CVS Message-ID: <20020313113424.B4997@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 13, 2002 at 08:17:56PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 08:17:56PM +0100, Dag-Erling Smorgrav wrote: > Julian Elischer writes: > > wellll, what is the AIM of this? > > Kill val-tags with extreme prejudice. WHY? What problem is it causing you? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 11:40:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1709B37B402; Wed, 13 Mar 2002 11:40:56 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 133C65347; Wed, 13 Mar 2002 20:40:54 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: obrien@freebsd.org Cc: Julian Elischer , arch@freebsd.org Subject: Re: Unmoronify CVS References: <20020313113424.B4997@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Mar 2002 20:40:53 +0100 In-Reply-To: <20020313113424.B4997@dragon.nuxi.com> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" writes: > On Wed, Mar 13, 2002 at 08:17:56PM +0100, Dag-Erling Smorgrav wrote: > > Julian Elischer writes: > > > wellll, what is the AIM of this? > > Kill val-tags with extreme prejudice. > WHY? What problem is it causing you? Prevents checking out from ro repos; slows down any operation involving a tag not yet listed in val-tags; does not actually serve a discernable purpose (though it would have been moderatly useful if implemented differently) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 12:29: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 25BF837B41D; Wed, 13 Mar 2002 12:28:47 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2DKShWZ080532; Wed, 13 Mar 2002 15:28:44 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20020313113424.B4997@dragon.nuxi.com> Date: Wed, 13 Mar 2002 15:28:42 -0500 To: Dag-Erling Smorgrav , obrien@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Unmoronify CVS Cc: Julian Elischer , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:40 PM +0100 3/13/02, Dag-Erling Smorgrav wrote: >"David O'Brien" writes: > > WHY? What problem is it causing you? > >Prevents checking out from ro repos; You can check out from read-only repos, such as cd-rom drives. I know I've done it, but maybe I've only done it on openbsd. There's some option you have to include to 'cvs' so it won't try to write anything to the repository. (I forget what it is though). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 12:32:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 79D5037B400; Wed, 13 Mar 2002 12:32:53 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 551E9AE1D0; Wed, 13 Mar 2002 12:32:53 -0800 (PST) Date: Wed, 13 Mar 2002 12:32:53 -0800 From: Alfred Perlstein To: Garance A Drosihn Cc: Dag-Erling Smorgrav , obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313203253.GA74829@elvis.mu.org> References: <20020313113424.B4997@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Garance A Drosihn [020313 12:29] wrote: > At 8:40 PM +0100 3/13/02, Dag-Erling Smorgrav wrote: > >"David O'Brien" writes: > > > WHY? What problem is it causing you? > > > >Prevents checking out from ro repos; > > You can check out from read-only repos, such as cd-rom drives. > I know I've done it, but maybe I've only done it on openbsd. > There's some option you have to include to 'cvs' so it won't > try to write anything to the repository. (I forget what it > is though). under freebsd's cvs 'cvs -R', under netbsd's 'cvs -u' or you can export CVSREADONLYFS before running the command. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 12:39:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 379D237B404; Wed, 13 Mar 2002 12:39:08 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 322BB5348; Wed, 13 Mar 2002 21:39:06 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Garance A Drosihn Cc: obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020313113424.B4997@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Mar 2002 21:39:05 +0100 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > You can check out from read-only repos, such as cd-rom drives. Not if you need to use a tag and the repo doesn't have a val-tags file, or the tag isn't listed in it. > I know I've done it, but maybe I've only done it on openbsd. > There's some option you have to include to 'cvs' so it won't > try to write anything to the repository. (I forget what it > is though). -R, but it won't help. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 12:44:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1F33F37B400; Wed, 13 Mar 2002 12:44:29 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2DKiPWZ071532; Wed, 13 Mar 2002 15:44:26 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20020313113424.B4997@dragon.nuxi.com> Date: Wed, 13 Mar 2002 15:44:24 -0500 To: Dag-Erling Smorgrav From: Garance A Drosihn Subject: Re: Unmoronify CVS Cc: obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:39 PM +0100 3/13/02, Dag-Erling Smorgrav wrote: >Garance A Drosihn writes: >> You can check out from read-only repos, such as cd-rom drives. > >Not if you need to use a tag and the repo doesn't have a val-tags >file, or the tag isn't listed in it. > >> I know I've done it, but maybe I've only done it on openbsd. >> There's some option you have to include to 'cvs' so it won't >> try to write anything to the repository. (I forget what it >> is though). > >-R, but it won't help. Sounds like -R should be fixed so it works right in this situation, instead of providing a compile-time option to avoid the problem. (mind you, I don't even know what "val-tags" are...) Why should someone have to recompile CVS just to get -R to work? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13: 1: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6245C37B405; Wed, 13 Mar 2002 13:00:59 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id AA6835348; Wed, 13 Mar 2002 22:00:56 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Garance A Drosihn Cc: obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020313113424.B4997@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Mar 2002 22:00:56 +0100 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > Sounds like -R should be fixed so it works right in this situation, > instead of providing a compile-time option to avoid the problem. > (mind you, I don't even know what "val-tags" are...) Why should > someone have to recompile CVS just to get -R to work? You don't get the point at all. The val-tags stuff is *not needed* for *any purpose whatsoever* and *does not achieve the goal it was intended for* and *slows down any tag-related cvs operation by approximately half*. It's just not worth fixing. It is much simpler to just dike it out. If it had been implemented correctly, val-tags might have been somewhat useful for small repos containing just one module (or a very few), but it's *not* implemented correctly and it simply makes no sense at all for larger repos with dozens or hundreds or thousands of modules. It greatly pessimizes the common case and barely affects the rare case, and it generally pisses off anyone doing any serious amount of work with a read-only repo (or *any* repo that takes more than roughly three seconds to scan through) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13:12:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0B08A37B428; Wed, 13 Mar 2002 13:12:40 -0800 (PST) Received: from pool0271.cvx40-bradley.dialup.earthlink.net ([216.244.43.16] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lG2c-0007eO-00; Wed, 13 Mar 2002 13:12:11 -0800 Message-ID: <3C8FC098.9F665C4B@mindspring.com> Date: Wed, 13 Mar 2002 13:11:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Garance A Drosihn , obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020313113424.B4997@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Garance A Drosihn writes: > > You can check out from read-only repos, such as cd-rom drives. -R > Not if you need to use a tag and the repo doesn't have a val-tags > file, or the tag isn't listed in it. How is it possible to get a repository with a tag that's not in the val-tags file, or that lacks a val-tags file, I guess is the next question? > > I know I've done it, but maybe I've only done it on openbsd. > > There's some option you have to include to 'cvs' so it won't > > try to write anything to the repository. (I forget what it > > is though). > > -R, but it won't help. It certainly won't help if your val-tags file is corrupted or deleted. I still can't figure out how you could get into that situation, anyway. In the deleted case, it should fall back (obviously), so there is definitely room for improvement there; in the corrupt case, well, whatever corrupted it should be undone so it's not corrupted. Maybe we can tyurn this another direction? What is the purpose that you feel that val-tags was intended to fulfill, and where does it fall short? My personal impression is that it's intended as a list of tags that are there to allow a quick check against a cached list. Given that perspective (if right), then the same argument should be applied to the fallback situation for ldconfig when the lookup fails to find what it's looking for in cache. Modern csh's don't require a "rehash" for a new command to be found, either... it's just found by falling back to a search (smart ones update their cache when this happens). It seems to me that if the val-tags was advisory rather than mandatory, it would meet the design goals I personally thought it had... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13:28:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 93C1437B419 for ; Wed, 13 Mar 2002 13:28:12 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA17069; Wed, 13 Mar 2002 16:28:11 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2DLRfT40329; Wed, 13 Mar 2002 16:27:41 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15503.50253.527438.195997@grasshopper.cs.duke.edu> Date: Wed, 13 Mar 2002 16:27:41 -0500 (EST) To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-Reply-To: References: <20020313093805.GA29679@genius.tao.org.uk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Garance A Drosihn writes: > > Would it make any sense to compress it in the 'gzip' sense of > > the word (or some simpler algorithm)? > > Not really. The compression rate is not sufficiently predictable, and > dumping would be s...l...o...w... > You might not want to discount it out of hand. Other OSes (at least Tru64, possibly others) do compressed dumps effectively. Investigating this, once you've gotten a unified dumpsys, is a potential Junior Kernel Hacker task. Your dumpsys cleanup & proposed format with a nice little header at the front will facilitate work like this, as well as partial dumps, (which I'm partial to ;) to be easily integrated. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13:31:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 663A937B400 for ; Wed, 13 Mar 2002 13:31:17 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2DLVD447785; Wed, 13 Mar 2002 22:31:13 +0100 (CET) (envelope-from wkb) Date: Wed, 13 Mar 2002 22:31:13 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: dumpsys() rewrite Message-ID: <20020313223113.H47476@freebie.xs4all.nl> References: <20020313093805.GA29679@genius.tao.org.uk> <15503.50253.527438.195997@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15503.50253.527438.195997@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Mar 13, 2002 at 04:27:41PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 04:27:41PM -0500, Andrew Gallatin wrote: > > Dag-Erling Smorgrav writes: > > Garance A Drosihn writes: > > > Would it make any sense to compress it in the 'gzip' sense of > > > the word (or some simpler algorithm)? > > > > Not really. The compression rate is not sufficiently predictable, and > > dumping would be s...l...o...w... > > > > You might not want to discount it out of hand. Other OSes (at least > Tru64, possibly others) do compressed dumps effectively. T64 needs to (badly). Given that Wildfires with 256 GB core find their way to customers.. ;-) Even for more modest boxes with 32GB core a compressed dump becomes interesting. Wilko -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13:38: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id AE02937B416 for ; Wed, 13 Mar 2002 13:37:57 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA17413; Wed, 13 Mar 2002 16:37:57 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2DLbRe41372; Wed, 13 Mar 2002 16:37:27 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15503.50839.236894.328862@grasshopper.cs.duke.edu> Date: Wed, 13 Mar 2002 16:37:27 -0500 (EST) To: Wilko Bulte Cc: arch@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-Reply-To: <20020313223113.H47476@freebie.xs4all.nl> References: <20020313093805.GA29679@genius.tao.org.uk> <15503.50253.527438.195997@grasshopper.cs.duke.edu> <20020313223113.H47476@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wilko Bulte writes: > > T64 needs to (badly). Given that Wildfires with 256 GB core find their > way to customers.. ;-) Even for more modest boxes with 32GB core a > compressed dump becomes interesting. And they also have other optimizations (partial dumps, dumps to RAM) which make dumping fast. BTW, dumping to RAM is so God Damned cool.. we should do it too -- what platforms have memory which is persistant across reboots besides alpha? Between partial dumps, dumping to RAM, and compression, my XP1000 at work will dump in about 5 seconds for a 512 MB machine. I almost don't mind crashing it because its so cool to watch it dump in a few seconds ;) Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 13:58:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8373F37B405; Wed, 13 Mar 2002 13:58:40 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g2DLwW611237; Wed, 13 Mar 2002 16:58:34 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200203132158.g2DLwW611237@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: Garance A Drosihn , obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS In-Reply-To: Your message of "13 Mar 2002 22:00:56 +0100." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Mar 2002 16:58:32 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Garance A Drosihn writes: > > Sounds like -R should be fixed so it works right in this situation, > > instead of providing a compile-time option to avoid the problem. > > (mind you, I don't even know what "val-tags" are...) Why should > > someone have to recompile CVS just to get -R to work? > > You don't get the point at all. The val-tags stuff is *not needed* > for *any purpose whatsoever* and *does not achieve the goal it was > intended for* and *slows down any tag-related cvs operation by > approximately half*. It's just not worth fixing. It is much simpler > to just dike it out. > > If it had been implemented correctly, val-tags might have been > somewhat useful for small repos containing just one module (or a very > few), but it's *not* implemented correctly and it simply makes no > sense at all for larger repos with dozens or hundreds or thousands of > modules. It greatly pessimizes the common case and barely affects the > rare case, and it generally pisses off anyone doing any serious amount > of work with a read-only repo (or *any* repo that takes more than > roughly three seconds to scan through) To provide the appropriate misquotation: BANG. BANG. BANG. BANG. BANG. BANG. BANG. BANG. click. click. BANG. BANG. BANG. BANG. BANG. BANG. BANG. BANG. click. click. Please, please, please remove it. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 14: 0:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id ED9E537B404 for ; Wed, 13 Mar 2002 14:00:40 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 46C175346; Wed, 13 Mar 2002 23:00:38 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Andrew Gallatin Cc: Wilko Bulte , arch@FreeBSD.ORG Subject: Re: dumpsys() rewrite References: <20020313093805.GA29679@genius.tao.org.uk> <15503.50253.527438.195997@grasshopper.cs.duke.edu> <20020313223113.H47476@freebie.xs4all.nl> <15503.50839.236894.328862@grasshopper.cs.duke.edu> From: Dag-Erling Smorgrav Date: 13 Mar 2002 23:00:37 +0100 In-Reply-To: <15503.50839.236894.328862@grasshopper.cs.duke.edu> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrew Gallatin writes: > And they also have other optimizations (partial dumps, dumps to RAM) > which make dumping fast. BTW, dumping to RAM is so God Damned > cool.. we should do it too -- what platforms have memory which is > persistant across reboots besides alpha? i386 (provided it's a warmboot), probably sparc64, possibly ia64. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 14:36:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 66C6037B41C; Wed, 13 Mar 2002 14:36:37 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DMablv014286; Wed, 13 Mar 2002 14:36:37 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DMZM9T014272; Wed, 13 Mar 2002 14:35:22 -0800 (PST) Date: Wed, 13 Mar 2002 14:35:22 -0800 From: "David O'Brien" To: "Brian F. Feldman" Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313143522.A13768@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200203132158.g2DLwW611237@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203132158.g2DLwW611237@green.bikeshed.org>; from green@FreeBSD.ORG on Wed, Mar 13, 2002 at 04:58:32PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 04:58:32PM -0500, Brian F. Feldman wrote: > > sense at all for larger repos with dozens or hundreds or thousands of > > modules. It greatly pessimizes the common case and barely affects the > > rare case, and it generally pisses off anyone doing any serious amount > > of work with a read-only repo (or *any* repo that takes more than > > roughly three seconds to scan through) ... > Please, please, please remove it. Neither of you two have yet to give real justification. I use -R all the time -- does that mean I am not using a "read-only" repo? I use serveral repos with "dozens or hundreds or thousands of modules" and it isn't "generally pisses [me] off". Please explain in more detail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 14:53:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D7DE637B400; Wed, 13 Mar 2002 14:53:04 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id F11485346; Wed, 13 Mar 2002 23:53:02 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: obrien@FreeBSD.ORG Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Mar 2002 23:53:01 +0100 In-Reply-To: <20020313143522.A13768@dragon.nuxi.com> Message-ID: Lines: 71 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" writes: > Neither of you two have yet to give real justification. > I use -R all the time -- does that mean I am not using a "read-only" > repo? I use serveral repos with "dozens or hundreds or thousands of > modules" and it isn't "generally pisses [me] off". Because you don't use tags much, or the read-only repos you use have fully populated val-tags. > Please explain in more detail. There are three possible scenarios: a) The tag you're asking for is in val-tags. No sweat. CVS scans all the files you're asking it to operate on, and does whatever you asked it to do. b) The tag you're asking for exists, but isn't in val-tags. CVS will scan all the files you're asking it to operate on, looking for the tag - and it won't stop at the first hit. It will then add the tag to val-tags (if possible) and go to a), or fail because val-tags isn't writeable. Note that CVS processes every file twice - once to see if it has the tag, and once to actually perform the requested operation. c) The tag you're asking for does not exist. CVS will scan all the files you're asking it to operate on, and give you an error message. Without val-tags, these three cases become: a) No difference. b) Go directly to a), scanning each file once rather than twice, and don't fail if the repo is read-only. c) Try to do whatever you asked it to do, and fail. So val-tags adds no value whatsoever in cases a) and b), and actually pessimizes case b) (which I encounter often enough to be *really* pissed off at val-tags). It all hinges on case c), so let's take a closer look at it. The idea with case c) is that CVS should be able to tell you that none of the files you asked it to operate on have the tag you specified. But: - That may be intentional. Maybe you're 'cvs up'ing to a nonexistent tag in order to quickly and cleanly remove all unmodified files in your tree. - You'd find out quickly enough anyway, at very little or no expense; if you typed 'cvs up -rRELEN_4' by mistake, you'll very quickly realize you've done something wrong, as CVS starts removing all unmodified files, and you can recover by aborting and restarting the command with the correct tag; you won't have lost anything. - When operating on portions of the tree, val-tags can give false positives because the tag you asked for exists in another part of the tree. To summarize, val-tags saves a little time in a small number of cases, is useless in most cases, and outright harmful in many common cases. And all this is a waste of my time; rather than ask why I want it removed, you should accept that I (and many others) consider it an incredible nuisance, and focus instead on explaining how *you* benefit from it, so we can understand why you're opposed to my patch. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 15: 7:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 39DD737B400; Wed, 13 Mar 2002 15:07:28 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DN7Slv014757; Wed, 13 Mar 2002 15:07:28 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DN6DZj014736; Wed, 13 Mar 2002 15:06:13 -0800 (PST) Date: Wed, 13 Mar 2002 15:06:13 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313150613.B13768@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 13, 2002 at 11:53:01PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 11:53:01PM +0100, Dag-Erling Smorgrav wrote: > And all this is a waste of my time; rather than ask why I want it > removed, you should accept that I (and many others) consider it an > incredible nuisance, and focus instead on explaining how *you* benefit > from it, so we can understand why you're opposed to my patch. 1. CVS is contrib'e software. We try not to make grautious changes in contrib'ed softare. 2. CVS is used by many, many people on all kinds of repositories -- not just those used in FreeBSD development. So you are changing a tool away from its stock, expected behavior. There needs to be a good reason for that. Of all the CVS users, why are you the only one bothered by this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 15: 9: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id F08F637B402; Wed, 13 Mar 2002 15:09:01 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8AAC15346; Thu, 14 Mar 2002 00:09:00 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: obrien@FreeBSD.ORG Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <20020313150613.B13768@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 14 Mar 2002 00:09:00 +0100 In-Reply-To: <20020313150613.B13768@dragon.nuxi.com> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" writes: > 2. CVS is used by many, many people on all kinds of repositories -- not > just those used in FreeBSD development. So you are changing a tool > away from its stock, expected behavior. There needs to be a good > reason for that. Of all the CVS users, why are you the only one > bothered by this? I am not, but for some reason - probably your personal dislike of me - you enjoy pretending that I am, and opposing this patch without providing a single argument to show that val-tags is actually useful. I find that extremely unprofessional of you. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 15:14: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A175837B416; Wed, 13 Mar 2002 15:14:03 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DNE3lv014835; Wed, 13 Mar 2002 15:14:03 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DNCnS5014832; Wed, 13 Mar 2002 15:12:49 -0800 (PST) Date: Wed, 13 Mar 2002 15:12:49 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313151249.A14813@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <20020313150613.B13768@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Thu, Mar 14, 2002 at 12:09:00AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 14, 2002 at 12:09:00AM +0100, Dag-Erling Smorgrav wrote: > I am not, but for some reason - probably your personal dislike of me - > you enjoy pretending that I am, and opposing this patch without > providing a single argument to show that val-tags is actually useful. > I find that extremely unprofessional of you. DES, what the fsck are you talking about. There is nothing showing any personal dislike of you here, nor have I been unprofessional. You have had one agreement with you -- and that was only "yes!" with no explantion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 15:20:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5413F37B400 for ; Wed, 13 Mar 2002 15:20:45 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2DNKjlv014871 for ; Wed, 13 Mar 2002 15:20:45 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2DNJUS9014867 for arch@FreeBSD.ORG; Wed, 13 Mar 2002 15:19:30 -0800 (PST) Date: Wed, 13 Mar 2002 15:19:30 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313151930.B14813@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 13, 2002 at 11:53:01PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It has been worse than pulling teeth from a rattle snake, (and also had to take some abuse from DES on IRC (yeah, what's new)). According to Brian Feldman, here is an example of what this is all about: $ cvs -R -d opensource:/home/freebsd/ncvs co -rRELENG_4_3_0_RELEASE src/UPDATINGcvs server: warning: cannot open cvs server: warning: cannot open /home/freebsd/ncvs/CVSROOT/val-tags read/write: Permission deniedcvs [server aborted]: cannot read /home/freebsd/ncvs/CVSROOT/val-tags: Permission denied With just no write access but still read access: $ cvs -R -d opensource:/home/freebsd/ncvs co -rRELENG_4_3_0_RELEASE src/UPDATING cvs [server aborted]: cannot write /home/freebsd/ncvs/CVSROOT/val-tags: Permission denied To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 15:50:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CDD2537B405; Wed, 13 Mar 2002 15:50:07 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g2DNo5i32059; Wed, 13 Mar 2002 16:50:06 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g2DNo5L44481; Wed, 13 Mar 2002 16:50:05 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200203132350.g2DNo5L44481@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: Unmoronify CVS Cc: Garance A Drosihn , obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG In-reply-to: Your message of "13 Mar 2002 21:39:05 +0100." References: <20020313113424.B4997@dragon.nuxi.com> Date: Wed, 13 Mar 2002 16:50:05 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : Garance A Drosihn writes: : > You can check out from read-only repos, such as cd-rom drives. : : Not if you need to use a tag and the repo doesn't have a val-tags : file, or the tag isn't listed in it. Strange, it works for me. But if it doesn't for you, maybe you should fix the root cause of the problem. I use RO repos all the time and have yet to have this bite me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 16: 1:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 6B02A37B426; Wed, 13 Mar 2002 16:00:59 -0800 (PST) Received: from pool0256.cvx22-bradley.dialup.earthlink.net ([209.179.199.1] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lIfv-0005ND-00; Wed, 13 Mar 2002 16:00:55 -0800 Message-ID: <3C8FE822.1B5FBC0B@mindspring.com> Date: Wed, 13 Mar 2002 16:00:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: obrien@FreeBSD.ORG, "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > "David O'Brien" writes: > > Neither of you two have yet to give real justification. > > I use -R all the time -- does that mean I am not using a "read-only" > > repo? I use serveral repos with "dozens or hundreds or thousands of > > modules" and it isn't "generally pisses [me] off". > > Because you don't use tags much, or the read-only repos you use have > fully populated val-tags. Yeah. How do you get a val-tags that's not fully populated, if your repository isn't writeable, so you can't lay down new tags, since if your repo was writable, you'd be able to write the tags file, too? > a) The tag you're asking for is in val-tags. No sweat. CVS scans all > the files you're asking it to operate on, and does whatever you > asked it to do. Yes. > b) The tag you're asking for exists, but isn't in val-tags. CVS will > scan all the files you're asking it to operate on, looking for the > tag - and it won't stop at the first hit. It will then add the tag > to val-tags (if possible) and go to a), or fail because val-tags > isn't writeable. Note that CVS processes every file twice - once > to see if it has the tag, and once to actually perform the > requested operation. I think that it should process every file, and stop at the first one that has the tag. Then it should add the tag to an internal list that it treats as if it were val-tags. Basically, this means that the writeability of the val-tags file should affect you. I would not mind if you added the printf: fprintf( stderr, "Hey moron, your val-tags is out of date!\n"); So that the repository maintainer can update the val-tags, since they are updating the rest of the world, but not the val-tags file for some reason unknown to mortal ken. ;^). In other words, I think that the two pass scan is necessary to the code knowing that a tag exists before it goes off and tries to do work in the context of a tag. Stopping the first pass after finding the tag, and starting the second in the context of the tag existing seems like the write thing. You could probably combine the pass based on the patches you posted. > c) The tag you're asking for does not exist. CVS will scan all the > files you're asking it to operate on, and give you an error message. > > Without val-tags, these three cases become: > > a) No difference. Yes. > b) Go directly to a), scanning each file once rather than twice, and > don't fail if the repo is read-only. > > c) Try to do whatever you asked it to do, and fail. I think that these might be slightly different behaviours, based on attempting to start the operation. In particular, there's a bad interaction with "-P" if you typo on a tag name that doesn't happen with the pre-validation of the tag, which your patch breaks. > So val-tags adds no value whatsoever in cases a) and b), and actually > pessimizes case b) (which I encounter often enough to be *really* > pissed off at val-tags). It all hinges on case c), so let's take a > closer look at it. My version of case b is much more often a typo on my part, than the intentional use of a non-existant tag. > The idea with case c) is that CVS should be able to tell you that none > of the files you asked it to operate on have the tag you specified. OR that the tag doesn't exist! > But: > > - That may be intentional. Maybe you're 'cvs up'ing to a nonexistent > tag in order to quickly and cleanly remove all unmodified files in > your tree. It's tempting to make a special tag like "HEAD" called "EMPTY" that could take care of this. > - You'd find out quickly enough anyway, at very little or no expense; > if you typed 'cvs up -rRELEN_4' by mistake, you'll very quickly > realize you've done something wrong, as CVS starts removing all > unmodified files, and you can recover by aborting and restarting > the command with the correct tag; you won't have lost anything. I think you might be screwed on sticky tags, in this instance. Also, the removing isn't inexpensive, and neither is getting it back. Using CVS over ssh over a slow link could make the removal very fast, and the recovery incredibly slow. > - When operating on portions of the tree, val-tags can give false > positives because the tag you asked for exists in another part of > the tree. This is true for tags that aren't over the entire tree. I'm of two minds on it. The first is that tags are tree-wide, and if the source in question is untagged, then the untagging is intentional, and not accidental. The second is that you might tag subtrees without using modules, even though this is contrary to the CVS documentation and FAQ, you could have discovered that it works. 8-). I think the "EMPTY" tag covers the first case. The second case almost wants to make the "case b" pass over the tree, if the pass is over a subtree that is not rooted at a module base (e.g. if I cd into /usr/src/sys/ufs and do it, vs. /usr/src/sys) ...but it assumes that val-tags tags are differentiable on a per module basis, which is wrong (for now), I think. > To summarize, val-tags saves a little time in a small number of cases, > is useless in most cases, and outright harmful in many common cases. It saves your butt in the slow-link-typo case... I think the cases where it's harmful are contrived: they are based on having bogus contents in the val-tags file in the first place. > And all this is a waste of my time; rather than ask why I want it > removed, you should accept that I (and many others) consider it an > incredible nuisance, and focus instead on explaining how *you* benefit > from it, so we can understand why you're opposed to my patch. I have to say that val-tags has saved my ass when using anonymous CVS to a read-only repository (NetBSD) over a 28k modem. I can see there being room for a patch that: 1) Caches the results of the val-tags update, so that if the update fails, the second pass doesn't fail. 2) Stops the first pass at the first file where the tag is seen, and converts immediately to second-pass. It probably needs to start from scratch in the "-P" case. This fixes your "case b" completely. I don't know if I agree with your "case c", but I can see some merit to it; a special tag (e.g. "EMPTY") on the order of "HEAD" would probably be the correct overall fix for this. If you wanted to cheap out, you could predicate the change on "-R present and -P absent", and only change to the patched behaviour in that case. Most people would find this much less objectionable. Though it still would bite you in the cases where val-tags has saved me, so I would prefer it if the behaviour is not changed using the "cheap out" approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 16:30:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 3F00A37B405 for ; Wed, 13 Mar 2002 16:30:47 -0800 (PST) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 16lJ8o-0002tT-01; Thu, 14 Mar 2002 01:30:46 +0100 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.2/8.12.2) with ESMTP id g2E05pdr091015 for ; Thu, 14 Mar 2002 01:05:51 +0100 (CET) (envelope-from mailnull@localhost.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.2/8.12.2/Submit) id g2E05pfk091014 for freebsd-arch@freebsd.org; Thu, 14 Mar 2002 01:05:51 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Unmoronify CVS Date: Thu, 14 Mar 2002 00:05:50 +0000 (UTC) Message-ID: References: <3C8FC098.9F665C4B@mindspring.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > How is it possible to get a repository with a tag that's not > in the val-tags file, or that lacks a val-tags file, I guess > is the next question? The FreeBSD CVSup mirror configuration explicitly excludes CVSROOT/val-tags from being mirrored. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 16:56:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 5892337B404 for ; Wed, 13 Mar 2002 16:56:08 -0800 (PST) Received: from pool0256.cvx22-bradley.dialup.earthlink.net ([209.179.199.1] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lJXJ-0005FZ-00; Wed, 13 Mar 2002 16:56:06 -0800 Message-ID: <3C8FF50F.C16C431A@mindspring.com> Date: Wed, 13 Mar 2002 16:55:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Weisgerber Cc: freebsd-arch@freebsd.org Subject: Re: Unmoronify CVS References: <3C8FC098.9F665C4B@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Christian Weisgerber wrote: > Terry Lambert wrote: > > How is it possible to get a repository with a tag that's not > > in the val-tags file, or that lacks a val-tags file, I guess > > is the next question? > > The FreeBSD CVSup mirror configuration explicitly excludes > CVSROOT/val-tags from being mirrored. If it's not excluded, does that fix the problem? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 20:13: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A78C637B416 for ; Wed, 13 Mar 2002 20:13:02 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g2E4D1i33544 for ; Wed, 13 Mar 2002 21:13:01 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g2E4CvL46115 for ; Wed, 13 Mar 2002 21:13:01 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 13 Mar 2002 21:12:52 -0700 (MST) Message-Id: <20020313.211252.132928159.imp@village.org> To: arch@freebsd.org Subject: Comments on sys.mk change to make /etc/make.conf optional From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm posting this here because it is a fairly fundamental change to the system. It makes /etc/make.conf optional, for shared environments that might want to have different settings for different users. I used __MAKE_CONF to try not to pollute things. This also lets people like bde say "setenv __MAKE_CONF /dev/null" for extreme purity. Comments? Warner Index: sys.mk =================================================================== RCS file: /base/FreeBSD-CVS/src/share/mk/sys.mk,v retrieving revision 1.56 diff -u -r1.56 sys.mk --- sys.mk 2001/08/31 12:20:43 1.56 +++ sys.mk 2002/03/12 18:31:36 @@ -244,8 +244,9 @@ .endif -.if exists(/etc/make.conf) -.include +__MAKE_CONF?=/etc/make.conf +.if exists(${__MAKE_CONF}) +.include "${__MAKE_CONF}" .endif .include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 20:59:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 7BAE137B417 for ; Wed, 13 Mar 2002 20:59:49 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2E4xlWZ076674; Wed, 13 Mar 2002 23:59:47 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020313.211252.132928159.imp@village.org> References: <20020313.211252.132928159.imp@village.org> Date: Wed, 13 Mar 2002 23:59:46 -0500 To: "M. Warner Losh" , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Comments on sys.mk change to make /etc/make.conf optional Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:12 PM -0700 3/13/02, M. Warner Losh wrote: >I'm posting this here because it is a fairly fundamental change >to the system. It makes /etc/make.conf optional, for shared >environments that might want to have different settings for >different users. I used __MAKE_CONF to try not to pollute things. I like the idea. I would prefer a different name for the variable. Something without the leading __ , because to me the leading underscores would imply a name that a user would *not* define. BSD_MAKE_CONF ? FBSD_MAKE_CONF ? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 21: 4:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E4BEB37B41E for ; Wed, 13 Mar 2002 21:04:12 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g2E54Bi33864; Wed, 13 Mar 2002 22:04:11 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g2E54AL46434; Wed, 13 Mar 2002 22:04:10 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 13 Mar 2002 22:04:00 -0700 (MST) Message-Id: <20020313.220400.07696500.imp@village.org> To: drosih@rpi.edu Cc: arch@FreeBSD.ORG Subject: Re: Comments on sys.mk change to make /etc/make.conf optional From: "M. Warner Losh" In-Reply-To: References: <20020313.211252.132928159.imp@village.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : At 9:12 PM -0700 3/13/02, M. Warner Losh wrote: : >I'm posting this here because it is a fairly fundamental change : >to the system. It makes /etc/make.conf optional, for shared : >environments that might want to have different settings for : >different users. I used __MAKE_CONF to try not to pollute things. : : I like the idea. I would prefer a different name for the variable. : Something without the leading __ , because to me the leading : underscores would imply a name that a user would *not* define. I specifically chose __MAKE_CONF because users aren't supposed to set it and it doesn't polute the user's name space. sys.mk are global variables. In general, people shouldn't change it, but it is there in extreme cases, can set it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 23:50:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 04D1B37B404 for ; Wed, 13 Mar 2002 23:50:43 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020314075042.JRCH1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Thu, 14 Mar 2002 07:50:42 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g2E7of739647; Wed, 13 Mar 2002 23:50:41 -0800 (PST) (envelope-from cjc) Date: Wed, 13 Mar 2002 23:50:41 -0800 From: "Crist J. Clark" To: Terry Lambert Cc: Christian Weisgerber , freebsd-arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313235041.C29705@blossom.cjclark.org> References: <3C8FC098.9F665C4B@mindspring.com> <3C8FF50F.C16C431A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C8FF50F.C16C431A@mindspring.com>; from tlambert2@mindspring.com on Wed, Mar 13, 2002 at 04:55:43PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 04:55:43PM -0800, Terry Lambert wrote: > Christian Weisgerber wrote: > > Terry Lambert wrote: > > > How is it possible to get a repository with a tag that's not > > > in the val-tags file, or that lacks a val-tags file, I guess > > > is the next question? > > > > The FreeBSD CVSup mirror configuration explicitly excludes > > CVSROOT/val-tags from being mirrored. > > If it's not excluded, does that fix the problem? It fixes the problem, but it also goes to further show how useless the file is. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 13 23:54:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id ED42137B404; Wed, 13 Mar 2002 23:54:25 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020314075425.JSAL1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Thu, 14 Mar 2002 07:54:25 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g2E7sMd39667; Wed, 13 Mar 2002 23:54:22 -0800 (PST) (envelope-from cjc) Date: Wed, 13 Mar 2002 23:54:22 -0800 From: "Crist J. Clark" To: Warner Losh Cc: Dag-Erling Smorgrav , Garance A Drosihn , obrien@FreeBSD.ORG, Julian Elischer , arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020313235422.D29705@blossom.cjclark.org> References: <20020313113424.B4997@dragon.nuxi.com> <200203132350.g2DNo5L44481@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203132350.g2DNo5L44481@harmony.village.org>; from imp@harmony.village.org on Wed, Mar 13, 2002 at 04:50:05PM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 13, 2002 at 04:50:05PM -0700, Warner Losh wrote: > In message Dag-Erling Smorgrav writes: > : Garance A Drosihn writes: > : > You can check out from read-only repos, such as cd-rom drives. > : > : Not if you need to use a tag and the repo doesn't have a val-tags > : file, or the tag isn't listed in it. > > Strange, it works for me. But if it doesn't for you, maybe you should > fix the root cause of the problem. I use RO repos all the time and > have yet to have this bite me. Really? I've had this problem several times with read-only, NFS-mounted repositories. # mv $CVSROOT/CVSROOT/val-tags $CVSROOT/CVSROOT/val-tags.hold And try a read-only CVS operation. If the repository is _really_ read-only, you should get an error. If you just give '-R' to cvs(1), but the respository can really be written to, it will write to val-tags. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 0:35:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from postoffice.aims.com.au (eth0.lnk.aims.com.au [203.31.73.253]) by hub.freebsd.org (Postfix) with ESMTP id 3CC6B37B419 for ; Thu, 14 Mar 2002 00:35:54 -0800 (PST) Received: from postoffice.aims.com.au (nts-ts1.aims.private [192.168.10.2]) by postoffice.aims.com.au with ESMTP id g2E8ZqW18798 for ; Thu, 14 Mar 2002 19:35:52 +1100 (EST) (envelope-from chris@aims.com.au) Received: from ntsts1 by aims.com.au with SMTP (MDaemon.v3.5.3.R) for ; Thu, 14 Mar 2002 19:35:37 +1100 Reply-To: From: "Chris Knight" To: Cc: Subject: RE: Unmoronify CVS Date: Thu, 14 Mar 2002 19:35:35 +1100 Message-ID: <028e01c1cb33$36de8d50$020aa8c0@aims.private> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Return-Path: chris@aims.com.au X-MDaemon-Deliver-To: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Howdy, The patch is OK, except you've sent it to the wrong list. Send it to dev@ccvs.cvshome.org and see what they think. If it's worthwhile, it will be added to the CVS source first, then added to the FreeBSD repository during the next import. If you insist on adding the patch go add a cvs port to the ports tree and put it in there. Thanks. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au > -----Original Message----- > From: owner-freebsd-arch@FreeBSD.ORG > [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of > Dag-Erling Smorgrav > Sent: Wednesday, 13 March 2002 23:56 > To: arch@FreeBSD.ORG > Subject: Unmoronify CVS > > > Any objections to the attached patch? > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 0:55:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from inpbox.inp.nsk.su (inpbox.inp.nsk.su [193.124.167.24]) by hub.freebsd.org (Postfix) with ESMTP id 28F3137B416; Thu, 14 Mar 2002 00:55:21 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by inpbox.inp.nsk.su (8.12.1/8.12.1) with ESMTP id g2E8khqf011610; Thu, 14 Mar 2002 14:46:43 +0600 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 16lR11-0000gA-00; Thu, 14 Mar 2002 14:55:15 +0600 Received: (from fjoe@localhost) by iclub.nsu.ru (8.11.6/8.11.6) id g2E8tGd83525; Thu, 14 Mar 2002 14:55:16 +0600 (NS) (envelope-from fjoe) Date: Thu, 14 Mar 2002 14:55:16 +0600 From: Max Khon To: "David O'Brien" Cc: arch@freebsd.org Subject: Re: Unmoronify CVS Message-ID: <20020314145516.A83128@iclub.nsu.ru> References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <20020313151930.B14813@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020313151930.B14813@dragon.nuxi.com>; from obrien@freebsd.org on Wed, Mar 13, 2002 at 03:19:30PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, there! On Wed, Mar 13, 2002 at 03:19:30PM -0800, David O'Brien wrote: > It has been worse than pulling teeth from a rattle snake, (and also had > to take some abuse from DES on IRC (yeah, what's new)). > > According to Brian Feldman, here is an example of what this is all about: > > $ cvs -R -d opensource:/home/freebsd/ncvs co -rRELENG_4_3_0_RELEASE src/UPDATINGcvs server: warning: cannot open > cvs server: warning: cannot open /home/freebsd/ncvs/CVSROOT/val-tags read/write: Permission deniedcvs [server aborted]: cannot read /home/freebsd/ncvs/CVSROOT/val-tags: Permission denied > > With just no write access but still read access: > > $ cvs -R -d opensource:/home/freebsd/ncvs co -rRELENG_4_3_0_RELEASE src/UPDATING > cvs [server aborted]: cannot write /home/freebsd/ncvs/CVSROOT/val-tags: Permission denied does setenv CVS_SERVER 'cvs -R' help? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 3:18: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id F270E37B416; Thu, 14 Mar 2002 03:17:51 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2EBH4D02622; Thu, 14 Mar 2002 03:17:04 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203141117.g2EBH4D02622@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: Dag-Erling Smorgrav , Josef Karthauser , arch@FreeBSD.ORG, peter@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: dumpsys() rewrite In-reply-to: Your message of "Wed, 13 Mar 2002 10:42:41 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Mar 2002 03:17:03 -0800 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >dumpsys() controls what is written and when. It is perfectly > >conceivable for dumpsys() to do the same kind of hole compression > >that savecore(1) does, but it would be *much* slower and ... > > Would it make any sense to compress it in the 'gzip' sense of > the word (or some simpler algorithm)? Or does it already do > some of that? The problem here is that when dumpsys is called, the system is in an unknown but probably hosed state. Compression algorithms typically require considerable amounts of memory, which would have to be tied down at startup to avoid depending on a possibly broken, deadlocked or corrupt allocator at dump time. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 4: 1:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7DE7D37B404 for ; Thu, 14 Mar 2002 04:01:20 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 9B8905346; Thu, 14 Mar 2002 13:01:18 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Cc: Subject: Re: Unmoronify CVS References: <028e01c1cb33$36de8d50$020aa8c0@aims.private> From: Dag-Erling Smorgrav Date: 14 Mar 2002 13:01:17 +0100 In-Reply-To: <028e01c1cb33$36de8d50$020aa8c0@aims.private> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Chris Knight" writes: > The patch is OK, except you've sent it to the wrong list. Send it to > dev@ccvs.cvshome.org and see what they think. Does anyone seriously believe that CVS is still being maintained? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 4:12:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id E797337B417 for ; Thu, 14 Mar 2002 04:12:27 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 40E635346; Thu, 14 Mar 2002 13:12:26 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: naddy@mips.inka.de (Christian Weisgerber) Cc: freebsd-arch@freebsd.org Subject: Re: Unmoronify CVS References: <3C8FC098.9F665C4B@mindspring.com> From: Dag-Erling Smorgrav Date: 14 Mar 2002 13:12:25 +0100 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG naddy@mips.inka.de (Christian Weisgerber) writes: > Terry Lambert wrote: > > How is it possible to get a repository with a tag that's not > > in the val-tags file, or that lacks a val-tags file, I guess > > is the next question? > The FreeBSD CVSup mirror configuration explicitly excludes > CVSROOT/val-tags from being mirrored. Irrelevant - CVS doesn't add tags to val-tags when they're laid down, so even freefall's val-tags is not necessarily complete. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 4:12:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C44B237B405; Thu, 14 Mar 2002 04:12:52 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 589E25346; Thu, 14 Mar 2002 13:12:51 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Max Khon Cc: "David O'Brien" , arch@freebsd.org Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <20020313151930.B14813@dragon.nuxi.com> <20020314145516.A83128@iclub.nsu.ru> From: Dag-Erling Smorgrav Date: 14 Mar 2002 13:12:50 +0100 In-Reply-To: <20020314145516.A83128@iclub.nsu.ru> Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Max Khon writes: > does setenv CVS_SERVER 'cvs -R' help? No. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 4:13:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 232A337B404 for ; Thu, 14 Mar 2002 04:13:52 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EB20F5347; Thu, 14 Mar 2002 13:13:50 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Comments on sys.mk change to make /etc/make.conf optional References: <20020313.211252.132928159.imp@village.org> From: Dag-Erling Smorgrav Date: 14 Mar 2002 13:13:50 +0100 In-Reply-To: <20020313.211252.132928159.imp@village.org> Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" writes: > Comments? Excellent! Thank you! DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 6:20:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) by hub.freebsd.org (Postfix) with ESMTP id 2C48437B404; Thu, 14 Mar 2002 06:20:09 -0800 (PST) Received: from dungeon.home (ppp18.dyn249.pacific.net.au [203.143.249.18]) by mongrel.pacific.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id BAA31942; Fri, 15 Mar 2002 01:19:17 +1100 X-Authentication-Warning: mongrel.pacific.net.au: Host ppp18.dyn249.pacific.net.au [203.143.249.18] claimed to be dungeon.home Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.6/8.11.1) with ESMTP id g2EEKLP15630; Fri, 15 Mar 2002 00:20:21 +1000 (EST) (envelope-from mckay) Message-Id: <200203141420.g2EEKLP15630@dungeon.home> To: Dag-Erling Smorgrav Cc: arch@freebsd.org, mckay@thehub.com.au, obrien@freebsd.org Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> In-Reply-To: from Dag-Erling Smorgrav at "Wed, 13 Mar 2002 22:53:01 +0000" Date: Fri, 15 Mar 2002 00:20:21 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday, 13th March 2002, Dag-Erling Smorgrav wrote: >To summarize, val-tags saves a little time in a small number of cases, >is useless in most cases, and outright harmful in many common cases. Val-tags has caused me nothing but irritation. It has never assisted me in any way. It deserves to die. Who here is helped by val-tags? It seems to be just plain wrong from the day it was added. >And all this is a waste of my time; rather than ask why I want it >removed, you should accept that I (and many others) consider it an >incredible nuisance, and focus instead on explaining how *you* benefit >from it, so we can understand why you're opposed to my patch. That's not the normal way to go about things. Normally you explain why changing things is a good idea. Sort of an "innocent until proven guilty" idea. Once you've got a good argument *for* changing things it's time to look for arguments *against* changing it, not the other way round. But that little nit aside (which, let's face it, got up some people's noses), I fully agree with your argument. I'm frankly surprised you had to spell it all out. I expected a chorus of "Hell yeah!" and a quick commit. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 7:28:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id BB07237B416 for ; Thu, 14 Mar 2002 07:28:31 -0800 (PST) Received: from dan.emsphone.com (dan@localhost [127.0.0.1]) by dan.emsphone.com (8.12.2/8.12.2) with ESMTP id g2EFSLik022018; Thu, 14 Mar 2002 09:28:21 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.2/8.12.2/Submit) id g2EFSJCw022015; Thu, 14 Mar 2002 09:28:19 -0600 (CST) Date: Thu, 14 Mar 2002 09:28:19 -0600 From: Dan Nelson To: Dag-Erling Smorgrav Cc: chris@aims.com.au, arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020314152819.GE5074@dan.emsphone.com> References: <028e01c1cb33$36de8d50$020aa8c0@aims.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Mar 14), Dag-Erling Smorgrav said: > "Chris Knight" writes: > > The patch is OK, except you've sent it to the wrong list. Send it > > to dev@ccvs.cvshome.org and see what they think. > > Does anyone seriously believe that CVS is still being maintained? Browsing the source tree at cvsweb.org, I see about 2 commits/month to the tree, so, yes, just barely. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 12: 5:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 3D12237B400; Thu, 14 Mar 2002 12:05:43 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2EK5ft7145108; Thu, 14 Mar 2002 15:05:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200203100456.g2A4u2j01429@mass.dis.org> References: <200203100456.g2A4u2j01429@mass.dis.org> Date: Thu, 14 Mar 2002 15:05:40 -0500 To: Michael Smith , Luigi Rizzo From: Garance A Drosihn Subject: Re: For review: machdep.bootdev sysctl (for i386) Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:56 PM -0800 3/9/02, Michael Smith wrote: >Luigi wrote: > > Looking at a way to determine the boot device from > > userland, I have come to the conclusion that the most > > reasonable way is to export to userland whatever > > information the kernel has (and this is machine > > dependent, sorry!), and let some userland program > > (getbootdev(1)) convert it into a reasonable device > > name. > >What do you mean by "boot device"? > >The device from which the initial bootstrap was loaded? >The device from which the loader was loaded? The device >from which the kernel was loaded? In thinking some more about what I was hoping for, what I want is really the "rootdev" value. For instance, I want to be able to duplicate a bunch of partitions to a second set of partitions, and I want to have a different /etc/fstab picked during the bootup-process based on which partition I am booting off of. In my case, I would be doing simple booting of the partition, so bootdev and rootdev and any-other-initial-dev would all be the same value. But strictly-speaking, I imagine rootdev is really what I am looking for. Is that something which could be done? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13: 0:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id AB38037B400; Thu, 14 Mar 2002 13:00:24 -0800 (PST) Received: from pool0226.cvx22-bradley.dialup.earthlink.net ([209.179.198.226] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lcKh-0003cQ-00; Thu, 14 Mar 2002 13:00:19 -0800 Message-ID: <3C910F51.7AB7199E@mindspring.com> Date: Thu, 14 Mar 2002 13:00:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen McKay Cc: Dag-Erling Smorgrav , arch@freebsd.org, obrien@freebsd.org Subject: Re: Unmoronify CVS References: <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <200203141420.g2EEKLP15630@dungeon.home> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stephen McKay wrote: > On Wednesday, 13th March 2002, Dag-Erling Smorgrav wrote: > >To summarize, val-tags saves a little time in a small number of cases, > >is useless in most cases, and outright harmful in many common cases. > > Val-tags has caused me nothing but irritation. It has never assisted > me in any way. It deserves to die. Who here is helped by val-tags? > It seems to be just plain wrong from the day it was added. It has saved me from tag typos on a slow link that would have otherwise deleted large chunks of my local source tree. Because of the slow link, recovering from this deletion would have required considerable time. I think people are seriously glossing over the fact that FreeBSD is used as a platform for other projects, which allow AnonCVS, and face this deletion problem. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13:17:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 5C19E37B42B for ; Thu, 14 Mar 2002 13:16:52 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020314211652.BROF1147.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Thu, 14 Mar 2002 21:16:52 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g2ELGps41881 for ; Thu, 14 Mar 2002 13:16:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id B9CBE38CC; Thu, 14 Mar 2002 13:16:46 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS In-Reply-To: Date: Thu, 14 Mar 2002 13:16:46 -0800 From: Peter Wemm Message-Id: <20020314211646.B9CBE38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > --=-=-= > > Any objections to the attached patch? Yes. Do not compile this choice in. Make it runtime configurable like the rest of the CVSROOT/config stuff so that we can send it back to the cvs folks. val-tags is a useful feature (even if flawed), just not for freebsd's cvs tree. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13:19:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AA07F37B442 for ; Thu, 14 Mar 2002 13:19:04 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7D55E5347; Thu, 14 Mar 2002 22:19:02 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020314211646.B9CBE38CC@overcee.wemm.org> From: Dag-Erling Smorgrav Date: 14 Mar 2002 22:19:01 +0100 In-Reply-To: <20020314211646.B9CBE38CC@overcee.wemm.org> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: > val-tags is a useful feature (even if flawed) Please - and I mean this question seriously - explain to me what value it has, because I sure can't figure it out. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13:34:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id E61E737B41A; Thu, 14 Mar 2002 13:34:17 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 712D75347; Thu, 14 Mar 2002 22:34:16 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Wemm Cc: Stephen McKay , arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020314212012.9263E38CC@overcee.wemm.org> From: Dag-Erling Smorgrav Date: 14 Mar 2002 22:34:15 +0100 In-Reply-To: <20020314212012.9263E38CC@overcee.wemm.org> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: > The point of it is a speedup when you do have a complete list of known > tags. Then tags should be added to val-tags when they're laid down, and possibly removed when they're deleted (though that would be harder to get right). Otherwise it's just useless. And freefall's val-tags should be included in the cvs-all collection. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13:45: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id D36DE37B404; Thu, 14 Mar 2002 13:45:01 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020314214501.BZVQ2626.rwcrmhc51.attbi.com@peter3.wemm.org>; Thu, 14 Mar 2002 21:45:01 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g2ELKCs41907; Thu, 14 Mar 2002 13:20:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 9263E38CC; Thu, 14 Mar 2002 13:20:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen McKay Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Unmoronify CVS In-Reply-To: <200203141420.g2EEKLP15630@dungeon.home> Date: Thu, 14 Mar 2002 13:20:12 -0800 From: Peter Wemm Message-Id: <20020314212012.9263E38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stephen McKay wrote: > On Wednesday, 13th March 2002, Dag-Erling Smorgrav wrote: > > >To summarize, val-tags saves a little time in a small number of cases, > >is useless in most cases, and outright harmful in many common cases. > > Val-tags has caused me nothing but irritation. It has never assisted > me in any way. It deserves to die. Who here is helped by val-tags? > It seems to be just plain wrong from the day it was added. val-tags does not work with distributed repositories, but it does work for non-distributed repos. The point of it is a speedup when you do have a complete list of known tags. It is there to stop your checked out tree geting trashed when you accidently type cvs up -r RELENG-4 (ie: misspelled). If val-tags does not list it, then it does an exhaustive search first. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 13:51: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B3DEF37B41E for ; Thu, 14 Mar 2002 13:51:03 -0800 (PST) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2ELp2lv071379 for ; Thu, 14 Mar 2002 13:51:04 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2ELnlI7071368 for arch@FreeBSD.ORG; Thu, 14 Mar 2002 13:49:47 -0800 (PST) Date: Thu, 14 Mar 2002 13:49:47 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020314134947.A71343@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200203141420.g2EEKLP15630@dungeon.home> <20020314212012.9263E38CC@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020314212012.9263E38CC@overcee.wemm.org>; from peter@wemm.org on Thu, Mar 14, 2002 at 01:20:12PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 14, 2002 at 01:20:12PM -0800, Peter Wemm wrote: > val-tags does not work with distributed repositories, but it does work > for non-distributed repos. Sounds like maybe DES should add a global CVS flag (i.e. cvs -V) that turns off the val-tags processing rather than just diking it out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 18:15:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7D2F237B402 for ; Thu, 14 Mar 2002 18:15:51 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020315021551.LGBD2626.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Fri, 15 Mar 2002 02:15:51 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g2F2Fos43006 for ; Thu, 14 Mar 2002 18:15:50 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id B8F8F38CC; Thu, 14 Mar 2002 18:15:50 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS In-Reply-To: Date: Thu, 14 Mar 2002 18:15:50 -0800 From: Peter Wemm Message-Id: <20020315021550.B8F8F38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Peter Wemm writes: > > val-tags is a useful feature (even if flawed) > > Please - and I mean this question seriously - explain to me what value > it has, because I sure can't figure it out. Somebody got annoyed enough that a typo on a tag removed every file from the client, so cvs got modified to actively look for tags before "activating them". peter@freefall[5:43pm]~/work/ls-107> ls CVS/ cmp.c lomac.c ls.1 ls.h util.c Makefile extern.h lomac.h ls.c print.c peter@freefall[5:43pm]~/work/ls-108> cvs up -r RELNG_4 cvs [update aborted]: no such tag RELNG_4 In this case, it searched every file in src/bin/ls/* (and any descendants if they existed) and conclusively found that RELNG_4 didn't exist, and therefore it wasn't going to switch my client to that incorrect tag. But that would be slow if it had to recursively search for RELENG_4 each time you did a 'cvs up -r RELENG_4' in /usr/src, so they added a cache. I do not recall whether it aborts the search on the first match, or if it searches everything. I believe it is the latter (ie: if there is no val-tags match, it will search the entire tree). Once the client validates a tag by searching for it, it stores it in the val-tags file. Next time around, it will skip the search because the tag is known to exist. The problem with removing val-tags is that cvs will now search *always* before doing an update. Effectively, you will be condeming every end-user to an exhaustive search each time they do a cvs update -r RELENG_4 cd src/sys cvs up -r RELENG_4 ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 15560354 Mar 14 17:55 ktrace.out rm "RELENG_4" from val-tags on freefall ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 30356403 Mar 14 17:55 foo.out ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 15560711 Mar 14 17:55 foo2.out rm "RELENG_4" from val-tags on freefall ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 30356761 Mar 14 17:56 foo3.out ie: if the RELENG_4 tag doesn't exist in val-tags, there is twice as much syscall activity, because the ncvs tree is scanned *twice* instead of once. The first is to see if RELENG_4 exists, the second entire scan is to update it. Note that my checked out tree is in sync already, no actual updates happened. You are looking solely at the ncvs/* scanning activity. If my memory serves correctly, the reason why the tag search is exhaustive rather than stops at the first match, is because it uses common scanning code for all consumers. Looking over your patch, it seems as though it skips the recursive scan. Is this correct? I could live with that, but if it going to do the recursive check each time, then no way :-). It looks like the worst case is that if you accidently do this: cd /usr/src; cvs up -r RELNG_4 then you'll end up with an empty tree, right? Again, if memory serves me correctly, the reason this was added in the first place was because if you had a 500MB checked out *remote* cvs tree, a simple typo on the "cvs up -r" line would cost a hell of a lot of network traffic to recover from. I know this has saved my backside at least twice with the gcc and bintuils anoncvs trees and once with mozilla. It takes forever to checkout and I'd hate to blow it away as a result of an typo. Secondly, why not export val-tags via cvsup? because if nobody has referenced a given tag on freefall, then each time the user does a 'cvs update' locally to that given tag, then cvsup will remove the cached "validated" local tag, and the end user will be forced to do an exhaustive scan again. As a footnote, you should have gone to MAINTAINER rather than arch first. If you add in a CVSROOT/config file check and make tag_check_valid() immediately return if the config file specifies it "off", then I'm happy. We could run with that on freefall. (assuming that it skips the recursion check and assumes that all tags are valid). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 18:29:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C203F37B400 for ; Thu, 14 Mar 2002 18:29:37 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 79C725347; Fri, 15 Mar 2002 03:29:36 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS References: <20020315021550.B8F8F38CC@overcee.wemm.org> From: Dag-Erling Smorgrav Date: 15 Mar 2002 03:29:35 +0100 In-Reply-To: <20020315021550.B8F8F38CC@overcee.wemm.org> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: > But that would be slow if it had to recursively search for RELENG_4 each > time you did a 'cvs up -r RELENG_4' in /usr/src, so they added a cache. I > do not recall whether it aborts the search on the first match, or if it > searches everything. I believe it is the latter (ie: if there is no > val-tags match, it will search the entire tree). Yep, even if it finds the tag in the very first file. > The problem with removing val-tags is that cvs will now search *always* > before doing an update. Effectively, you will be condeming every end-user > to an exhaustive search each time they do a cvs update -r RELENG_4 No - my patch disables the entire tag-checking code. > If my memory serves correctly, the reason why the tag search is exhaustive > rather than stops at the first match, is because it uses common scanning > code for all consumers. Correct. > Looking over your patch, it seems as though it skips the recursive scan. > Is this correct? I could live with that, but if it going to do the > recursive check each time, then no way :-). It looks like the worst > case is that if you accidently do this: cd /usr/src; cvs up -r RELNG_4 > then you'll end up with an empty tree, right? Any sensible person would discover his mistake and abort the update long before that, and cvs does not remove modified files, so no real harm is done. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 14 18:38:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from eudoramail.com (netturbo3.cscoms.com [202.183.214.4]) by hub.freebsd.org (Postfix) with SMTP id 0E41237B439 for ; Thu, 14 Mar 2002 18:35:12 -0800 (PST) From: "Moissanite" To: Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 15 Mar 2002 09:39:03 +0700 Reply-To: "Moissanite" Content-Transfer-Encoding: 8bit Message-Id: <20020315023513.0E41237B439@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Moissanite: More Fire and Brilliance
The Truth About Moissanite
 
Fact - Moissanite delivers more fire, brilliance and luster than any other hard jewel on Earth.
This unretouched photograph supports the adage that "a picture is worth a thousand words". Here, a light source over a similar sized moissanite and diamond placed in shallow water clearly shows the superior fire and brilliance of this unique new jewel. And the picture is supported by measurable facts: the GIA publishes the dispersion (fire) of created moissanite at 0.104, refractive index (brilliance) at 2.65 to 2.69, and luster at 20.4%. No other hard jewel measures up, not even a fine diamond. And only moissanite and diamond are over 9 on the Mohs hardness scale. Moissanite jewels created by Charles & Colvard are available in all popular shapes and sizes. 

www.moissanitesource.com is the place to buy moissanite jewelry on the internet. Buy with confidence at the best prices in the world. 
 
Moissanite Created By Charles & Colvard
 

Moissanite created by Charles & Colvard is a unique jewel, not a synthetic diamond.

Moissanite Source is an authorized distributor of Moissanite.

 

If you wish to stop receiving these occasional mailings, simply reply to this email with the word "REMOVE" in
the subject line and we will remove your name and email address from our database.
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 0:48:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from postoffice.aims.com.au (eth0.lnk.aims.com.au [203.31.73.253]) by hub.freebsd.org (Postfix) with ESMTP id E014837B402 for ; Fri, 15 Mar 2002 00:48:31 -0800 (PST) Received: from postoffice.aims.com.au (nts-ts1.aims.private [192.168.10.2]) by postoffice.aims.com.au with ESMTP id g2F8mUW71445 for ; Fri, 15 Mar 2002 19:48:30 +1100 (EST) (envelope-from chris@aims.com.au) Received: from ntsts1 by aims.com.au with SMTP (MDaemon.v3.5.3.R) for ; Fri, 15 Mar 2002 19:47:36 +1100 Reply-To: From: "Chris Knight" To: Cc: Subject: RE: Unmoronify CVS Date: Fri, 15 Mar 2002 19:47:34 +1100 Message-ID: <032e01c1cbfe$0dc60ee0$020aa8c0@aims.private> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Return-Path: chris@aims.com.au X-MDaemon-Deliver-To: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Howdy, > -----Original Message----- > From: owner-freebsd-arch@FreeBSD.ORG > [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of > Dag-Erling Smorgrav > Sent: Thursday, 14 March 2002 23:01 > To: chris@aims.com.au > Cc: arch@FreeBSD.ORG > Subject: Re: Unmoronify CVS > > > "Chris Knight" writes: > > The patch is OK, except you've sent it to the wrong list. Send it to > > dev@ccvs.cvshome.org and see what they think. > > Does anyone seriously believe that CVS is still being maintained? > > DES If you think that CVS isn't being maintained to your satisfaction, then add the patch to a port of cvs, like I mentioned in my previous message. I don't see why the rest of us have to be inflicted with your patch just because you don't like the default behaviour of cvs and you have commit privileges on the FreeBSD repository. Stop being lazy and do it the right way. There are guidelines for contrib software and I don't think your patch meets the spirit of those guidelines. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 7:35:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 938E137B449 for ; Fri, 15 Mar 2002 07:34:31 -0800 (PST) Received: (qmail 23947 invoked from network); 15 Mar 2002 15:34:30 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Mar 2002 15:34:30 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2FFYuv39818; Fri, 15 Mar 2002 10:34:57 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 15 Mar 2002 10:34:32 -0500 (EST) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: Unmoronify CVS Cc: arch@FreeBSD.ORG, Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 15-Mar-2002 Dag-Erling Smorgrav wrote: > Peter Wemm writes: >> But that would be slow if it had to recursively search for RELENG_4 each >> time you did a 'cvs up -r RELENG_4' in /usr/src, so they added a cache. I >> do not recall whether it aborts the search on the first match, or if it >> searches everything. I believe it is the latter (ie: if there is no >> val-tags match, it will search the entire tree). > > Yep, even if it finds the tag in the very first file. > >> The problem with removing val-tags is that cvs will now search *always* >> before doing an update. Effectively, you will be condeming every end-user >> to an exhaustive search each time they do a cvs update -r RELENG_4 > > No - my patch disables the entire tag-checking code. > >> If my memory serves correctly, the reason why the tag search is exhaustive >> rather than stops at the first match, is because it uses common scanning >> code for all consumers. > > Correct. > >> Looking over your patch, it seems as though it skips the recursive scan. >> Is this correct? I could live with that, but if it going to do the >> recursive check each time, then no way :-). It looks like the worst >> case is that if you accidently do this: cd /usr/src; cvs up -r RELNG_4 >> then you'll end up with an empty tree, right? > > Any sensible person would discover his mistake and abort the update > long before that, and cvs does not remove modified files, so no real > harm is done. Not if you do a cvs up -rFOO and then go to sleep only to wake up in the morning and now need to cvs up a whole big tree over your 28.8k dialup link. :) Remember, the cvs binary in the tree is used by more than just FreeBSD developers doing FreeBSD development. Add a command line option or config file option and submit it to the cvshome folks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 8:31: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.bsdhome.com (rdu25-2-113.nc.rr.com [24.25.2.113]) by hub.freebsd.org (Postfix) with ESMTP id 46BB137B402 for ; Fri, 15 Mar 2002 08:31:00 -0800 (PST) Received: from neutrino.bsdhome.com (jupiter [192.168.220.13]) by smtp.bsdhome.com (8.11.3nb1/8.11.4) with ESMTP id g2FGUxd03503 for ; Fri, 15 Mar 2002 11:30:59 -0500 (EST) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.11.6/8.11.6) id g2FGUro48766; Fri, 15 Mar 2002 11:30:53 -0500 (EST) (envelope-from bsd) Date: Fri, 15 Mar 2002 11:30:53 -0500 From: Brian Dean To: freebsd-arch@freebsd.org Subject: uthread patch to correct the return code for pthread_rwlock_tryXXlock() Message-ID: <20020315113053.A48681@neutrino.bsdhome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, The man pages for pthread_rwlock_trywrlock() and pthread_rwlock_tryrdlock() say that EBUSY is returned when the calling thread is not able to aquire the lock without blocking. However, the actual functions return EWOULDBLOCK. I believe the man page is correct (Solaris and others, at least, return EBUSY). Unless there are objections, I plan on committing the attached patch to correct the code. Thanks, -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com Index: uthread_rwlock.c =================================================================== RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_rwlock.c,v retrieving revision 1.6 diff -u -r1.6 uthread_rwlock.c --- uthread_rwlock.c 10 Apr 2001 04:19:20 -0000 1.6 +++ uthread_rwlock.c 15 Mar 2002 16:21:54 -0000 @@ -209,7 +209,7 @@ /* give writers priority over readers */ if (prwlock->blocked_writers || prwlock->state < 0) - ret = EWOULDBLOCK; + ret = EBUSY; else if (prwlock->state == MAX_READ_LOCKS) ret = EAGAIN; /* too many read locks acquired */ else @@ -245,7 +245,7 @@ return(ret); if (prwlock->state != 0) - ret = EWOULDBLOCK; + ret = EBUSY; else /* indicate we are locked for writing */ prwlock->state = -1; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 8:45:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A573237B42A for ; Fri, 15 Mar 2002 08:45:13 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g2FGj6Xx001643; Fri, 15 Mar 2002 11:45:06 -0500 (EST) Date: Fri, 15 Mar 2002 11:45:06 -0500 (EST) From: Daniel Eischen To: Brian Dean Cc: freebsd-arch@FreeBSD.ORG Subject: Re: uthread patch to correct the return code for pthread_rwlock_tryXXlock() In-Reply-To: <20020315113053.A48681@neutrino.bsdhome.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 15 Mar 2002, Brian Dean wrote: > Hi, > > The man pages for pthread_rwlock_trywrlock() and > pthread_rwlock_tryrdlock() say that EBUSY is returned when the calling > thread is not able to aquire the lock without blocking. However, the > actual functions return EWOULDBLOCK. I believe the man page is > correct (Solaris and others, at least, return EBUSY). > > Unless there are objections, I plan on committing the attached patch > to correct the code. Yes, it should be EBUSY. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 19:24:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2608F37B402; Fri, 15 Mar 2002 19:24:34 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 306375347; Sat, 16 Mar 2002 04:24:31 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: HEADS UP: caddr_t sweep From: Dag-Erling Smorgrav Date: 16 Mar 2002 04:24:31 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm preparing a sweep that will remove incorrect caddr_t casts in copy{in,out,str,instr}(), bcopy() and bzero() calls in the kernel. This will affect 650 to 700 lines of code, leaving approximately 2,000 lines of code containing caddr_t casts, most of which are probably equally bogus but will take more work to eradicate. This will probably cause merge conflicts for some of you. I apologize for the inconvenience. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 15 20:38:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B107E37B400 for ; Fri, 15 Mar 2002 20:38:08 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g2G4c7i47113; Fri, 15 Mar 2002 21:38:07 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g2G4c6L62627; Fri, 15 Mar 2002 21:38:07 -0700 (MST) (envelope-from imp@village.org) Date: Fri, 15 Mar 2002 21:37:57 -0700 (MST) Message-Id: <20020315.213757.117909745.imp@village.org> To: des@ofug.org Cc: arch@FreeBSD.ORG Subject: Re: HEADS UP: caddr_t sweep From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Dag-Erling Smorgrav writes: : I'm preparing a sweep that will remove incorrect caddr_t casts in : copy{in,out,str,instr}(), bcopy() and bzero() calls in the kernel. : This will affect 650 to 700 lines of code, leaving approximately 2,000 : lines of code containing caddr_t casts, most of which are probably : equally bogus but will take more work to eradicate. : : This will probably cause merge conflicts for some of you. I apologize : for the inconvenience. i'd like to take a look at this patch before you commit it please. There are many driver uses of bcopy that are non-obvious and likely should be bus_space_read instead... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 4: 1:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8A1D537B402 for ; Sat, 16 Mar 2002 04:01:43 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA29159; Sat, 16 Mar 2002 22:59:02 +1100 Date: Sat, 16 Mar 2002 23:00:38 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , Subject: Re: HEADS UP: caddr_t sweep In-Reply-To: <20020315.213757.117909745.imp@village.org> Message-ID: <20020316225716.I28305-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 15 Mar 2002, M. Warner Losh wrote: > In message: > Dag-Erling Smorgrav writes: > : I'm preparing a sweep that will remove incorrect caddr_t casts in > : copy{in,out,str,instr}(), bcopy() and bzero() calls in the kernel. > ... > > i'd like to take a look at this patch before you commit it please. > There are many driver uses of bcopy that are non-obvious and likely > should be bus_space_read instead... Maybe limit it to copy* and other userland interfaces (mmap?) then. There are also some bcopies which should be struct assignments. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 4:11: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6554937B402 for ; Sat, 16 Mar 2002 04:10:56 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2GCAoUD037368; Sat, 16 Mar 2002 13:10:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: "M. Warner Losh" , des@ofug.org, arch@FreeBSD.ORG Subject: Re: HEADS UP: caddr_t sweep In-Reply-To: Your message of "Sat, 16 Mar 2002 23:00:38 +1100." <20020316225716.I28305-100000@gamplex.bde.org> Date: Sat, 16 Mar 2002 13:10:50 +0100 Message-ID: <37367.1016280650@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020316225716.I28305-100000@gamplex.bde.org>, Bruce Evans writes: >On Fri, 15 Mar 2002, M. Warner Losh wrote: > >> In message: >> Dag-Erling Smorgrav writes: >> : I'm preparing a sweep that will remove incorrect caddr_t casts in >> : copy{in,out,str,instr}(), bcopy() and bzero() calls in the kernel. >> ... >> >> i'd like to take a look at this patch before you commit it please. >> There are many driver uses of bcopy that are non-obvious and likely >> should be bus_space_read instead... > >Maybe limit it to copy* and other userland interfaces (mmap?) then. >There are also some bcopies which should be struct assignments. I would like the argument in ioctl funtions to either become a void * argument or for caddr_t to become a void *. I did a testshot on LINT with caddr_t as a void * and the fallout is surprisingly moderate. That said, any journey starts with the first step so rather than hold up DES, I think DES should go ahead, and Warner can look for busspace_ improvements in a separate commit and Bruce can look for struct assignments in a separate sweep. I suspect that DES' patch is pretty much program generated anyway, so I don't see a value to "polluting" it with manual fixups. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 7:58: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 39B8237B400; Sat, 16 Mar 2002 07:58:00 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g2GFvqt45950; Sat, 16 Mar 2002 10:57:52 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200203161557.g2GFvqt45950@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Bruce Evans , "M. Warner Losh" , des@ofug.org, arch@FreeBSD.ORG Subject: Re: HEADS UP: caddr_t sweep In-Reply-To: Your message of "Sat, 16 Mar 2002 13:10:50 +0100." <37367.1016280650@critter.freebsd.dk> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Mar 2002 10:57:51 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > I would like the argument in ioctl funtions to either become > a void * argument or for caddr_t to become a void *. Pointer arithmetic is defined for char *. The void type has no size and therefore pointer arithmetic is not defined for it (except as a hack in GCC...). The problem with caddr_t being a char * is that C does not actually require that every pointer can be coerced to/from char *, but it does require that for void *. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 8:39:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id F41A337B405 for ; Sat, 16 Mar 2002 08:35:07 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EAFD85347; Sat, 16 Mar 2002 17:35:03 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: Bruce Evans , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: HEADS UP: caddr_t sweep References: <37367.1016280650@critter.freebsd.dk> From: Dag-Erling Smorgrav Date: 16 Mar 2002 17:35:02 +0100 In-Reply-To: <37367.1016280650@critter.freebsd.dk> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > I suspect that DES' patch is pretty much program generated anyway, > so I don't see a value to "polluting" it with manual fixups. I did the rough work with a Perl one-liner, but manual fixups will be required anyway. This is going to take some time, but I wanted the heads-up to go out early. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 12:22:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 8BC5237B425 for ; Sat, 16 Mar 2002 12:22:55 -0800 (PST) Received: from pool0236.cvx21-bradley.dialup.earthlink.net ([209.179.192.236] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16mKhN-0003GM-00; Sat, 16 Mar 2002 12:22:41 -0800 Message-ID: <3C93A97E.97362250@mindspring.com> Date: Sat, 16 Mar 2002 12:22:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: "M. Warner Losh" , des@ofug.org, arch@FreeBSD.ORG Subject: Re: HEADS UP: caddr_t sweep References: <20020316225716.I28305-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Fri, 15 Mar 2002, M. Warner Losh wrote: > > In message: > > Dag-Erling Smorgrav writes: > > : I'm preparing a sweep that will remove incorrect caddr_t casts in > > : copy{in,out,str,instr}(), bcopy() and bzero() calls in the kernel. > > ... > > > > i'd like to take a look at this patch before you commit it please. > > There are many driver uses of bcopy that are non-obvious and likely > > should be bus_space_read instead... > > Maybe limit it to copy* and other userland interfaces (mmap?) then. > There are also some bcopies which should be struct assignments. This issue was mentioned at the BSDCon Developer's Summit as the main issue in the limitation of Alpha systems to 2G of physical RAM. I think it's important to address this issue. Right now, there is a similar limitation on Intel at 4G, for 32 bit PCI cards, where the bus_space code is not being used to keep the transfers in the low 4G of memory. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 16 13:25:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from park.rambler.ru (park.rambler.ru [217.73.193.2]) by hub.freebsd.org (Postfix) with ESMTP id 2796437B436 for ; Sat, 16 Mar 2002 13:25:51 -0800 (PST) Received: from is (is.stack.net [217.73.193.40]) by park.rambler.ru (8.11.4/8.9.3) with ESMTP id g2GLPod60535 for ; Sun, 17 Mar 2002 00:25:50 +0300 (MSK) (envelope-from is@rambler-co.ru) Date: Sun, 17 Mar 2002 00:25:50 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: freebsd-arch@FreeBSD.ORG Subject: kqueue EV_POLL proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Suppose event-driven server that have forked to several processes. Each process listens on the same one or several ports. All sockets, listening and usual, are non-blocking and checked via single kevent() call. If several processes pass listening sockets to kevent() and some of them ready then all these processes will get event than will call accept() and many of them will get EAGAIN. There is workaround for this situation - we can use mutex (or token) to allow passing listening sockets to kevent(). But before (or after) each iteration we need to delete previous not ready listening sockets if we have not acquired mutex (or token). Code is following: ---- if (accept_mutex_locked = accept_mutex_trylock()) for each listening sockets EV_SET(socket, EV_READ, EV_ADD|EV_ONESHOT); else for each PREVIOUS NOT ready listening sockets EV_SET(socket, EV_READ, EV_DELETE); kevent(changelist, eventlist); for each ready listening sockets accept() if (accept_mutex_locked) accept_mutex_unlock(); process other events ---- I think that kqueue should have EV_POLL action (or flag) with following sense - it's like EV_ONESHOT flag but if filter right now has no event then it's removed, i.e. this filter lives for single kevent() call. Than code can be clearer: ---- if (accept_mutex_locked = accept_mutex_trylock()) for each listening sockets EV_SET(socket, EV_READ, EV_POLL); kevent(changelist, eventlist); for each ready listening sockets accept() if (accept_mutex_locked) accept_mutex_unlock(); process other events ---- Here is small tested patch made on FreeBSD-4.3. It can be downloaded from http://sysoev.ru/freebsd/patch.ev_poll.txt ---- --- src/sys/sys/event.h Mon Feb 26 07:23:21 2001 +++ src/sys/sys/event.h Sat Mar 16 22:56:54 2002 @@ -61,6 +61,7 @@ #define EV_DELETE 0x0002 /* delete event from kq */ #define EV_ENABLE 0x0004 /* enable event */ #define EV_DISABLE 0x0008 /* disable event (not reported) */ +#define EV_POLL 0x0040 /* poll event */ /* flags */ #define EV_ONESHOT 0x0010 /* only report one occurrence */ --- src/sys/kern/kern_event.c Mon Feb 26 07:23:15 2001 +++ src/sys/kern/kern_event.c Sat Mar 16 22:52:19 2002 @@ -414,7 +414,7 @@ } } - if (kn == NULL && ((kev->flags & EV_ADD) == 0)) { + if (kn == NULL && ((kev->flags & (EV_ADD|EV_POLL)) == 0)) { error = ENOENT; goto done; } @@ -422,7 +422,7 @@ /* * kn now contains the matching knote, or NULL if no match */ - if (kev->flags & EV_ADD) { + if (kev->flags & (EV_ADD|EV_POLL)) { if (kn == NULL) { kn = knote_alloc(); @@ -465,6 +465,11 @@ s = splhigh(); if (kn->kn_fop->f_event(kn, 0)) KNOTE_ACTIVATE(kn); + else if (kev->flags & EV_POLL) { + kn->kn_fop->f_detach(kn); + knote_drop(kn, p); + goto done; + } splx(s); } else if (kev->flags & EV_DELETE) { @@ -585,7 +590,7 @@ *kevp = kn->kn_kevent; kevp++; nkev++; - if (kn->kn_flags & EV_ONESHOT) { + if (kn->kn_flags & (EV_ONESHOT|EV_POLL)) { kn->kn_status &= ~KN_QUEUED; kq->kq_count--; splx(s); ---- Igor Sysoev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message