Re: libc size
David Schultz wrote:
> At least in the case of the base system, it should be easy to link
> all programs that actually use the resolver with -lresolv. Is
> there some standard that says that the resolver is an integral
> part of the C library, such that separating the two would break
> compatibility beyond comprehension?
It is a historical matter of pride in BSD-land that the resolver
is both available merely by linking libc ("BSD is a true networking
OS"), and that the resolver code is perpetually out of datem
relative to the ISC BIND distribution version of the resolver
code.
> If you wanted to be really evil, I suppose you could have a libc.a
> that included the resolver and a libc.so that didn't. ;-)
It's a lot easier to just have universal rules, and ignore the
fact that ELF lets you do these things, if you want to ignore the
fact that ELF was never written for static libraries in the first
place, and let people link things static. 8-) 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Crash upon exit from X
Hi
Yesterday I had crash just after exit from X and KDE3. Sources and
kernel are from 24 Oct. ~9:30 GMT.
Script started on Thu Oct 31 09:45:34 2002
bash-2.05b# gdb -k /usr/src/sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/c
rash/vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0239d18
stack pointer = 0x10:0xd6710c20
frame pointer = 0x10:0xd6710c58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 5d3h47m33s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:223
#1 0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#3 0xc027e982 in bwrite (bp=0xce4b8680) at ../../../kern/vfs_bio.c:796
#4 0xc027f039 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5 0xc033b1bf in ffs_fsync (ap=0xd6710a20) at ../../../ufs/ffs/ffs_vnops.c:236
#6 0xc033a4e9 in ffs_sync (mp=0xc4067200, waitfor=2, cred=0xc13c4e80,
td=0xc0436d40) at vnode_if.h:612
#7 0xc02939e8 in sync (td=0xc0436d40, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8 0xc0236a6b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc03a89a2 in trap_fatal (frame=0xd6710be0, eva=0)
at ../../../i386/i386/trap.c:846
#11 0xc03a8652 in trap_pfault (frame=0xd6710be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:760
#12 0xc03a80c2 in trap (frame=
{tf_fs = -697237480, tf_es = -1071382512, tf_ds = -1069088752, tf_edi =
-1005778304, tf_esi = 1, tf_ebp = -697234344, tf_isp = -697234420, tf_ebx = 0, tf_edx
= 0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071407848,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1005778060, tf_ss = 134217742}) at
../../../i386/i386/trap.c:446
#13 0xc0391328 in calltrap () at {standard input}:99
#14 0xc0243ffc in realitexpire (arg=0xc40d0a80)
at ../../../kern/kern_time.c:531
#15 0xc0244655 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc0223f54 in ithread_loop (arg=0xc13c6600)
at ../../../kern/kern_intr.c:535
#17 0xc0222e14 in fork_exit (callout=0xc0223d80 , arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:860
(kgdb) quit
bash-2.05b# exit
exit
Script done on Thu Oct 31 09:46:04 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
"M. Warner Losh" wrote: > : > This > : > example shows that we don't support it in printf, since the above > : > example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is. [ ... ] > Terry you are wrong. This has to do with the RANGE not the PRECISION > of the floating point number. It is ***NOT*** +Inf. I await an explanation of how you can fit 2*DBL_MAX into a double, which has a range of DBL_MIN..DBL_MAX. > You are wrong. You are confusing the precision of the mantissa with > the range of the exponent. I'm talking about the range of the double itself. When you round it, you don't jsut truncate the bits off the mantissa, you also increase the exponent. > Printf should *NOT* truncate to double before converting to print. > That's a bug too. I agree with the printf statement, but I don't see where printf is coing into the discussion. > Yes. > > : The main issue that I think is outstanding is that you can't get > : both exception behaviour and non-exception behaviour, and it is > : going to have to be the compiler's job to force the issue, because > : it can't dictate implementaiton to the host OS. > > I don't follow. I think that a number that's a 64 bit mantissa reaised to an exponent N takes a larger N if you have only 53 bits of mantissa, if you want to represent the same value. > : One problem is the initialization of the hardware (there was already > : a flags change for an initialization difference from what the compiler > : expects suggested in this thread -- to my mind, it's a workaround for > : the gcc generating header files, instead of taking the system's word > : for it). > > I don't follow. The obvious example in the FreeBSD case is the default value of the expression (fpgetprec() == FP_PE). The compiler is not permitted to assume, one way or the other; it has to do runtime testing, at the time you compile the compiler, to comply with a completely strict interpretation of C99 (IMO). It would have been nice if C99 provided a way to list the host defaults for use in compiling the compiler, since the host and the compiler have to cooperate, but there's no way to do this at run time because the standard failed to assign responsibility totally to the compiler vendor or totally to host OS. The closest possible approach will be for the compilation of the compiler to make some runtime tests to find out about the host environment. Really, it comes down to whether the host, or the compiler, owns math.h and float.h. According to my reading of C99, ownership is split between them. This kind of implies that the compiler gets to generate them however it wants, but that the host gets to dictate operation to the compiler, based on runtime tests the compiler is required to run to get the information. Since gcc supplies the crt0, it could always call fpsetprec(FP_PE); before starting to force the hardware into the compiler's preferred state. That's one answer, which makes it really hard to have a gcc and a TenDRA compiler that give the same results, if they happen to pick different defaults. The FP-using code would have to take all this into account, and be prepared to deal with all the possible allowed values. One workaround to this really ugly situation would be to define a host specific header file that's included by a host independent math.h and float.h to control its behaviour on a per-host basis, and then expect the host OS vendor to provide it, or the compiler to dig it out itself. It's better for the vendor to provide it, if the vendor wants any say in the matter at all (i.e. if the crt0 is going to call fpsetprec() to force the initial state, then why would the OS define an initial state that wasn't what the compiler wanted, so it could skip the set call?, etc.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > David Schultz wrote: > > > > We've been over this before. To make this work right, we need to make > > > > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > > > > solve the "oops!" and other foot shooting problems. > > > > > > Yes please. Our root filesystem space requirements are too high, IMHO. > > > > Why is it absolutely necessary to dynamically link everything just > > to move the resolver out of libc? > > Because ELF supports linking a shared library to another shared > library, which will automatically get you the appearance of the > historical "libresolv is integrated into libc". But it does not > support the linking of a static library to a static library, or > a static library to a shared library, the same way. At least in the case of the base system, it should be easy to link all programs that actually use the resolver with -lresolv. Is there some standard that says that the resolver is an integral part of the C library, such that separating the two would break compatibility beyond comprehension? If you wanted to be really evil, I suppose you could have a libc.a that included the resolver and a libc.so that didn't. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
David Schultz wrote: > > > We've been over this before. To make this work right, we need to make > > > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > > > solve the "oops!" and other foot shooting problems. > > > > Yes please. Our root filesystem space requirements are too high, IMHO. > > Why is it absolutely necessary to dynamically link everything just > to move the resolver out of libc? Because ELF supports linking a shared library to another shared library, which will automatically get you the appearance of the historical "libresolv is integrated into libc". But it does not support the linking of a static library to a static library, or a static library to a shared library, the same way. The ELF specification never expected things to be linked statically. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: > If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r > will break. The only way to really fix this is to export pthread_ symbols as > strong in libc_r. Exporting them as weak sounds like is a mistake which > should be fixed. You people keep saying this, and yet the code keeps working on Solaris. Either FreeBSD or Solaris has it wrong, and since the code works on Solaris... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
Yes, this makes a lot of sense to me. You are exercising the system in a way that breaks the LRU algorithm. The buffer cache, without your patch, is carefully tuned to deal with this case... that is why vm_page_dontneed() exists and why the vm_object code calls it. This creates a little extra work when the buffer cache cycles, but prevents the system from reusing pages that it actually needs under certainly types of load. In particular, the situation the system is saving itself from by making this call is the situation where a user is reading data file(s) sequentially which are far larger then can be reasonably cached. In that situation strict LRU operation would result in terrible performance due to the system attempting to unconditionally cache data it is going to have to throw away anyway, and soon, which displaces older cached data that it will actually need soon. LRU isn't always the best policy. When you disable vm_page_dontneed() the huge amount of data you are moving through the system create a huge amount of pressure on the rest of the VM system, thus the slower performance when your data operations exceed what can be reasonably cached. This would also have a severely detrimental effect on production systems running real loads. It's a tradeoff. The system is trading off some cpu overhead generally in order to deal with a fairly common heavy-loading case and in order to reduce the pressure on the VM system for situations (such as reading a large file sequentially) which have no business putting pressure on the VM system. e.g. the system is trying to avoid blowing away user B's cache when user A reads a huge file. Your patch is changing the tradeoff, but not really making things better overall. Sure, the buildworld test went faster, but that's just one type of load. I am somewhat surprised at your 32MB tests. Are you sure you stabilized the dd before getting those timings? It would take more then one run of the dd on the file to completely cache it (that's one of the effects of vm_page_dontneed(). Since the system can't predict whether a large file is going to be re-read over and over again, or just read once, or even how much data will be read, it depresses the priority of pages statistically so it might take several full reads of the file for the system to realize that you really do want to cache the whole thing. In anycase, 32MB dd's should be fully cached in the buffer cache, with no rewiring of pages occuring at all, so I'm not sure why your patch is faster for that case. It shouldn't be. Or the 64MB case. The 96MB case is getting close to what your setup can cache reasonably. The pre-patch code can deal with it, but with your patch you are probably putting enough extra pressure on the VM system to force the pageout daemon to run earlier then it would without the patch. The VM system is a very finely tuned beast. That isn't to say that it can't be improved, I'm sure it can, and I encourage you to play with it! But you have to be wary of it as well. The VM system is tuned primarily for performance under heavy loads. There is a slight loss of performance under light loads because of the extra management. You have to be sure not to screw up the heavy-load performance when running light-load benchmarks. A buildworld is a light load benchmark, primarily because it execs so programs so many times (the compiler) that there are a lot of free VM pages sitting around for it to use. Buildworlds do not load-test the VM system all that well! A dd test is not supposed to load-test the VM system either. This is why we have vm_page_dontneeds()'s.. user B's cache shouldn't be blown away just because user A is reading a large file. We lose a little in a light load test but gain a lot under real world loads which put constant pressure on the VM system. -Matt Matthew Dillon <[EMAIL PROTECTED]> :I tried that on the same PC as my last benchmark. The PC has 160MB :RAM, so I created a file of 256MB. : :One pre-read (in order to stabilize the buffer cache) and four read :tests were run consecutively for each of six distinct read sizes just :after boot. The average read times (in seconds) and speeds (in :MB/sec) are shown below: : : : without my patchwith my patch :read size timespeed timespeed :32MB .49765.5.47169.0 :64MB 1.0263.6.90172.1 :96MB 2.2450.55.5218.9 :128MB 20.76.1916.57.79 :192MB 32.95.8332.95.83 :256MB 42.56.02
Re: Lack of real long double support
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: > This
: > example shows that we don't support it in printf, since the above
: > example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is.
:
: That would be +Inf for double values... a 53 bit +Inf. But
: since it's being improperly treated as a 64 bit value, you don't
: get +Inf when you *should*. I think this case is about *not*
: getting an error you should get.
Terry you are wrong. This has to do with the RANGE not the PRECISION
of the floating point number. It is ***NOT*** +Inf.
: > The exponent range is ***NOT*** lost until printf truncates it, as my
: > test programs showed.
:
: Exactly! And it *should* be, because a double *is not* the same
: precision as a *long double*. A validation suite that tested edge
: conditions to ensure that there was a precision failure where there
: was supposed to be, and didn't get an expected failure, would mean
: it's broken.
You are wrong. You are confusing the precision of the mantissa with
the range of the exponent.
Printf should *NOT* truncate to double before converting to print.
That's a bug too.
: > The one issue that I've seen is
: >
: > long double a = 1.0L;
: > long double b = 1.0L + LDBL_EPSION
: > if (a == b) abort();
: >
: > which is what I'm trying to fix. (note, "1.0L" must be spelled
: > "oneld()" and long double oneld() { return (1.0L);}) to avoid the
: > optimizer getting it right.
:
: Heh. I saw that discussion; I think that's seperate.
Yes.
: The main issue that I think is outstanding is that you can't get
: both exception behaviour and non-exception behaviour, and it is
: going to have to be the compiler's job to force the issue, because
: it can't dictate implementaiton to the host OS.
I don't follow.
: One problem is the initialization of the hardware (there was already
: a flags change for an initialization difference from what the compiler
: expects suggested in this thread -- to my mind, it's a workaround for
: the gcc generating header files, instead of taking the system's word
: for it).
I don't follow.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
"M. Warner Losh" wrote:
> : The compiler must emit instructions to truncate and set flags, as
> : well as generating pseudo-exceptions (should they be called for)
> : in the case that the storage is in registers bigger than the memory
> : backing them. IT doesn't do this.
>
> I think I don't understand what you are saying at all. It doesn't
> seem top jive with the rest of the messages in this thread.
I mean that if there is a difference between doing the math in
registers vs. doing it in memory (or storing it in memory and
pulling it back in the registers, then you have two options:
1) Don't late-bind the FPU registers in the kernel, and take
a huge performance hit
2) Have the compiler generate code that will give the same
results as if the store and load had taken place
The gcc people argue that it's the kernel's job (do #1, not #2),
and the kernel argues that it's the compilers job (do #2, not #1).
> Except that's wrong, and further messages in the thread showed.
I didn't see a printf involved; Bruce was talking, as far as I
could tell, about a direct compare, with no printf() involved.
Are you maybe mixing this up with the "paranoia" tests?
The problem is that the double didn't give +Inf, like it should
have, because the rvalue was incorrectly promoted to long
double, instead of staying double, and overflowing (Bruce?
Correct this if it's wrong, please).
> This
> example shows that we don't support it in printf, since the above
> example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is.
That would be +Inf for double values... a 53 bit +Inf. But
since it's being improperly treated as a 64 bit value, you don't
get +Inf when you *should*. I think this case is about *not*
getting an error you should get.
> The exponent range is ***NOT*** lost until printf truncates it, as my
> test programs showed.
Exactly! And it *should* be, because a double *is not* the same
precision as a *long double*. A validation suite that tested edge
conditions to ensure that there was a precision failure where there
was supposed to be, and didn't get an expected failure, would mean
it's broken.
> The one issue that I've seen is
>
> long double a = 1.0L;
> long double b = 1.0L + LDBL_EPSION
> if (a == b) abort();
>
> which is what I'm trying to fix. (note, "1.0L" must be spelled
> "oneld()" and long double oneld() { return (1.0L);}) to avoid the
> optimizer getting it right.
Heh. I saw that discussion; I think that's seperate.
The main issue that I think is outstanding is that you can't get
both exception behaviour and non-exception behaviour, and it is
going to have to be the compiler's job to force the issue, because
it can't dictate implementaiton to the host OS.
One problem is the initialization of the hardware (there was already
a flags change for an initialization difference from what the compiler
expects suggested in this thread -- to my mind, it's a workaround for
the gcc generating header files, instead of taking the system's word
for it).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Nate Lawson wrote: > Here is a link to the size of various components of libc, ... Terry Lambert wrote: Move the resolver code out to ibresolv.so, ... Peter Wemm: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. Peter, Could you elaborate? I'm not sure I follow you. How would dynamically linking /bin and /sbin make "this" work right? Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Oct 30 22:06:00 PST 2002 -- ===> xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /home/tinderbox/ia64/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Oct 30 22:11:09 PST 2002 -- ===> xe cc1: warnings being treated as errors /local0/scratch/des/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /local0/scratch/des/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible pointer type *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
On Mon, 28 Oct 2002 00:54:57 -0800 (PST), Matthew Dillon <[EMAIL PROTECTED]> said: dillon> I can demonstrate the issue with a simple test. Create a large file dillon> with dd, larger then physical memory: dillon> dd if=/dev/zero of=test bs=1m count=4096# create a 4G file. dillon> Then dd (read) portions of the file and observe the performance. dillon> Do this several times to get stable numbers. dillon> dd if=test of=/dev/null bs=1m count=16 # repeat several times dillon> dd if=test of=/dev/null bs=1m count=32 # etc... dillon> You will find that read performance will drop in two significant dillon> places: (1) When the data no longer fits in the buffer cache and dillon> the buffer cache is forced to teardown wirings and rewire other dillon> pages from the VM page cache. Still no physical I/O is being done. dillon> (2) When the data no longer fits in the VM page cache and the system dillon> is forced to perform physical I/O. I tried that on the same PC as my last benchmark. The PC has 160MB RAM, so I created a file of 256MB. One pre-read (in order to stabilize the buffer cache) and four read tests were run consecutively for each of six distinct read sizes just after boot. The average read times (in seconds) and speeds (in MB/sec) are shown below: without my patchwith my patch read size timespeed timespeed 32MB.49765.5.47169.0 64MB1.0263.6.90172.1 96MB2.2450.55.5218.9 128MB 20.76.1916.57.79 192MB 32.95.8332.95.83 256MB 42.56.0243.05.95 dillon> Its case (1) that you are manipulating with your patch, and as you can dillon> see it is entirely dependant on the number of wired pages that the dillon> system is able to maintain in the buffer cache. The results of 128MB-read are likely to be so. 96MB-read gave interesting results. Since vfs_unwirepages() passes buffer pages to vm_page_dontneed(), it seems that the page scanner reclaims buffer cache pages too aggressively. The table below shows the results with my patch where vfs_unwirepages() does not call vm_page_dontneed(). read size timespeed 32MB.50363.7 64MB.91670.5 96MB4.5727.1 128MB 17.07.62 192MB 35.85.36 256MB 46.05.56 The 96MB-read results were a little bit better, although the reads of larger sizes became slower. The unwired buffer pages may be putting a pressure on user process pages and the page scanner. -- Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel with fresh drive
In message: <[EMAIL PROTECTED]> Jun Kuriyama <[EMAIL PROTECTED]> writes: : : I'm trying to install fresh 5.0-current from self-baked ISO. : : But when I select fresh drive at "Configure" -> "Label" in sysinstall, : sysinstall stalls (title, table, synopsis is printed, but no Part : rows). I can do Alt-F2 even if main screen cannot accept any command : keys. : : When I select already formatted drive, it works fine. : : Is there a possibility fresh drive is not supported in libdisk? I had similar issues when I tried to install pc98 onto a semi-virgin disk. I thought it was pc98 releated... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Thus spake Doug Rabson <[EMAIL PROTECTED]>: > > > Move the resolver code out to ibresolv.so, and link libc.so > > > against libresolv.so so that legacy applications are happy, as > > > long as they are compiled shared. Non-network apps can ignore > > > most of it. Internal use of some of the biggest chunks is > > > limited, so this should avoid dragging in a lot of it. > > > > We've been over this before. To make this work right, we need to make > > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > > solve the "oops!" and other foot shooting problems. > > Yes please. Our root filesystem space requirements are too high, IMHO. Why is it absolutely necessary to dynamically link everything just to move the resolver out of libc? I'm all for doing the latter, but I think dynamically linking /bin and /sbin is a really bad idea, for several reasons: - If the single user mode runtime includes several shared libraries, you have several additional points of failure. - The use of shared libraries incurs a performance hit for programs like sh and echo, which should be fast. o Exec time is greatly increased because you have to map in the libraries. o The -fPIC code in the shared libraries is slower, particularly on the register-starved i386. o The VM system has to do more work when you have a sparse virtual memory map, which is what you get when you stick shared libraries in the middle of your address space. - Using shared libraries for trusted binaries like sh has negative consequences for security. For example, a `feature' of OpenSSH allows users to circumvent restrictions imposed using /sbin/nologin, provided that /sbin/nologin is dynamically linked. I don't think the disk space argument outweighs these problems. There are a few binaries in /sbin that are bigger than they ought to be, but it isn't as though /bin and /sbin occupy 500 MB. Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. I have run into problems with dynamic linking in the past. In one case, I couldn't log into a Linux machine because the administrator (who used bash, of course) had tcsh linked against a version of glibc that didn't exist on his system. I would really hate to see FreeBSD open itself up to the same kinds of foot-shooting opportunities just because of the resolver, or for the sake of a few dozen megs of disk space. Of all things, don't dynamically link my shell. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
In message: <[EMAIL PROTECTED]> Peter Wemm <[EMAIL PROTECTED]> writes: : Terry Lambert wrote: : > Nate Lawson wrote: : > > Here is a link to the size of various components of libc, sorted by text : > > size. If you can find some way to reduce or even remove some of this, : > > please submit a patch. : > > : > > http://www.root.org/~nate/freebsd/lib_size.out : > : > Move the resolver code out to ibresolv.so, and link libc.so : > against libresolv.so so that legacy applications are happy, as : > long as they are compiled shared. Non-network apps can ignore : > most of it. Internal use of some of the biggest chunks is : > limited, so this should avoid dragging in a lot of it. : : We've been over this before. To make this work right, we need to make : /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would : solve the "oops!" and other foot shooting problems. Let's make / and /usr on the same partition by default, which makes this easy... :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen <[EMAIL PROTECTED]> wrote: > > If last weak will win, the normal case when Xthrstub is loaded > > _after_ libc_r will break. The only way to really fix this is to > > export pthread_ symbols as strong in libc_r. Exporting them as weak > > sounds like is a mistake which should be fixed. > > I disagree. See Solaris 6, 7, 8 & 9 for an example. > Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel with fresh drive
On Thu, 31 Oct 2002, Jun Kuriyama wrote: > I'm trying to install fresh 5.0-current from self-baked ISO. > > But when I select fresh drive at "Configure" -> "Label" in sysinstall, > sysinstall stalls (title, table, synopsis is printed, but no Part > rows). I can do Alt-F2 even if main screen cannot accept any command > keys. > > When I select already formatted drive, it works fine. > > Is there a possibility fresh drive is not supported in libdisk? Some errors I saw for ioctls on a fresh drive were reported in: <[EMAIL PROTECTED]> It may be the same problem you are seeing. I didn't get any responses to my message. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
* De: Loren James Rittle <[EMAIL PROTECTED]> [ Data: 2002-10-30 ] [ Subjecte: Re: Objective-C threads ] > > Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread > abstration layer and is better supported these days. It will also > correctly disable overhead related to threading when a program is > single-threaded using weak symbols. thr-posix doesn't do that... So *that's* where thr-gcc went! -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread abstration layer and is better supported these days. It will also correctly disable overhead related to threading when a program is single-threaded using weak symbols. thr-posix doesn't do that... Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
burncd hangs after 'blank'
Sorry if this is old news, but I've just discovered a problem in burncd.
If I do a 'blank' the operation completes but burncd then hangs. I have
a gdb session that shows the situation quite nicely: when burncd does
CDRIOCGETPROGRESS to get the number for the progress bar, it always
reports 0, and with no error, so burncd gets stuck in an infinite loop.
This really looks like an ioctl() issue more than a burncd one: either
CDRIOCGETPROGRESS shouldn't be allowed on 'blank' or it should return
valid information. Gdb session follows (sorry about the horrible
line-wrapping).
/usr/src/usr.sbin/burncd 10:23PM % sudo cc -O -pipe -g -march=athlon
-Wall -Wno-format-y2k -Wno-uninitialized -o burncd burncd.c
/usr/src/usr.sbin/burncd 10:26PM % sudo gdb burncd
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(gdb) r -s 4 -f /dev/acd0c blank
Starting program: /usr/src/usr.sbin/burncd/burncd -s 4 -f /dev/acd0c blank
^Zanking CD, please wait..
Program received signal SIGTSTP, Stopped (user).
0x280b0823 in nanosleep () from /usr/lib/libc.so.5
(gdb) bt
#0 0x280b0823 in nanosleep () from /usr/lib/libc.so.5
#1 0x280a594f in sleep () from /usr/lib/libc.so.5
#2 0x08049069 in main (argc=1, argv=0x2812247c) at burncd.c:194
#3 0x08048a80 in _start ()
(gdb) up 2
#2 0x08049069 in main (argc=1, argv=0x2812247c) at burncd.c:194
194 sleep(1);
(gdb) l
189 blank == CDR_B_ALL ?
"eras" : "blank");
190
191 if (ioctl(fd, CDRIOCBLANK, &blank) < 0)
192 err(EX_IOERR, "ioctl(CDRIOCBLANK)");
193 while (1) {
194 sleep(1);
195 error = ioctl(fd,
CDRIOCGETPROGRESS, &percent);
196 if (percent > 0 && !quiet)
197 fprintf(stderr,
198 "%sing CD - %d
%% done \r",
(gdb)
199 blank ==
CDR_B_ALL ?
200 "eras" :
"blank", percent);
201 if (error || percent == 100 ||
202 (percent == 0 && last ==
99))
203 break;
204 last = percent;
205 }
206 if (!quiet)
207 printf("\n");
208 continue;
(gdb) p error
$1 = 0
(gdb) p percent
$2 = 0
(gdb) p last
$3 = 0
(gdb) set last=99
(gdb) p last
$4 = 99
(gdb) c
Continuing.
Program exited normally.
(gdb) q
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Alexander Kabaev wrote: > On Wed, 30 Oct 2002 15:51:48 -0800 > Terry Lambert <[EMAIL PROTECTED]> wrote: > > > NO. > > > > If you have a library that's linked to a library containing string > > symbols, then no other library gets a chance to replace to symbols > > with its own strong symbols. The first strong symbol always wins, > > and the search is defined to be depth-first. > > You are ignoring the fact, that objects, loaded at the application startup > time are getting searched first, followed RTLD_GLOBAL objects, and finally by > the loaded object DAG. LD_PRELOAD objects override them all. > > > > > First strong/last weak should win. You are saying "last weak" is not > > winning. That's a linker bug. > > If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r > will break. The only way to really fix this is to export pthread_ symbols as > strong in libc_r. Exporting them as weak sounds like is a mistake which > should be fixed. I disagree. See Solaris 6, 7, 8 & 9 for an example. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > > > You need to link the library against libc_r.so instead of libXThrStub.so. > > Probably not. Doing that breaks the existing 'feature' of being able to > use X11 in entirely non-threaded programs. I'm not sure whether that is > acceptable. It also stops programs from being able to select between > several thread implementations, of which -current has two. > > I think the only sensible solution to this problem is for libraries which > provide an actual pthreads implementation (rather than a set of stubs) to > define strong symbols. Wierd debugging wrappers can still be achieved via > some dlopen/dlsym hackery. I don't really like this. It should be possible to have the same type of implementation as Solaris. How does X11 work for them? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002 15:51:48 -0800 Terry Lambert <[EMAIL PROTECTED]> wrote: > NO. > > If you have a library that's linked to a library containing string > symbols, then no other library gets a chance to replace to symbols > with its own strong symbols. The first strong symbol always wins, > and the search is defined to be depth-first. You are ignoring the fact, that objects, loaded at the application startup time are getting searched first, followed RTLD_GLOBAL objects, and finally by the loaded object DAG. LD_PRELOAD objects override them all. > > First strong/last weak should win. You are saying "last weak" is not > winning. That's a linker bug. If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel with fresh drive
I'm trying to install fresh 5.0-current from self-baked ISO. But when I select fresh drive at "Configure" -> "Label" in sysinstall, sysinstall stalls (title, table, synopsis is printed, but no Part rows). I can do Alt-F2 even if main screen cannot accept any command keys. When I select already formatted drive, it works fine. Is there a possibility fresh drive is not supported in libdisk? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-10-30 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] > > > Maybe the workaround for now is to make the symbols in libXThrStub.so > > > weak? > > > > They *are* weak Terry. The problem is that every bloody definition is weak > > so the linker has no way of picking the one definition which will actually > > work. The real problem is that the actual working threads library doesn't > > provide strong symbols to allow it to override all the other stubs. > > First strong/last weak should win. You are saying "last weak" is not > winning. That's a linker bug. Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. juli. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Followup: questions about the performance of current
Ok, so based on the promising response I got to my original 3 questions, I went ahead and upgraded. It went _very_ smoothly, with the help of UPDATING and some experience with this sort of thing. No make errors at any point. The only issues I hit were my fault, like forgetting to run mergemaster and then having pam lock me out, and forgetting to install perl and having half of my port rebuilds fail. D'oh. Every port I have built cleanly with the exception of games/xkobo (very minor, and I can file a PR if desired). (Also, the WITHOUT_COMPOSER hack to mozilla-devel seems to be broken, but that's a separate issue.) I am working on a write-up of my upgrade path, a sort of "Informal Guide to doing 4.X->current", which I will post to -doc when the network on the (non-FreeBSD) machine starts working again. So, to sum it up, my upgrading experience was excellent. Great work. - @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
< said: [rude snipe deleted...] Sorry, that was un-called-for (and was intended to be a private message to Warner). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
< said: > I think I don't understand what you are saying at all. It doesn't > seem top jive with the rest of the messages in this thread. Of course not, it's Terry ``Irrelevant Tangent'' Lambert you're taking about. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RCng Awkwardness
On Wed, Oct 30, 2002 at 02:23:48PM -0800, Tim Kientzle wrote: > Gordon Tetlow wrote: > > >On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote: > > > >>I find the standard arguments used by RCng quite > >>awkward. In particular, ... "/etc/rc.d/nfsd stop" does > >>not actually stop the nfsd process. ... > > > >... I've found this behavior to be quite annoying. I'll > >see if I can put something together. If you want to help me out and > >put together the patches, I'd be more than happy to commit them. > > > I have something partly sketched out, but > it still needs some work. I can > send you something in the next > couple of days to look at. > > I see two awkward issues: > > * Is it necessary to distinguish 'stop' > (unconditional stop) from 'shutdown' > (stop only if enabled)?? > > Seems that at system shutdown you want > everything to be taken down, regardless > of whether it was brought up at boot > or brought up manually post-boot. > The unconditional 'stop' seems to be > all that's needed. I agree, but can you make it use shutdown and just alias it to stop? This will be just in case we see a new need for a special shutdown case. > * Local rc scripts (in /usr/local/etc/rc.d) > will still get run with a 'start' > argument, while system scripts in > /etc/rc.d will get a 'boot' argument. > That's a bit awkward, but still > reasonably consistent: 'start' > is still an unconditional operation. That's fine. No big deal there. -gordon msg45718/pgp0.pgp Description: PGP signature
Re: Lack of real long double support
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > And there's a comment:
: > * 64-bit precision often gives bad results with high level languages
: > * because it makes the results of calculations depend on whether
: > * intermediate values are stored in memory or in FPU registers.
: > which seems like a compiler issue, not an OS issue to me.
:
: The compiler must emit instructions to truncate and set flags, as
: well as generating pseudo-exceptions (should they be called for)
: in the case that the storage is in registers bigger than the memory
: backing them. IT doesn't do this.
I think I don't understand what you are saying at all. It doesn't
seem top jive with the rest of the messages in this thread.
: This is the basis of Bruce's complaint:
:
:
:http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1099099+0+archive/2002/freebsd-current/20021027.freebsd-current
:
: | gcc can't actually support the full range, since it doesn't control
: | the runtime environement (it could issue a fninit before main() to
: | change the default, but it shouldn't and doesn't). The exponent
: | range is lost long before printf() is reached. E.g.,
: |
: | long double x= DBL_MAX;
: | long double y = 2 * x;
: |
: | gives +Inf for y since the result is doesn't fit in 53-bit precision.
: | The system header correctly reports this default precision. Any header
: | genrated by the gcc build should be no different, since the build should
: | run in the target environment.
Except that's wrong, and further messages in the thread showed. This
example shows that we don't support it in printf, since the above
example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is.
The exponent range is ***NOT*** lost until printf truncates it, as my
test programs showed.
The one issue that I've seen is
long double a = 1.0L;
long double b = 1.0L + LDBL_EPSION
if (a == b) abort();
which is what I'm trying to fix. (note, "1.0L" must be spelled
"oneld()" and long double oneld() { return (1.0L);}) to avoid the
optimizer getting it right.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: > > > For what its worth, doing this (defining strong pthread_* symbols in > > > libc_r) makes everything work fine, with or without libXThrStub. > > > > No, this would be bad. There's some justification for not > > doing this, in allowing programs linked againts libraries linked > > against threaded libraries to link against alternate threads > > libraries. If the symbols are stong, then this is not possible. > > Wrong. Either link the app to libc_r or to libpthread or to > libmyOwnThreads. NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. > > Maybe the workaround for now is to make the symbols in libXThrStub.so > > weak? > > They *are* weak Terry. The problem is that every bloody definition is weak > so the linker has no way of picking the one definition which will actually > work. The real problem is that the actual working threads library doesn't > provide strong symbols to allow it to override all the other stubs. First strong/last weak should win. You are saying "last weak" is not winning. That's a linker bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: > > You can't have a library that's sort of threaded and sort of not > > threaded: pick one. > > Yes you can - libX11 is *thread safe* but doesn't create threads. When a > real pthreads implementation is present, libX11 uses its implementation of > mutex, cond etc. to ensure its own safety. If the application doesn't link > to a real pthreads implementation, it uses no-op stubs instead. I'm still not understanding; you say that it's thread-safe, but mutex, cond, etc. are not, in fact, thread-safe. Why aren't the libc_r implementations overriding the do-nothing implementations? The entire point of weak vs. strong symbols is that the first strong symbol wins over any weak symbols. It seems to me that you are saying there is a linker recursion problem that is not being correctly addressed because no one wants to admit there is a problem. I guess my question is: if this is all so wrong, how is it that it doesn't fail on Solaris, which does the same thing? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Oct 30 15:09:20 PST 2002 -- >>> Kernel build for GENERIC completed on Wed Oct 30 15:41:24 PST 2002 -- >>> Kernel build for LINT started on Wed Oct 30 15:41:24 PST 2002 -- ===> vinum "Makefile", line 4517: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Peter Wemm wrote: > > Note that dynamically-linked executables take significantly longer to > > exec than statically-linked ones. > > Indeed yes. Running ld-elf.so.1 isn't free. Also, calling PIC libraries > isn't free either. Not only that, but even fork(2) is slower when you come > *from* a dynamic executable. I can't tell if he's complaining about runtime costs, or startup costs. Much of the runtime cost can be gotten rid of by thunking the code, at the expense of dirting the pages that make the references by replacing their reference targets with the addresses of the real functions. That's way overboard, for my tastes, but it's possible to remove the indirection overhead that way. The PIC overhead is likely unavoidable. I'd actually like to see the "benchmark" run on statically linked PIC vs. non-PIC code, so we can assign the proper portion of the blame for "PIC-ness". IMO, the cost is actually very small, given that you have to go over a 64K boundary before it becomes really expensive; relative branches are very common in non-PIC code. I think the expense in the the LD_PRELOAD treatment, and in the finding and mapping of the ld.so and library images... and that was designed to be avoidable by the ELF designers, even if most OSs never chose to properly implement it, and wedged ld.so loading into crt0, instead. > But for /bin/sh, then ~user etc doesn't work too well when your account > exists only somewhere like ldap. Just like /bin/ls -l doesn't show the > user and groups. > > Fortunately the costs associated with this are mostly one-off per exec and > are mostly lost in the noise when the commands being run are doing real > work. I agree. If you are concerned about the overhead, then at least assign the blame to the proper place; but for the most part, the concern is unwarranted. > In the days of monsters like mozilla, kde, gnome, gcc-3.x etc, dynamic > binary exec times seem to be the least of our worries. :-( AMEN. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > > I think the only sensible solution to this problem is for libraries which > > > provide an actual pthreads implementation (rather than a set of stubs) to > > > define strong symbols. Wierd debugging wrappers can still be achieved via > > > some dlopen/dlsym hackery. > > > > For what its worth, doing this (defining strong pthread_* symbols in > > libc_r) makes everything work fine, with or without libXThrStub. > > No, this would be bad. There's some justification for not > doing this, in allowing programs linked againts libraries linked > against threaded libraries to link against alternate threads > libraries. If the symbols are stong, then this is not possible. Wrong. Either link the app to libc_r or to libpthread or to libmyOwnThreads. > > Maybe the workaround for now is to make the symbols in libXThrStub.so > weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > > You need to link the library against libc_r.so instead of libXThrStub.so. > > > > Probably not. Doing that breaks the existing 'feature' of being able to > > use X11 in entirely non-threaded programs. I'm not sure whether that is > > acceptable. It also stops programs from being able to select between > > several thread implementations, of which -current has two. > > > > I think the only sensible solution to this problem is for libraries which > > provide an actual pthreads implementation (rather than a set of stubs) to > > define strong symbols. Wierd debugging wrappers can still be achieved via > > some dlopen/dlsym hackery. > > OK... I guess I don't understand the problem. > > If you are not compiling threaded programs for use with X, and > X itself is not threaded, then why the heck was the threads stuff > there in the first place? > > If X itself uses threads, then you need to use threads: there's > no option in the matter. > > If libX11.so does not reference, the threads symbols, who cares? > > If libX11.so *does* reference the threads symbols, then they need > to be there. > > You can't have a library that's sort of threaded and sort of not > threaded: pick one. Yes you can - libX11 is *thread safe* but doesn't create threads. When a real pthreads implementation is present, libX11 uses its implementation of mutex, cond etc. to ensure its own safety. If the application doesn't link to a real pthreads implementation, it uses no-op stubs instead. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
"M. Warner Losh" wrote: > And there's a comment: > * 64-bit precision often gives bad results with high level languages > * because it makes the results of calculations depend on whether > * intermediate values are stored in memory or in FPU registers. > which seems like a compiler issue, not an OS issue to me. The compiler must emit instructions to truncate and set flags, as well as generating pseudo-exceptions (should they be called for) in the case that the storage is in registers bigger than the memory backing them. IT doesn't do this. This is the basis of Bruce's complaint: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1099099+0+archive/2002/freebsd-current/20021027.freebsd-current | gcc can't actually support the full range, since it doesn't control | the runtime environement (it could issue a fninit before main() to | change the default, but it shouldn't and doesn't). The exponent | range is lost long before printf() is reached. E.g., | | long double x= DBL_MAX; | long double y = 2 * x; | | gives +Inf for y since the result is doesn't fit in 53-bit precision. | The system header correctly reports this default precision. Any header | genrated by the gcc build should be no different, since the build should | run in the target environment. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Dan Nelson wrote: > In the last episode (Oct 30), Doug Rabson said: > > On Wed, 30 Oct 2002, Peter Wemm wrote: > > > We've been over this before. To make this work right, we need to > > > make /bin and /sbin dynamically linked. NetBSD's /rescue/* > > > approach would solve the "oops!" and other foot shooting problems. > > > > Yes please. Our root filesystem space requirements are too high, > > IMHO. > > Note that dynamically-linked executables take significantly longer to > exec than statically-linked ones. Indeed yes. Running ld-elf.so.1 isn't free. Also, calling PIC libraries isn't free either. Not only that, but even fork(2) is slower when you come *from* a dynamic executable. But for /bin/sh, then ~user etc doesn't work too well when your account exists only somewhere like ldap. Just like /bin/ls -l doesn't show the user and groups. Fortunately the costs associated with this are mostly one-off per exec and are mostly lost in the noise when the commands being run are doing real work. In the days of monsters like mozilla, kde, gnome, gcc-3.x etc, dynamic binary exec times seem to be the least of our worries. :-( 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: libc size
Dan Nelson wrote: > In the last episode (Oct 30), Doug Rabson said: > > On Wed, 30 Oct 2002, Peter Wemm wrote: > > > We've been over this before. To make this work right, we need to > > > make /bin and /sbin dynamically linked. NetBSD's /rescue/* > > > approach would solve the "oops!" and other foot shooting problems. > > > > Yes please. Our root filesystem space requirements are too high, > > IMHO. > > Note that dynamically-linked executables take significantly longer to > exec than statically-linked ones. Running the following simple script > with getfacl and grep linked dynamically runs a little over twice as > slow as with them both static: I can't tell if the time difference is coming from where you say it's coming from, or if it's coming from somewhere else. If it's coming from where I think it's coming from, the answer is very easy: in the original ELF specification, the program offset in the UVM was very large, to permit "enough room" for the kernel to pre-mmap both the ld.so and the libc.so into the address space of each program before it started, making the decision after it faulted in the first page. This was the intentional design of the ELF initial offset being so large. Basically, this means that the template process that's used to start new processes following an exec can have a preinitialized shared address space for these areas, which will save the overhead that's probably contributing most to the problem. In other words, this is an exec/crt0 problem, not a static vs. dynamic problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
In message: <[EMAIL PROTECTED]> Bruce Evans <[EMAIL PROTECTED]> writes: : The reasons are the same as they used to be: incomplete language support : and incomplete library support. Language support is being completed but : is far from here yet. See the paper referenced in Loren's reply for more : details than anyone should want to know. OK. I'll have to go back and find that reference. I'd really like to change the __INITIAL_NPXCW__ from 0x127f to 0x137f in npx.h. I think that we can get the library support in place over time, as this already is a bullet item in the standards todo list web page. The gcc 3.2 compiler does a decent, but not perfect, job of dealing with the floating point stuff. I'll have to dive into the archive to find said paper. : > : > : gcc 3.3 will support a framework in which such changes would be easy : > : > : to convey at compile-time but, to my knowledge, there is no support : > : > : yet to obtain e.g. the precision setting at run-time. I.e. : > : : > : FreeBSD (on i386's) has fpgetprec() to get it and fpsetprec() to set it, : > : but these are nonstandard and won't become standard. They don't exist : > : on most or all non-i386's now, unlike fpget/setround() which will become : > : the standard feget/setround(). : > : > Is there some reason we can't just put them into the machine specific : > startup code like I've done with the tree. : : Putting them there would just blow away the kernel default. There are : arguments for putting the in both places, but not at the same time. : Linux seems to have gone the other way and move the initialization : from crt to the kernel. I'm not sure what happened to moves to set the : Linux default for Linux applications in the kernel. Yea, putting it in crt is bogus. Forget I suggested it. : C99 encourages having a behaviour that is known at compile time and : telling applications about it in FLT_EVAL_METHOD (this can be set to : -1 == indeterminable, but that would not be very useful although it : is the only correct setting now). The compiler should implement the : system implementor's choice or enforce its own choice. gcc doesn't : really understand this this. gcc-3.2 thinks that it implementing : method 0 (no extension of precision) but the npx hardware is nothing : like that. I don't understand this completely. ARe you saying that gcc is doing something worng? : The compiler doesn't have any special problems knowing the state of : the precision control on entry to functions. It just needs the initial : value to be set correctly and the state to not change underneath it : like it already requires for other aspects of the state. Changing the : state using fpset*() counts as changing the state underneath it here. I do understand this, which is why changing the defaults seems reasonable to me. BTW, NetBSD is kinda schizophrenic about this: /* * The i387 defaults to Intel extended precision mode and round to nearest, * with all exceptions masked. */ #define __INITIAL_NPXCW__ 0x037f /* NetBSD uses IEEE double precision. */ #define __NetBSD_NPXCW__0x127f /* FreeBSD leaves some exceptions unmasked as well. */ #define __FreeBSD_NPXCW__ 0x1272 /* iBCS2 goes a bit further and leaves the underflow exception unmasked. */ #define __iBCS2_NPXCW__ 0x0262 /* Linux just uses the default control word. */ #define __Linux_NPXCW__ 0x037f /* SVR4 uses the same control word as iBCS2. */ #define __SVR4_NPXCW__ 0x0262 So their float.h values are correct only for Linux binaries and emulation. Also, it looks like FreeBSD_NPXCW is incorrect, since we have: #define __INITIAL_NPXCW__ 0x127F And there's a comment: * 64-bit precision often gives bad results with high level languages * because it makes the results of calculations depend on whether * intermediate values are stored in memory or in FPU registers. which seems like a compiler issue, not an OS issue to me. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: > > I think the only sensible solution to this problem is for libraries which > > provide an actual pthreads implementation (rather than a set of stubs) to > > define strong symbols. Wierd debugging wrappers can still be achieved via > > some dlopen/dlsym hackery. > > For what its worth, doing this (defining strong pthread_* symbols in > libc_r) makes everything work fine, with or without libXThrStub. No, this would be bad. There's some justification for not doing this, in allowing programs linked againts libraries linked against threaded libraries to link against alternate threads libraries. If the symbols are stong, then this is not possible. Maybe the workaround for now is to make the symbols in libXThrStub.so weak? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: > > You need to link the library against libc_r.so instead of libXThrStub.so. > > Probably not. Doing that breaks the existing 'feature' of being able to > use X11 in entirely non-threaded programs. I'm not sure whether that is > acceptable. It also stops programs from being able to select between > several thread implementations, of which -current has two. > > I think the only sensible solution to this problem is for libraries which > provide an actual pthreads implementation (rather than a set of stubs) to > define strong symbols. Wierd debugging wrappers can still be achieved via > some dlopen/dlsym hackery. OK... I guess I don't understand the problem. If you are not compiling threaded programs for use with X, and X itself is not threaded, then why the heck was the threads stuff there in the first place? If X itself uses threads, then you need to use threads: there's no option in the matter. If libX11.so does not reference, the threads symbols, who cares? If libX11.so *does* reference the threads symbols, then they need to be there. You can't have a library that's sort of threaded and sort of not threaded: pick one. If you want a seperate libdlopen, then I can help you: I did some of the code necessary to implement this already, but stopped because there needs to be a change to the constructor arguments to pass the address of the arg list down to the constructors, so you can use a constructor section in a linker set to do the init that's necessary to get at the symbols. I didn't want to have to fight the rest of you to get that mod into libc and the crt0 code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with 5.0 current release in case of multiple PCI busses ...
Hello, I am using a Force 4203 motherboard which has multiple PCIX busses. Devices on PCIX busses > 0 are not detected. This is the dmesg with ACPI enabled. Note that I have actually put the printf's for the vendor id's and device id's in the bge driver since the BCM5701 NIC does not get detected. Copyright (c) 1992-2002 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-20020917-JPSNAP #12: Wed Oct 30 17:54:30 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0682000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06820a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2399668260 Hz CPU: Pentium 4 (2399.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 3758096384 (3670016K bytes) avail memory = 3649335296 (3563804K bytes) Using $PIR table, 10 entries at 0xc00fded0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_cpu2: on acpi0 acpi_cpu3: on acpi0 pcib1: port 0xcf8-0xcff on acpi0 pci0: on pcib1 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0014 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1166 The device id is : 0x0015 The vendor id is : 0x1002 The device id is : 0x4752 The vendor id is : 0x1002 The device id is : 0x4752 The vendor id is : 0x1002 The device id is : 0x4752 The vendor id is : 0x1002 The device id is : 0x4752 The vendor id is : 0x1002 The device id is : 0x4752 The vendor id is : 0x1002 The device id is : 0x4752 pci0: at device 5.0 (no driver attached) The vendor id is : 0x1166 The device id is : 0x0201 The vendor id is : 0x1166 The device id is : 0x0201 The vendor id is : 0x1166 The device id is : 0x0201 The vendor id is : 0x1166 The device id is : 0x0201 The vendor id is : 0x1166 The device id is : 0x0201 The vendor id is : 0x1166 The device id is : 0x0201 atapci0: port 0x1400-0x140f,0x374-0x377,0x170-0 x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 The vendor id is : 0x1166 The device id is : 0x0225 The vendor id is : 0x1166 The device id is : 0x0225 The vendor id is : 0x1166 The device id is : 0x0225 The vendor id is : 0x1166 The device id is : 0x0225 The vendor id is : 0x1166 The device id is : 0x0225 The vendor id is : 0x1166 The device id is : 0x0225 isab0: at device 15.3 on pci0 isa0: on isab0 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 The vendor id is : 0x1166 The device id is : 0x0101 pcib2: on acpi0 pcib2: duplicate bus number 0 - not probing bus pcib4: on acpi0 pcib4: duplicate bus number 0 - not probing bus pcib5: on acpi0 pcib5: duplicate bus number 0 - not probing bus pcib6: on acpi0 pcib6: duplicate bus number 0 - not probing bus atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 pcib3: at pcibus 3 on motherboard pci3: on pcib3 orm0: at iomem 0xc9800-0xcafff,0xc8000-0xc97ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa
Re: libc size
In the last episode (Oct 30), Doug Rabson said: > On Wed, 30 Oct 2002, Peter Wemm wrote: > > We've been over this before. To make this work right, we need to > > make /bin and /sbin dynamically linked. NetBSD's /rescue/* > > approach would solve the "oops!" and other foot shooting problems. > > Yes please. Our root filesystem space requirements are too high, > IMHO. Note that dynamically-linked executables take significantly longer to exec than statically-linked ones. Running the following simple script with getfacl and grep linked dynamically runs a little over twice as slow as with them both static: #! /bin/sh for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/* ; do if ! getfacl "$i" | grep -q owner:0 ; then echo "owner of $i is not root" fi done Static: 3.20r 0.16u 3.59s Dynamic: 6.88r 1.60u 7.03s 3.62r 0.18u 3.50s6.82r 2.08u 6.56s 3.26r 0.22u 3.52s6.92r 1.35u 7.26s 3.23r 0.16u 3.62s7.59r 1.25u 7.48s 3.26r 0.19u 3.65s7.74r 1.66u 7.42s 3.63r 0.16u 3.76s7.17r 1.67u 7.15s 6 runs, alternatic static and dynamic scripts for each run. I actually link quite a few binaries in /usr/bin and /usr/sbin static (awk, basename, dirname, find, head, install, sed, tr, uniq, wc). Try this: enable process accounting, run "make fetch-recursive-list" in ports/www/mozilla, then run lastcomm and see how many times tr, sed, basename, sh, and grep got called. Linking these static makes a big difference. As a compromise, how about converting the major space wasters in /bin and /sbin to dynamic but leaving the rest? Except for /bin/sh, none of them are run often enough to matter. -r-xr-xr-x 1 root wheel 475108 Sep 7 17:50 /sbin/routed* -r-xr-xr-x 1 root wheel 495943 Sep 7 17:50 /sbin/fore_dnld* -r-xr-xr-x 1 root wheel 521654 Oct 22 12:14 /sbin/tunefs* -r-xr-xr-x 1 root wheel 528572 Sep 7 17:46 /bin/pax* -r-xr-xr-x 1 root wheel 532428 Sep 7 17:46 /bin/ls* -r-xr-xr-x 1 root wheel 605588 Sep 7 17:50 /sbin/ipfstat* -r-xr-xr-x 1 root wheel 616277 Sep 7 17:50 /sbin/ilmid* -r-xr-xr-x 1 root wheel 670188 Sep 7 17:50 /sbin/fsdb* -r-xr-xr-x 1 root wheel 695512 Sep 7 17:50 /sbin/vinum* -r-xr-xr-x 1 root wheel 713372 Oct 8 00:44 /bin/sh* -r-xr-xr-x 1 root wheel 752168 Sep 7 17:58 /sbin/dhclient* -r-xr-xr-x 2 root wheel 844512 Sep 7 17:46 /bin/tcsh* -r-xr-xr-x 1 root wheel 3214381 Oct 25 10:29 /sbin/ipfw* -r-xr-xr-x 2 root wheel 3420946 Oct 25 16:02 /sbin/rdump* -r-xr-xr-x 3 root wheel 3464372 Oct 22 12:07 /sbin/fsck_ufs* -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc in CURRENT fails as of 1200 GMT today
On Wed, Oct 30, 2002 at 08:55:05PM +, Daniel Flickinger wrote:
> Sent: Wed, 30 Oct 2002 09:02:17 -0800 by Marcel Moolenaar
>
> On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote:
>> /usr/src/lib/libc/uuid/uuid_compare.c:31:18: uuid.h: No such file \
>> or directory
>+> [snip]
>+>
>+> and a couple pages of resulting syntax errors
>+
>+ I assume you didn't do a makeworld, but just a make in libc?
>
> No, I go for broke...
>
> make -j 4 -k -s ${TFLG} buildworld
What is ${TFLG}?
I just did
cvsup /root/supfile
cd /usr/obj
rm -rf *
cd /usr/src
make -j 4 buildworld
Everything built without a problem on my athlon system.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Terry Lambert wrote: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Nate Lawson wrote: > > > > Here is a link to the size of various components of libc, sorted by tex t > > > > size. If you can find some way to reduce or even remove some of this, > > > > please submit a patch. > > > > > > > > http://www.root.org/~nate/freebsd/lib_size.out > > > > > > Move the resolver code out to ibresolv.so, and link libc.so > > > against libresolv.so so that legacy applications are happy, as > > > long as they are compiled shared. Non-network apps can ignore > > > most of it. Internal use of some of the biggest chunks is > > > limited, so this should avoid dragging in a lot of it. > > > > We've been over this before. To make this work right, we need to make > > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > > solve the "oops!" and other foot shooting problems. > > Or add: > > LDFLAGS+= -lresolv > > To the Makefiles of the things that need to be statically linked, > and access the network code. Except that getpwent() etc have got hard coded references to yp, and yp has got hard coded references to getXXXbyYYY(), which has references to libresolv. The number of things that are infected by this is quite big. This means a good number of things in /bin and /sbin would have to have -lresolv added. And that defeats the point. All that we do is move the bloat from one library to another. It's the same problem with the db embedded in there - getpwent() uses it via the pwd.db stuff. And then there's the cgetent() stuff that that *curses uses to access termcap.db. And login.conf.db. And so on. > I'm going to go out on a limb here, though, and guess that without > a resolv.conf, most of the resolver library is going to be really > useless. 8-) 8-). Except to satisfy internal dependencies. > -- Terry > 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: libc]Re: gnome on current
Doug Rabson wrote: > On Wed, 30 Oct 2002, Daniel Eischen wrote: > > Well, it must have the same problem with Solaris then. Somehow, > > you've got to force it to link libc_r before libc... > > The only way I can see to do that is to link libX11, libXt and friends > against libc_r. What this comes down to is that we've grown a distruct of libc_r, and we think that the things that are pulling the threads in have no business running threads, or forcing your program to link threaded when it's not using threads. The problem is that they *are* using threads, if they are using a library that uses threads. In the Western U.S., we'd say "Cowboy Up, and eat the overhead!". If there are going to be libraries which, by their nature, suck threads in, then we are just going to have to live with it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Peter Wemm wrote: > Terry Lambert wrote: > > Nate Lawson wrote: > > > Here is a link to the size of various components of libc, sorted by text > > > size. If you can find some way to reduce or even remove some of this, > > > please submit a patch. > > > > > > http://www.root.org/~nate/freebsd/lib_size.out > > > > Move the resolver code out to ibresolv.so, and link libc.so > > against libresolv.so so that legacy applications are happy, as > > long as they are compiled shared. Non-network apps can ignore > > most of it. Internal use of some of the biggest chunks is > > limited, so this should avoid dragging in a lot of it. > > We've been over this before. To make this work right, we need to make > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > solve the "oops!" and other foot shooting problems. Or add: LDFLAGS+= -lresolv To the Makefiles of the things that need to be statically linked, and access the network code. I'm going to go out on a limb here, though, and guess that without a resolv.conf, most of the resolver library is going to be really useless. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rc.d and sysctl.conf
/etc/rc runs /etc/rc.sysctl twice: one "early", after mounting filesystems, reseeding the random number generator and adding a swap file, and before running rc.serial, rc.pccard, rc.network. one "late", after network_pass4 but before raising the securelevel. This was added in response to http://www.freebsd.org/cgi/query-pr.cgi?pr=19629 The update to the /etc/rc.d infrastructure keeps the ability to run twice, but does not actually run it twice. I started creating an /etc/rc.d/sysctl-last that would run "/etc/rc.d/sysctl lastload", but realized that I didn't know how to say where the first/second call should go. To strictly follow /etc/rc.d, I could change the existing /etc/rc.d/sysctl to say "BEFORE: serial" and add "BEFORE: securelevel" to sysctl-last, but I'm not sure this is appropriate given the meta-checkpoints that we have. (It also raises the question of if /etc/rc.d/securelevel actually runs at the right time. /etc/rc puts it almost at the absolute end, while rcorder sticks it somewhere in the middle -- number 67 of 102 on my system.) Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > Doug Rabson wrote: > > > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > > Daniel Eischen wrote: > > > > > Patch looks correct. > > > > > > > > Please commit? 8-). > > > > > > Well I made a libc with this patch and rebuilt XFree86-4-libraries without > > > libXThrStub but I ran into problems compiling the clients. The clients > > > *require* someone in the link to supply the pthread_* symbols and libc.so > > > only had _pthread_* symbols. I added some more weak references to libc.so > > > but that just gets us back to square one. > > > > > > The problem is that the sawfish configuration tools are written using some > > > extensible lisp/scheme thing called rep. The main rep binary links against > > > libc.so so that occurs early in the list. Later on stacks of libraries are > > > loaded dynamically, some of which depend on libc_r.so. Unfortunately > > > libc_r.so is far too late in the list to get a lookin and it dies in > > > exactly the same way as before, for the same reason (calling a > > > non-functional stub version of pthread_setspecific(). > > > > You need to link the library against libc_r.so instead of libXThrStub.so. > > Probably not. Doing that breaks the existing 'feature' of being able to > use X11 in entirely non-threaded programs. I'm not sure whether that is > acceptable. It also stops programs from being able to select between > several thread implementations, of which -current has two. > > I think the only sensible solution to this problem is for libraries which > provide an actual pthreads implementation (rather than a set of stubs) to > define strong symbols. Wierd debugging wrappers can still be achieved via > some dlopen/dlsym hackery. For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RCng Awkwardness
Gordon Tetlow wrote: On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote: I find the standard arguments used by RCng quite awkward. In particular, ... "/etc/rc.d/nfsd stop" does not actually stop the nfsd process. ... ... I've found this behavior to be quite annoying. I'll see if I can put something together. If you want to help me out and put together the patches, I'd be more than happy to commit them. I have something partly sketched out, but it still needs some work. I can send you something in the next couple of days to look at. I see two awkward issues: * Is it necessary to distinguish 'stop' (unconditional stop) from 'shutdown' (stop only if enabled)?? Seems that at system shutdown you want everything to be taken down, regardless of whether it was brought up at boot or brought up manually post-boot. The unconditional 'stop' seems to be all that's needed. * Local rc scripts (in /usr/local/etc/rc.d) will still get run with a 'start' argument, while system scripts in /etc/rc.d will get a 'boot' argument. That's a bit awkward, but still reasonably consistent: 'start' is still an unconditional operation. I don't see any way around this without breaking existing systems after upgrade. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
On Wed, 30 Oct 2002, Peter Wemm wrote: > Terry Lambert wrote: > > Nate Lawson wrote: > > > Here is a link to the size of various components of libc, sorted by text > > > size. If you can find some way to reduce or even remove some of this, > > > please submit a patch. > > > > > > http://www.root.org/~nate/freebsd/lib_size.out > > > > Move the resolver code out to ibresolv.so, and link libc.so > > against libresolv.so so that legacy applications are happy, as > > long as they are compiled shared. Non-network apps can ignore > > most of it. Internal use of some of the biggest chunks is > > limited, so this should avoid dragging in a lot of it. > > We've been over this before. To make this work right, we need to make > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > solve the "oops!" and other foot shooting problems. Yes please. Our root filesystem space requirements are too high, IMHO. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > > Patch looks correct. > > > > > > Please commit? 8-). > > > > Well I made a libc with this patch and rebuilt XFree86-4-libraries without > > libXThrStub but I ran into problems compiling the clients. The clients > > *require* someone in the link to supply the pthread_* symbols and libc.so > > only had _pthread_* symbols. I added some more weak references to libc.so > > but that just gets us back to square one. > > > > The problem is that the sawfish configuration tools are written using some > > extensible lisp/scheme thing called rep. The main rep binary links against > > libc.so so that occurs early in the list. Later on stacks of libraries are > > loaded dynamically, some of which depend on libc_r.so. Unfortunately > > libc_r.so is far too late in the list to get a lookin and it dies in > > exactly the same way as before, for the same reason (calling a > > non-functional stub version of pthread_setspecific(). > > You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc in CURRENT fails as of 1200 GMT today
[The crucial question is hidden somewhere...] On Wed, Oct 30, 2002 at 08:55:05PM +, Daniel Flickinger wrote: > Sent: Wed, 30 Oct 2002 09:02:17 -0800 by Marcel Moolenaar > > On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote: > + > /usr/src/lib/libc/uuid/uuid_compare.c:31:18: uuid.h: No such file or directory > + > [snip] > + > > + > and a couple pages of resulting syntax errors > + > > + > + I assume you didn't do a makeworld, but just a make in libc? > > No, I go for broke... Why doubt if you can be sure :-) > I 'buildworld' at least once a day based on 1200 GMT > --other times, if necessary. The system is CURRENT as of > 1800 GMT 27 Oct 2002, both kernel and world. The last two > days have had too many errors to go for installworld. I buildworld alpha, i386 and ia64 yesterday without any problems. I did an installworld for alpha and ia64 without problems. The i386 installworld is going to happen once I'm home. The point: I have no idea what problems you're referring to other than the typical "commit->breakage->fix" cycles we have. > find /usr -name 'uuid\.h' -print > > /usr/obj/usr/src/i386/usr/include/uuid.h > /usr/include/sys/uuid.h > /usr/src/lib/libc/uuid/uuid.h > /usr/src/sys/sys/uuid.h This list is correct. Note that /usr/obj/usr/src/i386/usr/include/sys is a link to /usr/src/sys/sys. This explains why you don't see sys/uuid.h under /usr/obj/usr/src/i386/usr/include, but it's visible there alright. > However, after running the script above we now have a > uuid.h in both /usr/include and /usr/include/sys: > > find /usr -name 'uuid\.h' -print > > /usr/obj/usr/src/i386/usr/include/uuid.h > /usr/include/sys/uuid.h > /usr/include/uuid.h > /usr/src/lib/libc/uuid/uuid.h > /usr/src/sys/sys/uuid.h However? This is correct again. > The include/uuid.h reads in the sys/uuid.h file. This now > provides a fallback, masking the real problem. [here it is] Could you explain to me what you think the real problem actually is? So far you described correct behaviour and labeled it as broken, so you have to excuse me if I prefer to assume as little as possible now. > Both files are present in the src tree --which is where > 'make buildworld' SHOULD find them and place them in the > /usr/obj tree during buildworld. There is a missing -I > declaration ... or cp or install statement. It is finding both in the object dir. At least on my systems. I specifically tested this by removing /usr/include/uuid.h prior to starting a buildworld that didn't had -DNOCLEAN. > It SHOULD NOT be necessary to run 'make > build/installincludes' prior to 'make buildworld' Correct and that's what it currently is: not necessary. > After 23 years of BSD, it's just another day... Happiness devaluates just as money does. After experiencing the joy of BSD for 23 years I'm not surprised that you've grown not to notice it anymore and thus that it feels like just another day. Try Windows for an hour and you'll feel alive and refreshed again... :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Daniel Eischen wrote: > On Wed, 30 Oct 2002, Doug Rabson wrote: > > > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > > > Daniel Eischen wrote: > > > > > That's bizarre... it's defined in libc_r, so there's no reason for > > > > > the omission in libc. > > > > > > > > I only added stubs that I thought the implementation of libc used > > > > (or would use). > > > > > > Makes sense. > > > > > > Actually, it looks like most of this could be done with macros, > > > including the function definitions, so that we are just dealing > > > with lists; I didn't go that far with it. > > > > > > > > > > > Please find attached a patch that corrects this. > > > > > > > > Patch looks correct. > > > > > > Please commit? 8-). > > > > Well I made a libc with this patch and rebuilt XFree86-4-libraries without > > libXThrStub but I ran into problems compiling the clients. The clients > > *require* someone in the link to supply the pthread_* symbols and libc.so > > only had _pthread_* symbols. I added some more weak references to libc.so > > but that just gets us back to square one. > > I think Terry might be right in suggesting using a macro to automate > all the link and stub generation... > > > The problem is that the sawfish configuration tools are written using some > > extensible lisp/scheme thing called rep. The main rep binary links against > > libc.so so that occurs early in the list. Later on stacks of libraries are > > loaded dynamically, some of which depend on libc_r.so. Unfortunately > > libc_r.so is far too late in the list to get a lookin and it dies in > > exactly the same way as before, for the same reason (calling a > > non-functional stub version of pthread_setspecific(). > > Well, it must have the same problem with Solaris then. Somehow, > you've got to force it to link libc_r before libc... The only way I can see to do that is to link libX11, libXt and friends against libc_r. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: questions about the state of current
On Wednesday, October 30, 2002, at 11:43 AM, Doug Rabson wrote: I compiled kde3 a week or so ago on my laptop running -current and it is now my new desktop, so I think reports of kde being totally hosed are a bit exagerated or perhaps dated. Hmm. I compiled it a few days ago and it was quite broken. It died in kdeinit very quickly. I will probably retest after sorting out the X threading problems as I have a hunch this is related. Okay, I am going t o delurk for a few minutes and put in my little bit... I did a clean -current boxen from scratch over the weekend and I have been able to get the following work, (some via ports others by packages) Netscape Mozilla OpenOffice XFree86 many small things gaim, bash, pico, xemacs, vim, ghostview, acrobat, etc However KDE compile install fails from ports, I tried an old packages version of it , get installed, when I go to run it, it tanks. This could just be a local issue, and I have not had time to test it more... Thats my story, and I don't always stick to it. CH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Terry Lambert wrote: > Nate Lawson wrote: > > Here is a link to the size of various components of libc, sorted by text > > size. If you can find some way to reduce or even remove some of this, > > please submit a patch. > > > > http://www.root.org/~nate/freebsd/lib_size.out > > Move the resolver code out to ibresolv.so, and link libc.so > against libresolv.so so that legacy applications are happy, as > long as they are compiled shared. Non-network apps can ignore > most of it. Internal use of some of the biggest chunks is > limited, so this should avoid dragging in a lot of it. We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the "oops!" and other foot shooting problems. 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: RCng Awkwardness
Gordon Tetlow writes:
> On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote:
> > I find the standard arguments used by RCng quite
> > awkward. In particular, especially for people who
> > have worked with SysV-style init scripts, it's
> > rather surprising that "/etc/rc.d/nfsd stop" does
> > not actually stop the nfsd process. Likewise, 'start'
> > doesn't actually start the specified system.
>
> As one of the people that supposedly worked on this. I'm heartily in
> favor of this. I've found this behavior to be quite annoying. I'll
> see if I can put something together. If you want to help me out and
> put together the patches, I'd be more than happy to commit them.
>
> -gordon
Even more annoyingly, the RCng nfsd script ignores arguments specified
in /etc/rc.conf. See the example below, where "nfsd" is my patched
script, "nfsd.old" is what is in CVS now. Patch appended.
% grep nfs /etc/rc.conf
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 8 -h 172.31.193.10 -h 172.31.193.1"
% ./nfsd.old stop
nfsd not running?
% sudo ./nfsd.old start
Starting nfsd.
% ps ax | grep nfsd | wc -l
5
%sudo ./nfsd.old stop
Stopping nfsd.
kill: 2903: No such process
kill: 2905: No such process
<4:33pm>whisper/gallatin:rc.d>ps ax | grep nfsd | wc -l
0
% sudo ./nfsd start
Starting nfsd.
% ps ax | grep nfsd | wc -l
9
%
Note that the default script ignores the arguments -n 8 and starts
only 4 nfsds.
Can this be fixed, please?
Thanks,
Drew
cvs diff nfsd
Index: nfsd
===
RCS file: /home/ncvs/src/etc/rc.d/nfsd,v
retrieving revision 1.8
diff -u -r1.8 nfsd
--- nfsd12 Oct 2002 10:31:31 - 1.8
+++ nfsd24 Oct 2002 23:57:27 -
@@ -13,6 +13,7 @@
name="nfsd"
rcvar=`set_rcvar nfs_server`
command="/usr/sbin/${name}"
+load_rc_config $name
case ${OSTYPE} in
FreeBSD)
@@ -51,5 +52,4 @@
return 0
}
-load_rc_config $name
run_rc_command "$1"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: > On Wed, 30 Oct 2002, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > > That's bizarre... it's defined in libc_r, so there's no reason for > > > > the omission in libc. > > > > > > I only added stubs that I thought the implementation of libc used > > > (or would use). > > > > Makes sense. > > > > Actually, it looks like most of this could be done with macros, > > including the function definitions, so that we are just dealing > > with lists; I didn't go that far with it. > > > > > > > > Please find attached a patch that corrects this. > > > > > > Patch looks correct. > > > > Please commit? 8-). > > Well I made a libc with this patch and rebuilt XFree86-4-libraries without > libXThrStub but I ran into problems compiling the clients. The clients > *require* someone in the link to supply the pthread_* symbols and libc.so > only had _pthread_* symbols. I added some more weak references to libc.so > but that just gets us back to square one. I think Terry might be right in suggesting using a macro to automate all the link and stub generation... > The problem is that the sawfish configuration tools are written using some > extensible lisp/scheme thing called rep. The main rep binary links against > libc.so so that occurs early in the list. Later on stacks of libraries are > loaded dynamically, some of which depend on libc_r.so. Unfortunately > libc_r.so is far too late in the list to get a lookin and it dies in > exactly the same way as before, for the same reason (calling a > non-functional stub version of pthread_setspecific(). Well, it must have the same problem with Solaris then. Somehow, you've got to force it to link libc_r before libc... -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Nate Lawson wrote: > Here is a link to the size of various components of libc, sorted by text > size. If you can find some way to reduce or even remove some of this, > please submit a patch. > > http://www.root.org/~nate/freebsd/lib_size.out Move the resolver code out to ibresolv.so, and link libc.so against libresolv.so so that legacy applications are happy, as long as they are compiled shared. Non-network apps can ignore most of it. Internal use of some of the biggest chunks is limited, so this should avoid dragging in a lot of it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: > On Wed, 30 Oct 2002, Terry Lambert wrote: > > Daniel Eischen wrote: > > > Patch looks correct. > > > > Please commit? 8-). > > Well I made a libc with this patch and rebuilt XFree86-4-libraries without > libXThrStub but I ran into problems compiling the clients. The clients > *require* someone in the link to supply the pthread_* symbols and libc.so > only had _pthread_* symbols. I added some more weak references to libc.so > but that just gets us back to square one. > > The problem is that the sawfish configuration tools are written using some > extensible lisp/scheme thing called rep. The main rep binary links against > libc.so so that occurs early in the list. Later on stacks of libraries are > loaded dynamically, some of which depend on libc_r.so. Unfortunately > libc_r.so is far too late in the list to get a lookin and it dies in > exactly the same way as before, for the same reason (calling a > non-functional stub version of pthread_setspecific(). You need to link the library against libc_r.so instead of libXThrStub.so. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: speed of -CURRENT [was: questions about the state of current]
> The systems hostname was changed between Aug & Oct, but it's the > same laptop, a P3-800 w/256MB memory. > > Thoughts? > I have not really noticed a performance difference here. In fact with WITNESS and INVARIANTS disabled, I find that -CURRENT seems to be a bit faster than -STABLE. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libc size
After a discussion on cvs-all regarding size of our libc, I wrote a quick script to see where the problems are. A cursory glance at its output shows there are numerous things we can improve, including: * setproctitle(3) uses 4k of static scratch buffers when it could allocate these on the stack (let alone reducing the length of the proc title to something more reasonable than 2k). * vfwprintf and vfprintf are near duplicates of each other (in fact, the former is derived from the latter). Each uses 14k of text so this could be split in half by combining them and selecting different behavior with a flag. Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > > That's bizarre... it's defined in libc_r, so there's no reason for > > > the omission in libc. > > > > I only added stubs that I thought the implementation of libc used > > (or would use). > > Makes sense. > > Actually, it looks like most of this could be done with macros, > including the function definitions, so that we are just dealing > with lists; I didn't go that far with it. > > > > > Please find attached a patch that corrects this. > > > > Patch looks correct. > > Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's this for ?
Terry Lambert wrote: > You're right... I confused the "Live FS" with the "Live CD", > which is a seperate image distribution. Sorry for the bum > information. FWIW, on the original question of "what is it for", I personally tend to use it to create chroot environments for hosted builds across FreeBSD versions. For this to work, you have to copy in all the applications that care about sizeof(struct proc) and the network structures (e.g. "w", "ps", "netstat", etc.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make relase, new mode of breakage...
Fresh -current, fresh fracture: cd /usr/src/release/..; make TARGET_ARCH=i386 TARGET=i386 -j12 -DNO_MAKEDB_RUN -DMAKE_KERBEROS5 SUBDIR_OVERRIDE="kerberos5 lib/libpam lib/libssh secure/usr.bi n/ssh secure/usr.sbin/sshd" buildworld distributeworld DISTDIR=/R/stage/trees -- >>> stage 2: cleaning up the object tree -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE = GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/sr c/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tma c DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/ usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i38 6/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 par-cleandir ===> kerberos5 ===> lib/libpam ===> lib/libssh cd: can't cd to /usr/src/lib/libssh ===> secure/usr.bin/ssh *** Error code 2 ===> kerberos5/doc -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's this for ?
John Baldwin wrote: > > It's an installed FreeBSD that is on a CDROM. It depends on your > > BIOS being able to boot the FS as if it were a hard disk image. > > Huh? It doesn't do that. If it is bootable, then it boots into > sysinstall just like CD #1. What it is useful for is to be used > as a fixit CD. We don't boot it as a hard drive though. You're right... I confused the "Live FS" with the "Live CD", which is a seperate image distribution. Sorry for the bum information. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RCng Awkwardness
On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote: > I find the standard arguments used by RCng quite > awkward. In particular, especially for people who > have worked with SysV-style init scripts, it's > rather surprising that "/etc/rc.d/nfsd stop" does > not actually stop the nfsd process. Likewise, 'start' > doesn't actually start the specified system. As one of the people that supposedly worked on this. I'm heartily in favor of this. I've found this behavior to be quite annoying. I'll see if I can put something together. If you want to help me out and put together the patches, I'd be more than happy to commit them. -gordon msg45677/pgp0.pgp Description: PGP signature
Re: Objective-C threads
Chad David wrote: > In your experience, how long is the delay between gcc-patches accepting > something and FreeBSD picking it up, ie. is it worth the effort? Jeremey Allison (of SAMBA) and I made patches to ACAP to get it to compile under G++, and that required patches to G++ 2.9.3 to support per thread exception handlers. It took about 6 months to get them into ECC, and the ones they added to ECC bloated the library in the non-threads case, rather than registering the handlers in the thread creation case only, like Jeremy originally had it doing. It took another 6 months before the new compiler made it into FreeBSD. So expect it to take you about a year, particularly since 3.2.1 was just imported for the 5.x release, and the compiler is not very likely to have a major number upgrade until 6.x. IMO, you are better off doing it as a patch in the FreeBSD tree, if you want it to work in FreeBSD in less than a year, but you should *also* send it into the GCC people, because if you don't, they'll potentially fix it the wrong way for your application, and their code will conflict with your patch, and you'll be hating life. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's this for ?
On 30-Oct-2002 Terry Lambert wrote: > Juan Francisco Rodriguez Hervella wrote: >> I've seen this looking for ISO images >> of FreeBSD-5.0-DP1: >> >> 5.0-DP1-disc2.iso - 5.0 Developer Preview #1 - live filesystem. >> >> is it possible to work with this filesystem ? >> I mean, what can be done ? is it auto-bootable or >> I need to boot from the other one ? > > It's an installed FreeBSD that is on a CDROM. It depends on your > BIOS being able to boot the FS as if it were a hard disk image. Huh? It doesn't do that. If it is bootable, then it boots into sysinstall just like CD #1. What it is useful for is to be used as a fixit CD. We don't boot it as a hard drive though. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
Chad David wrote: > > That said, if you want to make it work for you, I'm behind you > > 100%: I think any changes you want to make are OK; they can > > always be backed out, if anyone starts complaining about them > > breaking things, so I think it's kind of silly for you to ask > > for permission to maintain something no one else is maintaining. > > I wouldn't say I'm "asking for permission", I'd be more inclined to > say "I'm asking for guidance" :). I've seen what happens when > somebody commits to gcc, and life is just too short.. Nothing you do to Objective C gould break "make world"; the only thing you have to worry about is ports, and you can identify them and keep them happy before you commit something. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RCng Awkwardness
I find the standard arguments used by RCng quite awkward. In particular, especially for people who have worked with SysV-style init scripts, it's rather surprising that "/etc/rc.d/nfsd stop" does not actually stop the nfsd process. Likewise, 'start' doesn't actually start the specified system. I would find it vastly more intuitive if the current arguments were named differently: current 'start' -> new 'boot' current 'stop' -> new 'shutdown' current 'forcestart' -> new 'start' current 'forcestop' -> new 'stop' This better reflects the actual usage: the current 'start' and 'stop' are really intended to be used by RC at system boot and shutdown time. 'forcestart' and 'forcestop' are really for manually starting/stopping services. For that matter, I don't really understand why 'stop' and 'forcestop' are separate anyway; if I type 'stop', I want it to stop, even if rc.conf says it shouldn't be running. I could provide diffs to change this, but won't bother if everyone else thinks the existing system is perfect and unalterable. ;-) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's this for ?
Juan Francisco Rodriguez Hervella wrote: > I've seen this looking for ISO images > of FreeBSD-5.0-DP1: > > 5.0-DP1-disc2.iso - 5.0 Developer Preview #1 - live filesystem. > > is it possible to work with this filesystem ? > I mean, what can be done ? is it auto-bootable or > I need to boot from the other one ? It's an installed FreeBSD that is on a CDROM. It depends on your BIOS being able to boot the FS as if it were a hard disk image. You can pretty much do anything with it that you would do with any other FreeBSD that you had installed and then mounted as read-only. Running of a CDROM long terms is not such a good idea. To be specific, CDROM drives are not built for continuous duty cycles, and will cook themselves fairly quickly if asked to operate this way (i.e. a couple weeks to a month). So it's mostly for "test drive", "recovery", and "security comparisons". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: > > That's bizarre... it's defined in libc_r, so there's no reason for > > the omission in libc. > > I only added stubs that I thought the implementation of libc used > (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the function definitions, so that we are just dealing with lists; I didn't go that far with it. > > Please find attached a patch that corrects this. > > Patch looks correct. Please commit? 8-). > > PS: It looks like the semaphore code use pthread_cond_signal; maybe it > > should be using the pthread_cond_broadcast, instead? This seeems to > > be broken, if we are talking a large vs. small count on the semaphore... > > Semaphores only increment/decrement the semaphore by 1. In the code in question, it looks like a "thundering herd" race is a correct thing to do to avoid starvation; maybe I'm reading it wrong. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: questions about the state of current
On Tue, 29 Oct 2002, John Baldwin wrote: > > On 29-Oct-2002 clark shishido wrote: > > On Tue, Oct 29, 2002 at 11:40:53AM -0700, Raymond Kohler wrote: > >> 1) How is the speed compared to stable? I remember it being just too slow some >months ago and > >> was wondering how it was improving. > >> > >> 2) Are the random hangs in X fixed yet? I can put up with a few issues (it is >current, after > >> all), but that's just too much to bear. > >> > >> 3) Are there any Very Important Packages (mozilla, kde, &c) that won't build or >refuse to work > >> right? > >> > > > > I started using current a couple months ago, I just rebuilt the big three > > (world, XFree86, mozilla) last week after the latest gcc import. Speed > > difference with 4-STABLE on a PIII 866 is not very noticable. > > > > If I was reading the threads correctly they trace the X crashes back to > > a floating point error. > > > > I hear kde is broken, mozilla compiled cleanly so some gtk stuff is OK. > > (Sorry I don't use the full gnome suite either). > > > > I lost a filesystem on my current disk a month ago so make sure you > > use current on another disk. > > I compiled kde3 a week or so ago on my laptop running -current and it is > now my new desktop, so I think reports of kde being totally hosed are a > bit exagerated or perhaps dated. Hmm. I compiled it a few days ago and it was quite broken. It died in kdeinit very quickly. I will probably retest after sorting out the X threading problems as I have a hunch this is related. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: burncd/cdcontrol
On Sun, 27 Oct 2002, Soeren Schmidt wrote: > Hmm, it is true that I could use ATAPI command directly in burncd, and > I actually have a version in the lab that is ~75% converted to that, I'd love to see that once you're ready to release. > but that is not the only issue here. The ATAPI cd driver has quite a > bit of functionality that the SCSI cd driver hasn't, fx the ability > to read all kinds of CD's no matter what the block size, the ablity > to read individual tracks, and supporting ATAPI changer devices just > to mention a few :) We need to fixup cd(4) then. > Besides for some of us that uses small systems without SCSI in them, > saving the +100k of compiled code for the CAM overhead is important. > > Oh, and besides the SCSI/CAM cd driver didn't exist when I did the > first version of the ATAPI cd driver, that was the old SCSI system > back then... That's surprising to me since the man page claimed CAM cd(4) (not scd) appeared in 3.0R while acd(4) appeared in 4.0R. I guess you mean the predecessor to acd (was it wcd)? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
* De: Chad David <[EMAIL PROTECTED]> [ Data: 2002-10-30 ] [ Subjecte: Re: Objective-C threads ] > On Wed, Oct 30, 2002 at 09:22:21AM -0800, Juli Mallett wrote: > > * De: David O'Brien <[EMAIL PROTECTED]> [ Data: 2002-10-30 ] > > [ Subjecte: Re: Objective-C threads ] > > > On Wed, Oct 30, 2002 at 09:23:53AM -0700, Chad David wrote: > > > > > > > > Which brings us back to my original question... why are ObjC threads > > > > disabled? I don't much care about my other patches, I just want > > > > to know who the 10 others are who will break if we enable threads, > > > > and how to fix that breakage. My minor patches were only posted because > > > > you asked :). > > > > > > I am not sure. But for some reason you didn't provide a patch that would > > > turn them on. All you provided was a minor patches that really should go > > > thru the offical FSF GCC repo in-route to FreeBSD. So back to my > > > original request. Do you have a patch for changing this part of the way > > > we configure and build ObjC that you feel might be wrong? > > > > With a simple test program, > > > > [cut] > > > > > obj = [Test alloc]; > > [obj set:"Threads"]; > > pthread_create(&td, NULL, thr, NULL); > > This will work the way FreeBSD currently builds ObjC, what I want > to use is objc_thread_xxx() and friends, so that the code maintains > portability, and the runtime is kept up to date with what is going > on. My point was it doesn't break currently working things in a threading case. Your observations of the real issues are, of course, correct :) When you're chattign with the gcc objc people, get them to fix the nit in README.threads or THREADS where it says if you have a thread-aware GCC you can use thr-gcc.c... That file does not seem to exist, at least not in our contrib sources. juli. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 09:22:21AM -0800, Juli Mallett wrote: > * De: David O'Brien <[EMAIL PROTECTED]> [ Data: 2002-10-30 ] > [ Subjecte: Re: Objective-C threads ] > > On Wed, Oct 30, 2002 at 09:23:53AM -0700, Chad David wrote: > > > > > > Which brings us back to my original question... why are ObjC threads > > > disabled? I don't much care about my other patches, I just want > > > to know who the 10 others are who will break if we enable threads, > > > and how to fix that breakage. My minor patches were only posted because > > > you asked :). > > > > I am not sure. But for some reason you didn't provide a patch that would > > turn them on. All you provided was a minor patches that really should go > > thru the offical FSF GCC repo in-route to FreeBSD. So back to my > > original request. Do you have a patch for changing this part of the way > > we configure and build ObjC that you feel might be wrong? > > With a simple test program, > [cut] > > obj = [Test alloc]; > [obj set:"Threads"]; > pthread_create(&td, NULL, thr, NULL); This will work the way FreeBSD currently builds ObjC, what I want to use is objc_thread_xxx() and friends, so that the code maintains portability, and the runtime is kept up to date with what is going on. For example: accept_thread = objc_thread_detach(@selector(processLoop:), self, Nil); objc_thread_yield(); ... thr-single.c simply returns an error for each thread call. > pthread_yield(); > exit(0); > } > > (jmallett@luna:~/gnu/lib/libobjc)128% cvs diff > cvs server: Diffing . > Index: Makefile > === > RCS file: /home/ncvs/src/gnu/lib/libobjc/Makefile,v > retrieving revision 1.14 > diff -r1.14 Makefile > 14c14 > < thr.c thr-single.c \ > --- > > thr.c thr-posix.c \ Yes, this is what I did. Thanks. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 09:09:16AM -0800, David O'Brien wrote: > On Wed, Oct 30, 2002 at 09:23:53AM -0700, Chad David wrote: > > > > Which brings us back to my original question... why are ObjC threads > > disabled? I don't much care about my other patches, I just want > > to know who the 10 others are who will break if we enable threads, > > and how to fix that breakage. My minor patches were only posted because > > you asked :). > > I am not sure. But for some reason you didn't provide a patch that would > turn them on. All you provided was a minor patches that really should go > thru the offical FSF GCC repo in-route to FreeBSD. So back to my > original request. Do you have a patch for changing this part of the way > we configure and build ObjC that you feel might be wrong? That is fair. Here is a patch to start with. There are minor problems with thr-posix.c, but I'll take them up with the appropriate people. Thanks. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada Index: Makefile === RCS file: /mnt1/ncvs/src/gnu/lib/libobjc/Makefile,v retrieving revision 1.14 diff -u -d -r1.14 Makefile --- Makefile12 May 2002 16:00:46 - 1.14 +++ Makefile29 Oct 2002 21:34:52 - @@ -11,7 +11,7 @@ SRCS= archive.c class.c encoding.c gc.c hash.c init.c misc.c \ nil_method.c objects.c sarray.c selector.c sendmsg.c \ - thr.c thr-single.c \ + thr.c thr-posix.c \ NXConstStr.m Object.m Protocol.m linking.m INCS= encoding.h hash.h objc-api.h objc-list.h objc.h runtime.h \
Re: Objective-C threads
On Wed, Oct 30, 2002 at 09:16:26AM -0700, Chad David wrote: > No there is no reason, and yes the changes are generic. I don't really > expect there to be many (if any) changes to libobjc that are not generic, > so if gcc-patches is the place to go, that is where I'll go. It is. > In your experience, how long is the delay between gcc-patches accepting > something and FreeBSD picking it up, ie. is it worth the effort? It all depends on where we are in our release cycle vs. GCC's. Ie, we don't update what is in /usr/src every week. We do update the GCC ports frequently (every 2 weeks or so). It is worth the effort as the toolchain maintainers may take the stance that making these changes aren't worth the maintaince effor that taking something off the vendor branch entails. So the effort is your only way to make these const'ifying changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
* De: David O'Brien <[EMAIL PROTECTED]> [ Data: 2002-10-30 ]
[ Subjecte: Re: Objective-C threads ]
> On Wed, Oct 30, 2002 at 09:23:53AM -0700, Chad David wrote:
> >
> > Which brings us back to my original question... why are ObjC threads
> > disabled? I don't much care about my other patches, I just want
> > to know who the 10 others are who will break if we enable threads,
> > and how to fix that breakage. My minor patches were only posted because
> > you asked :).
>
> I am not sure. But for some reason you didn't provide a patch that would
> turn them on. All you provided was a minor patches that really should go
> thru the offical FSF GCC repo in-route to FreeBSD. So back to my
> original request. Do you have a patch for changing this part of the way
> we configure and build ObjC that you feel might be wrong?
With a simple test program,
%%%
#include
#include
#include
@interface Test : Object {
const char *string;
}
-(void) set:(const char *)str;
-(void) print;
@end
@implementation Test
-(void) set:(const char *)str {
string = str;
}
-(void) print {
printf("Test: %s\n", string);
}
@end
id obj;
static void *thr(void *ctxt __unused)
{
[obj print];
[obj set:"Inside"];
[obj print];
}
void main(void)
{
pthread_t td;
obj = [Test alloc];
[obj set:"Threads"];
pthread_create(&td, NULL, thr, NULL);
pthread_yield();
exit(0);
}
%%%
It seems a simple case doesn't break:
(jmallett@luna:~)121% cc test.m -lobjc -pthread
test.m: In function `main':
test.m:31: warning: return type of `main' is not `int'
(jmallett@luna:~)122% ./a.out
Test: Threads
Test: Inside
Simply with using thr-posix.c.
%%%
(jmallett@luna:~/gnu/lib/libobjc)128% cvs diff
cvs server: Diffing .
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/lib/libobjc/Makefile,v
retrieving revision 1.14
diff -r1.14 Makefile
14c14
< thr.c thr-single.c \
---
> thr.c thr-posix.c \
%%%
Thanks,
juli.
--
Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 09:23:53AM -0700, Chad David wrote: > > Which brings us back to my original question... why are ObjC threads > disabled? I don't much care about my other patches, I just want > to know who the 10 others are who will break if we enable threads, > and how to fix that breakage. My minor patches were only posted because > you asked :). I am not sure. But for some reason you didn't provide a patch that would turn them on. All you provided was a minor patches that really should go thru the offical FSF GCC repo in-route to FreeBSD. So back to my original request. Do you have a patch for changing this part of the way we configure and build ObjC that you feel might be wrong? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 02:23:00AM -0800, Terry Lambert wrote: > David O'Brien wrote: > > On Tue, Oct 29, 2002 at 11:52:56PM -0800, Terry Lambert wrote: > > > That said, if you want to make it work for you, I'm behind you > > > 100%: I think any changes you want to make are OK; they can > > > always be backed out, if anyone starts complaining about them > > > breaking things, so I think it's kind of silly for you to ask > > > for permission to maintain something no one else is maintaining. > > > > Perhaps because maintaining them in the FreeBSD repo might be the wrong > > place. To answer your other questiion -- because a change to fix one > > thing for one person might break things for 10 others. > > "they can always be backed out, if anyone starts complaining about them > breaking things" > > Better to have someone trying, than no one doing anything (IMO). Because making these changes will take files off the vendor branch -- something we think about before doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc in CURRENT fails as of 1200 GMT today
On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote the words in effect of: > [ ... ] > > I have not seen a commit since that time --4+ hours. > > everything else compiled; obviously a lot of incompletes > without libc Hey there. Could you please do a `make includes', before building libc only. This error indicates that uuid.h is not in /usr/include. Cheers. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc in CURRENT fails as of 1200 GMT today
On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote: > /usr/src/lib/libc/uuid/uuid_compare.c:31:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_create.c:30:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_create_nil.c:31:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_equal.c:31:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_from_string.c:32:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_hash.c:30:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_is_nil.c:30:18: uuid.h: No such file or directory > /usr/src/lib/libc/uuid/uuid_to_string.c:32:18: uuid.h: No such file or directory > install: libc.a: No such file or directory > > and a couple pages of resulting syntax errors > I assume you didn't do a makeworld, but just a make in libc? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: adaptec scsi - seagate da -- current
> Hi, > > I am running current cvsuped within this week. I have an adaptec > builtin scsi controller and a seagate drive attached to it and > after every bootup as soon as there is heavy disk activity > the drive gets disabled for 1 or 2 minutes and meanwhile all > functionality RELATED to disk I/O freezes for this time duration > eventually I see the following messages on console and every > thing is hunky dorry again. Have had this problem ever since I > upgraded to current. Stable never had any problem. neither did > netbsd which ran on this machine for a little while. > Can anyone familiar with this device driver comment. > Is it also coincidentally possible that the disk starts > showing its age right when I switched to current nah too > much of coincidence. anyway here are the messages: Can you provide the model number and firmware revision for this drive? According to the controller, the drive is failing to respond to a whole slew of commands that we have queued to it. You might have better luck if you reduce the tag depth to the disk via camcontrol. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD and "Linksys PCM200 ver. 2" CardBus Ethernet
In message: <[EMAIL PROTECTED]> Garrett Wollman <[EMAIL PROTECTED]> writes: : < said: : > I used to use one. The dc(4) driver was broken a while back and : > now has issues with this card that it didn't used to have, but it : > should mostly work (it just needs to be ifconfig'd down and up when : > it freezes sometimes). You do need the dc(4) driver in your kernel : > or kldload the module. : : The laptop is currently using GENERIC, which already has `dc', and as I : noted, the card is not recognized. I think that you'll need to hack the dc driver. This appears to be yet another variant of the PCM200 v.2 card. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: NEWCARD and "Linksys PCM200 ver. 2" CardBus Ethernet
< said: > I used to use one. The dc(4) driver was broken a while back and > now has issues with this card that it didn't used to have, but it > should mostly work (it just needs to be ifconfig'd down and up when > it freezes sometimes). You do need the dc(4) driver in your kernel > or kldload the module. The laptop is currently using GENERIC, which already has `dc', and as I noted, the card is not recognized. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
Gerald Pfeifer <[EMAIL PROTECTED]> writes: > Poul-Henning, your patch to src/sys/i386/include/reg.h > > revision 1.28 > date: 2002/10/20 20:48:56; author: phk; state: Exp; lines: +6 -9 > Change the definition of the debugging registers to be an array, so > that we can index into it, rather than do pointer gymnastics on a > structure containing 8 elements. > > unfortunately changed this structure in a way that makes it hard to > write code that remains compatible across -STABLE and -CURRENT. That revision doesn't change the structure, just how it is defined, so binary compatibility is not an issue. As for source compatibility, just use the DBREG_DRX macro, which exists in both -STABLE and -CURRENT (it was merged into -STABLE two years ago). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 02:19:43AM -0800, David O'Brien wrote: > On Tue, Oct 29, 2002 at 11:52:56PM -0800, Terry Lambert wrote: > > That said, if you want to make it work for you, I'm behind you > > 100%: I think any changes you want to make are OK; they can > > always be backed out, if anyone starts complaining about them > > breaking things, so I think it's kind of silly for you to ask > > for permission to maintain something no one else is maintaining. > > Perhaps because maintaining them in the FreeBSD repo might be the wrong > place. To answer your other questiion -- because a change to fix one > thing for one person might break things for 10 others. > Which brings us back to my original question... why are ObjC threads disabled? I don't much care about my other patches, I just want to know who the 10 others are who will break if we enable threads, and how to fix that breakage. My minor patches were only posted because you asked :). I do have other patches for thr-posix, but I agree that it would be better if they went to gcc, and didn't get stacked locally. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine-2002.10.07 port on FreeBSD 5.0-current
On Wed, 30 Oct 2002, Krzysztof [iso-8859-2] Jêdruczyk wrote: > Yesterday I tried to upgrade wine on my FreeBSD-current box. It didn't > compile until I changed following in server/context_i386.c (looks like > this is because of commit of 1.28 version of src/sys/i386/include/reg.h) Thanks for the heads up. Indeed this breaks the Wine port (and possibly other software) that relied on the old structure of dbreg. Poul-Henning, your patch to src/sys/i386/include/reg.h revision 1.28 date: 2002/10/20 20:48:56; author: phk; state: Exp; lines: +6 -9 Change the definition of the debugging registers to be an array, so that we can index into it, rather than do pointer gymnastics on a structure containing 8 elements. unfortunately changed this structure in a way that makes it hard to write code that remains compatible across -STABLE and -CURRENT. (I'm also Cc:ing Pierre, who contributed this FreeBSD-specific code to Wine in August.) How can we fix this problem (a) for Wine, and (b) in general? Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 02:17:07AM -0800, David O'Brien wrote: > On Tue, Oct 29, 2002 at 09:02:16PM -0700, Chad David wrote: > > On Tue, Oct 29, 2002 at 07:11:56PM -0800, David O'Brien wrote: > > > On Tue, Oct 29, 2002 at 07:09:41PM -0700, Chad David wrote: > > > > Does anybody know if there is a good reason why libobjc is built with > > > > thr-single.c? As well, who is the current maintainer of Objective-C? > > > > > > Few of us have ObjC clue. Do you have a patch that makes things better > > > that you can explain to us? > > > > To start with I have a few changes to hash.h, objc-list.h and thr.h that > > allow my code to even compile (without warnings) with I have attached. > > I believe they are all pretty obvious, except for the change to > > compare_ptrs(), which I'm not totally sure about... > > Is there any reason you have not sent these changes to the > [EMAIL PROTECTED] list? It looks like you're making generic ObjC > chagnes, not FreeBSD specific ones. No there is no reason, and yes the changes are generic. I don't really expect there to be many (if any) changes to libobjc that are not generic, so if gcc-patches is the place to go, that is where I'll go. In your experience, how long is the delay between gcc-patches accepting something and FreeBSD picking it up, ie. is it worth the effort? -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
Hi, I don't think many people in the FreeBSD community use Objective-C, hence the apparent lack of a maintainer. The proper way to submit patches to the [EMAIL PROTECTED] mailing list at the FSF GCC project is to follow the procedures documented at: http://gcc.gnu.org/contribute.html If you are used to how patches are submitted in FreeBSD, it's no big deal. In the source code for gcc, you will see a file called MAINTAINERS. The MAINTAINERS file lists a few names under Objective-C: objective-c Stan Shebs [EMAIL PROTECTED] objective-c Ovidiu Predescu [EMAIL PROTECTED] The most active maintenance of objective-c is going on at Apple, because of all the old NeXT stuff that they have in MacOS X. Keeping in touch with the darwin-development mailing list at Apple would probably not be a bad idea, since a lot of the Apple compiler developers read that list. http://lists.apple.com/mailman/listinfo/darwin-development -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
On Tue, Oct 29, 2002 at 11:52:56PM -0800, Terry Lambert wrote: > Chad David wrote: > > On Tue, Oct 29, 2002 at 07:04:21PM -0800, Terry Lambert wrote: > > > Chad David wrote: > > > > Does anybody know if there is a good reason why libobjc is built with > > > > thr-single.c? > > > > > > Historical threads problems. > > > > A few are obvious from simply reading the code. Do you have any > > knowledge of specific (non-trivial) problems? > > I used Objective C with threads on NeXT machines for a few years; > the FreeBSD threads weren't up to dealing with the requirements if > Objective C, at least until recently (I think some of the changes > that went into the pthreads standard after Draft 4 were specifically > put there to aid static initialization of declared Objective C > objects; they were pushed by people I know to have been NeXTStep > users). Other then a few minor issues, I haven't run into anything yet, but some of our larger servers are not up and running yet! I'm actually shying away from the NeXT stuff, and attempting to use the language for what I see are its strengths (which is not always a gigantic class library that nobody has documented, and which has a long history). > > > > > > As well, who is the current maintainer of Objective-C? > > > > > > Chad David? > > > > By default, since there seem to be no other users? > > I don't really use it. I like C++, but mostly code in C these > days. You can basically write object oriented code in any > procedural language which deals with structures the right way. I've spend the last year maintaining 10+ year old C++ and I really really dislike C++. I won't argue that each language has its place, only that given the fact that you don't always have old^H^H^Hexperienced programmers to work with, the language needs to help out whenever it can... I think ObjC does that, not quite as well as Java, but much better then C++. > > Maybe I'm just old, but I think it's more about programmers than > it is about the languages they use. That is my point exactly (within reason) :). > > So I'm not an Objective C user; unless a port I use happens to > require it to work, and I have to fix it, I don't go out of my > way to code in it, any more than, say, Perl, Java, COBOL, Visual > C++, or BLISS. 8-). I'm going out of my way. I "grew up" with C, then spent five years with Java, now I'm back to C, and I miss some things (not Java) which ObjC seems to bring to the table. > > That said, if you want to make it work for you, I'm behind you > 100%: I think any changes you want to make are OK; they can > always be backed out, if anyone starts complaining about them > breaking things, so I think it's kind of silly for you to ask > for permission to maintain something no one else is maintaining. I wouldn't say I'm "asking for permission", I'd be more inclined to say "I'm asking for guidance" :). I've seen what happens when somebody commits to gcc, and life is just too short.. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On Tue, 22 Oct 2002, Vitaly Markitantov wrote: > When i tries to copy a file from smbfs share mounted by mount_smbfs > i get an error: > cp: ./filename: Bad address > > But when i copy a file to share i get kernel panic like this: > > Fatal trap 12: page fault while in kernel mode Early started set of changes is not finished yeat and that panic might be caused by this. I'm sorry for leaving things broken for such long time, but really can't help right now. BTW, I'm looking for smbfs co-maintainer and if anyone interested in this, please mail me (obviously one are supposed to have knowledge of kernel and smbfs internals). -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD and "Linksys PCM200 ver. 2" CardBus Ethernet
On 29-Oct-2002 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Garrett Wollman <[EMAIL PROTECTED]> writes: >: Has anyone managed to make one of these work? I get the following >: messages: >: >: cardbus1: Expecting link target, got 0x59 >: cardbus1: Resource not specified in CIS: id=10, size=100 >: cardbus1: Resource not specified in CIS: id=14, size=400 >: cardbus1: (vendor=0x1737, dev=0xab09) at 0.0 irq 11 >: cbb1: CardBus card activation failed >: >: The box that this card came in was found in my boss's office, unopened >: and gathering dust, so I have no idea how recent it actually is; >: packaging seems to suggest 2001. > > Try loading the dc driver and the rl driver. Oh, wait, this is > vers.2. The ab09 looks similar to the ab02 for the Abocom FE2500. > > I think I have patches in my mailbox to add support for this, but > there was some issue with them that I wanted to get nailed down before > I committed. Hmmm, those patches were for a slightly different card, > with a vendor of 0x13d1, devid 0xab03. Looks like we need to add > some more vendor stuff. Also, I just found the patch in my inbox, and > it looks like there's some stuff that is specific to that card that > isn't called out as such. Hmm, one I have is version 2. Just a sec... *swaps cardbus cards* cardbus0: Expecting link target, got 0x59 cardbus0: Resource not specified in CIS: id=10, size=100 cardbus0: Resource not specified in CIS: id=14, size=400 dc0: port 0x1100-0x11ff mem 0x88002000-0x880023ff irq 11 at device 0.0 on cardbus0 dc0: Ethernet address: 00:e0:98:8c:2e:19 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto On the back it claims to be "Etherfast 10/100 / CardBus PC Card / Model No: PCMPC200" The serial number has a note under it that says "Ver.2" just under the right side of the barcode. Bill Paul got this to work practically eons ago back when cardbus support was first committed. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: NEWCARD and "Linksys PCM200 ver. 2" CardBus Ethernet
On 29-Oct-2002 Garrett Wollman wrote: > Has anyone managed to make one of these work? I get the following > messages: > > cardbus1: Expecting link target, got 0x59 > cardbus1: Resource not specified in CIS: id=10, size=100 > cardbus1: Resource not specified in CIS: id=14, size=400 > cardbus1: (vendor=0x1737, dev=0xab09) at 0.0 irq 11 > cbb1: CardBus card activation failed > > The box that this card came in was found in my boss's office, unopened > and gathering dust, so I have no idea how recent it actually is; > packaging seems to suggest 2001. I used to use one. The dc(4) driver was broken a while back and now has issues with this card that it didn't used to have, but it should mostly work (it just needs to be ifconfig'd down and up when it freezes sometimes). You do need the dc(4) driver in your kernel or kldload the module. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ipfilter IPv6 support in rc
On Tue, Oct 29, 2002 at 00:38:39 +0900, Hajimu UMEMOTO wrote: > Please review it. If there is no objection, I'll commit it at next > weekend. Reviewed -stable, looks OK. Would be nice to have this fix. Thanks. rvdp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: speed of -CURRENT [was: questions about the state of current]
On Wed, Oct 30, 2002 at 07:48:14AM -0500, Alexander Kabaev wrote:
> > I am experiencing a really noticable slower startup time on my very
> > recent-CURRENT laptop for almost all programs. The problem seems to be
> > in getting info in the cache, because it disappears when I start the
> > same program again.
>
> This almost certainly is caused by the 'ioslow' addition to
> specfs_vnops.c. Find a block in specfs_strategy function which goes into
> tsleep for niced processes and comment it out. Let us know if that helps
> :)
Yes, that's it. -CURRENT actually feels snappier than -STABLE now :)
Below is the diff that I used. Will something other than I/O for
niced processes break using this?
Thanks!
--Stijn
--- spec_vnops.c.orig Mon Oct 28 08:07:49 2002
+++ spec_vnops.cWed Oct 30 14:22:01 2002
@@ -530,17 +530,19 @@
struct mount *mp;
int error;
struct cdevsw *dsw;
- struct thread *td = curthread;
+/* struct thread *td = curthread; */
/*
* Slow down disk requests for niced processes.
*/
+/* XXX: per Alexander Kabaev mail 2002/10/30 07:48 -5
if (td && td->td_ksegrp->kg_nice > 0) {
mtx_lock(&strategy_mtx);
msleep(&strategy_mtx, &strategy_mtx,
PPAUSE | PCATCH | PDROP, "ioslow",
td->td_ksegrp->kg_nice);
}
+*/
bp = ap->a_bp;
vp = ap->a_vp;
if (bp->b_iocmd == BIO_WRITE) {
msg45645/pgp0.pgp
Description: PGP signature
