Re: glibc

1999-07-19 Thread John Polstra

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: glibc

1999-07-19 Thread John Polstra
In article pine.bsf.4.10.9907191315440.40596-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org 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

1999-07-19 Thread John Polstra
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: Why 'dd' does not seek over 'char' devs (specifically raw disk

1999-07-13 Thread John Polstra

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

1999-07-13 Thread John Polstra

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: Why 'dd' does not seek over 'char' devs (specifically raw disk

1999-07-13 Thread John Polstra
In article pine.bsf.4.10.9907131042310.76301-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org 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

1999-07-13 Thread John Polstra
In article 199907132004.aa08...@salmon.maths.tcd.ie,
Ian Dowse  iedo...@maths.tcd.ie 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: a BSD identd

1999-07-11 Thread John Polstra

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: a BSD identd

1999-07-11 Thread John Polstra
In article 199907102150.paa33...@harmony.village.org,
Warner Losh  i...@village.org 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

1999-07-11 Thread John Polstra
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: poll() vs select()

1999-07-06 Thread John Polstra

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()

1999-07-06 Thread John Polstra

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: mmap question

1999-07-06 Thread John Polstra

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 sys/mman.h"

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()

1999-07-06 Thread John Polstra
In article 199907050103.saa51...@bubba.whistle.com,
Archie Cobbs  arc...@whistle.com 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()

1999-07-06 Thread John Polstra
In article pine.bsf.4.10.9907042155090.66085-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org 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

1999-07-06 Thread John Polstra
In article 3780aeb2.20616...@agama.com,
Andrew Iltchenko  and...@agama.com 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

1999-07-06 Thread John Polstra
In article 000101bec73c$e20e3660$291c4...@kbyanc.alcnet.com,
Kelly Yancey kby...@alcnet.com 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 sys/mman.h

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()

1999-07-06 Thread John Polstra
Brian F. Feldman wrote:
 On Tue, 6 Jul 1999, John Polstra wrote:
 
 In article pine.bsf.4.10.9907042155090.66085-100...@janus.syracuse.net,
 
 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: Login.conf (Whose problem is this) ?

1999-07-05 Thread John Polstra
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: Login.conf (Whose problem is this) ?

1999-07-03 Thread John Polstra

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



Pictures from USENIX

1999-07-03 Thread John Polstra
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) ?

1999-07-03 Thread John Polstra
In article 377e34f9.ca198...@tdnet.com.br,
Gustavo V G C Rios  ker...@tdnet.com.br 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: dlopen returns non NULL

1999-06-30 Thread John Polstra
In article pine.bsf.4.05.9906291726460.1300-100...@iclub.nsu.ru,
Max Khon  f...@iclub.nsu.ru 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.

1999-06-30 Thread John Polstra
In article 19990630092358.a51...@wopr.caltech.edu,
Matthew Hunt  m...@astro.caltech.edu 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

1999-06-30 Thread John Polstra
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



Re: m3socks and cvsup

1999-06-17 Thread John Polstra
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: m3socks and cvsup

1999-06-16 Thread John Polstra
In article 19990608084217.a5...@alaska.cert.siemens.de,
Udo Schweigert  u...@cert.siemens.de 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: Partitioning a freebsd partition on the fly

1999-06-05 Thread John Polstra
In article 19990601131050.a27...@falcon.sourcee.com, Evan Tsoukalas
e...@falcon.sourcee.com 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 ?

1999-06-05 Thread John Polstra
In article 000201beacec$98086960$85343...@k, fretre fre...@163.net 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: PAM: Undefined symbols at runtime

1999-06-01 Thread John Polstra
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: PAM: Undefined symbols at runtime

1999-05-30 Thread John Polstra
In article 19990529151511.a34...@wopr.caltech.edu,
Matthew Hunt  m...@freebsd.org 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: more on the pcmcia saga.

1999-05-27 Thread John Polstra
In article 199905270619.qaa09...@cheops.anu.edu.au,
Darren Reed  ava...@coombs.anu.edu.au 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 co...@krtkg1.rug.ac.be
  
  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: dlopen failure

1999-05-22 Thread John Polstra
In article 37458ff0.fc9b2...@cablenet.net,
Damian Hamill  dam...@cablenet.net 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: dlopen failure

1999-05-21 Thread John Polstra

Doug Rabson wrote:
 On Thu, 20 May 1999, John Polstra wrote:
 
 In article 373c3f3f.a99db...@cablenet.net,
 Damian Hamill  dam...@cablenet.net 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

1999-05-20 Thread John Polstra
In article 373c3f3f.a99db...@cablenet.net,
Damian Hamill  dam...@cablenet.net 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: gas pseudo-ops

1999-01-16 Thread John Polstra

In article 01bf260d$837c8770$[EMAIL PROTECTED],
Stephane Potvin [EMAIL PROTECTED] wrote:
 
 Do you think it would be possible to change the
   .type symbol,@object
 for
   .type symbol,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
machine/gensetdefs.h.  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?

1999-01-16 Thread John Polstra

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



<    1   2   3