Re: [PATCH] Unbreak makefs -M
On Thu, Sep 11, 2014 at 7:26 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano dav...@freebsd.org wrote: r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts-avgfpdir == -1) ffs_opts-avgfpdir = AFPDIR; - if (roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) + if (fsopts-maxsize 0 +roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) - Should roundup be used with fsopts-maxsize) ? No. Maxsize is a hard limit, while minsize is always rounded up to at least the bsize. If you attempt to specify an improperly-rounded quantity as both the minimum and the maximum (for instance, because the bsize makefs decides to use has increased between executions), you'll always produce an image which is too large. That's exactly what this check was added to catch (and make less obtuse.) - style(9): put the `` on the previous line. errx(1, `%s' minsize of %lld rounded up to ffs bsize of %d exceeds maxsize %lld. Lower bsize, or round the minimum and maximum sizes to bsize., dir, This (and the other rev) should really be pushed back to NetBSD.. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk
On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd adr...@freebsd.org wrote:
.. not that I mind old things being retired, but we really should
announce things like this.
Also - you disconnected libftpio too; is that intentional?
I would assume so, given that this only removed the static library
name, which nothing else could be using still, seeing as how the
library was disconnected and removed in r225952.
Just because libdisk/libftpio isn't used by anything in the base -HEAD
doesn't mean that:
* it's not used by third party programs in ports;
* it's not used by any external, non open source utilities that people
have read.
So I'd suggest creating a port for them both and begin the process of
deprecating the kernel side interfaces that are unique to this API.
Pretty sure the addition of and widespread use of GEOM things
initiated the deprecation of the really lousy and properly-disliked
kernel interfaces involved.
On 30 December 2012 08:28, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
Author: nwhitehorn
Date: Sun Dec 30 16:28:06 2012
New Revision: 244865
URL: http://svnweb.freebsd.org/changeset/base/244865
Log:
With the old sade removed, libdisk is no longer used by anything in HEAD
and uses a number of problematic pre-gpart interfaces. Since it has been
entirely obsoleted by interfaces in geom, remove it.
Deleted:
head/lib/libdisk/
Modified:
head/ObsoleteFiles.inc
head/lib/Makefile
head/share/mk/bsd.libnames.mk
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Sun Dec 30 15:38:06 2012(r244864)
+++ head/ObsoleteFiles.inc Sun Dec 30 16:28:06 2012(r244865)
@@ -38,6 +38,9 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20121230: libdisk removed
+OLD_FILES+=usr/share/man/man3/libdisk.3.gz usr/include/libdisk.h
+OLD_FILES+=usr/lib/libdisk.a usr/lib32/libdisk.a
# 20121230: remove wrongly created directories for auditdistd
OLD_DIRS+=var/dist
OLD_DIRS+=var/remote
Modified: head/lib/Makefile
==
--- head/lib/Makefile Sun Dec 30 15:38:06 2012(r244864)
+++ head/lib/Makefile Sun Dec 30 16:28:06 2012(r244865)
@@ -69,7 +69,6 @@ SUBDIR= ${SUBDIR_ORDERED} \
libcompat \
libdevinfo \
libdevstat \
- libdisk \
libdwarf \
libedit \
${_libefi} \
Modified: head/share/mk/bsd.libnames.mk
==
--- head/share/mk/bsd.libnames.mk Sun Dec 30 15:38:06 2012
(r244864)
+++ head/share/mk/bsd.libnames.mk Sun Dec 30 16:28:06 2012
(r244865)
@@ -45,7 +45,6 @@ LIBCURSES?= ${DESTDIR}${LIBDIR}/libcurse
LIBDEVINFO?= ${DESTDIR}${LIBDIR}/libdevinfo.a
LIBDEVSTAT?= ${DESTDIR}${LIBDIR}/libdevstat.a
LIBDIALOG?=${DESTDIR}${LIBDIR}/libdialog.a
-LIBDISK?= ${DESTDIR}${LIBDIR}/libdisk.a
LIBDNS?= ${DESTDIR}${LIBDIR}/libdns.a
LIBDTRACE?=${DESTDIR}${LIBDIR}/libdtrace.a
LIBDWARF?= ${DESTDIR}${LIBDIR}/libdwarf.a
@@ -54,7 +53,6 @@ LIBELF?= ${DESTDIR}${LIBDIR}/libelf.a
LIBFETCH?= ${DESTDIR}${LIBDIR}/libfetch.a
LIBFL?=don't use LIBFL, use LIBL
LIBFORM?= ${DESTDIR}${LIBDIR}/libform.a
-LIBFTPIO?= ${DESTDIR}${LIBDIR}/libftpio.a
LIBG2C?= ${DESTDIR}${LIBDIR}/libg2c.a
LIBGCC?= ${DESTDIR}${LIBDIR}/libgcc.a
LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
There is a known problem with MIPS tinderbox.
On Thu, Apr 5, 2012 at 12:28, Doug Barton do...@freebsd.org wrote: But as always, if someone comes up with an actual problem related to the [BIND] update I'm happy to address it. The MIPS tinderbox build is currently broken. This is related to a binutils bug for which a workaround was committed to head. For some reason, the workaround seems to be sufficient for universe done independently, but not the tinderbox. There is a fix for binutils which is known, but the fix was made after the GPLv3 switch. HJ Lu, who made the change, has been contacted about making the change available under GPLv2, but so far has not replied. Independently, jchandra@ is investigating the problem in binutils and attempting to come up with a fix from scratch. You have not broken the MIPS tinderbox. It has been broken for a couple of weeks now, and is a known problem, and hopefully will be fixed soon. Thanks, Juli. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on mips/mips
On Thu, Mar 22, 2012 at 14:39, Stanislav Sedov s...@freebsd.org wrote: Hi! This is due to the bug in binutils which we're working on fixing in base binutils. I added a workaround to the libkafs5 Makefile, but tinderbox is using a deprecated TARGET_ARCH=mips which does not enable that workaround. Should we switch tinderbox to use mips.mipseb or mips.mipsel instead? Please don't switch it as mips will be the new spelling of mipseb in the very near future. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfw - default to accept + bootp = confusion.
* James Quick [EMAIL PROTECTED] [ Date: 2003-08-07 ] [ w.r.t. Re: ipfw - default to accept + bootp = confusion. ] On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: Does someone have any idea what approach to take for the following scenario? I'm leaning towards a compile time failure, or an informative panic at the beginning of bootp... You have IPFIREWALL, but not the default to accept option, and you have BOOTP. The BOOTP stuff will fail in sosend with EACCESS (informatively printed as 13), because of IPFW, and this may be slightly non-obvious to people who haven't dealt with early ipfw interference before. If not compile time failure / panic, I'd say probably we want some way to notify a user in general of ipfw stopping pre-init operation, but I don't want to add the concept of runlevels, and don't know if there's anything there currently to do detection of if we've hit that point yet. If the default rule controlled by IPFIREWALL_DEFAULT_TO_ACCEPT, default_rule.cmd[0].opcode, were made accessible via a sysctl. then bootp could check it and produce an informative message. Or, if possible try to insert a rule into the kernel restrictive enough to be safe. On the one hand it's a firewall, and you don't want to be making assumptions about trust on behalf of the user. On the other hand, we just accepted a kernel from someone, and now want to get some data for a root partition, so if we cannot trust the host we're booting from, what's the point? Given the above, would it be possible, to embed a small function taking just a pair of addresses and masks, and use that to add a rule so that this process could continue? After using sysctl to verify the predicament, you could then try installing one (or a few) rules to trust the machines that are booting us. Trust the server running bootpd, trust the dchp and nfs server, or just trust the network+submask in a single rule. the following is just a rough guess from looking at ip_fw.c. I don't know how far off it is to being valid. s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (s 0) err(EX_UNAVAILABLE, socket); memset(rule, 0, sizeof rule); rule.fw_flg |= IP_FW_F_ACCEPT; rule.fw_prot = IPPROTO_IP; rule.fw_src = /* the bootp servers address rule.fw_smsk = ~0; /* Does all 1s mean just from that host? */ rule.fw_dst = /* Is our addr known yet? */ rule.fw_dmsk = ??; rule.fw_flg |= (IP_FW_F_OUT|IP_FW_F_IN); /* you could do both directions */ i = sizeof(rule); if (getsockopt(s, IPPROTO_IP, IP_FW_ADD, rule, i) == -1) err(EX_UNAVAILABLE, getsockopt(%s), IP_FW_ADD); Is any of this reasonable or I am just being naive? (I'm new here.) It's entirely easy/possible to add such, but I'd rather not have a dumb sysadmin blame me for their firewall supposedly getting punctured. If you have BOOTP on a box, defaulting to DENY is insane. Does that mean I want to just *change* things at runtime? No. I'd rather prevent any foot-shooting of any form. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw - default to accept + bootp = confusion.
Does someone have any idea what approach to take for the following scenario? I'm leaning towards a compile time failure, or an informative panic at the beginning of bootp... You have IPFIREWALL, but not the default to accept option, and you have BOOTP. The BOOTP stuff will fail in sosend with EACCESS (informatively printed as 13), because of IPFW, and this may be slightly non-obvious to people who haven't dealt with early ipfw interference before. If not compile time failure / panic, I'd say probably we want some way to notify a user in general of ipfw stopping pre-init operation, but I don't want to add the concept of runlevels, and don't know if there's anything there currently to do detection of if we've hit that point yet. Thanx, juli. -- juli mallett [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make -U
* Ruslan Ermilov [EMAIL PROTECTED] [ Date: 2003-07-30 ]
[ w.r.t. make -U ]
Sorry, I've accidentally dropped an email about `make -U'.
I think that it's not needed, since the functionality can
easily be achieved by running make FOO=, i.e., assigning
an empty value. Remember that command line variables take
precedence over globals, so the following makefile,
FOO+= bar
all:
@echo ${FOO}
when run as ``make FOO=foo'', will print just ``foo''.
Does that work for the .if defined() case, too? Makefiles can grow
to be more complex than just that sort of stuff, after all :)
Thanx,
juli. (who admits she missed the rest of the conversation)
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata;
i have lost my way home early - i don't care cause i won't stay there.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make -U
* Ruslan Ermilov [EMAIL PROTECTED] [ Date: 2003-07-30 ]
[ w.r.t. Re: make -U ]
On Wed, Jul 30, 2003 at 04:23:20PM -0500, Juli Mallett wrote:
* Ruslan Ermilov [EMAIL PROTECTED] [ Date: 2003-07-30 ]
[ w.r.t. make -U ]
Sorry, I've accidentally dropped an email about `make -U'.
I think that it's not needed, since the functionality can
easily be achieved by running make FOO=, i.e., assigning
an empty value. Remember that command line variables take
precedence over globals, so the following makefile,
FOO+= bar
all:
@echo ${FOO}
when run as ``make FOO=foo'', will print just ``foo''.
Does that work for the .if defined() case, too? Makefiles can grow
to be more complex than just that sort of stuff, after all :)
Not sure what do you mean. The make -U FOO was support to
undefine the FOO variable, as it the ``.undef FOO'' was called
at the end of makefile. Of course, setting FOO= on a command
line still gets you a defined variable, but
.if defined(FOO) !empty(FOO)
should do the trick. Try this out with make FOO=:
FOO= bar
all:
.if defined(FOO) !empty(FOO)
@echo FOO is set
.endif
Why go thru those contortions? I sometimes use make FOO= to define
things. -U obviously has a place, if it not existing means I have to
have all these contortions to do a fairly obvious thing, yeah?
Thanx,
juli.
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata;
i have lost my way home early - i don't care cause i won't stay there.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
USB crappiness?
Hi, I tried to upgrade my workstation to current recently, and I have to use a lot of USB, and while using some USB mass storage device, with a UFS filesystem on it, and doing a large operation to it (tar c|tar x) everything deadlocked on ufs, the USB stack blew up, and upon causing an interrupt to it, it panicked, and panic pagefaulted. Anyone else seeing these sorts of cohesive fallovers? Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release of CURRENT on 4.7 box
* Bruce Evans [EMAIL PROTECTED] [ Date: 2003-07-13 ]
[ w.r.t. Re: make release of CURRENT on 4.7 box ]
On Sun, 13 Jul 2003, Tim Kientzle wrote:
Bruce Evans wrote:
I think splitting it or making it exit after just setting variables
in the userland case is the right fix. ...
[it == newvers.sh]
I think you're right, but don't see a very simple way to make that
work, especially given the surprising number of places
that newvers.sh is used.
I think there aren't so many -- only kernel Makefiles and
src/include/Makefile.
There seems to be a simple way due to bitrot. $1 in newvers.sh is
not set when newvers.sh is invoked from src/include/Makefile, but
it seems to always be set when newvers.sh is invoked from kernel
Makefiles, due to garbage in the latter. The garbage is now
centralized in sys/conf/kern.post.mk:
sh $S/conf/newvers.sh ${KERN_IDENT}
^
This passes an unused variable to newvers.sh. Passing and use of
this variable was removed in 4.4BSD-Lite1, but FreeBSD's kernel
Makefiles are based on Net/2 and haven't caught up with this change
yet, while FreeBSD's newvers.sh is based on the Lite1 so it has
the change. This variable became needed again in newvers.sh last
month, but it wasn't used; the make -V hack was used instead.
Some relevant uses and non-uses of $1 in newvers.sh:
%%%
FreeBSD rev.1.1 (same as Net/2?)
echo char version[] = \version: ${v} ($1) ${t}\;
FreeBSD-1.1.5:
echo const char version[] = \${kernvers} ($1) #${v}: ${t}\\n [EMAIL
PROTECTED]:${dir}\\n\;
4.4BSD-Lite1:
echo char version[] = \4.4BSD-Lite #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n\;
vers.c
[No $1's here or elsewhere in newvers.sh]
-current:
i=`make -V KERN_IDENT`
...
char version[] = ${VERSION} #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n;
...
char kern_ident[] = ${i};
[No $1's here or elsewhere in newvers.sh, but I think $i is always the
same as $1.]
%%%
So removing the make -V line and just using $1 should fix the main problem
and the bitrot.
Go for it.
Thanx,
juli.
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata;
i have lost my way home early - i don't care cause i won't stay there.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/libexec/talkd notification broken on pty's when useris using misc/screen ports in -CURRENT
* Vincent Poy [EMAIL PROTECTED] [ Date: 2003-06-30 ] [ w.r.t. /usr/src/libexec/talkd notification broken on pty's when user is using misc/screen ports in -CURRENT ] Greetings evertone: /usr/src/libexec/talkd aka /usr/libexec/ntalkd appears to be broken when one runs the screen-3.9.15_1 from ports and has the pty sessions under screen. Prior to running screen, ntalkd is showing the incoming talk request. After running screen, the talk request doesn't show up on any of the pty's the user is currently using under the primary login pty. The issue seems to be caused by the following commits done by jmallett: src/libexec/talkd/announce.c v1.16, Thu Apr 3 05:13:27 2003 UTC jmallett src/libexec/talkd/extern.h v1.3, Thu Apr 3 05:13:27 2003 UTC jmallett src/libexec/talkd/print.c v1.12, Thu Apr 3 05:13:27 2003 UTC jmallett src/libexec/talkd/table.c v1.9, Thu Apr 3 05:13:27 2003 UTC jmallett src/libexec/talkd/talkd.c v1.14, Thu Apr 3 05:13:27 2003 UTC jmallett which has the log: MFp4 @27667: WARNS=5 cleanup on i386. Remove the unused FILE\ *tf from print_mesg args, and the bogus passing in of an uninitialised FILE* for it. Call a timeval 'now' instead of 'clock' due to shadowing. Remove a nested localtime declaration. Make the delete invite argument match the ID type, u_int32_t. Use const for pointers to const items. Cast to long where printing as such. Include netinet/in.h for htonl/htons. Reviewed by: imp Reverting to the following previous versions of the files and rebuilding ntalkd fixes the issue. src/libexec/talkd/announce.c v1.15, Tue Feb 5 21:06:56 2002 UTC imp src/libexec/talkd/extern.h v1.2, Tue Feb 5 21:07:47 2002 UTC imp src/libexec/talkd/print.c v1.11, Mon Feb 18 20:35:19 2002 UTC mike src/libexec/talkd/table.c v1.8, Tue Feb 5 21:06:56 2002 UTC imp src/libexec/talkd/talkd.c v1.13, Tue Feb 5 21:06:56 2002 UTC imp This may be a bit frustrating, but can you back out deltas by hand and try to tell me which change it was that caused the problem? Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
tcsh being dodgy, or pipe code ishoos?
Anyone with insight into this? ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) 1 + 2 + 3 ([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + +2 3 ([EMAIL PROTECTED]:~)41% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + +2 3 ([EMAIL PROTECTED]:~)42% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + 2+ 3 -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh being dodgy, or pipe code ishoos?
* Andrey Chernov [EMAIL PROTECTED] [ Date: 2003-06-24 ] [ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ] On Tue, Jun 24, 2003 at 18:35:15 -0500, Juli Mallett wrote: Anyone with insight into this? ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) 1 + 2 + 3 Loks like stdout/stderr mix, but I not check the code, so just raw guess. Really? What makes you say that? All of these utilities deal with stdout. Where does stderr come into it? Yes I know about TTY races outputting to stdout and stderr from different processes, especially how confusing it is to have say foo | bar | baz and bar puts something on stderr, and baz buffers for a second. But I don't see how, practically, this comes into play? The first is clearly correct, but throwing a pipe of alll the combined stuff in seems to complicate matters, so I suspect either buggy pipe code (not unheard of) or buggy tcsh handling of pipes (possible). Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh being dodgy, or pipe code ishoos?
* Tim Kientzle [EMAIL PROTECTED] [ Date: 2003-06-24 ]
[ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ]
Artem 'Zazoobr' Ignatjev wrote:
Juli Mallett wrote:
Anyone with insight into this?
([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) )
1
+ 2
+ 3
([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) )
| cat
1
+ +2
3
last cat is not necessary...
And it's more weird than that:
( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo -- + % ) )
1
-- --+ +2
3
Hmmm... This looks like xargs isn't waiting for the subcommand
to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are
running concurrently.
How about this, it essentially says that in the not -P case, no procs
may be unwaited-on, whereas otherwise we say that 1 may be unwaited-on..
Thanx,
juli.
%%%
Index: xargs.c
===
RCS file: /home/ncvs/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.54
diff -d -u -r1.54 xargs.c
--- xargs.c 13 Jun 2003 17:05:41 - 1.54
+++ xargs.c 25 Jun 2003 04:45:39 -
@@ -123,7 +123,7 @@
/* 1 byte for each '\0' */
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
- maxprocs = 1;
+ maxprocs = 0;
while ((ch = getopt(argc, argv, 0E:I:J:L:n:oP:pR:s:tx)) != -1)
switch(ch) {
case 'E':
%%%
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh being dodgy, or pipe code ishoos?
* Juli Mallett [EMAIL PROTECTED] [ Date: 2003-06-24 ]
[ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ]
* Tim Kientzle [EMAIL PROTECTED] [ Date: 2003-06-24 ]
Hmmm... This looks like xargs isn't waiting for the subcommand
to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are
running concurrently.
How about this, it essentially says that in the not -P case, no procs
may be unwaited-on, whereas otherwise we say that 1 may be unwaited-on..
jmg@ points out this better idea, of doing the waitchildren before the
vfork, allowing xargs to do its work while the child runs, as seems to
be the desirable effect of having maxprocs=1, so.
%%%
Index: xargs.c
===
RCS file: /home/ncvs/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.54
diff -u -r1.54 xargs.c
--- xargs.c 13 Jun 2003 17:05:41 - 1.54
+++ xargs.c 25 Jun 2003 05:12:27 -
@@ -518,6 +518,8 @@
}
exec:
childerr = 0;
+ curprocs++;
+ waitchildren(*argv, 0);
switch(pid = vfork()) {
case -1:
err(1, vfork);
@@ -537,8 +539,6 @@
childerr = errno;
_exit(1);
}
- curprocs++;
- waitchildren(*argv, 0);
}
static void
%%%
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error building world
* Mike Bohan [EMAIL PROTECTED] [ Date: 2003-06-12 ] [ w.r.t. error building world ] Hey there, I recently ran into a problem when building updated (via cvsup) world from -CURRENT. This smells like a sed bug. Rebuild and install sed, and try again. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
* Daniel O'Connor [EMAIL PROTECTED] [ Date: 2003-05-28 ] [ w.r.t. Re: policy on GPL'd drivers? ] : I guess the problem with mandating somewhere in $PREFIX is that the : loader can't load it, so that's no good. I guess the only choice left is : /boot/modules. /boot/kernel : Any comments? Well, the patch was mostly a strawman to promote discussions about the issues. Fair enough. I think the port should install the source for the module in $PREFIX somewhere (well known) and the module should live in /boot/kernel. When things need rebuilding it uses the installed source to do so.. Jumping in a bit late as I thought someone would point this out, but I thought that 3rd-party modules would live in /boot/modules? Also, as for them being tied to kernel configs at minimum, definitely, and I'd say that maybe /boot/modules should have e.g. foobar-IDENT.ko and a symlink to it from /boot/kernel.IDENT/foobar.ko or something, where IDENT is the kernel IDENT, that way multiple copies of a given 3rd-party module could exist, and probably we'd want to do something similar to the .old shuffling we do with kernels, anyway. Just a thought. Just putting them *with* each kernel does seeem a lot more direct, for sure, but I'd feel less gross adding a new symlink than copying one from an existing directory, which could be crudded up with $DEITY knows what. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
* M. Warner Losh [EMAIL PROTECTED] [ Date: 2003-05-28 ] [ w.r.t. Re: policy on GPL'd drivers? ] In message: [EMAIL PROTECTED] Juli Mallett [EMAIL PROTECTED] writes: : Jumping in a bit late as I thought someone would point this out, but : I thought that 3rd-party modules would live in /boot/modules? third party binary only modules. If you have source, for some definition of having source, to rebuild from, then it makes the most sense to keep it directly with the kernel. I'd not bother with symlinks as that just makes things more complicated and I'm not sure what gain you get from it. I'm just curious how the third-party modules are kept around properly across installkernel/buildkernel. Did you get MAKEOBJDIR/MAKEOBJDIRPREFIX stuff working in the kernel build dir with ports modules? I'm glad we aren't doing the realpath(3) thing in Make anymore, if so, as I doubt I'm the only one with one hell of a convoluted setup in that sort of thing. And thanks for clearing up that that was binary-only ones, that makes a bit more sense I suppose, assuming we're handling the module installs all properly. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: don't do that, in ugen(4)
Running `quickcam' twice from: http://people.freebsd.org/~jmallett/qce-freebsd.tgz Yields the following loveliness: %%% Script started on Tue May 27 17:59:35 2003 ([EMAIL PROTECTED]:~)1% gdb -k /boot/kernel/kernel vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (no debugging symbols found)... panic: bremfree: removing a buffer not on a queue panic messages: --- panic: don't do that syncing disks, buffers remaining... 1806 panic: bremfree: removing a buffer not on a queue Uptime: 6m34s Dumping 191 MB ata0: resetting devices .. ata0: pre reset mask=03 ostat0=50 ostat2=00 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0: devices=01 ad0: success setting BIOSPIO on Intel PIIX4 chip done ad0: timeout waiting for DRQata0: resetting devices .. ata0: pre reset mask=03 ostat0=d0 ostat2=d0 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0-slave: ATA 01 a5 ata0: devices=03 ata0-slave: timeout waiting for cmd=ec s=00 e=00 ata0-slave: ATA identify failed ad0: success setting BIOSPIO on Intel PIIX4 chip done 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/acpi.ko...(no debugging symbols found)... done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/logo_saver.ko... (no debugging symbols found)...done. Loaded symbols for /boot/kernel/logo_saver.ko #0 0xc030d6eb in doadump () (kgdb) bt #0 0xc030d6eb in doadump () #1 0xc030dd13 in boot () #2 0xc030e05b in panic () #3 0xc0351e12 in bremfreel () #4 0xc0351cf5 in bremfree () #5 0xc0355397 in getblk () #6 0xc0351ef2 in breadn () #7 0xc0351e9c in bread () #8 0xc04273d2 in ffs_update () #9 0xc043bc5f in ffs_fsync () #10 0xc043acfe in ffs_sync () #11 0xc03677fb in sync () #12 0xc030d92d in boot () #13 0xc030e05b in panic () #14 0xc02ede12 in destroy_dev () #15 0xc02a369f in ugen_destroy_devnodes () #16 0xc02a48db in ugen_set_interface () #17 0xc02a4e2c in ugen_do_ioctl () #18 0xc02a5367 in ugenioctl () #19 0xc02d538e in spec_ioctl () #20 0xc02d4ac8 in spec_vnoperate () #21 0xc036fbe1 in vn_ioctl () #22 0xc0334098 in ioctl () #23 0xc049a27e in syscall () ---Type return to continue, or q return to quit--- #24 0xc04896ed in Xint0x80_syscall () ---Can't read userspace from dump, or kernel process--- ([EMAIL PROTECTED]:~)2% uname -a FreeBSD big-lizard.backyard.newgold.net 5.1-BETA-20030522-JPSNAP FreeBSD 5.1-BETA-20030522-JPSNAP #0: Thu May 22 00:15:14 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Script done on Tue May 27 18:01:06 2003 %%% Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kp_proc and kp_eproc
* De: Glenn Johnson [EMAIL PROTECTED] [ Data: 2003-04-04 ] [ Subjecte: kp_proc and kp_eproc ] I have some software that compiled fine on FreeBSD-4 but is not compiling on FreeBSD-5. It is looking for kp_proc and kp_eproc. The error I get is: structure has no member named `kp_proc' structure has no member named `kp_eproc' Have those changed from FreeBSD-4? Yes, kinfo_proc has changed. What do you need to access? I have found that just doing a set of macros helps a lot. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD/alpha kern.flp flood
* De: Bruce Evans [EMAIL PROTECTED] [ Data: 2003-04-02 ] [ Subjecte: Re: FreeBSD/alpha kern.flp flood ] I'd hardly call it a bug, since style(9) explicitly says C files should use __FBSDID(). Another bug. __FBSDID() is is not normally used in the kernel. E.g., rev.1.1 of almost every file in libkern is about removing (sccs) id strings since their bloat is not wanted in the kernel. It is true that __FBSDID() and suitable stripping can handle this more configurably, but no one ever cared enough to change n,000 $FreeBSD$'s to __FBSDID()'s in the kernel (ugh) or provide infrastructure (#define lint doesn't count) for stripping the ids. #define STRIP_FBSDID does, however, count I think. It would work just fine in opt_global.h, too, if someone threw the necessary options bit in, and then users could decide, as well as strip(1)ers. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr and 1:1 threading.
* De: Jeff Roberson [EMAIL PROTECTED] [ Data: 2003-04-02 ] [ Subjecte: Re: libthr and 1:1 threading. ] On Wed, 2 Apr 2003, Terry Lambert wrote: Also, any ETA on the per process signal mask handing bug in libthr? Might not be safe to convert everything up front, in a rush of eager enthusiasm... Which bug is that? I'm not aware of it. I think Terry is referring to the Uncertainty Doubt as if it were a bug over the lack of a process sigmask (moved into the threads), as raised by the M:N group. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr and 1:1 threading.
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-04-02 ] [ Subjecte: Re: libthr and 1:1 threading. ] leafy wrote: On Wed, Apr 02, 2003 at 07:38:14AM -0800, Terry Lambert wrote: Has anyone tried compiling X11 to use libthr? Someone reported success with KDE, so it should serve as a sign of working X11. Not X11 clients. The X11 server. In any case, compiling there is bogus. Just replace (symlink) lc_r. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Odd issues with USB SmartMedia Reader/Writer (PNY)
I'm really dumb when it comes to CAM, SCSI, USB, and so on, so forgive if I am being naive... (Also that would probably explain why I am having a hard time deciding where this mail should end up... Forgive me on that account, plz.) I have a PNY USB SmartMedia reader which works excellently with 5.x with 8M media, but which blows up with 32M media. I'd assume this is due to improper geometry or something, but I really have no idea. Insert-reinsert produces no change in results, etc. Below are bits from dmesg, with the smaller then the larger. Any insight would be appreciated. Once this is taken care of, the weekly reboots into windows to clean off the camera can finally stop... Out last legitimate use of Windows :) %%% -- With the 8M SmartMedia umass0: Alcor Mass Storage Device, rev 1.10/1.00, addr 5 umass0: Get Max Lun not supported (STALLED) umass0:0:0:-1: Attached to scbus0 as device 0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Generic USB SMC Reader 1.00 Removable Direct Access SCSI-0 device pass0: 1.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Generic USB SMC Reader 1.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 7MB (16000 512 byte sectors: 64H 32S/T 7C) (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. [0] f:80 typ:1 s(CHS):0/1/10 e(CHS):249/3/16 s:25 l:15975 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 12800 length 8179200 end 8191999 %%% %%% -- With the 32M SmartMedia umass0: Alcor Mass Storage Device, rev 1.10/1.00, addr 5 umass0: Get Max Lun not supported (STALLED) umass0:0:0:-1: Attached to scbus0 as device 0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Generic USB SMC Reader 1.00 Removable Direct Access SCSI-0 device pass0: 1.000MB/s transfers GEOM: new disk da0 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Generic USB SMC Reader 1.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present Unretryable error (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present Unretryable error (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 - 6 %%% Thanx! juli. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
syscons patch to fix SC_NO_CUTPASTE build with Werror.
So like, here's a patch, commit message inline, to syscons to fix the
SC_NO_CUTPASTE build, with Werror, which LINT misses cause it has a
lame combination of build options, which result in not even testing
most useful syscons stuff, rather a minimal set. I'd commit it now,
but syscons is a scary beast, and while the logic doesn't change, I
don't use cutpaste (nor desire to figure out how to) and so I cannot
really test it to be sure (yeah, right.) So here it is for review,
for the next 24 or so hours.
%%% xxx
Protect (hide) unused variables in the SC_NO_CUTPASTE case.
Reviewed by:marcel
? xxx
Index: scmouse.c
===
RCS file: /home/ncvs/src/sys/dev/syscons/scmouse.c,v
retrieving revision 1.32
diff -d -u -r1.32 scmouse.c
--- scmouse.c 19 Feb 2003 05:47:12 - 1.32
+++ scmouse.c 18 Mar 2003 20:26:24 -
@@ -75,8 +75,10 @@
#ifndef SC_NO_SYSMOUSE
/* local variables */
+#ifndef SC_NO_CUTPASTE
static int cut_buffer_size;
static u_char *cut_buffer;
+#endif
/* local functions */
static void set_mouse_pos(scr_stat *scp);
@@ -770,10 +772,10 @@
}
}
+#ifndef SC_NO_CUTPASTE
if (ISGRAPHSC(cur_scp) || (cut_buffer == NULL))
break;
-#ifndef SC_NO_CUTPASTE
if ((mouse-operation == MOUSE_ACTION) f) {
/* process button presses */
if (cur_scp-mouse_buttons MOUSE_BUTTON1DOWN)
@@ -825,10 +827,10 @@
}
}
+#ifndef SC_NO_CUTPASTE
if (ISGRAPHSC(cur_scp) || (cut_buffer == NULL))
break;
-#ifndef SC_NO_CUTPASTE
switch (mouse-u.event.id) {
case MOUSE_BUTTON1DOWN:
switch (mouse-u.event.value % 4) {
%%%
Thanx,
juli.
--
juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
lock? panic in networking swi
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d47c6 stack pointer = 0x10:0xc5d33a90 frame pointer = 0x10:0xc5d33ab4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (swi1: net) trap number = 12 panic: page fault No core, of course, nm says the ip is likely: _mtx_unlock_sleep Thoughts? This is a kernel from last weekend, I'll try to get something more recent soon. FWIW, I'm reproducing these by running gtk-gnutella and telling it to auto-download anything with talk talk in it, which due to its wonderful anti-foot-shooting algorithms means it downloads everything with talk in it, which is quite a lot. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xl: discard frame without packet header
This fixed yet? xl0: discard frame w/o packet header Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01fbcf8 stack pointer = 0x10:0xc5d6fc34 frame pointer = 0x10:0xc5d6fc58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 20 (irq10: xl0) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 5d23h7m28s If not I'll be able to take a quick stab at it tomorrow. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Murray [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Terry, watch your language. And then find me a site running XNS that expects to be running a current version of FreeBSD, or ideally someone I could peer an XNS system with if I were to take up maintainership of it? You have until the code is gone from CVS, which hopefully will be very soon. Thanx, juli. PS: I might be interested in getting it out of the attic if you could find me a good place for XNS-only connectivity, with IP-over-XNS of some sort so I could still IRC. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Linimon [EMAIL PROTECTED] [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] On Tue, 4 Mar 2003, Terry Lambert wrote: Tell you what, I'll fix these and post a patch. Will that make you guys happy? Yes, as will anything else that cuts down on the metadiscussions and increases the quality of the codebase. No, it screws up the quality of the codebase if it cannot be tested and used every day, and I doubt Terry will be doing real testing. HOWEVER, I am willing to keep netns working if someone can provide a pure XNS with IP-over-XNS provider. Playing around using multiple FreeBSD boxen with a possibly broken but interoperable implementation is also out of the question, as nobody uses it. For things that people actually use, it's OK as prototyping fixes and getting them in tree, and then the users can find where it's broken later. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
elf_loadfile: kernel already loaded
Hi, (Trying to boot an alternate kernel on FreeBSD/i386 with normal loader running at a console, loading kernel from a disk.) It looks like after I unload the default kernel, and try to load a new one, when I go to boot, loader is trying to load some other kernel, and I'm not sure why, but I get the elf_loadfile: kernel already loaded, I was trying to fix this on my p4 branch by adding some printfs to figure out what it was trying to load, and since I didn't have libstand around, it threw a fit at me during the compile and I gave up, so I figured I'd just mail here and ask if anyone has seen what I'm talking about, or knows if it is fixed, or how to fix it. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Re: PATCH: type errors in src-tree ] Barney Wolff wrote: On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote: Shouldn't we care about u_char vs char? On some machines it matters, and on all machines compilers tend to notice and generate warnings. Just another question: I turned on '-ansi' and got some warning about a function declaration is not a prototype (all functions are declared in KR style). Is it preferred by the FreeBSD-Team having functions in KR styles or is the Ansi-Style on, too? ANSI is preferred, but mixing style with functional changes is discouraged. I get the impression your change to width-specified values has a real correlation to what things need to use, and thus it might fix brokenness with systems not ILP32. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible patch for limiting APs at startup
* De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Possible patch for limiting APs at startup ]
Hello.
Just as the topic says, do you think this patch is good enough, or gets
even close to it? I have tested the patch, and it seems to do it's job
in the right way. Some might call it hackery, but it's better than
nothing I would suppose.
I think your use of cpus to refer to APs only is silly, and also that
overriding mp_naps instead of using a real cpus value and using it as
a bounds check akin to MAXCPU, is a bit of the wrong direction. As you
know, the following is my patch, and it does not work, but I think,
personally, the behaviour is saner, in theory at least :)
%%%
Index: mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.203
diff -d -c -r1.203 mp_machdep.c
*** mp_machdep.c24 Feb 2003 14:36:03 - 1.203
--- mp_machdep.c2 Mar 2003 00:22:58 -
***
*** 249,254
--- 249,259
/** XXX FIXME: what system files declare these??? */
extern struct region_descriptor r_gdt, r_idt;
+ int mp_maxcpus = 0; /* max CPUs; not in BSS so it can be hacked. */
+ TUNABLE_INT(machdep.smp_max_cpus, mp_maxcpus);
+ SYSCTL_INT(_machdep, OID_AUTO, smp_max_cpus, CTLFLAG_RD,
+ mp_maxcpus, 1, Maximum number of CPUs to use.);
+
int bsp_apic_ready = 0; /* flags useability of BSP apic */
int mp_naps;/* # of Applications processors */
int mp_nbusses; /* # of busses */
***
*** 864,874
}
}
! /* qualify the numbers */
! if (mp_naps MAXCPU) {
printf(Warning: only using %d of %d available CPUs!\n,
! MAXCPU, mp_naps);
! mp_naps = MAXCPU;
}
/* See if we need to fixup HT logical CPUs. */
--- 869,881
}
}
! /* use the smallest number of requested CPUs or CPUs we support. */
! if ((mp_maxcpus 0 mp_naps mp_maxcpus) || mp_naps MAXCPU) {
! if (mp_maxcpus = 0)
! mp_maxcpus = MAXCPU;
printf(Warning: only using %d of %d available CPUs!\n,
! mp_maxcpus, mp_naps);
! mp_naps = mp_maxcpus;
}
/* See if we need to fixup HT logical CPUs. */
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't load if_gif.ko
* De: Bruce Cran [EMAIL PROTECTED] [ Data: 2003-02-26 ] [ Subjecte: Re: can't load if_gif.ko ] On Wed, Feb 26, 2003 at 03:30:30PM -0300, Daniel C. Sobral wrote: It seems something has gone wrong on current wrt if_gif: [EMAIL PROTECTED] etc]# ifconfig gif0 create ifconfig: SIOCIFCREATE: Invalid argument [EMAIL PROTECTED] etc]# kldload if_gif kldload: can't load if_gif: No such file or directory It works for vlan, so that's not a general module/ifmodule loading problem. Very recent current. It doesn't work on 4.7 either if IPv6 isn't compiled into the kernel. If you look at the kernel messages it might give you more information. It might be a different problem, but mine was wanting IPv6, and refused to load without it. This type of error reminds me of trying to run FreeBSD binaries on Linux - you run ./bsd_app and it says 'No such file or directory' which is less than helpful, while I generally find FreeBSD error messages to be a lot more informative. Would it be possible for this message to be reworded to be more helpful? The file does indeed exist, it's just that the system cannot load it. Or, if a module fails to load, maybe prompt the user to look at the kernel messages for any error messages? It's easy to change kldload to have something like Failed to load module, but changing the result of strerror(errno) isn't possible in this case. It is possible, however, to check for obtuse errno values being used that we KNOW mean something in this context, and give something more informative. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't load if_gif.ko
* De: Brooks Davis [EMAIL PROTECTED] [ Data: 2003-02-26 ] [ Subjecte: Re: can't load if_gif.ko ] On Wed, Feb 26, 2003 at 01:12:59PM -0600, Juli Mallett wrote: It's easy to change kldload to have something like Failed to load module, but changing the result of strerror(errno) isn't possible in this case. It is possible, however, to check for obtuse errno values being used that we KNOW mean something in this context, and give something more informative. I wonder if we shouldn't add ENOSYMBOL translating to Unresolved symbol for this case. Or we could just work with the contracts that the kld code has made with the world already, and just deal with them appropriately in our tools. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HyperThreading not working?
* De: Trish Lynch [EMAIL PROTECTED] [ Data: 2003-02-26 ] [ Subjecte: RE: HyperThreading not working? ] On Wed, 26 Feb 2003, John Baldwin wrote: On 26-Feb-2003 Slawek Zak wrote: Hi, I'm in the process of installing 5.0-RELEASE-p3 on a Dell PowerEdge 2600 server. It has two HyperThreading Xeon 2.4Ghz processors, but HyperThreading is not working in FreeBSD. I guess that four processors should be visible in the system after boot. Yes - I've enabled `Logical Processors' in BIOS. BIOS revision is the latest available. Any thoughts? I attach full dmesg and mptable output. Kernel config too. 5.0 doesn't support HyperThreading. The upcoming 5.1 and 4.8 releases will support it. it doesn't? I have a 5.0-R box that surely does support HTT. Your BIOS puts the logical CPUs into the MPTable. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Errors with wireless
* De: Sam Leffler [EMAIL PROTECTED] [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] wi0: tx failed, retry limit exceeded If this happens again show the output of sysctl hw.wi. I get those constantly when doing e.g. an interactive FTP session. ([EMAIL PROTECTED]:~)10% sysctl hw.wi hw.wi.txerate: -1 hw.wi.debug: 0 Should I be tuning txerate or something? -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Errors with wireless
* De: Sam Leffler [EMAIL PROTECTED] [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] * De: Sam Leffler [EMAIL PROTECTED] [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] wi0: tx failed, retry limit exceeded If this happens again show the output of sysctl hw.wi. I get those constantly when doing e.g. an interactive FTP session. ([EMAIL PROTECTED]:~)10% sysctl hw.wi hw.wi.txerate: -1 hw.wi.debug: 0 Should I be tuning txerate or something? I blew it. The default setting of -1 was supposed to disable all tx error messages (a la the old driver) but instead caused all messages to be printed (no rate limiting). It looks like you need to do something like: sysctl hw.wi.txerate=99 to disable the error messages or set it to some other value N to get no more than N messages/second printed. I'll fix the code to set the default to a large number. Making it 2^31-1 seems to have no effect. My kernel is about 14 days old, maybe it was debörken in that time? Feb 25 22:40:32 luna sudo: jmallett : TTY=ttyp7 ; PWD=/usr/people/jmallett ; USER=root ; COMMAND=/sbin/sysctl hw.wi.txerate=2147483647 Feb 26 04:41:58 luna kernel: wi0: tx failed, retry limit exceeded Feb 26 04:42:13 luna last message repeated 9 times ([EMAIL PROTECTED]:~)18% sysctl hw.wi.txerate hw.wi.txerate: 2147483647 Soo... I tried your value: Feb 25 22:44:49 luna sudo: jmallett : TTY=ttyp7 ; PWD=/usr/people/jmallett ; USER=root ; COMMAND=/sbin/sysctl hw.wi.txerate=99 Feb 26 04:45:00 luna kernel: wi0: tx failed, retry limit exceeded And then that's that. I'm confused? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
* De: Chris BeHanna [EMAIL PROTECTED] [ Data: 2003-02-16 ] [ Subjecte: Local repo: Perforce/CVS integration ] For those of you doing development with Perforce, could you talk a little bit about how this is done? Do you do a cvsup nightly and import that on a vendor branch, then integrate it into your working tree? (That sounds like it would work.) Do you use cvs2p4? How about going in the other direction (from your local branches back to the trunk?) I'm reasonably well-versed in both CVS and Perforce, and Perforce just does merging *so* much better than CVS that'd I'd rather use it, but I'd also rather crib from someone who has a process that's working, rather than roll my own. FreeBSD has special great evil triggers which will import things into //depot/vendor/freebsd/src/... for example, and then we just branch off of there, and integ -b as needed. :) As for the CVS merge, I personally keep vendor/freebsd/src in my client view, as well, and use diff(1) to manually prepare both change diffs (modification) and additions, in whatever style I prefer. If it is just for review, I'd use diff2 :) Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
* De: Andrey A. Chernov [EMAIL PROTECTED] [ Data: 2003-02-16 ] [ Subjecte: Re: OPIE breakage: backout patch for review ] On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote: In the case where an application is OPIEised and not PAMised, we need to figure out something; PAMizing such apps is not terribly hard. If any of them are in the base system, then this situation We are not in the situation to force users and admins to rewrite their OPIE apps under new PAM framework. I always believe that non-destructive for OPIE defaults (i.e. PAM only) solution is possible here, but not being PAM specialist, can't demonstrate it. Recent des commits solve problem correctly. Can you explain how this stops purely opieized apps from working? I was under the impression the implicit case was still there, we just have a more explicit contract with the OPIE system. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
* De: Andrey A. Chernov [EMAIL PROTECTED] [ Data: 2003-02-16 ] [ Subjecte: Re: cvs commit: src/lib/libc/stdlib rand.c ] On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote: I don't think rand() needs a warning message like gets() c. because it's not as dangerous. Wait, what kind of warning __warn_references() produce? I was under impression that it is compile-time only. I don't like the idea of this, people using rand incorrectly deserve to get their foot shot off. People using it legitimately don't need to have their heart skip a beat whenever thye link on FreeBSD because it looks like there's some danger to using rand(), when it is perfectly good at what it does, for a lot of common uses. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
* De: Mathieu Arnold [EMAIL PROTECTED] [ Data: 2003-02-17 ] [ Subjecte: Re: Local repo: Perforce/CVS integration ] --En cette belle journée du dimanche 16 février 2003 16:08 -0600 -- Juli Mallett [EMAIL PROTECTED] écrivait : | FreeBSD has special great evil triggers which will import things into | //depot/vendor/freebsd/src/... for example, and then we just branch off | of there, and integ -b as needed. | | :) Are these triggers top secret, or would it be possible to share them with the rest of us ? When i said triggers above, I was thinking of something else, what I was referring to is actually a periodic (or manually kicked off) job to import things to the vendor area. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is scsi device wiring broken?
* De: [EMAIL PROTECTED] [ Data: 2003-02-15 ] [ Subjecte: Re: Is scsi device wiring broken? ] On Sat, Feb 15, 2003 at 02:55:34PM -0800, John Polstra wrote: What's the magic incantation to make it work? see SCSI DEVICE CONFIGURATION in /sys/conf/NOTES, you have to use a hints-file. jdp is right though, scsi(4) is full of lies. Really needs fixed before the next release :) -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig problems
* De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-02-13 ] [ Subjecte: Re: mdconfig problems ] On Thu, Feb 13, 2003 at 02:08:30PM -0700, [EMAIL PROTECTED] wrote the words in effect of: -su-2.05b# mdconfig -a -t vnode -f filesys mdconfig: ioctl(/dev/mdctl): No such file or directory -su-2.05b# ls /dev/md* /dev/mdctl -su-2.05b# why does that happen? I'm doing everything the handbook says to... Do you actually have the file, 'filesys'? The argument to -f is meant to be the name of a file used as a backing store. Something like thse might help you: Making it './filesys' should work. I don't have the OP's message, in my inbox, so I'll just reply here. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
* De: Garrett Wollman [EMAIL PROTECTED] [ Data: 2003-02-11 ] [ Subjecte: C conformance. ] On Sun, 09 Feb 2003 19:43:38 +0100, Marcin Dalecki [EMAIL PROTECTED] said: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. It should probably be a #error instead. Yes, I discussed this with BDE shortly before the RELEASE freeze, and intended to investigate it afterwards, but lost my stomach for doing such stuff for quite some time. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2.2 import -- questions
* De: Craig Rodrigues [EMAIL PROTECTED] [ Data: 2003-02-10 ] [ Subjecte: Re: GCC 3.2.2 import -- questions ] On Mon, Feb 10, 2003 at 08:44:33PM -0500, Wesley Morgan wrote: that are supposedly fixed with 3.2.2... My question is, should I consider rebuilding my ports with this new compiler because of stability and/or speed improvements? Or is this point release not worth the effort. Speed improvements? No. gcc 3.2.2 is definitely slower than gcc 2.95. There is a lot of arguing on the gcc mailing list right now about this, but no concrete action to improve the situation yet. I would assume the OP meant relative to the previous version of GCC in tree. Current hasn't been 2.95.x for some time. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
* De: Andrey A. Chernov [EMAIL PROTECTED] [ Data: 2003-02-07 ] [ Subjecte: Re: Wrong date for DEVFS entries ] On Sat, Feb 08, 2003 at 00:16:24 +0100, [EMAIL PROTECTED] wrote: Can we stop considering workarounds, and instead work on solving the problem please ? I see no solving way until kernel will understand fully and can handle timezone database format. It means timezone code should be integrated into kernel. And for which reason? Only to heal DEVFS timestamps? Mount workaround looks more light-weighted. The contents of /dev/ really don't need audited, in a devfs world, like they might be in a non-devfs one. For example hiding rootkits in /dev/wd0./foo or /dev/somedev0/ or whatever isn't really quite the issue it may have ever been. People who read too much into the contents of a devfs /dev should not be too surprised if the results are dodgy. What with cloning and all. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
* De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-03 ]
[ Subjecte: Re: rand() is broken ]
FWIW - AIX aggrees with Solaris.
Endiannes, or an SVR4 implementation difference?
OS X agrees with FreeBSD i386. In fact, FreeBSD sparc64 and FreeBSD
alpha are all the same too, so it seems the code isn't too sensitive
to byteorder or wordsize.
Bakul's comments on who agrees with BSD 4.{2,3,4}-* probably explain
the differences.
*Nod* when I saw that message, I got it :)
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
* De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-02 ] [ Subjecte: Re: rand() is broken ] On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote: FreeBSD Redhat SunOS 660787754660787754645318364 FWIW - AIX aggrees with Solaris. Endiannes, or an SVR4 implementation difference? -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
* De: Bakul Shah [EMAIL PROTECTED] [ Data: 2003-02-01 ] [ Subjecte: Re: Style fixups for proc.h ] Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. According to C99, a function prototype has its own scope or name space. It terminates at the end of the function declarator. Basically naming a parameter in a function prototype is an aide to the human user; it is not needed for correct compilation[1] so this warning is bogus. As the spec says in section 6.7.5.3 (according the draft I have) The identifiers [naming parameters] are declared for descriptive purposes only and go out of scope at the end of the [prototype] declaration. I can't see what actual error is avoided by this warning. If a named prototype clashes with something in global scope, isn't it still a shadowing issue? They should probably never be *in* scope. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the Union Report (backout request department)
* De: Mike Barcroft [EMAIL PROTECTED] [ Data: 2003-01-31 ] [ Subjecte: Re: State of the Union Report (backout request department) ] The archives might not be telling the whole story. A lot of times these things get handled behind closed doors, whether private e-mail or developer-only lists. Thankfully though, most conflicts *do* get resolved. :) Might be nice if we had an internal trouble ticket system for things like this, TODOs that are high priority, and pending MFCs. I got the impression NetBSD does something like this for branch pullups that are needed? Then there's a clearer qudit trail, and it's easier to find out if things have not been honoured. And to keep other sorts of things from falling behind. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
* De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ] [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Further, export -d somedir might be useful in this situation to get the files where you want them, though sometimes -d does not DWIM, so I'm not sure :) -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is netstat b?rked?
* De: Ruslan Ermilov [EMAIL PROTECTED] [ Data: 2003-01-30 ] [ Subjecte: Re: Is netstat b?rked? ] On Wed, Jan 29, 2003 at 02:07:50PM -0800, Juli Mallett wrote: ref5% netstat -na -p tcp ref5% dalek# netstat -an -p tcp dalek# Both beast and ref5 are from Jan 4 and exhibit this problem; builder, which is from Jan 28, doesn't. Perhaps, someone updated the kernel and forgot to update the userland, or vice versa? No, a modern kernel fixes it. Apparently the kernel was really broken since I first started seeing this (which means that it is in 5.0-R too). Kernel build took as long as it did for your reply :) I kinda doubted it was that, since my kernel was only 6 days old. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is netstat b?rked?
* De: Scott R. [EMAIL PROTECTED] [ Data: 2003-01-30 ] [ Subjecte: Re: Is netstat b?rked? ] On Thu, Jan 30, 2003 at 12:30:44AM -0800, Juli Mallett wrote: * De: Ruslan Ermilov [EMAIL PROTECTED] [ Data: 2003-01-30 ] [ Subjecte: Re: Is netstat b?rked? ] On Wed, Jan 29, 2003 at 02:07:50PM -0800, Juli Mallett wrote: ref5% netstat -na -p tcp ref5% dalek# netstat -an -p tcp dalek# Both beast and ref5 are from Jan 4 and exhibit this problem; builder, which is from Jan 28, doesn't. Perhaps, someone updated the kernel and forgot to update the userland, or vice versa? No, a modern kernel fixes it. Apparently the kernel was really broken since I first started seeing this (which means that it is in 5.0-R too). Kernel build took as long as it did for your reply :) I kinda doubted it was that, since my kernel was only 6 days old. I'm running 5.0-RELEASE here and 'netstat -na -p tcp' works as expected. Hmm, OK. Thanks :) -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote: Or are you saying that you would prefer to change how the machine directive works in config(8) and introduce a new non-standard directive for pc98? That was the thought I was playing with. Hmm. Juli, what do you think of this? We could perhaps introduce platform and make it mutually exclusive with machine, and that way if the config file has a machine directive we get the old behaviour and only invoke the new behaviour when we have a platform directive. Then we can start transitioning over to it as needed. This is pretty much a no-op on sparc64, ia64 and alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it later on. Perhaps this could be a target for 6.0. What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. Well, the whole point of platform is it doesn't affect first-class platforms, which is where we have one architecture, one platform. In those cases it would gain nothing, and by not having it, there is no loss. Of course, i386 might eventually grow it, if pc98 is merged, as there may be some things we would restrict to the !pc98 case. But hell, at that point we may have platform isa and platform acpi or something, for the two different growing i386 platforms. I suppose jhb might prefer legacy for the former :) I've been thinking about the implicit selection of the architecture based on where the config file lives. We currently restrict where config(8) can be run from and don't really have a nice way of dealing with the case where SYSTEM_NAME is actually a path. This basicly means that we must run config(8) from /sys/$ARCH/conf. This makes the implicit selection of the architecture logical, even or especially if we want to remove the restriction of where we have the kernel config file and/or where we run the config(8) utility from later. We can always add the necessary options and keywords to deal with the added flexibility, including making the architecture explicit. In that case it would work the same on all architectures without any weird interferences of having multiple platforms. If we just make machine mean more of what it means now, then we're set. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: John Baldwin [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On 29-Jan-2003 Benno Rice wrote: On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote: On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: Agreed. There's an advantage there, but see also my reply to Juli about the use of machine to mean MACHINE_ARCH and the use of platform to mean MACHINE. This I don't find appealing. I can see your point here, but if needed I'd rather see them renamed to MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and machine and platform on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate machine to MACHINE and platform to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. In that case I'm mostly in agreement. Avoiding confusion is a Good Thing(tm). Just be consistent please. Ignore the implementation and choose one of these two paths: 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture and MACHINE being the platform and use the 'machine' keyword for MACHINE with MACHINE_ARCH either explicit (in which case 'machine' defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or implicit from the config file location. 2) Use PLATFORM and MACHINE with matching config keywords and if platform is not specified it defaults to MACHINE. I don't really care which, but please just pick one and be fully consistent. If you go with 1), I suggest an alternative header file layout where you have an /usr/include/arch and the machine/ headers (which are platform-specific) include the arch/ headers for common things. I think both ways can work, but please do not change the meaning of one set w/o changing the other. If we change the meaning of machine, IMO the requirement to include up to *every* exported header with a stub is ugly. NetBSD does this. What if we install them as they're named. arch for the multi-arch systems, platform too... And symlink machine to arch for backwards compatability? I have to think that a complete move to a new pair of words would be GREAT, but we'd want to maintain some (faked) historic mistakes :) Unless you think that the platform headers should be the consumers, but of course, then you'd want to invert how the build, etc., are in what I'm suggesting, or? I mean, a lot of this is out of wanting the master port to drive, with the meta-data in the back, reading off the map, as it were. Aside from that, a pair of arch and platform would be good, and have them be mutually exclusive with machine where machine is for the traditional 1:1 ports. And retains the old behaviour, modulo any possible new stuff wrt config file location that arch would give us flexibility on. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) Well, I like what jhb has suggested, of fully moving to a new set of keywords for config(8) to describe these sorts of things, rather than having machine+platform, having arch+platform, but keeping machine for those things that want it. Does that work for you? That way there's no misunderstanding about machine as it comes out of the picture, except for cases where MACHINE_ARCH is MACHINE is machine, unless we are making the (unaffected) pc98 mistake. When I mean make machine more of what it is now, I mean just use it for finding stuff, which is all it does now. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Is netstat börked?
ref5% netstat -na -p tcp ref5% dalek# netstat -an -p tcp dalek# Both times logged in via ssh, etc. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Newfs börked: Kills make release in strange ways.
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Newfs börked: Kills make release in strange ways. ] Newfs is börked right now (see below), and that kills make release in really strange ways. It looks like it was this typo, which didn't show up as being a problem as I never tried to boot (fsck) off one of these volumes: %%% Index: mkfs.c === RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v retrieving revision 1.68 diff -d -u -r1.68 mkfs.c --- mkfs.c 27 Jan 2003 07:24:32 - 1.68 +++ mkfs.c 29 Jan 2003 22:59:32 - @@ -842,7 +842,7 @@ else ((struct ufs2_dinode *)iobuf)[ino_to_fsbo(sblock, ino)] = ip-dp2; - wtfs(d, sblock.fs_size, (char *)iobuf); + wtfs(d, sblock.fs_bsize, (char *)iobuf); } /* %%% Also, the ioctl stuff was giving me trouble, I thought this was due to my local configuration being a mix of rather old and rather new bits (my newfs in /sbin was from October before my libufs version), but I was just not doing writable disks Right At All in libufs, really. Now there's a command to do it, used by bwrite, etc. I'll be committing that in a sec. Then I'll sit on newfs again for a few days. BTW, I ended up with the few of these: Zone md99 was not empty. Lost 1 pages of memory. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Force 1 CPU on SMP kernel?
* De: Odhiambo Washington [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Force 1 CPU on SMP kernel? ] * Ceri Davies [EMAIL PROTECTED] [20030128 12:50]: wrote: On Mon, Jan 27, 2003 at 11:33:02PM -0500, Adam Migus wrote: Hi, I'm doing some performance analysis on FreeBSD. I would like to be able to make an SMP kernel use only one CPU. Of course I realize running GENERIC would only use 1 CPU but the concern is that the overhead assoicated with SMP will skew the statistics. So my question is what would be the 'best' way to make an SMP kernel only start/use CPU0? Yank the others ? What about building two kernels, one SMP, the other non-SMP, then just boot wheichever kernel you want? Doesn't it server same purpose? Better than Ceri's idea ;) You're missing the point. He wants to boot only the bootstrap processor, none of the APs, but still be running an SMP kernel. I think checking how much overhead SMP and APIC_IO add is a noble goal, and throwing real SMP into the mix would be dumb. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Takahashi Yoshihiro [EMAIL PROTECTED] [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about platforms. ]
In article [EMAIL PROTECTED]
Juli Mallett [EMAIL PROTECTED] writes:
For example platform sgimips implies
options SGIMIPS. Below are patches to makefile glue and config(8)
itself.
I think that using '#ifdef machine' (like #ifdef PC98) is not a good
idea. If it requires, the file should be splited into sys/machine.
I'll split some files in sys/i386 into sys/pc98.
For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in machine/endian.h like:
#include platform/endian.h
How about next way?
- Install sys/${MACHINE}/include into /usr/include/${MACHINE}
- Symlink /usr/include/machine - /usr/include/${MACHINE}
- If ${MACHINE} != ${MACHINE_ARCH},
install sys/${MACHINE_ARCH}/include into /usr/include/${MACHINE_ARCH}
For example, sys/pc98/include/endian.h is '#include i386/endian.h'
only.
This approach is a really bad one architecturally, in my opinion. It means
there is a lot of duplication of what may all be VERY similar, and it means
that if we had say 5 platforms supported by the MIPS port (certainly this is
not a high number at all) that means there would be 5 directories under
src/sys... And none of them would be mips since we wouldn't be supporting
any hardware called mips, that's just the general architecture.
Or maybe we'd have mips and it would just be the first machine we ported
to, and so that would be even more confusing for people trying to do a clean
port to *just* support their architecture. They would have to know the other
hardware very well also, not just the MIPS stuff, so they would know what to
remove, what was something FreeBSD needed on MIPS, etc.
I just really would like things to be clean, and abstracted, and not waste
anyone's time. Why should we have to duplicate so much code?
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. IMHO the right thing to do is have a meta-port be meta-data under the master (arch) port, as opposed to having a hell of a lot of meta-ports driving and duplicating a lot from the arch-port, at least in the files list, if not in a gamillion other places. Generic endianness related information. sys/endian.h -- Implementations of swapping routines, etc., for this architecture, among other things. machine/endian.h -- Defines the endianness of this platform. platform/endian.h Early cpu startup machine_arch::locore.s::_start -- Set up things in C that are early. machine_arch::machdep.c::mach_init -- Set up hardware for this platform we need early (e.g. console, bootstrap vector, etc.) machine::machdep_machine.c::platform_init -- Continue with slightly later CPU startup... -- Call out to MI startup... -- Do that thing you do. kern::kern_main.c::mi_startup config GENERIC -- files.machine_arch -- enable standard things enable platform things -- -- make platform symlink build Etc. Follow my logic? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. I'm sorry, you use implications I don't see to come to a conclusion I don't get: Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you represent the problem you're seeing with MIPS with two entities, namely MACHINE_ARCH and MACHINE? If yes, how exactly do these entities need to be defined in that case and how do they relate to each other. If no, explain why you need more entities to capture the problem. Sure, say we support sgimips and algor MACHINE's on the mips MACHINE_ARCH. That's SGI workstations, which are big-endian and have ARCBIOS stuff, and Algorithmics development boards, which support little-endian and big-endian configurations. Obviously we have machine mips, right? But that determines what machine is a link to, and files.machine that is read. So that means that we need to have machine/*.h stubbed in both algor/ and sgimips/. Each of those defines the things they need to be defined, and then includes mips/\.h. Even if we know that we never need to have any changes, or otherwise have the abstraction the wrong way around. It also means that you have to pull in the mips options and files list for both of those ports, and so on. So you end up having machine $(MACHINE) and having to explicitly inherit bit by bit everything that you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an explicit manner. My way, machine is mips and the headers which provide tunables include platform/\.h. Optional hardware for a given platform is pulled in via files.mips optional directives. Everything is less convoluted, IMHO. No implementation details please. I did my best, but I still have to show that there are two explicit meta-ports. My previous email had no implementation details, just general structure, and you rejected it, so I hope this is better. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] But that determines what machine is a link to, and files.machine that is read. So that means that we need to have machine/*.h stubbed in both algor/ and sgimips/. Each of those defines the things they need to be defined, and then includes mips/\.h. Even if we know that we never need to have any changes, or otherwise have the abstraction the wrong way around. It also means that you have to pull in the mips options and files list for both of those ports, and so on. So you end up having machine $(MACHINE) and having to explicitly inherit bit by bit everything that you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an explicit manner. My way, machine is mips and the headers which provide tunables include platform/\.h. Optional hardware for a given platform is pulled in via files.mips optional directives. Everything is less convoluted, IMHO. No implementation details please. I did my best, but I still have to show that there are two explicit meta-ports. My previous email had no implementation details, just general structure, and you rejected it, so I hope this is better. It's different :-) What I'm trying to get at is how sgimips is the same as algor and likewise how it is different, independent as to how this would be handled in our source tree. For example: if they both use the same processor and instruction set and have the same runtime specification, you can say that they are both MIPS. The endianness is just a slight variation of the general theme. Thus (in this case), ARCH=mips and MACH=algor or MACH=sgimips... That's what I'm saying, yes. So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 04:49:55PM -0800, Juli Mallett wrote: So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. Ok. Now that we've established that the platform keyword is not needed, is there any meaning we attach to MACHINE that conflicts with the meaning it must have in order to solve the mips/powerpc problem? Or do we not attach a certain meaning to MACHINE that we should attach to it? No, we have not established that. Using machine still does not fix the machine issues. If we keep everything under mips for the mchine architecture (/sys/mips) then we need platform to get stuff from the per-$MACHINE directories in a generic way, or every $MACHINE needs to be known to the upper-level, exposing implementation details along the lines of every machine header (those are under MACHINE_ARCH _not_ MACHINE's domain, given how config works). If we keep all the meta- ports under /sys/mips then machine is /sys/mips/include, NOT e.g. /sys/mips/sgimips or /sys/mips/sgimips/include with a machine sgimips and neither is an option set to turn on optional SGIMIPS hardware. The machine keyword has NOTHING to do with the machine directory, except in the case where /sys/$MACHINE/compile/$KERNCONF is where the port ends up being built, and where the machine setting is equal to $MACHINE above. Such as pc98. I'm not talking about how pc98 works, with platform. That way is dumb and braindead and does not work. As Benno said, platform is for per-platform quirks. We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. It is, however, the same as the platform keyword. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] No, we have not established that. *sigh* Is the problem space 2D or 3D? Define your terms better. I could argue the number of axes very easily, and you could come back and argue against them. We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Unless you propose to create platform based on MACHINE in the MACHINE_ARCH != MACHINE case anyway, and use that, there is now even more duplication and obfuscation that must be done to e.g. the headers. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. I don't want to change the meaning of machine, the two things are orthogonal, but because the name is similar you want to callesce them. I want to add a new paradigm of FreeBSD ports, as well as the mechanism to do this, based on what I want to do, and the fact that it makes sense to Benno. We're just providing a set of quirks, and that should be something that fits in nicely as an addition. And it does, and it stays out of the way of things that do not need it, and provides IMO the cleanest design. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Ok, if making them the same means that we're changing the meaning of machine, then clearly you know what the meaning is now. Please tell me. Right now, it says where to get files, options, and Makefile. In the paradigm I chose to use, these are all part of the master port, rather than the meta-port. Each machine is actually closer to MACHINE_ARCH in intended meaning from config(8), as it is intended to be related to the cpu directive, e.g. machine defines the architecture, say, mips, and to go with it, you define a specific CPU, e.g. R4400. Unless you propose to create platform based on MACHINE in the MACHINE_ARCH != MACHINE case anyway, and use that, there is now even more duplication and obfuscation that must be done to e.g. the headers. I did not propose anything yet. I'm trying to understand what it is you're talking about. At the same time I'm trying to avoid defining the problem in terms of the proposed solution so that I can validate that there is a problem, whether the solution you proposes addresses that problem and see if other solutions exist that solve the problem so that we can find the best alternative. Okay, but understand I'm doing it this way as opposed to using the existing mechanism as a kludge, as that is roughly what NetBSD does, and other systems, and also similar to how we do pc98, and while that is vaguely meaningful, it ends up being messy like pc98, or like the system NetBSD has. I want to shift to a different paradigm, as discussed, and see below. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. I don't want to change the meaning of machine, the two things are orthogonal, but because the name is similar you want to callesce them. Again: what does machine mean to you. To what is it othogonal and with what do you think I want to coalesce it that has a similar name? It provides something orthogonal to what platform does, and I want it to stay that way, so that things fit below. I want to add a new paradigm of FreeBSD ports, as well as the mechanism to do this, based on what I want to do, and the fact that it makes sense to Benno. Good. What is the new paradigm? As explained, you have a master port, to the architecture, assume that it is mips ok? That's /sys/mips on FreeBSD. Each architecture port may have a number of specific platforms it supports. These map to the definitions of MACHINE_ARCH and MACHINE respectively. An architecture port then pulls in, based off the platform directive, appropriate options to have MACHINE-specific code. If we assume that is sgimips then it is headers and code in /sys/mips/sgimips. Based on the option defined in options.mips and files.mips. The build glue sees that our MACHINE_ARCH directory contains a MACHINE equivalent directory, and it sets up the platform directory, the meta-port headers, which is then used by the architecture port to tune the meta-data of the port. Like Benno put it (probably better than I did) you have an architecture, and you have MACHINE-specific quirks. Those define a platform. And a platform is meta-port data to the architecture. I feel very good about that definition, does that work for you? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Mike Barcroft [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] Benno Rice [EMAIL PROTECTED] writes: On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. That would be an interesting idea, but I don't know if the pc98 people feel like it. One of them voiced dislike for having lots of #ifdef code, as you may have seen, so I don't know. Unless we can convince them that that is cleaner and that pc98 is not a first-class port itself, which I doubt is very likely. Note that when I say first-class, I mean wholly unique architecture which should define everything, e.g. sparc64 or alpha. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] Good. What is the new paradigm? As explained, you have a master port, to the architecture, assume that it is mips ok? That's /sys/mips on FreeBSD. Each architecture port may have a number of specific platforms it supports. These map to the definitions of MACHINE_ARCH and MACHINE respectively. An architecture port then pulls in, based off the platform directive, appropriate options to have MACHINE-specific code. If we assume that is sgimips then it is headers and code in /sys/mips/sgimips. Based on the option defined in options.mips and files.mips. The build glue sees that our MACHINE_ARCH directory contains a MACHINE equivalent directory, and it sets up the platform directory, the meta-port headers, which is then used by the architecture port to tune the meta-data of the port. Like Benno put it (probably better than I did) you have an architecture, and you have MACHINE-specific quirks. Those define a platform. And a platform is meta-port data to the architecture. I feel very good about that definition, does that work for you? Yes. It's what I've been saying all along, except that I use existing variables/keywords and you don't :-) I used MACHINE_ARCH to hold the identification of the master port (mips in this case) and used MACHINE to hold the identification of the platform/implementation (sgimips in this example). So do you, except you map platform onto MACHINE, whereas I map machine onto MACHINE. Now, where I think this went wrong is that you linked this to how it is done with pc98 and how config has it implemented and that is what you don't want. You want a better (directory) structure. My explicit request to not talk in terms of implementation, but instead to keep it abstract failed to prevent that. To be perfectly clear: I think your directory structure makes sense and is better than what we do for pc98. This has on an abstract level nothing toi do with the keyword we use in config. Are we in sync? If we are in sync, we can discuss the ups and down and see what we think works best. Clearly, if we make machine equivalent to MACHINE and we want to have a directory structure as you describe, things need to change. Do we want that, is it doable. One thing is for sure: we don't need both machine and platform in a single kernel config file to do what we want. But is what we want doable with just machine? Yes, you are following me. But also, you mention that machine as implemented means what I said it means, but there is other precident for using it as I say. For example, BSD/OS uses machine sparc and options SUN4M. NetBSD uses machine in a way more similar to what you want, but like machine sgimips mips for example. What we want... Could be done with machine, if we allow there to be no files.XXX for a given machine XXX and so on, but I think this is less clear. How would you propose to write the following: %%% machine mips platformsgimips %%% Would you write it as: %%% machine mips sgimips %%% If so, how do you know which is MACHINE and which is MACHINE_ARCH? How do you accurately get a platform include directory? Certainly we don't want to make i386 do this: %%% architecturei386 machine i386 %%% Because that would be backwards... But an addition of something like platform would allow it to be orthogonal to existing structure, it would not mandate its use, of course... And so on. There's more at stake than just what we need, it also has to make sense when we don't need it, and so on. The above two things I have suggested break in dumb ways... If you just figure out the MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could define MACHINE based on the machine directive, and as such, on i386 and sparc64 and ... it would do the right thing, and it would allow the MIPS stuff to be done, but it breaks the existing pc98 stuff, because it resides in /sys/$MACHINE. I really think we need platform, and I really think it needs to come in as part of new infrastructure, as it provides something totally new which breaks in interesting ways if you don't make it optional and cleanly seperated as I've tried to do. Again, this is based off experience with a number of build systems, and the needs of PowerPC and MIPS, and also is something I run on my laptop, which is i386. It stays out of the way and only affects those explicit consumers of it. The more we discuss making machine act like platform, the more concerns that come to my head for that, and the more platform seems right to me. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about platforms. ]
On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
Yes, you are following me. But also, you mention that machine
as implemented means what I said it means, but there is other
precident for using it as I say. For example, BSD/OS uses
machine sparc and options SUN4M. NetBSD uses machine in a
way more similar to what you want, but like machine sgimips mips
for example. What we want... Could be done with machine, if we
allow there to be no files.XXX for a given machine XXX and so
on, but I think this is less clear. How would you propose to write
the following:
%%%
machine mips
platformsgimips
%%%
Would you write it as:
%%%
machine mips sgimips
%%%
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
I'm not talking only about MACHINE_ARCH, but also where the MD files
and so on are. If we moved to sys/ARCH/conf/files and so on, I'd
be more supportive of such an approach. And if we made pc98 not
dumb in this regard (with consent of their maintainers).
There's more at stake than just what we need, it also has to make
sense when we don't need it, and so on. The above two things I
have suggested break in dumb ways... If you just figure out the
MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could
define MACHINE based on the machine directive, and as such, on
i386 and sparc64 and ... it would do the right thing, and it
would allow the MIPS stuff to be done, but it breaks the existing
pc98 stuff, because it resides in /sys/$MACHINE.
Correct. I either want pc98 transformed or if that's not possible
or feasible, a keyword root, tree, directory or
nonstandardlocation to tell config(8) that the (sub-)port is
not where we normally have it. We then create a new keyword,
That sort of keyword is even more convoluted than platform.
but it explcitly means a location, a path. The introduction of
platform is more confusing. First of all it maps to MACHINE,
while we have the machine keyword mapping to something else.
MACHINE is a cpp define and (relatedly) is defined by make(1),
it isn't a config file element. Why do they have to be related
just because they by coincidence have the same name?
This is illogical. The machine keyword basicly controls
source layout and has nothing to do with the machine you're
building for. Again, illogical.
Yes it does, in a traditional meaning of machine. This is being
built for the MIPS machine, with support for the sgimips platform.
Or This is being built for the VAX [machine].
So, I'm not opposed to having a new variable if it's too hard to
do it without, but I think there's a more logical/optimal scheme
of naming and attaching meaning that does not affect the common
case (it only affects pc98).
My case affects nothing, therefore, since yours is good for only
affecting one, mine is better for only affecting none, and for working
right in every case. You don't like my choice of how, that's fine,
you don't have to maintain a port which uses it. All the more reason
for it to not be one that is even used by you at all.
I've made a note that you don't think my way is optimal. I do, and
that's that, at this point. No black magic, no convoluted config
files, etc. Go deal with the ODE config and Mach's configuration
files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am
convinced that the platform keyword is the least offensive and most
productive way of doing all of this, and so on, being someone who
has worked with more backwards methods, and being the person who
had to deal with this first, and came up with something that suits
the two groups who need it most (the pc98 mistake is probably near
impossible to correct, due to the historical nature), MIPS, and
PowerPC.
If you can convince the PowerPC folks to go with what you suggest,
then I'll be glad to also push for files, etc., to be in the proper
place, as the significance of the configuration file's contents
becoems even less important (except for the option of having a
directive point to the meta-port, which is horrid, and which I'd
really dislike seeing go in as a solution to part of these issues).
Or I suppose, since you seem to have more of a desire to re-spend
the time I spent planning this out, you could take it up with the
technical
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: but it explcitly means a location, a path. The introduction of platform is more confusing. First of all it maps to MACHINE, while we have the machine keyword mapping to something else. MACHINE is a cpp define and (relatedly) is defined by make(1), it isn't a config file element. Why do they have to be related just because they by coincidence have the same name? No, because using machine in your proposal would then be more like what MACHINE_ARCH means everywhere else. There already is confusion about the difference between MACHINE and MACHINE_ARCH and you're only adding to that confusion by using machine in the same way MACHINE_ARCH is used everywhere else. And by using machine in the same way it is used everywhere else. You don't like my choice of how, that's fine, you don't have to maintain a port which uses it. All the more reason for it to not be one that is even used by you at all. Blablabla. Your proposal affects FreeBSD. I'm having a constructive discussion about your proposal because I like to understand your point of view and tell you mine. Childish behaviour does not impress me. In fact it only tells me that you're incapable of convincing me and that you're incapable of looking at it from my point of view and tell me where I'm missing something. No, you're fixated and it took a lot of effort from my end to get to a point where we understood each other. If you're tired of it, try an open mind next time. No Marcel, I've been through your discussion already, with myself, when I first did this. I came up with the optimal way of doing it in my head, and considered all the possibilities. I also have to use it. What I was saying is that I have the need for it, and so I have had to deal with the implementation details. I've compared to every config utility I've worked with, and I've worked with the build systems of * that uses a similar mechanism, that I can get my hands on, and I prefer my way. I don't have the energy to go nowhere with you for a long time. I already went nowhere with me for a long time. I looked at it from your point of view months ago, and to make sure I didn't miss something, I looked at it from your point of view today, even made the necessary changes to the config(8) program to do it that way again, and tested it and so on. I did everything but draw out a map on a whiteboard (again). I used a piece of paper. Sorry if you find it childish to want to move on from that sort of rehashing. Not my intention, and I had no problem with our discussion. Only when I realised that you kept coming back to things I'd already been through, and I began to feel a bit over whelmed by the nature of the conversation, which was leaning towards bikeshedding, did I try to back out of it. I didn't go and give up when you were rehashing all this. When I gave up, I advised you to use your energy to come up with a working solution for this, and make it suit all the people who need it and will be affected by it, as I did. I don't doubt you could come up with something better over time, but I don't see why? If you happen to have something much, much better, please just get people to agree to it. As I have said, I already satisfied those affected (those who want to be affected), and I'm apparently not the only one who has an explicit preference of one way to the other (see what Benno has posted)... This isn't a matter of who's more childish or something, it's code, it's getting the job done, and making it possible to do the right thing. I'm sorry if that was how it seemed... And yes, I am incapable of convincing you, for now. Maybe if you spent the time on this problem I did, I could, or maybe if you had to deal with it, I could. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 10:20:52PM -0800, Juli Mallett wrote: Sorry if you find it childish to want to move on from that sort of rehashing. No, I find it childish that you revert to childish arguments when you could have said that you've gone over this before already with multiple people and that this was intended as a formality only and that you didn't want to rehash it. In fact, you could just as well have committed this :-) You're right. And I suppose it's just as well that everything is out there, and so on. Sorry it got a bit frustrating for both of us at times. I'm sorry if that was how it seemed... And yes, I am incapable of convincing you, for now. Maybe if you spent the time on this problem I did, I could, or maybe if you had to deal with it, I could. I have no problem accepting this. Maybe if I spend as much time on it as you apparently did I would have come to the same conclusion as you. It's possible that my point of view is the direct result of not having thought it through. The point is that I didn't spend the time and that I have in my head this notion that it makes sense in some other way. I think I did my best to get us in line in an attempt to find mutual understanding. I don't feel responsible for you perceiving it as bikeshedding. If it was, please tell me next time when I do it again. Thank you for trying harder to get it to the point of mutual understanding. That should have been my job, but I wasn't sure how to get you there. And you understand it your way, and maybe your understanding will lead to something better out of this, in the long run. And no, it wasn't really bikeshedding, it just began to feel that it was just a matter of but I think we should go at it from this angle when really all I intended to get was whether or not my code was OK. I fell short there, in what sort of review I wanted, or saught, or dealing with what I got. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] You see how the current approach affects other architectures if you look at the diff for src/sys/conf/kmod.mk. All architectures, including those that don't have multiple variants will have a link added that mirrors the machine link. I find that aestheticly displeasing. If you have the variants under machine, you don't have to create more links. Only within the kernel build directory. That's at Peter's request. Doing it for the installed version breaks mkioctl. The change to src/include/Makefile also seems to have a bug in that it depends in /usr/include/platform to be created by mtree, but I don't see and diff for that. Adding platform to BSD.include.dist means that every architecture gets the directory. Otherwise it has to be created by hand for those platforms that have it. I forgot to make the BSD.include.dist change. D'oh. The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. See the comment for kmod.mk. It doesn't affect anything. It can be changed, if you like. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Diff to make fsck(8) ignore certain filesystems.
This prevents fsck from failing at boot if there are nullfs or unionfs
filesystems in fstab(5), as reported by [EMAIL PROTECTED] Anyone mind
if I commit this? (Or have suggestions for filesystems to add to the
list?)
%%%
Index: fsck.c
===
RCS file: /home/ncvs/src/sbin/fsck/fsck.c,v
retrieving revision 1.12
diff -d -u -r1.12 fsck.c
--- fsck.c 31 Oct 2002 15:32:39 - 1.12
+++ fsck.c 27 Jan 2003 23:24:51 -
@@ -79,6 +79,8 @@
static int flags = 0;
static int forceflag = 0;
+static const char *nofsck[] = { nullfs, unionfs, NULL };
+
static int checkfs(const char *, const char *, const char *, char *, pid_t *);
static int selected(const char *);
static void addoption(char *);
@@ -90,6 +92,7 @@
static const char *getfslab(const char *);
static void usage(void) __dead2;
static int isok(struct fstab *);
+static int skip(const char *);
int
main(int argc, char *argv[])
@@ -209,6 +212,10 @@
errx(1, %s has unknown file system type.,
spec);
}
+ if (skip(type)) {
+ printf(%s: FILESYSTEM DOES NOT SUPPORT FSCK\n, *argv);
+ continue;
+ }
if ((flags CHECK_BACKGRD)
checkfs(type, spec, mntpt, -F, NULL) == 0) {
printf(%s: DEFER FOR BACKGROUND CHECKING\n, *argv);
@@ -577,6 +584,17 @@
return vfstype;
}
+static int
+skip(const char *fstype)
+{
+ const char *p;
+
+ for (p = nofsck[0]; p != NULL; p++) {
+ if (strcmp(p, fstype) == 0)
+ return 1;
+ }
+ return 0;
+}
static void
usage(void)
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
* De: Max Khon [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: add ext2fs to the module list in modules/Makefile ] hi, there! On Tue, Jan 28, 2003 at 12:40:12AM +0200, Enache Adrian wrote: On Mon, Jan 27, 2003 at 01:36:35PM -0800, Steve Kargl wrote: Portions of the ext2fs source are covered by the GPL. You need to rebuild the kernel with option EXT2FS. The FreeBSD cannot create a ext2fs.ko and comply with the GPL. This is weird. Builting it as part of kernel is ok, but separate, as a module isn't. IIRC NetBSD has BSD-copyrighted ext2fs implementation Closely tied to their VFS implementation, which is different, of course, last I heard it was a fairly heavy task to port it, but something a lot of people would like to see. juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Diff to make fsck(8) ignore certain filesystems.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Diff to make fsck(8) ignore certain filesystems. ] This prevents fsck from failing at boot if there are nullfs or unionfs filesystems in fstab(5), as reported by [EMAIL PROTECTED] Anyone mind if I commit this? (Or have suggestions for filesystems to add to the list?) Nevermind, it's too long since I wrote an fstab(5) by hand, and I (and the submitter) forgot about the Pass# field, and what it actually means *sigh* Sorry :/ juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xl thinkpad 600x watchdog timeout
* De: Matthew N. Dodd [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: xl thinkpad 600x watchdog timeout ] On Mon, 27 Jan 2003, Toni Schmidbauer wrote: got no useful response from -mobile so re-posting to -current: i am having problems with 5.0-REL on an ibm thinkpad 600x.the xl driver for my 3com 3ccfe575ct writes the following message to the console xl0: watchdog timeout. The 575 may require some special driver attention. I haven't had much time to look into it. Also 3c556, which is a mini-pci 56k/xl combo card, has a lot of stalls and tx issues. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tunefs using libufs.
* De: Conrad Sabatier [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: tunefs using libufs. ] I'm getting some odd behavior with tunefs (5.0-CURRENT cvsupped and built Sunday, Jan 26). If a filesystem, rather than an actual device, is specified, it spits out a weird error message regarding my linproc mount: # tunefs -p /tmp tunefs: linproc: could not find special device My /etc/fstab: # DeviceMountpoint FStype Options DumpPass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1f /tmpufs rw 2 2 /dev/ad0s1g /usrufs rw 2 2 /dev/ad0s1e /varufs rw 2 2 /dev/acd0c /cdrom cd9660 ro,noauto 0 0 /dev/acd1c /cdrom1 cd9660 ro,noauto 0 0 proc/proc procfs rw 0 0 /dev/ad1s1e /mm ufs rw 2 2 linproc /compat/linux/proc linprocfs rw 0 0 Is anyone else seeing this? Could it just be the result of the gcc optimizations I'm using (an admittedly heavy set of flags)? Or might it be related to the recent changes the OP mentioned? Now that libufs will hunt for the disk, tunefs shouldn't, that's all. Doing it both shouldn't have caused a problem, I don't think, but it does for me, too. This is caused by more-recent changes to libufs. I'll commit a fix shortly, once I verify the behaviour is correct. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
* De: David Schultz [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: add ext2fs to the module list in modules/Makefile ] Thus spake Juli Mallett [EMAIL PROTECTED]: * De: Max Khon [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: add ext2fs to the module list in modules/Makefile ] IIRC NetBSD has BSD-copyrighted ext2fs implementation Closely tied to their VFS implementation, which is different, of course, last I heard it was a fairly heavy task to port it, but something a lot of people would like to see. Does it work any better/worse than FreeBSD's implementation? Think about it: people don't have to be bothered by the license when they work on it, etc. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release still broken
* De: Ruslan Ermilov [EMAIL PROTECTED] [ Data: 2003-01-26 ] [ Subjecte: make release still broken ] Hi Juli! This is just a FYI that your patch for newfs(8) that makes it use libufs _does_ make it fit onto the MFSROOT floppy again! Okay, cool. I haven't gotten many (any?) reports of the state of newfs though. Given that it was sort of a rocky conversion due to little things newfs does different from everything else, I'd really like to know if it works to, e.g., newfs a real filesystem, and if anyone can get it to barf. I'm not comfortable committing it until that point, sadly. Just not enough data. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Patch to teach config(8) about platforms.
in /sys/param.h */
{ makeoptions, MAKEOPTIONS },
{ maxusers, MAXUSERS },
+ { platform, PLATFORM },
{ profile,PROFILE },
{ option, OPTIONS },
{ options,OPTIONS },
Only in mips/usr.sbin/config: lang.o
diff -dur src/usr.sbin/config/main.c mips/usr.sbin/config/main.c
--- src/usr.sbin/config/main.c Thu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/main.c Fri Nov 1 11:16:59 2002
@@ -164,6 +164,22 @@
srcdir, machinename);
(void) unlink(path(machine));
(void) symlink(xxx, path(machine));
+ /*
+* make symbolic link for the platform, if we have one.
+* otherwise, just fall back to using the machine (symlink).
+*/
+ if (platformname != NULL) {
+ if (*srcdir == '\0')
+ (void)snprintf(xxx, sizeof(xxx), ../../%s,
+ platformname);
+ else
+ (void)snprintf(xxx, sizeof(xxx), %s/%s/%s,
+ srcdir, machinename, platformname);
+ } else {
+ (void)snprintf(xxx, sizeof(xxx), machine);
+ }
+ (void) unlink(path(platform));
+ (void) symlink(xxx, path(platform));
options(); /* make options .h files */
makefile(); /* build Makefile */
headers(); /* make a lot of .h files */
Only in mips/usr.sbin/config: main.o
Only in mips/usr.sbin/config: mkheaders.o
Only in mips/usr.sbin/config: mkmakefile.o
diff -dur src/usr.sbin/config/mkoptions.c mips/usr.sbin/config/mkoptions.c
--- src/usr.sbin/config/mkoptions.c Thu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/mkoptions.c Sat Jan 25 02:29:58 2003
@@ -78,7 +78,20 @@
op-op_name = ns(cp-cpu_name);
op-op_next = opt;
opt = op;
- }
+ }
+
+ /* Fake the platform as an option. */
+ if (platformname != NULL) {
+ char *p;
+
+ op = (struct opt *)malloc(sizeof(*op));
+ memset(op, 0, sizeof(*op));
+ op-op_name = ns(platformname);
+ for (p = op-op_name; *p != '\0'; p++)
+ *p = toupper((unsigned char)*p);
+ op-op_next = opt;
+ opt = op;
+ }
if (maxusers == 0) {
/* printf(maxusers not specified; will auto-size\n); */
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Test this! Patch to make newfs(8) use libufs.
(36, wtfs);
- }
+ bwrite(disk, d, (char *)iobuf, sblock.fs_bsize);
}
/*
Index: newfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v
retrieving revision 1.66
diff -d -u -r1.66 newfs.c
--- newfs.c 30 Nov 2002 18:28:26 - 1.66
+++ newfs.c 23 Jan 2003 21:35:28 -
@@ -135,7 +135,6 @@
intmaxbpg; /* maximum blocks per file in a cyl group */
intavgfilesize = AVFILESIZ;/* expected average file size */
intavgfilesperdir = AFPDIR;/* expected number of files per directory */
-intfso;/* filedescriptor to device */
static chardevice[MAXPATHLEN];
static char*disktype;
@@ -261,17 +260,20 @@
special = device;
}
- fso = open(special, Nflag ? O_RDONLY : O_RDWR);
- if (fso 0)
- err(1, %s, special);
- if (fstat(fso, st) 0)
+ if (ufs_disk_fillout_blank(disk, special) == -1) {
+ if (disk.d_error != NULL)
+ errx(1, %s: %s, special, disk.d_error);
+ else
+ err(1, %s, special);
+ }
+ if (fstat(disk.d_fd, st) 0)
err(1, %s, special);
if ((st.st_mode S_IFMT) != S_IFCHR)
errx(1, %s: not a character-special device, special);
if (sectorsize == 0)
- ioctl(fso, DIOCGSECTORSIZE, sectorsize);
- if (sectorsize !ioctl(fso, DIOCGMEDIASIZE, mediasize)) {
+ ioctl(disk.d_fd, DIOCGSECTORSIZE, sectorsize);
+ if (sectorsize !ioctl(disk.d_fd, DIOCGMEDIASIZE, mediasize)) {
if (fssize == 0)
fssize = mediasize / sectorsize;
else if (fssize mediasize / sectorsize)
@@ -350,7 +352,7 @@
if (!Nflag bcmp(pp, oldpartition, sizeof(oldpartition)))
rewritelabel(special, lp);
}
- close(fso);
+ ufs_disk_close(disk);
exit(0);
}
@@ -360,7 +362,7 @@
static struct disklabel lab;
struct disklabel *lp;
- if (!ioctl(fso, DIOCGDINFO, (char *)lab))
+ if (!ioctl(disk.d_fd, DIOCGDINFO, (char *)lab))
return (lab);
unlabeled++;
if (disktype) {
@@ -378,12 +380,12 @@
return;
lp-d_checksum = 0;
lp-d_checksum = dkcksum(lp);
- if (ioctl(fso, DIOCWDINFO, (char *)lp) 0)
+ if (ioctl(disk.d_fd, DIOCWDINFO, (char *)lp) 0)
warn(ioctl (WDINFO): %s: can't rewrite disk label, s);
}
static void
-usage()
+usage(void)
{
fprintf(stderr,
usage: %s [ -fsoptions ] special-device%s\n,
Index: newfs.h
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.h,v
retrieving revision 1.8
diff -d -u -r1.8 newfs.h
--- newfs.h 21 Aug 2002 18:11:21 - 1.8
+++ newfs.h 23 Jan 2003 21:35:28 -
@@ -45,6 +45,13 @@
* $FreeBSD: src/sbin/newfs/newfs.h,v 1.8 2002/08/21 18:11:21 trhodes Exp $
*/
+/*
+ * libufs interfaces.
+ */
+#include libufs.h
+
+extern struct uufsd disk; /* the disk where we will operate */
+
/*
* variables set up by front end.
@@ -67,6 +74,5 @@
extern int maxbpg; /* maximum blocks per file in a cyl group */
extern int avgfilesize;/* expected average file size */
extern int avgfilesperdir; /* expected number of files per directory */
-extern int fso;/* filedescriptor to device */
void mkfs (struct partition *, char *);
%%%
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: /dev/dsp disappears while being used
* De: Alexander Langer [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: /dev/dsp disappears while being used ] When I then symbolically link /dev/dsp to one of the dspX.X devices, XMMS can play sound for some more time, but then these are disappearing as well. Is this a devfs bug? I almost think so, but I'm not sure. Not sure. I always just get dsp to re-appear (I think it gets re- cloned) by doing cat /dev/dsp0.0 for a second. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ] On Thu, 23 Jan 2003, Juli Mallett wrote: Thanks to Ruslan's reminder that tunefs now uses libufs and tunefs is one of the crunched programs, I realised that I really needed to make newfs(8) use libufs. To show off that it *can* help us reduce space, a good bit in some cases. Good to see this. Does libufs do an fsync() in bwrite() or do you need to do that manually in place of the previous calls to wtfsflush()? It doesn't. Do you think it should? I'd rather do that than litter the newfs code. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Test this! Patch to make newfs(8) use libufs. ] [rambling, and a patch] I thought every bit of code that would possibly write out was protected by Nflag, it isn't. I'll re-instate the wtfs function as a wrapper to bwrite which checks Nflag. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ] * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Test this! Patch to make newfs(8) use libufs. ] [rambling, and a patch] I thought every bit of code that would possibly write out was protected by Nflag, it isn't. I'll re-instate the wtfs function as a wrapper to bwrite which checks Nflag. Here: http://people.freebsd.org/~jmallett/newfs-libufs.diff -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ] On Thu, 23 Jan 2003, Juli Mallett wrote: * De: Nate Lawson [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ] On Thu, 23 Jan 2003, Juli Mallett wrote: Thanks to Ruslan's reminder that tunefs now uses libufs and tunefs is one of the crunched programs, I realised that I really needed to make newfs(8) use libufs. To show off that it *can* help us reduce space, a good bit in some cases. Good to see this. Does libufs do an fsync() in bwrite() or do you need to do that manually in place of the previous calls to wtfsflush()? It doesn't. Do you think it should? I'd rather do that than litter the newfs code. Not needed. On second look, I see you removed the wc[] caching and fall back to just write(). (BTW, what's the performance difference with your patch?) If newfs doesn't complete successfully due to a system crash, it doesn't matter if data written was flushed to disk, just run it again. *nod*. Not to mention that I don't think you need it for writing to a raw device? As for performance, I don't know. Test it and find out? :) -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-23 ]
[ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ]
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2003-01-23 ]
[ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ]
On Thu, 23 Jan 2003, Juli Mallett wrote:
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2003-01-23 ]
[ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ]
On Thu, 23 Jan 2003, Juli Mallett wrote:
Thanks to Ruslan's reminder that tunefs now uses libufs and tunefs is
one of the crunched programs, I realised that I really needed to make
newfs(8) use libufs. To show off that it *can* help us reduce space,
a good bit in some cases.
Good to see this. Does libufs do an fsync() in bwrite() or do you need to
do that manually in place of the previous calls to wtfsflush()?
It doesn't. Do you think it should? I'd rather do that than litter the
newfs code.
Not needed. On second look, I see you removed the wc[] caching and fall
back to just write(). (BTW, what's the performance difference with your
patch?) If newfs doesn't complete successfully due to a system crash, it
doesn't matter if data written was flushed to disk, just run it again.
*nod*. Not to mention that I don't think you need it for writing to a raw
device?
As for performance, I don't know. Test it and find out? :)
I just went to do this, and found that pwrite is failing, saying EBADF.
Could this be because of the failed ioctl? I'm not sure why this is
happening. Any thoughts would be appreciated.
12228 newfsRET open 4
12228 newfsCALL fstat(0x4,0xbfbff798)
12228 newfsRET fstat 0
12228 newfsCALL ioctl(0x4,DIOCGSECTORSIZE,0x80509c0)
12228 newfsRET ioctl 0
12228 newfsCALL ioctl(0x4,DIOCGMEDIASIZE,0xbfbff790)
12228 newfsRET ioctl 0
12228 newfsCALL ioctl(0x4,DIOCGDINFO,0x8050480)
12228 newfsRET ioctl -1 errno 25 Inappropriate ioctl for device
12228 newfsCALL gettimeofday(0xbfbff5c8,0)
12228 newfsRET gettimeofday 0
12228 newfsCALL open(0x28111300,0,0)
12228 newfsNAMI /dev/random
12228 newfsRET open 5
12228 newfsCALL read(0x5,0x2811d0a4,0x7c)
12228 newfsGIO fd 5 read 124 bytes
\^A9\M^I\^S\M-`b\M^Y\M-T~\M-I\b{\M-mN\M-b\M-{(\^Q\M-k|n\M-( :\M-pA\
S\^Y\M-|\M-m\M^P\M-M*\M-%\^_e\M^G\M-v\M-H\M-;2*\M-e\M-E\M-d\M^Y\M^U=\
\^WrB\^S\M-*\^UuL\0\M-=\M-M7@i\M-t`\M^Y\M-+\M-U\M^X\M-jA{\M-L cq_TvW\
\^_\M-5\M-Af\M-)\^TP8
\^U\M-.
*\^V\^^\M-=\^R\M-e\M-'I\M-Tm\M^BY\M^M\M-W\M^JZ\M-y\240gX\M-=\M^Z\M-)\0\
\^P\^R\M^]\^Xq\M-F0\M-3
12228 newfsRET read 124/0x7c
12228 newfsCALL close(0x5)
12228 newfsRET close 0
12228 newfsCALL pwrite(0x4,0x8050a24,0x200,0,0x1fff,0)
12228 newfsRET pwrite -1 errno 9 Bad file descriptor
I didn't notice this before as the test ran fine :/ Last time I trust a test
I didn't write to be honest. Also, forget to check the return value of code.
Any help would be appreciated.
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Test this! Patch to make newfs(8) use libufs.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: Re: Test this! Patch to make newfs(8) use libufs. ] I just went to do this, and found that pwrite is failing, saying EBADF. Could this be because of the failed ioctl? I'm not sure why this is happening. Any thoughts would be appreciated. It was because bwrite/sbwrite were wrong wrt which opened things writable. Now the patch at the URL elsewhere in this thread works. The remaining bug was that disk.d_bsize had to be set to the sectorsize, or things to work as newfs needs them to. Where can I pick up my dunce cap? Here's the URL once more: http://people.freebsd.org/~jmallett/newfs-libufs.diff Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release fails building floppies ...
* De: Marc G. Fournier [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: make release fails building floppies ... ] I'm slowly getting closer, but am not quite there yet :( I'm at the stage where its building teh floppies, but its telling me that the md devices are out of disk space: This is probably my fault, since tunefs(8) needs libufs now. Converting other things that could use it that are on the floppies to use libufs would be a start. My newfs changes might be enough. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: cleaned vnode isn't
I (today) got a panic, panic: cleaned vnode isn't. My kernel does not have debugging symbols (I'll rebuild one that does shortly), but here is the bt: #0 0xc023ee50 in doadump () #1 0xc023f2fd in boot () #2 0xc023f557 in panic () #3 0xc0279cf1 in bremfree () #4 0xc027c423 in getblk () #5 0xc0279e0f in breadn () #6 0xc0279dc0 in bread () #7 0xc02d9245 in ffs_update () #8 0xc02eb514 in ffs_fsync () #9 0xc02ea7b5 in ffs_sync () #10 0xc028b9e6 in sync () #11 0xc023ef45 in boot () #12 0xc023f557 in panic () #13 0xc02870eb in getnewvnode () #14 0xc02eaa54 in ffs_vget () #15 0xc02f3152 in ufs_lookup () #16 0xc02f9573 in ufs_vnoperate () #17 0xc027ed31 in vfs_cache_lookup () #18 0xc02f9573 in ufs_vnoperate () #19 0xc0282dd5 in lookup () #20 0xc02827e0 in namei () #21 0xc028e10a in lstat () #22 0xc0347d52 in syscall () #23 0xc03393ed in Xint0x80_syscall () ---Can't read userspace from dump, or kernel process--- Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pcm panic (dsp_write nonbusy channel)
lock order reversal 1st 0xc12602c0 pcm0:play:0 (pcm channel) @ ../../../dev/sound/pcm/sound.c:191 2nd 0xc1260440 pcm0 (sound cdev) @ ../../../dev/sound/pcm/sound.c:163 acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ ../../../dev/sound/pcm/dsp.c:328 2nd pcm0:play:0 @ ../../../dev/sound/pcm/dsp.c:335 Expensive timeout(9) function: 0xc0244c80(0xc0a06e00) 0.001034076 Expensive timeout(9) function: 0xc024da60(0) 0.001427603 panic: dsp_write: nonbusy channel Bt: #13 0xc01d61c1 in dsp_write () #14 0xc0200911 in spec_write () #15 0xc0200313 in spec_vnoperate () #16 0xc0292d27 in vn_write () #17 0xc025ed74 in dofilewrite () #18 0xc025ec1b in write () #19 0xc0347d52 in syscall () #20 0xc03393ed in Xint0x80_syscall () At the time I was listening to an mp3 in a loop. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM_METER no longer defined?
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2003-01-18 ] [ Subjecte: Re: VM_METER no longer defined? ] On Sat, Jan 18, 2003 at 02:40:45PM -0700, Scott Long wrote: a line like #warning VM_METER is deprecated and will be removed on kluctember 43, 2861 would be nice to, of course. =-) I wanted this, but I don't know who to implement it so that it only prints out IIF VM_METER is used somewhere in 3rd party code. Could you do something like define VM_METER to some libc symbol that is a constant zero, and then warn on link-time reference? -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
badsect testers?
Can someone who actually uses badsect, or who has clue about it, test this diff, to make it use libufs? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: badsect testers?
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-18 ]
[ Subjecte: badsect testers? ]
Can someone who actually uses badsect, or who has clue about it, test this
diff, to make it use libufs?
Err, THIS diff.
%%%
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/badsect/Makefile,v
retrieving revision 1.5
diff -d -u -r1.5 Makefile
--- Makefile4 Dec 2001 02:19:44 - 1.5
+++ Makefile19 Jan 2003 03:17:32 -
@@ -4,5 +4,6 @@
PROG= badsect
WARNS= 0
MAN= badsect.8
+LDADD= -lufs
.include bsd.prog.mk
Index: badsect.c
===
RCS file: /home/ncvs/src/sbin/badsect/badsect.c,v
retrieving revision 1.16
diff -d -u -r1.16 badsect.c
--- badsect.c 27 Nov 2002 02:18:56 - 1.16
+++ badsect.c 19 Jan 2003 03:17:32 -
@@ -65,37 +65,21 @@
#include err.h
#include dirent.h
#include fcntl.h
+#include libufs.h
#include paths.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
-union {
- struct fs fs;
- charfsx[SBLOCKSIZE];
-} ufs;
-#define sblock ufs.fs
-union {
- struct cg cg;
- charcgx[MAXBSIZE];
-} ucg;
-#defineacg ucg.cg
-struct fs *fs;
-intfso, fsi;
+#define sblock disk.d_fs
+#defineacg disk.d_cg
+struct uufsd disk;
+struct fs *fs = sblock;
interrs;
-long dev_bsize = 1;
-char buf[MAXBSIZE];
-
-void rdfs(daddr_t, int, char *);
intchkuse(daddr_t, int);
-/*
- * Possible superblock locations ordered from most to least likely.
- */
-static int sblock_try[] = SBLOCKSEARCH;
-
static void
usage(void)
{
@@ -137,23 +121,12 @@
(u_long)stbuf.st_rdev, argv[1]);
exit(5);
}
- if ((fsi = open(name, O_RDONLY)) 0)
- err(6, %s, name);
- fs = sblock;
- for (i = 0; sblock_try[i] != -1; i++) {
- rdfs(sblock_try[i] / dev_bsize, SBLOCKSIZE, (char *)fs);
- if ((fs-fs_magic == FS_UFS1_MAGIC ||
-(fs-fs_magic == FS_UFS2_MAGIC
- fs-fs_sblockloc == sblock_try[i]))
- fs-fs_bsize = MAXBSIZE
- fs-fs_bsize = sizeof(struct fs))
- break;
- }
- if (sblock_try[i] == -1) {
- printf(Cannot find file system\n);
- exit(7);
+ if (ufs_disk_fillout(disk, name) == -1) {
+ if (disk.d_error != NULL)
+ errx(6, %s: %s, name, disk.d_error);
+ else
+ err(7, %s, name);
}
- dev_bsize = fs-fs_fsize / fsbtodb(fs, 1);
for (argc -= 2, argv += 2; argc 0; argc--, argv++) {
number = atol(*argv);
if (chkuse(number, 1))
@@ -175,6 +148,7 @@
errs++;
}
}
+ ufs_disk_close(disk);
printf(Don't forget to run ``fsck %s''\n, name);
exit(errs);
}
@@ -204,8 +178,11 @@
return (1);
}
}
- rdfs(fsbtodb(fs, cgtod(fs, cg)), (int)sblock.fs_cgsize,
- (char *)acg);
+ if (cgread1(disk, cg) != 1) {
+ fprintf(stderr, cg %d: could not be read\n, cg);
+ errs++;
+ return (1);
+ }
if (!cg_chkmagic(acg)) {
fprintf(stderr, cg %d: bad magic number\n, cg);
errs++;
@@ -215,23 +192,4 @@
if (isclr(cg_blksfree(acg), bn))
printf(Warning: sector %ld is in use\n, (long)blkno);
return (0);
-}
-
-/*
- * read a block from the file system
- */
-void
-rdfs(daddr_t bno, int size, char *bf)
-{
- int n;
-
- if (lseek(fsi, (off_t)bno * dev_bsize, SEEK_SET) 0) {
- printf(seek error: %ld\n, (long)bno);
- err(1, rdfs);
- }
- n = read(fsi, bf, size);
- if (n != size) {
- printf(read error: %ld\n, (long)bno);
- err(1, rdfs);
- }
}
%%%
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC3 working great, but NOTES incomplete?
* De: Craig R [EMAIL PROTECTED] [ Data: 2003-01-18 ] [ Subjecte: 5.0-RC3 working great, but NOTES incomplete? ] I got 5.0-RC3 working great on my box today, but when I went to make a custom kernel and read NOTES I noticed that it makes no mention of IPFIREWALL and friends. Is this intentional? craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES craig@boss:~$ Nothing shows up. What's the scoop? Run 'make LINT' and base your kernel off of LINT. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
