Re: ACPI project progress report
Mike Smith wrote: On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Andrew Reilly" writes: : That sounds way too hard. Why not restrict suspend activity to : user-level processes and bring the kernel/drivers back up through : a regular boot process? At least that way the hardware and drivers : will know what they are all up to, even if some of it has changed : in the mean time. Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. Why then brand commercial vendors have such capability in their "server-class" operating system for a long time? Particularly HP's PA-RISC servers does have it, at least I remember such feature in the old 30MHz systems which I managed several years ago (the systems was shipped with small internal battery, which in the case of power failure was used to dump system to the disk). -Maxim. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
In message [EMAIL PROTECTED], Anatoly Vorobey writes: On Mon, Jun 19, 2000 at 01:42:33PM +0200, Adrian Chadd wrote: * the rest of the system treats ffs filesystems as "ufs". Besides the fact that I dislike this, I decided against the NetBSD way of Isn't it time, anyway, to fix this? This legacy dates from long time ago; e.g. the log message in the kernel code which declares the ffs module (it reads: `` Call ffs ``ufs'' for the benefit of poor, confused user-land programs. '') dates to September '94. Are there any arguments against changing the filesystem type name to 'ffs' in the kernel and in the userland? If not, I'll volunteer to find all kernel/userland uses I can and provide a diff. The correct way to do this is to make it accept both for some limited time, and then warn about the obsolete for a few months, then discontinue it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Am I the only person who miss a brief document which tells what the outcome of the meeting was ? Can we get to see the slides ? Audio ? Video ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
On Tue, Jun 20, 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Anatoly Vorobey writes: On Mon, Jun 19, 2000 at 01:42:33PM +0200, Adrian Chadd wrote: * the rest of the system treats ffs filesystems as "ufs". Besides the fact that I dislike this, I decided against the NetBSD way of Isn't it time, anyway, to fix this? This legacy dates from long time ago; e.g. the log message in the kernel code which declares the ffs module (it reads: `` Call ffs ``ufs'' for the benefit of poor, confused user-land programs. '') dates to September '94. Are there any arguments against changing the filesystem type name to 'ffs' in the kernel and in the userland? If not, I'll volunteer to find all kernel/userland uses I can and provide a diff. The correct way to do this is to make it accept both for some limited time, and then warn about the obsolete for a few months, then discontinue it. Thats one thing that has always bugged me too, but I was thinking about fixing that after the fsck wrappers. Thinking in hindsight, it might be easier to change ufs to ffs in the fsck wrapper right now, and then once the wrapper is stable worry about moving ufs to ffs. I would rather not have both happen right now, as doing ufs-ffs requires kernel changes and userland (mount) changes. Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the [EMAIL PROTECTED]rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In [EMAIL PROTECTED], Poul-Henning Kamp wrote: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? Who was there, anyway? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000 10:27:08 +0300 Maxim Sobolev wrote: +-- | Mike Smith wrote: | | The real issue here is persistent system state across the S4 suspend; ie. | leaving applications open, etc. IMO this isn't really something worth a | lot of effort to us, and it has a lot of additional complications for a | "server-class" operating system in that you have to worry about network | connections from other systems, not just _to_ other systems. | | Why then brand commercial vendors have such capability in their | "server-class" operating system for a long time? Particularly HP's PA-RISC | servers does have it, at least I remember such feature in the old 30MHz | systems which I managed several years ago (the systems was shipped with | small internal battery, which in the case of power | failure was used to dump system to the disk). | | -Maxim. +-- On very old systems with ferrite core memory the whole "core" simply retained whatever was running at the time of a power out. When power was restored the program just started ticking from where it left off with no loss of state. Later attempts at preserving "core" state over power out involved batteries for memory, processor registers and for peripheral buffers. As buffer sizes in controllers grew and processor memory became more volatile it became harder and harder to simply recover that way. The system always came up from bootstrap and never attempted to automatically recover to a previously running system state. These days we tend to think of a "core dump" as a diagnostic tool and not as a state image to be recovered as a part of powering up the computer. But does it have to be that way? Perhaps I am nieve but it seems to me that many "server class" systems could make great use of a hibernation mode which would allow the system to be suspended to wait for some critical event to pass and then to start running exactly as they were at the time of the suspend signal. At worst this could only minimize the recovery time experienced by the server. -- Chris Fedde 303 773 9134 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
On Mon, 19 Jun 2000, Adrian Chadd wrote: Watching my machine boot, the parallel nature of this fsck is now confusing the output, eg: Automatic reboot in progress... ** /dev/ad0s1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes de0: enabling 10baseT port ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1506 files, 57594 used, 10837 free (285 frags, 1319 blocks, 0.4% fragmentation) ** /dev/amrd0a ** /dev/ad0s1f ** Last Mounted on /cache ** Phase 1 - Check Blocks and Sizes ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ... Would people object to fsck printing out either the mountpoint or the devname (where appropriate) prepending each line of fsck_ffs ? Yes, if it is down for anything except the parallel (preen) case. How did you get all the above output? The current fsck doesn't print any "Phase" messages for the preen case. When these messages are printed, interactive input is required except in the -y case, so the processes can't be run in parallel. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
Marc van Woerkom [EMAIL PROTECTED] writes: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. # mt -f /dev/rsa0 offline # camcontrol eject cd0 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
On Tue, Jun 20, 2000, Bruce Evans wrote: On Mon, 19 Jun 2000, Adrian Chadd wrote: Watching my machine boot, the parallel nature of this fsck is now confusing the output, eg: Automatic reboot in progress... ** /dev/ad0s1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes de0: enabling 10baseT port ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1506 files, 57594 used, 10837 free (285 frags, 1319 blocks, 0.4% fragmentation) ** /dev/amrd0a ** /dev/ad0s1f ** Last Mounted on /cache ** Phase 1 - Check Blocks and Sizes ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ... Would people object to fsck printing out either the mountpoint or the devname (where appropriate) prepending each line of fsck_ffs ? Yes, if it is down for anything except the parallel (preen) case. How did you get all the above output? The current fsck doesn't print any "Phase" messages for the preen case. When these messages are printed, interactive input is required except in the -y case, so the processes can't be run in parallel. A couple of oversights when I did the code merging. They've been fixed, and I'll throw up a new copy of the source code at the same URL in about an hour. Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the [EMAIL PROTECTED]rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe winmail.dat
subscribe
subscribe Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Updated kame tarball (oops)
Thus spake Mark Huizer ([EMAIL PROTECTED]): the stf is unknown when running config but well :-) But I'll try to compile a kernel this way It's also unknown in our current tree, though stf(4) does exist. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP discussion moving to freebsd-smp
All SMP/FreeBSD/BSDI work should move to the freebsd-smp list. (I've BCC'd this to -current). -- I now have mutexes 99% working in an SP build. I will be making SP (single processor) patch sets available tonight or tomorrow morning. (99% == I can boot the machine normally but after a while it locks up due to an interrupt nesting issue which I haven't dealt with yet). In order to make an MP build work, we need interrupt threads (either light or heavy weight). Greg, you expressed an interest in doing the light-weight interrupt threads. Do you want me to do the heavy-weight interrupt threads first? It's a lot of nasty assembly and it is a prerequisit for being able to do the light weight interrupt threads. I think once the heavy weight interrupt threads are done that the light weight interrupts can be implemented entirely in C. Right now the SP build works because I am allowing (unthreaded) interrupts to steal the idleproc's context, and that only works because they can get the giant mutex without blocking (remember, the BSDI giant mutex is a blocking mutex, not a spin mutex). In the MP build the interrupts need to be able to block getting the giant mutex which means we need to implement heavy-weight interrupt threads at the very least before we can get anything working, because we are not allowed to block in the idleproc. I believe I have done almost everything necessary to implement heavy weight interrupt threads, including moving the kthreads initialization code to an earlier point in the boot process (so much so that I think the device init stuff can run with working kernel processes rather then with all the delayed-thread stuff). I also think that people can start hacking on the code with the SP build once I fix this last little problem, then I can work on the MP build in parallel. The MP build requires a significant amount of additional work including having to rewrite most of the APIC assembly code (just as I had to rewrite most of the ICU assembly code for the SP build). It's another weekend at least for that. Using the SP build does not exercise all the MP characteristics of the mutexes but it exercises enough that it can be used to vett for dumb mistakes. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Martin Cracauer wrote: In [EMAIL PROTECTED], Poul-Henning Kamp wrote: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? Who was there, anyway? Yeah, those of us who couldn't make it are kinda (to say the least) interested in what was said/decided...!! -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED] Jason Evans writes: : Summary: -current will be destabilized for an extended period (on the order : of months). A tag (not a branch) will be laid down before the initial : checkin, and non-developers should either stick closely to that tag until : the kernel stabilizes, or expect large doses of pain. This tag will be : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning : beforehand. Thanks for the fair warning. Now don't do it. Has core approved this? I don't think so, I've seen nothign from them about it. The instability ni -current for MONTHS is pain not acceptible. We've never really allowed that in the past. A CVS branch would be mcuh better for this sort of thing. I know that's a pain as well, but this is just for SMP people and the rest of us shouldn't have to deal with the pain. I understand your desire to have it all in a working tree, but causing pain for ALL developers for potentially MONTHS isn't a reasonable request. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Am I the only person who miss a brief document which tells what : the outcome of the meeting was ? : : Can we get to see the slides ? : : Audio ? : : Video ? I know that I'd love to see this. Steve Passe also is interested. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due toSMP development)
On Tue, 20 Jun 2000, Warner Losh wrote: I know that I'd love to see this. Steve Passe also is interested. I heard that Greg Lehey was videotaping (he's currently at usenix) and someone else had slides they were going to make available. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWING config changes? : Kernel profiling support
In message [EMAIL PROTECTED] The Hermit Hacker writes: : : that did her, thanks ... should this maybe be mentioned in : /usr/src/UPDATING? I've gotten into the habit of pretty much checking : there first, and saw no mention of this (could be blind too, its happened : before) ... The new hints mechanism is mentioned in UPDATING, but there's not a complete entry/how-to for it. One needs to be written. I've nto had the time to do it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Jason Evans writes: : Summary: -current will be destabilized for an extended period (on the order : of months). A tag (not a branch) will be laid down before the initial : checkin, and non-developers should either stick closely to that tag until : the kernel stabilizes, or expect large doses of pain. This tag will be : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning : beforehand. Thanks for the fair warning. Now don't do it. Has core approved this? I don't think so, I've seen nothign from them about it. I think core has approved in principle, and several core members were present at the meeting (at least peter, dg, gibbs, dfr), that being said, I think we need to see some more concrete info before we pull the lever, just so we know what to expect. The instability ni -current for MONTHS is pain not acceptible. Sorry, Warner, but progress has its price, and this may be it. I understand your desire to have it all in a working tree, but causing pain for ALL developers for potentially MONTHS isn't a reasonable request. I belive the only viable alternative, as CVS branches are generally agreed to be = 25 megasuckage caliber, is to switch the project to use Perforce. Until now at least, we have not done that, because developing open source with a closed source tool has been too much taboo for us to bother, and it would (as far as we know) not work with cvsup. I'm not sure now is the time to do it either. So: No I don't like -current being toast anymore than you do, but I don't think there is a viable alternative. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : I think core has approved in principle, and several core members : were present at the meeting (at least peter, dg, gibbs, dfr), that : being said, I think we need to see some more concrete info before : we pull the lever, just so we know what to expect. I'd like to see an explicit vote saying that current can be broken for months for SP users so the MP work can go in. It has often been said that individual core members do not speak for core. : The instability ni -current for MONTHS is pain not acceptible. : : Sorry, Warner, but progress has its price, and this may be it. I don't think so. I've done all the NEWCARD work in the tree, and it hasn't broken anything else (at least not for more than a few hours when I screwed up). It has been painful for me to do it that way, but I think that some consideration should be given for the transition period for SP users. A few days or weeks I don't have a prblem with, but a few months is flat not acceptible. It is too long. If the code is that green, then some other mechanism needs to be used to facilitate collaberative working. I'd rather see a firm deadline proposed (eg, we'll commit the core on June 26, and will be done by Aug 26) so that I know what to expect rather than having the nebulous a few months phrase kicked around. I expected the newcard stuff to be working in a few months, and it has been about 8 so far. : So: No I don't like -current being toast anymore than you do, but : I don't think there is a viable alternative. Sure we do. They get their patches together, and commit them once they will cuase less pain. There's always alternatives. The issue here is who has to live with the pain. The MP guys could easily use perforce for this and then merge once things are stabilized enough to not impact SP people to the point that things won't be usable. The cam folks did this in the past, and it worked fairly well. Also, what if the new MP core goes in and one or more of the key players all of a sudden have no time to finish this due to unforseen circumstances? Will the tree remain broken while they sort this out? Again, I dont' want to hold up progress, but saying that it must be done this way and I have to put up with it for the sake of progerss is not a good justification. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : I think core has approved in principle, and several core members : were present at the meeting (at least peter, dg, gibbs, dfr), that : being said, I think we need to see some more concrete info before : we pull the lever, just so we know what to expect. I'd like to see an explicit vote saying that current can be broken for months for SP users so the MP work can go in. It has often been said that individual core members do not speak for core. I'm certainly not speaking for core, unless you see me saying so explcitly I never speak officially for core. I just tried to shed some light on the current status as best I knew it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
:: the kernel stabilizes, or expect large doses of pain. This tag will be :: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning :: beforehand. : :Thanks for the fair warning. Now don't do it. Has core approved :this? I don't think so, I've seen nothign from them about it. : :The instability ni -current for MONTHS is pain not acceptible. We've :never really allowed that in the past. A CVS branch would be mcuh :better for this sort of thing. I know that's a pain as well, but this :is just for SMP people and the rest of us shouldn't have to deal with :the pain. : :I understand your desire to have it all in a working tree, but causing :pain for ALL developers for potentially MONTHS isn't a reasonable :request. : :Warner The problem is that the changes are simply too extensive to be able be able to split them off then merge them back into 5.x N months later. Creating another branch will tripple the workload on anyone doing merge work. We knew we'd probably have to do it this way months ago, and Chuck Paterson of BSDI confirmed it when he related his experiences with trying to manage the BSDI 5.x MP stuff as a separate branch. In short, it was a complete disaster, and I have no doubts that trying to manage it as a separate branch in FreeBSD would also result in a complete disaster. We've known this day was coming for ages... ever since Jordan announced the BSDI merger. Jordan and other core members have hinted, intimated, and outright told people that FreeBSD-current would be used for the BSDI merge work. Well, the time is now folks! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
On Tue, Jun 20, 2000 at 08:49:27PM +0200, Poul-Henning Kamp wrote: So: No I don't like -current being toast anymore than you do, but I don't think there is a viable alternative. Not even a seperate repository, as was done (briefly) for newbus? Of course, maybe that was done so briefly because it was painful... -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED] Matthew Dillon writes: : The problem is that the changes are simply too extensive to be able : be able to split them off then merge them back into 5.x N months later. : Creating another branch will tripple the workload on anyone doing : merge work. One could argue that you could merge the changes to FreeBSD 5.X on a daily or weekly basis to that branch so that the branch doesn't get too far out of what. Perforce users do this all the time (cf the cam project). The model that I see is that a branch is created for SMP work, and that you find a volunteer who has access to SMP machines who will merge from current into the SMP branch once a week and boot the resulting kernel. If it works, he commits it, otherwise he resovles the problems. That way the main developers aren't significantly impacted by the merging. I'd be a lot happier if there was an upper bound on the length of time that -current would be unstable, if there was a plan in place on what to do if that timelimit was exceeded, if there was a roadmap I could look at, etc. Right now the vagueness of it all pushes my panic button. I'm trying to get more information so that I know if I should just calm down and it won't be that bad, or if I should pitch a huge fit because it will be too painful to make progress on any other front. Please help me with that. I'd also be happy if I could create a newcard branch off the last stable version of freebsd 5.0-current. That way I could continue my work with others and the instability wouldn't matter. All merging, if any, would be my responsibility. I don't know what the level of pain Of course the same arugment about merging you make could be made for new kernel work. They will either have to live with the pain (which is currently ill-defined at best, knowing what the pain would be would help my confort level), or do their work and then redo it on the new and improved FreeBSD months later. Why should SMP force others to do that? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? This sounds odd at first glance, but it means that others are forced to MFC into the smp branch - if they don't they lose. Anybody that's not confident to be able to merge into the smp branch will simply be in the same position - merge or hold off. They'd also be just as likely to break the smp work with their commits as if the smp work was done in HEAD. :: the kernel stabilizes, or expect large doses of pain. This tag will be :: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning :: beforehand. : :Thanks for the fair warning. Now don't do it. Has core approved :this? I don't think so, I've seen nothign from them about it. : :The instability ni -current for MONTHS is pain not acceptible. We've :never really allowed that in the past. A CVS branch would be mcuh :better for this sort of thing. I know that's a pain as well, but this :is just for SMP people and the rest of us shouldn't have to deal with :the pain. : :I understand your desire to have it all in a working tree, but causing :pain for ALL developers for potentially MONTHS isn't a reasonable :request. : :Warner The problem is that the changes are simply too extensive to be able be able to split them off then merge them back into 5.x N months later. Creating another branch will tripple the workload on anyone doing merge work. We knew we'd probably have to do it this way months ago, and Chuck Paterson of BSDI confirmed it when he related his experiences with trying to manage the BSDI 5.x MP stuff as a separate branch. In short, it was a complete disaster, and I have no doubts that trying to manage it as a separate branch in FreeBSD would also result in a complete disaster. We've known this day was coming for ages... ever since Jordan announced the BSDI merger. Jordan and other core members have hinted, intimated, and outright told people that FreeBSD-current would be used for the BSDI merge work. Well, the time is now folks! -Matt Matthew Dillon [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? I believe that Jason Evans already sent a message summarizing the meeting, and Matt Dillon's webpage gives a pretty good summary of the work too (at http://apollo.backplane.com/FreeBSDSmp/) Can we get to see the slides ? Chuck Patterson presented a bunch of slides (which was actually a .ps file that displayed page by page in gv), so perhaps he could be persuaded to make the entire postscript file available somewhere. Audio ? Video ? After several mishaps, I believe that Greg finally got a video camera up and running for most of the session. I think that it was in PAL format as well. Greg has the tapes, so I assume that after he's done with USENIX, he'll have them available. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
In message [EMAIL PROTECTED], Brian Somers writes: What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? "CVS branches suck" is the reason I belive. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In message [EMAIL PROTECTED], Jonathan Lemon writes: In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? I believe that Jason Evans already sent a message summarizing the meeting, and Matt Dillon's webpage gives a pretty good summary of the work too (at http://apollo.backplane.com/FreeBSDSmp/) But we're not looking for a summary of the meeting, we're looking for all the gory details... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make.conf fix
Hi -current and -ports,
I've noticed something that seems to have been broken for a long time.
In etc/defaults/make.conf we have several MASTER_SITE_* variables which
reference "%SUBDIR%". However, these variables do not work as expected.
So we must fix this discrepancy with the following patch.
Comments?
--
Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+
G+ e- h! r--+++ y?
Index: make.conf
===
RCS file: /extra/cvsroot/src/etc/defaults/make.conf,v
retrieving revision 1.110
diff -u -r1.110 make.conf
--- make.conf 2000/06/17 10:51:47 1.110
+++ make.conf 2000/06/20 21:20:45
@@ -184,22 +184,22 @@
# Some ports use a special variable to point to a collection of
# mirrors of well-known software archives. If you have a mirror close
# to you, uncomment any of the following lines and change it to that
-# address. (Don't remove the "/%SUBDIR%/" part.)
+# address. (Don't remove the "/${MASTER_SITE_SUBDIR}/" part.)
#
# Note: the right hand sides of the following lines are only for your
# information. For a full list of default sites, take a look at
# bsd.port.mk.
#
-#MASTER_SITE_XCONTRIB= ftp://ftp.x.org/contrib/%SUBDIR%/
-#MASTER_SITE_GNU= ftp://prep.ai.mit.edu/pub/gnu/%SUBDIR%/
-#MASTER_SITE_PERL_CPAN=
ftp://ftp.digital.com/pub/plan/perl/CPAN/modules/by-module/%SUBDIR%/
-#MASTER_SITE_TEX_CTAN= ftp://ftp.tex.ac.uk/tex-archive/%SUBDIR%/
-#MASTER_SITE_SUNSITE= ftp://metalab.unc.edu/pub/Linux/%SUBDIR%/
-#MASTER_SITE_KDE= ftp://ftp.kde.org/pub/kde/%SUBDIR%/
-#MASTER_SITE_COMP_SOURCES=
ftp://gatekeeper.dec.com/pub/usenet/comp.sources.%SUBDIR%/
-#MASTER_SITE_GNOME=ftp://ftp.gnome.org/pub/GNOME/sources/%SUBDIR%/
-#MASTER_SITE_AFTERSTEP=ftp://ftp.afterstep.org/%SUBDIR%/
-#MASTER_SITE_WINDOWMAKER= ftp://ftp.windowmaker.org/pub/%SUBDIR%/
+#MASTER_SITE_XCONTRIB= ftp://ftp.x.org/contrib/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_GNU= ftp://prep.ai.mit.edu/pub/gnu/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_PERL_CPAN=
+ftp://ftp.digital.com/pub/plan/perl/CPAN/modules/by-module/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_TEX_CTAN= ftp://ftp.tex.ac.uk/tex-archive/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_SUNSITE= ftp://metalab.unc.edu/pub/Linux/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_KDE= ftp://ftp.kde.org/pub/kde/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_COMP_SOURCES=
+ftp://gatekeeper.dec.com/pub/usenet/comp.sources.${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_GNOME=ftp://ftp.gnome.org/pub/GNOME/sources/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_AFTERSTEP=ftp://ftp.afterstep.org/${MASTER_SITE_SUBDIR}/
+#MASTER_SITE_WINDOWMAKER= ftp://ftp.windowmaker.org/pub/${MASTER_SITE_SUBDIR}/
#
#
# Kerberos IV
Re: HEADS UP: Destabilization due to SMP development
What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? This sounds odd at first glance, but it means that others are forced to MFC into the smp branch - if they don't they lose. Anybody that's not confident to be able to merge into the smp branch will simply be in the same position - merge or hold off. They'd also be just as likely to break the smp work with their commits as if the smp work was done in HEAD. Isn't this the same thing as breaking the head and keeping every thing else (that is the pre-broken 5.0) on a branch... Just sorta rotating the tree a little... And, isn't this the same idea as -stable? If that's all true - I'd suggest that those who really want stability might be better served with the -stable branch for the interim. If you need a totally-brand-new-feature, then MFC that to -stable and get it there... The point of -current is to be breakable - the extent of the breaking isn't known ahead of time. -current can be broken for a long time by simply breaking several small things - say, one a day for several months. The difference here seems to be the forethought in the announcement; which I take as good planning... i.e. instead of being broken for some unknown reasons, we're simply saying that we know it's broken... If you can't live with a broken situation, then I humbly suggest staying with -stable. I suppose I can sum this up with "isn't this already handled?" - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mount_nfs/df bug?
Hello! Today I wanted to add a new NFS to my /etc/fstab, but forgot to add it to /etc/exports on the server. However, I did mount -a several times and always got a "Permission denied" for the last one. Now look what I have here: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad2a 396895 2919047324080%/ /dev/ad2e 5257421 4626154 21067496%/usr procfs 440 100%/proc /dev/ad0s1 4224828 3755464 46936489%/dos neutron:/usr/ports 496367 3634489321080%/usr/ports neutron:/usr/ports-distfiles 2482878 1191660 109258852%/usr/ports-distfiles neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/src928695 482371 37202956%/usr/src neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/www/docs 297423 168669 10496162%/www neutron:/usr/doc 2482878 1191660 109258852%/usr/doc neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn Cute, isn't it? Not yet discovered why. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
FreeBSD cichlids.cichlids.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jun 14 22:25:49 CEST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
On 19 Jun 2000, Eric Jacoboni wrote: "Sergey" == Sergey Osokin [EMAIL PROTECTED] writes: Sergey Hello! Sergey After CVSuped my source, i try to buildworld and it failed... Sergey === libssh (...) Sergey /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory Sergey mkdep: compile failed Sergey *** Error code 1 Sergey Stop in /usr/src/secure/lib/libssh. Sergey *** Error code 1 [...] Same for me (fresh cvsup)... From the FAQ : "You can try to config OpenSSL so as not to use IDEA by using './config no-idea'". But i've no idea (what's a joke...) on how to do that with 'make buildworld'. Me too. I would very much appreciate a hint here. Thx! -- Marc Schneiders --- [EMAIL PROTECTED] --- [EMAIL PROTECTED] FreeBSD unclad.freebeastie.org 5.0-CURRENT (SMP) NetBSD vax.freebeastie.org 1.4Y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
Although I would not like to put it as strongly as Warner does, I would like to ask how the decision makers expect the rest of the project to progress (the other 30 or so kernel committers) in a reasonable, not too time consuming way. Will there be a general mechanism for making patchsets against CURRENT-26-JUNE-2000 available? Will there be moments in time were the tree will be made and kept stable for a week or so for people to insert their fixes. What about xtra tags being laid at certain moments in time? Any schedule for that? Will all the spls in all the drivers be removed and replaced by other mechanisms by the SMP group in the process? This would create a lot of extra work if the code is shared between different source trees, for example between the *BSDs, if the spls/shims will be removed completely. On the side, I would like to suggest that some sort of posting of updates (by you, Jason?) is done on a regular basis (bi-weekly or so) to show progress and to indicate the state of important aspects of the kernel (VM, kernel threads, API's, etc.), so other people have an indication of how reliable the system is and when it would be a reasonable point in time for them to start working their code/fixes back into the tree again. I must say that I find it slightly annoying that this aspect is completely ignored in your initial e-mail and definitely would like to see this addressed properly before any tag goes down and breakage occurs. I can see that everybody is very excited about what is going to happen, but I would like to make sure the rest of us, who will only participate on the side, are not left in the cold for 2 months or so while the basic stuff is being done. In any case, thanks for the work you guys are doing. From what Doug told me there is a lot of really, really cool stuff coming our way. Nick On Tue, 20 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Jason Evans writes: : Summary: -current will be destabilized for an extended period (on the order : of months). A tag (not a branch) will be laid down before the initial : checkin, and non-developers should either stick closely to that tag until : the kernel stabilizes, or expect large doses of pain. This tag will be : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning : beforehand. Thanks for the fair warning. Now don't do it. Has core approved this? I don't think so, I've seen nothign from them about it. The instability ni -current for MONTHS is pain not acceptible. We've never really allowed that in the past. A CVS branch would be mcuh better for this sort of thing. I know that's a pain as well, but this is just for SMP people and the rest of us shouldn't have to deal with the pain. I understand your desire to have it all in a working tree, but causing pain for ALL developers for potentially MONTHS isn't a reasonable request. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? This sounds odd at first glance, but it means that others are forced to MFC into the smp branch - if they don't they lose. Anybody that's not confident to be able to merge into the smp branch will simply be in the same position - merge or hold off. They'd also be just as likely to break the smp work with their commits as if the smp work was done in HEAD. Isn't this the same thing as breaking the head and keeping every thing else (that is the pre-broken 5.0) on a branch... Just sorta rotating the tree a little... And, isn't this the same idea as -stable? If that's all true - I'd suggest that those who really want stability might be better served with the -stable branch for the interim. If you need a totally-brand-new-feature, then MFC that to -stable and get it there... [.] I suppose I can sum this up with "isn't this already handled?" True, if you run current you've gotta be able to cope with the blood. However, I don't think it's a good idea to have a single project prevent a load of other developers from doing their bits - not if it can be helped. I'm sure SMP is not the only code in -current that's not ready for -stable yet. - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Narvi writes: : You obviously haven't considered the ability to be able to near hot-swap : motherboard and cpu - or even RAM - in this way. The ACPI spec specifically states that one cannot disassemble a machine in S4 state and expect the state to be saved on reassembly. Maybe the same sort of mechanism could be used to do this, but then again, maybe night. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
Warner Losh writes: In message [EMAIL PROTECTED] Jason Evans writes: : Summary: -current will be destabilized for an extended period (on the order : of months). A tag (not a branch) will be laid down before the initial : checkin, and non-developers should either stick closely to that tag until : the kernel stabilizes, or expect large doses of pain. This tag will be : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning : beforehand. Thanks for the fair warning. Now don't do it. Has core approved this? I don't think so, I've seen nothign from them about it. The instability ni -current for MONTHS is pain not acceptible. We've never really allowed that in the past. A CVS branch would be mcuh better for this sort of thing. I know that's a pain as well, but this is just for SMP people and the rest of us shouldn't have to deal with the pain. As someone who does consulting on for release engineering and such things, I'll comment that that's one of the key uses of branches; buliding a development branch so that adding major new features doesn't disrupt other development until they are as stable as the rest of the project. If CVS makes merging a branch back in a pain, and there isn't an open source tool (bitkeeper, maybe?) that solves this problem, then possibly a compromise can be reached with the folks at Perforce(*). They're reasonable people, and think highly of the FreeBSD project. "The Cathederal and the Bazaar" talks about transitioning from closed to open source, so I'd be very surprised if they haven't thought about these issues. As a for instance, possibly they could be talked out of sources for the client (client libraries, that is - the rest is trivial) and a spec for talking to the server, on the assumption that the truly valuable information is in the server. That way, the tools installed by developers would all be open source. Of course, Perforce may have no interest in this, but I can't think of anything more likely to convince them to make such a move than the possibility of the FreeBSD project moving to Perforce. I understand your desire to have it all in a working tree, but causing pain for ALL developers for potentially MONTHS isn't a reasonable request. How far can the tag be stretched to make things work? Can CVS tags be changed to include updates versions of a file, so that there is some possibility that other developers could work with that tag, instead of creating another branch? mike *) While I am a Perforce Consulting Partner, I have no official position with Perforce, I am *not* speaking for them, and I'm not privy to any of their strategic planning. If you want to know what the folks at Perforce think about any of this, ask them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer [EMAIL PROTECTED] writes: Today I wanted to add a new NFS to my /etc/fstab, but forgot to add it to /etc/exports on the server. However, I did mount -a several times and always got a "Permission denied" for the last one. why there isn't an exportfs command as most unices have ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
In local.freebsd-current you write: On 19 Jun 2000, Eric Jacoboni wrote: "Sergey" == Sergey Osokin [EMAIL PROTECTED] writes: Sergey Hello! Sergey After CVSuped my source, i try to buildworld and it failed... Sergey === libssh (...) Sergey /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory Sergey mkdep: compile failed Sergey *** Error code 1 Sergey Stop in /usr/src/secure/lib/libssh. Sergey *** Error code 1 [...] Same for me (fresh cvsup)... From the FAQ : "You can try to config OpenSSL so as not to use IDEA by using './config no-idea'". But i've no idea (what's a joke...) on how to do that with 'make buildworld'. Me too. I would very much appreciate a hint here. Thx! Try this as a workaround: cp /usr/src/crypto/openssl/crypto/idea/idea.h /usr/include/openssl /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs second mount
On Sun, 18 Jun 2000, kit wrote: On Freebsd 4.0-Release I am trying the smbfs-1.2.1 to mount a couple of NT shares so that I can read some files and copy them to a web server. The problem I am having is that the second mount kills the first. Ok, this problem fixed along with others NT related things. An updated version (1.2.2) can downloaded from ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs second mount
On Sun, 18 Jun 2000, Brandon D. Valentine wrote: Out of curiosity, are there any plans to commit the smbfs stuff? It is really useful and I'd love to see it in the base system. Yes, I'm get much more responses about smbfs compared to nwfs. So, probably it should be in the base system. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer wrote: neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn You probably have a symlink in the client path somewhere. Is /usr/home a symlink to /home or something? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: ACPI project progress report
In message [EMAIL PROTECTED] Mike Smith writes: : The real issue here is persistent system state across the S4 suspend; ie. : leaving applications open, etc. IMO this isn't really something worth a : lot of effort to us, and it has a lot of additional complications for a : "server-class" operating system in that you have to worry about network : connections from other systems, not just _to_ other systems. They why bother supporting laptops at all? FreeBSD is now more than just a server OS. And the network connection issue is a non issue. If the connections are present when we go to sleep, either the connection will time out or it won't. It is no different than yanking out the ethernet cable. Those that time out will get a connection reset when the application comes back when the system wakes from the S4 state. Those that don't won't care since they will just continue working. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 12:47:38PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. That would probably explain why W'98 gets confused when you _do_ change the hardware configuration while in suspend state. Pretty silly state to get into, then, if hardware like floppy drives are easy to add or remove, and the box looks as though it's off... Any good theories about how to avoid this problem? Avoid S4 and go all the way to shutdown, with a flag set on the boot disk? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Josef Karthauser wrote: On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) You obviously haven't considered the ability to be able to near hot-swap motherboard and cpu - or even RAM - in this way. Joe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Mitsuru IWASAKI wrote: : : - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep : require some hack in boot loader needs help. : : I thought hibernation was entirely controlled by kernel? What do you : need? You have to use the BIOS to put the machine into the state, but when the machine comes out of that state, it goes through the reset vector, at least for S4 (I think S2 and S3 as well, I don't have my copy of the standard handy). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Andrzej Bialecki wrote: This thread is long, so maybe I missed something.. Can we have the *.hints file loadable as a module of some special type (like kernel.conf), and searched for during configuration like userconfig did? Funny you got no reply. This is not necessary. If you copy said file to /boot/device.hints, it will be read automatically as a loader .conf file and set environment variables that will be read automatically by the kernel. If you wish to use alternate configurations without tweaking device.hints, you can do loader_conf_files="xyzzy" And xyzzy will be read. Since device.hints is read right after /boot/defaults/loader.conf, anything later will override it's values. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Peter Jeremy wrote: On Sun, Jun 11, 2000 at 02:41:12AM +1000, Daniel C. Sobral wrote: Mind you, shells don't have problems with any character at all in a filename if they are properly written, but if you are expecting the filenames generated by mktemp() to be handled by shell, they ought to pass the IFS=':'; for file in $filelist test. Why? Isn't it equally valid to state that they ought to pass IFS='a'; for file in $filelist or setting IFS to any other random character? Because : is a standard separator. See, for instance, PATH. (And see the "mind you" part of my comment above :). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Warner Losh wrote: In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Hi, here is the latest report on our ACPI project's progress. As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should enable us to properly put the chipsets in laptops to sleep and then wake them up again. Right now pccard insert/removal can be missed when you put a laptop to sleep... BTW, have you decided between NetBSD and BSD/OS cardbus code yet? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : BTW, have you decided between NetBSD and BSD/OS cardbus code yet? No. There is no BSD/OS cardbus card that I could find in the tree. If I'm being insanely blind, please someone tell me. The short term plan is to get NEWCARD working and then look at wildboar to see if it could be useful. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
