Re: ipfw question.

2000-10-27 Thread Bill Fumerola

On Thu, Oct 26, 2000 at 03:10:35PM -0700, David O'Brien wrote:

 So one doesn't have to change the source, would you be willing to add
 WANT_foo logic so one could just set it in /etc/make.conf?  Or add
 ${IPFIREWALL_OPTS} to CFLAGS and then IPFIREWALL_OPTS could be set in
 /etc/make.conf?

Having read the rest of this thread my position is "willing, able, but
unsure if its needed".  I'll talk with Peter when he's back on this
side of the Pacific.

-- 
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Is this a typo?

2000-10-27 Thread Jeroen Ruigrok van der Werven

-On [20001026 23:30], Julian Elischer ([EMAIL PROTECTED]) wrote:
in the bus_alloc_resource() man page it states:


 dev is the device that requests ownership of the resource.  Before
allo-
 cation, the device is owned by the parent bus.

should that be:
"Before allocation, the resource is owned by the parent bus."  ?

I will fix the manpage later on today, your requested change is not
entirely accurate, yet.

-- 
Jeroen Ruigrok van der Werven  Network- and systemadministrator
[EMAIL PROTECTED]VIA Net.Works The Netherlands
BSD: Technical excellence at its best  http://www.via-net-works.nl
Judge not, that ye be not judged...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: more endian.h breakage; patch included.

2000-10-27 Thread Bruce Evans

On Wed, 18 Oct 2000, Brian Somers wrote:

  On Mon, 16 Oct 2000, Brian Somers wrote:
   ntohl()  ntonl() were previously wrong to return u_long.
  
  Not wrong.  They have always been documented to return u_long.
 
 But if sizeof(u_long) != 4, this is wrong.

It's not best, but not wrong, since u_long is large enough to hold
all values of interest and the interfaces don't involve any pointers.

[... lots deleted]

 I think the best way forward is to prototype things in terms of 
 in_addr_t and in_port_t and to leave them as inlines for __GNUC__ 
 (I don't know where other compilers are supposed to get this 
 functionality).

I agree.

 I think we should *not* include sys/types.h and should leave all of 
 the sys/types.h additions that I've done to files that include 
 sys/wait.h, but this idea conflicts with all other endian.h files 
 (both ours and {Net,Open}BSDs), and is probably wrong in that 
 requiring sys/anything for machine/anything is probably not too good.

Just define in_addr_t and in_port_t in terms of basic types, like we
already do for int32_t, etc.

 Maybe the NetBSD way of moving machine/endian.h to sys/endian.h and 
 having machine/endian.h as a simple ``#include sys/endian.h'' is 
 the cleanest solution

Except this isn't backwards compatible and there is no reason to put it
in sys.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problem in fetch

2000-10-27 Thread Harti Brandt

On Thu, 26 Oct 2000, Andrea Campi wrote:

 When trying to install ports, very often I find everything freezes just
 after fetch completes. If I hit ^C and type "make install" again, the
 tarball is there, that's why I say that fetch is already done.
 If I hit ^T, I see fetch sitting in sbwait, the time not increasing.
 
 Any idea?

The same here. It blocks in utimes(2) when trying to set the times on the
fetched file.

No clue. Annoying.

harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



kernel build problem

2000-10-27 Thread Doug Barton

With tonight's sources I had an error in sys/netinet/ip_compat.h that
was looking for an osreldate.h that didn't exist. The following patch
fixes it, in the sense that the kernel and lkm compile, and ipfilter
compiled into the kernel works. However I'm told it might not be
appropriate. FWIW, I'm using buildkernel, and I can see
src/i386/usr/include/osreldate.h and src/include/osreldate.h both in
/usr/obj. 

Doug

Index: ip_compat.h
===
RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v
retrieving revision 1.11
diff -u -r1.11 ip_compat.h
--- ip_compat.h 2000/10/26 12:33:42 1.11
+++ ip_compat.h 2000/10/27 06:14:46
@@ -265,10 +265,10 @@
 
 #if defined(__FreeBSD__)  (defined(KERNEL) || defined(_KERNEL))
 # ifdef IPFILTER_LKM
-#  include osreldate.h
+#  include sys/param.h
 #  define   ACTUALLY_LKM_NOT_KERNEL
 # else
-#  include sys/osreldate.h
+#  include sys/param.h
 # endif
 # if __FreeBSD__  3
 #  include machine/spl.h


-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problem in fetch

2000-10-27 Thread Jeroen Ruigrok van der Werven

-On [20001027 10:00], Dag-Erling Smorgrav ([EMAIL PROTECTED]) wrote:
Jeroen Ruigrok van der Werven [EMAIL PROTECTED] writes:
 [Making sure Dag-Erling gets the mail]
 -On [20001026 18:45], Andrea Campi ([EMAIL PROTECTED]) wrote:
  When trying to install ports, very often I find everything freezes just
  after fetch completes. If I hit ^C and type "make install" again, the
  tarball is there, that's why I say that fetch is already done.
  If I hit ^T, I see fetch sitting in sbwait, the time not increasing.
 Just a note, I got the same thing under 4-STABLE with the latest
 sources.

Weird. I develop libfetch on -STABLE these days, and have no such problems.

I guess it is some sites again.  I don't have the problem with every
http or ftp site.

Does this only happen with FTP documnts, BTW? I recently changed the
FTP code so it waits for the status code to arrive on the control
socket when the transfer is complete (so that connection caching will
work). That may be the problem; try setting FETCH_CMD to 'fetch -T60'
and see if it times out after sixty seconds.

Might be, cannot be sure 100% right now, from memory, I'd say yes.

The vim6 port for one is problematic.

 I'll get a debug/verbose dump for you tomorrow DES.

Thanks!

No problem.

Everybody else, if you don't know how to do this:

# cd /usr/src/lib/libfetch  make clean  make obj  \
make depend -DDEBUG  make -DDEBUG  make install

then run fetch with -vv, and you'll get a full transcript of the
session (note that this can be quite a lot when fetching a
chunk-encoded HTTP document)

[10:28] [root@lucifer] (7) {1} # FETCH_CMD='fetch -vv -T60' make fetch 
 vim-6.0j-rt.tar.gz doesn't seem to exist in /usr/ports/distfiles/vim.
 Attempting to fetch from
 ftp://ftp.prz.tu-berlin.de/pub/unix/editors/vim/unreleased/unix/.
looking up ftp.prz.tu-berlin.de
connecting to ftp.prz.tu-berlin.de:21
fetch: vim-6.0j-rt.tar.gz: File unavailable (e.g., file not found, no
access)
 Attempting to fetch from ftp://ftp.vim.org/pub/vim/unreleased/unix/.
looking up ftp.vim.org
connecting to ftp.vim.org:21
setting passive mode
opening data connection
initiating transfer
fetch: remote: 1266150 / 972245439
Receiving vim-6.0j-rt.tar.gz (1266150 bytes): 100%
1266150 bytes transferred in 2.3 seconds (540.03 kBps)
/usr/ports/editors/vim6
[10:29] [root@lucifer] (8) {0} # 

It timed out after the 60 seconds had passed.

DEBUG output:

[10:43] [root@lucifer] (30) {0} # FETCH_CMD='fetch -vv -T60' make fetch 
 vim-6.0j-src.tar.gz doesn't seem to exist in
 /usr/ports/distfiles/vim.
 Attempting to fetch from
 ftp://ftp.prz.tu-berlin.de/pub/unix/editors/vim/unreleased/unix/.
scheme:   [ftp]
user: []
password: []
host: [ftp.prz.tu-berlin.de]
port: [0]
document: [/pub/unix/editors/vim/unreleased/unix/vim-6.0j-src.tar.gz]
--- ftp.prz.tu-berlin.de:21
looking up ftp.prz.tu-berlin.de
connecting to ftp.prz.tu-berlin.de:21
 220 ProFTPD 1.2.0pre8 Server (ftp.prz.tu-berlin.de) [kumpel.prz.tu-berlin.de]
 USER ftp
 331 Anonymous login ok, send your complete e-mail address as password.
 PASS [EMAIL PROTECTED]
 230 Anonymous access granted, restrictions apply.
 TYPE I
 200 Type set to I.
 CWD /pub/unix/editors/vim/unreleased/unix
 550 /pub/unix/editors/vim/unreleased/unix: No such file or directory
fetch: vim-6.0j-src.tar.gz: File unavailable (e.g., file not found, no access)
 Attempting to fetch from ftp://ftp.vim.org/pub/vim/unreleased/unix/.
scheme:   [ftp]
user: []
password: []
host: [ftp.vim.org]
port: [0]
document: [/pub/vim/unreleased/unix/vim-6.0j-src.tar.gz]
--- ftp.vim.org:21
looking up ftp.vim.org
connecting to ftp.vim.org:21
 220-Welcome to the FTP archive of The Netherlands Unix Users Group, NLUUG.
 220-
 220-This server is located in The Netherlands, Europe.
 220-If you are abroad, please find an ftp site near you.
 220-Most information on this site is mirrored.
 220-
 220-Information about your login and any transfers you do are logged.
 220-If you don't like this, disconnect now.
 220-
 220-There are currently 153 users logged in (maximum 175).
 220-
 220-You may login as "ftp" or "anonymous".
 220-
 220 ftp.nluug.nl FTP server (Version wu-2.6.0(1) Fri Jun 23 09:17:44 EDT 2000) 
ready.
 USER ftp
 331 Guest login ok, send your complete e-mail address as password.
 PASS [EMAIL PROTECTED]
 230 Guest login ok, access restrictions apply.
 TYPE I
 200 Type set to I.
 CWD /pub/vim/unreleased/unix
 250-Unreleased versions of Vim - Vi IMproved - for Unix et al.
 250-
 250-The files in this directory contain test versions for Unix systems.
 250-Get both the "src" and the "rt" (runtime) archive!
 250-These are also used for VMS, BeOS, OS/2, Mac, etc., in combination
 250-with the "extra" archive (in ../extra).
 250-
 250-Ctags is no longer included.  See http://ctags.sourceforge.net.
 250-A copy of the sources is in the "extra" directory.
 250-
 250- SIZEFILE  CONTENTS
 250-

platform byte order macros?

2000-10-27 Thread Konstantin Chuguev

Hi,

AFAICS ntoh[ls] and hton[ls] defined as asm instructions. This prevents
using them in const variables initialisation.
I need to create a const unsigned char array[] (C source file) from quite
a big network byte ordered binary data. Although the data consists mainly
of bytes and 16- and 32-bit words, it is difficult in my case to use
u_char, u_int16_t and u_int32_t, as the order and the number of each type
does not fit to any possible C struct declaration.
Well, I can just create a network ordered byte array C declaration like
const unsigned char array[] = { byte0, byte1, ... };
But for more efficient processing I would like to have something like
const unsigned char array[] = {
_4bytes(b0, b1, b2, b3)
_1long(b4, b5, b6, b7)
_2shorts(b8, b9, b10, b11)
_1long(b12, b13, b14, b15)
_4bytes(b16, b17, b18, b19)
...
};
... i.e. platform independent source code which would compile into
platform dependent object file. _4bytes, _2shorts and _1long are macros
produced for byte sequence in appropriate byte order. The macros need to
know the platform byte order, theoretically it can be one of 1234, 4321,
2143.
In endian.h I can see just huge line of comparisons to *_386 et. al., but
I cannot find any macros clearly decsribing the byte order. Am I wrong?

Thanks,
Konstantin.


--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: kernel build problem

2000-10-27 Thread Darren Reed

What failed ?  Do you have the make error output ?

Darren

In some email I received from Doug Barton, sie wrote:
   With tonight's sources I had an error in sys/netinet/ip_compat.h that
 was looking for an osreldate.h that didn't exist. The following patch
 fixes it, in the sense that the kernel and lkm compile, and ipfilter
 compiled into the kernel works. However I'm told it might not be
 appropriate. FWIW, I'm using buildkernel, and I can see
 src/i386/usr/include/osreldate.h and src/include/osreldate.h both in
 /usr/obj. 
 
 Doug
 
 Index: ip_compat.h
 ===
 RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v
 retrieving revision 1.11
 diff -u -r1.11 ip_compat.h
 --- ip_compat.h 2000/10/26 12:33:42 1.11
 +++ ip_compat.h 2000/10/27 06:14:46
 @@ -265,10 +265,10 @@
  
  #if defined(__FreeBSD__)  (defined(KERNEL) || defined(_KERNEL))
  # ifdef IPFILTER_LKM
 -#  include osreldate.h
 +#  include sys/param.h
  #  define   ACTUALLY_LKM_NOT_KERNEL
  # else
 -#  include sys/osreldate.h
 +#  include sys/param.h
  # endif
  # if __FreeBSD__  3
  #  include machine/spl.h
 
 
 -- 
 "The dead cannot be seduced."
   - Kai, "Lexx"
 
   Do YOU Yahoo!?
 
 
 
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: kernel build problem

2000-10-27 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Darren Reed writes
:
What failed ?  Do you have the make error output ?

Did you try to compile LINT before you committed ?

Right, if you had you would have seen the error :-(

Darren

 Index: ip_compat.h
 ===
 RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v
 retrieving revision 1.11
 diff -u -r1.11 ip_compat.h
 --- ip_compat.h 2000/10/26 12:33:42 1.11
 +++ ip_compat.h 2000/10/27 06:14:46
 @@ -265,10 +265,10 @@
  
  #if defined(__FreeBSD__)  (defined(KERNEL) || defined(_KERNEL))
  # ifdef IPFILTER_LKM
 -#  include osreldate.h
 +#  include sys/param.h
  #  define   ACTUALLY_LKM_NOT_KERNEL
  # else
 -#  include sys/osreldate.h
 +#  include sys/param.h
  # endif
  # if __FreeBSD__  3
  #  include machine/spl.h
 
 
 -- 
 "The dead cannot be seduced."
  - Kai, "Lexx"
 
  Do YOU Yahoo!?
 
 
 
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



endian.h problem with gnats port

2000-10-27 Thread Doug Barton

I'm trying to compile gnats locally, and getting an ugly error
regarding endian.h. Due to the recent include file shuffling I'm
starting in -current rather than ports. 

cc -c -I. -I. -I./../include  -O -ggdb -pipe -g  -DHAVE_CONFIG_H
queue-pr.c
In file included from /usr/include/sys/wait.h:93,
 from queue-pr.c:23:
/usr/include/machine/endian.h:72: syntax error before
`__uint16_swap_uint32'
/usr/include/machine/endian.h:72: syntax error before `__x'
/usr/include/machine/endian.h: In function `__uint16_swap_uint32':
/usr/include/machine/endian.h:74: `__x' undeclared (first use in this
function)
/usr/include/machine/endian.h:74: (Each undeclared identifier is
reported only once
/usr/include/machine/endian.h:74: for each function it appears in.)
/usr/include/machine/endian.h: At top level:
/usr/include/machine/endian.h:80: syntax error before
`__uint8_swap_uint32'
/usr/include/machine/endian.h:80: syntax error before `__x'
/usr/include/machine/endian.h: In function `__uint8_swap_uint32':
/usr/include/machine/endian.h:86: `__x' undeclared (first use in this
function)
/usr/include/machine/endian.h: At top level:
/usr/include/machine/endian.h:92: syntax error before
`__uint8_swap_uint16'
/usr/include/machine/endian.h:92: syntax error before `__x'
/usr/include/machine/endian.h: In function `__uint8_swap_uint16':
/usr/include/machine/endian.h:94: `__x' undeclared (first use in this
function)
gmake[1]: *** [queue-pr.o] Error 1
gmake[1]: Leaving directory
`/usr/amd/slave/usr/ports/databases/gnats/work/gnats-3.113/gnats'
gmake: *** [all-gnats] Error 2
*** Error code 2

Stop in /usr/amd/slave/usr/ports/databases/gnats.

I've tried wiping out and reinstalling my includes, and checked the cvs
logs for endian.h and nothing leaps to mind here. 

Also, a quick question for the maintainer, why is bison still a
dependency if patch-aa defines "BISON=$(YACC)"? 

Doug
-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: kernel build problem

2000-10-27 Thread Doug Barton

Darren Reed wrote:
 
 What failed ?  Do you have the make error output ?

In file included from
/usr/amd/slave/usr/current/src/sys/netinet/fil.c:79:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_auth.c:93:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_fil.c:101:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_frag.c:71:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_log.c:112:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_nat.c:99:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_proxy.c:72:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/ip_state.c:82:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory
In file included from
/usr/amd/slave/usr/current/src/sys/netinet/mlfk_ipl.c:44:
/usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271:
sys/osreldate.h: No such file or directory

HTH,

Doug

-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: endian.h problem with gnats port

2000-10-27 Thread Harti Brandt

On Fri, 27 Oct 2000, Doug Barton wrote:

   I'm trying to compile gnats locally, and getting an ugly error
 regarding endian.h. Due to the recent include file shuffling I'm
 starting in -current rather than ports. 
 
 cc -c -I. -I. -I./../include  -O -ggdb -pipe -g  -DHAVE_CONFIG_H
 queue-pr.c
 In file included from /usr/include/sys/wait.h:93,
  from queue-pr.c:23:

sys/wait.h now needs sys/types.h.

That's documented. Many ports break also.

harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: endian.h problem with gnats port

2000-10-27 Thread Doug Barton

Harti Brandt wrote:
 
 On Fri, 27 Oct 2000, Doug Barton wrote:
 
I'm trying to compile gnats locally, and getting an ugly error
  regarding endian.h. Due to the recent include file shuffling I'm
  starting in -current rather than ports.
 
  cc -c -I. -I. -I./../include  -O -ggdb -pipe -g  -DHAVE_CONFIG_H
  queue-pr.c
  In file included from /usr/include/sys/wait.h:93,
   from queue-pr.c:23:
 
 sys/wait.h now needs sys/types.h.
 
 That's documented. Many ports break also.

Bah... I knew it was something like this and I just couldn't remember
the voodoo. Attached patch gets the port built, and a quick pass through
edit-pr and query-pr seem to DTRT.

Thanks,

Doug
-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?

Index: Makefile
===
RCS file: /usr/ncvs/ports/databases/gnats/Makefile,v
retrieving revision 1.32
diff -u -r1.32 Makefile
--- Makefile2000/10/08 10:19:23 1.32
+++ Makefile2000/10/27 10:34:49
@@ -22,7 +22,6 @@
--with-release-based
 
 USE_GMAKE= yes
-USE_BISON= yes
 MAN1=  edit-pr.1 query-pr.1 send-pr.1
 MAN7=  gnats.7
 MAN8=  mkcat.8 rmcat.8 mkdist.8 queue-pr.8 file-pr.8 gen-index.8
Index: files/patch-ae
===
RCS file: patch-ae
diff -N patch-ae
--- /dev/null   Fri Oct 27 03:41:59 2000
+++ patch-aeFri Oct 27 03:39:51 2000
@@ -0,0 +1,10 @@
+--- gnats/queue-pr.c.Dist  Wed Nov 25 06:15:20 1998
 gnats/queue-pr.c   Fri Oct 27 03:37:29 2000
+@@ -20,6 +20,7 @@
+ 
+ #include "config.h"
+ 
++#include sys/types.h
+ #include sys/wait.h /* FIXME */
+ #include sys/param.h /* FIXME: gets MAXBSIZE */
+ 



Re: platform byte order macros?

2000-10-27 Thread Bruce Evans

On Fri, 27 Oct 2000, Konstantin Chuguev wrote:

 AFAICS ntoh[ls] and hton[ls] defined as asm instructions. This prevents
 using them in const variables initialisation.

They are normally implemented using asm, but their man page just hints
that they are functions by giving prototypes for them.

 I need to create a const unsigned char array[] (C source file) from quite
 a big network byte ordered binary data. Although the data consists mainly

NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version).  It takes fancier macros to support
constants.  This gives an excuse to change the inline functions back to
macros :-).

 of bytes and 16- and 32-bit words, it is difficult in my case to use
 u_char, u_int16_t and u_int32_t, as the order and the number of each type
 does not fit to any possible C struct declaration.
 Well, I can just create a network ordered byte array C declaration like
 const unsigned char array[] = { byte0, byte1, ... };
 But for more efficient processing I would like to have something like
 const unsigned char array[] = {
 _4bytes(b0, b1, b2, b3)
 ... i.e. platform independent source code which would compile into
 platform dependent object file. _4bytes, _2shorts and _1long are macros
 produced for byte sequence in appropriate byte order. The macros need to
 know the platform byte order, theoretically it can be one of 1234, 4321,
 2143.

Theoretically there are 4! = 12 orders :-).

 In endian.h I can see just huge line of comparisons to *_386 et. al., but
 I cannot find any macros clearly decsribing the byte order. Am I wrong?

There are macros LITTLE_ENDIAN, BIG_ENDIAN and PDP_ENDIAN to indicate 3 of
the 12 possible orders.  You can write your own conversion macros for these
3 orders.  Other orders hopefully won't happen in practice.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



pkg_add -r broken

2000-10-27 Thread David O'Brien

Are others seeing that ``pkg_add -r foo'' is broken?

Core was generated by `pkg_add'.
Program terminated with signal 11, Segmentation fault.

(gdb) where
#0  0x280e2866 in strchr () from /usr/lib/libc.so.4
#1  0x28074d74 in fetchRestartCalls () from /usr/lib/libfetch.so.2
#2  0x280720d6 in fetchXGet () from /usr/lib/libfetch.so.2
#3  0x2807236c in fetchXGetURL () from /usr/lib/libfetch.so.2
#4  0x280723ab in fetchGetURL () from /usr/lib/libfetch.so.2
#5  0x804d050 in free ()
#6  0x8049a45 in free ()
#7  0x8049913 in free ()
#8  0x80497fe in free ()
#9  0x80493e1 in free ()


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Support for USB scanners in FreeBSD

2000-10-27 Thread Nick Hibma


FreeBSD now has preliminary support for USB scanners. You will need to
have SANE installed in order to use the uscanner driver. You can kldload
the uscanner driver.

Please do not contact me personally with questions on which scanner is
supported. You can get this information from

http://www.etla.net/~n_hibma/usb/uscanner-support.pl

If you have questions or would like to notify us of additional scanners
that work through the uscanner driver, please post them to the USB-BSD
mailing list available from

http://lists.inteltec.com/wws/info/usb-bsd

Cheers,

Nick
--
Qube Software, Ltd. Private:
[EMAIL PROTECTED]  [EMAIL PROTECTED]
 [EMAIL PROTECTED]
http://www.qubesoft.com/   http://www.etla.net/~n_hibma/




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: kernel build problem

2000-10-27 Thread David O'Brien

On Fri, Oct 27, 2000 at 11:43:04AM +0200, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Darren Reed writes
 :
 What failed ?  Do you have the make error output ?
 Did you try to compile LINT before you committed ?

Hell, forget LINT, just try GENERIC.

Darren, you really, really have a major problem importing new ipfilter
bits.  I cannot think of a single time you have not broken world.  What
can we do to help you prevent this in the future?  Do you compile a
GENERIC and/or LINT kernel before your change(s)?  Do you ``cvsup'' and
then test what actually got committed in a virgin src tree?

-- 
-- David  ([EMAIL PROTECTED])

P.S.
=== ipfilter
rm -f .depend
mkdep -f .depend -a   -nostdinc -DIPFILTER=1 -DIPFILTER_LKM -DIPFILTER_LOG -D_KERNEL 
-DKLD_MODULE -I- -I. -I@ -I@/../include
/usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_nat.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_frag.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_state.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_proxy.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_auth.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_log.c
/usr/src/sys/modules/ipfilter/../../netinet/ip_fil.c
/usr/src/sys/modules/ipfilter/../../netinet/fil.c
In file included from
/usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c:44: @/netinet/ip_compat.h:268: 
osreldate.h: No such file or directory
..snip..


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: kernel build problem

2000-10-27 Thread Darren Reed

In some email I received from David O'Brien, sie wrote:
 On Fri, Oct 27, 2000 at 11:43:04AM +0200, Poul-Henning Kamp wrote:
  In message [EMAIL PROTECTED], Darren Reed writes
  :
  What failed ?  Do you have the make error output ?
  Did you try to compile LINT before you committed ?
 
 Hell, forget LINT, just try GENERIC.
 
 Darren, you really, really have a major problem importing new ipfilter
 bits.  I cannot think of a single time you have not broken world.  What
 can we do to help you prevent this in the future?  Do you compile a
 GENERIC and/or LINT kernel before your change(s)?  Do you ``cvsup'' and
 then test what actually got committed in a virgin src tree?

I don't use cvsup (but may soon) as I have to pay for megabytes at the
moment.  I'm generally compiling/developing on -STABLE (in this case,
the imported code was compiling cleanly on 4.1-RELEASE) and generally
don't think that it'll be _that_ different.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



$BFMA3$N%a!<%k<:NiCW$7$^$9(B$B!#K\Ev$K$*F@$J>pJs$G$9!#(B

2000-10-27 Thread $B%5%/%;%9%+%s%Q%K!<(B
$B=i$a$^$7$F%5%/%;%9%+%s%Q%K!<$H?=$7$^$9!#(B
$BFMA3!"<:Ni$+$H;W$$$^$7$?$,0lEY$@$1$N%a!<%k$H8@$&$3$H$G!"$I$&$+$*5v$72<(B
$B$5$$!#(B
$B$3$N%a!<%k$,FO$$$?$3$H$,!"2?$+$N1o$@$H;W$C$FD:$1$l$P9,$$$G$9!#(B
$B6=L#$,L5$1$l$P!"$*O$G$9$,!"$7$C$+$jFI$s$GM}2r$7$F$/$@$5$$!#(B
$B$"$J$?$N?M@8$K$*$$$F0l$D$N%A%c%s%9$G$"$k$3$H$O!"4V0c$$$"$j$^$;$s!#(B

$B$3$N%a!<%k$rFI$b$&$H$7$F$$$k$"$J$?$O!"K\Ev$K6/1?$N;}$AR2p$7$^$9!#$3$N%S%8%M%9$O!">pJs$rGd$k$H(B
$B$$$&4JC1$G%j%9%/$b$J$/9b<}F~$,K>$a$k%S%8%M%9$G$9!#(B
$B;d$O?.Mj$G$-$kJ}$+$i$N>R2p$G$3$N%S%8%M%9$rCN$j$^$7$?!#(B
$B$b$A$m$s:G=i$OH>?.H>5?$G$7$?$,!"$9$0$K7k2L$,8=$l$F(B
$BDLD"$rKhF|8+$F$S$C$/$j$7$F$$$^$9!#(B
$BFbMF$r$7$C$+$j8+$F$$$?$@$1$?$i!"$d$i$J$$$h$j$d$C$?J}$,$3$H$,(B
$B$o$+$k$H;W$$$^$9!#@'Hs;O$a$F$_$F$/$@$5$$!#(B
**

$B!!(B  $B#E%a!<%k$rAw$C$FI{<}F~#1#8#0#0K|1_$r2T$0!*!*!*(B

**
$B#E%a!<%k$rAw$k$3$H$K$h$C$F!":#$+$i#2!"#3%v7n8e$K$O#2#0#0K|0J>e$NI{(B
$B<}F~$rF@$k$3$H$,$G$-$k!"L5M}$@$H;W$$$^$9$+!)!!>\:Y$r$*FI$_$/$@$5$$!#(B

-

$B!V:G6aJ|Aw$5$l$?%"%a%j%+$N%F%l%SHVAH$+$i!W(B

$B$3$N%a!<%k$K$D$$$F!":rG/=U:"!"El5~#1#2%A%c%s%M%k$N%K%e!<%9$GCN$C$?J}$b(B
$B$"$k$+$HB8$8$^$9!#(B

$B%$%s%?!<%M%C%H>e$G?M5$$,9b$^$k$K=>$$!"%"%a%j%+$G$bA49q%M%C%H$NLk$N%K%e(B
$B!<%9HVAH$GFC=8$rAH$_!"$3$l$GK\Ev$K$*6b$,LY$+$k$+$I$&$+$K$D$$$F!":G6a!"(B
$BD4::$7$^$7$?!#(B

$B$3$NHVAH$G$O!"$3$N$*6bLY$17W2h$,9gK!$+$I$&$+$K$D$$$F$bD4::$7$^$7$?!#(B
$BD4::$N7k2L!"$3$N7W2h$K;22C$9$k$3$H$r6X$8$kK!N'$O$^$C$?$/$J$$$3$H$,H=L@(B
$B$7$^$7$?!#(B
$B$3$NHVAH$N$*$+$2$G!"$3$N7W2h$O!"4JC1$+$DL532$J!"$*$b$7$m$$:_BpI{<}(B
$BF~3MF@K!$G$"$k$3$H$,$o$+$j$^$7$?!#(B

$B$3$NHVAH$,$b$?$i$7$?7k2L$Oo$KB?$/$N3'$5$s$,;22C$5$l$k$h$&$K$J$j!"0JA0$KA}$7$F3hF0$,$O$k$+$K@9(B
$B$s$K$J$j$^$7$?!#(B

$B$h$jB?$/$N?M$,;22C$9$k$K=>$$!"F@$i$l$k6b3[$,$=$l$K$D$l$FBg$-$/$J$j$^$9(B
$B$+$i!":G6a;22C$7$??M$O$H$F$b%(%-%5%$%F%#%s%0$J7P83$r$5$l$F$$$^$9!#(B

$B$"$J$?$b0lEY;22C$5$l$l$P!"$*$o$+$j$K$J$k$G$7$g$&!#(B

$B%5%/%;%9%+%s%Q%K!&6H2=$rLH$l$?9-9p$N?M$?$A$,$I$s$I$s#E%a!<%k$r;H$C$F%S%8%M%9$r;O(B
$B$a$^$9!#$3$l$r9TF0$K0\$7$F$/$@$5$$!#(B


$BB?CJ<0%^!<%1%F%#%s%0!J#M#L#M!K$O$D$$$Ke$G=R$Y$?$H$3$m$K$h$l$P!"(B1990$BG/BeKv$^(B
$B$G$K$O!"A4>!&%5!<%S%9$N#5#0!<#6#0!s$,B?CJJ}<0$K$h$C$FHNGd$5$l$k$h(B
$B$&$K$J$k!#(B
$B$3$l$O?t==2/%I%k5,LO$N;:6H$G$"$j!"%"%a%j%+$K$*$$$F2a5n?tG/4V$K%_%j%*%M(B
$B%"!<$H$J$C$?#5#0K|?MCf!"#2#0!s$KAjEv$9$k#1#0K|?M$,B?CJ<0(B
$B%^!<%1%F%#%s%0$K$h$C$F:b$r@.$7!"$5$i$K!"E}7W$K$h$k$H!"B?CJ<0%^!<%1%F%#(B
$B%s%0$K$h$j!"KhF|#4#5?M$N%_%j%*%M%"!<$,CB@8$7$F$$$^$9!#(B

$B$J%I%J%k%I(B
$B%H%i%s%W;a!J2/K|D9$9$3$H$K$J$C$?$i!"$I$&$9(B
$B$k(B
$B$Hl$K$$$?D0=0$O!"AaB.!"%V!<%$%s%0$7$FH`$rHsFq$7(B
$B$^$7$?!#$9$k$H!"H`$OD0=0$r8+EO$7!"??LLL\$J4i$G$3$&8@$$$^$7$?!#(B
$B!V$@$+$i;d$O$3$N$H$*$j!J%2%9%H$H$7$F!K$3$A$i$K:B$j!"$"$J$?J}$O!JD0=0$H(B
$B$7$F!K3'$=$C$A$NJ}$K:B$C$F$$$k$N$G$9$h!*!W(B

$B%M%C%H%o!<%/%^!<%1%F%#%s%0$K$*$$$F$O!"#2DL$j$N<}F~$,$"$j$^$9!#$"$J$?<+(B
$B?H$N%;!<%k%9$K$h$kD>@\%3%_%C%7%g%s$H$"$J$?$,>R2p$7$??M$N%;!<%k%9$+$i@8(B
$B$8$k%3%_%C%7%g%s$G$9!#(B

$B;DB8<}F~!"$3$l$3$=$,$*6b;}$A$NHkL)$G$9!#$D$^$j!";~4V$H$*6b$r0lEYEj;q$9(B
$B$k$3$H$K$h$j!"Js=7$r7+$jJV$72?EY$b2?EY$bF@$k$H$$$&$3$H$G$9!#%M%C%H%o!<(B
$B%/%^!<%1%F%#%s%0$K$*$$$F$O!"B>$N?M$,$7$?;E;v$KBP$7$FJs=7$,;YJ'$o$l$k$H(B
$B$$$&$3$H$b0UL#$7$^$9!#(B

$B$?$@!"$3$A$i$+$i$*EO$7$9$k7G<(HD%j%9%H$K=q$-9~$s$G$$$/$@$1$G$N$G$9(B

$B=q$-9~$_Be9T6Hl9g%S%8%M%9$N3+;O$+$i#1=54V$G#1#0?M$N%Q!<%H%J!<$rF@$k$3$H$,=PMh$^(B
$B$7$?!#(B
$B$^$5$K!"%P%i?'$N?M@8$KBgJQ?H$G$9!#(B


$B0J2<$,!"$3$N6C$/$Y$-:_BpI{<}F~3MF@K!$N%O%&%D!<$G$9!'(B

$B!c!c!c!a!a!a!!!V@bL@=q!W$N;O$a(B


$B!c!c!c!!@bL@=q!!!d!d!d(B

$B$3$N;q6b3MF@K!$Oe$NGc$$J*$r$7(B
$B$F$$$k$3$H$G$7$g$&!#!V$=$s$J$P$+$J!*!W$H$*$C$7$c$kA0$K!"$3$N%W%m%0%i%`(B
$B$r(B
$B$h$/$*FI$_$/$@$5$$!#$3$l$O%A%'!<%s%l%?!<$G$O$"$j$^$;$s!#40A4$K9gK!$J:_(B

Re: kernel build problem

2000-10-27 Thread David O'Brien

On Fri, Oct 27, 2000 at 10:46:24PM +1100, Darren Reed wrote:
 I'm generally compiling/developing on -STABLE (in this case, the
 imported code was compiling cleanly on 4.1-RELEASE) and generally don't
 think that it'll be _that_ different.

In all seriousness, the farther down the 4.x branch we get, the
divergence between -STABLE and -CURRENT gets *quite* different.  This is
unfortunate, but until we do major paid release engineering, many things
are MFC'ed that really could/should be to reduce the differences.
 
-- 
-- David  ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Ruslan Ermilov

On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
[...]
 
 NetBSD supports the ntohl family on constants, but only on some arches
 (at least in last year's version).  It takes fancier macros to support
 constants.  This gives an excuse to change the inline functions back to
 macros :-).
 
Cool!  My upcoming byte-swapping changes to IPv4 code would benefit from
having these macros.  Could you please review the attached patch (it was
obtained from NetBSD)?

PS
BTW, converting from macros to inline functions slightly broke the things.
It is currently impossible to simply include the machine/endian.h, since
it now depends on sys/inttypes.h.
/PS

-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


Index: endian.h
===
RCS file: /home/ncvs/src/sys/i386/include/endian.h,v
retrieving revision 1.21
diff -u -p -r1.21 endian.h
--- endian.h2000/10/16 17:06:48 1.21
+++ endian.h2000/10/27 13:03:55
@@ -69,7 +69,7 @@ __END_DECLS
 #ifdef __GNUC__
 
 static __inline uint32_t
-__uint16_swap_uint32(uint32_t __x)
+__uint16_swap_uint32_variable(uint32_t __x)
 {
__asm ("rorl $16, %1" : "=r" (__x) : "0" (__x));
 
@@ -77,7 +77,7 @@ __uint16_swap_uint32(uint32_t __x)
 }
 
 static __inline uint32_t
-__uint8_swap_uint32(uint32_t __x)
+__uint8_swap_uint32_variable(uint32_t __x)
 {
 #if defined(_KERNEL)  (defined(I486_CPU) || defined(I586_CPU) || defined(I686_CPU)) 
 !defined(I386_CPU)
__asm ("bswap %0" : "=r" (__x) : "0" (__x));
@@ -89,12 +89,36 @@ __uint8_swap_uint32(uint32_t __x)
 }
 
 static __inline uint16_t
-__uint8_swap_uint16(uint16_t __x)
+__uint8_swap_uint16_variable(uint16_t __x)
 {
__asm ("xchgb %h1, %b1" : "=q" (__x) : "0" (__x));
 
return __x;
 }
+
+#ifdef __OPTIMIZE__
+
+#define__uint8_swap_uint32_constant(x) \
+   x)  0xff00)  24) | \
+(((x)  0x00ff)   8) | \
+(((x)  0xff00)   8) | \
+(((x)  0x00ff)  24))
+#define__uint8_swap_uint16_constant(x) \
+   x)  0xff00)  8) | \
+(((x)  0x00ff)  8))
+#define__uint8_swap_uint32(x) \
+   (__builtin_constant_p((x)) ? \
+__uint8_swap_uint32_constant(x) : __uint8_swap_uint32_variable(x))
+#define__uint8_swap_uint16(x) \
+   (__builtin_constant_p((x)) ? \
+__uint8_swap_uint16_constant(x) : __uint8_swap_uint16_variable(x))
+
+#else /* __OPTIMIZE__ */
+
+#define__uint8_swap_uint32(x)  __uint8_swap_uint32_variable(x)
+#define__uint8_swap_uint16(x)  __uint8_swap_uint16_variable(x)
+
+#endif /* __OPTIMIZE__ */
 
 /*
  * Macros for network/external number representation conversion.



Re: endian.h problem with gnats port

2000-10-27 Thread Paul Traina

Looks good to me. Sorry for the hassles.  I'll make sure the upstream release
gets an extra #include in GNATS v4.

On Fri, Oct 27, 2000 at 03:46:55AM -0700, Doug Barton wrote:
 Harti Brandt wrote:
  
  On Fri, 27 Oct 2000, Doug Barton wrote:
  
 I'm trying to compile gnats locally, and getting an ugly error
   regarding endian.h. Due to the recent include file shuffling I'm
   starting in -current rather than ports.
  
   cc -c -I. -I. -I./../include  -O -ggdb -pipe -g  -DHAVE_CONFIG_H
   queue-pr.c
   In file included from /usr/include/sys/wait.h:93,
from queue-pr.c:23:
  
  sys/wait.h now needs sys/types.h.
  
  That's documented. Many ports break also.
 
   Bah... I knew it was something like this and I just couldn't remember
 the voodoo. Attached patch gets the port built, and a quick pass through
 edit-pr and query-pr seem to DTRT.
 
 Thanks,
 
 Doug
 -- 
 "The dead cannot be seduced."
   - Kai, "Lexx"
 
   Do YOU Yahoo!?
 Index: Makefile
 ===
 RCS file: /usr/ncvs/ports/databases/gnats/Makefile,v
 retrieving revision 1.32
 diff -u -r1.32 Makefile
 --- Makefile  2000/10/08 10:19:23 1.32
 +++ Makefile  2000/10/27 10:34:49
 @@ -22,7 +22,6 @@
   --with-release-based
  
  USE_GMAKE=   yes
 -USE_BISON=   yes
  MAN1=edit-pr.1 query-pr.1 send-pr.1
  MAN7=gnats.7
  MAN8=mkcat.8 rmcat.8 mkdist.8 queue-pr.8 file-pr.8 gen-index.8
 Index: files/patch-ae
 ===
 RCS file: patch-ae
 diff -N patch-ae
 --- /dev/null Fri Oct 27 03:41:59 2000
 +++ patch-ae  Fri Oct 27 03:39:51 2000
 @@ -0,0 +1,10 @@
 +--- gnats/queue-pr.c.DistWed Nov 25 06:15:20 1998
  gnats/queue-pr.c Fri Oct 27 03:37:29 2000
 +@@ -20,6 +20,7 @@
 + 
 + #include "config.h"
 + 
 ++#include sys/types.h
 + #include sys/wait.h /* FIXME */
 + #include sys/param.h /* FIXME: gets MAXBSIZE */
 + 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Support for USB scanners in FreeBSD

2000-10-27 Thread Nick Hibma


Grmbl... Alan Clegg reported that the URL is not working. Not that there
is much to see yet, but the correct URL should be:

http://www.etla.net/~n_hibma/usb/uscanner-supported.pl

Sorry about that.

Nick

 
 FreeBSD now has preliminary support for USB scanners. You will need to
 have SANE installed in order to use the uscanner driver. You can kldload
 the uscanner driver.
 
 Please do not contact me personally with questions on which scanner is
 supported. You can get this information from
 
   http://www.etla.net/~n_hibma/usb/uscanner-support.pl
 
 If you have questions or would like to notify us of additional scanners
 that work through the uscanner driver, please post them to the USB-BSD
 mailing list available from
 
   http://lists.inteltec.com/wws/info/usb-bsd
 
 Cheers,
 
 Nick
 --
 Qube Software, Ltd. Private:
 [EMAIL PROTECTED]  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
 http://www.qubesoft.com/   http://www.etla.net/~n_hibma/
 
 
 

--
Qube Software, Ltd. Private:
[EMAIL PROTECTED]  [EMAIL PROTECTED]
 [EMAIL PROTECTED]
http://www.qubesoft.com/   http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



/dev/random related mouse jerkiness is again here

2000-10-27 Thread Maxim Sobolev

Hi,

I wonder if anyone noticed that mouse jerkiness caused by entropy harvesting
routine is here again (both in syscons and X11), although it was expected to be
solved by kthreads, at least on my poor old P133 with PS/2 mouse.

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Handspring Visor / USB cradle / HotSync

2000-10-27 Thread Sascha Luck

Hi all,

with regard to PR kern/17961, I've recently come across the following:

If Coldsync is called with the -p /dev/ugen0 argument (as described in
the problem report), it still crashes the system with a Trap 12.

However, if a global coldsyncrc in /usr/local/etc/coldsync.rc is
created:

listen usb {
device: "/dev/ugen0";
} 

and coldsync is called w/o arguments (after pressing the hotsync button
to create /dev/ugen0)
it works and syncs just fine :o)

FreeBSD: 5.0-CURRENT, Fri, Oct 20
ColdSync: coldsync version 1.4.6 (ports version)

Hope that's good news for someone :)

Regards,
Sascha


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Mike Smith

 On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
 [...]
  
  NetBSD supports the ntohl family on constants, but only on some arches
  (at least in last year's version).  It takes fancier macros to support
  constants.  This gives an excuse to change the inline functions back to
  macros :-).
  
 Cool!  My upcoming byte-swapping changes to IPv4 code would benefit from
 having these macros.  Could you please review the attached patch (it was
 obtained from NetBSD)?
...
 +#ifdef __OPTIMIZE__

Using macros does not "optimise" anything, and this is a very poor choice 
of defines.  __MACRO_ENDIAN_CONVERSIONS might be better.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Ruslan Ermilov

On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
  On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
  [...]
   
   NetBSD supports the ntohl family on constants, but only on some arches
   (at least in last year's version).  It takes fancier macros to support
   constants.  This gives an excuse to change the inline functions back to
   macros :-).
   
  Cool!  My upcoming byte-swapping changes to IPv4 code would benefit from
  having these macros.  Could you please review the attached patch (it was
  obtained from NetBSD)?
 ...
  +#ifdef __OPTIMIZE__
 
 Using macros does not "optimise" anything, and this is a very poor choice 
 of defines.  __MACRO_ENDIAN_CONVERSIONS might be better.
 
Huh, you would not call this optimization?!

#include sys/types.h
#include stdio.h

void
foo(void)
{
printf("%hx\n", htons(0x80));
}

--- a.s.without Fri Oct 27 18:11:26 2000
+++ a.s.withFri Oct 27 18:11:59 2000
@@ -13,12 +13,7 @@
movl %esp,%ebp
subl $8,%esp
addl $-8,%esp
-   movl $128,%eax
-#APP
-   xchgb %ah, %al
-#NO_APP
-   andl $65535,%eax
-   pushl %eax
+   pushl $32768
pushl $.LC0
call printf
leave


-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Ruslan Ermilov

On Fri, Oct 27, 2000 at 06:11:49PM +0300, Ruslan Ermilov wrote:
 On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
   On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
   [...]

NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version).  It takes fancier macros to support
constants.  This gives an excuse to change the inline functions back to
macros :-).

   Cool!  My upcoming byte-swapping changes to IPv4 code would benefit from
   having these macros.  Could you please review the attached patch (it was
   obtained from NetBSD)?
  ...
   +#ifdef __OPTIMIZE__
  
  Using macros does not "optimise" anything, and this is a very poor choice 
  of defines.  __MACRO_ENDIAN_CONVERSIONS might be better.
  
 Huh, you would not call this optimization?!
 
Just thought that you raised another issue here, the choice of __OPTIMIZE__.
If that's the case, it is the GCC's define used to indicate the optimizing
compilation:

# cpp -O -dM /dev/null
#define __FreeBSD__ 4
#define __FreeBSD_cc_version 41
#define __i386__ 1
#define __i386 1
#define i386 1
#define __OPTIMIZE__ 1
#define __unix 1
#define __unix__ 1
#define __ELF__ 1
#define unix 1


-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Support for USB scanners in FreeBSD

2000-10-27 Thread Daniel O'Connor

Nick Hibma wrote:

 Please do not contact me personally with questions on which scanner is
 supported. You can get this information from
 
 http://www.etla.net/~n_hibma/usb/uscanner-support.pl

404 - here is the correct URL -
   http://www.etla.net/~n_hibma/usb/uscanner-supported.pl 

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: $B$O$8$a$^$7$F!#(B

2000-10-27 Thread Jan Knepper

Jun Kuriyama wrote:

 At 26 Oct 2000 20:37:48 GMT,
 Rogier R. Mulhuijzen [EMAIL PROTECTED] wrote:
  Does this look like english to anyone and is my mailer messed, or is this
  gobbledegook to anyone not using Outlook + japanese character set?

 That is spam like a "get money fast!" written in Japanese.  That is
 not related to FreeBSD so please ignore.

grin
Thanks for clearing that up. My Japanese is kinda rusty you know...

By the way, is anyone reporting theise things?

Don't worry, be Kneppie!
Jan



--
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.

http://www.smartsoft.cc/
http://www.mp3.com/pianoprincess

Phone : 609-628-4260
FAX   : 609-628-1267
FAX   : 303-845-6415 http://www.fax4free.com/

Phone : 020-873-3837 http://www.xoip.nl/ (Dutch)
FAX   : 020-873-3837 http://www.xoip.nl/ (Dutch)

In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: AMD broken in -current?

2000-10-27 Thread Jordan Hubbard

 On Thu, Oct 26, 2000 at 09:04:45PM -0700, Jordan Hubbard wrote:
  It use to work in early October, but now I get the following using
  the stock (/etc/defaults/rc.conf) amd flags:
 
 It works on my Oct 22nd world.

OK, so maybe it broke even later.  What does it do on your
Oct 27th world? :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /dev/random related mouse jerkiness is again here

2000-10-27 Thread Mark Murray

 I wonder if anyone noticed that mouse jerkiness caused by entropy
 harvesting routine is here again (both in syscons and X11), although
 it was expected to be solved by kthreads, at least on my poor old P133
 with PS/2 mouse.

You say "here again". Was there a time that it went away with kthreads?

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /dev/random related mouse jerkiness is again here

2000-10-27 Thread Rogier R. Mulhuijzen

At 10:07 27-10-00 -0700, you wrote:
  I wonder if anyone noticed that mouse jerkiness caused by entropy
  harvesting routine is here again (both in syscons and X11), although
  it was expected to be solved by kthreads, at least on my poor old P133
  with PS/2 mouse.

You say "here again". Was there a time that it went away with kthreads?

I had mouse jerkiness at the same time as I had the sound glitches. Those 
were explained as a result of SMPNG IRQ latency (IIRC). Could this be the 
same problem?

 DocWilco



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



VCD

2000-10-27 Thread ii1254hd

$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B"#"#"#%"%8%"H/!*!*!VF|K\?M#A#V=wM%=P1i!*N"#V#C#D9XF~J}!W$N$40FFb"#"#"#(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B"""#$O$8$a$K"#""(B
$B$3$N%a!<%k$O!">e5-%?%$%H%k$N!VF|K\?M#A#V=wM%=P1i!*N"#V#C#D9XF~J}!W$r0F(B
$BFb$9$k%a!<%k$G$9!#62=L$G$9$,6=L#$N$J$$J}$O!"$3$N%a!<%k$r:o=|$7$F$/$@$5(B
$B$$!#?<$/$*OM$S$$$?$7$^$9!#(B

$B"""#@bL@"#""(B
$B%"%8%"=t9q$G$O!"F|K\?M$N7]G=?M$d%F%l%SHVAH$N?M5$$,9b$$$3$H$OM-L>$G$9!#(B
$BF1MM$KF|K\@=$N%"%@%k%H%S%G%*$bBgJQ9b$$?M5$$,M-$j!"F|K\F1MM$KN"%S%G%*$N(B
$BCO2<;T>l$bB8:_$7$^$9!#$?$@!"F|K\$H0c$@$O(BMPEG$BJ}<0$N%S%G%*(BCD(VCD$B!KJ}<0(B
$B$GN.DL$7$F$$$kE@$H!"Cx:n8"$d>SA|8"$,L$@0Hw$J$?$a$+!"F|K\$NCO2<;T>l$G$O(B
$BN.=P$7$F$$$J$$!"?M5$#A#V>n$N:nIJ$,?tB?$/N.DL$7$F$$$k=j$G$9!#(B

$B!z!zFCJs!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B
$BBg9%I>$NF|K\;T>lL$N.=P$N!V6bBtJ8;R!W!V>.Bt$^$I$+!W!VGr@P$R$H$_!W$K2C$((B
$B?7$?$K!V@nEgOBDEH~!W!V0*$_$N$j!W!VM<l$OCx:n8"$d>SA|8"$J$I4X78$J$$L5K!COBS$G$9!#(B
$B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B

$B"#"#:nIJ>R2p"#"#(B

$B!|Gr@PE*M6OG!|!|=P1i!!Gr@P$R$H$_!|!!(B42$BJ,(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B!!$3$N:nIJ$O!"$4$/:G6a$K$J$C$F#V#H#S%F!<%W$GF|K\;T>l$K$bN.DL$7$@$7$?$h(B
$B$&$G$9!#%"%8%";T>l$G$O$+$J$jA0$+$iN.DL$7$F$^$7$?!#;DG0$J$,$i56;wK\HV$G(B
$B$9$,!"%P%C%A%j4]8+$($G$9!#%U%!%s$J$i(BCD-ROM$B$G1J5WJ]B8$7$^$7$g$&!#!!(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B!|Nx0*8l!|!!!|=P1i!!@nEgOBDEH~!|!!(B35$BJ,(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B$J$s$H!*@nEgOBDEH~$G$9$h!#8+$D$1$?$H$-$O!"46F0$7$^$7$?!#$d$O$jE];:#A#V(B
$B%a!<%+!<$NN.=P$G$7$g$&$+!)=w;R9b@8J*$G#3#P$d%l%$%W$b$"$j!"$+$J$j%O!<%I(B
$B$JFbMF$G$9!#$5$F!"56;wK\HV$+??@-K\HV$+$O8+$F$N$*3Z$7$_!&!&!&!&!&!!(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B!|F15i@8=iBN83!|!!!|=P1i!!6bBtJ8;R!!>.Bt$^$I$+!|(B40$BJ,(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B?M5$%"%$%I%k#A#V=wM%$N6%1i:n$G$O$J$/$F!"#2:nIJ$rJT=8$7$?:nIJ$G$9!#$G$9(B
$B$,!"$=$l$>$l$*$$$7$$=j$I$j$G$*F@$J:nIJ$G$9!#$"$^$j%O!<%I$JFbMF$G$O$J$$(B
$B$G$9$,!"8+$($k$H$3$m$OEvA3$h$/8+$($k1J5WJ]B8HG$G$7$g$&!#!!(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B!|K=0|!|!!!|=P1i!!M<e5-$N$h$&$J(B
$B8=>]$K$J$j$^$9!#5pF}4G8nIX$N%Q%$%:%j<#NE$,$b$A$m$s4]8+$(>uBV$G$9!#(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B!|E=?HA4MgE7;H!|!!!|=P1i!!HSEg0&!!>.NS$R$H$_!!9bAR5.H~;R!|!!(B41$BJ,(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B#3?M$H$b0l@NA0$N?M5$=wM%$5$s$G$9!#6%1i:n$G$O$J$/!"$*$$$7$$$H$3$I$j$N%*(B

Re: AMD broken in -current?

2000-10-27 Thread David O'Brien

On Fri, Oct 27, 2000 at 09:34:07AM -0700, Jordan Hubbard wrote:
  On Thu, Oct 26, 2000 at 09:04:45PM -0700, Jordan Hubbard wrote:
   It use to work in early October, but now I get the following using
   the stock (/etc/defaults/rc.conf) amd flags:
  
  It works on my Oct 22nd world.
 
 OK, so maybe it broke even later.  What does it do on your
 Oct 27th world? :)

On a 4.5hr old world (I need more sleep), it also works fine.

-- David


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Mike Smith

 On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
   On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
   [...]

NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version).  It takes fancier macros to support
constants.  This gives an excuse to change the inline functions back to
macros :-).

   Cool!  My upcoming byte-swapping changes to IPv4 code would benefit from
   having these macros.  Could you please review the attached patch (it was
   obtained from NetBSD)?
  ...
   +#ifdef __OPTIMIZE__
  
  Using macros does not "optimise" anything, and this is a very poor choice 
  of defines.  __MACRO_ENDIAN_CONVERSIONS might be better.
  
 Huh, you would not call this optimization?!

No, since it is incapable of dealing with a non-constant argument.

 #include sys/types.h
 #include stdio.h
 
 void
 foo(void)
 {
   printf("%hx\n", htons(0x80));
 }
 
 --- a.s.without   Fri Oct 27 18:11:26 2000
 +++ a.s.with  Fri Oct 27 18:11:59 2000
 @@ -13,12 +13,7 @@
   movl %esp,%ebp
   subl $8,%esp
   addl $-8,%esp
 - movl $128,%eax
 -#APP
 - xchgb %ah, %al
 -#NO_APP
 - andl $65535,%eax
 - pushl %eax
 + pushl $32768
   pushl $.LC0
   call printf
   leave

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: ipfw question.

2000-10-27 Thread Terry Lambert

 I've also sent out numerous appeals to the various mailing lists for
 someone, anyone, to come up with something better than sysinstall
 which was somehow less grandiose than my own follow-on designs or,
 failing that, to significantly revamp sysinstall itself.  The fact
 that nobody has stepped up to the plate has, I feel, nothing to do
 with vaporware, it has to do with certain problems simply being icky
 and unpleasant to deal with.  If such was not the case, you'd think
 one of the other *BSDs would have done it if not us.
 
 Let's also not forget that Caldera had to PAY Trolltech to do their
 fancy installer and then Red Hat came along and substantially pinched
 off of that one, so even the vastly better-funded and staffed Linux
 projects haven't really managed to crack the nut just on volunteer
 labor alone.

FWIW:

I know someone who is willing to substantially revise the install
process, BUT:

1)  They will want to keep it proprietary for commercial
use for a period of at least a year, and that would
mean probably keeping it out of the official source
tree for that period of time.  As you note, it is icky
and unpleasent to deal with, and they will expect to
recoup their investment.

2)  They will want to call their stuff FreeBSD, but that
has historically been vetoed, unless the installation
images are exactly the same as what you can download
of the net or buy from Walnut Creek.  During that year,
they wouldn't be.

Obviously, #1 would potentially cannibalize the WC CDROM market
for FreeBSD CDROMs, assuming they do a decent job of things.

Obviously, #2 means that they people willing to do the work
are interested in a "RedHat FreeBSD"-like play, which may not
be in everyones interest.

As I said: FWIW.

Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: entropy reseeding is totally broken

2000-10-27 Thread Doug Barton

Terry Lambert wrote:
 
   This is sweet!  Seems it would give us the full benefits of Mark's
   randomdev, and fit nicely with our normal configuration framework and
   gives good flexibility.
 
It also describes just what we have currently, except it misses the
  advantages of putting the entropy file on the root partition which makes
  it available immediately, and doesn't have mounting races built in.
 
 What currently exists does not allow a read-only /.  Which sucks.

Please keep a couple things in mind. First, there is no one solution
that is going to suit everyone. It's exactly because my /var is not on /
that I got interested in patching the current implementation of "save
some randomness at boot and read it back in at startup" in the first
place. I kept read-only and diskless / cases in mind when I tied my idea
into the existing ability to specify the file AND used /var as a
failsafe. 

Second, Mark has always intended and is currently working on ways to
make entropy harvesting happen in the boot phase. No one expected, or
represented this file-based method as the ultimate solution. 

Third, Schneier's paper suggests loading a file of written-out entropy
at boot as an additional reseeding source, so we need to work out the
store a file across boot in any case. It's entirely possible that this
won't work for some edge cases, but harvesting entropy in the boot
process will help alleviate that. Finding answers to the current
problems will be easier if we keep the goals clear. 

Doug
-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: platform byte order macros?

2000-10-27 Thread Bruce Evans

On Fri, 27 Oct 2000, Ruslan Ermilov wrote:

 On Fri, Oct 27, 2000 at 06:11:49PM +0300, Ruslan Ermilov wrote:
  On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
+#ifdef __OPTIMIZE__
   
   Using macros does not "optimise" anything,

Not quite true.  Using inline functions pessimizes everything that is
compiled without -O since the functions don't get inlined but code
for them is generated in each object file whether or not they are
used.  sys/types.h is included a lot, so having inline functions in
it is especially pessimal for the -O0 case.

 and this is a very poor choice 
   of defines.  __MACRO_ENDIAN_CONVERSIONS might be better.

__OPTIMIZE__ is the standard gcc macro for telling whether gcc has been
invoked with -O.  It is used sort of backwards here.  There is no reason
to turn off the macros for constants, but turning off the inlines for
non-constants would fix the useless bloat in the -O0 case.

Is the htonl() family used enough on constants for the constant case to
be worth optimizing?

Writing the byte swapping using shifts and masks might be best in all
cases.  The compiler can in theory reduce shifts and masks to bswap on
i386's if that is best, but it can't look inside asm statements.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message