Re: tcpdump(1) additions.
In article <[EMAIL PROTECTED]>, Matthew Hunt <[EMAIL PROTECTED]> wrote: > > I think the point is that when root is running tcpdump on host A, a bad > guy on host B can create a packet which makes tcpdump on A execute his > code (as root, since that's who's running it). This is not desirable. I would say it is not _acceptable_. The code shouldn't go into our source tree until the known buffer overflow problems have been fixed. It's just stupid to add buffer overflow problems to a program that is always run as root. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen returns non NULL
In article <[EMAIL PROTECTED]>, Max Khon <[EMAIL PROTECTED]> wrote: > > in the following code `dlopen' returns NULL > on the first iteration (because g() is not defined) -- it's ok > but on the second iteration `dlopen' returns "valid" dlh ELF or a.out? Which version of FreeBSD? For a.out, it's a known bug and there is already an open PR on it. I wouldn't be surprised if the bug existed in ELF too. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen returns non NULL
Max Khon wrote: >> For a.out, it's a known bug and there is already an open PR on it. >> I wouldn't be surprised if the bug existed in ELF too. > > 3.2-STABLE built on 10 Jun, ELF Thanks for the info. Could you please do a send-pr on this bug, and tell me the PR number? Then I'll assign myself as the resposible person. Please be sure to state that it's the ELF dynamic linker. If you're in a big hurry and would like to work on it yourself, the relevant code is in "src/libexec/rtld-elf/rtld.c" in the function dlopen() near the comment that says "XXX - Clean up properly after an error." :-) The fix may be as simple as calling unref_object_dag() from the failure cases there, but it will need careful checking. Some additional changes may be needed in load_needed_objects() near the comment that says "XXX - cleanup." :-) Thanks, John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Pictures from USENIX
I put a handful of pictures from this year's USENIX conference at <http://www.freebsd.org/~jdp/usenix1999/>. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Login.conf (Whose problem is this) ?
In article <[EMAIL PROTECTED]>, Gustavo V G C Rios <[EMAIL PROTECTED]> wrote: > i am trying to get a login classes for my users, so i decided to edit > /etc/login.conf. > > Among other, i have yma classes this way: > > > shell:\ > :maxproc=5:\ > :tc=auth-default: > > > Looking for auth-default, i saw the following: > > ## Authentication methods > ## Note that these are disabled by default, and libutil must > ## be rebuilt with LOGIN_CAP_AUTH defined to use them. This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any more. (It never was fully supported, actually.) Don't use it. > That's happened cause i turn on LOGIN_CAP_AUTH! > My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH? Yes, of course. That's what "with LOGIN_CAP_AUTH defined" means. But it's broken, so don't bother. If you want login classes all you need to do is "vipw" and insert the correct class in the class field. (See passwd(5) for details.) If you want to create a new class, just edit it into your login.conf file and then run cap_mkdb as instructed in the comment at the top of that file. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Login.conf (Whose problem is this) ?
Sheldon Hearn wrote: >> This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any >> more. (It never was fully supported, actually.) Don't use it. > > There's an open PR for this, PR 10115. I assume all that's required is > that we smack the outdated comments from login.conf? Yes, I think so. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
In article <[EMAIL PROTECTED]>, Archie Cobbs <[EMAIL PROTECTED]> wrote: > > A new, faster event notification system would be great. But don't forget > to include *all* events, not just file descriptor readability/writability. Yes! Yes! Yes! (I agree.) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
In article <[EMAIL PROTECTED]>, Brian F. Feldman <[EMAIL PROTECTED]> wrote: > On Sun, 4 Jul 1999, Archie Cobbs wrote: > > > A new, faster event notification system would be great. But don't forget > > to include *all* events, not just file descriptor readability/writability. > > I.e., signal delivery, child exit notification, maybe even support for > > an arbitrary number of (independent) timers. And make the events independent > > from each other -- to avoid problems like when an application completely > > hangs for 90 seconds when it calls gethostbyname(). > > An async thread to do hostname lookups would be great! Wouldn't be too > hard in libc_r, would it? The application itself has to get involved if it wants to do async name lookups, or async anything else, for that matter. Suppose you do have an async thread to do hostname lookups as you propose. What is the application going to do while that thread is waiting for the lookup to complete? It depends on the application, and thus it has to be coded into the application. Maybe there's nothing useful the application could do until the lookup returns. I've been told that it works fine to use libc_r and put the name lookups into a separate thread. But to take advantage of it, the application has to have something useful it wants to do (and can do) in the meantime. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic linking
In article <[EMAIL PROTECTED]>, Andrew Iltchenko <[EMAIL PROTECTED]> wrote: > Hi everyone! > > Is there a way of making dlopen return an error from the shared object's > _init function? No. The _init function by definition is "void _init(void)", and so it cannot return a value. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap question
In article <000101bec73c$e20e3660$[EMAIL PROTECTED]>, Kelly Yancey <[EMAIL PROTECTED]> wrote: > > Also, in case it hasn't been notice already (I'm running -stable from May > 18th), the mmap(2) manpage has a typo: it has "#include " So what's the typo, exactly? John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
Brian F. Feldman wrote: > On Tue, 6 Jul 1999, John Polstra wrote: > >> In article <[EMAIL PROTECTED]>, >> >> The application itself has to get involved if it wants to do async >> name lookups, or async anything else, for that matter. Suppose you >> do have an async thread to do hostname lookups as you propose. What >> is the application going to do while that thread is waiting for the >> lookup to complete? It depends on the application, and thus it has >> to be coded into the application. Maybe there's nothing useful the >> application could do until the lookup returns. >> >> I've been told that it works fine to use libc_r and put the name >> lookups into a separate thread. But to take advantage of it, the >> application has to have something useful it wants to do (and can do) >> in the meantime. > > It would let the other threads run more while the lookup is occurring. > Wouldn't that be the most natural expectation of it? Or would this > be too hard without kernel-assisted threading? What I'm saying is, we already have that in multi-threaded applications. The system can't just provide it automatically to single-threaded applications; they wouldn't know how to take advantage of it. In other words: * Multi-threaded applications already have it. * Single-threaded applications can't use it. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article <[EMAIL PROTECTED]>, Warner Losh <[EMAIL PROTECTED]> wrote: > > Some ftpd and sendmail servers make the queries. When I have my fake > identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. The only way a long timeout can occur is if you have a filter rule installed that drops the incoming packets without responding to them. You can block the incoming packets but still avoid the timeout with a filter rule that sends back a reset: add reset tcp from any to any auth setup in via etha16 John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Doug wrote: > John Polstra wrote: >> >> Are you sure? If you simply don't run an identd, the queries will >> get an instant connection refused error. That's even faster than >> sending back a bogus response. > > Many daemons that request ident, and almost all IRC daemons > that I'm aware of don't take "NO" for an answer. They sit waiting > for a valid response, and timeout after X seconds, where X is c. 30 > seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. > Whether this behavior is good or not begs the question, Agreed. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why 'dd' does not seek over 'char' devs (specifically raw disk
In article <[EMAIL PROTECTED]>, Brian F. Feldman <[EMAIL PROTECTED]> wrote: > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > couldn't we first try lseek and only do the reads on char devs where > > the lseek fails ? > > lseek() won't usually fail unless it's something like EBADF. It merely > sets the current fd's offset. It would be nice to be able to tell from > a device driver if it supports seeking (da) or not (sa). Hmm... actually, > if we just specify somehow that we support either direct or sequential > access... this would be possible. It would be a big improvement if dd could handle seeking on character disk devices. I'm reasonably certain there exists some ioctl (perhaps related to reading disk labels) which could be used to figure out whether a character device was a disk or not. A simple fix like that would make dd a lot more useful for the case Luigi brought up. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article <[EMAIL PROTECTED]>, Ian Dowse <[EMAIL PROTECTED]> wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > do a readlink(), which would be safer, neater and faster than reading a > file. A user can set up a fake ID with something like: > > ln -s "Warm-Fuzzy" .fakeid Ick. Please, no more abuse of symbolic links! Once (malloc) was enough. Data is held in files, not in filenames. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In article <[EMAIL PROTECTED]>, Brian F. Feldman <[EMAIL PROTECTED]> wrote: > [GNU getopt] > If you give me documentation on it, I'll implement it for the BSD libc. Note, we already have GNU getopt in the source tree in libiberty (in two different places -- binutils and gdb). It might be better just to install libiberty from one of those places. Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
Brian F. Feldman wrote: > On Mon, 19 Jul 1999, John Polstra wrote: > >> Left as an exercise for the reader: Figure out how the two differ >> and which one is "better". :-) > > I'd rather hurt myself severely. Of course. That's a prerequisite for becoming a committer. :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
In article <[EMAIL PROTECTED]>, Oscar Bonilla <[EMAIL PROTECTED]> wrote: > Couldn't we do this with /etc/auth.conf? The plan when PAM was brought in was to eliminate auth.conf. I don't think we should be looking for new uses for it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dl.h in stable causes sendmail segmentation
In article <[EMAIL PROTECTED]>, Reinier Bezuidenhout <[EMAIL PROTECTED]> wrote: > I have the following situation... ... [various userland SEGVs traced down to a change in if_dl.h] Just a guess: it sounds like the kind of thing that would happen if you updated your kernel without also rebuilding userland. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Oscar Bonilla wrote: > > ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf > and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf > for the info on where to obtain the databases from. That seems reasonable to me. PAM actually is designed to serve four separate but related functions. We're only using the authentication function currently. For an overview of PAM, see PAM(8) in the manual pages. There is also a spec in "src/contrib/libpam/doc/specs/rfc86.0.txt". John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: linking question...
In article <[EMAIL PROTECTED]>, David E. Cross <[EMAIL PROTECTED]> wrote: > > The problem indeed was conflicting libraries... (in /usr/X11R6/lib).. however > I did place on the line *immediately* before the -lwcs a -L/usr/local/lib, > however it appeared to take the /usr/X11R6/lib (which was in a previous -L > statement) version instead. Is this correct? Yes, it's correct. The -L options can appear anywhere relative to the -l options -- even after them -- and it doesn't make any difference. The relative ordering among the -L options with respect to *each other* is all ld cares about. That's been the traditional behavior on every Unix system I've ever used that supported -L at all. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
In article <[EMAIL PROTECTED]>, Dominic Mitchell <[EMAIL PROTECTED]> wrote: > On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: > > > > PAM is also "using masses of weird shared objects" but nevertheless it's > > quite usable > > By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed substitution for ACLs
In article <[EMAIL PROTECTED]>, Daniel C. Sobral <[EMAIL PROTECTED]> wrote: > > Do whatever you want: as a fs layer. That would be good advice, if FS layers worked. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
In article <[EMAIL PROTECTED]>, Peter Jeremy <[EMAIL PROTECTED]> wrote: > Assar Westerlund <[EMAIL PROTECTED]> wrote: > >Peter Jeremy <[EMAIL PROTECTED]> writes: > >> We need to be able to build an application that has no dynamically > >> loaded code for recovery purposes (/stand and /sbin) as well as for > >> security. > > > >Isn't that the same problem as with PAM? > > Quite probably PAM has the same problem. I haven't bumped into it > with PAM, so I can't be sure. When you're not sure, it's really best to find out or keep quiet on the mailing list. As it is, you've just created a dozen or so new people all over the world who will go around saying, "Hmm, I seem to remember reading that PAM doesn't work in statically-linked executables" -- which is false. It works fine. It is implemented using a linker set approach which you are encouraged to investigate in the sources. > the situation where init can fail to load (or be unable to validate > the single-user password for a secure console) because the appropriate > encryption library is on a partition that isn't mounted yet If that happened, it would have to be considered a severe design error. > (or has been corrupted somehow). Many things can get corrupted to make the system unrecoverable. For example: the kernel, init itself, entries in the /dev directory, and various combinations of cp, fsck, newfs, restore, ... > The idea of being able to dynamically add new password encrytion > schemes (PAM) or database access methods (NSS) is generally good. > The problems appear when you try to marry these schemes with the > system security and initialisation/recovery tools (which need to > rely on and trust a minimal subset of the system). Well, dynamic linking is here to stay, and that enlarges the scope of "minimal subset" somewhat. But nothing would be qualitatively different if we went to an all-dynamic scheme (which I hope we will do some day). In any case, your system has to be working to a certain degree to be recovered, or else you have to use external media such as the fixit disk. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
In article <[EMAIL PROTECTED]>, Mike Smith <[EMAIL PROTECTED]> wrote: > > I am working on some resource limit stuff and would like to be > > able to use login.conf to restrict the number of cgi processes that > > certain users can run. Unfortunately, the proprietary cgi product we use > > is owned by root and suid's to the user who owns the script that it is > > called to run. (This is not what I would call a "good idea," but it's what > > I have to work with.) [...] > You need to pester the vendor to correctly switch limits when they > switch UIDs. > > Alternatively, if this is unlikely _and_ the application is dynamically > linked, you could produce a library containing patched set*id functions > and force it into the app using LD_PRELOAD. N.B., LD_PRELOAD won't work if the program is setuid or setgid. I'm not 100% sure from the original post whether that's the case or not. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How the `struct linker_set' is used in building an ELF kernel?
In article <[EMAIL PROTECTED]>, Joe Jih-Shien Lu <[EMAIL PROTECTED]> wrote: > I started studying 3.2-stable kernel source for days. There are > some questions I cannot figure out in an ordinary C programmer's > point of view: > > * In cninit(), it references a global variable `cons_set' of > the type `struct linker_set,' but I don't see its definition > in any of the source files except the setdef0.c generated by > /usr/bin/gensetdefs. It is defined by the .long asm psuedo-op, > and seems to have the size of 4 bytes. However, in > /sys/i386/i386/cons.h, it is declared as of the type `struct > linker_set' which is 8-byte long. This inconsistency confused > me. > > * Similar problem is encountered when I'm poking around the > system initializing for-loop in main(). sysinit_set, declared > as struct linker_set, is referenced, but I can't get into the > way how this variable is initialized. > > I guess it is the linker who did all the magic, since the comment in > /sys/sys/linker_set.h mentioned about it. After studying the linker > script (/sys/i386/conf/kernel.script) and ld.info, though, I still > don't have any idea about the details behind the scene. Linker sets are basically arrays of pointers that are constructed by the linker using values that can come from many object files. The first word contains the number of elements (pointers) in the set. Then come the pointers themselves. Finally, a NULL pointer appears at the end of the set. The old a.out linker supported linker sets directly, and did all the bookkeeping necessary to keep track of the set sizes and so forth. The ELF linker does not directly support linker sets. However, it does support an arbitrary number of independent sections. Using that along with a little help from gensetdefs, we can get a.out-style linker sets using the ELF tools. setdef0.o must appear first on the linker command line. It contributes the leading count word to each set. Then come the "normal" object files, which may contribute pointers to various sets. These are just appended to special sections, one per linker set. Finally comes setdef1.o, which emits the terminating NULL pointers. > I notice that gensetdefs looks for the sections by the `.set.'-prefixed > name in all the ELF kernel object files, and produces the setdef[12].c > accordingly. Does the `.set.'-prefixed section name have any special > meaning in an ELF object file? No, it is just a convention we use for naming the sections that contain linker sets. gensetdefs knows this convention, and so do the macros in . The compiler, assembler, and linker aren't aware of anything special about the names. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
Peter Jeremy wrote: > I apologize if I gave anyone the impression that you couldn't build > statically linked executables with libpam. Sorry I was so prickly about it. > I recall having a similar static-vs-dynamic discussion with you a couple > of years ago. Yow, your memory is better than mine. Premature senility is a sad, sad thing. :-} > My position was (and still is) that for most purposes dynamic > linking is a definite advantage, but we should continue to permit > static linking for applications that want it (which Sun doesn't). I generally agree, except I feel that when there are cases where we can do useful things which rely on dynamic linking, we shouldn't let static linking hold us back. Plenty of people disagree with me, though. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
In article <[EMAIL PROTECTED]>, Brian F. Feldman <[EMAIL PROTECTED]> wrote: > > Mind pointing me to the technical reason why (I'm sure you've explained > it before) we can't use the dl* calls in any way without linking > against ld-elf.so.1? I mean, have them in libc, for instance... The versions in libc are just stubs. Take a look at "src/lib/libc/gen/dlfcn.c". The implementations are in the dynamic linker. > One option I don't think anyone's brought up: why don't we _just_ > have ld-elf.so.1 in the root, but not libraries? That way, we > don't bloat root excessively, but we can let people depend on > being able to build -static/-Bstatic binaries that make everything > static except the rtld? And modify gcc/ld to have static link with > the rtld, so we have the benefit of those calls, can have static > binaries still, and be able to depend on having an rtld (even for > single-user mode.) I think you have some misconceptions about how it all fits together. Executables aren't "linked with" the dynamic linker. It's a separate shared object that is loaded directly by the kernel. It gets control before the main executable gets control. Look at "src/sys/kern/imgact_elf.c" and at the dynamic linker. Also, programs that are linked (at "ld" time) with dynamic libraries are different from programs that are linked with static libraries. I.e., "ld" does very different things in the two cases. You can't take a statically-linked program and suddenly decide to treat it as dynamically-linked at runtime. It's too late at that point. Finally, shared "libraries" aren't really libraries at all in the traditional sense. They're monolithic whereas traditional archive libraries are made up of separate object files which are subsetted by the linker. To really understand the issues I think it's necessary to read through the dynamic linker sources and understand what it's doing. There used to be books that described how it all worked (Prentice-Hall "System V Application Binary Interface"), but as far as I know they're out of print now. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
In article <[EMAIL PROTECTED]>, Bill Fumerola <[EMAIL PROTECTED]> wrote: > On Sat, 7 Aug 1999, Mike Pritchard wrote: > > > *default umask=002 > > SetAttrs CVSROOT/commitlogs/other.981201.gz > > That seems to be doing the trick for everything. Thanks. Note, if you would have just _run_ the program with a umask of 2 then it would have worked too. It honors the umask setting unless overridden in the supfile. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In article <[EMAIL PROTECTED]>, Bernd Walter <[EMAIL PROTECTED]> wrote: > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > > > > But not on the Alpha... int64_t is a long there, and gcc complains unless > > you use %ld. > Mmm and long is 32Bit it seems. No, longs are 64 bits on the Alpha. Ints are 32 bits, though. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: prototypes with __P
In article <[EMAIL PROTECTED]>, Bill Fumerola <[EMAIL PROTECTED]> wrote: > On Fri, 6 Aug 1999, Matthew Hunt wrote: > > > I have no idea how much of the FreeBSD code would actually build on > > a K&R compiler. > > Thanks to Bruce, a lot of it. Note, the use of __P is discouraged in new code. From style(9): Only use the __P macro from the include file if the source file in general is (to be) compilable with a K&R Old testament compiler. Use of the __P macro in new code is discouraged, although modifications to existing files should be consistent with that file's conventions. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
Mike Pritchard wrote: >> >> Note, if you would have just _run_ the program with a umask of 2 >> then it would have worked too. It honors the umask setting unless >> overridden in the supfile. > > Yes, but if I ever run cvsup by hand I wind up with cvsup > going through my whole tree and resetting attributes because > my default umask isn't 2. I once started up a cvsup by hand, sat > down to eat/watch TV, came back and realized that cvsup had reset > all of my file permissions. That just shows that watching TV is _bad_. ;-) > Putting it in the cvsup file help to make sure you don't screw > yourself up by accident. Yep -- that's why I added the feature. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STAILQ macros..
In article <[EMAIL PROTECTED]>, Daniel O'Connor <[EMAIL PROTECTED]> wrote: > I am looking at the STAILQ macros defined in and I am > curious why it is necessary to declare stqh_last in the STAILQ_HEAD > as a pointer to pointer, rather than just a pointer? (like the head > pointer) When the list is empty, stqh_last points at stqh_first (which means it must be a pointer to pointer). That way, STAILQ_INSERT_TAIL doesn't have to treat an empty list as a special case. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Getting device and inode number from a vnode
I have two VFS-related questions which are probably pretty basic. 1. I have a pointer to a vnode and I want to get the corresponding dev_t and inode number. Is there a non-sleazy way to do that other than calling vn_stat? 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) says, "The file should not be locked on entry." But when stat calls vn_stat, the vnode is locked. Which is correct -- or doesn't it matter? Thanks, John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting device and inode number from a vnode
Alfred Perlstein wrote: > On Sun, 15 Aug 1999, John Polstra wrote: >> >> 1. I have a pointer to a vnode and I want to get the corresponding >> dev_t and inode number. Is there a non-sleazy way to do that other >> than calling vn_stat? > > use vn_todev from "vfs_subr.c" ~line 2970 of 2976 if you just > need the dev_t. Thanks. I didn't make it clear in my question, but I want the dev_t of the filesystem containing the file (st_dev rather than st_rdev). > but you may wind up needing the GETATTR call for the inode lookup. OK. >> 2. The first action of vn_stat is to call VOP_GETATTR. VOP_GETATTR(9) >> says, "The file should not be locked on entry." But when stat calls >> vn_stat, the vnode is locked. Which is correct -- or doesn't it >> matter? > > the lookup at the begininngin of the stat() call's side-effect is to > lock the vnode it returns but kern/vnode.src seems to indicate > that the vnode's locking state doesn't matter... Ah, good. That helps. > so does the various states that vnodes are in when called from > vfs_syscalls, such as the lseek syscall. Yes, and fstat doesn't lock it either. > it's slighly confusing, if the vnode is locked for "access" calls > why is it not locked for attribute calls? I'm confused too. :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildfailure -current on Alpha?
In article <[EMAIL PROTECTED]>, Kenneth D. Merry <[EMAIL PROTECTED]> wrote: > > I take it you haven't rebuilt world in the past few months? There was a > change that went in in June, I think, that requires that you reinstall > ld-elf.so.1 manually before you can buildworld on an Alpha. Kinda > annoying, I think. Annoying but unavoidable. There's no way to override the location of the dynamic linker at make world time, for security-related reasons. An important bugfix to the Alpha binutils required an updated dynamic linker to handle the new relocation type. The new dynamic linker was committed well before the binutils changes that required it. But still it can bite people who aren't tracking -current very closely. That's life in currentland. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netscape Bus Error
In article <[EMAIL PROTECTED]>, Darren R. Davis <[EMAIL PROTECTED]> wrote: > I believe that a Bus Error is specifically referencing miss aligned > data vs segmentation violation (SIGSEGV) which is accessing data > that is either free'd or not yours, etc. That was the traditional distinction, but it's different on FreeBSD/i386. SIGSEGV means you accessed memory that is unmapped. SIGBUS means you accessed memory that is mapped, but protected (unwritable and/or unreadable). To further confuse matters, FreeBSD/alpha generates SIGSEGV for both cases. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
In article <[EMAIL PROTECTED]>, Darryl Okahata <[EMAIL PROTECTED]> wrote: > > There's the problem. While I agree with you about persistent, > annoying, and utterly clueless newbies, I don't agree with the apparent > sentiment (with which you may or may not agree) where all newbies (and > not just in -hackers) should be flamed and roasted. I've seen perfectly > innocent questions (asked once), from non-persistent/non-annoying > newbies, get flamed in -questions. Darryl is right, folks. Please either be nice or keep quiet. I swear I've seen more unjustified crabby answers in our mailing lists during the past month than at any other time during my involvement with the project. A few of you -- and you know who you are -- seem to make a point of writing something utterly rude every day. If you are so stressed out that you can't help it, then please just take a break from the lists entirely for a couple of weeks. You're not doing a thing to help our reputation. Remember, the _individual_ you are replying to is not personally responsible for the sum total of annoyances you have endured lately. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD CVS mirror
In article <[EMAIL PROTECTED]>, Sameh Ghane <[EMAIL PROTECTED]> wrote: > On Tue, Oct 12, 1999 at 04:36:39PM +0700, Max Khon wrote: > > hi, there! > > > > maybe i'm posting into wrong list, but how is FreeBSD > > CVS repository mirrored? > > We probably will have an opportunity to set up local FreeBSD mirror here > > (we do not have space for full mirror but some parts, including > > CVS repository is desired) > > For the set up of mirrors, send your request to: [EMAIL PROTECTED] That mailing list doesn't exist any more. For CVSup mirrors, send the request to [EMAIL PROTECTED] or [EMAIL PROTECTED] John Polstra CVSup Mirrormeister -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Search a symbol in the source tree
In article <[EMAIL PROTECTED]>, W Gerald Hicks <[EMAIL PROTECTED]> wrote: > I find it ironic that nobody has suggested global yet; > > That sure would make a nice port, especially since we could > easily recommend gozilla as a nice way to browse and search > the source tree. Er, global is part of the base system. :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: paper on fine-grained OS timers
In article <[EMAIL PROTECTED]>, Mohit Aron <[EMAIL PROTECTED]> wrote: > I'd like to tell the BSD community about my paper entitled > "Soft timers: efficient microsecond software timer support for network > processing" that's going to appear in SOSP 1999. The abstract for the paper > is attached below. The gzip'd postcript for the paper can be downloaded from: >http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz This looks like it would be a nice solution to a known problem with dummynet. From dummynet(4): dummynet performs its task once per timer tick. The granularity of operation is thus controlled by the kernel option options HZ whose default value (100) means a granularity of 10ms. For an accurate simulation of high data rates it might be necessary to reduce the timer granularity to 1ms or less. Consider, however, that some interfaces using programmed I/O may require a considerable time to output packets. So, re- ducing the granularity too much might actually cause ticks to be missed thus reducing the accuracy of operation. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSDCon pictures
I put a few pictures from FreeBSDCon here for your enjoyment: http://www.freebsd.org/~jdp/freebsdcon1999/ John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvsup not being updated?
In article <[EMAIL PROTECTED]>, Julian Elischer <[EMAIL PROTECTED]> wrote: > I checked in stuff about 3 hours ago but it's still not showing up on > either of cvsup2 or svsup3 > > anything funny going on? Yes, freefall was screwed up again. Something has been causing its amd to hang occasionally, and that hoses the updates to cvsup-master. I intend to add a monitoring process to raise the alarm sooner, but FreeBSDCon week wasn't a likely time for that to happen. To everybody: when you think something is wrong with our mirror system as a whole, please tell me, <[EMAIL PROTECTED]>. Writing to a list like -hackers generally won't cut it. You need to let me personally know as soon as possible. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
In article <[EMAIL PROTECTED]>, Andrew Gallatin <[EMAIL PROTECTED]> wrote: > I have an older AlphaStation 600 5/266 running -current (cvsupped > last week) which is setup as a router between 2 100mb networks. > When the machine is pushed fairly hard (like running a netperf > -tUDP_STREAM -- -m 100 across the router, eg about 10-20k 100byte > packets/sec ) the alpha falls over almost instantly. I have not > enabled any NAT or firewall functionality, just ip forwarding. > > It generally crashes in MCLGET down in the ethernet driver's > receiver interrupt handler. I'm probably way off the mark, but I have to ask. Are you sure you're not simply running out of mbufs? I noticed your maxusers is only 32 and I didn't see an options line to raise NMBCLUSTERS. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RTLD_GLOBAL/RTLD_LOCAL dlopen mode flags
In article <[EMAIL PROTECTED]>, Max Khon <[EMAIL PROTECTED]> wrote: > Are there any plans to implement RTLD_GLOBAL/RTLD_LOCAL mode flags for > dlopen? RTLD_GLOBAL has been supported in -current since around the beginning of September. What is RTLD_LOCAL, and which OS supports it? I've never heard of that one. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gas pseudo-ops
In article <[EMAIL PROTECTED]>, Stephane E. Potvin <[EMAIL PROTECTED]> wrote: > Does anyone have any idea where I could find some documentation about > the following gas pseudo-ops? > .type ,@object There is a type associated with symbol in the object files. It can be function (obvious), object (data), or other/unknown. This pseudo-op sets the type of a given symbol. > .previous The assembler maintains a stack of sections. Each time you change to a new section, it pushes the previous one onto the stack. The ".previous" pseudo-op pops the stack and changes back to the previous section. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio Functions
In article <[EMAIL PROTECTED]>, Christopher Sedore <[EMAIL PROTECTED]> wrote: > > I've got a set of patches that fix this and the fact that signals don't > get issued for completion on certain types of requests. I'm hoping to get > it committed, but feel free to contact me for the latest stuff until then. > I just finished updating and consolidating my patches so they cleanly > apply to -current of a week ago. Testing thus far appears promising--I'm > balancing more than a few sockets and pushing 10MB/sec through them (disk > to socket and the inverse). I killed the last bug I knew of this week > (occasionally paniced under some wierd process shutdown conditions). > > I hope to try 1000 descriptors soon. That's great news! So have you gotten rid of some of these absurdly low fixed limits? vfs.aio.max_aio_per_proc: 32 vfs.aio.max_aio_queue_per_proc: 256 vfs.aio.max_aio_procs: 32 vfs.aio.max_aio_queue: 1024 vfs.aio.max_buf_aio: 16 And worst of all: #define AIO_LISTIO_MAX 16 John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing symbols in LIBC ???
In article <[EMAIL PROTECTED]>, Nils M Holm <[EMAIL PROTECTED]> wrote: > > Hello! > > I am currently porting my compiler to the release 3.3. My RT lib depends > on /usr/lib/libc.a. When attempting to link a program, I get messages about > unresolved externals (it DOES work on release 2.x). > > I have seen that the C compiler no longer generates underscores on > symbols by default and consequently, '_printf' in /usr/lib/libc.a has > become simply 'printf'. There seem to exist kind of 'compatibility > entries' for some functions, though. > > However, (at least) the symbols _creat, _lseek, and _memmove are not > defined in /usr/lib/libc.a. (creat, lseek, and memove are defined.) > > Is this a bug or a feature? Will underscores vanish totally in the > future? Do I have to create a workaround for the 3.x branch?? Yes, the underscores are gone permanently because we switched from a.out to ELF as the object file format. You can test for it at compile time with #ifdef __ELF__. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gas pseudo-ops
In article <01bf260d$837c8770$[EMAIL PROTECTED]>, Stephane Potvin <[EMAIL PROTECTED]> wrote: > > Do you think it would be possible to change the > .type ,@object > for > .type ,object > in gensetdef? By looking in the gas code I found that the assembler just > ignores the @ character. I think it would be much better to remove all of the platform-specific asm statements from gensetdefs and put them into a header . Gensetdefs would then emit an include of that header to get the needed definitions. This isn't very high on my personal priority list, though. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
In article <[EMAIL PROTECTED]>, Robert Watson <[EMAIL PROTECTED]> wrote: > On Mon, 15 Nov 1999, Wes Peters wrote: > > > On a single system, if st_dev and st_ino are equal, you must be > > referring to the same object. If not, I'd like to hear about it. > > This assumption has always caused lots of pain and suffering for > distributed file system people -- in a distributed file system, the > requirement that you can generate a unique 32 bit number for each > file or directory visible in the FS is a fairly arduous one. I don't dispute that point, but it is worth mentioning that POSIX specifically guarantees that st_dev and st_ino "taken together uniquely identify the file within the system." So it is OK for applications to rely on that. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
Garance A Drosihn wrote: > At 10:40 AM -0800 11/18/99, John Polstra wrote: >>I don't dispute that point, but it is worth mentioning that POSIX >>specifically guarantees that st_dev and st_ino "taken together >>uniquely identify the file within the system." So it is OK for >>applications to rely on that. > > Given how many people have files mounted from foreign file systems, > I would think that applications should not rely on that. Sure, it's > a nice guarantee for a completely stand-alone system, but a "general > purpose" application should consider that it may be dealing with > files in NFS, AFS, or some other file system, and plan accordingly. We must be interpreting the requirement differently, because it doesn't seem onerous at all to me. The st_dev value needn't be the same on two different hosts which both mount the same filesystem. I also doubt that the requirement has to hold across remounts. Under that interpretation, it's simple to meet the requirement. Just create a locally-unique st_dev value whenever you mount a filesystem, and if the filesystem is remote then record a mapping between (remote hostname, remote host's idea of the "device") and the local st_dev value. (I've never used AFS, so I may be missing something crucial here.) > If the program is only for you in your organization, then the > POSIX promise is helpful. If you're sending the code off to "the > world", then you should not rely on that posix promise. Just my own > opinion, of course. Well, the POSIX requirement isn't optional. If a system doesn't meet it then it is not POSIX-compliant. So any application that is targeted toward POSIX systems is perfectly within its rights to rely on the requirement. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In article <[EMAIL PROTECTED]>, Daniel C. Sobral <[EMAIL PROTECTED]> wrote: > "Ronald F. Guilmette" wrote: > > > As I say, my understanding is that FreeBSD still doesn't have real > > and/or complete thread support in the kernel. So if you have a > > multi-threaded application and one thread blocks (e.g. on I/O) > > then the whole thing is blocked. [...] > Not to dismiss FreeBSD's kernel problems, but that thing about > blocking is absurdly untrue. It is in fact partially true. If a thread blocks on disk I/O then the whole process (all threads) blocks. That can be significant for applications that are disk intensive. I believe it to be the most significant bottleneck in current versions of CVSup, for example. (CVSup doesn't use FreeBSD's threads library, but it uses Modula-3's built-in threads package which is similar in design.) Once our aio support is knocked into shape, it should be possible for userland threads packages to use that in preference to select(). Then threads could run while one or more others were blocked on disk I/O. Of course kernel thread support may improve soon enough so that this approach isn't necessary. For CVSup I plan to experiment with using a small farm of disk I/O subprocesses (processes, not threads), communicating with the master process via shared memory and/or pipes. Without trying it, I can't say for sure whether it will yield a net win or a net loss in speed. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In article <[EMAIL PROTECTED]>, Ronald F. Guilmette <[EMAIL PROTECTED]> wrote: > > Is there code somewhere, perhaps within the libc implementation of read(2) > that looks to see what kind of device I am reading from, and then does two > different things if the read is for a disk file versus a read for a terminal? No. It's simply that the read() and write() system calls are willing to return EAGAIN or only do a portion of the requested I/O for pipes and sockets and terminals, but they are not willing to do that for disk I/O. There is a long-standing distinction in Unix between "slow" I/O devices and "fast" ones. Disks are "fast" ones, and the process always blocks until the full I/O has completed. This is not some kind of brokenness particular to FreeBSD; it's the way Unix has always behaved. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In article <[EMAIL PROTECTED]>, Ronald F. Guilmette <[EMAIL PROTECTED]> wrote: > > The other way is just have your server be a single thread/process, and to > have it keep one big list of all of the connections (i.e. socket fds) that > it has open at present. Then it just executes mail loop, over and over > again. At the top of the main look is one big honkin' call to select() > in which you find out which of your connections is ready to be read or > written. Then you go off and read/write those as appropriate, and then > just come back and do the big select() again. (You could do this using > calls to poll() instead of calls to select(), and that might be a bit > more efficient.) > > The only real problem with doing things this way is that you have to diddle > some things to make sure the bit arrays that you pass to select() are big > enough to handle the maximum number of connections you ever anticipate > having to service/maintain at one time. [... etc] The "eventlib" package is pretty nice for this style of programming. It takes care of all these gory details for you. It's part of BIND (www.isc.org) and it might be distributed separately too -- I forget. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: YES: it works..
In article <[EMAIL PROTECTED]>, Wilko Bulte <[EMAIL PROTECTED]> wrote: > Fri Dec 31 23:59:56 CET 1999 > Fri Dec 31 23:59:57 CET 1999 > Fri Dec 31 23:59:58 CET 1999 > Fri Dec 31 23:59:59 CET 1999 > Sat Jan 1 00:00:00 CET 1900 > Sat Jan 1 00:00:01 CET 1900 > Sat Jan 1 00:00:02 CET 1900 > Sat Jan 1 00:00:03 CET 1900 > > In short: yes it works. > > Happy New Millenium to all of you! Huh? That doesn't look so good to me! (Just kidding, just kidding. ;-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
In article <1a6101bf5bc1$4e364b20$[EMAIL PROTECTED]>, Scott Hess <[EMAIL PROTECTED]> wrote: > > I've implemented a rough fix, which is to rfork() processes which I label > "iothreads" to handle the disk I/O. The parent process running pthreads > has a socketpair() to each of the iothreads. The iothreads wait for > requests on the socketpair, and since socketpairs can block, pthreads can > handle them efficiently. ... > Unfortunately, I'm concerned about using this code in production, because > it needs a fair amount of cleanup to handle signals and administrative > functions correctly. For this reason and others, I'm starting a project to > move it into the pthreads library itself. Before I embark on that effort, > I have a couple questions: > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > it tastes strongly of hack.] I think the approach is reasonable, but it shouldn't go into the pthreads library. It's too heavyweight for that -- too much machinery when your average client just wants to read from a file. Pthreads will eventually handle disk I/O better than it does now, using aio calls or some other technique. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LD_PRELOAD
In article <[EMAIL PROTECTED]>,
Tony Finch <[EMAIL PROTECTED]> wrote:
> I'm experimenting with using LD_PRELOAD to implement "shim" wrappers
> around functions in libc. It's really easy to do on Solaris but I'm
> having some difficulty on FreeBSD.
>
> The first problem I had was compiling my shim library so that the rtld
> would accept it.
The right way to do it on FreeBSD is like this:
gcc -fpic -c *.c
gcc -shared -o libshim.so *.o
> This brings me on to the second problem. I want to do some
> initialization of my library before the real action starts. On Solaris
> the linker calls a function in the object called _init() when it is
> loaded; it's easy to make this work. I can see similar functionality
> in FreeBSD's rtld but it looks like I have to jump through obscure
> hoops to make it work (an ELF DT_INIT section if I understand it
> correctly).
The names "_init" and "_fini" are "reserved for the implementation"
in ANSI/ISO-speak. You shouldn't use them. You can get what you
want like this with gcc:
void myInitFunction(void) __attribute__ ((constructor));
void
myInitFunction(void)
{
/* Your initialization code here. */
}
Or, write it in C++ and use a global constructor.
> code like
> if (!initialized)
> init_me_baby();
> at the start of entry-point functions. This seems grotty and
> inefficient to me and I'd like to avoid it if possible.
Fine, but then you're venturing into areas not covered by the relevant
standards. That will make your code less portable.
> I also note a user-interface incompatibility between FreeBSD's
> implementation of LD_PRELOAD and Solaris's: on Solaris the filenames
> listed in LD_PRELOAD are space-separated, but on FreeBSD they are
> colon or semicolon separated.
That could be a bug. You're probably the first person on earth to
have more than one library in LD_PRELOAD. :-) What does Linux do?
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: LD_PRELOAD
In article <[EMAIL PROTECTED]>, Tony Finch <[EMAIL PROTECTED]> wrote: > John Polstra <[EMAIL PROTECTED]> wrote: > >The right way to do it on FreeBSD is like this: > >gcc -fpic -c *.c > >gcc -shared -o libshim.so *.o > > That works fine, thanks! Any idea why my clumsy success worked and why > my clumsy failures didn't? Nah, I didn't pay that much attention to what you did. I just noticed that it wasn't right. :-) The "gcc -fpic" makes the object code position-independent. I am not sure, but probably you would also benefit (performance-wise) by using that on Solaris. The "gcc -shared" turns it into a shared library instead of a normal object file. In the process it also links in some extra little .o files which are necessary to hold it all together. You can use "gcc -v" to get the gory details. > >The names "_init" and "_fini" are "reserved for the implementation" > >in ANSI/ISO-speak. You shouldn't use them. > > I don't have any choice on Solaris, unfortunately (and my code has to > be portable between FreeBSD and Solaris). I suppose in that case > Solaris is the implementation and they have reserved it for my use. I > gather from the linker errors that FreeBSD has reserved the names for > a different use? The machinery that supports C++ constructors uses them. > >Or, write it in C++ and use a global constructor. > > No. Never. No way. NO. :-) I didn't mean write everything in C++ -- just the initialization hook. It's not that bad. There's an example in "src/lib/libc_r/uthread/uthread_autoinit.cc". The advantage of using C++ for this is that you're using a portable mechanism instead of a gcc extension. > >> I also note a user-interface incompatibility between FreeBSD's > >> implementation of LD_PRELOAD and Solaris's: on Solaris the filenames > >> listed in LD_PRELOAD are space-separated, but on FreeBSD they are > >> colon or semicolon separated. > > > >That could be a bug. You're probably the first person on earth to > >have more than one library in LD_PRELOAD. :-) What does Linux do? > > According to the documentation I looked at it uses arbitrary > whitespace as the separator. I haven't looked at the code to check. I took a look. They accept white space or colons. I'll change ours to be similarly tolerant. The semicolons are a vestige from SVR4.0, and should probably be ditched. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: java -> ld-elf.so.1: assert failed: ... lockdflt.c:55
In article <[EMAIL PROTECTED]>, Chad David <[EMAIL PROTECTED]> wrote: > > Since the ~Jan 25 I have been getting an error while > running any java programs on 3.4-stable. I cvsup'd,and > ran a make world this afternoon and it still fails. It doesn't > always hit... about 50% of the time. > > The errors is: > > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 [...] > FreeBSD stronghold.guild.ab.ca 3.4-STABLE FreeBSD 3.4-STABLE #0: Thu Jan > 27 17:04:43 MST 2000 I believe I fixed this one in -current 3 days ago, but I haven't merged it into -stable yet. I would appreciate it if you would try the patch below and let me know whether it clears up the problem for you. John Index: lockdflt.c === RCS file: /home/ncvs/src/libexec/rtld-elf/lockdflt.c,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 lockdflt.c --- lockdflt.c 2000/01/21 02:31:50 1.3.2.1 +++ lockdflt.c 2000/01/28 18:25:01 @@ -28,10 +28,9 @@ /* * Default thread locking implementation for the dynamic linker. It * is used until the client registers a different implementation with - * dllockinit(). The default implementation does mutual exclusion - * by blocking the SIGVTALRM, SIGPROF, and SIGALRM signals. This is - * based on the observation that most userland thread packages use one - * of these signals to support preemption. + * dllockinit(). The default implementation does mutual exclusion by + * blocking almost all signals. This is based on the observation that + * most userland thread packages use signals to support preemption. */ #include @@ -63,10 +62,13 @@ l = NEW(LockDflt); l->depth = 0; -sigemptyset(&l->lock_mask); -sigaddset(&l->lock_mask, SIGVTALRM); -sigaddset(&l->lock_mask, SIGPROF); -sigaddset(&l->lock_mask, SIGALRM); +sigfillset(&l->lock_mask); +sigdelset(&l->lock_mask, SIGTRAP); +sigdelset(&l->lock_mask, SIGABRT); +sigdelset(&l->lock_mask, SIGBUS); +sigdelset(&l->lock_mask, SIGSEGV); +sigdelset(&l->lock_mask, SIGKILL); +sigdelset(&l->lock_mask, SIGSTOP); return l; } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: java -> ld-elf.so.1: assert failed: ... lockdflt.c:55
In article <[EMAIL PROTECTED]>, Chad David <[EMAIL PROTECTED]> wrote: > > Yes this fixed it. Thanks. Thanks for testing it. I have merged the fix into -stable now. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
In article <[EMAIL PROTECTED]>, Chuck Robey <[EMAIL PROTECTED]> wrote: > The modula-3 port is about the same size as yours, and it > bootstraps, but (like you said) it does it from C. Actually, the standard Modula-3 bootstraps contain assembly-language sources generated by a cross-compiler, not C. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to compile without libc (so not static)
In article <[EMAIL PROTECTED]>,
Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> I finished the syscalls, so now I moved on the initialisation code.
>
> To test that I try to create an empty binary, which doesn't link to libc:
>
> I've put in an hour effort, and wrote the following C file:
>
> int main (void) {
> return 0;
> }
>
> gcc -nostdlib empty.c /usr/lib/crti.o /usr/lib/crt0.o -o empty
>
> results in:
>
> /usr/lib/crt1.o: In function `_start':
> /usr/lib/crt1.o(.text+0x4f): undefined reference to `atexit'
> /usr/lib/crt1.o(.text+0x5c): undefined reference to `atexit'
> /usr/lib/crt1.o(.text+0x6f): undefined reference to `exit'
I suspect that "gcc" isn't the standard FreeBSD C compiler in your
case. Try "which gcc" and find out. It works fine for me on both
-stable and -current with "cc":
blake$ cc -v -nostdlib hello.c
Using builtin specs.
gcc version 2.95.2 19991024 (release)
/usr/libexec/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -Dunix
-D__FreeBSD__=4 -D__FreeBSD_cc_version=44 -D__i386__ -D__unix__ -D__FreeBSD__=4
-D__FreeBSD_cc_version=44 -D__i386 -D__unix -Acpu(i386) -Amachine(i386)
-Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -Di386 -D__i386
-D__i386__ -D__ELF__ hello.c /tmp/cciRD216.i
GNU CPP version 2.95.2 19991024 (release) (i386 FreeBSD/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/include/g++
End of omitted list.
/usr/libexec/cc1 /tmp/cciRD216.i -quiet -dumpbase hello.c -version -o /tmp/ccbyU216.s
GNU C version 2.95.2 19991024 (release) (i386-unknown-freebsd) compiled by GNU C
version 2.95.2 19991024 (release).
/usr/libexec/elf/as -v -o /tmp/ccWvs216.o /tmp/ccbyU216.s
GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1
/usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1
-L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/ccWvs216.o
/usr/libexec/elf/ld: warning: cannot find entry symbol _start; defaulting to 08048074
/tmp/ccWvs216.o: In function `main':
/tmp/ccWvs216.o(.text+0xf): undefined reference to `printf'
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to compile without libc (so not static)
In article <[EMAIL PROTECTED]>, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > I suspect that "gcc" isn't the standard FreeBSD C compiler in your > > case. Try "which gcc" and find out. It works fine for me on both > > -stable and -current with "cc": > > It is an older one indeed. [...] > Still doesn't work though with the newer one :-) > (try some arithmetic to see if that works. What do you mean, "Still doesn't work"? If you are using the /usr/bin/cc that comes with FreeBSD, and if -nostdlib causes the crt* files and libc to be omitted from the link, then it works. Making it do something useful is _your_ problem, not ours. :-) We don't recommend or support linking that way. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In article <[EMAIL PROTECTED]>,
W Gerald Hicks <[EMAIL PROTECTED]> wrote:
>
> Convince me that nothing like the following exists in the
> ports framework and /usr/src and I'd be ok with a change
> *after* 4.0 release (repeats himself)
>
> # Makefile.foo
>
> FOOVAR=
>
> .
> .
> .
>
> BARVAR=${FOOVAR}
>
> baz:
> for i in ${BARVAR} ; do \
>${BLAP} $$i ; \
> done
>
>
> To me, changing it right now on the eve of -release
> would be gratuitous. Later I would be fine with it.
I agree that this is not the time to change it. But in the long run,
if the ports framework is misusing /bin/sh then the framework needs to
be fixed. We shouldn't let bugs there influence what we do with the
shell.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
In article <[EMAIL PROTECTED]>, Archie Cobbs <[EMAIL PROTECTED]> wrote: > I already have code for MPPC/MPPE, minus the proprietary STAC > code and the patented RC4 algorithm, I have read in several places that only the name "RC4" is trademarked, and that the algorithm itself is not patented. Is that not the case? John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Keeping using locally modified source
In article <[EMAIL PROTECTED]>, Bill Fenner <[EMAIL PROTECTED]> wrote: > > I've got this program in my head that takes a CVS tree and turns it > into a branch ofanother CVS tree (e.g. FreeBSD rev 1.7 turns into > rev 1.1.1.7) but it's never managed to make it out of my head, so > it must be harder than I keep thinking it is =) I've had the same idea for CVSup for quite awhile but haven't gotten around to implementing it. It would be a new "import mode" where the updates you fetched were "imported" onto the vendor branch of your local repository. It would be great for maintaining local modifications. I've been thinking about it for a long time and haven't found a reason yet why it wouldn't work. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In article <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> wrote: > > Given that Bash in both standard and POSIX mode complains about 'for i > in ; do echo $i; done', I would say that it's not POSIX compatible. What > could/does depend on this behavior "working?" It works for the realistic cases that might actually be useful. E.g.,: x= for i in $x; do echo $i done works fine. I don't think it matters very much that the pathological case "for i in ; ..." doesn't work. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
Doug Barton wrote: > > Agreed on all counts. By "this behavior" I was referring to the > example. Yep -- I was agreeing with you. :-) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lazy binding
In article <[EMAIL PROTECTED]>, Arun Sharma <[EMAIL PROTECTED]> wrote: > Is there a strong reason why FreeBSD rtld uses lazy binding by default ? 1. Faster start-up times for programs. 2. Better interversion library compatibility. It doesn't matter if a function is missing from a library, as long as the program never calls it at runtime. 3. It's what everybody else has always done by default. I.e., it's what users expect. > In a multithreaded environment, this could make things pretty complex. > What if a thread holds locks and fails at runtime due to a missing > symbol ? *shrug* The same thing that happens if a thread holds locks and fails for any other reason. > Also, is there a significant performance benefit to doing lazy binding ? Start-up time is faster. Overall runtime might be faster or slower, depending on the ratio of called functions to total functions. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: need to borrow a clue re: rtld
In article <[EMAIL PROTECTED]>, Jacques A . Vidrine <[EMAIL PROTECTED]> wrote: > Messing about with Dante (the SOCKS5 replacement), I've encountered > some difficulty with run-time linking that I don't understand. > > In brief: > > $ env LD_PRELOAD=libdsocks.so telnet # works > $ env LD_PRELOAD=libdsocks.so xchat # undefined symbol '_gethostbyname' > $ env LD_PRELOAD=libc.so:libdsocks.so xchat # works Which version of FreeBSD? If you have time, please rebuild "src/libexec/rtld-elf" with DEBUG_FLAGS=-DDEBUG. Make a copy of your existing "/usr/libexec/ld-elf.so.1" and then install the debugging version. Run your first test case like this: script Log.1 env LD_DEBUG=1 LD_PRELOAD=libdsocks.so telnet (exit telnet and get out of "script") and likewise for the failing test case (with a different filename for script, of course). Send the output to me and I'll try to figure out what's happening. After you're done, you should restore your original (non-debugging) rtld. It's more efficient and also probably more secure. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen failure
In article <373c3f3f.a99db...@cablenet.net>, Damian Hamill wrote: > I have a program that is dumping core. > > --- > Here's the gdb output; > > Program terminated with signal 6, Abort trap. > #0 0x800b728 in _kill () > (gdb) bt > #0 0x800b728 in _kill () > #1 0x800b34c in abort () > #2 0x8004aa2 in __assert () > #3 0x8003b4b in map_object () > #4 0x8002e9e in find_symdef () > #5 0x800334d in dlopen () > #6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 "mysql") at Vdb.c:150 > #7 0x8049ff9 in GetDefaultDriver () at Vdb.c:254 > #8 0x804a141 in VdbInit (user=0x804bfb1 "nobody", passwd=0x0) at > Vdb.c:329 > #9 0x8049316 in main () > #10 0x8048be5 in _start () I don't know what's going on here, but this stack trace can't be right. dlopen doesn't call find_symdef, and find_symdef doesn't call map_object. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen failure
Doug Rabson wrote: > On Thu, 20 May 1999, John Polstra wrote: > >> In article <373c3f3f.a99db...@cablenet.net>, >> Damian Hamill wrote: >> > I have a program that is dumping core. >> > >> > --- >> > Here's the gdb output; >> > >> > Program terminated with signal 6, Abort trap. >> > #0 0x800b728 in _kill () >> > (gdb) bt >> > #0 0x800b728 in _kill () >> > #1 0x800b34c in abort () >> > #2 0x8004aa2 in __assert () >> > #3 0x8003b4b in map_object () >> > #4 0x8002e9e in find_symdef () >> > #5 0x800334d in dlopen () >> > #6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 "mysql") at Vdb.c:150 >> > #7 0x8049ff9 in GetDefaultDriver () at Vdb.c:254 >> > #8 0x804a141 in VdbInit (user=0x804bfb1 "nobody", passwd=0x0) at >> > Vdb.c:329 >> > #9 0x8049316 in main () >> > #10 0x8048be5 in _start () >> >> I don't know what's going on here, but this stack trace can't be >> right. dlopen doesn't call find_symdef, and find_symdef doesn't >> call map_object. > > Isn't map_object() part of the a.out rtld? Both rtlds have functions named find_symdef() and map_object(). He indicated that it was an ELF system, so I assumed he was using the ELF rtld. In any case, my statement about the stack trace would be equally true for the a.out dynamic linker. :-) John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen failure
In article <37458ff0.fc9b2...@cablenet.net>,
Damian Hamill wrote:
> I have found the problem and it is a problem with make. By chance I did
> an ls -l of the directory and noticed the shared object was only 371
> bytes and thought no that can't be right.
Thanks for letting us know. I'm glad it's solved now.
> My makefile sez.
>
> mysqlacc.so : mysqlacc.o
> ld -Bshareable -o $@ $< -u _floor ../../lib/libV.a ... {other libs}
By the way, don't use "ld -Bshareable" to build shared libraries.
Use "cc -shared". There are some special .o files from /usr/lib
that need to be linked in, and "cc -shared" will do that for you
automatically.
John
--
John Polstra j...@polstra.com
John D. Polstra & Co., Inc.Seattle, Washington USA
"Self-interest is the aphrodisiac of belief." -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: more on the pcmcia saga.
In article <199905270619.qaa09...@cheops.anu.edu.au>, Darren Reed wrote: > In some mail from Wes Peters, sie said: > [...] > > PC-Card Intel 82365 (5 mem & 2 I/O windows) > > pcic: controller irq 3 > > ^^ > > Initializing PC-card drivers: sio > > Why does it list "sio" here ? I don't see where sio is actually > used with PCMCIA here...why doesn't it list ed0 too ? (Is this a > bug ?) Yes, this was a bug. I committed the fix on April 27: jdp 1999/04/27 11:34:14 PDT Modified files: sys/pccard pccard.c Log: Fix the code that prints the "Initializing PC-card drivers" message so that the list of drivers is correct. This is a slightly simplified version of the patch from the PR. PR: misc/10544 Submitted by: Christophe Colle Revision ChangesPath 1.75 +3 -4 src/sys/pccard/pccard.c jdp 1999/04/27 11:39:25 PDT Modified files:(Branch: RELENG_3) sys/pccard pccard.c Log: MFC 1.74 -> 1.75: Print correct list of PC-Card drivers. Revision ChangesPath 1.68.2.3 +3 -4 src/sys/pccard/pccard.c John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM: Undefined symbols at runtime
In article <19990529151511.a34...@wopr.caltech.edu>, Matthew Hunt wrote: > I have been running 3.x and 4.0-CURRENT for some time, but have > never bothered using PAM. If you are running 3.1 or later, or -current, you _are_ using PAM. Login uses it automatically, and it's not something you enable or disable. If you don't have a valid /etc/pam.conf file then login issues loud and repeated complaints to syslog, which will appear on the system console. > Yesterday, after a build of 4.0-CURRENT of that day, I decided to > try enabling PAM by copying /usr/src/pam.conf to /etc. There is no file /usr/src/pam.conf. Do you mean /usr/src/etc/pam.conf? > My problem is that login fails, due to undefined symbols in the PAM > modules: I don't know what's going on with your system, but something is messed up. Maybe you're trying to mix and match a.out and ELF files. Try running "file" on /usr/bin/login as well as your libpam and pam modules. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM: Undefined symbols at runtime
Matthew Hunt wrote: > If I add "-export-dynamic" to LDADD in usr.bin/login/Makefile, everything > is groovy. > > I've noticed that dynamic linking in Perl also doesn't work for me, > likely for the same reason. I haven't tried rebuilding perl with > "-export-dynamic" yet, though. > > So, the question now is: Why do I need "-export-dynamic", when > evidently nobody else does? I don't know. Maybe you have something unusual in your /etc/make.conf file? John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Partitioning a freebsd partition on the fly
In article <19990601131050.a27...@falcon.sourcee.com>, Evan Tsoukalas wrote: > My question is, can I shrink my /usr partition down without losing > what is on it? It is a 3.8 gig partition that only has 900 meg or > so on it. I would like to trim about a gigabyte off of it so that > I can install Windoze. Is this going to be possible, or should I > start from scratch installing Winoze first? The only way to shrink it is like this: * back up the filesystem to someplace using dump * shrink the partition * run newfs to create a filesystem on the resized partition * restore the data from your backup John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: where is variable edata defined ?
In article <000201beacec$98086960$85343...@k>, fretre wrote:
> The variable such as _edata, _etext,_gdt are defined in the
> file asnames.h(/usr/include/machine/asnames.h),but
> 1. Where is the file that the variable such as edata,etext,gdt
>are defined in? and
I don't know about gdt. But edata and etext are provided
automatically by the linker ("ld").
John
--
John Polstra j...@polstra.com
John D. Polstra & Co., Inc.Seattle, Washington USA
"Self-interest is the aphrodisiac of belief." -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: m3socks and cvsup
In article <19990608084217.a5...@alaska.cert.siemens.de>, Udo Schweigert wrote: > I'm using it (runsocks cvsup -P m) for a year now and it works > without any problems. (Since cvsup 16 the "-P m" is not needed, so > "runsocks cvsup" should so it). Just to make sure I understand: You're using standard socks rather than m3socks, right? I believe that standard socks should work with cvsup's multiplexed mode, but I've never tried it. It would probably be necessary to add "@M3novm" to the command line, though. If standard socks works, then I want to eliminate m3socks. There are some problems with m3socks that I just found out about recently. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: m3socks and cvsup
Udo Schweigert wrote:
> I'm not using m3socks, I use the standard socks5 from ports (current
> version is socks5-1.0.8). To use it (the runsocks program) with
> cvsup one has to build cvsup with dynamic linking (by building port
> net/cvsup), the precompiled package from CD-ROM and the one from
> net/cvsup-bin port will not work.
>
> For example I changed in /usr/local/etc/cvsup/update.sh (contained in
> net/cvsup-mirror port):
>
> < cvsup -1gL 1 -c ${colldir} -h ${host} supfile
> ---
> > runsocks cvsup -P m -1gL 1 -c ${colldir} -h ${host} supfile
>
> As stated before, this works since approx. one year without any problems.
Thanks for the information. I was pretty sure that multiplexed mode
had eliminated the need for a special socks package, but I hadn't
checked it myself.
I recommend adding "@M3novm" to the cvsup command line when using
socks. Otherwise you might get "Bad address" errors occasionally.
John
---
John Polstra j...@polstra.com
John D. Polstra & Co., Inc.Seattle, Washington USA
"Self-interest is the aphrodisiac of belief." -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen returns non NULL
In article , Max Khon wrote: > > in the following code `dlopen' returns NULL > on the first iteration (because g() is not defined) -- it's ok > but on the second iteration `dlopen' returns "valid" dlh ELF or a.out? Which version of FreeBSD? For a.out, it's a known bug and there is already an open PR on it. I wouldn't be surprised if the bug existed in ELF too. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump(1) additions.
In article <19990630092358.a51...@wopr.caltech.edu>, Matthew Hunt wrote: > > I think the point is that when root is running tcpdump on host A, a bad > guy on host B can create a packet which makes tcpdump on A execute his > code (as root, since that's who's running it). This is not desirable. I would say it is not _acceptable_. The code shouldn't go into our source tree until the known buffer overflow problems have been fixed. It's just stupid to add buffer overflow problems to a program that is always run as root. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen returns non NULL
Max Khon wrote: >> For a.out, it's a known bug and there is already an open PR on it. >> I wouldn't be surprised if the bug existed in ELF too. > > 3.2-STABLE built on 10 Jun, ELF Thanks for the info. Could you please do a send-pr on this bug, and tell me the PR number? Then I'll assign myself as the resposible person. Please be sure to state that it's the ELF dynamic linker. If you're in a big hurry and would like to work on it yourself, the relevant code is in "src/libexec/rtld-elf/rtld.c" in the function dlopen() near the comment that says "XXX - Clean up properly after an error." :-) The fix may be as simple as calling unref_object_dag() from the failure cases there, but it will need careful checking. Some additional changes may be needed in load_needed_objects() near the comment that says "XXX - cleanup." :-) Thanks, John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Pictures from USENIX
I put a handful of pictures from this year's USENIX conference at <http://www.freebsd.org/~jdp/usenix1999/>. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Login.conf (Whose problem is this) ?
In article <377e34f9.ca198...@tdnet.com.br>, Gustavo V G C Rios wrote: > i am trying to get a login classes for my users, so i decided to edit > /etc/login.conf. > > Among other, i have yma classes this way: > > > shell:\ > :maxproc=5:\ > :tc=auth-default: > > > Looking for auth-default, i saw the following: > > ## Authentication methods > ## Note that these are disabled by default, and libutil must > ## be rebuilt with LOGIN_CAP_AUTH defined to use them. This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any more. (It never was fully supported, actually.) Don't use it. > That's happened cause i turn on LOGIN_CAP_AUTH! > My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH? Yes, of course. That's what "with LOGIN_CAP_AUTH defined" means. But it's broken, so don't bother. If you want login classes all you need to do is "vipw" and insert the correct class in the class field. (See passwd(5) for details.) If you want to create a new class, just edit it into your login.conf file and then run cap_mkdb as instructed in the comment at the top of that file. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Login.conf (Whose problem is this) ?
Sheldon Hearn wrote: >> This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any >> more. (It never was fully supported, actually.) Don't use it. > > There's an open PR for this, PR 10115. I assume all that's required is > that we smack the outdated comments from login.conf? Yes, I think so. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
In article <199907050103.saa51...@bubba.whistle.com>, Archie Cobbs wrote: > > A new, faster event notification system would be great. But don't forget > to include *all* events, not just file descriptor readability/writability. Yes! Yes! Yes! (I agree.) John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
In article , Brian F. Feldman wrote: > On Sun, 4 Jul 1999, Archie Cobbs wrote: > > > A new, faster event notification system would be great. But don't forget > > to include *all* events, not just file descriptor readability/writability. > > I.e., signal delivery, child exit notification, maybe even support for > > an arbitrary number of (independent) timers. And make the events independent > > from each other -- to avoid problems like when an application completely > > hangs for 90 seconds when it calls gethostbyname(). > > An async thread to do hostname lookups would be great! Wouldn't be too > hard in libc_r, would it? The application itself has to get involved if it wants to do async name lookups, or async anything else, for that matter. Suppose you do have an async thread to do hostname lookups as you propose. What is the application going to do while that thread is waiting for the lookup to complete? It depends on the application, and thus it has to be coded into the application. Maybe there's nothing useful the application could do until the lookup returns. I've been told that it works fine to use libc_r and put the name lookups into a separate thread. But to take advantage of it, the application has to have something useful it wants to do (and can do) in the meantime. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic linking
In article <3780aeb2.20616...@agama.com>, Andrew Iltchenko wrote: > Hi everyone! > > Is there a way of making dlopen return an error from the shared object's > _init function? No. The _init function by definition is "void _init(void)", and so it cannot return a value. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap question
In article <000101bec73c$e20e3660$291c4...@kbyanc.alcnet.com>, Kelly Yancey wrote: > > Also, in case it hasn't been notice already (I'm running -stable from May > 18th), the mmap(2) manpage has a typo: it has "#include " So what's the typo, exactly? John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
Brian F. Feldman wrote: > On Tue, 6 Jul 1999, John Polstra wrote: > >> In article , >> >> The application itself has to get involved if it wants to do async >> name lookups, or async anything else, for that matter. Suppose you >> do have an async thread to do hostname lookups as you propose. What >> is the application going to do while that thread is waiting for the >> lookup to complete? It depends on the application, and thus it has >> to be coded into the application. Maybe there's nothing useful the >> application could do until the lookup returns. >> >> I've been told that it works fine to use libc_r and put the name >> lookups into a separate thread. But to take advantage of it, the >> application has to have something useful it wants to do (and can do) >> in the meantime. > > It would let the other threads run more while the lookup is occurring. > Wouldn't that be the most natural expectation of it? Or would this > be too hard without kernel-assisted threading? What I'm saying is, we already have that in multi-threaded applications. The system can't just provide it automatically to single-threaded applications; they wouldn't know how to take advantage of it. In other words: * Multi-threaded applications already have it. * Single-threaded applications can't use it. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article <199907102150.paa33...@harmony.village.org>, Warner Losh wrote: > > Some ftpd and sendmail servers make the queries. When I have my fake > identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. The only way a long timeout can occur is if you have a filter rule installed that drops the incoming packets without responding to them. You can block the incoming packets but still avoid the timeout with a filter rule that sends back a reset: add reset tcp from any to any auth setup in via etha16 John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Doug wrote: > John Polstra wrote: >> >> Are you sure? If you simply don't run an identd, the queries will >> get an instant connection refused error. That's even faster than >> sending back a bogus response. > > Many daemons that request ident, and almost all IRC daemons > that I'm aware of don't take "NO" for an answer. They sit waiting > for a valid response, and timeout after X seconds, where X is c. 30 > seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. > Whether this behavior is good or not begs the question, Agreed. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Why 'dd' does not seek over 'char' devs (specifically raw disk
In article , Brian F. Feldman wrote: > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > couldn't we first try lseek and only do the reads on char devs where > > the lseek fails ? > > lseek() won't usually fail unless it's something like EBADF. It merely > sets the current fd's offset. It would be nice to be able to tell from > a device driver if it supports seeking (da) or not (sa). Hmm... actually, > if we just specify somehow that we support either direct or sequential > access... this would be possible. It would be a big improvement if dd could handle seeking on character disk devices. I'm reasonably certain there exists some ioctl (perhaps related to reading disk labels) which could be used to figure out whether a character device was a disk or not. A simple fix like that would make dd a lot more useful for the case Luigi brought up. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article <199907132004.aa08...@salmon.maths.tcd.ie>, Ian Dowse wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > do a readlink(), which would be safer, neater and faster than reading a > file. A user can set up a fake ID with something like: > > ln -s "Warm-Fuzzy" .fakeid Ick. Please, no more abuse of symbolic links! Once (malloc) was enough. Data is held in files, not in filenames. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In article , Brian F. Feldman wrote: > [GNU getopt] > If you give me documentation on it, I'll implement it for the BSD libc. Note, we already have GNU getopt in the source tree in libiberty (in two different places -- binutils and gdb). It might be better just to install libiberty from one of those places. Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
Brian F. Feldman wrote: > On Mon, 19 Jul 1999, John Polstra wrote: > >> Left as an exercise for the reader: Figure out how the two differ >> and which one is "better". :-) > > I'd rather hurt myself severely. Of course. That's a prerequisite for becoming a committer. :-) John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
In article <19990720082825.b...@fisicc-ufm.edu>, Oscar Bonilla wrote: > Couldn't we do this with /etc/auth.conf? The plan when PAM was brought in was to eliminate auth.conf. I don't think we should be looking for new uses for it. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dl.h in stable causes sendmail segmentation
In article <199907201542.raa02...@oskar.nanoteq.co.za>, Reinier Bezuidenhout wrote: > I have the following situation... ... [various userland SEGVs traced down to a change in if_dl.h] Just a guess: it sounds like the kind of thing that would happen if you updated your kernel without also rebuilding userland. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Oscar Bonilla wrote: > > ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf > and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf > for the info on where to obtain the databases from. That seems reasonable to me. PAM actually is designed to serve four separate but related functions. We're only using the authentication function currently. For an overview of PAM, see PAM(8) in the manual pages. There is also a spec in "src/contrib/libpam/doc/specs/rfc86.0.txt". John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
