Re: ipfw question.
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?
-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.
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
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
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
-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?
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
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
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
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
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
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
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?
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
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
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
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
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
$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;}$A R2p$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$$$K e$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$H l$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~$_Be9T6H l9g%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
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?
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
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
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
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
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?
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?
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?
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
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
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?
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
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
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
$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?
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?
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.
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
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?
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