Re: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid)
On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote:
> ram_attach is based on regions_to_avail but that is a problem for
> its later bus_alloc_resource use --and that can lead to:
>
> panic("ram_attach: resource %d failed to attach", rid);
>
> Unfortunately, the known example is use of EDK2 on RPi4B
> class systems, not what is considered the supported way.
> The panic happens for main [so: 15] and will happen once
> the cortex-a72 handling in 14.0-* is in a build fixed by:
>
> • git: 906bcc44641d - releng/14.0 - arm64: Fix errata workarounds that
> depend on smccc Andrew Turner
>
> The lack of the fix leads to an earlier panic as stands.
>
>
> sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring
> phys_avail and using only hwregions and exregions. In other words,
> in part:
>
> * Initially dump_avail and phys_avail are identical. Boot time memory
> * allocations remove extents from phys_avail that may still be included
> * in dumps.
>
> This means that early, dedicated memory allocations are treated
> as available for general use by regions_to_avail . The distinction
> is visible in the boot -v output in that:
>
> real memory = 3138154496 (2992 MB)
> Physical memory chunk(s):
> 0x20 - 0x002b7f, 727711744 bytes (177664 pages)
> 0x002ce3a000 - 0x003385, 111304704 bytes (27174 pages)
> 0x00338c - 0x00338c6fff, 28672 bytes (7 pages)
> 0x0033a3 - 0x0036ef, 55377920 bytes (13520 pages)
> 0x00372e - 0x003b2f, 67239936 bytes (16416 pages)
> 0x004000 - 0x00bb3dcfff, 2067648512 bytes (504797 pages)
> avail memory = 3027378176 (2887 MB)
>
> does not list the wider:
>
> 0x004000 - 0x00bfff
>
> because of phys_avail . But the earlier dump based on hwregions and
> exregions shows:
>
> Physical memory chunk(s):
> 0x001d - 0x001e, 0 MB ( 32 pages)
> 0x0020 - 0x338c6fff, 822 MB ( 210631 pages)
> 0x3392 - 0x3b2f, 121 MB ( 31200 pages)
> 0x4000 - 0xbfff, 2048 MB ( 524288 pages)
> Excluded memory regions:
> 0x001d - 0x001e, 0 MB ( 32 pages) NoAlloc
> 0x2b80 - 0x2ce39fff,22 MB ( 5690 pages) NoAlloc
> 0x3386 - 0x338b, 0 MB ( 96 pages) NoAlloc
> 0x3392 - 0x33a2, 1 MB (272 pages) NoAlloc
> 0x36f0 - 0x372d, 3 MB (992 pages) NoAlloc
>
> which indicates:
>
> 0x4000 - 0xbfff
>
> is available as far as it is concerned.
>
> (Note some code works/displays in terms of: 0x4000 - 0xc000
> instead.)
>
> For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource
> that is used as bus_alloc_resource . It ends up rejecting the
> RPi4B boot via using the result of the call in ram_attach:
>
> if (bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, start,
> end,
> end - start, 0) == NULL)
> panic("ram_attach: resource %d failed to attach",
> rid);
>
> as shown by the just-prior start/end pair sequence messages:
>
> ram0: reserving memory region: 20-2b80
> ram0: reserving memory region: 2ce3a000-3386
> ram0: reserving memory region: 338c-338c7000
> ram0: reserving memory region: 33a3-36f0
> ram0: reserving memory region: 372e-3b30
> ram0: reserving memory region: 4000-c000
> panic: ram_attach: resource 5 failed to attach
>
> I do not see anything about this that looks inherently RPi*
> specific for possibly ending up with an analogous panic. So
> I expect the example is sufficient context to identify a
> problem is present, despite EDK2 use not being normal for
> RPi4B's and the like as far as FreeBSD is concerned.
>
I'm not quite clear why phys_avail changes and why that is triggered by the
906bcc44641d commit. I'm wondering if it makes sense to arrange for
ram_attach to happen before acpi, e.g. using BUS_PASS_ORDER_FIRST?
Doug.
Re: mount_nullfs: /var/run/log: must be either a file or directory
On Fri, 7 Jul 2023 at 13:11, Mina Galić wrote: > Hi folks, > > "recently", we added support for null-mounting single files: > > > https://freshbsd.org/freebsd/src/commit/521fbb722c33663cf00a83bca70ad7cb790687b3 > > This code restricts the mountable … thing to: > > if ((lowerrootvp->v_type != VDIR && lowerrootvp->v_type != VREG) > || … > > > As the author of the abandoned https://reviews.freebsd.org/D27411 > which attempted to add facility to syslog's rc to provide (selected) > jails with a log socket, it was pointed out to me that this is a big > security risk: https://reviews.freebsd.org/D27411#882100 > > so I was wondering if null mounts are the same kind of security > hazard, or if not allowing sockets is just the oversight of a > first approximation of this patch? > Mounting anything into a jail needs to be done carefully. Clearly null mounting /sbin into an untrusted jail allows all kinds of shenanigans to happen but I don't see a huge problem with mounting e.g. a data volume or a config file into a jail. Care needs to be taken at the point when the object is mounted to defend against symlinks in the jail's chroot causing the mount point to change to a surprising location outside the chroot. In ocijail, I added code to resolve symlinks in the context of the jail's chroot to avoid this. I also think it's important to perform any mounts or other configuration strictly before the jail is started - for OCI containers under podman or containerd, this may happen after the jail is created but strictly before anything in the container image is executed. Conversely, unmounting happens strictly after the jail is removed. In principle, I don't think it's a problem to mount sockets or fifos into a jail but one of the points made in your diff that allowing jails to connect to the host syslogd is a potential risk is a good one. Doug.
Re: kldunload kernel: How should the kernel behave when it is requested to unload itself
I think your intuition is correct - it never makes sense to unload the kernel (IMO). I approved the review. Doug. On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang wrote: > Hi, > > This is *NOT* joking. > > While working on https://reviews.freebsd.org/D42527 I realized the > module kernel also has userrefs, that is to say, userland can request > to unload kernel, aka `kldunload kernel`. > > This is interesting. Well no doubt that the loader can unload kernel. > Then after the kernel is loaded and has been initialized (SYSINIT), how > should it behave when it get an unload request? > > I'm proposing https://reviews.freebsd.org/D42530 to do not allow unloading > the kernel. It is by intuition. > > What do you think ? > > > Best regards, > Zhenlei > >
Re: HWPMC on SkyLake
Did you get any feedback on this? I would like to be able to use hwpmc but my desktop is a recent skylake and I also get the 'hwpc_core: unknown PMC architecture: 4' error. CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbb XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics hwpc_core: unknown PMC architecture: 4 hwpmc: SOFT/16/64/0x67 On 20 February 2016 at 12:49, Larry Rosenman wrote: > Is there anything I can do to help: > > hwpc_core: unknown PMC architecture: 4 > hwpmc: SOFT/16/64/0x67 > > CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 > > Features=0xbfebfbff > > Features2=0x7ffafbbf > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > Features=0x29c6fbf > XSAVE Features=0xf > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
plockstat
Is plockstat supposed to work on FreeBSD? I'm running FreeBSD-current and when I try it, I get: plockstat: failed to compile program: probe description plockstat65047:::rw-block does not match any probes Any ideas what to try next? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFSROOT UEFI boot
On 28 January 2016 at 15:03, Tomoaki AOKI wrote: > It's exactly the NO GOOD point. The disk where boot1 is read from > should be where loader.efi and loader.conf are first read. > I just wanted to note that gptzfsboot and zfsboot behaves this way. Boot1 looks for loader in the pool which contains the disk that the BIOS booted. It passes through the ID of that pool to loader which uses that pool as the default for loading kernel and modules. I believe this is the correct behaviour. For gptzfsboot and zfsboot, it is possible to override by pressing space at the point where it is about to load loader. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPC request sent to 127.0.0.1 becomes from other IP on machine
I think a local socket is probably the best solution long term. Using a local socket also allows using filesystem permissions to control access which is required for gssd but not necessarily for nfsuserd. On 10 December 2015 at 13:37, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? > > And do you know if it will always be replaced with the same > address? > (I'm basically wondering if the workaround needs to be a list of IP > addresses > instead of a single address?) > > Thanks in advance for any help with this, rick > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
On Thursday, July 9, 2015, Garrett Wollman wrote: > In article > >, > oliver.pin...@hardenedbsd.org writes: > > >Btw, I have found this is atf's documantation: > >atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the > >specific test case could "fail" / or expect to coredump. > > No. > > I'm not sure why people are having trouble understanding this. > > The test in question is not valid C. It is entirely erroneous, and > should be deleted. Merely computing the value "(void *)-1" is allowed > to perform LITERALLY ANY ACTION AT ALL, including turning your > computer into a frog. The compiler is free to implement this as a > call to abort() if it chooses. Testing this is nonsensical. > > -GAWollman > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > +1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
As far as I can tell, POSIX doesn't require either EFAULT or any other behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf just says, "No errors are defined". Our man page is wrong and any real program which relies on gettimeofday not faulting when given bad inputs is broken. On 8 July 2015 at 17:16, Jamie Landeg-Jones wrote: > Oliver Pinter wrote: > > > On 7/8/15, O'Connor, Daniel wrote: > > > > > > In defence of the test, the man page says it can return EFAULT. > > > > That's fine, but why changed the behaviour since 2015. May 27.? I have > > an older FreeBSD/HardenedBSD install, where this test passing. See > > some previous email in this thread. > > That's why it's called 'undefined' :-) > > Pedantically, being 'undefined', it's behaviour hasn't changed at all! > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nmount, mountd drops high order MNT_xx flags during a mount update
You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? On 7 May 2015 at 02:10, Rick Macklem wrote: > David Boyd reported a problem to freebsd-current@ w.r.t. the > MNT_AUTOMOUNTED > flag getting cleared by mountd. > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > I just took a look at this and it's kinda ugly... > > mountd acquires a list of mounts via getmntinfo() and then does an > nmount() for each of them to get rid of any exports. It uses > f_flags from the statfs returned by getmntinfo() as the 3rd > argument to nmount(). > --> Since nmount()s 3rd argument is a "int", it silently drops any > MNT_xx flag in the high order 32bits of f_flags. At this time, > it happens that MNT_AUTOMOUNTED is the only one, but... > > I can think of a couple of ways to fix this, but I don't like any of > them;-) > > 1) I suppose mountd could check for each flag set in f_flags and generate > a vfsopts string for it, but that means that every time a new flag that > can be updated is added to MNT_xx, this mountd.c code would have to > updated. > --> Ugly!! > > 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. >I wouldn`t mind this except in means that the MNT_xx flags must be > redefined >and I don`t think that could get MFC`d. > > 3) Add a new newernmount(2) which has a 64bit flags argument instead of > int. > > Hopefully someone can think of a nice way to fix this, rick > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Possible bug in NFSv4 with krb5p security?
On 16 February 2013 16:18, Elias Mårtenson wrote: > On 17 February 2013 00:03, Doug Rabson wrote: > >> I don't think much (if anything) has changed with gssd between 9.1 and >> current. When your gssd hangs, you can try to get a stack trace using gdb's >> attach command. >> >> Fair enough. However, when it hangs, I have at least a 50% chance of > hitting the gssd-realted kerberl panic. Should I apply the patch you gave > me, or would you suggest an upgrade? > I think it was Rick that mentioned the patch. I would apply the patch and rebuild your kernel in the interests of changing as little as possible while debugging the original issue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Possible bug in NFSv4 with krb5p security?
On 16 February 2013 13:57, Elias Mårtenson wrote: > On 16 February 2013 18:58, Doug Rabson wrote: > >> This may be a stupid question but does the user 'elias' exist in the >> local password database? >> >> If you are using heimdal from the base distribution and you have source, >> you should be able to build them with debug information which may help. >> When I was writing gssd, I mostly ran it under gdb to debug problems like >> this. To build something in the base with debug information, go to the >> directory in the source tree for that component and type something like >> 'make DEBUG_FLAGS=-g clean all install'. >> > > No worries. I do have that user (and everything else, specifically single > sign-on ssh) works with it. I do agree that if I had not that user, the > behaviour I see would be neatly explained. > > When it comes to gssd, I've got its behaviour pretty well nailed down. It > does what it's supposed to do. > > However, when I tried rebuilding libgssapi.so.10, I ended up with gssd > hanging when it used the new library. I have no idea why. > > Would it be wise to upgrade from 9.1-RELEASE to something newer? I've seen > references to 10-CURRENT. I'd like to be debugging the latest version of > everything, but this machine also needs to serve as a fileserver for my > home office, so some degree of stability is needed. > > I don't think much (if anything) has changed with gssd between 9.1 and current. When your gssd hangs, you can try to get a stack trace using gdb's attach command. > Regards, > Elias > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Possible bug in NFSv4 with krb5p security?
This may be a stupid question but does the user 'elias' exist in the local password database? If you are using heimdal from the base distribution and you have source, you should be able to build them with debug information which may help. When I was writing gssd, I mostly ran it under gdb to debug problems like this. To build something in the base with debug information, go to the directory in the source tree for that component and type something like 'make DEBUG_FLAGS=-g clean all install'. On 16 February 2013 09:24, Elias Mårtenson wrote: > OK, here I am replying to my own email. I just want to mention that I > removed the ports version of Heimdal, but with no change in behaviour. > > > On 16 February 2013 09:38, Elias Mårtenson wrote: > > > > > On 16 Feb, 2013 1:42 AM, "Benjamin Kaduk" wrote: > > > > > >> And yet one more thing: Heimdal ships with its own version of > > libgssapi. I > > >> can link gssd to it, but it won't run properly (it hangs pretty > early). > > > > > > I have forgotten: you are using Heimdal from ports, not from the base > > system? I remember it being easy to get into subtly-broken > configurations > > when both a ports and a base version are present. > > > > I am indeed using Heimdal from ports. This machine is also the KDC. I > > wasn't aware that there was a non-ports version available. > > > > What do you suggest I do? Simply remove the one from ports? Do I have to > > do something to activate the other one? > > > > (I have a hard time checking this as I am nowhere near the computers now) > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS+J panics on HEAD
If all you are doing is reading, the ZFS on-disk format is well documented and fairly easy to work with. Take a look at the ZFS bootloader code - that implements a ZFS reader in not too many lines of code and could easily be re-purposed for a recovery tool. On 24 May 2012 09:04, Lev Serebryakov wrote: > Hello, Steven. > You wrote 24 мая 2012 г., 1:58:48: > > SH> While it might be a shame to see FFS go by the wayside are there any > SH> big reasons why you would rather stick with FFS instead of moving > SH> to ZFS with all the benefits that brings? > I afraid, that after real hardware failure (like real HDD death, > not these pseudo-broken-hardware situations, when HDDs is perfectly > alive and in good condition), all data will be lost. I could restore > data from remains of FFS by hands (format is straightforward and > well-known), but ZFS is different story... > > And all these messages about panics after pool import... Yes, it > could be result of REAL hardware problems, but I want to have some > hope to restore some of the data after such crashes. > > Yes, backups is solution, but I don't have money to buy (reliable) > hardware to backup 4Tb of data :( > > I attended "Solaris internals" 5-days training four years ago (when I > worked for Sun Microsystems), and instructor says same words... > > > -- > // Black Lion AKA Lev Serebryakov > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On 27 September 2011 13:57, Adrian Chadd wrote: > On 27 September 2011 20:22, Robert Huff wrote: > > > > krad writes: > >> we can leave that to our grand children to figure out though 8) > > > >Wasn't that what people said about two-digit years? > > Our children will be dealing with Y2038. :-) > > I'm sure some of us old-timers will be looking for high-paid 2038 consultancy work to fund our lavish retirement plans... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-CUR/amd64 CLANG: howto use gcc __builtin_ia32?
You could try using the standard header - that has inline functions which should cover all the SSE instructions. On 12 June 2011 17:43, Hartmann, O. wrote: > I use some numerical code utilizing the SIMD units of modern X86 > architectures. Code compiles well using gcc/gcc46, > but clang does not know about the __builtin_ia32_x() statements. How to > treat those in clang and how to make > C code compiling with clang utilizing those __builtin_ia32 statements? > > Thanks, > Oliver > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Our aging base system heimdal
On 6 June 2010 21:09, Jos Backus wrote: > Any chance the kadmin protocol will ever be standardized? > > My understanding is that the MIT kadmin protocol is based GSS-API authenticated RPC which FreeBSD didn't support until recently. I added working RPCSEC_GSS to our userland RPC library in 2008 and it should be available in FreeBSD 8.x and later. In theory, if MIT actually document their protocol, it should be reasonably straightforward to support it. I doubt if I will be able to do the work either for this or for upgrading heimdal. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Core i5 AES acceleration
On 9 Mar 2010, at 00:10, James R. Van Artsdalen wrote: > Norikatsu Shigemura wrote: >> According to http://en.wikipedia.org/wiki/AES-NI , we can get >> specification document: http://software.intel.com/file/20457 . >> >> I saw it, and consider that we can release under BSDL. Because >> of 'from specification'. > > That document is short on details, such as the opcodes and machine > implementation details (flags, etc). > > The XMM registers are used. That may be a problem for kernel code. > > When last I looked openssl did not use /dev/crypt - it's not clear how > big the benefit would be from doing this if nothing that uses openssl wins. > > It might be more beneficial to FreeBSD to patch openssl to use > /dev/crypt. If it turns out to not be a significant win then that might > hint that the AES opcodes won't be significant win in general either. The in-kernel kerberos code for NFS would also benefit since it uses the crypto framework. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 14:27:06 +0300, Alex Keda wrote: > On 05.03.2010 14:16, Doug Rabson wrote: >> On Fri, 05 Mar 2010 14:10:43 +0300, Alex Keda wrote: >> >>> On 05.03.2010 13:59, Poul-Henning Kamp wrote: >>> >>>> In message<4b90e171.2040...@lissyara.su>, Alex Keda writes: >>>> >>>> >>>> >>>>> then can a more correct name of the project or ClosedBSD or >>>>> >> ManagedBSD? >> >>>>> =) >>>>> or something abstract? >>>>> >>>>> >>>> You are free to use any other operating system of your choice, if you >>>> are not happy with FreeBSD. >>>> >>>> Don't let the door hit you on the way out. >>>> >>>> >>> I'm not going anywhere, not even hope for it =) >>> I'm trying to make FreeBSD a better, more logical. >>> Maybe that's not very successful, but judging by the number of >>> responses, it hurt many, and made to think even more people. >>> >> I think you misunderstand. Some of us old-timers have been having this >> discussion repeatedly for well over ten years. It always ends up the same >> way - a re-org might make the source tree marginally prettier but the >> consequences for long-term maintenance and supporting downstream >> contributors outweigh any possible benefit. Having the same conversation >> every two years with the same outcome gets annoying. >> > And the fact that this issue was raised with enviable regularity - not > make you think that it really needs to be done? Read what I wrote. Consequences outweigh benefits so no. On the other hand, if you are just trolling, please try somewhere else. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 14:10:43 +0300, Alex Keda wrote: > On 05.03.2010 13:59, Poul-Henning Kamp wrote: >> In message<4b90e171.2040...@lissyara.su>, Alex Keda writes: >> >> >>> then can a more correct name of the project or ClosedBSD or ManagedBSD? >>> =) >>> or something abstract? >>> >> You are free to use any other operating system of your choice, if you >> are not happy with FreeBSD. >> >> Don't let the door hit you on the way out. >> > I'm not going anywhere, not even hope for it =) > I'm trying to make FreeBSD a better, more logical. > Maybe that's not very successful, but judging by the number of > responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 13:48:17 +0300, Alex Keda wrote: > On 05.03.2010 12:59, Doug Rabson wrote: >> On 5 Mar 2010, at 09:56, Alex Keda wrote: >> >> >>> On 05.03.2010 12:45, Doug Rabson wrote: >>> >>>> On 5 Mar 2010, at 09:30, Alex Keda wrote: >>>> >>>> >>>> >>>>> On 05.03.2010 12:17, Robert Watson wrote: >>>>> >>>>> >>>>>> consumers like Isilon, NetApp, Juniper, and many others >>>>>> >>>>>> >>>>> thus, it is not 'Free', this managed by 'consumers like Isilon, >>>>> NetApp, Juniper, and many others'? >>>>> >>>>> >>>> It might be helpful to think of them as 'customers' who are using our >>>> 'product' and paying for it by feeding back patches and employing >>>> FreeBSD developers. Normal business practice doesn't include >>>> intentionally making your customers' lives difficult - if you make a >>>> habit of it they tend to go elsewhere. >>>> >>>> >>> It seems to me, business and freedom - are mutually exclusive things. >>> or you can choose the path of development, or who pays - giver commands >>> to community. >>> no freedom there. >>> >> Someone always pays. If this project didn't have sponsors like Isilon, >> NetApp, Juniper, Yahoo, and many others it simply would not exist. >> > > then can a more correct name of the project or ClosedBSD or ManagedBSD? =) > or something abstract? No. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
On 5 Mar 2010, at 09:56, Alex Keda wrote: > On 05.03.2010 12:45, Doug Rabson wrote: >> On 5 Mar 2010, at 09:30, Alex Keda wrote: >> >> >>> On 05.03.2010 12:17, Robert Watson wrote: >>> >>>> consumers like Isilon, NetApp, Juniper, and many others >>>> >>> thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, >>> Juniper, and many others'? >>> >> It might be helpful to think of them as 'customers' who are using our >> 'product' and paying for it by feeding back patches and employing FreeBSD >> developers. Normal business practice doesn't include intentionally making >> your customers' lives difficult - if you make a habit of it they tend to go >> elsewhere. >> > It seems to me, business and freedom - are mutually exclusive things. > or you can choose the path of development, or who pays - giver commands to > community. > no freedom there. Someone always pays. If this project didn't have sponsors like Isilon, NetApp, Juniper, Yahoo, and many others it simply would not exist. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
On 5 Mar 2010, at 09:30, Alex Keda wrote: > On 05.03.2010 12:17, Robert Watson wrote: >> consumers like Isilon, NetApp, Juniper, and many others > thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, > Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Apples linking
On Fri, 2003-11-28 at 07:59, Peter Jeremy wrote: > On Thu, Nov 27, 2003 at 11:24:23AM -0500, Robert Watson wrote: > [Darwin pre-binding] > >presumably applies to other processor architectures. The one thing that > >turns me off to this scheme is that I'd like it if we could find a way to > >represent this using solely existing BSD/UNIX kernel primitives (mmap, et > >al) and userspace, rather than adding special-purpose system calls that > >complicated various code paths, and that aren't portable. > > Compaq/HP Tru64 supports link-time pre-binding, called "Quickstart". > To use it, shared libraries are linked to load at mutually exclusive > addresses and applications are linked assuming the preferred .so load > addresses. At run-time, the rtld verifies that it can map every > shared library at its preferred address and that each shared library > is the same one the application was linked against (using checksums in > the COFF headers). If all this is true, all the relocations are > correct and execution starts immediately. If any checks fail, rtld > falls back to the traditional check-every-symbol-and-relocation > approach. > > The benefit is very fast start times - not much more overhead than > starting a static executable. This is approximately what happens on Win32 too. When developing DLLs for windows, I tend to manually pick a load address at link time. This is messy but it helps load time a lot for large projects. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cbb cardbus activation failed
On Mon, 2003-11-17 at 08:44, Philippe Charnier wrote:
> Salut,
>
> Doug Rabson <[EMAIL PROTECTED]> wrote:
>
> >On Sat, 2003-11-15 at 22:32, Philippe Charnier wrote:
> >> Hello,
> >>
> >> I have a Compaq armada 7800 with a noname pccard ethernet adapter
> >> which used to be detected as:
> >>
> >> rl0: port 0x1100-0x11ff mem 0x8800-0x880001f
> >f irq 11 at device 0.0 on cardbus0
> >> rl0: Ethernet address: 00:10:60:58:60:b8
> >> miibus0: on rl0
> >> rlphy0: on miibus0
> >> rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> >> rl0: bpf attached
> >>
> >> After revision 1.222 of src/sys/pci/if_rl.c, the card is not detected
> >> anymore and I get:
> >>
> >> cardbus0: at device 0.0 (no driver attached)
> >> cbb0: CardBus card activation failed
> >
> >Which version of dev/cardbus/cardbus.c and dev/pci/pci.c do you have?
> >
> >
>
> In a CET timezone (1 hour shift against UTC) I got a working kernel
> using cvs update -D "november 3" which gives if_rl.c(1.121)
> cardbus.c(1.42) and pci.c(1.234). I got a failing kernel using cvs
> update -D "november 5" which gives if_rl.c(1.122) cardbus.c(1.42) and
> pci.c(1.235). I don't think 1.234->1.235 of pci.c (committed by jhb@)
> is relevant here ("Enable PCI interrupt routing for i386 SMP kernels")
> because SMP is not defined in my kernel configuration file. Using
> if_rl.c(1.125 but with 1.121->1.122 reverted), I have a running kernel
> with cardbus(1.42) and pci.c(1.235) which is -current. I takes nearly
> 2 hours to get a new kernel, but if you need more testing, just ask.
Now I'm very confused. I can't see why the rl driver should be different
from any of the other cardbus-supporting drivers which still work. Could
I see your kernel config file?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cbb cardbus activation failed
On Sat, 2003-11-15 at 22:32, Philippe Charnier wrote: > Hello, > > I have a Compaq armada 7800 with a noname pccard ethernet adapter > which used to be detected as: > > rl0: port 0x1100-0x11ff mem 0x8800-0x880001ff irq 11 > at device 0.0 on cardbus0 > rl0: Ethernet address: 00:10:60:58:60:b8 > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: bpf attached > > After revision 1.222 of src/sys/pci/if_rl.c, the card is not detected > anymore and I get: > > cardbus0: at device 0.0 (no driver attached) > cbb0: CardBus card activation failed Which version of dev/cardbus/cardbus.c and dev/pci/pci.c do you have? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: taskqueue patch
On Mon, 2003-11-10 at 23:39, Alex Wilkinson wrote: > On Mon, Nov 10, 2003 at 09:02:03AM +0000, Doug Rabson wrote: > > I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel > threads so I can't be sure but this does look reasonable. I've been > wondering about the 'not exiting' diagnostic from init for a while > myself. > > Hi Doug, > > What are "SWIs" ? Its an ancient VAX concept - 'SoftWare Interrupts'. Basically on a vax, you could poke a register and it would cause a low-priority interrupt. They were often used for 'split priority' interrupt handlers where you did the minimum amount of work in the first interrupt and then triggered a SWI for the rest. The advantage being that the SWI could be pre-empted by another high-priority hardware interrupt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: taskqueue patch
I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel threads so I can't be sure but this does look reasonable. I've been wondering about the 'not exiting' diagnostic from init for a while myself. On Mon, 2003-11-10 at 05:10, Alfred Perlstein wrote: > I noticed that init was complaining about processes not exiting > when doing a transition to single user mode. It appears > that the problem is that the taskqueue kernel process is > started with RFNOWAIT but doesn't respect orderly shutdown > signs. > > Diff follows: > > Index: subr_taskqueue.c > === > RCS file: /home/ncvs/src/sys/kern/subr_taskqueue.c,v > retrieving revision 1.19 > diff -u -r1.19 subr_taskqueue.c > --- subr_taskqueue.c 6 Sep 2003 21:05:18 - 1.19 > +++ subr_taskqueue.c 10 Nov 2003 05:00:00 - > @@ -271,7 +271,7 @@ > > TASKQUEUE_DEFINE(thread, taskqueue_thread_enqueue, 0, >kthread_create(taskqueue_kthread, NULL, > - &taskqueue_thread_proc, RFNOWAIT, 0, "taskqueue")); > + &taskqueue_thread_proc, 0, 0, "taskqueue")); > > int > taskqueue_enqueue_fast(struct taskqueue *queue, struct task *task) > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Memory modified after free
On Thu, 2003-10-23 at 22:45, othermark wrote: > I wrote: > > I will try seeing how far I can go up the list of snapshots until I > > encounter the first boot -s panic. > > Well I walked up the available snapshots and the first panic occurs with > the snapshot from the 17th of October. Reviewing the commit logs between > the 16th and the 17th I note the following commits are the most > 'interesting.' as related to this panic.. This is just a cursory look > at the logs, I haven't gotten into compiling and fingering an exact commit > yet (which takes loads of time). > > dfr 2003/10/16 02:16:28 PDT > > FreeBSD src repository > > Modified files: > sys/sys bus.h kobj.h param.h > sys/kern subr_bus.c subr_kobj.c > Log: > * Add multiple inheritance to kobj. I haven't had any other reports of breakage related to this. Is it possible that you are using a kernel module which you have not re-built after this date (e.g. nvidia.ko)? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random signals in {build,install}world recently?
On Tue, 2003-10-21 at 07:59, Terry Lambert wrote: > Christian Brueffer wrote: > > > I don't think so. I tried that on my A7M266D with no effect. I believe > > > something in recent pmap code doesn't like this mobo, or maybe dual > > > athlons in general. I can run RELENG_5_1 rock solid, and -current from > > > 9/24/03 rock solid, but -current from 10/3 or later gets random sigs > > > and eventually panics. I have scsi disks so it's not ata. > > > > I have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. > > Used to work fine, but got random signals with my latest builds. > > On thing that occurs to me: try the other scheduler: there were > recent changes in this area, which may be the problem. I also get random segfaults and ICEs on my dual 1900+ system with recent current. It certainly isn't hardware problems since older kernels work very nicely. I haven't got around to trying to diagnose what is causing it yet though. I was planning to try disabling a few things like SSE, PSE etc and see if I could improve things. My kernel is dated from 1 October (I did try a bit later than that but those ones just paniced all over themselves, very messy). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kobj.h changes make buildkernel broken
On Thu, 2003-10-16 at 14:23, Jun Su wrote: > Seems Tools\makeobjops.awk needs some update. Sorry about that - I forgot to commit that bit. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EC/sensor support questions
On Fri, 2003-09-12 at 12:46, Johny Mattsson wrote: > Hi all, > > My main FreeBSD box has an Elite/ECS motherboard with the ITE8705 > Environmental Controller/hardware monitor chip, which I'd love to use so > that I can monitor the system temperature, voltages, and fan speed. > > At present (well, 5.1-R) there appears to exist no support for this > particular chip. Not being deterred by such a fact, I thought I'd grab > the specs and write up a driver for it, naively believing that I'd be > able to link it in under the smbus code, like the intpm, alpm, et al. > Having now read through the docs, it doesn't appear that this chip is an > SMBus device. Skimming through the sysutil/xmbmon source supports that > impression, as that app only talks to this chipset directly via ISA-IO. > > My questions are: > - Is it feasible to write a pseudo smb driver that can translate smb > requests to a different ioctl interface (or similar), and then write a > specific ITE87xx driver to attach to that node? > > - Or is there already a framework or an ioctl set defined for sensors > that I could/should be using instead? It appears that Linux has got > something like that, but I haven't looked into in any detail (since I > don't use Linux...) > > - Would we even want such a thing? I don't think I'd bother spending a > lot of time deciphering the specs unless it'd benefit more people than > myself. > > - Who would be able to point me to further specs for SMBus/i2c/sensor > stuff? This stuff is seriously tedious to google for :/ I would recomment just treating the thing as an ISA device. There is no standard ioctl api for accessing sensor information from kernel devices as yet (mainly because there are no kernel sensor drivers). You can do most of what you need from userland - xmbmon is a good place to start if it doesn't already support your chip. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Last inline offenders...
The code in mga_stage.c is externally maintained. Its probably not a
good idea to edit that one.
On Wed, 2003-07-23 at 19:55, Poul-Henning Kamp wrote:
> The following patch are my suggestion (already sent to maintainers)
> for inlines to remove so we can get under the 2000 limit in GCC on
> i386.
>
>
> Index: dev/aic7xxx/aic79xx_inline.h
> ===
> RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_inline.h,v
> retrieving revision 1.12
> diff -u -r1.12 aic79xx_inline.h
> --- dev/aic7xxx/aic79xx_inline.h 28 Jun 2003 04:43:19 - 1.12
> +++ dev/aic7xxx/aic79xx_inline.h 23 Jul 2003 16:37:59 -
> @@ -451,7 +451,7 @@
> static __inline void ahd_set_sescb_qoff(struct ahd_softc *ahd, u_int value);
> static __inline u_intahd_get_sdscb_qoff(struct ahd_softc *ahd);
> static __inline void ahd_set_sdscb_qoff(struct ahd_softc *ahd, u_int value);
> -static __inline u_intahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
> +static u_int ahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
> static __inline u_intahd_inw_scbram(struct ahd_softc *ahd, u_int offset);
> static __inline uint32_t
> ahd_inl_scbram(struct ahd_softc *ahd, u_int offset);
> @@ -664,7 +664,7 @@
> ahd_outb(ahd, SDSCB_QOFF+1, (value >> 8) & 0xFF);
> }
>
> -static __inline u_int
> +static u_int
> ahd_inb_scbram(struct ahd_softc *ahd, u_int offset)
> {
> u_int value;
> Index: dev/drm/mga_state.c
> ===
> RCS file: /home/ncvs/src/sys/dev/drm/mga_state.c,v
> retrieving revision 1.6
> diff -u -r1.6 mga_state.c
> --- dev/drm/mga_state.c 25 Apr 2003 01:18:46 - 1.6
> +++ dev/drm/mga_state.c 23 Jul 2003 18:33:33 -
> @@ -71,7 +71,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g200_emit_context( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_context( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -97,7 +97,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g400_emit_context( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_context( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -128,7 +128,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
> @@ -159,7 +159,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
> @@ -203,7 +203,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[1];
> @@ -244,7 +244,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> unsigned int pipe = sarea_priv->warp_pipe;
> @@ -274,7 +274,7 @@
> ADVANCE_DMA();
> }
>
> -static __inline__ void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
> {
> drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
> unsigned int pipe = sarea_priv->warp_pipe;
> Index: dev/drm/r128_state.c
> ===
> RCS file: /home/ncvs/src/sys/dev/drm/r128_state.c,v
> retrieving revision 1.6
> diff -u -r1.6 r128_state.c
> --- dev/drm/r128_state.c 25 Apr 2003 01:18:46 - 1.6
> +++ dev/drm/r128_state.c 23 Jul 2003 18:33:33 -
> @@ -98,7 +98,7 @@
> ADVANCE_RING();
> }
>
> -static __inline__ void r128_emit_context( drm_r128_private_t *dev_priv )
> +static void r128_emit_context( drm_r128_private_t *dev_priv )
> {
> drm_r128_sarea_t *sarea_priv = dev_priv->sarea_priv;
> drm_r128_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -140,7 +140,7 @@
> ADVANCE_RING();
> }
>
> -static __inline__ void r128_emit_masks( drm_r128_private_t *dev_priv )
> +static void r128_emit_masks( drm_r128_private_t *dev_priv )
> {
> drm_r128_sarea_t *sarea_priv = dev_priv->sarea_pr
Re: VFS: C99 sparse format for struct vfsops
On Wednesday 04 June 2003 1:26 pm, Paul Richards wrote:
> On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote:
> > On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
> > > On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
> > > > Notice how thread 1's _m gets set based on the results of the
> > > > kobj lookup, and we have a race, even if thread1 and thread2
> > > > took out their driver instance locks.
> > >
> > > That means we have to lock the dispatch table before every method
> > > is looked up and hold it until the method returns (the
> > > alternative would be to free it inside the method once it had
> > > been called but that'd be a right mess).
> >
> > Don't even think about trying to put a mutex into the kobj dispatch
>
> I wasn't, I was just pointing out what would be necessary if the
> cacheing problem wasn't resolved :-)
I think this patch should fix the SMP-unsafe problems with kobj, at the
expense of changing the ABI slightly.
Index: tools/makeobjops.awk
===
RCS file: /home/ncvs/src/sys/tools/makeobjops.awk,v
retrieving revision 1.2
diff -u -r1.2 makeobjops.awk
--- tools/makeobjops.awk20 Aug 2002 03:06:30 - 1.2
+++ tools/makeobjops.awk9 Jun 2003 09:25:30 -
@@ -283,7 +283,7 @@
firstvar = varnames[1];
if (default == "")
- default = "0";
+ default = "kobj_error_method";
# the method description
printh("extern struct kobjop_desc " mname "_desc;");
@@ -293,8 +293,12 @@
line_width, length(prototype)));
# Print out the method desc
+ printc("struct kobj_method " mname "_method_default = {");
+ printc("\t&" mname "_desc, (kobjop_t) " default);
+ printc("};\n");
+
printc("struct kobjop_desc " mname "_desc = {");
- printc("\t0, (kobjop_t) " default);
+ printc("\t0, &" mname "_method_default");
printc("};\n");
# Print out the method itself
Index: sys/kobj.h
===
RCS file: /home/ncvs/src/sys/sys/kobj.h,v
retrieving revision 1.7
diff -u -r1.7 kobj.h
--- sys/kobj.h 10 Jun 2002 22:40:26 - 1.7
+++ sys/kobj.h 9 Jun 2003 09:26:14 -
@@ -79,13 +79,13 @@
#define KOBJ_CACHE_SIZE256
struct kobj_ops {
- kobj_method_t cache[KOBJ_CACHE_SIZE];
+ kobj_method_t *cache[KOBJ_CACHE_SIZE];
kobj_class_tcls;
};
struct kobjop_desc {
unsigned intid; /* unique ID */
- kobjop_tdeflt; /* default implementation */
+ kobj_method_t *deflt; /* default implementation */
};
/*
@@ -151,19 +151,27 @@
*/
#define KOBJOPLOOKUP(OPS,OP) do { \
kobjop_desc_t _desc = &OP##_##desc; \
- kobj_method_t *_ce =\
+ kobj_method_t **_cep = \
&OPS->cache[_desc->id & (KOBJ_CACHE_SIZE-1)]; \
+ kobj_method_t *_ce = *_cep; \
if (_ce->desc != _desc) { \
KOBJOPMISS; \
- kobj_lookup_method(OPS->cls->methods, _ce, _desc); \
+ _ce = kobj_lookup_method(OPS->cls->methods, \
+_cep, _desc); \
} else {\
KOBJOPHIT; \
} \
_m = _ce->func; \
} while(0)
-void kobj_lookup_method(kobj_method_t *methods,
- kobj_method_t *ce,
- kobjop_desc_t desc);
+kobj_method_t* kobj_lookup_method(kobj_method_t *methods,
+ kobj_method_t **cep,
+ kobjop_desc_t desc);
+
+
+/*
+ * Default method implementation. Returns ENXIO.
+ */
+int kobj_error_method(void);
#endif /* !_SYS_KOBJ_H_ */
Index: kern/subr_kobj.c
===
RCS file: /home/ncvs/src/sys/kern/subr_kobj.c,v
retrieving revision 1.5
diff -u -r1.5 subr_kobj.c
--- kern/subr_kobj.c10 Jun 2002 22:40:26 - 1.5
+++ kern/subr_kobj.c9 Jun 2003 09:27:14 -
@@ -59,7 +59,7 @@
static int kobj_next_id = 1;
-static int
Re: VFS: C99 sparse format for struct vfsops
On Thu, 2003-06-05 at 15:51, Paul Richards wrote: > On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: > > On Wed, 2003-06-04 at 14:16, Paul Richards wrote: > > > On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: > > > > > > > Interfaces actually can be added at runtime. Existing objects (i.e. > > > > objects instantiated before the new interface was added) will continue > > > > to work as before. If methods from the new interface are called on old > > > > objects, the default method will be called. > > > > > > How can you add an interface at runtime? > > > > By loading a kernel module. If I load e.g. the agp kernel module, I add > > the agp_if interface to the kernel. > > Yes, I know that you can load a pre-compiled interface at runtime > and thereby add that interface, but you can only "create" interfaces > at build time because each method in the interface is uniquely > identified by a kobjop_desc struct, which is what I was referring to. What has build time got to do with anything? At build time, you have no idea what interfaces are available either. Besides modules can be built at a different time from the rest of the kernel. > > > The code which is doing the method dispatch has no real idea what > > methods (or what interfaces for that matter) that the object's class > > implements. You can't use the classes method table layout for the ops > > table since the caller has no way of knowing that layout (and the layout > > will be different for almost every class in the system). > > > > One possible way of making this slightly simpler might be to make the > > class point at a table indexed by interface ID, each entry of which is a > > table indexed by a method ID from that interface. This sounds fine in > > theory but in practice, it would end up slower due to the two memory > > accesses. > > That's along the lines of what I suggested at the start of the thread :-) Its still slower and wastes more memory and bloats the code for every call site. I have a better approach in mind which I will be trying out soonish. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VFS: C99 sparse format for struct vfsops
On Wed, 2003-06-04 at 14:16, Paul Richards wrote: > On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: > > > Interfaces actually can be added at runtime. Existing objects (i.e. > > objects instantiated before the new interface was added) will continue > > to work as before. If methods from the new interface are called on old > > objects, the default method will be called. > > How can you add an interface at runtime? By loading a kernel module. If I load e.g. the agp kernel module, I add the agp_if interface to the kernel. > > All of this runtime activity is theoretically possible, i.e. all > these structures can be messed around with to add methods to existing > objects etc. but wasn't kobj supposed to provide an OO type > abstraction and therefore the interfaces and classes are determined > at compile time. > > I'm not aware of any actual code that changes interfaces or classes > at runtime and if we added that functionality then I think it would > break the abstraction and complicate the usage of kobj for no real > gain. > > Coming back to the central point, I don't understand why we need > a cache at all. I don't see the reason for having to support the > dispatching of anything other than the methods in the class that > the object was instantiated into, so that means a relatively small > fixed size method dispatch table. > > The only argument for that not working is if the class gets extended > after the object is created but I'm not convinced yet that that's > something to worry about in practice at least at the moment since we > don't extend classes anywhere. > > Even if we added code to make that possible at runtime it would be > simple enough to get a "miss" when looking that method up in older > objects and to realloc the method table in the object to accomodate > the new methods. Extending the class is something that is likely > to be so rare that some performance penalty should that happen > would be palatable. The code which is doing the method dispatch has no real idea what methods (or what interfaces for that matter) that the object's class implements. You can't use the classes method table layout for the ops table since the caller has no way of knowing that layout (and the layout will be different for almost every class in the system). One possible way of making this slightly simpler might be to make the class point at a table indexed by interface ID, each entry of which is a table indexed by a method ID from that interface. This sounds fine in theory but in practice, it would end up slower due to the two memory accesses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VFS: C99 sparse format for struct vfsops
On Wed, 2003-06-04 at 13:24, Paul Richards wrote: > On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote: > > On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: > > > On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: > > > > In message: <[EMAIL PROTECTED]> > > > > > > > > Paul Richards <[EMAIL PROTECTED]> writes: > > > > : The possible methods available in an interface are fixed, they're > > > > : defined in the .m files. > > > > > > > > No it isn't. One can add additional interfaces at any time without > > > > breaking binary compatibility, so you don't know, a priori, the > > > > number of methods in a given interface when you build a client of > > > > that interface. > > > > > > I don't think that's true. > > > > > > The interface is defined in the .m file and it's created using > > > makeobjs. You can't do that at runtime because it creates the > > > kobj_desc struct that uniquely represents the existence of that > > > method globally for the whole of the kobj subsystem. The set of all > > > kobj_desc defines all possible methods that can be implemented by an > > > object, and yes you can extend that interface later and previously > > > built modules will still work because they only implement a subset of > > > those possible methods, but the set of all methods that can exist is > > > determined at compile time from the interface definitions > > > > > > A class is then defined which specifies the set of methods that > > > objects instantiated into that class *can* implement (but are note > > > required to). The set of methods in a class is also fixed, since it's > > > basically the method table plus some class fields and the method > > > table is created at compile time. Again though, if you later extend > > > the class older compiled modules will still work because if the > > > method doesn't exist in that older module the default from the > > > kobj_desc will be used or the kobj_error_method will be called (which > > > is safe). > > > > > > So yes you can extend the interface and the class and keep backwards > > > compatibility but that all happens at compile time, and therefore at > > > runtime when the object is instantiated you know the maximum number > > > of methods that the object can possibly call. > > > > It is true, I'm afraid. A class is can implement any number of > > interfaces so knowing the compile-time size of an interface doesn't > > help you reserve space for a class. The system is intended to have a > > robust ABI so that e.g. a class implementing an interface can be used > > safely by a kernel in which new methods have been added to that > > interface. > > I though Warner meant adding interfaces at runtime, but he meant > build time (I misread that). My comments about interfaces where > therefore in rebuttal of the possibility to extend them at runtime. > So yes, what Warner asserted is true but as I did also point out > above and you've confirmed below, it's the class that determines > the methods for an object and that is fixed when the object is > instantiated into that class. Interfaces actually can be added at runtime. Existing objects (i.e. objects instantiated before the new interface was added) will continue to work as before. If methods from the new interface are called on old objects, the default method will be called. > > > The class is a concrete definition of a set of methods (at this level, > > the interfaces are mostly ignored). Objects instantiated in that class > > use exactly that set of methods, no more, no less. There is no choice > > involved. You appear to be confusing class and interface here. > > Given that we agree that the method table is fixed at object > instantiation time, why isn't allocating a fixed array appropriate? Mainly because there isn't an easy way to decide how big the array should be. The older version of this code reserved enough space for all current interfaces. This ended up wasting a lot of space (per class, not per object) and still ended up with a table size comparison in the method dispatch since interfaces might get added after existing classes had been initialised. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VFS: C99 sparse format for struct vfsops
On Mon, 2003-06-02 at 21:04, Paul Richards wrote: > On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote: > > > > Notice how thread 1's _m gets set based on the results of the kobj > > lookup, and we have a race, even if thread1 and thread2 took out their > > driver instance locks. > > That means we have to lock the dispatch table before every method is > looked up and hold it until the method returns (the alternative would be > to free it inside the method once it had been called but that'd be a > right mess). Don't even think about trying to put a mutex into the kobj dispatch sequence. That would make the call several thousand times slower. We might as well write the kernel in Visual Basic. I've been thinking about this problem for a long time and I'm certain there is a way to make this safe without sacrificing performance. I have an idea I'm working on right now which should work (at least I haven't managed to disprove it so far) and which would have approximately the same performance profile as the current mechanism. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VFS: C99 sparse format for struct vfsops
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: > On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > > > Paul Richards <[EMAIL PROTECTED]> writes: > > : The possible methods available in an interface are fixed, they're > > : defined in the .m files. > > > > No it isn't. One can add additional interfaces at any time without > > breaking binary compatibility, so you don't know, a priori, the > > number of methods in a given interface when you build a client of > > that interface. > > I don't think that's true. > > The interface is defined in the .m file and it's created using > makeobjs. You can't do that at runtime because it creates the > kobj_desc struct that uniquely represents the existence of that > method globally for the whole of the kobj subsystem. The set of all > kobj_desc defines all possible methods that can be implemented by an > object, and yes you can extend that interface later and previously > built modules will still work because they only implement a subset of > those possible methods, but the set of all methods that can exist is > determined at compile time from the interface definitions > > A class is then defined which specifies the set of methods that > objects instantiated into that class *can* implement (but are note > required to). The set of methods in a class is also fixed, since it's > basically the method table plus some class fields and the method > table is created at compile time. Again though, if you later extend > the class older compiled modules will still work because if the > method doesn't exist in that older module the default from the > kobj_desc will be used or the kobj_error_method will be called (which > is safe). > > So yes you can extend the interface and the class and keep backwards > compatibility but that all happens at compile time, and therefore at > runtime when the object is instantiated you know the maximum number > of methods that the object can possibly call. It is true, I'm afraid. A class is can implement any number of interfaces so knowing the compile-time size of an interface doesn't help you reserve space for a class. The system is intended to have a robust ABI so that e.g. a class implementing an interface can be used safely by a kernel in which new methods have been added to that interface. The class is a concrete definition of a set of methods (at this level, the interfaces are mostly ignored). Objects instantiated in that class use exactly that set of methods, no more, no less. There is no choice involved. You appear to be confusing class and interface here. This incarnation of kobj uses a smallish fixed-size method dispatch table, with hashing. A previous version (embedded into 4.x's newbus) allocated space in the method dispatch table for every interface which was currently resident in the kernel. This was fine when the expected number of interfaces was small but as the number of interfaces increases, the wasted space per-class increases unacceptably. This is the sole reason for changing the method-dispatch algorithm for kobj. The only valid objection to kobj at this point is that resolving hash collisions is not SMP safe. I believe that this is a limitation which can be overcome without pessimising the dispatch mechanism. Performance is not an issue. The performance of method dispatch in kobj is very slightly slower than a vtable-style array of function pointers but the difference is barely measurable. Given the behaviour of modern caches, it is possible to make nearly as many kobj method calls per second as normal function calls. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] note the __sF change in src/UPDATING
On Saturday 09 November 2002 4:28 pm, Daniel Eischen wrote: > On Sat, 9 Nov 2002, Doug Rabson wrote: > > On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > > > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > > > This is not a fly in the pointment, but rather a major > > > > incompatibility that makes it impossible to have a reasonable > > > > mix. > > > > > > If it's really a hassle for folks, then just provide the > > > optional compatability hack and make them rebuild libc. > > > Or provide a pre-built version that doesn't get installed > > > by default. > > > > So what you are saying, basically, is that we should ship a > > release, for the first time ever, which can't run old binaries. > > Sorry, that isn't acceptable. The correct and robust way of doing > > things is to stop creating binaries (in both 4.x and 5.x) that > > reference __sF, then wait a full release cycle for the change to > > propagate. We can then remove the symbol in 6.x. > > If you put an optional compatibility hack in libc, then folks > can still use it, plus they will be informed that it is going > away at some point. I don't think removing it from > is good enough. Unless there's a way of putting out an error > message at run-time, we need some other way of being a little > bit of a nuisance. I don't see the need for this. We aren't supporting the original broken API (i.e. __sF in stdio.h). We do need to support the broken ABI for another release cycle otherwise we break everyone who tries to upgrade from 4.x to 5.x, which is a bad thing. > > > In general, its a very poor idea to simply remove a feature that > > was supported in the last release of a package. The normal route is > > to deprecate (but still support) the feature in one release and > > remove it in the next. > > Do kld's from 4.x work on -current? Just curious -- I don't really > know. The kernel ABI is hopeless. It changes almost daily :-(. At one time, I thought I could change this but these days, I don't think anyone except me cares about having a stable ABI in the kernel. -- 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] note the __sF change in src/UPDATING
On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > In message: > > <[EMAIL PROTECTED]> > > > > Daniel Eischen <[EMAIL PROTECTED]> writes: > > : All the ports are going to be rebuilt for the release anyways, > > : so this doesn't affect fresh installs, correct? It is only a > > : problem when mixing older 4.x and 5.0 libraries/binaries with > > : __sF-free libc (if I understand things correctly). > > > > The problem is that you cannot have 4.x packages and 5.x packages > > co-mingled on the same system. that's what I'm trying to fix. > > You'd have to rebuild the 4.x packages before they are fixed. > > I don't think this is a show-stopper. Just recompile all your > ports or use the pre-built 5.0 packages. > > > : This is 5.0; it is a major release and there will be some flies > > : in the ointment. I say bite the bullet now -- don't wait. > > : If we want to provide an optional compatability hack to libc > > : so that folks can compile it with __sF support, then I think > > : that is better than leaving __sF in the release, perhaps > > : with a mktemp(3)-like warning if possible (?). > > > > You'd need a run-time warning for this to be effective. I'm not > > sure that ld.so can do this right now. > > Could you put __sF in it's own file, and put the error in > a .init section? We don't care about static binaries, right? > They shouldn't have a problem. > > > This is not a fly in the pointment, but rather a major > > incompatibility that makes it impossible to have a reasonable mix. > > If it's really a hassle for folks, then just provide the > optional compatability hack and make them rebuild libc. > Or provide a pre-built version that doesn't get installed > by default. So what you are saying, basically, is that we should ship a release, for the first time ever, which can't run old binaries. Sorry, that isn't acceptable. The correct and robust way of doing things is to stop creating binaries (in both 4.x and 5.x) that reference __sF, then wait a full release cycle for the change to propagate. We can then remove the symbol in 6.x. In general, its a very poor idea to simply remove a feature that was supported in the last release of a package. The normal route is to deprecate (but still support) the feature in one release and remove it in the next. -- 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] note the __sF change in src/UPDATING
On Thursday 07 November 2002 9:42 pm, Tim Kientzle wrote: > Terry Lambert asked: > > Any chance we could get rid of all externally visable symbols that > > are not defined as being there by some standard, and not just __sF, > > since we are breaking the FORTRAN compiler and other third party > > code already? > > This cannot be entirely done if you still want to > manage library bloat. In short, library routines > have shared interfaces between them---common variables > or common functions---that are internal to the library > and should not be used by applications. > > To avoid this, you would have to bundle library functions > together, which causes bloat. Worse, you would have to > avoid or drastically limit your use of macros. (Any > macro that uses one of these internal symbols generates > a dependency in the compiled application.) > > It _would_ be a good idea to document any internal library > symbols used by macros. Removing such symbols is a > good way to break existing compiled applications. > > Library design involves a lot of tradeoffs. In the windows world, all this is handled by having a strict list of explicit symbol exports, either in the source code using syntax extensions or with a file supplied to the linker. I'm not sure whether binutils supports this kind of thing but it would allow us to cut down the set of symbols exported from libc.so. -- 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 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. It looks like my problems centered around not properly re-compiling the fam port. KDE 3.0.4 is working nicely now. -- 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
ock_destroy(rwlock));
+}
+
+static int
+pthread_rwlock_rdlock_stub(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_rdlock(rwlock));
+}
+
+static int
+pthread_rwlock_tryrdlock_stub(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_tryrdlock(rwlock));
+}
+
+static int
+pthread_rwlock_trywrlock_stub(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_trywrlock(rwlock));
+}
+
+static int
+pthread_rwlock_unlock_stub(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_unlock(rwlock));
+}
+
+static int
+pthread_rwlock_wrlock_stub(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_wrlock(rwlock));
+}
+
+static pthread_t
+pthread_self_stub(void)
+{
+ return (_pthread_self());
+}
+
+static int
+pthread_setspecific_stub(pthread_key_t key, const void *value)
+{
+ return (_pthread_setspecific(key, value));
+}
+
+static int
+pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
+{
+ return (_pthread_sigmask(how, set, oset));
}
Index: include/namespace.h
===
RCS file: /home/ncvs/src/lib/libc/include/namespace.h,v
retrieving revision 1.9
diff -u -r1.9 namespace.h
--- include/namespace.h 29 Mar 2002 22:43:42 - 1.9
+++ include/namespace.h 30 Oct 2002 20:04:44 -
@@ -77,6 +77,7 @@
#defineopen_open
#definepoll_poll
#definepthread_cond_signal _pthread_cond_signal
+#definepthread_cond_broadcast _pthread_cond_broadcast
#definepthread_cond_wait _pthread_cond_wait
#definepthread_cond_init _pthread_cond_init
#definepthread_exit_pthread_exit
Index: include/reentrant.h
===
RCS file: /home/ncvs/src/lib/libc/include/reentrant.h,v
retrieving revision 1.1
diff -u -r1.1 reentrant.h
--- include/reentrant.h 19 Mar 2001 12:49:49 - 1.1
+++ include/reentrant.h 30 Oct 2002 20:04:44 -
@@ -109,6 +109,8 @@
#define cond_init(c, a, p) _pthread_cond_init(c, a)
#define cond_signal(m) if (__isthreaded) \
_pthread_cond_signal(m)
+#define cond_broadcast(m) if (__isthreaded) \
+ _pthread_cond_broadcast(m)
#define cond_wait(c, m)if (__isthreaded) \
_pthread_cond_wait(c, m)
--
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 Thu, 31 Oct 2002, Daniel Eischen wrote: > On Thu, 31 Oct 2002, Doug Rabson wrote: > > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > I don't see how that can be. _pthread_mutex_lock() in libc_r calls > > > init_static_private(), not init_static(). > > > > That was it (I single stepped through this in the debugger a couple of > > days ago). Unfortunately init_static_private() also calls > > pthread_mutex_init() without the leading underscore. > > And because it calls the non-underscore version, this breaks something? > I guess both init_static_private and init_static should both call > _pthread_mutex_init. Yes. In my case it ended up in a noop stub defined by libXThrStub.so. Right afterwards libc_r bombed because the mutex it tried to initialise wasn't initialised. -- 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 Thu, 31 Oct 2002, Daniel Eischen wrote: > On Thu, 31 Oct 2002, Doug Rabson wrote: > > > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > > > On Thu, 31 Oct 2002, Doug Rabson wrote: > > > > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > > > You can also play the libgcc game inside of libc for those applications > > > > > or libraries that are too lazy to do it for themselves. Have the > > > > > libc pthread stubs key on a weak reference to pthread_create and > > > > > call the pthread_* if they are present. libXThrStub should be > > > > > able to do that though. > > > > > > > > It almost doesn't matter which of the solutions we use as long as we do > > > > something. What we currently have is clearly wrong but I'll list it along > > > > with the others. Solutions so far proposed are: > > > > > > > > 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads > > > > implementation defines strong _pthread_* symbols and weak pthread_* > > > > aliases for them. Anyone else which defines pthread_* symbols (either weak > > > > or strong) can take over and will normally end up breaking libc. > > > > > > We only use _pthread_* in libc, so it doesn't break libc unless > > > they provide strong symbols for _pthread_*. Our implementation > > > relies on the use of single underscore versions in libc so we > > > can tell the difference between the implementation locks and > > > application locks. The weak references from pthread_* in libc_r > > > are to the double underscore versions (mostly, the locking > > > functions) so that applications actually resolve to __pthread_mutex_lock > > > and libc uses will resolve to _pthread_mutex_lock. > > > > Actually its pretty easy to break libc. Someone calls flockfile() which in > > turn calls _pthread_mutex_lock(). This ends up in libc_r which notices > > that the mutex is uninitialised and calls init_static(). That calls > > pthread_mutex_init() and dies shortly afterwards (note the non-_pthread > > call from init_static()). > > I don't see how that can be. _pthread_mutex_lock() in libc_r calls > init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. > > > > > > > > > Right now, I can't tell what Solaris does. Alexander suggested that it was > > > > (1) but you disagree. It would be interesting to see the output of 'nm | > > > > grep pthread' for both libc.so and libpthread.so. > > > > > > I've already done that and posted it. Here it is again. > > > > > > ... > > > > Ok then. Next attempt. This one defines weak pthread_foo stubs which call > > _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All > > symbols weak. Everyone happy. Actually, I haven't tested this since my > > test system is at home. For kicks, I also staticised the stubs. > > This is better, although it has two stubs for each routine. Adding > a weak definition from pthread_foo() to _pthread_foo() (note the > lack of _stub) doesn't do the same thing? I already tried that one this morning. The assignment happens at compile time unfortunately. What I wanted was for pthread_foo to be resolved in rtld to the best available _pthread_foo. Unforunately the resolution happens at link time and by the time we get to rtld, we just have a pthread_foo which happens to have the same value as _pthread_foo. -- 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 Thu, 31 Oct 2002, Daniel Eischen wrote:
> On Thu, 31 Oct 2002, Doug Rabson wrote:
> > On Thu, 31 Oct 2002, Daniel Eischen wrote:
> > > You can also play the libgcc game inside of libc for those applications
> > > or libraries that are too lazy to do it for themselves. Have the
> > > libc pthread stubs key on a weak reference to pthread_create and
> > > call the pthread_* if they are present. libXThrStub should be
> > > able to do that though.
> >
> > It almost doesn't matter which of the solutions we use as long as we do
> > something. What we currently have is clearly wrong but I'll list it along
> > with the others. Solutions so far proposed are:
> >
> > 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads
> > implementation defines strong _pthread_* symbols and weak pthread_*
> > aliases for them. Anyone else which defines pthread_* symbols (either weak
> > or strong) can take over and will normally end up breaking libc.
>
> We only use _pthread_* in libc, so it doesn't break libc unless
> they provide strong symbols for _pthread_*. Our implementation
> relies on the use of single underscore versions in libc so we
> can tell the difference between the implementation locks and
> application locks. The weak references from pthread_* in libc_r
> are to the double underscore versions (mostly, the locking
> functions) so that applications actually resolve to __pthread_mutex_lock
> and libc uses will resolve to _pthread_mutex_lock.
Actually its pretty easy to break libc. Someone calls flockfile() which in
turn calls _pthread_mutex_lock(). This ends up in libc_r which notices
that the mutex is uninitialised and calls init_static(). That calls
pthread_mutex_init() and dies shortly afterwards (note the non-_pthread
call from init_static()).
> >
> > Right now, I can't tell what Solaris does. Alexander suggested that it was
> > (1) but you disagree. It would be interesting to see the output of 'nm |
> > grep pthread' for both libc.so and libpthread.so.
>
> I've already done that and posted it. Here it is again.
>
> ...
Ok then. Next attempt. This one defines weak pthread_foo stubs which call
_pthread_foo. It also defines weak _pthread_foo stubs which are noops. All
symbols weak. Everyone happy. Actually, I haven't tested this since my
test system is at home. For kicks, I also staticised the stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 15:39:50 -
@@ -31,6 +31,9 @@
#include
#include
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -73,166 +78,371 @@
static struct pthread main_thread;
-int
+static int
_pthread_cond_init_stub(pthread_cond_t *cond,
const pthread_condattr_t *cond_attr)
{
return (0);
}
-int
+static int
_pthread_cond_signal_stub(pthread_cond_t *cond)
{
return (0);
}
-int
+static int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+static int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
}
-int
+static int
_pthread_cond_destroy_stub(pthread_cond_t *cond)
{
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: > On Thu, 31 Oct 2002, Alexander Kabaev wrote: > > > On Thu, 31 Oct 2002 09:08:12 -0500 (EST) > > Daniel Eischen <[EMAIL PROTECTED]> wrote: > > > > > > 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_??. > > > > > > No, please see earlier messages in this thread. > > > > > > > Dan, > > > > could you please be consistent? You cited Solaris as an example against > > making all the symbols in libc_r strong. I gave you an answer that the > > only way why this works on Solaris is because libc itself provides weak > > pthread_ definitions. pthread_ functions in libc simply call their > > _pthread counterparts, which are also weekly defined in libc. libpthread > > defines _pthread_ symbols as strong and consequently its symbols > > override one provided by libc. > > No, you stated that Solaris libpthread defines pthread_ symbols > strong. It doesn't. Perhaps you really meant _pthread_ symbols, > which is what you say above. > > For the record, neither libc nor libthread or libpthread in Solaris > provide strong pthread_* symbols. They (Solaris) do provide strong > _pthread_* symbols in libpthread, as we do in libc_r. > > bash-2.05$ uname -rvs > SunOS 5.8 Generic_108528-12 > bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock > 3c80 T _pthread_mutex_lock > 3c80 W pthread_mutex_lock > bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock > 00096c38 W _pthread_mutex_lock > 00096c38 W pthread_mutex_lock Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. -- 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 Thu, 31 Oct 2002, Daniel Eischen wrote: > On Thu, 31 Oct 2002, Doug Rabson wrote: > > > On Thu, 31 Oct 2002, Alexander Kabaev wrote: > > > > > 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. > > > > Something along these lines appears to work nicely and ought to work > > either with or without libXThrStub, which is now redundant since libc will > > be providing strong symbols that override all the weak symbols in > > libXThrStub. We should adjust the XFree86-4-libraries port to avoid > > building and using that library. > > Please no, you've got strong pthread_* symbols in libc. I'd rather > see them as strong in libpthread (but don't really want that either). > > You can also play the libgcc game inside of libc for those applications > or libraries that are too lazy to do it for themselves. Have the > libc pthread stubs key on a weak reference to pthread_create and > call the pthread_* if they are present. libXThrStub should be > able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. -- 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 Thu, 31 Oct 2002, Max Khon wrote: > hi, there! > > On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: > > > > 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. > > > > Huh? Your statement is rather speculative stuff. Other systems (say > > Linux) are using the same linker we are. Please speculate less. Please > > grab an older ld and try to prove your speculation. > > I think the problem is in our dynamic linker or in the way we link > dynamic libraries or in the way we compile and link X11 libraries. > Linux also has pthreads symbols weakly defined > (some of them are defined in glibc, some of them in libpthread) > and does not have such problems. I think you are mistaken. On my RedHat 8.0 system, there are weak pthread_* symbols in libc.so and strong ones in libpthread.so. Linux doesn't use libXThrStub.so, presumably because libc.so's pthread_* symbols are suitable 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 Thu, 31 Oct 2002, Doug Rabson wrote:
> On Thu, 31 Oct 2002, Alexander Kabaev wrote:
>
> > 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.
>
> Something along these lines appears to work nicely and ought to work
> either with or without libXThrStub, which is now redundant since libc will
> be providing strong symbols that override all the weak symbols in
> libXThrStub. We should adjust the XFree86-4-libraries port to avoid
> building and using that library.
This version works better - it fixes some typos in the rwlock stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 10:10:42 -
@@ -31,6 +31,9 @@
#include
#include
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -87,6 +92,12 @@
}
int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
@@ -235,4 +246,174 @@
_pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
{
return (0);
+}
+
+int
+pthread_cond_init(pthread_cond_t *cond,
+const pthread_condattr_t *cond_attr)
+{
+ return (_pthread_cond_init(cond, cond_attr));
+}
+
+int
+pthread_cond_signal(pthread_cond_t *cond)
+{
+ return (_pthread_cond_signal(cond));
+}
+
+int
+pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ return (_pthread_cond_broadcast(cond));
+}
+
+int
+pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
+{
+ return (_pthread_cond_wait(cond, mutex));
+}
+
+int
+pthread_cond_destroy(pthread_cond_t *cond)
+{
+ return (_pthread_cond_destroy(cond));
+}
+
+void *
+pthread_getspecific(pthread_key_t key)
+{
+ return (_pthread_getspecific(key));
+}
+
+int
+pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
+{
+ return (_pthread_key_create(key, destructor));
+}
+
+int
+pthread_key_delete(pthread_key_t key)
+{
+ return (_pthread_key_delete(key));
+}
+
+int
+pthread_main_np()
+{
+ return (_pthread_main_np());
+}
+
+int
+pthread_mutex_destroy(pthread_mutex_t *mattr)
+{
+ return (_pthread_mutex_destroy(mattr));
+}
+
+int
+pthre
Re: [PATCH: libc]Re: gnome on current
hread_rwlock_init(rwlock, attr));
+}
+
+int
+pthread_rwlock_destroy(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_destroy(rwlock));
+}
+
+int
+pthread_rwlock_rdlock(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_rdlock(rwlock));
+}
+
+int
+pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_tryrdlock(rwlock));
+}
+
+int
+pthread_rwlock_trywrlock(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_trywrlock(rwlock));
+}
+
+int
+pthread_rwlock_unlock(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_unlock(rwlock));
+}
+
+int
+pthread_rwlock_wrlock(pthread_rwlock_t *rwlock)
+{
+ return (_pthread_rwlock_wrlock(rwlock));
+}
+
+pthread_t
+pthread_self(void)
+{
+ return (_pthread_self());
+}
+
+int
+pthread_setspecific(pthread_key_t key, const void *value)
+{
+ return (_pthread_setspecific(key, value));
+}
+
+int
+pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
+{
+ return (_pthread_sigmask(how, set, oset));
}
Index: include/namespace.h
===
RCS file: /home/ncvs/src/lib/libc/include/namespace.h,v
retrieving revision 1.9
diff -u -r1.9 namespace.h
--- include/namespace.h 29 Mar 2002 22:43:42 - 1.9
+++ include/namespace.h 30 Oct 2002 20:04:44 -
@@ -77,6 +77,7 @@
#defineopen_open
#definepoll_poll
#definepthread_cond_signal _pthread_cond_signal
+#definepthread_cond_broadcast _pthread_cond_broadcast
#definepthread_cond_wait _pthread_cond_wait
#definepthread_cond_init _pthread_cond_init
#definepthread_exit_pthread_exit
Index: include/reentrant.h
===
RCS file: /home/ncvs/src/lib/libc/include/reentrant.h,v
retrieving revision 1.1
diff -u -r1.1 reentrant.h
--- include/reentrant.h 19 Mar 2001 12:49:49 - 1.1
+++ include/reentrant.h 30 Oct 2002 20:04:44 -
@@ -109,6 +109,8 @@
#define cond_init(c, a, p) _pthread_cond_init(c, a)
#define cond_signal(m) if (__isthreaded) \
_pthread_cond_signal(m)
+#define cond_broadcast(m) if (__isthreaded) \
+ _pthread_cond_broadcast(m)
#define cond_wait(c, m)if (__isthreaded) \
_pthread_cond_wait(c, m)
--
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 Thu, 31 Oct 2002, Alexander Kabaev wrote: > 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. Our libc is quite different. We define a (weak) set of _pthread_* symbols and libc_r defines a set of strong _pthread_* symbols and a set of weak pthread_* aliases for them. It sounds like libc should define weak _pthread_*, and weak pthread_* aliases for them. Libc_r should define strong _pthread_* symbols and libc's aliases will then resolve to them. That ought to work quite well in this situation and should satisfy everyone. -- 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, Daniel Eischen wrote: > 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. Actually, I don't much care about Solaris. I care that a popular desktop package which we have supported for earlier releases does not work. I don't expect anyone to ever run gnome on Solaris but people certainly run gnome on FreeBSD. If you can find some other way that pthread calls can be directed reliably to libc_r even if some random stub library was loaded first, then fine. Otherwise, it seems that strong definitions for pthread symbols is the only reasonable option (which is why gnome2 works on FreeBSD 4.7 presumably). -- 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, Juli Mallett wrote: > * 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. I'm not misunderstanding things. I single stepped through the call to pthread_setspecific(), watched the linker lookup the symbol and followed it through into the wrong place (i.e. the stub instead of the real implementation). -- 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: > > > 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: [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: 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: [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: [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: 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: gnome on current
On Tue, 29 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > The point is that with the current setup of the XFree86-4-libraries port, > > you don't have any choice, since libX11 links to libXThrStub. This is the > > key problem, IMHO. I have a machine running RedHat 8.0 and they don't have > > any such thing. On RedHat, libXThrStub doesn't even exist. > > So what breaks, when you dike it out? Building now... > > > All you have to do is create a situation where a shared object that links > > to libc_r is loaded after libX11 and the thing breaks into little pieces. > > So let's dike out libXThrStub.so, and be done with it. I think the only stub which it defines that libc.so doesn't also define is pthread_cond_broadcast. I'm waiting to see if that lack causes any noticeable problems. -- 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: gnome on current
On Tue, 29 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > The point is that with the current setup of the XFree86-4-libraries port, > > you don't have any choice, since libX11 links to libXThrStub. This is the > > key problem, IMHO. I have a machine running RedHat 8.0 and they don't have > > any such thing. On RedHat, libXThrStub doesn't even exist. > > So what breaks, when you dike it out? I doubt if anything would break. Our libc already defines a perfectly reasonable set of pthread stubs. > > > All you have to do is create a situation where a shared object that links > > to libc_r is loaded after libX11 and the thing breaks into little pieces. > > So let's dike out libXThrStub.so, and be done with it. Probably. -- 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: gnome on current
On Tue, 29 Oct 2002, Terry Lambert wrote: > Doug Rabson wrote: > > On investigating one of the crashes more carefully, I discovered that all > > calls to pthread_*() were being resolved to stubs in libXThrStub.so in > > spite of the fact that libc_r was also loaded. This caused problems for > > e.g. flockfile which failed to initialise its mutex (uthread_mutex.c's > > init_static calls pthread_mutex_init instead of _pthread_mutex_init and > > ends up in libXThrStub). After working around that, I had more fun where > > one of the gnome libs tried to call pthread_getspecific(). > > > > Why isn't the linker resolving these symbols against the ones in libc_r? > > For some reason, libc_r defines them weakly so they get resolved by the > > first weak definition in the list of libs, which in this case is > > libXThrStub :-( > > So that people who know what they are doing can implement their > own versions of the code do in.strument things like "open". > > Unfortunately, the people who wrote libXThrStub.so apparently > didn't know what they were doing... > > Or, more likely, you are not supposed to be linking against > library at all, if you have a working threads library... I > feel pretty safe guessing that, given that it's name seems to > le "X Threads Stub Library". The point is that with the current setup of the XFree86-4-libraries port, you don't have any choice, since libX11 links to libXThrStub. This is the key problem, IMHO. I have a machine running RedHat 8.0 and they don't have any such thing. On RedHat, libXThrStub doesn't even exist. All you have to do is create a situation where a shared object that links to libc_r is loaded after libX11 and the thing breaks into little pieces. -- 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: gnome on current
On Tue, 29 Oct 2002, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Doug Rabson <[EMAIL PROTECTED]> wrote: > > On Tue, 29 Oct 2002, John Polstra wrote: > > > When a symbol is defined in multiple libraries, the first library > > > wins. That's how it has always been in Unix, for archive libraries > > > and for shared libraries. > > > > This is a big problem then since X11.so links to XThrStub.so. This means > > that XThrStub will be ahead of libc_r in many situations. > > I think it would work if the symbol were defined strongly in libc_r. I think so too. I was trying to work out why this wasn't how things were done already. FWIW, linux's libpthread appears to be defining the pthread_* symbols strongly. -- 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: gnome on current
On Tue, 29 Oct 2002, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Doug Rabson <[EMAIL PROTECTED]> wrote: > > I just spent a few hours trying to get gnome working on one of my systems, > > since kde still appears to be completely hosed. Unfortunately, not much of > > it worked reliably. In particular, all the sawfish preferences applets > > crash instantly. > > > > On investigating one of the crashes more carefully, I discovered that all > > calls to pthread_*() were being resolved to stubs in libXThrStub.so in > > spite of the fact that libc_r was also loaded. This caused problems for > > e.g. flockfile which failed to initialise its mutex (uthread_mutex.c's > > init_static calls pthread_mutex_init instead of _pthread_mutex_init and > > ends up in libXThrStub). After working around that, I had more fun where > > one of the gnome libs tried to call pthread_getspecific(). > > > > Why isn't the linker resolving these symbols against the ones in libc_r? > > For some reason, libc_r defines them weakly so they get resolved by the > > first weak definition in the list of libs, which in this case is > > libXThrStub :-( > > When a symbol is defined in multiple libraries, the first library > wins. That's how it has always been in Unix, for archive libraries > and for shared libraries. This is a big problem then since X11.so links to XThrStub.so. This means that XThrStub will be ahead of libc_r in many situations. -- 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
gnome on current
I just spent a few hours trying to get gnome working on one of my systems, since kde still appears to be completely hosed. Unfortunately, not much of it worked reliably. In particular, all the sawfish preferences applets crash instantly. On investigating one of the crashes more carefully, I discovered that all calls to pthread_*() were being resolved to stubs in libXThrStub.so in spite of the fact that libc_r was also loaded. This caused problems for e.g. flockfile which failed to initialise its mutex (uthread_mutex.c's init_static calls pthread_mutex_init instead of _pthread_mutex_init and ends up in libXThrStub). After working around that, I had more fun where one of the gnome libs tried to call pthread_getspecific(). Why isn't the linker resolving these symbols against the ones in libc_r? For some reason, libc_r defines them weakly so they get resolved by the first weak definition in the list of libs, which in this case is 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: gdb breaks world
On Wednesday 22 May 2002 6:49 pm, David O'Brien wrote: > On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote: > > GDB 5.2 works pretty well with -current - I've been using it recently. I > > plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough > > time to sort out the CVS magic). > > I fail to see your patches to gdb 5.2 for the kernel bits. > It would be nice to get them in the public view before they are > committed. I'll certainly put them up for review when I've written them. I've been busy on other things since we last spoke on the subject. -- 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: gdb breaks world
On Monday 20 May 2002 3:49 am, Terry Lambert wrote: > Steve Kargl wrote: > > > Use "-ggdb" instead, thus avoiding DWARF. > > > > BZZZT... Thanks for play! > > Did Mark Peek's suggestion of using the gdb that matched > the compiler (gdb 5.2 from ports) work instead? GDB 5.2 works pretty well with -current - I've been using it recently. I plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to sort out the CVS magic). -- 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: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
On Saturday 27 April 2002 4:51 am, Kris Kennaway wrote: > On Fri, Apr 26, 2002 at 02:51:08PM -0700, Poul-Henning Kamp wrote: > > phk 2002/04/26 14:51:08 PDT > > > > Modified files: > > sys/kern kern_tc.c > > sys/sys timepps.h timetc.h > > Log: > > This commit causes the bento package cluster to hang at boot time: > > [...] > Timecounters tick every 10.000 msec > ad0: 29314MB [59560/16/63] at ata0-master UDMA66 > Mounting root from nfs: > > And it hangs there forever. Backing out this commit fixes things. It hangs on my ia64 diskless box too. -- 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: can't build world on alpha
On Sun, 24 Mar 2002, Matthew Dillon wrote: > > :On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: > :> Anyone have any ideas? I'm trying to build the latest -current > :> (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. > : > :I have thought about what could be the problem several times and cannot > :come up with anything (thus my slow responce). > : > :Please tell more about your environment. How did you get 4.3 on the > :Alpha. Can you build 4.3 first to verify things are OK. Or are you > :willing to try building RELENG_4 first? > > I have successfully built and installed a -stable world. It took all > day, but it worked :-) Unfortunately, it did not clear up the problem. > > I still get this error however: You must build kernel sources for -current with the argument -ffixed-8. -- 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: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Fri, 8 Mar 2002, Matthew Jacob wrote: > > And FWIW, alpha kernels on some Uniprocessor boxes freeze up. I managed to panic my 4-cpu 4100 yesterday with a 'make -j8 buildworld' I'm going to look at that today. -- 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 for critical_enter()/critical_exit() & interrupt assemblyrevamp, please review!
On Sun, 24 Feb 2002, Andrew Gallatin wrote: > > I'm not fluent in x86 asm, so can you confirm for me what you're > attempting to do here? > > I think you're making critical_enter()/critical_exit() cheaper by not > actually messing with the interrupt hardware when they're called. > Very much like what we do in 4-stable. > > Instead, you set/clear a per-cpu flag (or incr/decr a counter). If an > interrupt comes in when you're inside a critical section, you make > note of it & mask interrupts on that cpu. In critical_exit(), > you run the interrupt handler if there's a pending interrupt, and > unmask interrupts. If there's not a pending interrupt, you just clear > the flag (or devrement a counter). > > Is that basically it? > > If so, I'm wondering if this is even possible on alpha, where we don't > have direct access to the hardware. However, according to the psuedo > code for rti in the Brown book, munging with the saved PSL in > trapframe to set the IPL should work. Hmm.. I think we can tweak the saved PSL and it should be able to mask interrupts in the same way as for x86. This should be quite easy for ia64 too. -- 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: FreeBSD/powerpc commit candidate for review
On Tue, 5 Jun 2001, Benno Rice wrote: > After considration of the last patchset I put up, I decided to get the > stuff in a slightly cleaner condition before I committed. > > The results are now at: > http://people.freebsd.org/~benno/commit/powerpc.diff > > There's still a lot of commented or #if 0'd out code, but I've cleaned up > a lot of warnings, did a style pass of sorts and also managed to get VM > initialising properly. =) > > You can see the current boot messages from my iMac at: > http://jeamland.net/~benno/powerpc-boot.txt > > It hangs after the mountroot> prompt. > > I'd like to commit this around the end of this week. > > Replies have been set to go to freebsd-ppc. Congratulations on the progress so far! You probably want to fix the $FreeBSD$ in md_var.h and maybe change/delete the alpha specific stuff there. Come to think about it, there are several cases where the $FreeBSD$ header still shows the location where the file was copied from. The cvs scripts should stop you from committing these files until that is fixed. I notice that reloc.h is just the copyright message. I guess you ought to use your own copyright here instead of John Birrell's. Come to think of it, the same thing could be said of alpha/include/reloc.h. Perhaps this header could be removed entirely if the contents of i386/include/reloc.h found a better home. Other than those minor comments, I think it looks ready to commit. -- 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: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Brian > Somers writes: > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > : spell digiio.h /usr/include/sys/digi_io.h. > > Actually, the more I think about it, the more I like putting it in > /usr/include/sys/fooio.h. We have lots of other files there now. The > down side to this approach is that it breaks up the driver sources > that we've been trying to concentrate into sys/dev/foo/* (or > introduces asymetry such that you can't just toss in a -I/sys and have > the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. -- 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: HEADS UP! bad bug in -current.
On Tue, 1 May 2001, Peter Wemm wrote: > Any -current kernel built over the weekend is a likely victim of this bug. > In a nutshell, it will eat your root filesystem at the very least, leaving > you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156 > is should be avoided at all costs. > > BEWARE: there are some snapshots on current.freebsd.org with this bug. They > will self destruct after install. Too late - I'm just rebuilding one of my scratch machines right now :-( -- 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: Entropy harvesting? Grim reaper is more like it...
On Sat, 10 Mar 2001, David O'Brien wrote: > On Fri, Mar 09, 2001 at 01:39:58PM -0800, Matthew Jacob wrote: > > > Erm, just so you know. The 4100 here at WC doesn't even make it past > > > the SCSI probe due to interrupt issues. > > > > Hmm. Well, it *was* working a couple of days ago :-) > > Uh, actually _your_ 4100 is the only I've ever known to work on > post-SMPng. The WC 4100 has *never* worked on post SMPng. I don't > believe I've heard that DFR's runs SMPng either. > > I guess I should get a `dd' of your system disk, or get you a console on > the WC box. My 4100 was working after the last set of mcpcia fixes. I haven't updated it for about a week so it may be broken again I guess. -- 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: Dirty buffers on reboot..
On Sun, 10 Sep 2000, John Baldwin wrote: > > H. At least on the x86, curproc is now set to proc0 before we probe > to see how much memory we have in init386(). In fact, we set curproc up > right after setting up the GDT, and before both the ldt and idt, so at least > on x86, we won't get a trap with curproc == NULL. :) On the alpha I'm not > as sure. Hmm, after looking, we set curproc in alpha_init(), but we do > it much later on. I'm not sure if we have enabled interrupts at that point > or not. Interrupts are certainly not enabled in alpha_init() - this is the earliest part of the alpha boot sequence. After alpha_init() returns, we switch to using proc0's stack for the first time (alpha_init() runs on the bootstrap stack) and call mi_startup() to get the rest of the kernel going. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installed SMP patch and now mouse doesn't work?
On Wed, 6 Sep 2000, John Baldwin wrote: > The Hermit Hacker wrote: > > > > Have nothing else to go on yet ... I updated both the current source code > > and installed the SMP patch from Sept 5th. Everything installed great, > > rebooted and I can work in character mode ... go to X, and the mouse gives > > me no activity, where it did just before the upgrade ... > > > > Am still investigating at this end, but if anyone else has experience > > similar and knows how to fix? > > Uh, all of the SMPng boxes so far haven't had mice. :P Is your mouse a > serial mouse? There seem to be some problems with input on the sio > devices. This is because the schedsofttty() call is commented out so the high-level interrupt routine in sio is never entered. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
On Tue, 5 Sep 2000, David O'Brien wrote: > On Tue, Sep 05, 2000 at 05:58:32PM -0700, Jason Evans wrote: > > this email is a minimum 24 hour notice that SMP code will be committed > > to -current. > > What is the status of the Alpha bits? Will we have a working kernel > after the commit, or should we site tight for a week while the Alpha bits > are tweaked into working status? The code should boot - if not, I will follow up with a few cleanup commits. The next job for the alpha is to overhaul the interrupt code to support irq threads. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange problems with AGP driver & sound.
On Wed, 6 Sep 2000, Stephen Hocking wrote: > > With very recent current sources, the agp driver doesn't probe when loaded as > a module, but works OK when compiled into the kernel. Oh. I thought that was only a problem in 4.x. Can I see a verbose bootlog for a kernel where this is a problem. > > However, when compiled into the kernel, it seems to mess up the sound driver > (pcm, crystal cs23x) such that no sound or garbled sound at a low volume comes > out. Has anyone else seen this? I'm using the mga driver from the XFree86 cvs > tree to do 3D work, which is why I'm using the AGP driver. No idea about this one. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
On Sun, 25 Jun 2000, Soren Schmidt wrote: > It seems Mark Murray wrote: > > > > Without knowing what you typed (and where), I can't help. > > > > > > Well, I thought that was obvious :) > > > > Not really; folks do the darndest things. :-) > > > > > Just added options RANDOMDEV as pr your instructions and made > > > a new kernel with config -r and make depend then make > > > > Do you have a full crypto distribution (kernel also)? > > Nope, just figured that out myself :) > Aren't we supposed to be able to build without crypto ?? Since the random dev is a cryptographically strong PRNG, I think its reasonable to depend on the crypto kernel bits. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AGPGART for FreeBSD
--- Maxim Sobolev <[EMAIL PROTECTED]> wrote: > Hi, > > I've just found that somebody ported linux agpgart module (used by > the GXL) to > FreeBSD. Could someone take a look at it and tell me whether it have > a chances > to be imported into base system or I should create a port of it. > > http://utah-glx.sourceforge.net/gart/agpgart-freebsd-2619.tar.gz I haven't looked at the code yet but there is really no need for this since the AGP driver which I committed to -current last week should work just fine for most reasonable uses. I will be merging this driver to 4.x as soon as it gets more testing in -current. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: GDB 5.0 is released!
On Fri, 26 May 2000, David O'Brien wrote: > > > > GDB 5.0 is released! > > Do you have any forecasts as to when we will see this baby in the -current? > > Its priority is behind GCC 2.96 Incidentally David, I have some patches which make a pre-release gdb 5.0 work for FreeBSD which I was going to give you since you have the right paperwork for submitting stuff to FSF. With those patches, a simple port would be easy and might make importing it to -current a bit easier. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major device numbers and mem device redesign
On Sun, 21 May 2000, Mark Murray wrote: > Hi > > I want to commit a new /dev/random RSN, so I'll be needing a major > device; what is the procedure for getting one? I know how to steal one, > but ISTR that this is not how it is done. Just edit sys/conf/majors and claim the next available number. > > Also - Peter said something about the "mem" device needing > to only contain the /dev/mem and /mem/kmem devices, and > /dev/(random|urandom|null|zero) needing to move to MI areas. I have done > this, as KLD's. Who wants to review? I'll take a look. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On Wed, 10 May 2000, Simon Shapiro wrote: > > On 10-May-00 Doug Rabson wrote: > > On Tue, 9 May 2000, Mike Smith wrote: > > > >> > On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: > >> > > The only answer I've seen for this one is to kick, hard, whoever it was > >> > > that added -Wcast-qual to the kernel options. > >> > > >> > Or we should just delete it from the options. > >> > >> Ugh. I don't actually like that, because it serves a valid purpose. > >> What irritates me mostly is just that there is no way of casting a > >> volatile object into a non-volatile type, so you can't implement any sort > >> of conditional volatility exclusion. > > > > You can suppress the warning if you cast to uintptr_t first. Pretty ugly > > though. > > It actually worked! Now I will go and see what this uintptr_t > actually is :-) Its an unsigned integer type which is the same size as a pointer (i.e. its safe to cast a pointer to uintptr_t without losing information). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
On Tue, 9 May 2000, Mike Smith wrote: > > > > On 10-May-00 Mike Smith wrote: > > >> Sorry to bother y'll, but; > > >> > > >> Has anyone ever used that? I see no trace of any kernel > > >> code calling it, and the at_shutdown code appears to be > > >> gone. > > > > > > It's still used in the shutdown code; it was meant to be available for > > > general use elsewhere, but I haven't seen anyone playing with it, so > > > maybe the design tradeoffs were bad choices. > > > > I dunno. It seems to do anything I need; Call me with an argument. > > I do not even need the priority. > > It won't notify you that your code is about to be removed from the kernel. > > > >> BTW, for all it is worth, any caching controller not using > > >> this is guaranteed to lose data. > > > > > > Wrong layer. You should be using the bus shutdown method; look at eg. > > > the Mylex driver to see how this is done. You should probably call your > > > flush routine from the suspend method as well. > > > > This is dangerous for the OSM. When the i2o OSM shuts an IOP > > down, it is history. It will stop doing any work at all; network, > > disk, console, mouse, whatever. I reserve that for really, really > > shutdown/reset. > > I'm not sure I understand what you mean by "dangerous". When your > shutdown method is called, you're being told that you're about to stop > being able to control your hardware, either because your code is about to > be removed from the kernel (module unload) or because the system is being > shut down. Actually, DEVICE_DETACH is called when the driver is unloaded and it can return an error which should abort the unload. If DEVICE_SHUTDOWN is called, then you have no choice - the kernel is stopping soon and this is your last change to tidy up. > > Before you return success from your shutdown method, you must have > brought your hardware to a quiescent state, ready for immediate loss of > power. It must not generate any more interrupts or access any more data > once you have returned. > > You can veto your shutdown (by returning nonzero), which will fail a > module unload, but _will_not_ fail a kernel shutdown. See above - you can veto detach but not shutdown. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On Tue, 9 May 2000, Mike Smith wrote: > > On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: > > > The only answer I've seen for this one is to kick, hard, whoever it was > > > that added -Wcast-qual to the kernel options. > > > > Or we should just delete it from the options. > > Ugh. I don't actually like that, because it serves a valid purpose. > What irritates me mostly is just that there is no way of casting a > volatile object into a non-volatile type, so you can't implement any sort > of conditional volatility exclusion. You can suppress the warning if you cast to uintptr_t first. Pretty ugly though. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
On Mon, 8 May 2000, Mike Pritchard wrote: > On Mon, May 08, 2000 at 02:10:28AM -0400, Kenneth Wayne Culver wrote: > > I have a suggestion for pkg_delete: Very often when I'm deleting a package > > (such as kde, after testing the port) I want to delete that package, and > > all it's dependancies; instead of going around looking for the > > dependancies, I think it would be a nice idea to add an option to > > pkg_delete to automatically delete all dependancies that aren't currently > > used by anything else. If nobody is interested in doing this, I can do it > > when I have some spare time (finals here at school). And then submit > > patches. > > That would have saved me a *lot* of time about a month ago when I > went and weeded out all of my packages when my /usr filled up. > I basically did what you are proposing by hand and it took forever. > e.g. pkg_delete some_package - oops, it depends on pkg_xxx, delete that, > oops, it depends on pkg_xxx2, and so on, when in reality that only > reason any of those additional packages were installed were for the > original package. I just go to /var/db/pkg and type 'pkg_delete kde*' a few times. After a while they all get deleted. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS, rl0 and Alpha
On Tue, 2 May 2000, Matthew Dillon wrote: > > :Is anyone else observing kernel panics in the NFS code with Alpha > :(pc164) and rl0 (the Alpha is running as a client only) ? > : > :NFS worked just fine when I had a de0 in the box. After installing an > :rl0 (I know they suck, but they're so cheap :) I _always_ get an > :unaligned access panic when I try to access an NFS mounted FS, in any > :way. > > This is almost certainly related to differences in how the > packet is aligned in memory between de0 and rl0. > > If you are getting panics, it is probably at the same > location every time. If you can get a kernel core dump > and backtrace I'll bet we can find and fix this problem > quickly. Bill put workarounds for the alpha's alignment restrictions into some of his drivers but it seems that he missed out rl. Basically the part of the packet which includes headers needs to have the start of the ip header aligned to a 4-byte boundary. Since the preceding ethernet header is not padded to 4 bytes, this often means copying the first part of the packet to another mbuf. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
On Thu, 27 Apr 2000, Jake Burkholder wrote: > ...snip... > > > > Its nice to see someone actually using kobj so soon. There is a possible > > performance problem though - kobj method calls are roughly 20% slower than > > direct function calls. Having said that, this isn't that slow - I timed a > > method call to a two argument function at ~40ns on a 300MHz PII. > > > > I could improve this for some applications (including this one) by > > providing a mechanism for an application to cache the function pointer > > returned by the method lookup. > > Yes, this sounds interesting. I can see that there are provisions for a > cache in the code, and I can see from the sysctls that hits and misses > are happening, but I can't see where the function pointers are entered > into the cache. Is this enabled by default? This is enabled by default. The address of the cache entry is passed as the second argument to kobj_lookup_method(). > > It also might be possible to have default implementations that do > "less than nothing", a special value could be entered in the cache that > indicates don't call through the function pointer at all. I don't know > how an inline cache lookup would compare to an empty function call, > but it might be a win when the locks are supposed to do nothing. Thats an interesting thought. It would add a compare and branch to the normal method dispatch case which might be too high a cost. > > Anyway, I've made a patch that uses Boris's suggestion of providing > functions with empty bodies. I worry about optimizing for the static UP > kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it > should just be a function call in all cases. > > http://io.yi.org/lock.diff > > I will send-pr it if no one has any comments. It looks quite reasonable to me. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remote serial gdb is broken in -CURRENT.
On Wed, 26 Apr 2000, Greg Lehey wrote: > On Tuesday, 25 April 2000 at 9:39:10 +0100, Doug Rabson wrote: > > On Tue, 25 Apr 2000, Greg Lehey wrote: > > > >> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > >>> On Sun, 23 Apr 2000, Greg Lehey wrote: > >>> > >>>> In the last few days, my remote serial gdb has almost completely > >>>> stopped working. Previously I had (almost) no trouble at 38400 bps; > >>>> now I can barely get a response at all at 9600 bps. Does anybody have > >>>> an idea where this could be coming from? > >>> > >>> I noticed this too but I have no idea why. I also had to move back to > >>> 9600. > >> > >> I've found the problem and fixed it. It's been broken all along, but > >> for some reason it got worse lately. > >> > >> Basically, what happened was that the getpacket function, which does > >> polled I/O, wasn't locking out interrupts, and something was > >> interrupting long enough for characters to get lost. Since sometimes > >> several consecutive characters got lost, it seems likely that either > >> something locks out interrupts for an inappropriately long time, or > >> the sio interrupt routines steal them. Anyway, it works nicely at > >> 115200 bps now. > > > > Great, thanks Greg. Debugging at 9600bps was getting painful :-) > > Even that didn't work for me. BTW, the fix had the side effect of > making the clock stand still. I've changed the code (spltty instead > of splhigh), and it seems to work OK now, so it probably was the tty > interrupt stealing characters. I'll commit when I'm sure all is still > OK. Cool. > > > On a nearly unrelated subject, can you try out the new stuff I just put > > into the kernel linker to allow it to export information to GDB. Now you > > should be able to use GDB's "sharedlibrary" command to load symbols. Make > > sure that the path used to load the file on the debugged machine is a > > valid path leading to the same file on the debugger machine. > > This looks like just what I'm looking for, especially if it can > extract kld symbols. How do I use it? Basically, all you do is load the module on the scratch box. Use an absolute path which also leads to the same file on the debugging box. Then break into GDB somehow and type "sharedlibrary". The debugger should print a message about each file which it finds and you can then use "info sharedlibrary" to see where they were loaded. All the symbols are loaded and relocated properly so you should be able to set breakpoints etc. as normal. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000, Jake Burkholder wrote: > > On Tue, 25 Apr 2000, Boris Popov wrote: > > > > > simple_lock* functions has breakage too. They defined as macros > > > for non-SMP case and as functions for SMP. > > > > This currently apparently affects the following modules: > > > > ccd > > cd9660 > > msdosfs > > nfs > > ntfs > > nwfs > > vinum > > > > All of these functions reference simple_lock() if it is not defined away. > > > > Bruce > > Has anyone thought about using kobj(9) for this? > > For example, it should be possible to make simple_lock and lockmgr locks > safe for use from modules by introducing a lock_if.h, which has > abstract version of all the lock routines. A class would be compiled > with null implementations for UP, or the 'lock'ed implementations for SMP. > The old functions would call through an instance of that class, automagically > finding the right method. Eventually this could be a runtime abstraction, > with both up and smp classes compiled into the kernel, and objects initialized > with the right method table at boot time. > > I have diffs in the works if anyone is interested. Its nice to see someone actually using kobj so soon. There is a possible performance problem though - kobj method calls are roughly 20% slower than direct function calls. Having said that, this isn't that slow - I timed a method call to a two argument function at ~40ns on a 300MHz PII. I could improve this for some applications (including this one) by providing a mechanism for an application to cache the function pointer returned by the method lookup. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remote serial gdb is broken in -CURRENT.
On Tue, 25 Apr 2000, Greg Lehey wrote: > On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > > On Sun, 23 Apr 2000, Greg Lehey wrote: > > > >> In the last few days, my remote serial gdb has almost completely > >> stopped working. Previously I had (almost) no trouble at 38400 bps; > >> now I can barely get a response at all at 9600 bps. Does anybody have > >> an idea where this could be coming from? > > > > I noticed this too but I have no idea why. I also had to move back to > > 9600. > > I've found the problem and fixed it. It's been broken all along, but > for some reason it got worse lately. > > Basically, what happened was that the getpacket function, which does > polled I/O, wasn't locking out interrupts, and something was > interrupting long enough for characters to get lost. Since sometimes > several consecutive characters got lost, it seems likely that either > something locks out interrupts for an inappropriately long time, or > the sio interrupt routines steal them. Anyway, it works nicely at > 115200 bps now. Great, thanks Greg. Debugging at 9600bps was getting painful :-) On a nearly unrelated subject, can you try out the new stuff I just put into the kernel linker to allow it to export information to GDB. Now you should be able to use GDB's "sharedlibrary" command to load symbols. Make sure that the path used to load the file on the debugged machine is a valid path leading to the same file on the debugger machine. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :I'm sure that something can be done for the kld compatibility issues
> :so that you can have your SMP cake and eat it too. Just give it a bit
> :more thought. :)
> :
> :- Jordan
>
> Thought I have. Time I don't. While I don't particularly see a
> problem staying compatible with KLD modules that do spl*() calls,
> It's several day's worth of additional work when we go through
> the whole review / test / test-again process. I've already gone
> through this process for what was committed to -current and I have
> already tested the patches under 4.x. I do not have time to go
> through it yet again due to having to make additional difficult-to-test
> changes.
>
> If this is an issue I suppose core can vote on whether the SMP
> cleanup should be MFC'd to 4.x. I've already laid out all the
> reasons why I think it's a good idea to do. I don't have the 40
> man-hours it will take to guarentee compatibility with existing kld's
> (even if most are probably already compatible) so if you make that
> a requirement, the result will be no MFC at all.
>
> So you guys (core) choose -- do you want 4.x to reap the benefits of
> further SMP development or not? If you choose no, beware that without
> this base cleanup there is *NO* chance whatsoever of any further SMP
> work being MFC'd to 4.x. None. Zilch. It will have diverged too
> much.
Personally (i.e. not speaking for core), I really want to preserve both
the API and ABI for as many kernel interfaces as possible in the 4.x
branch. This does restrict the kinds of work which can be done on 4.x but
I'm convinced that this will improve both the percieved ("I recompiled my
kernel and now it panics on boot - this sucks") and actual stability of
the system.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 20 8442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
On Sun, 23 Apr 2000, Matthew Dillon wrote: > There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. > > The SMP patchset, in fact, requires that all kernel modules be > recompiled due to the locks that were removed from the spl*() macros. > This is something I would contemplate doing for 4.0->4.1, but not > something I would consider for 4.1 onward. Even though 4.0 is the > most stable .0 release we've ever had, it's still a .0. > > I wonder if it makes sense to add a release id to the module header > and have the module loader refuse (unless forced) to load modules that > are out-of-date with the kernel? This sounds quite reasonable. Perhaps you should commit the linux patch to -current right now and then merge it on Wednesday. That would give plenty of time for any teething problems to show up. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remote serial gdb is broken in -CURRENT.
On Sun, 23 Apr 2000, Greg Lehey wrote: > In the last few days, my remote serial gdb has almost completely > stopped working. Previously I had (almost) no trouble at 38400 bps; > now I can barely get a response at all at 9600 bps. Does anybody have > an idea where this could be coming from? I noticed this too but I have no idea why. I also had to move back to 9600. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.ckern_prot.c kern_sig.c
On Thu, 6 Apr 2000, Matthew Dillon wrote:
>
> :The version of Linux kernel source that I have uses the first:
> :
> :asmlinkage long sys_getppid(void)
> :{
> : int pid;
> : struct task_struct * me = current;
> : struct task_struct * parent;
> :
> : parent = me->p_opptr;
> : for (;;) {
> : pid = parent->pid;
> :#if __SMP__
> :{
> : struct task_struct *old = parent;
> : mb();
> : parent = me->p_opptr;
> : if (old != parent)
> : continue;
> :}
> :#endif
> : break;
> : }
> : return pid;
> :}
> :
> :I like it. mb() is most certainly a "memory barrier" inline to
> :force ordering constraints. interesting how they don't use
> :volatile for the pointer though:
>
> mb() just prevents the compiler from optimizing access to the
> structural fields (otherwise it might move the accesses outside
> the for() loop and you would get an infinite loop. From the
> compiler's point of view, mb() is a subroutine call (I assume
> in the headers it's a volatile __asm).
>
> We can either use an mb() type of thing, or we can declare the structural
> field volatile, or we can cast the access to be volatile.
It also forces the cpu to drain writes and prevents reads from being
re-ordered before the mb(). This is mainly a hint for alpha processors but
I think it is relavent to other architectures.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
