Re: devfs configuration
Attila Nagy [EMAIL PROTECTED] wrote: Hello, Is there a recommended way to configure multiple devfs rules (massive jail usage) in a standard manner? I don't see any traces of it. Or is it up to the user how does he manage this question, for example a shell script with the rules? There is currently no standard way to do this. I described a way it might be implemented to freebsd-arch some time ago, but I recieved very few comments, and have not implemented it due to lack of time. The proposal is here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2002/freebsd-arch/20020804.freebsd-arch If that mechanism can be used to do what you want (I think it can be), and you end up implementing it, I will gladly help get it into the tree. Thanks, Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs configuration
Taavi Talvik [EMAIL PROTECTED] wrote: On Fri, 10 Jan 2003, Attila Nagy wrote: Is there a recommended way to configure multiple devfs rules (massive jail usage) in a standard manner? I don't see any traces of it. Or is it up to the user how does he manage this question, for example a shell script with the rules? If you are using devfs in jail, then following patch to current (by Dima Dorfman [EMAIL PROTECTED]) is extremely useful. Allows tules to work on symlinks (for example /dev/urandom is symlink and ssh works better if it is present). Oops, I forgot to commit that, didn't I? Rectified now in -CURRENT, but you'll still need to apply it if you're running RELENG_5_0. Thanks for the reminder. Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs rules and symbolik links
Taavi Talvik [EMAIL PROTECTED] wrote: I'i try to set up jail with following script, however as result, urandom/stdin/stdout/stderr will not appear. They exist before applying devfs rules, but I cannot find rules how to unhide those. Any ideas!? Please try the attached patch, which should be able to match symlinks based on pathname in order to unhide them. This is only lightly tested, and I'm not entirely sure why I didn't do this before (ISTR having trouble getting it to work, but this seems absurdly logical and simple), but it seems to work. phk, does this look okay to you? Dima. Index: devfs_rule.c === RCS file: /a/ncvs/src/sys/fs/devfs/devfs_rule.c,v retrieving revision 1.3 diff -u -r1.3 devfs_rule.c --- devfs_rule.c8 Oct 2002 04:21:54 - 1.3 +++ devfs_rule.c2 Dec 2002 21:20:04 - @@ -634,7 +634,8 @@ dev = devfs_rule_getdev(de); if (dev != NULL) pname = dev-si_name; - /* XXX: Support symlinks (check d_type == DT_LNK here). */ + else if (de-de_dirent-d_type == DT_LNK) + pname = de-de_dirent-d_name; else return (0); KASSERT(pname != NULL, (devfs_rule_matchpath: NULL pname)); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Anyone seeing snp(4) problems?
Juli Mallett [EMAIL PROTECTED] wrote: I just tried to sudo watch ttyv1 and ran into the following: % Fatal trap 12: page fault while in kernel mode ... Looks like use of a NULL structure, accessing member at offsetof==0x60? Anyway, I couldn't get a dump, but I'll keep trying... Also this kernel is a bit stale, but it'll take a while to get the kernel on this box updated, so I figured I'd go ahead and post now, and try with a new one when I can. Is snp loaded from a module, and if it is, are the modules in sync with the kernel? I tried the above command on a -current about a month old and it works for me. If something broke recently, I'm interested in tracebacks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the status of devfs(8)?
Andrew Lankford [EMAIL PROTECTED] wrote: When I try commands like: #devfs rule add path speaker mode 666 Did you set a ruleset before this? devfs ruleset 10 devfs rule: ioctl DEVFSIO_RADD: Input/output error This is telling you that you're trying to modify ruleset 0. From the man page: Ruleset number 0 is the default ruleset for all new mount-points. It is always empty, cannot be modified or deleted, and does not show up in the output of showsets. but /dev/devctl is in my /dev (devfs) partition. Actually, /dev/devctl is related to devd(8), not devfs(8). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the status of devfs(8)?
Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Nov 05), Dima Dorfman said: Andrew Lankford [EMAIL PROTECTED] wrote: devfs rule: ioctl DEVFSIO_RADD: Input/output error This is telling you that you're trying to modify ruleset 0. From the man page: Ruleset number 0 is the default ruleset for all new mount-points. It is always empty, cannot be modified or deleted, and does not show up in the output of showsets. Then it should return EPERM, EACCESS, EINVAL, or basically anything except EIO, imho. I'm not particularly attached to EIO. I wanted something different, though, so when I see posts like this, i know what the problem is. Perhaps I should document devfs's esoteric meanings for error numbers--it has quite a few of them. I got bit by this as well, and thought /sbin/devfs was simply broken or not fully coded until I saw this post. That one can't modify ruleset 0 is documented copiously in the man page, and all the examples are preceeded by devfs ruleset 10 (see the first sentence in the EXAMPLES section). Since this doesn't appear to be enough, perhaps you (or anyone, for that matter) could suggest a better way to communicate this requirement? Or maybe allow ruleset 0 to be modified like any other? Is there a benefit to having an invisible, immutable default ruleset? phk and I had a long discussion about this, and the conclusion was that it is indeed useful, sort of like having a NULL pointer is useful. I can go through my archives if you're interested in details. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the status of devfs(8)?
Dan Nelson [EMAIL PROTECTED] wrote: to. Maybe /sbin/devfs could check which set is active and print an error message like Cannot modify ruleset 0 if a user tries to mess with it? That would let the user know that rulesets are important and they had better go reread the manpage. I just sent a patch to do that. Or alternatively, change that example /dev/speaker rule in the manpage to devfs rule apply path speaker mode 666, so that people who only care about fixing the speaker permissions (like me and apparently Andrew Lankford) can just stick that command in /etc/rc.local and be done :) The example was really meant to describe This is how things are done, not This is how to fix the speaker permissions. Ideally the way I want people to do this is to put something like this in rc.conf: devfs_ruleset_10=/etc/devfs.rules.10 and put their rules into /etc/devfs.rules.10 like this: path speaker mode 660 Of course, that isn't implemented yet. I should probably try to get to that before 5.0-RELEASE . . . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usermount with devfs
Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Lars Eggert writes: So there is no more usermount under -current with devfs? Or is there another way to have the symlinks be created with the different permissions (since devfs rules don't seem to apply to them)? Symlinks permissions are not used in FreeBSD, only the permissions of whatever they point at is used. Do we think that devfs rules *should* apply to symlinks? I couldn't quite make it work when I tried before, but I didn't try very hard, so it's probably doable if it's desirable. Is it desirable, though? As phk points out, symlink permissions aren't used, so is there a reason besides aesthetics that one would want to change them? Likewise for ownership. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DEVFS rule subsystem (was: cvs commit: src/sbin Makefile src/sbin/devfs Makefile devfs.8 devfs.c extern.h rule.c src/sys/conf files src/sys/fs/devfs devfs.h devfs_devs.c devfs_rule.c devfs_vfsops.c devfs_vnops.c )
Sheldon Hearn [EMAIL PROTECTED] wrote: On (2002/07/17 01:52), Dima Dorfman wrote: The devfs(8) manual page is a pretty good reference of the existing features and semantics, but it lacks polish needed to be able to serve as an introduction. Actually, I think it's brilliant. The only nits are the weird sections, which made it hard for me to find my way around. For example, the examples are all in an Examples subsection of the non-standard RULE SUBSYSTEM section, so I didn't see that there were examples when I first looked for them. I'd suggest the attached patch, to make it easier for manpage die-hards to navigate. The reason everything is written under subsections is that /sbin/devfs is not, in theory, limited to just rule manipulation. I don't really like how I did it, either, but if I write everything under standard sections like you suggest, adding non-rule stuff to devfs(8) will be a much bigger pain. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DEVFS rule subsystem (was: cvs commit: src/sbin Makefile src/sbin/devfs Makefile devfs.8 devfs.c extern.h rule.c src/sys/conf files src/sys/fs/devfs devfs.h devfs_devs.c devfs_rule.c devfs_vfsops.c devfs_vnops.c )
I wrote: Log: Introduce the DEVFS rule subsystem. DEVFS rules permit the administrator to define certain properties of new devfs nodes before they become visible to the userland. Both static (e.g., /dev/speaker) and dynamic (e.g., /dev/bpf*, some removable devices) nodes are supported. Each DEVFS mount may have a different ruleset assigned to it, permitting different policies to be implemented for things like jails. This isn't entirely complete (e.g., globbing isn't implemented), but I think it works well enough for most purposes. I would appreciate it if people would try it and see whether it does what they want it to do (especially all of those people that have been asking for something like this since DEVFS became standard!). The devfs(8) manual page is a pretty good reference of the existing features and semantics, but it lacks polish needed to be able to serve as an introduction. As a starting point, try the following (you need to be root to do this stuff, of course): devfs rule -s 10 add path 'bpf*' group wheel mode 660 devfs ruleset 10 This should permit users in the wheel group to use the bpf devices (generally this probably isn't a good idea, but it's a good example, and easy to test). To test it, just run tcpdump as a non-root user in wheel; it should work unless you already have bpf devices with old permissions (rules are applied when the node is created (make_dev(9)), or if explicitly requested); in that case, you can do: devfs rule applyset to make your rules take effect on all current nodes. Some things to note about the above (this is all described in devfs(8)): if a mount-point isn't specified, /dev is assumed; if a ruleset isn't explicitly specified (command 3), the one associated with the mount-point you're using is assumed; globbing for the path argument isn't working yet (only a trailing asterisk is supported right now). At the moment, I'm not sure where people should be putting devfs commands to be run at boot time. I think hijacking /etc/rc.devfs for this purpose (a la rc.firewall) is probably the best idea, but if some of the rc hackers have better ideas, please let us (me) know. Questions and comments are most welcome. In particular, if you use this with removable devices (e.g., USB), I'd like to hear about it. I haven't had much of an opportunity to test this with different removable devices, and I'd like to know how well it works in such an environment. Thanks, Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mergemaster(8) broken -- uses Perl
Paul Herman [EMAIL PROTECTED] wrote: On Sun, 19 May 2002, Dima Dorfman wrote: How about fixing ls(1) to output the numeric mode if asked to? That's good, but while you're at it you'd probably want to get *everything* out of (struct stat) and print it numerically (device, flags, atime since epoch, etc.) You could do this in ls(1), but I'll have a patch for fstat(1) soon (working on it) that gives you: bash$ /usr/obj/usr/src/usr.bin/fstat/fstat -s /tmp /kernel INODE DEVSIZE BLOCKS MODE FLAGS LNK UID GID ATIME MTIME CTIME NAME 235226304 4114305 8096 100555 40 1 0 0 1021779222 10217403541021740354 /kernel 56651 226304 512 4 041777 00 6 0 0 1021787523 10217876571021787657 /tmp so you can parse it however you like. Either way, ls(1) or fstat(1), as long as you can get the info you need. :-) This looks much better than my extention. I look forward to seeing this get into the tree. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mergemaster(8) broken -- uses Perl
Giorgos Keramidas [EMAIL PROTECTED] wrote:
On 2002-05-18 11:54, David O'Brien wrote:
Anyone got a patch?
Part of the problems I had when I tried to replace perl in
mergemaster.sh with something `native' was that the perl code uses
stat(2) to obtain the permission bits of a directory/file and I can't
think of a way to do this with tools in the base system without
resorting to ugly awk scripts that parse and translate ls(1) output.
How about fixing ls(1) to output the numeric mode if asked to? E.g.,
instead of
% /bin/ls -ld /tmp | sed -e 's/[[:space:]].*$//' |\
awk -v mode=0 '{
[...]
/bin/ls -ldN /tmp | awk '{ print $1 }'
A proof-of-concept (i.e., not polished or fully-tested (in particular,
it lacks a manual page update)) patch to implement ls -N is attached
below. I've wanted this feature a number of times in the past, but
never had occasion to actually implement it until now. Note also that
if this is used in mergemaster, we need to deal with the issue of what
to do if mergemaster is run on a system that doesn't have this option
yet (perhaps try it first, and fall back to Perl (which should exist
on systems without ls -N) if it doesn't work?).
Index: ls.c
===
RCS file: /ref/cvsf/src/bin/ls/ls.c,v
retrieving revision 1.56
diff -u -r1.56 ls.c
--- ls.c19 Feb 2002 00:05:50 - 1.56
+++ ls.c19 May 2002 05:49:53 -
@@ -106,6 +106,7 @@
static int f_nosort; /* don't sort output */
int f_notabs; /* don't use tab-separated multi-col output */
static int f_numericonly; /* don't convert uid/gid to name */
+ int f_numeric_mode; /* don't convert file modes to a string */
int f_octal;/* show unprintables as \xxx */
int f_octal_escape; /* like f_octal but use C escapes if possible */
static int f_recursive;/* ls subdirectories also */
@@ -167,7 +168,7 @@
f_listdot = 1;
fts_options = FTS_PHYSICAL;
- while ((ch = getopt(argc, argv, 1ABCFGHLPRTWZabcdfghiklnoqrstuw)) != -1) {
+ while ((ch = getopt(argc, argv, 1ABCFGHLNPRTWZabcdfghiklnoqrstuw)) != -1) {
switch (ch) {
/*
* The -1, -C and -l options all override each other so shell
@@ -246,6 +247,9 @@
break;
case 'n':
f_numericonly = 1;
+ break;
+ case 'N':
+ f_numeric_mode = 1;
break;
case 'o':
f_flags = 1;
Index: ls.h
===
RCS file: /ref/cvsf/src/bin/ls/ls.h,v
retrieving revision 1.17
diff -u -r1.17 ls.h
--- ls.h3 Feb 2002 19:11:32 - 1.17
+++ ls.h19 May 2002 05:49:07 -
@@ -48,6 +48,7 @@
extern int f_lomac;/* show LOMAC attributes */
extern int f_inode;/* print inode */
extern int f_longform; /* long listing format */
+extern int f_numeric_mode; /* don't convert file modes to a string */
extern int f_octal;/* print unprintables in octal */
extern int f_octal_escape; /* like f_octal but use C escapes if possible */
extern int f_nonprint; /* show unprintables as ? */
Index: print.c
===
RCS file: /ref/cvsf/src/bin/ls/print.c,v
retrieving revision 1.53
diff -u -r1.53 print.c
--- print.c 25 Feb 2002 01:36:59 - 1.53
+++ print.c 19 May 2002 05:49:30 -
@@ -177,7 +177,10 @@
if (f_size)
(void)printf(%*lld ,
dp-s_block, howmany(sp-st_blocks, blocksize));
- strmode(sp-st_mode, buf);
+ if (f_numeric_mode)
+ snprintf(buf, sizeof(buf), %.6o, sp-st_mode);
+ else
+ strmode(sp-st_mode, buf);
np = p-fts_pointer;
(void)printf(%s %*u %-*s %-*s , buf, dp-s_nlink,
sp-st_nlink, dp-s_user, np-user, dp-s_group,
Index: util.c
===
RCS file: /ref/cvsf/src/bin/ls/util.c,v
retrieving revision 1.29
diff -u -r1.29 util.c
--- util.c 28 Feb 2002 18:52:47 - 1.29
+++ util.c 19 May 2002 05:50:08 -
@@ -158,9 +158,9 @@
{
(void)fprintf(stderr,
#ifdef COLORLS
- usage: ls [-ABCFGHLPRTWZabcdfghiklnoqrstu1]
+ usage: ls [-ABCFGHLNPRTWZabcdfghiklnoqrstu1]
#else
- usage: ls [-ABCFHLPRTWZabcdfghiklnoqrstu1]
+ usage: ls [-ABCFHLNPRTWZabcdfghiklnoqrstu1]
#endif
[file ...]\n);
exit(1);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mdmfs mount_mfs compatibility bug?
Ian Dowse [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Jos Backus writes: This was fixed some time ago, I thought. Are you up to date? There was a commit to mdmfs.c in August. This is with yesterday's -current, sorry, should have mentioned that. The mount -t mfs case doesn't work with mdmfs, because mount(8) uses the filesystem name, not the mount_xxx program as argv[0]. This seems to violate POLA. Would something break if it was changed to use mount_xxx (unforunately, I'm ~ 200 km away from my -current box at the moment, so I can't try it myself)? I had guessed this would be a problem when I read the commit message for revision 1.7 of mdmfs.c, but then I forgot to mention it to Dima. Here is a patch that should help - it makes mdmfs accept mount_mfs or mfs to trigger compatibility mode instead of mount_*. The problem with this is that in a bikeshed far, far in the past, some people wanted to me able to call it mount_md instead of mount_mfs. Of course, we could allow mfs and md, but that seems rather ugly (what if someone wants fish?). I'd rather see mount(8) use mount_xxx, although if we think that would break something, your patch is probably the best solution. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pw group add problem
David W. Chapman Jr. [EMAIL PROTECTED] wrote:
When I run the command in the topic I get the following error.
pw: group update: Inappropriate ioctl for device
This works in -stable
I noticed this problem while testing postfix-current which runs
/usr/sbin/pw groupadd ${group} -h - || exit
from pkg-install and also gives the above error message.
This should be fixed in rev 1.10 of src/usr.sbin/pw/grupd.c.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: md/mdmfs bugs
Kris Kennaway [EMAIL PROTECTED] writes: 1) For some reason, my mdmfs line in /etc/fstab always does a chmod 777 /tmp at mount-time /dev/md0/tmpmfs rw,-s=65536 0 0 As previously threatened, I implemented bug-to-bug compatibility with mount_mfs(). The patch is attached below. Please try it and see if it fixes this problem. Here's an excerpt from the manual page that roughly describes what I did: COMPATIBILITY mdmfs, while designed to be fully compatible with mount_mfs(8), can be useful by itself. Since mount_mfs(8) has some silly defaults, a ``full compatibility'' mode is provided for the case where bug-to-bug compati- bility is desired. Full compatibility is enabled with the -C flag, or by starting mdmfs with mount_ at the beginning of its name (as returned by getprogname(3)). In this mode, only the options which would be accepted by mount_mfs(8) are valid. Furthermore, the following behavior, as done by mount_mfs(8), is duplicated: o The file mode of mount-point is set to 01777 as if -p 1777 was given on the command line. If you have a link from /sbin/mount_mfs to /sbin/mdmfs, you don't need to worry about all that stuff. Just apply the patch below, build it, copy it to /sbin, and umount/mount /tmp; it should DTRT. Please let me know how it works out. Thanks. Index: mdmfs.8 === RCS file: /ref/cvsf/src/sbin/mdmfs/mdmfs.8,v retrieving revision 1.6 diff -u -r1.6 mdmfs.8 --- mdmfs.8 2001/07/30 09:13:21 1.6 +++ mdmfs.8 2001/08/05 00:17:02 @@ -25,7 +25,7 @@ .\ .\ $FreeBSD: src/sbin/mdmfs/mdmfs.8,v 1.6 2001/07/30 09:13:21 dd Exp $ .\ -.Dd May 26, 2001 +.Dd August 5, 2001 .Dt MDMFS 8 .Os .Sh NAME @@ -35,7 +35,7 @@ driver .Sh SYNOPSIS .Nm -.Op Fl DLMNSX +.Op Fl DLMNSUX .Op Fl a Ar maxcontig .Op Fl b Ar block-size .Op Fl c Ar cylinders @@ -53,6 +53,24 @@ .Op Fl w Ar user : Ns Ar group .Ar md-device .Ar mount-point +.Nm +.Fl C +.Op Fl NU +.Op Fl a Ar maxcontig +.Op Fl b Ar block-size +.Op Fl c Ar cylinders +.Op Fl d Ar rotdelay +.Op Fl e Ar maxbpg +.Op Fl F Ar file +.Op Fl f Ar frag-size +.Op Fl i Ar bytes +.Op Fl m Ar percent-free +.Op Fl n Ar rotational-positions +.Op Fl O Ar optimization +.Op Fl o Ar mount-options +.Op Fl s Ar size +.Ar md-device +.Ar mount-point .Sh DESCRIPTION The .Nm @@ -110,6 +128,13 @@ option). .It Fl b Ar block-size The block size of the filesystem, in bytes. +.It Fl C +Enable full compatibility mode with +.Xr mount_mfs 8 . +See the +.\ XXX link to another section? +.Em COMPATIBILITY +section for more information. .It Fl c Ar cylinders The number of cylinders per cylinder group in the filesystem. .It Fl D @@ -192,6 +217,13 @@ .Xr malloc 9 backed disks .Pq Dv MD_MALLOC . +.It Fl U +Enable soft-updates on the filesystem. +This is the default, even in compatibility mode, and is accepted only +for compatibility. +It is only really useful to negate the +.Fl S +flag, should such a need occur. .It Fl w Ar user : Ns Ar group Set the owner and group to .Ar user @@ -257,8 +289,46 @@ .Cm async : .Pp .Dl mdmfs -M -S -o async -s 16m md1 /tmp +.Sh COMPATIBILITY +.Nm , +while designed to be fully compatible with +.Xr mount_mfs 8 , +can be useful by itself. +Since +.Xr mount_mfs 8 +has some silly defaults, a +.Dq full compatibility +mode is provided for the case where bug-to-bug compatibility is desired. +.Pp +Full compatibility is enabled with the +.Fl C +flag, +or by starting +.Nm +with +.Li mount_ +at the beginning of its name +(as returned by +.Xr getprogname 3 ) . +In this mode, only the options which would be accepted by +.Xr mount_mfs 8 +are valid. +Furthermore, the following behavior, as done by +.Xr mount_mfs 8 , +is duplicated: +.Bl -bullet -offset indent -compat +.It +The file mode of +.Ar mount-point +is set to +.Li 01777 +as if +.Fl p Ar 1777 +was given on the command line. +.El .Sh SEE ALSO .Xr md 4 , +.Xr fstab 5 , .Xr disklabel 8 , .Xr mdconfig 8 , .Xr mount 8 , Index: mdmfs.c === RCS file: /ref/cvsf/src/sbin/mdmfs/mdmfs.c,v retrieving revision 1.5 diff -u -r1.5 mdmfs.c --- mdmfs.c 2001/07/30 09:11:17 1.5 +++ mdmfs.c 2001/08/05 00:18:38 @@ -65,6 +65,7 @@ bool mi_have_mode; }; +static bool compat;/* Full compatibility with mount_mfs? */ static bool debug; /* Emit debugging information? */ static bool loudsubs; /* Suppress output from helper programs? */ static bool norun; /* Actually run the helper programs? */ @@ -115,8 +116,12 @@ newfs_arg = strdup(); mount_arg = strdup(); + /* If we were started as mount_*, imply -C. */ + if (strncmp(getprogname(), mount_, 6) == 0) + compat = true; + while ((ch = getopt(ac, av, -
Re: named -u bind
Jun Kuriyama [EMAIL PROTECTED] writes: At Fri, 03 Aug 2001 19:50:24 -0700, Dima Dorfman wrote: IIRC the last time this came up somebody said something about it not being able to read zonefiles in some odd places where they like to put them. I.e., they want it to run as root so they can set their zonefile mode 600 or something. If they are running on -stable, is it possible to change default behaviour on -current to use bind account? Don't ask me, I wasn't one of those people. *I* won't object to this change; I was just warning you that somebody might, for that reason. # Or importing code to use chroot from OpenBSD? Import code? BIND can run in a chroot just fine. Sorry for my poor explanation. This means to get a part of shell code in /etc/rc of OpenBSD to prepare chroot environment. This seems users can use chroot'ed named easily with only setting variables at /etc/rc.conf. This seems like a good idea whether it's the default or not. The only thing is that something running in a chroot should be built statically, unless you also want to stick libc and friends in there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: md/mdmfs bugs
Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Jul 30, 2001 at 02:03:31AM -0700, Dima Dorfman wrote: Kris Kennaway [EMAIL PROTECTED] writes: 1) For some reason, my mdmfs line in /etc/fstab always does a chmod 777 /tmp at mount-time /dev/md0/tmpmfs rw,-s=3D65536 00 I can't reproduce this. You say it does a chmod; does that mean you see it caling chmod(2) (see as in using truss(1), or the undocumented -X option), or is the symptom that it winds up with mode 777? Also, does it happen when you run mdmfs from the command line, and/or with directories other than /tmp? I haven't tracked it down, except that every time I reboot my /tmp winds up mode 777 again. Okay, this is a bug in mdmfs in the sense that it doesn't do what mount_mfs did, but what mount_mfs used to do is silly. It sets mode 1777 on its mountpoint regardless of where it is (this would make sense if it was called tmpfs). mdmfs doesn't duplicate this behavior (I wasn't aware of it), but it does provide a way to set the mode: /dev/md0/tmpmfs rw,-s=65536,-p1777 0 0 Since mdmfs can be used for things other than fstab processing, the idea of setting 1777 on the mountpoint by default doesn't sound very good, but it is meant to be compatible with mount_mfs. How about fixing mdmfs to be bug-compatible (eew, Microsoft term) with mount_mfs if it's called as mount_* (e.g., argv[0] is mount_), and be sane otherwise? I'll do this if people think that'd be okay. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: md/mdmfs bugs
Sheldon Hearn [EMAIL PROTECTED] writes:
On Wed, 01 Aug 2001 09:39:58 MST, Dima Dorfman wrote:
How about fixing mdmfs to be bug-compatible (eew, Microsoft term) with
mount_mfs if it's called as mount_* (e.g., argv[0] is mount_), and
be sane otherwise? I'll do this if people think that'd be okay.
People already have to learn a new name. They may as well learn the
name of one that has sensible defaults.
They don't have to learn a new name:
cd /sbin ln -s mdmfs mount_mfs shutdown -r now
the existing fstab entries should work. Well, they should, but don't,
since mdmfs doesn't do some of the stupid and undocumented things that
mount_mfs used to. This is what I'd like to fix (but optionally, so
mdmfs can be used for other things, like implementing the rc.conf
knob, too).
I'm in favour of the current behaviour but I _still_ think you should
commit my patches that add a mount /tmp in mfs option to rc.conf.
I don't know where you got the idea that I thought your rc.conf knob
was a bad idea. Actually, before I imported mdmfs, dougb@ said he was
going to do something similar (if not just change your patch to use
mdmfs), but he appears to have disappeared (probably busy with
$real_life stuff).
Below is the etc/rc part of your patch converted to use mdmfs. I'd be
glad to see that (and the other parts) applied, but I can't speak for
others (although nobody objected that I know of).
WARNING: whitespace/tab corruption
WARNING: untested
Index: etc/rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.250
diff -u -d -r1.250 rc
--- etc/rc 2001/01/21 20:57:13 1.250
+++ etc/rc 2001/01/29 16:17:47
@@ -196,6 +196,23 @@
;;
esac
+case ${swap_backed_tmp_size} in
+[Nn][Oo] | '')
+ ;;
+*)
+ echo 'Mounting swap-backed /tmp'
+ mdmfs -s ${swap_backed_tmp_size} -p ${swap_backed_tmp_perm} md /tmp
+ ;;
+esac
+
umount -a /dev/null 21
# Mount everything except nfs filesystems.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new libmp imported
Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Jul 30, 2001 at 07:44:33AM -0700, David O'Brien wrote: On Sun, Jul 29, 2001, Kris Kennaway wrote: installed. This would involve a repo copy of crypto/openssl/crypto/bn to contrib/openssl-bn or something, and I'd keep the two in sync with future vendor imports. You're likely to get people saying repo bloat. And it does seem a little wrong to have two copies in the tree like that. Just what programs are affected by this issue (ie, which use libmp)? I don't have the list to hand right now, but they all related to the secure RPC code which arguably should be in the crypto distribution anyway. All the telnets, usr.sbin/keyserv, usr.bin/chkey, and usr.bin/newkey. The telnets need it for SRA, and the others are all SecureRPC-related as you say. I don't know how we distinguish crypto code, but I would think they all fit it there. Seeing as how this is a relatively minor problem, I plan to `cvs rm` libgmp tomorrow. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: md/mdmfs bugs
Kris Kennaway [EMAIL PROTECTED] writes:
1) For some reason, my mdmfs line in /etc/fstab always does a chmod
777 /tmp at mount-time
/dev/md0/tmpmfs rw,-s=65536 0 0
I can't reproduce this. You say it does a chmod; does that mean you
see it caling chmod(2) (see as in using truss(1), or the undocumented
-X option), or is the symptom that it winds up with mode 777? Also,
does it happen when you run mdmfs from the command line, and/or with
directories other than /tmp?
2) the -X debugging option to mdmfs isn't documented in the manpage
Oops, will fix.
3) The following sequence of commands will cause my -current box to blow up:
Step 1: disklabel -r -w md1c auto
^
Disklabel wants the disk name, not the partition. This is still a
panic(8)/hang(8) implementation, but it doesn't derive you of any
functionality.
where md1 isn't a valid configured md instance. This command spits
out a driver_mistake console warning message
Step 2: mdconfig -d -u md1
Step 3: Watch the console spew messages in an infinite loop until the
end of time (Step 3 is optional).
This is actually a bug in the disk minilayer. md(4) is just the most
convenient driver to exploit those bugs, which is why we don't see
stuff like this happening with ad/da.
Furthermore, this is actually an exception-handling bug, not a real
functionality problem. Notice how you call disklabel with md1c as
an argument, while disklabel wants the name of the *disk*, not the
partition! What ends up happening is that disklabel tries to access
md1cc, which isn't valid.
However, when subr_disk.c::disk_clone() parses the name to clone, it
only parses it up to where it got all the information it wants (it
wants the unit, slice, and partition). This means that asking it to
clone md1cKRIS will work just fine (try it: ls -l /dev/md1cKRIS);
the major/minor will be the same as md1c. How should this be handled?
It can either strip off the extraneous parts, or it can do nothing.
Either of these will remove the cause of the infinite loop (step 3).
I've attached a patch that does the latter as a proof-of-concept.
All that said, I probably just scratched the surface, and likely got a
few points even doing that. I'm sure phk will find the real problem
when he wakes up :-).
Index: subr_disk.c
===
RCS file: /ref/cvsf/src/sys/kern/subr_disk.c,v
retrieving revision 1.41
diff -u -r1.41 subr_disk.c
--- subr_disk.c 2001/05/29 18:19:57 1.41
+++ subr_disk.c 2001/07/30 08:42:25
@@ -82,6 +82,10 @@
continue;
else
p = name[i] - 'a';
+ if (name[++i] != '\0') {
+ printf(WARNING: attempt to access %s\n, name);
+ return;
+ }
}
*dev = make_dev(pdev-si_devsw, dkmakeminor(u, s, p),
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HEADS UP: new libmp imported
I've imported the libmp-in-terms-of-OpenSSL library and connected it to the build. I've also disconnected libgmp and friends from the build, but have not `cvs rm`'d it yet. Assuming no problems turn up, I plan to do that in two or three days. The only program that use libmp that I haven't been able to test is the Kerberized telnet, but since it's the same code as the other telnets, there shouldn't be any problems. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new libmp imported
Kris Kennaway [EMAIL PROTECTED] writes: On Sun, Jul 29, 2001 at 02:06:58AM -0700, Dima Dorfman wrote: I've imported the libmp-in-terms-of-OpenSSL library and connected it to the build. I've also disconnected libgmp and friends from the build, but have not `cvs rm`'d it yet. Assuming no problems turn up, I plan to do that in two or three days. The only program that use libmp that I haven't been able to test is the Kerberized telnet, but since it's the same code as the other telnets, there shouldn't be any problems. When Mark and I talked about this a few months ago, we concluded that we'd have to first break out the (self-contained) bignum lib [...] BIGNUM isn't self-contained. It needs the ERR_* subsystem, as well as (I think) the BIO subsystem. I tried creating a libbignum by only compiling stuff from openssl/bn, and it didn't work very well. If you can get it to work, so much the better. That said, right now everything that uses libmp could be considered `crypto' code, anyway, so it may just be better to classify it as such as not install it in the NO_CRYPTO case (is there such a knob, anyway?). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3dfx module breaks without /sys symlink
Sheldon Hearn [EMAIL PROTECTED] writes: Hi Coleman, Could you take a look at the 3dfx module build as handled under the buildkernel target? It breaks on can't find kernel source if the /sys symbolic link is broken. It shouldn't need that, right? This isn't Coleman's fault; it's a bug in bsd.kmod.mk, which was fixed in r1.86 (or r1.75.2.3 in RELENG_4), and it affects all modules (3dfx is failing because it's first on the list). Are you running a stale -stable (e.g., before 2001/05/18)? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current buildkernel fails on custom kernel
Vincent Poy [EMAIL PROTECTED] writes: linking kernel.debug linprocfs.o: In function `_linprocfs_mount': /usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to `pfs_mount' You compiled in linprocfs but not pseudofs. Don't do that: the former depends on the latter. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sys/dev/snp?
What do people think of moving sys/kern/tty_snoop.c to sys/dev/snp/snp.c? It doesn't belong in kern/; I'm guessing it was put there originally because it was dependent on some custom hacks in tty.c, but since those are gone I think there's no reason not to put it where it belongs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: handbook typo
David Hill [EMAIL PROTECTED] writes: Please wrap lines at 72 characters. Thanks. Hello - Under the sysctl Tuning section, the sysctl command is missing the -w option to set the values. -w is deprecated in -current. I think it's best to MFC the change that makes it optional instead of mucking around with the Handbook. Thanks - David Hill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: conficting cvs version numbers?
j mckitrick [EMAIL PROTECTED] writes: On Sat, Jul 07, 2001 at 12:00:19PM -0700, David O'Brien wrote: | On Fri, Jul 06, 2001 at 11:52:05PM +0100, j mckitrick wrote: | I get version 1.15. When I look at the .c,v file in the cvs tree, it says | HEAD is 1.16, but $Id says it is 1.15. | | We don't use $Id$ anymore. Do you mean $FreeBSD$? If so, please try | to be more exact. Also try ``cvs status'' on the file. My mistake. I was just using generic terminology. Well, according to status, I *do* have the latest version. But here is the confusing part. I have 1.16 of the file locally In the web CVS repository, $FreeBSD$ expands to version 1.16 In my local version, $FreeBSD$ is expanded to version 1.15 What could explain this? p.s. I just downloaded the file from the web repository and diff'ed it with the one in my local directory: local:~ diff immio.c /sys/dev/ppbus/immio.c 27c27 * $FreeBSD: src/sys/dev/ppbus/immio.c,v 1.16 2001/06/23 06:51:51 nsouch Exp $ --- * $FreeBSD: src/sys/dev/ppbus/immio.c,v 1.15 2001/01/25 13:07:55 nsouch Exp $ local:~ Are you using FreeBSD locally to do these checkouts? It sounds like cvs isn't expanding $FreeBSD$ on your local machine. See, when someone checks in a file, it gets checked in with the *old* $FreeBSD$ line; cvs is supposed to update it on checkout. That last bit isn't happening in your case for some reason. Since $FreeBSD$ (well, all custom keywords) are a FreeBSD extension, trying to use another system will give the results you're seeing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
John Baldwin [EMAIL PROTECTED] writes: On 06-Jul-01 Jordan Hubbard wrote: Well, unless implicit pointer-to-int conversions have suddenly become fatal, it blew up on something that just got fixed (I went to commit the fix and found that someone else had already done so in the last 12 hours). The world build has been restarted and is running again. Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum, people should be either testing the build on all archs, or asking for someone else to review the patch on archs they don't have available (this last is a more feasible means as we add more and more archs, we can't expect everyone to own a x86, sparc64, ppc, alpha, and ia64). No, but I think it's reasonable to expect that we can get some test/build boxes for these arches like we have beast for the Alpha. I'm curious how NetBSD does this. We got the WARNS stuff from them, and they have a lot more arches than we plan on in the foreseeable future. Kris? In the WARNS= case, another workable method would be to commit the warning fixes but don't commit the actual WARNS= change until the build has been verified on all archs. This doesn't work. The point of WARNS, as I see it anyway, is not to scrub the tree so that `make buildworld` produces less warning output. The point is that people who are modifying programs are less likely to introduce bugs if warnings as treated as errors (presumably, the compile outputs good warnings that actually help find bugs). The above (your idea) works when WARNS= is set the first time, but not when a program with WARNS set is modified. This, I think, is the real problem; it isn't a problem to test on all arches when you *first* set WARNS. The problem is somebody making a small change to the program later. They may not even know WARNS is set; their code didn't trigger warnings on their test box, so they think it's okay. Furthermore, this makes it harder for non-committers to submit changes; at least committers have potential access to the other arches (e.g., beast). I guess what I'm saying is that we might want to rethink how we use WARNS. It'd be nice if the tree would compile warning-free on all arches imaginable, but this simply isn't going to happen. Perhaps it makes sense to set NO_WERROR by default in a buildworld so that causing a warning on some arch isn't considered as bad as breaking world (this is less important on -current than it is on -stable). Kris already said that NO_WERROR would be the default in -stable, but it may even makes sense in -current; those developers that have a few spare minutes can unset it when they build world, and fix the warnings (or errors, now) as they encounter them. This has the advantage of making less people angry, and keeping the benifit of WARNS (i.e., finding bugs before they turn into a multitude of PRs). Thoughts? Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: please, commit thoses PR
[ -stable dropped ] Cyrille Lefevre [EMAIL PROTECTED] writes: hi, by order fo importance, sendmail.cf is missing some STARTTLS support http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28361 (w/o this one, depending on the provider, mails aren't can't go out...) This one's assigned to gshapiro. He's on vacation or something right now; his auto-reply says he'll be back in a week or so. And he's usually pretty responsive to these kinds of things (and since he's the de-facto sendmail maintainer, your best hope is that he likes it ;-). make sysinstall ask for the keymap at installation time http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27483 (this one is important for, at least, french users, since Q and A key are inverted and may cause damages at instalation time using fdisk) well, not so important, thoses are waiting for month right now... add -c for grand total to df(1), like du(1) does http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19635 (just for memory) I haven't read all 1100 lines of the audit-trail, but it looks like some people don't want this. skeyaccess(3) doesn't for primary group http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22212 (ditto) skey is being deprecated. thanks. To -stable CC -current I think -bugs would've been more appropriate. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particul ar work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig/umount Fatal trap 12
Jens Schweikhardt [EMAIL PROTECTED] writes: hello, world\n with a system cvsupped June 6th I can reliably reproduce a [panic] when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Been there, done that. Got the patches and long thread(s) to prove it ;-). See message ID [EMAIL PROTECTED] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
I'm picking a random message out of the thread to reply to, and as much as I hate contributing to a flame-war, this issue has not yet been mentioned. All the bickering about this not being discussed aside, fixing the relnotes isn't going to be the end of the story: the web site is broken. Well, sort of. It builds fine, but not in the right place. The URLs for the doc part of the web site correspond directly to the directories in the repository. E.g., we have URLs like this: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/ With this change, the above turned into: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/ (The first URL still exists because the contents of the web site is never actually wiped; normally, it's just installed over.) This breaks *a lot* of links. Not only within the web site, but external links as well. This is, quite franky, unacceptable. Using symbolic links or HTTP redirects to remedy this is unsatisfying. We've had this discussion before, and symlinks are *evil* on web sites (just ask wosch), and HTTP redirects simply don't work for mirrors. At this point, I'd just like to hear what kind of solution you have for the above problem. We already changed most of the URLs some months ago; I don't think anybody wants to do it again. Regards, Dima Dorfman [EMAIL PROTECTED] P.S. Some time ago, I heard someone say that any proposed change that creates work for or causes grief for a group of people should be communicated to that group of people *prior* to being enacted. (This isn't an official rule; I saw this on one of the lists.) This cosmetic (yes, I think removing an underscore is more cosmetic than it is technical) change certainly causes work for (e.g., bmah fixing relnotes) and grief for (just look at this thread) some people. It is akin to the /modules - /boot/kernel switch; it's probably a good thing, but it affects so many people that one shouldn't simply do it on a whim. P.P.S. I apologize in advance if this e-mail offended anybody; that was certainly not my intention. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release failure
David O'Brien [EMAIL PROTECTED] writes: On Sun, May 27, 2001 at 11:32:09PM -0700, Bruce A. Mah wrote: +.if !defined(NORELNOTES) Do we really need Yet Another Knob? Why isn't NODOC suffient? FWIW, I think we should lose NORELNOTES; as you say, NODOC is sufficient. I cannot think of any reason that the people who typically use NODOC=yes would want release notes. Heh, it isn't like they could get them, anyway. RELNOTESng depends on the doc tree. Dima Dorfman [EMAIL PROTECTED] Or please at least treat NODOCS=yes == NORELNOTES=yes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
src/share/man/man9/devfs*.9
dima@hornet% ls -1 share/man/man9/devfs*.9 share/man/man9/devfs_add_devswf.9 share/man/man9/devfs_link.9 share/man/man9/devfs_remove_dev.9 The above man pages are for the old DEVFS written by Julian, and don't apply to the new one (the functions they describe don't exist). Any objections to a `cvs rm` of these? Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release failure
John Hay [EMAIL PROTECTED] writes: A make release failed here with: # touch release.8 Making fixit floppy. disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g) super-block backups (for fsck -b #) at: 32 2556 blocks Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mount ed on /dev/md0c1363 1297 6695% 266 11670% /mnt *** Filesystem is 1440 K, 66 left *** 4000 bytes/inode, 116 left cp: /usr/src/release/texts/FLOPPIES.TXT: No such file or directory What revision of src/release/Makefile do you have? You want 1.618. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. ... ## John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release failure
John Hay [EMAIL PROTECTED] writes:
A make release failed here with:
#
touch release.8
Making fixit floppy.
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 1216 sector(s) in last cylinder unallocated
/dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors
1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g)
super-block backups (for fsck -b #) at:
32
2556 blocks
Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused M
ount
ed on
/dev/md0c1363 1297 6695% 266 11670% /
mnt
*** Filesystem is 1440 K, 66 left
*** 4000 bytes/inode, 116 left
cp: /usr/src/release/texts/FLOPPIES.TXT: No such file or directory
What revision of src/release/Makefile do you have? You want 1.618.
beast# fgrep '$FreeBSD' /usr/src/release/Makefile
# $FreeBSD: src/release/Makefile,v 1.618 2001/05/25 18:01:31 bmah Exp $
beast# fgrep 'texts/FLOPPIES.TXT' /usr/src/release/Makefile
@cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
Could you please try the attached, untested patch? I don't know
enough about the release build process to know if it should work, but
I guess it's worth a shot. Bruce Mah (cc'd) should know whether it's
the Right(tm) fix.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: Makefile
===
RCS file: /stl/src/FreeBSD/src/release/Makefile,v
retrieving revision 1.618
diff -u -r1.618 Makefile
--- Makefile2001/05/25 18:01:31 1.618
+++ Makefile2001/05/28 04:03:26
@@ -694,7 +694,8 @@
@sh -e ${.CURDIR}/scripts/doFS.sh ${RD}/floppies/fixit.flp ${RD} \
${MNT} ${FIXITSIZE} ${RD}/fixitfd ${FIXITINODE} ${FIXITLABEL}
# Do our last minute floppies directory setup in a convenient place.
- @cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
+ @cp ${.CURDIR}/doc/${RELNOTES_LANG}/readme/article.txt \
+ ${RD}/floppies/README.TXT
@(cd ${RD}/floppies; md5 README.TXT *.flp CHECKSUM.MD5)
touch release.9
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kbdcontrol the build-tool revisited (was: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.c)
Hi folks, As I'm sure most people here know, kbdcontrol is a build-tool because sysinstall requires it to generate keymap.h. This means that it has to compile with the headers already in /usr/include on the host system; the last time this came up with PASTE, we just defined the needed constant in kbdcontrol.c and forgot about the problem. This is rather silly, because it effectively means we can't add new features to kbdcontrol that depend on new header files. Furthermore, sysinstall only needs a small subset of its features, which can be easily factored out into a separate program. This has been proposed before; nobody really objected, but it was found that defining the constant was much quicker and easier. Since I think being unable to add new features to kbdcontrol is a rather silly limitation, I again propose to factor out `kbdcontrol -L` into a separate program, which can then be made a build-tool. I'll do all the work necessary if this is what we want to do. Regards, Dima Dorfman [EMAIL PROTECTED] Dima Dorfman [EMAIL PROTECTED] writes: dd 2001/05/26 21:03:53 PDT Modified files: usr.sbin/kbdcontrol kbdcontrol.c Log: A la rev. 1.36, define CONS_CLRHIST here if it isn't already since this is a build tool, so it has to build on 4.x with the old headers. Revision ChangesPath 1.38 +7 -3 src/usr.sbin/kbdcontrol/kbdcontrol.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vm_pager_(de)allocate and vm_mtx
Is there a reason vm_pager_allocate acquires vm_mtx itself if necessary but vm_pager_deallocate does not? At the moment, detaching an md(4) disk will panic the system with a failed mtx_assert in vm_pager_deallocate. This can be fixed one of two ways: vm_pager_deallocate could be made to deal with vm_mtx itself like vm_pager_allocate does, or md(4) and any other drivers which call vm_pager_deallocate can be fixed to acquire vm_mtx. So which will it be? I'll supply patches for either case. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mount_mfs (Re: smbfs)
Kris Kennaway [EMAIL PROTECTED] writes: On Fri, May 25, 2001 at 04:26:48PM +0200, Sheldon Hearn wrote: On Fri, 25 May 2001 09:34:16 -0400, Mikhail Teterin wrote: Why can't that program _replace_ mount_mfs? And assume the name too? The objection that impressed me the last time this was suggested is that it's totally counter-intuitive to have a binary called mount_mfs that doesn't mount an MFS filesystem. Rather, it does all sorts of icky extra stuff to achieve a rather specific goal. FWIW, I agree with this. It mounts *ufs*, not *mfs*. It just puts the ufs on a memory disk; thus, the name is inappropriate, but the idea is still good. I still don't see why an rc.conf knob specifically for /tmp isn't sufficient. That's what people want this for. Others can read the excellent documentation supplied in mdconfig(8), which is appropriately cross-referenced from md(4), which is the manual page for the device concerned. Logical, orthogonal and pretty damn easy, when you look at the EXAMPLES section. :-) How about make a port of out the mount_mfs compatible program and committing your (Sheldon's) /tmp rc.conf patch? Those who only need /tmp (and as you say, this is the majority) have what they need, we don't have [needless] stuff in the base system, and those who need something that pretends to be mount_mfs can get that from the ports. Does this sound good? Someone please just fix it :) Erm, perhaps you could elaborate on it? Would the above suggestion suit you? Regards, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_pager_(de)allocate and vm_mtx
Alfred Perlstein [EMAIL PROTECTED] writes:
* Dima Dorfman [EMAIL PROTECTED] [010525 22:22] wrote:
Is there a reason vm_pager_allocate acquires vm_mtx itself if
necessary but vm_pager_deallocate does not? At the moment, detaching
an md(4) disk will panic the system with a failed mtx_assert in
vm_pager_deallocate. This can be fixed one of two ways:
vm_pager_deallocate could be made to deal with vm_mtx itself like
vm_pager_allocate does, or md(4) and any other drivers which call
vm_pager_deallocate can be fixed to acquire vm_mtx. So which will it
be? I'll supply patches for either case.
Usually fixing the caller is better as it will catch people that
expect vm state to remain unchanged across several calls.
Patch to fix md(4) attached. Look okay?
Dima Dorfman
[EMAIL PROTECTED]
Index: md.c
===
RCS file: /stl/src/FreeBSD/src/sys/dev/md/md.c,v
retrieving revision 1.33
diff -u -r1.33 md.c
--- md.c2001/05/21 18:52:00 1.33
+++ md.c2001/05/26 05:48:57
@@ -711,8 +711,11 @@
(void)vn_close(sc-vnode, sc-flags MD_READONLY ? FREAD :
(FREAD|FWRITE), sc-cred, p);
if (sc-cred != NULL)
crfree(sc-cred);
- if (sc-object != NULL)
+ if (sc-object != NULL) {
+ mtx_lock(vm_mtx);
vm_pager_deallocate(sc-object);
+ mtx_unlock(vm_mtx);
+ }
if (sc-secp != NULL) {
for (u = 0; u sc-nsect; u++)
if ((uintptr_t)sc-secp[u] 255)
@@ -763,17 +766,20 @@
* Note the truncation.
*/
+ mtx_lock(vm_mtx);
sc-secsize = PAGE_SIZE;
sc-nsect = mdio-md_size / (PAGE_SIZE / DEV_BSIZE);
sc-object = vm_pager_allocate(OBJT_SWAP, NULL, sc-secsize *
(vm_offset_t)sc-nsect, VM_PROT_DEFAULT, 0);
if (mdio-md_options MD_RESERVE) {
if (swap_pager_reserve(sc-object, 0, sc-nsect) 0) {
vm_pager_deallocate(sc-object);
+ mtx_unlock(vm_mtx);
sc-object = NULL;
mddestroy(sc, mdio, p);
return(EDOM);
}
}
+ mtx_unlock(vm_mtx);
error = mdsetcred(sc, p-p_ucred);
if (error)
mddestroy(sc, mdio, p);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mount_mfs (Re: smbfs)
Kris Kennaway [EMAIL PROTECTED] writes: --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2001 at 10:35:43PM -0400, Mikhail Teterin wrote: On 24 May, Kris Kennaway wrote: On Thu, May 24, 2001 at 06:13:21PM -0700, Gordon Tetlow wrote: Should there be a mount_smbfs to go with this? How does one mount smb shares otherwise? It's in the smbfs port. Shouldn't it move to the base system now? BTW, what happened to mount_mfs in current? It still gives this nasty warning about migrating to mdconfig, waits 15 seconds and then panics my machine. Mine too. It also appears there's no canonical (i.e. rc.conf) knob for configuring /tmp as a MD (there are however instructions in the manpage which I hacked in manually on my system) Sheldon Hearn posted a patch to add such a knob around January when we were having this exact discussion. Personally, I think it only solves half a problem; what if you want /tmp and /tmp2? And why should it be limited to boot-up? Perhaps there's use for a program which emulates mount_mfs using md. I actually wrote a short program that emulates *all* of mount_mfs's umpteen options with md, disklabel, and newfs, but nobody seemed interested. My choice of name (mount_md) wasn't particuarly good, either. Look at the -hackers and cvs-all archives around late January and early February for the discussions. I still have that program, and it works great, so perhaps I should make it a port (comments?). Regards, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken in two places
Michael Harnois [EMAIL PROTECTED] writes: Unless I missed a heads-up somewhere ... mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I @/../include /usr/src/sys/modules/if_sl/../../net/if_sl.c /usr/src/sys/modul es/if_sl/../../net/slcompress.c /usr/src/sys/modules/if_sl/../../net/if_sl.c:96: #error Huh? Slip without in et? Are you compiling without options INET? and then, if I overcome that breakage by brute force ... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Ws trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../ include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_ global.h -elf -mpreferred-stack-boundary=2 ../../kern/tty_snoop.c ../../kern/tty_snoop.c: In function `snp_detach': ../../kern/tty_snoop.c:394: structure has no member named `snp_olddisc' ../../kern/tty_snoop.c: In function `snpioctl': ../../kern/tty_snoop.c:477: structure has no member named `snp_olddisc' *** Error code 1 This is my fault. I've fixed it. Sorry, everybody :-/ Dima Dorfman [EMAIL PROTECTED] -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Some folks you don't have to satirize, you just quote 'em. --Tom Paxton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned
David Malone [EMAIL PROTECTED] writes:
Please try the attached patch. I make no claims of its correctness,
but this e-mail is coming to you via X on -current updated a few hours
ago so it works here :-).
I tried Dima's patch (the one which Alfred has committed) and I
get an earlier mutex recursion panic, probably when a local progam
that uses shm forks and exits. I scribbled down this trace from
it:
Is there such a program in the base system?
panic+0x70
_mtx_assert+0x67
lockmgr+0xdc
vm_map_remove+0x42
shm_delete_mapping+0xe1
shmexit_myhook+0x29
exit1+0x9eb
exit1
So it looks like those routines are sometime called with the mutex
already held.
exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c
(rev. 1.127). Actually, shmexit_myhook should always be called with
vm_mtx held, so shm_delete_mapping can't assume it isn't held.
Attached is an untested patch to try to fix this. It's almost 02:00
here and I have to head to bed, but it may work for you. At least it
may be a starting point for someone.
Hope this helps,
Dima Dorfman
[EMAIL PROTECTED]
Index: sysv_shm.c
===
RCS file: /stl/src/FreeBSD/src/sys/kern/sysv_shm.c,v
retrieving revision 1.56
diff -u -r1.56 sysv_shm.c
--- sysv_shm.c 2001/05/19 01:28:03 1.56
+++ sysv_shm.c 2001/05/21 08:41:29
@@ -200,6 +206,8 @@
int segnum, result;
size_t size;
+ /* for vm_map_remove */
+ mtx_assert(vm_mtx, MA_OWNED);
segnum = IPCID_TO_IX(shmmap_s-shmid);
shmseg = shmsegs[segnum];
size = round_page(shmseg-shm_segsz);
@@ -229,6 +237,7 @@
{
struct shmmap_state *shmmap_s;
int i;
+ int error;
if (!jail_sysvipc_allowed jailed(p-p_ucred))
return (ENOSYS);
@@ -242,7 +251,10 @@
break;
if (i == shminfo.shmseg)
return EINVAL;
- return shm_delete_mapping(p, shmmap_s);
+ mtx_lock(vm_mtx);
+ error = shm_delete_mapping(p, shmmap_s);
+ mtx_unlock(vm_mtx);
+ return error;
}
#ifndef _SYS_SYSPROTO_H_
@@ -659,6 +671,8 @@
struct shmmap_state *shmmap_s;
int i;
+ /* shm_delete_mappings requires this */
+ mtx_assert(vm_mtx, MA_OWNED);
shmmap_s = (struct shmmap_state *)p-p_vmspace-vm_shm;
for (i = 0; i shminfo.shmseg; i++, shmmap_s++)
if (shmmap_s-shmid != -1)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned
David Malone [EMAIL PROTECTED] writes: On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote: exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c (rev. 1.127). Actually, shmexit_myhook should always be called with vm_mtx held, so shm_delete_mapping can't assume it isn't held. The following seems to work. It's basically your patch, but it removes the patch which was originally committed, adds an extra assert, expands on one comment and grabs a mutex in one place it seemed to be needed after removing the others. Great! I can confirm that this works for me. Alfred, any objections to me or David committing this? + /* shm_delete_mappings requires this */ + mtx_assert(vm_mtx, MA_OWNED); That should be 'shm_delete_mapping'; no 's'. That's my fault. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned
David Malone [EMAIL PROTECTED] writes: On Sun, May 20, 2001 at 12:59:51PM -0400, Mike Heffner wrote: The machine is up for about one minute and then I ran `startx' and the screen turned black and it appeared to lockup, after about 30 seconds plus some banging on the keyboard it rebooted. I have 256mb ram, so it shouldn't be swapping at this point. The kernel and world are cvsupd to about 12am May 20 EDT, the following is the panic message: I'm getting a panic whenever I start X too (with a kernel from earlier today). I managed to get a DDB trace from a serial console. Please try the attached patch. I make no claims of its correctness, but this e-mail is coming to you via X on -current updated a few hours ago so it works here :-). I had to manually edit out some unrelated local changes, so if you have trouble applying it fetch the full one from http://www.unixfreak.org/~dima/home/shm-full.diff. That one has local changes (new sysctls), but they (probably) won't hurt you. Thanks, Dima Dorfman [EMAIL PROTECTED] Index: sysv_shm.c === RCS file: /stl/src/FreeBSD/src/sys/kern/sysv_shm.c,v retrieving revision 1.56 diff -u -r1.56 sysv_shm.c --- sysv_shm.c 2001/05/19 01:28:03 1.56 +++ sysv_shm.c 2001/05/20 20:26:28 @@ -182,7 +186,9 @@ size_t size; shm_handle = shmseg-shm_internal; + mtx_lock(vm_mtx); vm_object_deallocate(shm_handle-shm_object); + mtx_unlock(vm_mtx); free((caddr_t)shm_handle, M_SHM); shmseg-shm_internal = NULL; size = round_page(shmseg-shm_segsz); @@ -203,7 +209,9 @@ segnum = IPCID_TO_IX(shmmap_s-shmid); shmseg = shmsegs[segnum]; size = round_page(shmseg-shm_segsz); + mtx_lock(vm_mtx); result = vm_map_remove(p-p_vmspace-vm_map, shmmap_s-va, shmmap_s-va + size); + mtx_unlock(vm_mtx); if (result != KERN_SUCCESS) return EINVAL; shmmap_s-shmid = -1; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pgm to kill 4.3 via vm
[ -stable dropped from cc list ] John Baldwin [EMAIL PROTECTED] writes: On 09-May-01 Robert Watson wrote: On Tue, 8 May 2001, John Baldwin wrote: That's easy enough. Well, it used to be at least. You can use 'ps' to find the address of the struct proc (first pointer in the display) and then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then hit 'c' to continue and voila, the process dies. I think that may panic now due to proc lock not being held (though the debugger shouldn't need any locks in theory.) Perhaps mtx_assert() should honor db_active and not panic if it is set. I followed everything here fine until you asserted that the debugger shouldn't need any locks. I guess I don't see why that is, at least in terms of not corrupting structures. From a practical perspective, the debugger is like any other interupt-driven preemptive code-path: if you want to modify a structure, you need to synchronize appropriately to avoid corrupting the structure. This may not be something you really want to do in a debugger, so in that sense perhaps you *shouldn't* grab a lock in the debugger, but to perform the described action safely, you *should* grab a lock so as not to corrupt fields of the proc structure (i.e., if you broke into the debugger during a non-atomic flags update). Violating system invariants is something you should be allowed to do in a debugger, but this sounded like it was a feature people were looking from to recover from unhappy behavior, not to introduce it :-). I am more worried about the fact that you can deadlock the debugger. What does the debugger do if another process hold the proc lock on the process you want to kill? Cute, eh? The debugger is an extra special environment. Most of the time you've panic'ed when you are in there (but then the panicstr tests that skip lock operations save you from that). Also, in the debugger you know that no other threads are running. This is why 'show pcpu' can list spin locks on other cpu's safely, for example. I'm not sure if a ddb 'kill' command shouldn't be better implemented using a 'trylock' and refusing to send the signal if it can't get the lock so it can avoid doing really bad things. I suppose it wouldn't deadlock but would I think this makes sense. How should this be implemented, though? pfind() locks the process before returning (as you well know). Not using pfind() will work, but that breaks the abstraction. Is that something to worry about? There's also no PROC_TRYLOCK macro, but that's not hard to fix. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel secure level
Corey Brune [EMAIL PROTECTED] writes: I forgot the kernel secure level was set to 1 when I started make build. The build almost finishes, but dies when it tries to install /usr/lib/libcrypt.so.2 saying operation not permitted. I cannot chflags because of the secure level. Does anyone know a way around this? This is answered at least three times in the FAQ, not to mention the Handbook and the man pages. http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#KERNEL-CHFLAG-FAILURE http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#UNSETTING-SCHG http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#SECURELEVEL init(8) Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pgm to kill 4.3 via vm
[ cc severely trimmed ]
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
I would *love* to have a DDB equivalent to 'kill -9', so I could drop
to the DDB prompt, check ps, kill a process or two, and drop back out
of DDB. It would have saved me a reboot and a longish fsck in this
case.
Mmm.. I implemented something like this a few days ago for similar
reasons. Essentially it's a ddb interface to psignal(). I haven't
tried using it to kill something like your program, but I have no
reason to think it wouldn't work.
Short patch attached. Sample use:
db kill 9 0t500
where '9' is the signal number and '500' is the process id.
Dima Dorfman
[EMAIL PROTECTED]
Index: db_command.c
===
RCS file: /st/src/FreeBSD/src/sys/ddb/db_command.c,v
retrieving revision 1.34
diff -u -r1.34 db_command.c
--- db_command.c1999/08/28 00:41:06 1.34
+++ db_command.c2001/05/08 23:37:59
@@ -36,7 +36,11 @@
*/
#include sys/param.h
#include sys/linker_set.h
+#include sys/lock.h
+#include sys/mutex.h
+#include sys/proc.h
#include sys/reboot.h
+#include sys/signalvar.h
#include sys/systm.h
#include sys/cons.h
@@ -61,6 +65,7 @@
static db_cmdfcn_t db_fncall;
static db_cmdfcn_t db_gdb;
+static db_cmdfcn_t db_kill;
/* XXX this is actually forward-static. */
extern struct command db_show_cmds[];
@@ -405,6 +410,7 @@
{ show, 0, 0, db_show_cmds },
{ ps, db_ps, 0, 0 },
{ gdb,db_gdb, 0, 0 },
+ { kill, db_kill,CS_OWN, 0 },
{ (char *)0, }
};
@@ -558,4 +564,41 @@
db_printf(Next trap will enter %s\n,
boothowto RB_GDB ? GDB remote protocol mode
: DDB debugger);
+}
+
+static void
+db_kill(dummy1, dummy2, dummy3, dummy4)
+ db_expr_t dummy1;
+ boolean_t dummy2;
+ db_expr_t dummy3;
+ char * dummy4;
+{
+ struct proc *p;
+ db_expr_tsig, pid;
+
+ if (!db_expression(sig)) {
+ db_printf(Missing signal number\n);
+ db_flush_lex();
+ return;
+ }
+ if (!db_expression(pid)) {
+ db_printf(Missing process id\n);
+ db_flush_lex();
+ return;
+ }
+ db_skip_to_eol();
+ if (sig 0 || sig _SIG_MAXSIG) {
+ db_printf(Signal number out of range\n);
+ db_flush_lex();
+ return;
+ }
+
+ p = pfind(pid);
+ if (p == NULL) {
+ db_printf(Can't find process with pid %d\n, pid);
+ db_flush_lex();
+ return;
+ }
+ psignal(p, sig);
+ PROC_UNLOCK(p);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
Garance A Drosihn [EMAIL PROTECTED] writes: At 10:01 AM -0400 4/25/01, John W. De Boskey wrote: I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. It is inconceivable that the proposed patch to 'xargs' would increase your running time. I don't mean the standard '-I' change, which would certainly destroy performance, but the proposed patch to 'xargs' which solves your specific problem in a general way. I'm still curious as to why you think the proposed change to xargs will cause you ANY performance problem. I simply can not imagine where you would get a performance problem from the -Y idea (though I'm still tempted to change the letter for that proposed option). I think everything that should have been said in this thread already has been (so I won't repeat it), except for the performace bit. As the author of the patch, I doubt it would hinder performance. All it does is move one part of a loop further down. Instead of doing something once, it does part of that job twice. This job acts on arguments *to xargs* (i.e., argv), and is nothing more than pointer arithmetic and assignment. Unless you give umpteen arguments *to xargs*, you shouldn't notice a difference in execution speed. And as you (gad) said, implementing -I the way SUSv2 defines it would most likely kill performance (most likely it'd also slow down whether you actually use that option or not). Dimi has written one or two different patches to xargs. Did ^^^ -- should be 'a', but that's okay. :-) One patch. Thanks, Dima Dorfman [EMAIL PROTECTED] P.S. obrien: that's a very clever and unintrusive way of avoiding getting two copies of a message; much better than [EMAIL PROTECTED] Those of us (well, at least me) who actually want a copy of the message in our inbox greatly appreciate it. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Bruce A. Mah [EMAIL PROTECTED] writes: If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. [ snip other good reasons not to regen and commit TXT files ] I agree completely. On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
Riccardo Torrini [EMAIL PROTECTED] writes: pca1: AT-style speaker sound at port 0x61 on isa0 WARNING: Driver mistake: repeat make_dev(pcaudio) WARNING: Driver mistake: repeat make_dev(pcaudioctl) As it says, this is a driver mistake. It's a bug. I don't know if it's new or not since I don't have any computers with a sound card (and thus have no need for pcaudio*). unknown: PNP0f13 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources This is not a bug. This is an FAQ. So much that it's actually documented in (*gasp!*) the FAQ: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#PNP-RESOURCES To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Garance A Drosihn [EMAIL PROTECTED] writes:
At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
Does that mean everyone is blind and missed my arrogant
cross-post of the amazingly short patch to do this, or
are we just interested in discussing it and not testing
the implementation? ;-)
Well, I'm in the middle of a massive reorganization of
all my machines at home (to fit in a new G4 Cube!), so
I'm not paying as much attention to this as I would like.
I think it's really great that Dima has volunteered to do
the work...:-)
From what I have been following, you had one patch to add
the '-I' and '-i' options, and a different patch to add
the newly proposed '-Y' option. Right?
No, not quite. It's the same patch. The second one just has the 'Y'
option renamed to 'I' because I thought they did the same thing: they
don't.
The '-I' option is of interest because it is used in some
other OS's, and is even defined in some standards, such as
the SingleUnixSpec. From that:
-I replstr
Insert mode: utility will be executed for each line from
standard input, taking the entire line as a single argument,
inserting it in arguments for each occurrence of replstr.
A maximum of five arguments in arguments can each contain
one or more instances of replstr. Any blank characters at
the beginning of each line are ignored. Constructed arguments
cannot grow larger than 255 bytes. Option -x is forced on.
I think that if we're going to add a '-I', then we should
follow that description. Note that '-I', by definition,
forces '-n 1'. It will always pick up only one file from
the input to xargs per command that xarg will generate.
It allows things like:
Adding support for 'I' the way it's described above wouldn't be a
trivial as it was to add 'Y'. The latter adds about 15 lines, while
the former may involve some restructuring of the code.
Xargs compiles the arguments to utility as an array of pointers. It
also has assumptions that argv is only touched in the begining. It
wasn't a problem for -Y since it doesn't support the replstr being
embedded in an argument (e.g., for a replstr of {}, something{}
will not work as one arugment, only {} will), and it didn't have to
touch argv more than twice (I just added a small loop before all
invocations of run()). With -I, it'd probably be necessary to put a
large chuck of what is now main() inside a loop. It's not exactly
rocket science, but not something I can whip up in an hour, either.
I'll see what I can do probably later this week.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jordan Hubbard [EMAIL PROTECTED] writes:
And to come back on topic: Portable scripts also should
_not_ assume that there are no limits on the length of
shell commands. On the other hand, portable scripts can
legitimately assume that xargs supports -i and -I, which
ours doesn't.
Agreed on both counts. I guess we should fix that.
I don't have a copy of SuSv2 or anything else that defines -I and -i,
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
dima@spike% ./xargs -I [] echo CMD LINE [] ARGS test
CMD LINE this is the contents of the test file ARGS
dima@spike% ./xargs -I [] echo CMD [] LINE ARGS test
CMD this is the contents of the test file LINE ARGS
dima@spike% ./xargs -I [] echo [] CMD LINE ARGS test
this is the contents of the test file CMD LINE ARGS
Does that mean everyone is blind and missed my arrogant cross-post of
the amazingly short patch to do this, or are we just interested in
discussing it and not testing the implementation? ;-)
FWIW, I'm not sure the patch is entirely correct; xargs' processing of
this stuff looks like black magic. It works, but I'm not sure if I
failed to cater to some other weird assumptions it makes. This is why
it'd help if someone would at least look at it.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: xargs.c
===
RCS file: /st/src/FreeBSD/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.9
diff -u -r1.9 xargs.c
--- xargs.c 1999/08/28 01:07:50 1.9
+++ xargs.c 2001/04/21 20:15:27
@@ -73,6 +73,8 @@
int cnt, indouble, insingle, nargs, nflag, nline, xflag, wasquoted;
char **av, *argp, **ep = env;
long arg_max;
+ int apargs = 0;
+ char **avv, *replstr = NULL;
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
@@ -96,8 +98,14 @@
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
nflag = xflag = wasquoted = 0;
- while ((ch = getopt(argc, argv, "0n:s:tx")) != -1)
+ while ((ch = getopt(argc, argv, "0I:in:s:tx")) != -1)
switch(ch) {
+ case 'I':
+ replstr = optarg;
+ break;
+ case 'i':
+ replstr = "{}";
+ break;
case 'n':
nflag = 1;
if ((nargs = atoi(optarg)) = 0)
@@ -144,6 +152,13 @@
else {
cnt = 0;
do {
+ if (replstr strcmp(*argv, replstr) == 0) {
+ apargs = 1;
+ *argv++;
+ for (avv = argv; *avv; *avv++)
+ cnt += strlen(*avv) + 1;
+ break;
+ }
cnt += strlen(*bxp++ = *argv) + 1;
} while (*++argv);
}
@@ -211,6 +226,8 @@
if (xp == exp || p ebp || ch == EOF) {
if (xflag xp != exp p ebp)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
if (ch == EOF)
@@ -253,6 +270,8 @@
if (xflag)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
xp = bxp;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Brian Somers [EMAIL PROTECTED] writes:
I looked at your patches and immediately thought ``these patches
can't be right'' as I was expecting it to deal with things such as
xargs -I [] echo args are [], duplicated are []
It deals with it. It conveniently ignores the second '[]' :-).
Seriosly though, what do you expect it to do in this case? It can
either read some more from stdin, or use the same input it used for
the first case of '[]'. I also can't think of a case when either one
of these would be useful.
I guess the only reason we would want this is if SUSv2 defines it, but
even that may not matter since we probably won't support the silly
'-i[nospace]' semantic (other than being silly, I can't think of how
to implement it without writing a custom getopt() facility).
I'm also dubious about the patches working for large volumes on
standard input. At this point I scrapped the email I was composing
'cos I didn't have time to look into it further :-/
I think it's important to test any patches with a large number of
large path names as input - so that ARG_MAX is reached before the
5000 argument limit and we can see that we don't end up getting E2BIG
because of an accidental overflow/miscalculation.
Any advice on testing this (you did write rev. 1.9 of xargs.1, after
all)? I created a file with 4500 words like this:
/this/is/a/very/long/path/name/because/I/am/testing/some/posix/limit/10
which ended up being 330 kB. It ran the `utility' multiple times like
I expected it to. That said, I don't know what kind of failure mode
to expect. I.e., if the patch is wrong, should it have failed with
something like, "xargs: exec: argument list too long", or would it
just produce incorrect output (which I didn't really check for)?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
[ attempting to consolidate two identical threads into one ]
Brian Somers [EMAIL PROTECTED] writes:
I agree - the script idea doesn't seem right.
If {} isn't allowed to implicitly mean ``all the arguments that'll
fit'', then I'd vote for using -i (a version that does full grouping)
although I would not vote for the semantics whereby -i must either be
followed directly with the replacement string (with no intervening
spaces) or else have an implicit {} replacement string, ie we should
have these meaning the same thing:
xargs -i '' command blah '' blah
xargs -i'' command blah '' blah
I honestly don't understand the differnece between this and the -y
option gad described. Nevertheless, it seems that pretty much
everyone agrees that something like this is a good idea.
Attached is a patch that adds a -Y option to xargs which does, well,
pretty much what I imagine the above would do. Here are a couple of
examples:
dima@spike% cat test# test input
this is just
a test; it has
no real purpose
in life
dima@spike% ./xargs -Y {} echo CMD LINE ARGS test
CMD LINE ARGS this is just a test; it has no real purpose in life
dima@spike% ./xargs -Y {} echo {} CMD LINE ARGS test
this is just a test; it has no real purpose in life CMD LINE ARGS
dima@spike% ./xargs -Y {} echo CMD {} LINE ARGS test
CMD this is just a test; it has no real purpose in life LINE ARGS
dima@spike% ./xargs -Y {} echo CMD LINE {} ARGS test
CMD LINE this is just a test; it has no real purpose in life ARGS
dima@spike% ./xargs -Y {} echo CMD LINE ARGS {} test
CMD LINE ARGS this is just a test; it has no real purpose in life
dima@spike% ./xargs -n 2 -Y {} echo CMD LINE {} ARGS test
CMD LINE this is ARGS
CMD LINE just a ARGS
CMD LINE test; it ARGS
CMD LINE has no ARGS
CMD LINE real purpose ARGS
CMD LINE in life ARGS
I'm not sure the patch is entirely correct. xargs seems to be overly
complicated in the way it does some of its processing, but it works
and I believe I managed to maintain most of the assumptions it makes.
Comments? Suggestions?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: xargs.c
===
RCS file: /st/src/FreeBSD/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.9
diff -u -r1.9 xargs.c
--- xargs.c 1999/08/28 01:07:50 1.9
+++ xargs.c 2001/04/20 22:37:15
@@ -73,6 +73,8 @@
int cnt, indouble, insingle, nargs, nflag, nline, xflag, wasquoted;
char **av, *argp, **ep = env;
long arg_max;
+ int apargs = 0;
+ char **avv, *replstr = NULL;
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
@@ -96,7 +98,7 @@
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
nflag = xflag = wasquoted = 0;
- while ((ch = getopt(argc, argv, "0n:s:tx")) != -1)
+ while ((ch = getopt(argc, argv, "0n:s:txY:")) != -1)
switch(ch) {
case 'n':
nflag = 1;
@@ -115,6 +117,9 @@
case '0':
zflag = 1;
break;
+ case 'Y':
+ replstr = optarg;
+ break;
case '?':
default:
usage();
@@ -144,6 +149,13 @@
else {
cnt = 0;
do {
+ if (replstr strcmp(*argv, replstr) == 0) {
+ apargs = 1;
+ *argv++;
+ for (avv = argv; *avv; *avv++)
+ cnt += strlen(*avv) + 1;
+ break;
+ }
cnt += strlen(*bxp++ = *argv) + 1;
} while (*++argv);
}
@@ -211,6 +223,8 @@
if (xp == exp || p ebp || ch == EOF) {
if (xflag xp != exp p ebp)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
if (ch == EOF)
@@ -253,6 +267,8 @@
if (xflag)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
Re: cp -d dir patch for review (or 'xargs'?)
Garance A Drosihn [EMAIL PROTECTED] writes:
Or maybe something to indicate where the list of arguments
should go in a command. Hrm. Let's say '-Y replstr' or
'-y[replstr]' (no blank after -y). If no [replstr] is
given on -y, it defaults to the two characters '[]'.
Then one might do:
cat big_file_list | xargs -y cp [] target_directory
This is a great idea! I'm willing to implement it if nobody else
wants to.
you're trying to address. On the other hand, the man page
for 'xargs' on FreeBSD says:
The xargs utility is expected to be IEEE Std 1003.2
(``POSIX.2'') compliant.
so I don't know how we go about adding options to it. On
the other hand, that same issue is faced by adding options
to 'cp', as there is a similar claim made in cp's man page.
I don't think it's a problem. We're adding new options here, not
changing--sometimes known as breaking--what already exists. I'm
pretty sure that the standards don't say anything to the effect of,
"You must support this and nothing else." That'd be rather silly.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cosmetic bug in pw_util.c (with patch)
Revision 1.18 of pw_util.c (fix for security advisory "chpass" 00:58)
introduces a cosmetic bug which manifests itself as such:
passwd
Changing local password for dima.
Old password:
passwd: (null): Permission denied
^
passwd: /etc/master.passwd: unchanged
Only machines *not* using NIS will display this, since passwd(1) acts
differently when changing an NIS password. Trivial patch to fix this
is attached below.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: pw_util.c
===
RCS file: /st/src/FreeBSD/src/usr.sbin/vipw/pw_util.c,v
retrieving revision 1.18
diff -u -r1.18 pw_util.c
--- pw_util.c 2000/07/12 00:49:40 1.18
+++ pw_util.c 2001/04/17 05:41:38
@@ -249,8 +249,12 @@
#ifdef YP
extern int _use_yp;
#endif /* YP */
- if (err)
- warn("%s", name);
+ if (err) {
+ if (name != NULL)
+ warn("%s", name);
+ else
+ warn(NULL);
+ }
#ifdef YP
if (_use_yp)
warnx("NIS information unchanged");
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
syscons panic in userconfig mode (with patch)
[ cc'd to -stable since that's affected, too ]
Attempting to switch VTYs in userconfig mode will lead to a null
dereference in syscons. I saw some messages about this on -current,
-stable, or -bugs recently, but I can't find them now. This is pretty
easy to reproduce: simply boot the kernel with the -c flag
(userconfig), and press ALT+F2 (i386). As far as I can tell, this
isn't a new bug.
The patch is also pretty trivial. It just changes the VIRTUAL_TTY
macro not to blindly assume sc-dev[x] is a valid pointer. It is safe
to have it "return" NULL because any code that uses it must (and does)
already check for that condition since si_tty may also be NULL in some
cases (or at least that's the way I understand it).
Could someone please look it over and, if it's okay, commit it?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: syscons.c
===
RCS file: /st/src/FreeBSD/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.355
diff -u -r1.355 syscons.c
--- syscons.c 2001/03/26 12:40:39 1.355
+++ syscons.c 2001/04/07 21:02:31
@@ -122,7 +122,8 @@
#define SC_CONSOLECTL 255
-#define VIRTUAL_TTY(sc, x) (SC_DEV((sc), (x))-si_tty)
+#define VIRTUAL_TTY(sc, x) (SC_DEV((sc), (x)) != NULL ?\
+ SC_DEV((sc), (x))-si_tty : NULL)
static int debugger;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Obscure sysinstall null dereference bug
(Excuse the size of the e-mail; small, one-line patch is at the end.)
On some occasions, sysinstall can be persuaded to follow a NULL
pointer. This particular bug is actually not so straight-forward that
many people would run into it, but it seems I always do :-/ (I've had
this bite me for just about every release since 4.0 or so).
The problem is that a lot of code in sysinstall (dist.c, particuarly)
expects the mediaDevice global variable to be non-NULL. When some
operation fails, you might see code like:
mediaDevice-shutdown(mediaDevice);
if (!mediaDevice-init(mediaDevice))
...
The problem is that sometimes the operation that fails sets
mediaDevice to NULL, causing a nice, annoying NULL dereference. The
simplest way to reproduce this that I've found is as follows:
1. Run sysinstall in whatever mode you want; doesn't matter if it's
on an existing system or not. Somehow get to the part where you
choose which distributions you want, choose at least one, then somehow
get to the part where it will extract the distributions
2. Choose an FTP install. Select ftp.freebsd.org (you can use any
server you want; I'm just using that as an example).
3. Let it start extracting distributions. Allow it to extract at
least one file (i.e., let it do something). At this point, cut off
its link to the FTP server. If this is an existing system,
`ipfw add 1 reset tcp from any to ftp.freebsd.org` works nicely. In
practice, it can be any reason (I've had this happen when I chose "FTP"
instead of "FTP passive" or when the Internet link died).
4. Wait for it to figure out the server is dead. It should prompt
you to select another one. At the "Please select a FreeBSD FTP
distribution site" menu, select Cancel (you'd do this if, e.g., you
wanted to switch from "FTP" to "FTP passive").
5. Push "OK" or "yes" on the dialog boxes it presents.
6. Watch it crash (if this is a new install where sysinstall is
acting as init, it will display a nice "I got sigsegv and that's bad"
message).
As you can deduce from the size of the instructions, few people
probably run into this. Nevertheless, I think that for sysinstall,
anything short of corruption is better than crashing; the latter is
very annoying, esp. after you've spent some time deciding on the
filesystem layout, distributions, packages, etc.
The patch below corrects the problem by removing the
"mediaDevice = NULL" assignment from the mediaClose routine. It's not the most
correct or elegant fix in the world, but too much code assumes
mediaDevice is non-NULL to simply go through and fix all of it.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: media.c
===
RCS file: /st/src/FreeBSD/src/usr.sbin/sysinstall/media.c,v
retrieving revision 1.112
diff -u -r1.112 media.c
--- media.c 2000/09/25 20:19:43 1.112
+++ media.c 2001/04/07 01:19:01
@@ -126,7 +126,6 @@
{
if (mediaDevice)
mediaDevice-shutdown(mediaDevice);
-mediaDevice = NULL;
}
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make buildkernel breakage in sys/modules/if_ef/../../net/if_ef.c??
David Wolfskill [EMAIL PROTECTED] writes:
machine - /usr/src/sys/i386/include
echo "#define INET 1" opt_inet.h
touch opt_inet6.h
rm -f .depend
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I
@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/if_dis
c/../../net/if_disc.c
=== if_ef
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
echo "#define IPX 1" opt_ipx.h
echo "#define INET 1" opt_inet.h
echo "
echo "
echo "
echo "
Try building make(1) manually, sticking it in /usr/bin, and using the
new version to build the kernel.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make buildkernel breakage in sys/modules/if_ef/../../net/if_ef.c??
David Wolfskill [EMAIL PROTECTED] writes:
So I'd have thought that the "make buildkernel" process should have been
using the freshly-made "make" over in /usr/obj -- or am I confused
(again)?
buildkernel tries to use all the newly-built binaries. I think make
is an exception, though. The make that you run (i.e., the one in your
path) is still the old one. Bug? Feature? Who knows.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes:
On Sat, Mar 10, 2001 at 10:32:23PM -0800, Dima Dorfman wrote:
Peter Wemm [EMAIL PROTECTED] writes:
The version of the patch for -current uses the softdep mount option only.
If you remove the mount option, you dont get softupdates.
In this case, it might be better to just turn it on by default and let
Problem is many still feel it should not be used on / .
There's always the 'nosoftdep' mount option. It's also possible to
enable it by default on everything except the root filesystem, but
that's a [minor] POLA violation.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
"David O'Brien" [EMAIL PROTECTED] writes:
As long as someone that is familiar with all the "cool" and more esoteric
uses of `md' was consulted to ensure the framework is sufficiently
capable.
If everyone (well, I guess mostly everyone) can agree on a suitable
format for this md.conf, I'll write the code. Someone already
proposed that mdconfig should be able to parse a config and configure
the devices based on that, but it was dropped in favor of a mount_md
wrapper some time ago.
Again, if someone can come up with a format for md.conf that most
people won't object to, I will write the code. I don't care if you
want to call it mdon or stick it in mdconfig.
Regards
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2001 at 05:12:13PM -0800, Dima Dorfman wrote:
There's always the 'nosoftdep' mount option. It's also possible to
enable it by default on everything except the root filesystem, but
that's a [minor] POLA violation.
I fail to see what is wrong with defaulting to `off'.
Right now, nothing. What mckusick was saying was that he didn't want
to have a "field day" where everyone would have to put "softdep" for
their filesystems in /etc/fstab. Yes, this isn't happening now since
ps's patches are backwards-compatible, but unless you always want to
keep that backwards-compatibility (which isn't bad, IMO), everyone
will eventually have to do it. I've no opinion either way; I'm simply
restating what I saw mckusick agree to.
Regards
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fix for OpenSSL -j build
Kris Kennaway [EMAIL PROTECTED] writes: Can everyone please test this patch against OpenSSL, which should fix the problems observed with -j builds as well as cleaning out the temporary ASM files. I can confirm that this fixes -j-enabled builds on a -current host a few days old. Thanks! Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Mar 11, 2001 at 03:15:27PM -0800, David O'Brien wrote:
It should be a wrapper called mount_mdfs or mount_mfs so people upgrading
can keep their /etc/fstab [mostly] the same.
The latter would be best, IMO.
I wrote a program to do this, but noone showed very much interest on
-hackers. The pros are that it makes it very convenient to do all
sorts of things with md without having to write different scripts to
do it. The cons are that it "calls itself a mount_* but isn't a
mount_* since it just runs a bunch of programs", and that it breaks
`mount -p` because the filesystem shows up as "ufs" (which is
technically correct). I'll post a URL to the code (it's a C program)
if someone wants to look at it.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes:
Why not add the softupdates option to newfs? Since newfs contains every
tunefs option other than softupdates, I consider it a bug that newfs
didn't gain that functionality when it was added to tunefs.
I wrote a patch to do this some time back. Stefan Esser
[EMAIL PROTECTED] pointed out that this would be made redundant when
(if?) softupdates is turned into a mount option. According to him,
mckusick agreed with his point of view on this matter. You can find
his e-mail to -audit about this here:
http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=0+0+archive/2001/freebsd-audit/20010218.freebsd-audit
You can find my patch to newfs at
http://www.unixfreak.org/~dima/home/newfs-softdep.diff. I suppose it
may be a worthwhile addition until se's patch goes in.
Regards
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes:
On Sat, Mar 10, 2001 at 09:06:20PM -0800, Peter Wemm wrote:
I seem to recall Paul Saab has a set for both -current and -stable.
Someone else also just posted a URL to a set of patches.
Is Paul going to commit his, or can I take this on and commit the ones
posted?
Are you talking about se's patches to make softdep a mount option, or
my newfs patch to optionally enable softdep during newfs? The former
isn't something you can just drop in. You'd have to decide if softdep
should be the default. If softdep is made the default, then those who
don't use it for a reason have to add "nosoftdep" to the appropriate
lines in /etc/fstab. If softdep isn't made the default, then those
who do use softdep have to add "softdep" to the appropriate lines to
/etc/fstab. Either way, it isn't something that can silently (i.e.,
without a heads up or something like that) go in. AFAIK there's no
problem with the latter (my newfs patch) except that it will be made
obsolete when the former goes in.
Regards
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
Peter Wemm [EMAIL PROTECTED] writes:
The version of the patch for -current uses the softdep mount option only.
If you remove the mount option, you dont get softupdates.
In this case, it might be better to just turn it on by default and let
those who don't want it somewhere use "nosoftdep"; this is what
mckusick originally agreed to. Here's his e-mail on the subject:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=404219+417718+/usr/local/www/db/text/2000/freebsd-arch/2702.freebsd-arch
Otherwise, the backwards-compatible stuff for -stable sounds good.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problem with sio in -current ... possible cause of hangs?
The Hermit Hacker [EMAIL PROTECTED] writes:
... neat ... I got all the boot info on my serial console, then the login
prompt went to the main screen, and no control on either one ...
is that supposed to happen?
You aren't supposed to get a login screen on the serial line unless
you enabled ttyd0 in /etc/ttys. For example, the following,
ttyd0 "/usr/libexec/getty std.9600" cons25 on secure
enables getty on the serial line. The default in /etc/ttys is for
ttyd? to be marked 'off' (second field from the end). Change that and
try again.
Hope this helps
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problems compiling kern_mutex.c
Matthew Thyer [EMAIL PROTECTED] writes: /usr/src/sys/kern/kern_mutex.c:593: warning: no previous prototype for `_mtx_ assert' /usr/src/sys/kern/kern_mutex.c: In function `_mtx_assert': /usr/src/sys/kern/kern_mutex.c:595: `MA_OWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: (Each undeclared identifier is reported o nly once /usr/src/sys/kern/kern_mutex.c:595: for each function it appears in.) /usr/src/sys/kern/kern_mutex.c:596: `MA_RECURSED' undeclared (first use in th is function) /usr/src/sys/kern/kern_mutex.c:597: `MA_NOTRECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:610: `MA_NOTOWNED' undeclared (first use in th is function) It looks like these are defined when you have, options INVARIANTS in your kernel config. It shouldn't be required, but try adding it and see if that helps. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
cam_periph.o: In function `cam_periph_mapmem':
/usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xa42): undefined refe
rence to `_mtx_assert'
Try putting,
options INVARIANT_SUPPORT
in your kernel config. I think jhb recently made mtx_assert
conditional on that option. Either that, or take out "options
INVARIANTS".
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
What on *earth* are you all referring to?
With current top of tree I get
QUARM:253: unknown option "INVARIANT_SUPPORT"
src/sys/conf/options:
revision 1.256
date: 2001/02/24 19:03:18; author: jhb; state: Exp; lines: +2 -1
Add back in INVARIANT_SUPPORT and expand the comments in NOTES about it
to include the reasoning Eivind justifiably thwapped me over the head with.
...
revision 1.254
date: 2001/02/22 10:03:05; author: jhb; state: Exp; lines: +1 -2
Now that zerror() and SPLASSERT() have been laid to rest, INVARIANT_SUPPORT
is no longer needed. R.I.P.
Looks like you have a tree somewhere between those two commits.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: doFS.sh should obey MDDEVICE if available
Also, I think that this isn't the right fix to a bigger problem. Instead, it shouldn't be hard to get a list of configured devices out of mdconfig via an ioctl on /dev/mdctl. This would be the right fix, as it would fix the general case problem you describe, not just one instance of it. mdconfig wont' be able to tell you what file it is attached to by filename, but it should be able to ask /dev/mdctl for a list of devices and report at least the type of each device (swap, file, etc.). I think I can do this, possibly with a little help. md(4) keeps a list of md_s structures. From these, I think you can fill in the majority (if not all) of the fields in an md_ioctl structure. I tried this, and I can successfully return one almost-filled md_ioctl structure. If someone can suggest a method for returning an arbitrary number of md_ioctl's (a list), I think I may be able to implement this. Any pointers? Thanks Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld Problems at NTP
Any more ideas what to try here? I'm sure you already thought of this, but have you made sure that you aren't running any memory-hogging applications? I just compiled all the ntp programs on my laptop which is a Pentium 75 with 24MB of memory and 64MB of swap (I didn't do an entire buildworld; I don't really want to wait a day). It's running 5.0-20001223-CURRENT, and compiled the ntp suite from 5.0-20010101-CURRENT. Hope this helps Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'host' command with CNAMEs
As I recall, Sean Kelly wrote:
I've got two machines here, one running 4.1-STABLE (from Aug 3) and a
5.0-CURRENT (from Aug 10) and both of them show the same issue. When
you use the 'host' command to resolve a CNAME, it will show all the A
records twice:
(7) smkelly@edgemaster:~$ host www.microsoft.com
www.microsoft.com is a nickname for microsoft.com
microsoft.com has address 207.46.130.45
microsoft.com has address 207.46.230.218
microsoft.com has address 207.46.230.219
microsoft.com has address 207.46.230.218
microsoft.com has address 207.46.230.219
microsoft.com has address 207.46.130.45
It is more complicated than that... the bug only shows up if you specify
an alias name...
You are both correct. In fact, it looks like you're stating the exact
same thing.
The obvious problem is that if 'host' is resolving a CNAME, there are
two independant places which display the real address. My guess is
that at some point, two independant developers decided to change the
way 'host' deals with CNAMEs, but they put their code in different
places. When they commited their code to the CVS repository, there
were no conflicts, and the second one to commit failed to notice that
a part of his code was already implemented.
This bug was actually fixed in rev. 8.28 of host.c (BIND v8.2.1), but
was resurrected in rev. 8.31 (BIND v8.2.2-REL). Since ISC doesn't
release their CVS logs to the public, I can't find out why this was
done (perhaps a developer commited something based on an earlier rev.,
and didn't merge this change).
If anybody wants it, I've made a patch to correct the problem (see
attached). It applies against src/contrib/bind/bin/host/host.c of
5-CURRENT (although host.c is the same in RELENG_4, and it applies
cleanly there). I heard somewhere that the contrib/ tree shouldn't
contain local changes, but I'm unclear as to where local changes to
contribited software go, so I made it against that. Once you've
applied it, all you should have to do is `( cd /usr/src/usr.bin/host
make)`, although I haven't tested that approach. This should also
apply cleanly to host.c of BIND 8.2.3-T5B, as that's what is in
FreeBSD.
Hope this helps
--
Dima Dorfman [EMAIL PROTECTED]
Finger [EMAIL PROTECTED] for my public PGP key.
"When in doubt, use brute force."
-- Ken Thompson
Index: host.c
===
RCS file: /usr/cvs/FreeBSD/src/contrib/bind/bin/host/host.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 host.c
--- host.c 2000/05/26 07:17:07 1.1.1.3
+++ host.c 2000/09/21 23:46:26
@@ -696,8 +696,18 @@
if (!hp-ad)
if (verbose isls == 0)
printf("The following answer is not verified as authentic by
the server:\n");
- while (--ancount = 0 cp cp eom)
+ while (--ancount = 0 cp cp eom) {
cp = pr_rr(cp, answer-qb2, stdout, filter);
+ /*
+* When we ask for address and there is a CNAME, it
+* seems to return both the CNAME and the address.
+* Since we trace down the CNAME chain ourselves, we
+* don't really want to print the address at this
+* point.
+*/
+if (cname ! verbose)
+return (1);
+}
}
if (!verbose)
return (1);
