-CURRENT is bad for me...
Just finished buildworld on recent -CURRENT. installworld target died with this: === gnu/usr.bin/perl/suidperl install -c -s -o root -g wheel -m 511 suidperl /usr/bin /usr/bin/sperl5 - /usr/bin/suidperl /usr/bin/sperl5.6.0 - /usr/bin/suidperl === gnu/usr.bin/perl/library sed: stdout: Bad file descriptor *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Sigh... Now I have an impaired world and kernel that's way out of sync :( I guess I am still lucky enough if this mail can reach the mailing list. This mail only serves as a warning to other typical -CURRENT user like me to be aware that -CURRENT has troubles for the moment... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is -CURRENT in bad shape?
On Mon, Feb 12, 2001 at 01:57:49PM +0700, John Indra wrote: BTW, today I saw post from John Baldwin to remove device random from the kernel config. Then, other post replied that this is a good thing, mpg123 playing went a lot better for him, well at least, that's what he said. If this is so, then why is there a device random line in GENERIC kernel? Do we really need device random? Only if you use things like SSH, SSL, or other cryptographic utilities/protocols :-) Mark committed patches last night which reduce the impact the random device has on the system, and it will probably get better over time with other commits. Kris PGP signature
Re: HEADS UP: installworld gotchas
Peter Wemm wrote: Argh... We are in far worse shape than I thought... It seems that the "temporary" copies of the host tools like install etc are getting clobbered by the non-version-bump of libc. It is sheer luck that only the sed thing died before. It could have been a lot worse. I managed to get through an install by doing 'make -k install ; make installworld' in /usr/src. So far, the only thing that's been negatively affected is my old x-chat binary. I compiled and installed a new one and it works just fine. FWIW, Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
Doug Barton wrote: Peter Wemm wrote: Argh... We are in far worse shape than I thought... It seems that the "temporary" copies of the host tools like install etc are getting clobbered by the non-version-bump of libc. It is sheer luck that only the sed thing died before. It could have been a lot worse. I managed to get through an install by doing 'make -k install ; make installworld' in /usr/src. So far, the only thing that's been negatively affected is my old x-chat binary. I compiled and installed a new one and it works just fine. Well, I spoke a little too soon. xauth is also dead. It isn't allowing connections back to the X server, and it dumps core when I try running it to list .Xauthority contents, etc. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My world is totally broken. Request help...
Please help me to overcome this. My world is totally broken. ps and top don't work. fetchmail, and other program seems to lost STDOUT. After failed installworld, I reboot my machine, blew away /usr/obj and make clean in /usr/src. Now when I want to rebuild the world, make just don't want to do its jobs anymore :( Now, what should I do. This is -CURRENT as of today... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My world is totally broken. Request help...
On Mon, Feb 12, 2001 at 04:19:57PM +0700, John Indra wrote: Please help me to overcome this. My world is totally broken. ps and top don't work. fetchmail, and other program seems to lost STDOUT. After failed installworld, I reboot my machine, blew away /usr/obj and make clean in /usr/src. Now when I want to rebuild the world, make just don't want to do its jobs anymore :( Now, what should I do. This is -CURRENT as of today... Revert to a backup or reinstall from somewhere.. Kris PGP signature
Re: My world is totally broken. Request help...
On Mon, 12 Feb 2001 16:19:57 +0700, John Indra wrote: Please help me to overcome this. My world is totally broken. ps and top don't work. fetchmail, and other program seems to lost STDOUT. After failed installworld, I reboot my machine, blew away /usr/obj and make clean in /usr/src. Now when I want to rebuild the world, make just don't want to do its jobs anymore :( 1) In multi-user mode, try to update your source tree to RELENG_4. 2) Drop to single-user mode. 3) cd /usr/src make cleandir make cleandir# (Yes, twice) 4) make buildworld 5) make buildkernel 6) make installkernel 7) make installworld 8) mergemaster 9) reboot If your box is hosed to the point where that doesn't work and you don't know how to fix each problem manually, you'll be better off going for a binary installation of 4.x-RELEASE and then updating to 4.x-STABLE. Seriously, now's not the time to run CURRENT "for fun". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My world is totally broken. Request help...
+---[ Sheldon Hearn ]-- | | Seriously, now's not the time to run CURRENT "for fun". Well if now isn't when is? It's been pretty boring up until now :-) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Peter Wemm wrote:
Matt Dillon wrote:
:
: This is a major change to libc. The library maj must be bumped if you
: intend to change the sizeof(FILE), or every single third party applicatio
n
: that uses stdio will break.
:
: -Matt
Oh wait, is libc already bumped in current verses 4.2? If so then I gues
s
we don't bump libc's maj. God help anyone using current though!
-Matt
I cant help but wonder why on earth we didn't have it like this from the
start:
[...]
That compiles fine. The __stdin thing is in case somebody likes the idea
of #undef stdin or #ifdef stdin for some reason.
In fact, I can't imagine *any* reason not to do this. At least this would
insulate us from future nasties in FILE size changes, and would have
saved us in this case.
Wouldn't this change/break code like the following?
main()
{
FILE **fp;
fp = stdin;
my_func(fp);
}
That is, previously stdin would work... in this new situation,
you would get __stdin which is not the same... is it?
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Lpt driver broken?
I have been trying to talk to a laserprinter but whenever I try cat file /dev/lpt0 the system panics (if the printer is online) Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable d Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Fatal trap 9: general protection faul t while in kernel mode Feb 12 02:36:56 jules /boot/kernel/kernel: instruction pointer = 0x8:0xc0252ebc Feb 12 02:36:56 jules /boot/kernel/kernel: stack pointer= 0x10:0 xccca4f50 Feb 12 02:36:56 jules /boot/kernel/kernel: frame pointer= 0x10:0 xccca4f64 Feb 12 02:36:56 jules /boot/kernel/kernel: code segment = base 0x0, limi t 0xf, type 0x1b Feb 12 02:36:56 jules /boot/kernel/kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 12 02:36:56 jules /boot/kernel/kernel: processor eflags = resume, IOPL = 0 Feb 12 02:36:56 jules /boot/kernel/kernel: current process = 288 (i rq7: lpt0) it seems to be in the fork trampoline code when it crashes. This was with kernels from Feb 1 and Feb 6. I'm going to try absolutely current now but have seen nothing about such a problem in the last 2 weeks in the lists. Is everyone using ethernet attached printers? -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
On Mon, Feb 12, 2001 at 03:49:04AM -0800, Julian Elischer wrote: I'm going to try absolutely current now but have seen nothing about such a problem in the last 2 weeks in the lists. Is everyone using ethernet attached printers? This system prints fine for me: FreeBSD cicely8.cicely.de 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Feb 7 14:25:42 CET 2001 [EMAIL PROTECTED]:/var/d9/src-2001-02-05/src/sys/compile/CICELY8 i386 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: Canon BJC-4550 PRINTER BJ,LQ,BJL,BJRaster,BSCC -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, John Indra wrote: Just finished buildworld on recent -CURRENT. installworld target died with this: === gnu/usr.bin/perl/suidperl install -c -s -o root -g wheel -m 511 suidperl /usr/bin /usr/bin/sperl5 - /usr/bin/suidperl /usr/bin/sperl5.6.0 - /usr/bin/suidperl === gnu/usr.bin/perl/library sed: stdout: Bad file descriptor *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Sigh... Now I have an impaired world and kernel that's way out of sync :( I guess I am still lucky enough if this mail can reach the mailing list. This mail only serves as a warning to other typical -CURRENT user like me to be aware that -CURRENT has troubles for the moment... Did you miss the HEADS UP posted to -current? You better read these. To get around the installworld problem, do: # cd /usr/src/usr.bin/sed # make install # cd /usr/src # make installworld If that doesn't work, then try: # make -k installworld # make installworld -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
Julian Elischer wrote: I have been trying to talk to a laserprinter but whenever I try cat file /dev/lpt0 the system panics (if the printer is online) Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable d Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Fatal trap 9: general protection faul t while in kernel mode Feb 12 02:36:56 jules /boot/kernel/kernel: instruction pointer = 0x8:0xc0252ebc Feb 12 02:36:56 jules /boot/kernel/kernel: stack pointer= 0x10:0 xccca4f50 Feb 12 02:36:56 jules /boot/kernel/kernel: frame pointer= 0x10:0 xccca4f64 Feb 12 02:36:56 jules /boot/kernel/kernel: code segment = base 0x0, limi t 0xf, type 0x1b Feb 12 02:36:56 jules /boot/kernel/kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 12 02:36:56 jules /boot/kernel/kernel: processor eflags = resume, IOPL = 0 Feb 12 02:36:56 jules /boot/kernel/kernel: current process = 288 (i rq7: lpt0) it seems to be in the fork trampoline code when it crashes. This was with kernels from Feb 1 and Feb 6. following up to myself: the dmesg shows: ppc0: ECP parallel printer port at port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port and the config has; # parallel port device ppc device ppbus device lpt The hints have no entry.. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata changes break kernel
../../dev/ata/ata-all.c:96: elements of array `ata_ids' have incomplete type ../../dev/ata/ata-all.c:97: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:97: warning: (near initialization for `ata_ids[0]') ../../dev/ata/ata-all.c:97: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:97: warning: (near initialization for `ata_ids[0]') ../../dev/ata/ata-all.c:98: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:98: warning: (near initialization for `ata_ids[1]') ../../dev/ata/ata-all.c:98: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:98: warning: (near initialization for `ata_ids[1]') ../../dev/ata/ata-all.c:99: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:99: warning: (near initialization for `ata_ids[2]') ../../dev/ata/ata-all.c:99: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:99: warning: (near initialization for `ata_ids[2]') ../../dev/ata/ata-all.c:100: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:100: warning: (near initialization for `ata_ids[3]') ../../dev/ata/ata-all.c:100: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:100: warning: (near initialization for `ata_ids[3]') ../../dev/ata/ata-all.c:101: warning: excess elements in struct initializer ../../dev/ata/ata-all.c:101: warning: (near initialization for `ata_ids[4]') ../../dev/ata/ata-all.c:102: invalid use of undefined type `struct isa_pnp_id' ../../dev/ata/ata-all.c: In function `ata_isa_probe': ../../dev/ata/ata-all.c:113: warning: implicit declaration of function `ISA_PNP_PROBE' -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "It's not what we don't know that hurts us, it's what we know for certain that just ain't so." -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCM: Channel dead
With a buildworld from two hours ago, i got the following message while playing an MP3: pcm1: play interrupt timeout, channel dead After which the player process hangs. Interrupting (CTRL-C) and restarting the player works. It happened only once so far, so I can't tell much more. -- Theo van Klaveren [EMAIL PROTECTED] http://home.student.utwente.nl/t.vanklaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata changes break kernel
It seems Michael Harnois wrote: Fixed. -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
On 12 Feb, Julian Elischer wrote: the system panics (if the printer is online) Same here. Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable d Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Feb 12 02:36:56 jules /boot/kernel/kernel: Fatal trap 9: general protection faul t while in kernel mode Feb 12 02:36:56 jules /boot/kernel/kernel: instruction pointer = 0x8:0xc0252ebc Feb 12 02:36:56 jules /boot/kernel/kernel: stack pointer= 0x10:0 xccca4f50 Feb 12 02:36:56 jules /boot/kernel/kernel: frame pointer= 0x10:0 xccca4f64 Feb 12 02:36:56 jules /boot/kernel/kernel: code segment = base 0x0, limi t 0xf, type 0x1b Feb 12 02:36:56 jules /boot/kernel/kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 12 02:36:56 jules /boot/kernel/kernel: processor eflags = resume, IOPL = 0 Feb 12 02:36:56 jules /boot/kernel/kernel: current process = 288 (i rq7: lpt0) it seems to be in the fork trampoline code when it crashes. Same here. This was with kernels from Feb 1 and Feb 6. I've a kernel from Feb 6 too (and one from Feb 8, but I think the sources are from Feb 6). But I remember some posts about a lpt panic some days ago. I tried to compile a new kernel because I think this is resolved, but I have to solve some problems with my system at the moment. Sorry, no dmesg at the moment. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On 12 Feb 2001, Dag-Erling Smorgrav wrote: Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... It seems to me that kinfo_proc is the wrong solution to a real problem. John Baldwin and I briefly discussed, online, an alternative solution that breaks out the per-process information into a series of sysctl's. This costs you more in terms of number of calls to retrieve the information, as well as introducing non-atomicity that might need to be addressed, but allows you to maintain compatibility in many more situations. It removes struct ordering constraints, allows you to happily handle the addition of new fields, and when a field is removed or changes size, you know which field it is, and your ability to look at other fields is not impacted. Another global sysctl could maintain a list of relevant fields, so you could even imagine a process browser that was extensible (especially when using base types for the fields, such as int). kinfo_proc addresses the issue that the kernel and userland concepts of a proc diverge due to the introduction of kernel-only fields, but doesn't really address issues such as ordered elements of the structure changing size. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata changes break kernel
On 12 Feb, Michael Harnois wrote: ../../dev/ata/ata-all.c:96: elements of array `ata_ids' have incomplete type [...] Workaround (compile in progress): remove the #if / #endif pair which tests "NISA 0" Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
But I remember some posts about a lpt panic some days ago. I tried to compile a new kernel because I think this is resolved, but I have to solve some problems with my system at the moment. My -CURRENT used to crash every time lpr has been used but the panic went away when John Baldwin committed his ithread cleanup megapatch: jhb 2001/02/09 09:47:47 PST Modified files: sys/i386/i386nexus.c sys/i386/isa intr_machdep.c intr_machdep.h ithread.c Log: Use the MI ithread helper functions in the x86 interrupt code. The kernel from Feb 9 worked just fine for me, but then the following commit has been made and the system started to crash again: jhb 2001/02/09 18:41:51 PST Modified files: sys/i386/isa ithread.c Log: Re-enable preemption on interrupts. My last commit accidentally reverted it as I was playing with some other ways of doing kernel preemption. Revision ChangesPath 1.14 +9 -2 src/sys/i386/isa/ithread.c If you badly need your printer to work, you can simply revert this patch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Have you seen these 3 video clips...they're hilarious
> -Original Message- > From: Phil Simms > Sent: Tuesday, February 9, 2001 4:14 PM > To: Barry Sanders > Cc: Steve Hartman, Rhonda Smalley, Jimmy Ward, Big Dave, Dean Fletcher > Subject: FW: -- 3 New Hilarious Video Clips and some more jokes. > Joke Lovers, > Here are the video clips* >1.Scratch Sniff - Hilarious - you gotta see this one!!! >2.Grandma Scores - This one's Great. I don't know how they did it? >3.Try Throwing Rocks - The title says it all... > Jokemeister > Five Bucks - > A man is walking around New York with his wife. > They find a perfume shop, the wife goes in, and he waits outside. > A hooker comes along and says to him, "Like to come home with me, buddy? " > "For how much?" asks the man. > "One hundred dollars," the hooker answers. > "I'll give you five bucks," he replies. > The hooker swears at him and walks away. A little later, the man's wife comes out of the shop and they continue their walk. As they round the corner, there stands the same hooker. She takes one look > at the man and his wife and says, "HA! see what you get for five bucks?" > > My Lying Wife "That wife of mine is a liar," said the angry husband to a sympathetic pal seated next to him in the bar. "How do you know?" the friend asked. "She didn't come home last night and when I asked her where she'd been, she said she had spent the night with her sister, Shirley." "So?" "So she's a liar I spent the night with her sister Shirley." > *Please Note - to view the video clips you may need to load Windows Media Player > from Microsoft. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic in irq14: ata0
Hi, I'm not sure whether it's related to ata driver, but starting from several days ago (my previous kernel was from 30 January) my kernel panices on every more or less active ad0 usage (for example, dd if=/dev/ad0 of=/dev/null kills it perfectly). The system in question is Toshiba Satellite Pro 445CDX with isa-based ATA controller. Following is relevant dmesg, kernel config and backtrace of crash dump. -Maxim Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Feb 11 02:05:32 EET 2001 root@notebook:/usr/src/sys/compile/NOTEBOOK Timecounter "i8254" frequency 1193136 Hz CPU: Pentium/P55C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33685504 (32896K bytes) avail memory = 29745152 (29048K bytes) Preloaded elf kernel "kernel" at 0xc0302000. Preloaded elf module "snd_pcm.ko" at 0xc030209c. Preloaded elf module "snd_mss.ko" at 0xc030213c. Intel Pentium detected, installing workaround for F00F bug VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc0293d20 (140) VESA: CHIPS 6x554 Super VGA apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 pcic0: Intel i82365 at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 pcm0: OPL3-SA3 (YMF715) at port 0x530-0x537,0x370-0x371 irq 5 drq 1 flags 0xc110 on isa0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 flags 0x1 on isa0 ppc0: Generic chipset (NIBBLE-only) in NIBBLE mode plip0: PLIP network interface on ppbus0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: TOS7400 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0e00 can't assign resources unknown: TOS7009 can't assign resources unknown: YMH0021 can't assign resources lp0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ad0: 1376MB TOSHIBA MK1403MAV [2796/16/63] at ata0-master BIOSPIO acd0: CDROM TOSHIBA CD-ROM XM-1502BN at ata1-master using BIOSPIO Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 WARNING: / was not properly dismounted ed0 at port 0x240-0x25f irq 3 slot 0 on pccard0 ed0: address 00:80:c8:88:86:b1, type NE2000 (16 bit) sio1 at port 0x2e8-0x2ef irq 10 slot 1 on pccard1 sio1: type 16550A debug.log machine i386 cpu I586_CPU # Coz we don't need stuff for I386, I486 and I686 ident GENERIC maxusers10 #optionsKTRACE options FFS #optionsFFS_ROOT options NFS options MSDOSFS options INET#InterNETworking options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options NSWAPDEV=1 options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION options USER_LDT options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L device random device isa #device pcm device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd device psm #optionsPSM_HOOKAPM device vga device sc 1 options VESA options SC_PIXEL_MODE #optionsSC_NO_SYSMOUSE options SC_TWOBUTTON_MOUSE options SC_HISTORY_SIZE=1024 device npx device sio device apm device pmtimer device card device pcic device ed options PCIC_RESUME_RESET options POWERFAIL_NMI # Zip Stuff - comment out if not needed #device vpo0 #device scbus0 at vpo0 #device da0 device ppc
Re: Kernel panic in irq14: ata0
It seems Maxim Sobolev wrote: [Charset koi8-r unsupported, filtering to ASCII...] Hi, I'm not sure whether it's related to ata driver, but starting from several days ago (my previous kernel was from 30 January) my kernel panices on every more or less active ad0 usage (for example, dd if=/dev/ad0 of=/dev/null kills it perfectly). The system in question is Toshiba Satellite Pro 445CDX with isa-based ATA controller. Following is relevant dmesg, kernel config and backtrace of crash dump. Try to go back to -current from about feb. 8 or there abouts... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic in irq14: ata0
Soren Schmidt wrote: It seems Maxim Sobolev wrote: [Charset koi8-r unsupported, filtering to ASCII...] Hi, I'm not sure whether it's related to ata driver, but starting from several days ago (my previous kernel was from 30 January) my kernel panices on every more or less active ad0 usage (for example, dd if=/dev/ad0 of=/dev/null kills it perfectly). The system in question is Toshiba Satellite Pro 445CDX with isa-based ATA controller. Following is relevant dmesg, kernel config and backtrace of crash dump. Try to go back to -current from about feb. 8 or there abouts... Reverting sys/i386/isa/ithread.c to r1.13 did the trick (credit goes to Alexander N. Kabaev). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
"Alexander N. Kabaev" wrote: But I remember some posts about a lpt panic some days ago. I tried to compile a new kernel because I think this is resolved, but I have to solve some problems with my system at the moment. My -CURRENT used to crash every time lpr has been used but the panic went away when John Baldwin committed his ithread cleanup megapatch: jhb 2001/02/09 09:47:47 PST Modified files: sys/i386/i386nexus.c sys/i386/isa intr_machdep.c intr_machdep.h ithread.c Log: Use the MI ithread helper functions in the x86 interrupt code. The kernel from Feb 9 worked just fine for me, but then the following commit has been made and the system started to crash again: jhb 2001/02/09 18:41:51 PST Modified files: sys/i386/isa ithread.c Log: Re-enable preemption on interrupts. My last commit accidentally reverted it as I was playing with some other ways of doing kernel preemption. Revision ChangesPath 1.14 +9 -2 src/sys/i386/isa/ithread.c If you badly need your printer to work, you can simply revert this patch. I booted with -c and set the irq and drq to -1 so that the driver is running in polled mode. it's now printing, slowly, but I am going to bed now so as long as it's done by the morning, I'm happy :-) I'll try your suggestion tomorrow. (I'm not interrupting this print run for anything, after spending most of the afternoon trying to get it to print at all.) :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001 16:51:29 -0800, Kris Kennaway [EMAIL PROTECTED] said: The major number has already been bumped, I thought. If this is true then we've only broken compatibility with older versions of -current after the version number was bumped but before this change, right? However, this may turn out to be so painful that we need to bump it again. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel.c disklabel.8 patch
Bruce Evans [EMAIL PROTECTED] writes:
On Fri, 9 Feb 2001, John W. De Boskey wrote:
I've been using the disklabel.c patch which allows easier
configuration by being able to specify a new disklabel of
the form:
I'd like to commit these if no one sees any major problems
with them.
These are not suitable for commit in their current form. The
disklabel.c patch has more than the usual density of style bugs.
It doesn't even use the normal brace style.
Sorry, my normal personal style definitions in Emacs probably
conflict with "standard" BSD style. I'll rework the style (I'm the author
of the patch). Any other problems while I'm at it?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
At 11:47 AM 2/12/2001 -0500, Garrett Wollman wrote: On Sun, 11 Feb 2001 16:51:29 -0800, Kris Kennaway [EMAIL PROTECTED] said: The major number has already been bumped, I thought. If this is true then we've only broken compatibility with older versions of -current after the version number was bumped but before this change, right? However, this may turn out to be so painful that we need to bump it again. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message I just did a make build world on current and was looking forward to rebuilding all the ports :) Should I wait until the version bump then try again. I realize that if I do a install world now I'll have to rebuild almost everything X,apache.bind,etc,etc. I just don't want to do it twice in two days. I guess I'll wait. I already experienced some of the ramifications from just installing a current libc.so.5. Fortunately i kept a backup copy of the old one :) Thanks Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is -CURRENT in bad shape?
In message [EMAIL PROTECTED] John Indra writes: : Is -CURRENT in bad shape? Yes. Life sucks in current - current upgrade land. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
To be blunt, the FILE * changes go too far, even for -current. Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Alternatively, the upgrade path must be fixed. We've managed to avoid extra special instructions in the vast majority of cases, and I don't want to start introducing them now. It is the road to madness. We tried that once before and the support load was too high. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
"Justin T. Gibbs" [EMAIL PROTECTED] wrote: It is not necessarily sufficient since the media may be changed after open on certain types of devices that don't have a media lock. But don't you risk a panic if you do that? Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] THAMES DOVER: SOUTHWEST VEERING NORTH 5 TO 7, VEERING NORTHEAST 4 LATER. RAIN CLEARING. MODERATE BECOMING GOOD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
"Justin T. Gibbs" [EMAIL PROTECTED] wrote: It is not necessarily sufficient since the media may be changed after open on certain types of devices that don't have a media lock. But don't you risk a panic if you do that? By pulling the media out and flipping off the hardware write protect? Even pulling out the media for a valid filesystem shouldn't panic. All I/O to that volume should fail and your system may become next to useless, but the system shouldn't panic. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, Warner Losh wrote: To be blunt, the FILE * changes go too far, even for -current. Other than having to installworld twice, I've had zero problems. But I don't recompile my applications often, and am probably still running things that depend on libc.so.4. Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Too bad ELF libraries don't have minor version numbers. It's a shame to waste a library version number. Alternatively, the upgrade path must be fixed. We've managed to avoid extra special instructions in the vast majority of cases, and I don't want to start introducing them now. It is the road to madness. We tried that once before and the support load was too high. I don't have the time or resources to fix the upgrade path. If someone else wants to, it would certainly be appreciated. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
In message [EMAIL PROTECTED] Daniel Eischen writes: : On Mon, 12 Feb 2001, Warner Losh wrote: : To be blunt, the FILE * changes go too far, even for -current. : : Other than having to installworld twice, I've had zero problems. : But I don't recompile my applications often, and am probably : still running things that depend on libc.so.4. I have lots of binaries that depend on libc.so.5 (I just checked) and none that depend on libc.so.4 or libc.so.3 (since those were removed from my system a while ago). I suspect many of them will break. : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. Alternatively, the locking : changes need to be backed out. : : Too bad ELF libraries don't have minor version numbers. It's : a shame to waste a library version number. Don't think of it as a waste. : Alternatively, the upgrade path must be fixed. We've managed to avoid : extra special instructions in the vast majority of cases, and I don't : want to start introducing them now. It is the road to madness. We : tried that once before and the support load was too high. : : I don't have the time or resources to fix the upgrade path. If : someone else wants to, it would certainly be appreciated. Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make install perl/library sed stdout error
Hey this may be a spot where the FILE change is felt - my installworld bombed in the perl/library install with a sed error. I went to usr.bin/sed and did a make install to put in the new sed and then make installworld completed ok. FYI Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. I have to "me too" this; the change simply isn't OK. There are a variety of ways that we can work around the issue and maintain binary compatibility, whilst still moving towards something that is immune to this breakage in future. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Yup, I agree here. IMO so many things depend on the stdio bits, that a major number increase would have been desireable. So far, bzip2, pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be rebuilt. Bumping the major number would at least allow these a stay of execution. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is -CURRENT in bad shape?
On Mon, Feb 12, 2001 at 01:20:36PM +0700, John Indra wrote: Now I'm in the middle of make -j10 buildworld. Is -CURRENT in bad shape? First thing to do when you're having problems building world is to STOP using -j. If you aren't hitting a race condition, you won't get able to figure out what is wrong due to the interleaved output. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Daniel Eischen writes: : On Mon, 12 Feb 2001, Warner Losh wrote: : To be blunt, the FILE * changes go too far, even for -current. : : Other than having to installworld twice, I've had zero problems. : But I don't recompile my applications often, and am probably : still running things that depend on libc.so.4. I have lots of binaries that depend on libc.so.5 (I just checked) and none that depend on libc.so.4 or libc.so.3 (since those were removed from my system a while ago). I suspect many of them will break. : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. Alternatively, the locking : changes need to be backed out. : : Too bad ELF libraries don't have minor version numbers. It's : a shame to waste a library version number. Don't think of it as a waste. : Alternatively, the upgrade path must be fixed. We've managed to avoid : extra special instructions in the vast majority of cases, and I don't : want to start introducing them now. It is the road to madness. We : tried that once before and the support load was too high. : : I don't have the time or resources to fix the upgrade path. If : someone else wants to, it would certainly be appreciated. Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. If you bump the library versions, doesn't that fix the upgrade path? I can think of a gross hack that gets around the problem for now. Allocate the FILE with enough storage for the lock, but don't declare it in FILE. __sF[3] would still be the same size and we could have __sF_locks[3] internally, and use these if fp is stdin, stdout, or stderr, else the lock is at the end of the struct. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. If you bump the library versions, doesn't that fix the upgrade path? No, because the library version bump has already happened. I can think of a gross hack that gets around the problem for now. Allocate the FILE with enough storage for the lock, but don't declare it in FILE. __sF[3] would still be the same size and we could have __sF_locks[3] internally, and use these if fp is stdin, stdout, or stderr, else the lock is at the end of the struct. You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. Now, __sF is defined as an array of FILE_old and handled specially internally (this part is gross, but necessary). You'll have to put the lock, etc. in a separate array and handle it specially, or you can have real FILE structures shadowing the FILE_old structures. Because this is a hack for binary compatibility and upgrading only, you can throw it away before we actually get to 5.0. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Warner Losh [EMAIL PROTECTED] writes: Alternatively, the upgrade path must be fixed. I don't see any way to do that. Everything on your system that isn't statically linked will need to be recompiled unless the libc major number is bumped. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
just FYI: playing with PnP and device.hints
Hello, I have been playing with PnP and device hints. Using a device.hints with hints for all the drivers, some "PNPxxx can't assing resources" messages showed up at boot. Then I removed hints one by one, until I ended up with these: hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.sc.0.at="isa" If I remove the hints for fd, the floppy is not attached (fd0c is). Something similar happens with atkbd and psm, and also with sc. Using the hints given above, I only get one PNPxxx..." message for the PNP0f13 device. I found that this message is not shown after removing the psm hints, so I suspect that the PNP0f13 device is the PS/2 port. However, I must keep the psm hints for getting the psm driver attached. All the rest of ISA devices are found and attached without problems. I include the dmesg output for reference. I have "PnP OS = yes" in the BIOS setup, BTW. Just FYI ;-) Cheers, -- JMA ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Wed Feb 7 15:04:53 CET 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEFIANT Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (342.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 127049728 (124072K bytes) Preloaded elf kernel "kernel" at 0xc036c000. Preloaded elf module "joy.ko" at 0xc036c09c. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fde00 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at 7.1 (no driver attached) pci0: serial bus, USB at 7.2 (no driver attached) pci0: bridge, PCI-unknown at 7.3 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xe400-0xe43f mem 0xe300-0xe30f,0xe3101000-0xe3101fff irq 15 at device 15.0 on pci0 fxp0: Ethernet address 00:d0:b7:3e:a0:fb ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xe800-0xe8ff mem 0xe310-0xe3100fff irq 11 at device 20.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs isa0: unexpected small tag 14 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: SB16 DSP 4.16 on sbc0 midi0: SB Midi Interface on sbc0 midi1: SB OPL FM Synthesizer on sbc0 joy0: Generic PnP Joystick at port 0x200-0x207 on isa0 midi2: CTL0022 WaveTable Synthesizer at port 0x620-0x623,0xa20-0xa23,0xe20-0xe23 on isa0 emu2: DRAM size = 512KB atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 unknown: PNP0f13 can't assign resources sio0: 16550A-compatible COM port at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A fdc0: NEC 72065B or clone at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Standard parallel printer port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode sio1: 16550A-compatible COM port at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Waiting 10 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a cd0 at ahc0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 4 lun 0 da1: FUJITSU M2513E 0050 Removable Optical SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DDRS-34560W S92A Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)
Patch for FILE problems (was Re: -CURRENT is bad for me...)
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
Thanks,
--
Dan Eischen
Index: include/stdio.h
===
RCS file: /opt/FreeBSD/cvs/src/include/stdio.h,v
retrieving revision 1.28
diff -u -r1.28 stdio.h
--- include/stdio.h 2001/02/12 03:31:23 1.28
+++ include/stdio.h 2001/02/12 23:21:41
@@ -96,6 +96,39 @@
*
* NB: see WARNING above before changing the layout of this structure!
*/
+typedefstruct __old_sFILE {
+ unsigned char *_p; /* current position in (some) buffer */
+ int _r; /* read space left for getc() */
+ int _w; /* write space left for putc() */
+ short _flags; /* flags, below; this FILE is free if 0 */
+ short _file; /* fileno, if Unix descriptor, else -1 */
+ struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */
+ int _lbfsize; /* 0 or -_bf._size, for inline putc */
+
+ /* operations */
+ void*_cookie; /* cookie passed to io functions */
+ int (*_close) __P((void *));
+ int (*_read) __P((void *, char *, int));
+ fpos_t (*_seek) __P((void *, fpos_t, int));
+ int (*_write) __P((void *, const char *, int));
+
+ /* separate buffer for long sequences of ungetc() */
+ struct __sbuf _ub; /* ungetc buffer */
+ unsigned char *_up; /* saved _p when _p is doing ungetc data */
+ int _ur;/* saved _r when _r is counting ungetc data */
+
+ /* tricks to meet minimum requirements even when malloc() fails */
+ unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
+ unsigned char _nbuf[1]; /* guarantee a getc() buffer */
+
+ /* separate buffer for fgetln() when line crosses buffer boundary */
+ struct __sbuf _lb; /* buffer for fgetln() */
+
+ /* Unix stdio files get aligned to block boundaries on fseek() */
+ int _blksize; /* stat.st_blksize (may be != _bf._size) */
+ fpos_t _offset;/* current lseek offset (see WARNING) */
+} __old_FILE;
+
typedefstruct __sFILE {
unsigned char *_p; /* current position in (some) buffer */
int _r; /* read space left for getc() */
@@ -131,7 +164,7 @@
} FILE;
__BEGIN_DECLS
-extern FILE __sF[];
+extern __old_FILE __sF[];
__END_DECLS
#define__SLBF 0x0001 /* line buffered */
@@ -194,9 +227,9 @@
#defineSEEK_END2 /* set file offset to EOF plus offset */
#endif
-#definestdin (__sF[0])
-#definestdout (__sF[1])
-#definestderr (__sF[2])
+#definestdin ((FILE *)__sF[0])
+#definestdout ((FILE *)__sF[1])
+#definestderr ((FILE *)__sF[2])
/*
* Functions defined in ANSI C standard.
Index: lib/libc/stdio/_flock_stub.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/stdio/_flock_stub.c,v
retrieving revision 1.5
diff -u -r1.5 _flock_stub.c
--- lib/libc/stdio/_flock_stub.c2001/02/11 22:06:39 1.5
+++ lib/libc/stdio/_flock_stub.c2001/02/12 23:16:41
@@ -67,6 +67,21 @@
int fl_count; /* recursive lock count */
};
+static FILEstd_files[3];
+
+static inline FILE *
+get_file_with_lock(FILE *fp)
+{
+ if (fp == stdin)
+ return (std_files[0]);
+ else if (fp == stdout)
+ return (std_files[1]);
+ else if (fp == stderr)
+ return (std_files[2]);
+ else
+ return (fp);
+}
+
/*
* Allocate and initialize a file lock.
*/
@@ -89,9 +104,10 @@
}
void
-_flockfile(FILE *fp)
+_flockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
/*
* Check if this is a real file with a valid lock, creating
@@ -123,9 +139,10 @@
}
int
-_ftrylockfile(FILE *fp)
+_ftrylockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
int ret = 0;
/*
@@ -153,9 +170,10 @@
}
void
-_funlockfile(FILE *fp)
+_funlockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
/*
* Check if this is a real file with a valid lock owned
Index: lib/libc/stdio/findfp.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/stdio/findfp.c,v
retrieving revision 1.12
diff -u -r1.12 findfp.c
--- lib/libc/stdio/findfp.c 2001/02/12 03:31:23 1.12
+++ lib/libc/stdio/findfp.c 2001/02/13 00:05:09
@@ -65,15 +65,14 @@
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hack. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Daniel Eischen writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. Thank you! I appreciate this! I'll kick off the compile right now. I have a machine I need to upgrade tonight. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. How does it break the upgrade path from 4.x to 5.0?? 5.0 has a higher libc.so version than 4.2. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Daniel Eischen [EMAIL PROTECTED] writes: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Please. Let's not, and say we did. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 04:20:04PM -0800, Alex Zepeda wrote: How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Yes. I don't want to be in a position where we wonder what happened to libc.so.5 when I don't see it in my /usr/lib/ or /usr/lib/compat/ Seems to me that a new major number is far cleaner than a gross hack. I am very against this. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. : : How does it break the upgrade path from 4.x to 5.0?? 5.0 has a higher : libc.so version than 4.2. It breaks the current pre Feb 10 - current post Feb 10 case. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Daniel Eischen [EMAIL PROTECTED] writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. : : Please. Let's not, and say we did. I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 01:42:16PM -0800, Alex Zepeda wrote: Yup, I agree here. IMO so many things depend on the stdio bits, that a major number increase would have been desireable. So far, bzip2, pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be rebuilt. Bumping the major number would at least allow these a stay of execution. /usr/ports is *very* easy to use. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Warner Losh [EMAIL PROTECTED] writes: : I'd rather see this patch, or something similar, than bump the major : version again. We can phase in a better way to obviate the need to do : this in the future. : : Brian Feldman, Peter Wemm, David O'Brien and myself have been : discussing possible solutions on IRC for the past two hours. Peter : will likely commit a patch sometime soon. If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 01:48:33AM +0100, Dag-Erling Smorgrav wrote: Peter will likely commit a patch sometime soon. I am hoping it is posted for discussion to -arch before commit (so we get this right). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, Feb 11, 2001 at 04:44:21PM -0800, Matt Dillon wrote: This is a major change to libc. The library maj must be bumped if you intend to change the sizeof(FILE), or every single third party application that uses stdio will break. For -stable this would be true. We've already done the bump in -current. -current users are expected to be able to work themselves over this huddle. Alternately, we should add symbol versioning to our shared libs like Solaris does. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Mon, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote: However, this may turn out to be so painful that we need to bump it again. That is (1) against Handbook documented policy, (2) too hackish (we aren't Linux). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On 13 Feb 2001, Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. I wish someone would have told me; I wouldn't have bothered with the patch. At any rate, kudos to you if you can fix it. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Yes, there is. Steal _cookie, rename it to _ext or something like that, and make it point to a separate structure that contains _cookie and the mutex. Optionally add a #define to avoid changing libc code that uses _cookie. That's not what Peter intends to commit, though. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 07:28:30PM -0500, Daniel Eischen wrote:
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
How about this? :^)
--- lib/libc/Makefile.orig Mon Feb 12 16:30:48 2001
+++ lib/libc/Makefile Mon Feb 12 16:30:37 2001
@@ -7,7 +7,7 @@
# from CFLAGS below. To remove these strings from just the system call
# stubs, remove just -DSYSLIBC_RCS from CFLAGS.
LIB=c
-SHLIB_MAJOR= 5
+SHLIB_MAJOR= 6
SHLIB_MINOR= 0
CFLAGS+=-DLIBC_RCS -DSYSLIBC_RCS -I${.CURDIR}/include
AINC= -I${.CURDIR}/${MACHINE_ARCH}
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Daniel Eischen [EMAIL PROTECTED] writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. : : Please. Let's not, and say we did. I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Personally, I think we place far too much weight on the major number thing. I think we should be allowed to bump it when the alternative is 'major pain' to developers. I also object to hacking around like this. I would far prefer that we fix it properly. We *need* to be able to innovate, especially with locking in libc in 5.x. I suspect we will have major events like this several more times before 5.0-R when we add in hooks for KSE or rfork threading. http://people.freebsd.org/~peter/stdio.diff3 Lets commit that and get on with life. Existing binaries will just keep on running. And if we dont ship libc.so.5, in 5.0-R, then *so what*? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 04:33:26PM -0800, Alex Zepeda wrote: How about this? :^) Because bumping the shared version again needs *DISCUSSING*. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. I can deal with /usr/local and /usr/X11R6 recompiles, but when the installworld dies because the dynamic linked copy of /usr/bin/* in /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving a 100% totally screwed up system, then I begin to think we are doing something wrong. If it wasn't for that, I could deal with a /usr/local and /usr/X11R6/lib recompile. I wish the people who say 'dont bump libraries at any cost' would fix the build so it was possible for an installworld to complete with an incompatable libc change. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: http://people.freebsd.org/~peter/stdio.diff3 Except that we bump to 500 instead of 6, and back to 5 before -RELEASE. When we've branched RELENG_5, if we need to bump libc's major in 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we want, and bump it down to 6 before 6.0-RELEASE. People tracking -CURRENT will end up with a handful of different libc versions, but they'll avoid the pains we're going through now, and people upgrading from RELENG_N to RELENG_N+1 will never see a libc major version increase of more than 1. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Warner Losh [EMAIL PROTECTED] writes: : I'd rather see this patch, or something similar, than bump the major : version again. We can phase in a better way to obviate the need to do : this in the future. : : Brian Feldman, Peter Wemm, David O'Brien and myself have been : discussing possible solutions on IRC for the past two hours. Peter : will likely commit a patch sometime soon. If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Do you really want to carry the baggage for the entire 5.0-RELEASE and 5-STABLE branch? Just because of a pedantic policy point? Personally, I think that sucks. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hack. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:09:19PM -0800, Peter Wemm wrote: I can deal with /usr/local and /usr/X11R6 recompiles, but when the installworld dies because the dynamic linked copy of /usr/bin/* in /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving a 100% totally screwed up system, then I begin to think we are doing something wrong. If it wasn't for that, I could deal with a /usr/local and /usr/X11R6/lib recompile. 100% agreed. Before doing this, can we put out a *HEADS UP* for people to NOT update their -current boxes for a day or two, and take a look at fixing the `make installworld' problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:14:03AM +0100, Dag-Erling Smorgrav wrote: No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Uh, NO. It was discussed on IRC, NOT -arch. It needs to go there before doing something like this. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: http://people.freebsd.org/~peter/stdio.diff3 Except that we bump to 500 instead of 6, and back to 5 before -RELEASE. When we've branched RELENG_5, if we need to bump libc's major in 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we want, and bump it down to 6 before 6.0-RELEASE. People tracking -CURRENT will end up with a handful of different libc versions, but they'll avoid the pains we're going through now, and people upgrading from RELENG_N to RELENG_N+1 will never see a libc major version increase of more than 1. I think this is the least evil of all. I totally support this option. It gives us a nice stable sequential *-RELEASE version numbering sequence without holes. It avoids the current problem: - RELENG_4 bumped from 3.0 to 4.0 - this forced a premature 4.0-5.0 bump in -current - we missed our chance for major changes. (!!!) If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Daniel Eischen wrote: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Thanks, __BEGIN_DECLS -extern FILE __sF[]; +extern __old_FILE __sF[]; __END_DECLS -#define stdin (__sF[0]) -#define stdout (__sF[1]) -#define stderr (__sF[2]) +#define stdin ((FILE *)__sF[0]) +#define stdout ((FILE *)__sF[1]) +#define stderr ((FILE *)__sF[2]) The problem with this is that it carries the baggage into 5.0-RELEASE and beyond... I wish there was a way we could get rid the array entirely and still stay compatable, but I dont see how. :-( A major bump makes it easy. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Mike Smith wrote: On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hac k. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE and 5.0-STABLE, because we *continue* to compile in the wrong sizes into applications. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Peter Wemm writes: : Personally, I think we place far too much weight on the major number thing. : I think we should be allowed to bump it when the alternative is 'major pain' : to developers. The more I think about this, the more that I think that you are right. I'd go farther and also say that we won't produce a libcompat/libc.so.5.uu or any other "current only" libc versions. : I also object to hacking around like this. I would far prefer that we fix : it properly. We *need* to be able to innovate, especially with locking in : libc in 5.x. I suspect we will have major events like this several more : times before 5.0-R when we add in hooks for KSE or rfork threading. And that's the argument that tipped me over from hacking around it... : http://people.freebsd.org/~peter/stdio.diff3 That looks good. I especially like the coupling of the std* changes to the new major version. I've killed my other build and will try to build this one. : Lets commit that and get on with life. Existing binaries will just keep : on running. : : And if we dont ship libc.so.5, in 5.0-R, then *so what*? I'd like to see a bias against major bumps remain in place, but I think that this change requires one. That is, we still don't generally bump major verions, but are allowed to when the pain is major. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
On Sun, Jan 28, 2001 at 01:27:04AM -0800, Julian Elischer wrote: This is the single most flagrant lack of cooperation I have experienced while working with the FreeBSD Project. I'm truly dumbfounded. It's not a lack of co-operation.. it's a lack of communication. I didn't see an any lists that anyone was doing this yet and thought I'd get the ball rolling to promote discussion.. I'm dumfounded to discover that you've done work here already as I thought I'd have heard of it. We've been waiting on JHB's (and others) locking changes on the proc structure because those will do nothing but make conflicts in the patches jasone has already. Has JHB made all the proc changes he was going to? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Peter Wemm [EMAIL PROTECTED] writes: : http://people.freebsd.org/~peter/stdio.diff3 : : Except that we bump to 500 instead of 6, and back to 5 before : -RELEASE. I don't think this will work. It is hard to downgrade a major number for libc.so. At least it used to be. : People tracking -CURRENT will end up with a handful of different libc : versions, but they'll avoid the pains we're going through now, and : people upgrading from RELENG_N to RELENG_N+1 will never see a libc : major version increase of more than 1. I don't see why we need only an increment of 1. What does this buy us other than a minor warm fuzzy. OpenBSD bumps libc bunchs of times per release cycle (they are up to libc.so.24 if my sources are current). I've not seen it cause problems there. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:20:51PM -0800, Peter Wemm wrote: It avoids the current problem: - RELENG_4 bumped from 3.0 to 4.0 - this forced a premature 4.0-5.0 bump in -current Actually "NO". I bumped libc.so because Garret said he had changes ready for libc, but was waiting for someone to bump the shared version number. - we missed our chance for major changes. (!!!) In the past, once it was bumped, incompatable changes to libc.so were fair game for -CURRENT. If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). /me wonders if we'll also do something about all the other things we do that kills our developers in -current.. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Sorry, I meant without the bump. it goes something like this: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Mike Smith wrote: On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hac k. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE and 5.0-STABLE, because we *continue* to compile in the wrong sizes into applications. Er, no, we wouldn't do this. The "gross hack" ensures binary compatibility with old applications. It's up to you or someone else to fix the source-level implementation of stdin/out/err such that it's not dependant on the size of the new FILE structure. This is the same as, for example, renaming an ioctl to keep an old interface alive. Newly compiled code uses the new interface, not the old one. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:21:58PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : Personally, I think we place far too much weight on the major number thing. : I think we should be allowed to bump it when the alternative is 'major pain' : to developers. The more I think about this, the more that I think that you are right. I'd go farther and also say that we won't produce a libcompat/libc.so.5.uu or any other "current only" libc versions. Huh?? We've never made a compat lib of a -current shared lib before. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I'd like to see a bias against major bumps remain in place, but I think that this change requires one. That is, we still don't generally bump major verions, but are allowed to when the pain is major. We can keep that bias by using temporary three-digit majors in -CURRENT and backing down to a single-digit major right before the first -RELEASE. In this specific case, we'd go from 5 to 500 or 501, then back to 5 right before 5.0-RELEASE; this will still screw people with older-than-feb-10 systems but at least they'll have plenty of time to rebuild their ports and stuff. For 6.0, we'd go straight from 5 to 600 or 601, then down to 6 right before 6.0-RELEASE, and nobody would get screwed. You know it makes sense. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Peter Wemm [EMAIL PROTECTED] writes: : http://people.freebsd.org/~peter/stdio.diff3 : : Except that we bump to 500 instead of 6, and back to 5 before : -RELEASE. I don't think this will work. It is hard to downgrade a major number for libc.so. At least it used to be. FYI; this is no longer the case. The numbers in the names mean nothing to ld or ldconfig. The library name is "libc.so.5" as a string with no significance to the naming at all. The versioning is done at link time by the libfoo.so - libfoo.so.N symlink. : People tracking -CURRENT will end up with a handful of different libc : versions, but they'll avoid the pains we're going through now, and : people upgrading from RELENG_N to RELENG_N+1 will never see a libc : major version increase of more than 1. I don't see why we need only an increment of 1. What does this buy us other than a minor warm fuzzy. OpenBSD bumps libc bunchs of times per release cycle (they are up to libc.so.24 if my sources are current). I've not seen it cause problems there. My thoughts exactly. Only do so when it is something big that is going to cause major pain. Minor pain we can live with and is part of -current life. But potential system killers like this sort of thing (my cleanup, not Dan's one) are worth it as long as they are not overdone. Warner Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, 12 Feb 2001, Peter Wemm wrote: Daniel Eischen wrote: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Thanks, __BEGIN_DECLS -extern FILE __sF[]; +extern __old_FILE __sF[]; __END_DECLS -#definestdin (__sF[0]) -#definestdout (__sF[1]) -#definestderr (__sF[2]) +#definestdin ((FILE *)__sF[0]) +#definestdout ((FILE *)__sF[1]) +#definestderr ((FILE *)__sF[2]) The problem with this is that it carries the baggage into 5.0-RELEASE and beyond... No, this hack was to be removed just before 5.0-release, not to stay in throughout the 5.0 cycle. I wish there was a way we could get rid the array entirely and still stay compatable, but I dont see how. :-( A major bump makes it easy. I think there's merit in DES' verion bump to 500, 501, etc. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
* Peter Wemm [EMAIL PROTECTED] [010212 17:28] wrote: Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Sorry, I meant without the bump. it goes something like this: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Er, why isn't /tmp/install.XXX done with static binaries? To fix it, it looks like the best idea is to add the programs in our current /tmp/install.XXX to some target to build them static as well, then install them over... gah, nevermind, signal problems, syscall mess, etc... -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
I don't see why we need only an increment of 1. What does this buy us
other than a minor warm fuzzy.
It is hackish.
OpenBSD bumps libc bunchs of times per release cycle (they are up to
libc.so.24 if my sources are current).
They do not always get things right...
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. I worked around this (with a fresh, unpatched -CURRENT) by simply running 'make install' manually in /usr/src/usr.bin/ and selected subdirectories of /usr/src/usr.sbin (chown, mtree, zic). The problem I'm facing now is that Somebody[tm] broke locale support, so Perl is spewing error messages about en_US.ISO_8859-1 not being supported. Like Juliana Hatfield says: dumb, dumb, fun. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Peter Wemm writes: : Warner Losh wrote: : significance to the naming at all. The versioning is done at link time : by the libfoo.so - libfoo.so.N symlink. Ah. That's different. If it is that easy, then my objection is withdrawn. I wasted about 3 days trying to untangle a version downgrade, but now that I think about that was in the 2.x days when we had a.out libs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Alfred Perlstein writes: : Er, why isn't /tmp/install.XXX done with static binaries? Because the binaries are host binaries and we have no control over whether they are static or dynmaic. At best we could do is to copy libraries over as well. But I think the major bumps ala Dag's 501 would be better. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:31:53PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : If we had taken -current to 500, we could go to 501, 502, etc as : required to stop killing our developers, and prior to entering 5.0-BETA we : go back to the next sequentially available major number (be it 5, or 6 : if RELENG_4 bumps again). I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. In the a.out days, yes. Are you sure you've seen this in the ELF days? What's wrong with shipping with say libc.so.505 in 5.0 and then say libc.so.645 in 6.0? HACK. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
* David O'Brien [EMAIL PROTECTED] [010212 17:35] wrote:
On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
I don't see why we need only an increment of 1. What does this buy us
other than a minor warm fuzzy.
It is hackish.
OpenBSD bumps libc bunchs of times per release cycle (they are up to
libc.so.24 if my sources are current).
They do not always get things right...
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
If that's true it doesn't seem like it would be terribly hard to
add a check to the installworld / world target to check for cross
version upgrades and do the magic (or at least print out those
instructions).
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Is it possible to produce a static executable from a dynamic one, provided the right libs are available? In that case, the initial "grab copies of the binaries we need" phase in the installworld target could be changed to "grab staticized copies of the binaries we need". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] "David O'Brien" writes: : What's wrong with shipping with say libc.so.505 in 5.0 and then say : libc.so.645 in 6.0? : : HACK. I think it is an astheitc issue only. It is not a hack, but how ELF shared libarires work. However, since it is easy to move from 505 - 5, there's no need to do it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Alfred Perlstein writes:
: Actually going from libc.so.500 to libc.so.{x500} is easy.
: Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
: libc.so.{x500}, that is the lib version number that will get burned into
: objects. After the first `make world', rm /usr/lib/libc.so.500.
:
: If that's true it doesn't seem like it would be terribly hard to
: add a check to the installworld / world target to check for cross
: version upgrades and do the magic (or at least print out those
: instructions).
Actaully, I think that the libc.so.500 can remain in its place because
of bsd.lib.mk:
...
SHLIB_NAME= lib${LIB}.so.${SHLIB_MAJOR}
SHLIB_LINK?=lib${LIB}.so
...
.if defined(SHLIB_LINK)
@ln -sf ${SHLIB_NAME} ${SHLIB_LINK}
.endif
...
As peter pointed out, it is the libc.so link that makes it the
default.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. What's wrong with shipping with say libc.so.505 in 5.0 and then say libc.so.645 in 6.0? Umm, I dunno, except that it'll look weird, but that's just a matter of taste. Of course, what we really need is "mandatory minor numbers", i.e. minor numbers that are treated as "I need this version", not as "I need this version or newer"... *ducks* *runs* DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. Umm, never mind this gross hack; as Peter pointed out, it's not a problem. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
"David O'Brien" wrote:
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
There is no need to rm /usr/lib/libc.so.500 - once a new libc is installed,
and the symlink points to it, then libc.so.500 will *never* get linked
against.
Remember, the number in the filename means *nothing*. There is no less
than or greater than relationship. We could use 100 digit random numbers
for each bump if we liked. We could use dates, current time_t, anything.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : When we back down to 5, we add magic to the Makefiles to move : libc.so.5?? to /usr/lib/compat - that way they're only used when : needed at runtime, not for linking new programs. No need. I misunderstood how ELF libraries work. The libc.so link is what makes it default. Peter set me right on this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:44:31PM -0800, Peter Wemm wrote: We could use dates, current time_t, anything. /usr/lib/libc.so.whistler (Sorry, working for MS I couldn't resist :-) -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:42:15AM +0100, Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. NO! No magic. No polution. If you are using -current when libc.so.5003 exists, you should be able to handle the `mv' yourself manually. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:44:53PM -0800, Peter Wemm wrote:
"David O'Brien" wrote:
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
There is no need to rm /usr/lib/libc.so.500 - once a new libc is installed,
The need is a clean, uncluttered /usr/lib/
and the symlink points to it, then libc.so.500 will *never* get linked
against.
Yes, I know. :-) But it is true that I didn't state that to make sure
others did.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:29:54AM +0100, Dag-Erling Smorgrav wrote: We can keep that bias by using temporary three-digit majors in -CURRENT and backing down to a single-digit major right before the first -RELEASE. In this specific case, we'd go from 5 to 500 or 501, Please read your -arch mail to discuss this issue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
