Patch for ping6 -o
The ping(8) utility has an -o switch that tells it to exit after
receiving the first reply. This is useful, but ping6(8) doesn't have
it.
Simple patch attached.
Comments/reviews/whatnots?
I'll commit to HEAD in a few days if I don't hear any objections.
--
Dima Dorfman
Index: ping6.8
===
RCS file: /home/ncvs/src/sbin/ping6/ping6.8,v
retrieving revision 1.23
diff -u -r1.23 ping6.8
--- ping6.8 10 Feb 2005 09:19:32 - 1.23
+++ ping6.8 15 Nov 2007 11:44:31 -
@@ -29,7 +29,7 @@
.\
.\ $FreeBSD: src/sbin/ping6/ping6.8,v 1.23 2005/02/10 09:19:32 ru Exp $
.\
-.Dd May 17, 1998
+.Dd November 15, 2007
.Dt PING6 8
.Os
.Sh NAME
@@ -40,7 +40,7 @@
.Sh SYNOPSIS
.Nm
.\ without ipsec, or new ipsec
-.Op Fl dfHmnNqtvwW
+.Op Fl dfHmnNoqtvwW
.\ old ipsec
.\ .Op Fl AdEfmnNqRtvwW
.Bk -words
@@ -225,6 +225,8 @@
outgoing interface needs to be specified by
.Fl I
option.
+.It Fl o
+Exit successfully after receiving one reply packet.
.It Fl p Ar pattern
You may specify up to 16
.Dq pad
Index: ping6.c
===
RCS file: /home/ncvs/src/sbin/ping6/ping6.c,v
retrieving revision 1.31
diff -u -r1.31 ping6.c
--- ping6.c 1 Jul 2007 12:08:06 - 1.31
+++ ping6.c 15 Nov 2007 11:45:12 -
@@ -188,6 +188,7 @@
#define F_NIGROUP 0x4
#define F_SUPTYPES 0x8
#define F_NOMINMTU 0x10
+#define F_ONCE 0x20
#define F_NOUSERDATA (F_NODEADDR | F_FQDN | F_FQDNOLD | F_SUPTYPES)
u_int options;
@@ -344,7 +345,7 @@
#endif /*IPSEC_POLICY_IPSEC*/
#endif
while ((ch = getopt(argc, argv,
- a:b:c:dfHg:h:I:i:l:mnNp:qS:s:tvwW ADDOPTS)) != -1) {
+ a:b:c:dfHg:h:I:i:l:mnNop:qS:s:tvwW ADDOPTS)) != -1) {
#undef ADDOPTS
switch (ch) {
case 'a':
@@ -485,6 +486,9 @@
case 'N':
options |= F_NIGROUP;
break;
+ case 'o':
+ options |= F_ONCE;
+ break;
case 'p': /* fill buffer with user pattern */
options |= F_PINGFILLED;
fill((char *)datap, optarg);
@@ -1164,7 +1168,8 @@
*/
pr_pack(packet, cc, m);
}
- if (npackets nreceived = npackets)
+ if (( (options F_ONCE) != 0 nreceived 0) ||
+ (npackets 0 nreceived = npackets))
break;
}
summary();
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer [EMAIL PROTECTED] wrote: What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. Is information about the slot even available on a PC? For something like this: : [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 : vendor = 'Intel Corporation' : device = '82547EI Gigabit Ethernet Controller' : class= network : subclass = ethernet would you consider eth-6-7-0 to be an improvement over em0? It has the advantage of not changing if another card is added to the system, but it's not very informative. For a system that has only its two on-board NICs, em0 and em1 are very obvious--at least it's clear which one corresponds to the label eth 0 on the chassis. pgp4Fog3jMEng.pgp Description: PGP signature
dumpon(8) obsolete
Since sysctl(8) grew support for setting dev_t's, dumpon(8) can be reduced to: sysctl kern.dumpdev=$argument Since dumpon(8) is not a standard interface and only appears to be used in /etc/rc, I'd like to change the latter to use sysctl(8) directly and remove dumpon(8) from the tree. The only issue I can see is that there is a lot of relevant information in the dumpon(8) manual page, but most of it is probably more appropriate for the Handbook or crash(8), anyway. If nobody objects, I'd like to move the relevant stuff out of the dumpon(8) manual and proceed to remove the program itself as described above. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/34744: Add -a (same as -PpR) flag to cp(1)
Jordan DeLong [EMAIL PROTECTED] wrote:
Number: 34744
Category: bin
Synopsis: Add -a (same as -PpR) flag to cp(1)
Description:
some other cp(1) implementations (such as GNU cp) provide a -a
flag, which just means -PpR. somewhat useful.
Does anybody on -hackers object to this change? I find myself using
`cp -RPp` frequently and would welcome this shortcut. If nobody
objects, I'll clean up the patch (minor style and mdoc nits) before
committing.
Thanks.
Fix:
diff -ruN cp.dist/cp.1 cp/cp.1
--- cp.dist/cp.1 Thu Aug 16 05:01:03 2001
+++ cp/cp.1 Fri Feb 8 21:44:40 2002
@@ -77,6 +77,13 @@
.Pp
The following options are available:
.Bl -tag -width flag
+.It Fl a
+Same as specifying the
+.Fl R
+.Fl P
+and
+.Fl p
+flags.
.It Fl H
If the
.Fl R
@@ -226,7 +233,9 @@
.Pp
The
.Fl v
-option is non-standard and its use in scripts is not recommended.
+and
+.Fl a
+options are non-standard and use in scripts is not recommended.
.Sh SEE ALSO
.Xr mv 1 ,
.Xr rcp 1 ,
diff -ruN cp.dist/cp.c cp/cp.c
--- cp.dist/cp.c Wed Jan 30 09:15:46 2002
+++ cp/cp.c Fri Feb 8 21:43:28 2002
@@ -102,7 +102,7 @@
char *target;
Hflag = Lflag = Pflag = 0;
- while ((ch = getopt(argc, argv, HLPRfiprv)) != -1)
+ while ((ch = getopt(argc, argv, aHLPRfiprv)) != -1)
switch (ch) {
case 'H':
Hflag = 1;
@@ -112,6 +112,10 @@
Lflag = 1;
Hflag = Pflag = 0;
break;
+ case 'a':
+ Rflag = 1;
+ pflag = 1;
+ /* FALLTHROUGH */
case 'P':
Pflag = 1;
Hflag = Lflag = 0;
diff -ruN cp.dist/utils.c cp/utils.c
--- cp.dist/utils.c Wed Jan 30 09:15:46 2002
+++ cp/utils.cFri Feb 8 21:39:05 2002
@@ -312,7 +312,7 @@
{
(void)fprintf(stderr, %s\n%s\n,
-usage: cp [-R [-H | -L | -P]] [-f | -i] [-pv] src target,
- cp [-R [-H | -L | -P]] [-f | -i] [-pv] src1 ... srcN directory);
+usage: cp [-R [-H | -L | -P]] [-f | -i] [-apv] src target,
+ cp [-R [-H | -L | -P]] [-f | -i] [-apv] src1 ... srcN directory);
exit(EX_USAGE);
}
Release-Note:
Audit-Trail:
Unformatted:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-bugs in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: jail.c.patch (allowing to use hostnames when invoking jail(8))
Chris Costello [EMAIL PROTECTED] wrote:
On Saturday, November 24, 2001, Igor M Podlesny wrote:
i = inet_aton(argv[3], in);
- if (!i)
- errx(1, Couldn't make sense of ip-number\n);
+ if (!i) {
+ /* check if it is resolveable */
+ struct hostent *hp;
+ hp = gethostbyname(argv[3]);
+ if (hp == NULL) {
+ errx(1, Couldn't make sense of the jail address\n);
+ }
+ else {
+ char **p = hp-h_addr_list;
+ if (p[1] != NULL) {
+ errx(1, Jail should have only one ip-address
associated with!\n);
+ }
+ else {
+ memcpy(in.s_addr, p[0], sizeof(in.s_addr));
+ }
+ }
+ }
I'd rewrite the above (`i = inet_aton' all the way down) as
hp = gethostbyname(argv[3]);
if (hp == NULL) {
errx(1, %s: %s, argv[3], hstrerror(h_errno));
}
in = *(struct in_addr *)hp-h_addr_list[0];
This makes the call to inet_aton() unnecessary (and really
shortens the code!).
As discussed off-list, this is a good idea. Attached is the final
patch that I plan to commit unless I hear objections. Please review.
Thanks.
Index: jail.8
===
RCS file: /ref/cvsf/src/usr.sbin/jail/jail.8,v
retrieving revision 1.30
diff -u -r1.30 jail.8
--- jail.8 2001/09/03 15:42:10 1.30
+++ jail.8 2001/12/09 19:14:30
@@ -43,7 +43,7 @@
.Nm
.Ar path
.Ar hostname
-.Ar ip-number
+.Ar hostname
.Ar command
.Ar ...
.Sh DESCRIPTION
Index: jail.c
===
RCS file: /ref/cvsf/src/usr.sbin/jail/jail.c,v
retrieving revision 1.7
diff -u -r1.7 jail.c
--- jail.c 2001/06/24 20:28:19 1.7
+++ jail.c 2001/12/09 19:14:11
@@ -17,6 +17,7 @@
#include arpa/inet.h
#include err.h
+#include netdb.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -25,12 +26,13 @@
int
main(int argc, char **argv)
{
+ struct hostent *hp;
struct jail j;
int i;
struct in_addr in;
if (argc 5)
- errx(1, Usage: %s path hostname ip-number command ...\n,
+ errx(1, Usage: %s path hostname hostname command ...\n,
argv[0]);
i = chdir(argv[1]);
if (i)
@@ -39,9 +41,11 @@
j.version = 0;
j.path = argv[1];
j.hostname = argv[2];
+ hp = gethostbyname(argv[3]);
+ if (hp == NULL)
+ errx(1, gethostbyname(%s): %s, argv[3], hstrerror(h_errno));
i = inet_aton(argv[3], in);
- if (!i)
- errx(1, Couldn't make sense of ip-number\n);
+ in = *(struct in_addr *)hp-h_addr;
j.ip_number = ntohl(in.s_addr);
i = jail(j);
if (i)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: jail.c.patch (allowing to use hostnames when invoking jail(8))
Dima Dorfman dima@bazooka wrote:
Chris Costello [EMAIL PROTECTED] wrote:
I'd rewrite the above (`i = inet_aton' all the way down) as
hp = gethostbyname(argv[3]);
if (hp == NULL) {
errx(1, %s: %s, argv[3], hstrerror(h_errno));
}
in = *(struct in_addr *)hp-h_addr_list[0];
This makes the call to inet_aton() unnecessary (and really
shortens the code!).
As discussed off-list, this is a good idea. Attached is the final
patch that I plan to commit unless I hear objections. Please review.
Here's an updated patch which is a result of comments from a few
people. The changes are: (a) deconfuse the usage message by not
naming two arguments as hostname (that was sloppiness on my part),
and (b) remove a redundant inet_aton call (gethostbyname(3) will DTRT
with an IP address) [1].
[1] It probably shouldn't, since as others have pointed out to me,
1.1.1.1 is a valid DNS name. The correct solution would be to have
a flag which makes it explicit whether the argument is an IP address
or DNS name, but few, if any, other programs in the system do this,
and I don't think this is a good place to start.
Index: jail.8
===
RCS file: /ref/cvsf/src/usr.sbin/jail/jail.8,v
retrieving revision 1.30
diff -u -r1.30 jail.8
--- jail.8 2001/09/03 15:42:10 1.30
+++ jail.8 2001/12/09 20:45:53
@@ -43,13 +43,16 @@
.Nm
.Ar path
.Ar hostname
-.Ar ip-number
+.Ar address
.Ar command
.Ar ...
.Sh DESCRIPTION
The
.Nm
command imprisons a process and all future descendants.
+The supplied
+.Ar address
+may either be a hostname or IPv4 address.
.Pp
Please see the
.Xr jail 2
Index: jail.c
===
RCS file: /ref/cvsf/src/usr.sbin/jail/jail.c,v
retrieving revision 1.7
diff -u -r1.7 jail.c
--- jail.c 2001/06/24 20:28:19 1.7
+++ jail.c 2001/12/09 20:50:20
@@ -14,23 +14,22 @@
#include sys/jail.h
#include netinet/in.h
-#include arpa/inet.h
#include err.h
-#include stdio.h
+#include netdb.h
#include stdlib.h
-#include string.h
#include unistd.h
int
main(int argc, char **argv)
{
+ struct hostent *hp;
struct jail j;
int i;
struct in_addr in;
if (argc 5)
- errx(1, Usage: %s path hostname ip-number command ...\n,
+ errx(1, Usage: %s path hostname address command ...\n,
argv[0]);
i = chdir(argv[1]);
if (i)
@@ -39,9 +38,10 @@
j.version = 0;
j.path = argv[1];
j.hostname = argv[2];
- i = inet_aton(argv[3], in);
- if (!i)
- errx(1, Couldn't make sense of ip-number\n);
+ hp = gethostbyname(argv[3]);
+ if (hp == NULL)
+ errx(1, gethostbyname(%s): %s, argv[3], hstrerror(h_errno));
+ in = *(struct in_addr *)hp-h_addr;
j.ip_number = ntohl(in.s_addr);
i = jail(j);
if (i)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Reducing syslogd output bloat (was: cvs commit: src/sys/conf Makefile.i386)
Peter Wemm [EMAIL PROTECTED] wrote:
Bruce Evans wrote:
- syslogd: the name of the kernel file is used as a prefix. If I kept
kernels in the standard place, then I would have complained about the
bloatage of syslogd output caused by renaming the kernel from /kernel
to /boot/${NAME_OF_MY_KERNEL}/kernel
It used to print kernel always, even when the kernel was /vmunix
and on other systems when it is /bsd or /netbsd. I'd much rather that
we went back.
When syslogd starts up, it could log the value of kern.bootfile and
kern.module_path once in the kernel log and just use kernel: for identifying
kernel originated messages.
The attached patch implements something like this:
Make the default kernel prefix kernel: instead of the boot file,
with the old behavior available via the -o option (it might still be
useful if one has many kernels and cares which messages came from
which). If the boot file is not used as the prefix, it is still
logged once at startup.
This change is prompted by the fact that the boot file is now much
longer (/boot/kernel/kernel vs. /kernel), which significanlty
bloats the syslogd output.
Please review and comment.
Thanks.
Index: syslogd.8
===
RCS file: /ref/cvsf/src/usr.sbin/syslogd/syslogd.8,v
retrieving revision 1.41
diff -u -r1.41 syslogd.8
--- syslogd.8 2001/09/01 08:42:49 1.41
+++ syslogd.8 2001/11/24 23:32:25
@@ -32,7 +32,7 @@
.\ @(#)syslogd.8 8.1 (Berkeley) 6/6/93
.\ $FreeBSD$
.\
-.Dd October 12, 1995
+.Dd November 24, 2001
.Dt SYSLOGD 8
.Os
.Sh NAME
@@ -40,7 +40,7 @@
.Nd log systems messages
.Sh SYNOPSIS
.Nm
-.Op Fl 46Adknsuv
+.Op Fl 46Adknosuv
.Op Fl a Ar allowed_peer
.Op Fl b Ar bind_address
.Op Fl f Ar config_file
@@ -181,6 +181,12 @@
messages; the default is 20 minutes.
.It Fl n
Disable dns query for every request.
+.It Fl o
+Prefix kernel messages with the full kernel boot file as determined by
+.Xr getbootfile 3 .
+Without this,
+the kernel message prefix is always
+.Dq kernel: .
.It Fl p
Specify the pathname of an alternate log socket to be used instead;
the default is
Index: syslogd.c
===
RCS file: /ref/cvsf/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.92
diff -u -r1.92 syslogd.c
--- syslogd.c 2001/11/14 09:20:24 1.92
+++ syslogd.c 2001/11/25 00:42:26
@@ -273,6 +273,7 @@
intfamily = PF_INET; /* protocol family (IPv4 only) */
#endif
intsend_to_all = 0;/* send message to all IPv4/IPv6 addresses */
+intuse_bootfile = 0; /* log entire bootfile for every kern msg */
char bootfile[MAXLINE+1];/* booted kernel file */
@@ -333,7 +334,7 @@
socklen_t len;
bindhostname = NULL;
- while ((ch = getopt(argc, argv, 46Aa:b:df:kl:m:np:P:suv)) != -1)
+ while ((ch = getopt(argc, argv, 46Aa:b:df:kl:m:nop:P:suv)) != -1)
switch (ch) {
case '4':
family = PF_INET;
@@ -375,6 +376,9 @@
case 'n':
resolve = 0;
break;
+ case 'o':
+ use_bootfile = 1;
+ break;
case 'p': /* path */
funixn[0] = optarg;
break;
@@ -807,7 +811,8 @@
/* add kernel prefix for kernel messages */
if (flags ISKERNEL) {
- snprintf(buf, sizeof(buf), %s: %s, bootfile, msg);
+ snprintf(buf, sizeof(buf), %s: %s,
+ use_bootfile ? bootfile : kernel, msg);
msg = buf;
msglen = strlen(buf);
}
@@ -1337,6 +1342,7 @@
char host[MAXHOSTNAMELEN];
char oldLocalHostName[MAXHOSTNAMELEN];
char hostMsg[2*MAXHOSTNAMELEN+40];
+ char bootfileMsg[LINE_MAX];
dprintf(init\n);
@@ -1525,6 +1531,16 @@
oldLocalHostName, LocalHostName);
logmsg(LOG_SYSLOG|LOG_INFO, hostMsg, LocalHostName, ADDDATE);
dprintf(%s\n, hostMsg);
+ }
+ /*
+* Log the kernel boot file if we aren't going to use it as
+* the prefix, and if this is *not* a restart.
+*/
+ if (signo == 0 !use_bootfile) {
+ (void)snprintf(bootfileMsg, sizeof(bootfileMsg),
+ syslogd: kernel boot file is %s, bootfile);
+ logmsg(LOG_KERN|LOG_INFO, bootfileMsg, LocalHostName, ADDDATE);
+ dprintf(%s\n, bootfileMsg);
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: error in man page kvm_nlist(3) ?
Sansonetti Laurent [EMAIL PROTECTED] wrote: Hi, I think there's an error in man page for kvm_nlist(3): a reference to kldsym(2) which doesn't exist in the manual... pinux@arrakis ~ man kvm_nlist | grep kldsym kldsym(2) is used to locate the symbol. This is a less than perfect emu- kldsym(2), kvm(3), kvm_close(3), kvm_getargv(3), kvm_getenvv(3), pinux@arrakis ~ man 2 kldsym No entry for kldsym in section 2 of the manual I'm running 4.2-RELEASE. This last part is the problem. The kldsym(2) manual page exists in more recent releases. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfw and access
Chad David [EMAIL PROTECTED] wrote: I was just wondering about the caveat in that access(2) man page that says that access is a potential security hole and should never be used, and the fact that ipfw calls it on line 2435. I seem to recall a discussion about this a few months ago, but I don't really remember the details... and the irony of ipfw calling a documented should never be used function got my attention. Is this really a problem, or is the man page paranoid? The manual page is probably paranoid, but I don't think we should change it. It's very easy to abuse access(2). It's a potential security hole if you use it to provide access control. E.g., you're a setuid process, and you got a filename as an argument. You want to open it, but only if the user that called you has sufficient privileges to do so. Using access(2) on that filename and opening it if it returns success would be a security hole, because that file might've changed (mv, cp, chmod, whatever) between your call to access(2) and your call to open(2) (classic example of a race condition). The right thing to do would be to drop effective privileges to that of the user, and use open(2) directly. ipfw just wants to know if its last argument is a valid filename (see the first usage form in the manual page). I think that's a pretty legitimate use, although it shouldn't rely on the fact that the file will exist and/or be readable when it gets around to opening it. I.e., it should still handle a failed open gracefully--and it does. One can still trick it into trying to open a file that isn't there, but the results won't be any more spectacular than doing that to any other program (e.g., `cat /nonexistent`). Besides, ipfw isn't privileged. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Outdated comment in namei.h
The following is from namei.h, around line 116 in -current (r1.30): /* * Namei parameter descriptors. * * SAVENAME may be set by either the callers of namei or by VOP_LOOKUP. * If the caller of namei sets the flag (for example execve wants to * know the name of the program that is being executed), then it must * free the buffer. If VOP_LOOKUP sets the flag, then the buffer must * be freed by either the commit routine or the VOP_ABORT routine. * SAVESTART is set only by the callers of namei. It implies SAVENAME * plus the addition of saving the parent directory that contains the * name in ni_startdir. It allows repeated calls to lookup for the * name being sought. The caller is responsible for releasing the * buffer and for vrele'ing ni_startdir. */ The line marked refers to VOP_ABORT, which doesn't exist. It probably means VOP_ABORTOP, but that was removed two years ago. Anybody care to update this comment, or suggest what to write instead of that sentence? Would s/VOP_ABORT/NDFREE/ do it? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: can't generate vnode_if.h automatically
Rohit Grover [EMAIL PROTECTED] writes: Interestingly, when I executed the command 'make depend', vnode_if.h was correctly created for me. I'd like to know why I don't need to do a 'make depend' for modules like 'vn' or 'nfs' before building them. Perhaps because it was done before? Check to see if you have a '.depend' file in those directories. I'm pretty sure you do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Accessing /dev/klog and similar
Peter Pentchev [EMAIL PROTECTED] writes: Or rather, do not try this while syslogd is running. src/sys/kern/subr_log.c defines the operation of the /dev/klog device, and there is an upper limit on the number of processes that can simultaneously open the log device - the limit is one. That is, while syslogd is running, no other process can open the klog device for reading. This seems to have been the case ever since rev. 1.1 of src/sys/kern/subr_log.c; that is, this has been the case in 4.4BSD and earlier. Anybody have any recollection on why the kernel won't let more than one process intercept log messages (aside from the obvious fact that stacked syslogd's could easily DoS a machine)? Take a look at how it spits out those messages and you'll see why. In short, if you have two processes reading them, neither will get the full set because a read advances the read pointer (msgbufp-bufp, IIRC). This can't easily be fixed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
portmap_enable vs. rpcbind_enable
Does anybody know (remember?) why portmap_enable (the rc.conf knob) wasn't renamed to rpcbind_enable when portmap became rpcbind? It seems odd to have a knob called portmap_enable that actually starts something called rpcbind (not to mention violating POLA). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: portmap_enable vs. rpcbind_enable
Dan Nelson [EMAIL PROTECTED] writes: In the last episode (Jul 31), Dima Dorfman said: Does anybody know (remember?) why portmap_enable (the rc.conf knob) wasn't renamed to rpcbind_enable when portmap became rpcbind? It seems odd to have a knob called portmap_enable that actually starts something called rpcbind (not to mention violating POLA). Probably to keep existing rc.conf's from breaking. Same reason we've still got xntpd_enable. Why not change the names now, but keep the old ones working until, say, 5.0 is branched? People moving from 4.x will have enough hurdles to jump through as it is, and those using -current will have half a year to change it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: portmap_enable vs. rpcbind_enable
David Malone [EMAIL PROTECTED] writes: On Tue, Jul 31, 2001 at 08:33:59AM -0700, Dima Dorfman wrote: Dan Nelson [EMAIL PROTECTED] writes: In the last episode (Jul 31), Dima Dorfman said: Does anybody know (remember?) why portmap_enable (the rc.conf knob) wasn't renamed to rpcbind_enable when portmap became rpcbind? It seems odd to have a knob called portmap_enable that actually starts something called rpcbind (not to mention violating POLA). Probably to keep existing rc.conf's from breaking. Same reason we've still got xntpd_enable. Why not change the names now, but keep the old ones working until, say, 5.0 is branched? People moving from 4.x will have enough hurdles to jump through as it is, and those using -current will have half a year to change it. It still is an extra change for people updating from 4.X to 5.0. Maybe we should just make a portmap_program variable which is set to portmap in -stable and rpcbind in -current. At least things would be orthogonal then. That's what we already have, but we still have a knob that says it will start 'portmap' starting something called 'rpcbind', and the user didn't explicitly ask for that. If people think it's too much trouble, though, I'm not going to press the issue. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Wanted: swapped backed disk on a diskless machine
David Gilbert [EMAIL PROTECTED] writes: Dima == Dima Dorfman [EMAIL PROTECTED] writes: Dima Only the `malloc' md type (as much as the name suggests Dima otherwise, it can be configured not to use malloc as a backing Dima store) has the limits I think you're referring to. Its `swap' Dima backing may be what you need. However, support for that is only Dima in -current, and there are no plans to MFC it since it isn't Dima backwards-compatible with the md that's in -stable. That said, Dima I have patches that backport -current's md to -stable; if Dima anybody wants them, feel free to ask. Me Please! Okay. This isn't a shrink-wrapped package, so you'll need to do a little footwork to get it working, but it's not so bad. You need three things from -current: - src/sys/sys/mdioctl.h; get this from -current and stick it in the same path. - mdconfig(8); you can find this in src/sbin/mdconfig. This compiles cleanly on -stable, but it needs the above header, so make sure it can find it. - md(4); the actual driver. Apply the patch attached below to src/sys/dev/md/md.c. It merges it up to rev. 1.34. Once you've done that, you should be able to recompile your kernel and use mdconfig(8) to configure an md(4) device. The interface is quite different from the one in -stable, but the man page should tell you everything you need to know. You can also get the module build framework from -current if you'd like to use that (src/sys/modules/md). DISCLAIMER: It is not my responsibility if this melts your computer. That isn't likely to happen, of course, but don't blame me if it does. Index: md.c === RCS file: /stl/src/FreeBSD/src/sys/dev/md/md.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 md.c --- md.c2000/07/17 13:48:40 1.8.2.1 +++ md.c2001/06/05 02:41:26 @@ -10,8 +10,55 @@ * */ +/* + * The following functions are based in the vn(4) driver: mdstart_swap(), + * mdstart_vnode(), mdcreate_swap(), mdcreate_vnode() and mddestroy(), + * and as such under the following copyright: + * + * Copyright (c) 1988 University of Utah. + * Copyright (c) 1990, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * the Systems Programming Group of the University of Utah Computer + * Science Department. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + *must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * from: Utah Hdr: vn.c 1.13 94/04/02 + * + * from: @(#)vn.c 8.6 (Berkeley) 4/1/94 + * From: src/sys/dev/vn/vn.c,v 1.122 2000/12/16 16:06:03 + */ + #include opt_mfs.h /* We have adopted some tasks from MFS */ -#include opt_md.h/* We have adopted some tasks from MFS */ +#include opt_md.h #include sys/param.h #include sys/systm.h @@ -19,11 +66,29 @@ #include sys/conf.h #include sys/devicestat.h #include sys/disk.h +#include sys/fcntl.h #include sys/kernel.h +#include sys/linker.h +#include sys/lock.h #include sys/malloc.h +#include sys/mdioctl.h +#include sys/namei.h +#include sys/proc.h +#include sys/queue.h #include sys/sysctl.h -#include sys/linker.h +#include sys/vnode.h + +#include machine/atomic.h
Re: Wanted: swapped backed disk on a diskless machine
David Gilbert [EMAIL PROTECTED] writes: I have somewhat of an interesting problem: I have applications that write arbitrarily large files (as much as 6 gig) and I find that the best performance for these disks is to use something like MFS. However, mfs has a maximum size of 512M. md appears to have a very small maximum size and only resides in core Only the `malloc' md type (as much as the name suggests otherwise, it can be configured not to use malloc as a backing store) has the limits I think you're referring to. Its `swap' backing may be what you need. However, support for that is only in -current, and there are no plans to MFC it since it isn't backwards-compatible with the md that's in -stable. That said, I have patches that backport -current's md to -stable; if anybody wants them, feel free to ask. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A full source-tour somewhere?
Julian Elischer [EMAIL PROTECTED] writes: At one stage at whistle we had the kernel fully cross-referenced using the 'global' program (now in ports) which produced a website that could be browsed to find 'all the callers of xxx()' etc. does anyone have such a site online at the moment? On http://www.freebsd.org/search/ there are links to two sites that might be what you're looking for: * The Source Code * A cross reference of the FreeBSD kernel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: your mail
Alfred Perlstein [EMAIL PROTECTED] writes:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [010723 19:47] wr
ote:
Hello
I am experimenting with kernel modules and am trying to write to a file.
This is the syscall function (sorry of my terminology is messed up)
static int write_file(struct proc *p, void *arg) {
struct write_args *wstructure;
struct open_args *ostructure;
Notice how you (the originator) never allocated memory for these
structures, so this assignment:
ostructure-path=/tmp/blehfile;
dereferences junk on the stack. Once you've fixed that, of course,
you'll have to fix all the issues Alfred and Andrew told you about.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Proper way for *config(8) to load corresponding modules
Most *config(8) programs, such as ifconfig(8), mdconfig(8), and ccdconfig(8), attempt to load their corresponding module if it isn't already loaded, or already compiled into the kernel. Looking at these programs, they achieve this task in (primarily) two different ways. The first uses modfind() then kldload() (e.g., see ccdconfig.c r1.19 l174). Others use a combination of kldnext(), modfnext(), and some loops to do this (e.g., see ifconfig.c r1.64 l1911). Is there any difference between these two, and which one is preferred (I'd think the former if there is no difference). It would be nice if they all did the same thing. Once it's determined which method is preferred, I'd like to propose a kldmaybeload(3) routine that takes a module name and loads it if it's not already loaded or compiled in. For now this just factors out some common code, but it may save headaches later if the kld interface is changed so that neither of these methods work without modification (with a kldmaybeload, it'd be sufficient just to modify the library function). Thanks for any insight. Dima Dorfman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ypbind broken...
Harti Brandt [EMAIL PROTECTED] writes: Hi, The last commit to ypbind (1.34) breaks parsing of the -S option. The following patch should fix this. Oops, my fault; I've applied a variant of this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird stdarg.h problem in 4.3-STABLE
Sheldon Hearn [EMAIL PROTECTED] writes:
static inline void
xdaemonwarn(char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
if (!daemon_quiet)
warn(fmt, ap);
^^
Shouldn't this be `vwarn'?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: disabling reboot on kernel panic
Eugene L. Vorokov [EMAIL PROTECTED] writes: Hello, maybe it's a bit offtopic, but still: how can I disable reboot on kernel panic in 15 seconds, so that it just hangs and I'm able to see what happened when I come ? Set PANIC_REBOOT_WAIT_TIME to -1. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Trailing newline in panic() calls
Hi folks, There are quite a few places in the kernel where panic(9) is called with a trailing newline. E.g.: panic(vm_page_free: freeing wired page\n); That '\n' is redundant, because panic() will print that by itself. Is there any reason not to correct these calls? panic() OpenBSD and NetBSD also prints a newline for the user, so there are no portability issues. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
DDB 'kill' command
Hi folks,
The attached patch implements a 'kill' command in DDB. Previously, it
was possible to do `call psignal(xxx,yyy)` and have it DTRT. (This
was very useful when you accidently got your system so deep in the
hole that spawning kill(1) takes forever and even then possibly
doesn't succeed.) However, psignal() doesn't respect locking by
itself, so trying that now leads to all kinds of badness. This patch
basically wraps the psignal() call in a 'kill' command that respects
all necessary locks.
Actually, it isn't very clear exactly which locks it should respect.
The debugger is a special case in this way. This patch uses the
PROC_TRYLOCK macro; if it fails, the command bails out. Thus, it
can't use pfind()--the latter automatically does a PROC_LOCK--so it
has to walk the allproc list manually. It does *not* attempt to get a
shared lock on the allproc list. There is similar code in db_trace.c,
and it doesn't call sx_slock(), either; I asked jhb about this a while
ago, and all he said was that it is intentional.
Comments? Suggestions?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: db_command.c
===
RCS file: /stl/src/FreeBSD/src/sys/ddb/db_command.c,v
retrieving revision 1.36
diff -u -r1.36 db_command.c
--- db_command.c2001/07/08 04:56:05 1.36
+++ db_command.c2001/07/10 07:19:45
@@ -36,7 +36,12 @@
*/
#include sys/param.h
#include sys/linker_set.h
+#include sys/lock.h
+#include sys/mutex.h
+#include sys/sx.h
+#include sys/proc.h
#include sys/reboot.h
+#include sys/signalvar.h
#include sys/systm.h
#include sys/cons.h
@@ -62,6 +67,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[];
@@ -413,6 +419,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, }
};
@@ -566,4 +573,44 @@
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_t pid, sig;
+
+#define DB_ERROR(f)do { db_printf f; db_flush_lex(); return; } while (0)
+
+ /* Retrieve arguments. */
+ if (!db_expression(sig))
+ DB_ERROR((Missing signal number\n));
+ if (!db_expression(pid))
+ DB_ERROR((Missing process ID\n));
+ db_skip_to_eol();
+ if (sig 0 || sig _SIG_MAXSIG)
+ DB_ERROR((Signal number out of range\n));
+
+ /* Find the process in queston. */
+ /* sx_slock(allproc_lock); */
+ LIST_FOREACH(p, allproc, p_list)
+ if (p-p_pid == pid)
+ break;
+ /* sx_sunlock(allproc_lock); */
+ if (p == NULL)
+ DB_ERROR((Can't find process with pid %d\n, pid));
+
+ /* If it's already locked, bail; otherwise, do the deed. */
+ if (PROC_TRYLOCK(p) == 0)
+ DB_ERROR((Can't lock process with pid %d\n, pid));
+ else {
+ psignal(p, sig);
+ PROC_UNLOCK(p);
+ }
+#undef DB_ERROR
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: panic when returning error on MOD_LOAD
Eugene L. Vorokov [EMAIL PROTECTED] writes: Hello, I'm pretty confused with the fact that kernel panics when my module's event handler returns something greater than zero on MOD_LOAD. I wanted module to refuse to load when it can't find it's config file, so I thought I can return error code and it will not be loaded, and behaviour of module_register_init() and other related functions after quick look seems to be intended to do just that. That look very ugly ... what could I do wrong ? What is the proper way of doing what I wanted ? And oh yes, it's 4.2 system. I can't reproduce this on -current or -stable. It's possible that it was fixed some time between 4.2 and -stable. If you could post the code that breaks it for you, however, we might be able to confirm that. (Alternatively, you could try a simple module that just does return (EINVAL); on MOD_LOAD and see if it still breaks.) Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ifmcstat(8) setgidness
Ruslan Ermilov [EMAIL PROTECTED] writes: On Tue, Jun 26, 2001 at 03:04:07PM -0700, Dima Dorfman wrote: Hi folks, Is there a particular reason, other than the desire for more setgid programs, that ifmcstat(8) is setgid kmem? It seems that there's no reason anyone but root would want to use it, anyway. OpenBSD and NetBSD already nuked its setgid bit; any reason why we shouldn't follow suit? $ ifmcstat kvm_openfiles: Permission denied I don't follow. Yes, it needs access to kmem to work. However, I don't see why anyone other than root would need to run it, so why is it setgid? root can access kmem either way. -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ifmcstat(8) setgidness
Ruslan Ermilov [EMAIL PROTECTED] writes: On Wed, Jun 27, 2001 at 01:29:28AM -0700, Dima Dorfman wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: On Tue, Jun 26, 2001 at 03:04:07PM -0700, Dima Dorfman wrote: Hi folks, Is there a particular reason, other than the desire for more setgid programs, that ifmcstat(8) is setgid kmem? It seems that there's no reason anyone but root would want to use it, anyway. OpenBSD and NetBSD already nuked its setgid bit; any reason why we shouldn't follow suit? $ ifmcstat kvm_openfiles: Permission denied I don't follow. Yes, it needs access to kmem to work. However, I don't see why anyone other than root would need to run it, so why is it setgid? root can access kmem either way. Could you please elaborate on why it should be restricted to root only? Because it looks like it doesn't provide any information that anyone other than the administrator would find useful (if I'm seeing things, please let me know), and the less setgid programs in the system the better our overworked security officer(s) sleep at night :-). OpenBSD's and NetBSD's commitlogs are too terse. This is quite an understatement! Dima Dorfman [EMAIL PROTECTED] Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ifmcstat(8) setgidness
Hi folks, Is there a particular reason, other than the desire for more setgid programs, that ifmcstat(8) is setgid kmem? It seems that there's no reason anyone but root would want to use it, anyway. OpenBSD and NetBSD already nuked its setgid bit; any reason why we shouldn't follow suit? Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: include directive in config(8) (was: Two Junior Kernel Hacker tasks..)
Warner Losh [EMAIL PROTECTED] writes: Is there a way to undef an option? I thought about this, too. Right now there isn't a way to do that, and neither OpenBSD nor NetBSD have one AFAIK. That said, I think it would be trivial to implement. The list of options and devices is a simple linked list (mind you, it's a home-grown one, not queue(3)); it shouldn't be too hard to implement unoption and undevice directives. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
include directive in config(8) (was: Two Junior Kernel Hacker tasks..)
[ peter@ cc'd because he's done a lot of work with config(8) ]
John Baldwin [EMAIL PROTECTED] writes:
On 22-Jun-01 Dima Dorfman wrote:
John Baldwin [EMAIL PROTECTED] writes:
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not
having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
OpenBSD (and I think NetBSD) solve this problem by having an 'include'
directive in the kernel config file. E.g., in
sys/arch/i386/conf/GENRIC (the MD config file):
machine i386
...
include ../../../conf/GENREIC # -- MI config file
...
I think this is much more general than just splitting NOTES. Is there
any reason we shouldn't do this? I'd be willing to implement
'include' in config(8).
That's fine. LINT is still special, because we do extra processing to convert
NOTES to LINT, but that would make updating GENERIC easier.
Okay, attached is a patch to config(8) that implements an 'include'
directive. The include()/endinclude() routines are mostly from
OpenBSD. I can't say I've done excessive testing on this, but it
works pretty well from what I can tell.
Comments? Suggestions? Reviews?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: config.h
===
RCS file: /stl/src/FreeBSD/src/usr.sbin/config/config.h,v
retrieving revision 1.48
diff -u -r1.48 config.h
--- config.h2001/02/28 02:55:15 1.48
+++ config.h2001/06/24 06:11:11
@@ -142,6 +142,7 @@
extern charerrbuf[80];
extern int yyline;
+extern const char *yyfile;
extern struct file_list *ftab;
Index: config.y
===
RCS file: /stl/src/FreeBSD/src/usr.sbin/config/config.y,v
retrieving revision 1.54
diff -u -r1.54 config.y
--- config.y2001/02/22 04:00:29 1.54
+++ config.y2001/06/24 06:11:11
@@ -17,6 +17,7 @@
%token OPTIONS
%token MAKEOPTIONS
%token SEMICOLON
+%token INCLUDE
%token str ID
%token val NUMBER
@@ -77,14 +78,15 @@
char *hints;
inthintmode;
intyyline;
+const char *yyfile;
struct file_list *ftab;
char errbuf[80];
intmaxusers;
#define ns(s) strdup(s)
+int include(const char *, int);
+void yyerror(const char *s);
-static void yyerror(const char *s);
-
static char *
devopt(char *dev)
{
@@ -147,11 +149,14 @@
= {
hints = $2;
hintmode = 1;
- };
+ } |
+ INCLUDE ID
+ = { include($2, 0); };
System_spec:
CONFIG System_id System_parameter_list
- = { errx(1, line %d: root/dump/swap specifications obsolete, yyline);}
+ = { errx(1, %s:%d: root/dump/swap specifications obsolete,
+ yyfile, yyline);}
|
CONFIG System_id
;
@@ -178,7 +183,8 @@
newopt(opt, $1, NULL);
if ((s = strchr($1, '=')))
- errx(1, line %d: The `=' in options should not be quoted,
yyline);
+ errx(1, %s:%d: The `=' in options should not be
+ quoted, yyfile, yyline);
} |
Save_id EQUALS Opt_value
= {
@@ -229,16 +235,17 @@
/* and the device part */
newdev($2, $3);
if ($3 == 0)
- errx(1, line %d: devices with zero units are not likely to be
correct, yyline);
+ errx(1, %s:%d: devices with zero units are not
+ likely to be correct, yyfile, yyline);
} ;
%%
-static void
+void
yyerror(const char *s)
{
- errx(1, line %d: %s, yyline + 1, s);
+ errx(1, %s:%d: %s, yyfile, yyline + 1, s);
}
/*
Index: lang.l
===
RCS file: /stl/src/FreeBSD/src/usr.sbin/config/lang.l,v
retrieving revision 1.30
diff -u -r1.30 lang.l
--- lang.l 2001/02/19 04:43:21 1.30
+++ lang.l 2001/06/24 06:11:11
@@ -35,6 +35,7 @@
* $FreeBSD: src/usr.sbin/config/lang.l,v 1.30 2001/02/19 04:43:21 peter Exp $
*/
+#include assert.h
#include ctype.h
#include string.h
#include y.tab.h
@@ -43,6 +44,19 @@
#define YY_NO_UNPUT
/*
+ * Data for returning to previous files from include files.
+ */
+struct incl {
+ struct incl *in_prev; /* previous includes in effect
Re: Two Junior Kernel Hacker tasks..
John Baldwin [EMAIL PROTECTED] writes:
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
OpenBSD (and I think NetBSD) solve this problem by having an 'include'
directive in the kernel config file. E.g., in
sys/arch/i386/conf/GENRIC (the MD config file):
machine i386
...
include ../../../conf/GENREIC # -- MI config file
...
I think this is much more general than just splitting NOTES. Is there
any reason we shouldn't do this? I'd be willing to implement
'include' in config(8).
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Monthly Development Status Report, June 2001
Robert Watson [EMAIL PROTECTED] writes: - Future Editions Assuming there is some positive feedback on this idea, and that future submissions get made such that there is content for future issues, the goal is to release a development status report once a month. [...] If this ends up being the case (i.e., there's an issue approx. once a month), how about archiving them on the web site? We used to have a newsletter, but it quickly grew stale. This sounds like something developers actually might be interested in (there's no glory in writing something if nobody knows about it ;-) ), so it has a much better chance of succeeding. I don't know if it's worth putting the first issue up not knowing if there will be more; anybody else have an opinion on this? Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: strangeness in web interface of send-pr
Giorgos Keramidas [EMAIL PROTECTED] writes: I have a few hours to spare tonight, and I was using the query-pr-summary.cgi script to view the open PRs. The query URL was (wrapped to avoid terminal silliness): 1 http://www.FreeBSD.org/cgi/query-pr-summary.cgi?\ 2 category=severity=criticalpriority=class=\ 3 state=opensort=categorytext=responsible=\ 4 multitext=originator= You can clearly see that (in line 3), I have chosen to view only PRs whose state is `open' AND (line 2) severity is `critical', in an effort to help closing first those PRs that are more important. Well, guess what, I am getting a summary of PRs in my Netscape window, which includes such PRs as i386/28002. The summary line for this PR looks like: o [2001/06/09] i386/28002make world fails (ref. to ipf) Knowing that this issue has been hashed in the mailing lists, I opened the PR to see what state it is in, and what its trail is so far. When I open the PR in a new window, only then I see that it's state is not `open', but `closed'. Yet, somehow, it has managed to sneak through my query-pr filter, despite the `state=open' rule I use. Does this strike anyone else as a problem of the problem reporting tool? (Nice recursion i got myself in.) Is it possible that the PR was closed between the time when you requested the summary and the time when you requested full information on the PR? -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
Mike Smith [EMAIL PROTECTED] writes: I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Well, I see that we just ripped out the wd compat bits, so I guess we don't care about ABI/API stability that much in -stable any more... We being who? Your Danish henchman? 8) Actually, I do recall discussion over 'wd' being end-of-lifed in 4.x. I suspect that it would make sense to EOL 'mfs' in a similar fashion. I don't think there's a lot of good sense in pulling it out at an arbitrary point, though, any more than there was in pulling 'wd' like it was. FWIW, this thread wasn't (originally) about EOL'ing mfs, but rather making the replacement of MFS (that being md(4)) available in -stable so that when MFS is finally EOL'd (which will be 5.0-REL at the latest), less people will cry. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: Is there any reason not to MFC the new md(4) functionality Zero reason not to. Others see it differently, it would seriously break a lot of people who are using -stable in embedded applications. If we have abandoned the no changes to API or ABI in -stable paradigm, it would be a good idea, but it serious rains on that rule... I don't think it would be much of a practical problem for anyone since the old behvior can be emulated with the new md pretty easily, but you're right that it isn't appropriate to break compatibility in -stable. It's probably possible to retrofit the old behavior into the new code, but I think that's too much evil for too little gain. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
Warner Losh [EMAIL PROTECTED] writes: In message 70325.991758797@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], David O'Brien writes: : On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: : Is there any reason not to MFC the new md(4) functionality : : Zero reason not to. : : Others see it differently, it would seriously break a lot of : people who are using -stable in embedded applications. : : If we have abandoned the no changes to API or ABI in -stable : paradigm, it would be a good idea, but it serious rains on that : rule... I've stated in the past that removing mfs from stable is going to cause me some grief. However, the addition of md won't so long as mfs remains intact. I don't think anybody is even remotely suggesting that MFS be removed, but someone (other than you) might get bitten by a change of this sort. I guess it's just a matter of whether the new functionality (and giving people a head start integrating the new behavior into their systems) is worth burning however many people depend on the old behavior. Dima Dorfman [EMAIL PROTECTED] Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MFC'ing new md(4) functionality?
Is there any reason not to MFC the new md(4) functionality (i.e., swap and vnode support)? With MFS and vn(4) gone in -current, I think that the sooner users can start moving to md(4) in -stable the less cries there will be come 5.0-RELEASE. Additionally, the porting effort is not that great. mdconfig(8) and mdioctl.h aren't in -stable so those can be brought over verbatim, and the only changes to md.c itself are bio-buf stuff, and some added spl's. I've put the diff for the latter against -stable at http://www.unixfreak.org/~dima/home/mdmfc.diff. If someone wants a diff between that and -current for review let me know and I'll generate one. I'm also willing to do the actual merges if no one else has time, so the question raised in the first paragraph remains: is there any reason not to do this? Thanks in advance, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
[EMAIL PROTECTED] (Peter Seebach) writes: In message [EMAIL PROTECTED], David O'Brien writes: On Thu, May 31, 2001 at 09:29:38PM -0700, Dima Dorfman wrote: Although this is a documented shortcoming, it's quite unnecessary given how easy it is to fix it. Any objections to allowing '--' to mean end of env. variable assignments? The orthoginal way (with grep, mv, et. al.) would be to use '==', not '--' as that is the problematic character. Principle of least astonishment says that, sinec everyone else uses -- to indicate the end of a series of options, that's what env should do too. But this isn't terminating the end of a series of options; it's terminating a series of assignments, and since env(1) detemines whether an argument is an assignment or not by whether it has a '=' in it, it makes sense to use '==' as David suggests. It's different from the others because it signifies the end of a different kind of series. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Honestly, I don't care about this all that much. I'll let you and David debate this to your liking. If no consensus develops in the next few days, I'll just commit what I have now. (Obviously, if consensus does develop I'll go along with it.) Thanks, Dima Dorfman [EMAIL PROTECTED] [EMAIL PROTECTED] (Peter Seebach) writes: In message [EMAIL PROTECTED], Dima Dorfman writes: But this isn't terminating the end of a series of options; it's terminating a series of assignments, and since env(1) detemines whether an argument is an assignment or not by whether it has a '=' in it, it makes sense to use '==' as David suggests. No. The reason for -- is that it's two of the *START* of an option. env assignments don't *start* with =. The most consistent thing here is -- to separate parts of a command line. It's different from the others because it signifies the end of a different kind of series. Sure, but the user doesn't necessarily care. Certainly, no one has ever tried to use == to end any sequence of arguments anywhere; people use -- to end subsequences of arguments all the time. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fixing documented bug in env(1)
Hi folks,
Right now, env(1) can't be used to run programs with an equals sign in
them for obvious reasons (if it isn't obvious, read the man page :-).
Although this is a documented shortcoming, it's quite unnecessary
given how easy it is to fix it. Any objections to allowing '--' to
mean end of env. variable assignments?
Patch attached below.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: env/env.c
===
RCS file: /stl/src/FreeBSD/src/usr.bin/env/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env/env.c 1999/08/27 08:59:31 1.5
+++ env/env.c 2001/06/01 04:27:41
@@ -73,6 +73,8 @@
}
for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv)
(void)setenv(*argv, ++p, 1);
+ if (*argv strcmp(*argv, --) == 0)
+ ++argv;
if (*argv) {
execvp(*argv, argv);
err(1, %s, *argv);
@@ -86,6 +88,6 @@
usage()
{
(void)fprintf(stderr,
- usage: env [-] [-i] [name=value ...] [command]\n);
+ usage: env [-] [-i] [name=value ...] [--] [command]\n);
exit(1);
}
Index: printenv/printenv.1
===
RCS file: /stl/src/FreeBSD/src/usr.bin/printenv/printenv.1,v
retrieving revision 1.10
diff -u -r1.10 printenv.1
--- printenv/printenv.1 2001/05/30 03:15:39 1.10
+++ printenv/printenv.1 2001/06/01 04:27:41
@@ -34,7 +34,7 @@
.\@(#)printenv.1 8.1 (Berkeley) 6/6/93
.\ $FreeBSD: src/usr.bin/printenv/printenv.1,v 1.10 2001/05/30 03:15:39 dd Exp $
.\
-.Dd June 6, 1993
+.Dd May 29, 2001
.Dt PRINTENV 1
.Os BSD 3
.Sh NAME
@@ -47,6 +47,7 @@
.Op Fl
.Op Fl i
.Op Ar name=value ...\
+.Op --
.Op Ar command
.Sh DESCRIPTION
.Nm Printenv
@@ -80,6 +81,18 @@
.Ar name ,
with a value of
.Ar value .
+If the argument
+.Ql --
+is found,
+.Nm env
+will assume that the argument(s) following it are part of
+.Ar command ,
+instead of
+.Ar name=value
+pairs,
+even if they have the
+.Ql =
+symbol in them.
.Pp
The options are as follows:
.Bl -tag -width indent
@@ -130,7 +143,3 @@
.Nm
command appeared in
.Bx 3.0 .
-.Sh BUGS
-.Nm Env
-doesn't handle commands with equal (``='') signs in their
-names, for obvious reasons.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Problem with find -fstype local ?
Doug Barton [EMAIL PROTECTED] writes: Gang, This may be my lack of understanding, but doing 'find / -fstype local' is definitely traversing nfs mounted directories for me in -current and -stable. The man page isn't 100% clear, but it seems to me that it should not be doing that. My debugging got as far as determining that the option is being recognized in function.c before I ran out of time. A cursory examination didn't reveal to me any uses of the value that gets added to new-mt_data, but I didn't look very hard. This problem was brought to my attention by /etc/periodic/weekly/340.no id. If I am not correct about what this option really should be doing, for the record it'd be great to have an option for find that _does_ restrict paths to locally mounted directories. See PR 23906. This has been bugging me, too, but so far I've been too lazy to fix it. Doug -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: De-setgid-ifying ipcs(1)
Alfred Perlstein [EMAIL PROTECTED] writes:
Probably not the commentary you're looking for, however the
getopt parsing shouldn't be done like this:
Some comments is usually better than no comments: to have noticed this
problem, you had to have at least skimmed through the other (kernel)
parts, so I know I didn't do anything *too* evil :-).
- while ((i = getopt(argc, argv, MmQqSsabC:cN:optT)) != -1)
+ use_sysctl = 1;
+ while ((i = getopt(argc, argv, MmQqSsabC:cN:optTy)) != -1)
switch (i) {
case 'M':
display = SHMTOTAL;
@@ -184,39 +187,45 @@
case 't':
option |= TIME;
break;
+ case 'y':
+ use_sysctl = !use_sysctl;
+ break;
default:
usage();
}
Multiple -y options will invert the sense of the flag right?
Might as well inialize it to 1 in the DATA segment and replace
!use_sysctl with just 0.
Point taken. I've done as you suggested in the patch I just posted to
-audit for review.
Thanks again,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
background_fsck rc.conf option
Does anybody object to adding a background_fsck rc.conf option to
facilitate easy switching of background fsck on or off? Robert Watson
suggested this on cvs-all some time ago, but the discussion drifted
off. Attached is a very short patch to implement it; it basically
makes rev. 1.263 of src/etc/rc conditional on ${background_fsck}. The
patch leaves background fsck on by default, but now that can be easily
changed; I'm sure there will be a long thread about what the default
should be later.
Comments? Suggestions?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: etc/rc
===
RCS file: /stl/src/FreeBSD/src/etc/rc,v
retrieving revision 1.264
diff -u -r1.264 rc
--- etc/rc 2001/05/13 20:43:30 1.264
+++ etc/rc 2001/05/21 00:19:25
@@ -184,9 +184,14 @@
case ${bootmode} in
autoboot)
echo 'Automatic boot in progress...'
-# To restore old fsck behavior use:
-# fsck -p
- fsck -F -p
+ case ${background_fsck} in
+ [Yy][Ee][Ss])
+ fsck -F -p
+ ;;
+ *)
+ fsck -p
+ ;;
+ esac
case $? in
0)
;;
@@ -810,9 +815,13 @@
;;
esac
-# Start background fsck checks
-echo 'Starting background filesystem checks'
-nice -4 fsck -B -p 21 | logger -p daemon.notice
+# Start background fsck checks if necessary
+case ${background_fsck} in
+[Yy][Ee][Ss])
+ echo 'Starting background filesystem checks'
+ nice -4 fsck -B -p 21 | logger -p daemon.notice
+ ;;
+esac
echo ''
Index: etc/defaults/rc.conf
===
RCS file: /stl/src/FreeBSD/src/etc/defaults/rc.conf,v
retrieving revision 1.105
diff -u -r1.105 rc.conf
--- etc/defaults/rc.conf2001/05/14 20:51:03 1.105
+++ etc/defaults/rc.conf2001/05/21 00:19:25
@@ -33,6 +33,7 @@
local_startup=/usr/local/etc/rc.d /usr/X11R6/etc/rc.d# startup script dirs.
rc_conf_files=/etc/rc.conf /etc/rc.conf.local
fsck_y_enable=NO # Set to YES to do fsck -y if the initial preen fails.
+background_fsck=YES # Attempt to run fsck in the background where possible.
##
### Network configuration sub-section ##
Index: share/man/man5/rc.conf.5
===
RCS file: /stl/src/FreeBSD/src/share/man/man5/rc.conf.5,v
retrieving revision 1.104
diff -u -r1.104 rc.conf.5
--- share/man/man5/rc.conf.52001/05/15 15:52:55 1.104
+++ share/man/man5/rc.conf.52001/05/21 00:19:25
@@ -625,6 +625,13 @@
.Xr fsck 8
will be run with the -y flag if the initial preen
of the filesystems fails.
+.It Va background_fsck
+.Pq Vt bool
+if set to
+.Ar YES ,
+the system will attempt to run
+.Xr fsck 8
+in the background where possible.
.It Va syslogd_enable
.Pq Vt bool
If set to
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
De-setgid-ifying ipcs(1)
Hi folks,
ipcs(1) is currently installed as setgid kmem. This isn't good for
obvious reasons. Moreover, the information it needs is easily
exported via sysctl. Below is a patch which adds the necessary sysctl
oids and changes ipcs(1) to use them. I had to export msgids,
msginfo, sema, seminfo, shmsegs, and shminfo. The *info variables
were exported via SYSCTL_STRUCT, and the rest via SYSCTL_PROC. All
read-only by anyone. I'm not particuarly sure it's appropriate to
export the *info variables like that--at least one of them has most
(all?) of its members already exported via SYSCTL_INT, but that would
be a pain to use in this case. The patch preserves ipcs(1)'s ability
to operate on a saved kernel and core. In addition, I also added a -y
command line flag that will cause it to use kvm(3) instead of
sysctl(3), even on a running system.
Comments? Particuarly, I'd like comments on whether I exported
everything correctly.
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/kern/sysv_msg.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_msg.c,v
retrieving revision 1.30
diff -u -r1.30 sysv_msg.c
--- sys/kern/sysv_msg.c 2001/02/21 06:39:54 1.30
+++ sys/kern/sysv_msg.c 2001/05/18 04:41:24
@@ -1166,3 +1166,17 @@
p-p_retval[0] = msgsz;
return(0);
}
+
+static int
+sysctl_msqids(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, msqids,
+ sizeof(struct msqid_ds) * msginfo.msgmni));
+}
+
+SYSCTL_DECL(_kern_ipc);
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, msginfo, CTLFLAG_RD, msginfo, msginfo,
+System V message info);
+SYSCTL_PROC(_kern_ipc, OID_AUTO, msqids, CTLFLAG_ANYBODY | CTLFLAG_RD,
+NULL, 0, sysctl_msqids, , Message queue IDs);
Index: sys/kern/sysv_sem.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_sem.c,v
retrieving revision 1.32
diff -u -r1.32 sysv_sem.c
--- sys/kern/sysv_sem.c 2001/02/21 06:39:54 1.32
+++ sys/kern/sysv_sem.c 2001/05/18 04:41:24
@@ -28,6 +28,7 @@
static int sysvsem_modload __P((struct module *, int, void *));
static int semunload __P((void));
static void semexit_myhook __P((struct proc *p));
+static int sysctl_sema __P((SYSCTL_HANDLER_ARGS));
#ifndef _SYS_SYSPROTO_H_
struct __semctl_args;
@@ -148,6 +149,9 @@
SYSCTL_INT(_kern_ipc, OID_AUTO, semusz, CTLFLAG_RD, seminfo.semusz, 0, );
SYSCTL_INT(_kern_ipc, OID_AUTO, semvmx, CTLFLAG_RW, seminfo.semvmx, 0, );
SYSCTL_INT(_kern_ipc, OID_AUTO, semaem, CTLFLAG_RW, seminfo.semaem, 0, );
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, seminfo, CTLFLAG_RD, seminfo, seminfo, );
+SYSCTL_PROC(_kern_ipc, OID_AUTO, sema, CTLFLAG_RD | CTLFLAG_ANYBODY,
+NULL, 0, sysctl_sema, , );
#if 0
RO seminfo.semmap /* SEMMAP unused */
@@ -1065,4 +1069,12 @@
#endif
suptr-un_proc = NULL;
*supptr = suptr-un_next;
+}
+
+static int
+sysctl_sema(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, sema,
+ sizeof(struct semid_ds) * seminfo.semmni));
}
Index: sys/kern/sysv_shm.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/sysv_shm.c,v
retrieving revision 1.55
diff -u -r1.55 sysv_shm.c
--- sys/kern/sysv_shm.c 2001/05/04 18:43:19 1.55
+++ sys/kern/sysv_shm.c 2001/05/18 04:41:24
@@ -101,6 +101,7 @@
static int shmunload __P((void));
static void shmexit_myhook __P((struct proc *p));
static void shmfork_myhook __P((struct proc *p1, struct proc *p2));
+static int sysctl_shmsegs __P((SYSCTL_HANDLER_ARGS));
/*
* Tuneable values
@@ -141,6 +142,9 @@
SYSCTL_INT(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RD, shminfo.shmseg, 0, );
SYSCTL_INT(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, shminfo.shmall, 0, );
SYSCTL_INT(_kern_ipc, OID_AUTO, shm_use_phys, CTLFLAG_RW, shm_use_phys, 0, );
+SYSCTL_STRUCT(_kern_ipc, OID_AUTO, shminfo, CTLFLAG_RD, shminfo, shminfo, );
+SYSCTL_PROC(_kern_ipc, OID_AUTO, shmsegs, CTLFLAG_ANYBODY | CTLFLAG_RD,
+NULL, 0, sysctl_shmsegs, , );
static int
shm_find_segment_by_key(key)
@@ -702,6 +706,13 @@
shm_committed = 0;
shmexit_hook = shmexit_myhook;
shmfork_hook = shmfork_myhook;
+}
+
+static int
+sysctl_shmsegs(SYSCTL_HANDLER_ARGS)
+{
+
+ return (SYSCTL_OUT(req, shmsegs, shmalloced * sizeof(shmsegs[0])));
}
static int
Index: usr.bin/ipcs/ipcs.1
===
RCS file: /st/src/FreeBSD/src/usr.bin/ipcs/ipcs.1,v
retrieving revision 1.11
diff -u -r1.11 ipcs.1
--- usr.bin/ipcs/ipcs.1 2000/12/14 11:49:46 1.11
+++ usr.bin/ipcs/ipcs.1 2001/05/18 04:41:24
@@ -37,7 +37,7 @@
.Nd report System V interprocess communication facilities status
.Sh SYNOPSIS
.Nm
-.Op Fl abcmopqstMQST
+.Op Fl abcmopqstMQSTy
.Op Fl C Ar system
.Op Fl N Ar core
.Sh DESCRIPTION
@@ -101,12 +101,16 @@
Extract the name list
Re: xargs(1) replstr patch
Peter Pentchev [EMAIL PROTECTED] writes:
On Mon, May 14, 2001 at 11:31:53PM -0400, Garance A Drosihn wrote:
Still, let me say that I do hope to get back to 'xargs', and add
the -I option. I must admit my enthusiasm for doing -I wore off
after seeing the current code to 'xargs'. Not only is -J more
useful, but it is much less work to implement (given the current
code as a starting point) than -I would be. Still, it *would* be
nice to say we have '-I', just to match what the various standards
list for options to 'xargs'.
While I do like the idea of adding it, I'll admit that it isn't a
particularly high priority on my list of things to do...
Just as a side thought: one we have -J, I guess -I could be done
as simply as emulating -n 1 and falling through to -J :)
Then there would need to be another couple of checks, like -n and -I
or -J and -I not being used simultaneously, but yes, I think it would
really be *that* easy.
Sorry, no. -I can be used more than once, and the replstr does not
have to be given as a separate pointer in argv. For example, given
the input,
one\ntwo\nthree\n
this command
xargs -I [] mv srcdir/[] destdir/[]
should generate:
mv srcdir/one destdir/one
mv srcdir/two destdir/two
mv srcdir/three destdir/three
This is a simplistic example that can be done in many other ways
(including using -J), but it shows what -I is supposed to be able to
do. -J doesn't work with the above since it only looks for the
replstr once, and will not find it unless it's given as a separate
argument. For example, this works:
xargs -J [] echo this is [] a test
but this does not:
xargs -J [] echo this is[] a test
That said, -I isn't all that hard to implement. It's just hard to
implement without rewriting xargs as it is. However, that may not be
a bad thing. -I would pose a performance problem, anyway; it would
have to iterate over the command line arguments and standard input
more than once, possibly having to cache what it finds. If we
special-case -I with something like,
if (flag_I_found) {
alternate_main_function(ac, av, ...);
/*NOTREACHED*/
}
..code as it is now goes here..
then we don't have the problem of destroying the current code, and the
performance impact will only be seen if -I is used (which is
reasonable).
Of course, not that hard is relative. Adding -J was rather trivial;
the delta is +30 -6, and most of those +30 are simple things like
defining or initializing variables. I guess that adding -I would mean
adding on the order of 100 or 150 lines; again, not hard, but not
something one can do in 10 minutes.
Just food for thought, I guess. I'm sure Garance wouldn't mind if
someone did this for him :-).
Regards,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
MIN()/MAX() definitions in sys/param.h
Is there a reason the definitions of the MIN() and MAX() macros in sys/param.h are under an '#ifndef _KERNEL'? Quite a few files in the kernel define these (well, at least MIN) themselves, so it would seem to make sense to define them globally in sys/param.h for the kernel as well. Any reason this isn't already done this way, or should I come up with a patch to fix that? Thanks for any insight, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Making snp(4) a module
Right now, snp(4) can't be compiled as a module because it depends on
hacks in the tty subsystem similar to the following:
#ifdef DEV_SNP
if (ISSET(tp-t_state, TS_SNOOP) tp-t_sc != NULL)
snpin((struct snoop *)tp-t_sc, cp, cc);
#endif
snpin() is a function in snp(4), so it's not simply a matter of
removing the #ifdef's.
Attached is a patch that converts snp(4) to use line disciplines to
get the information it needs. I'm not sure if it's entirely
appropriate to use line disciplines this way, but I think it's a lot
better than the above code, and it has the fortunate sideaffect that
snp(4) can be built as a module. If this gets accepted I'll submit
patches to remove the aforementioned tty hacks.
Comments?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: kern/tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.53
diff -u -r1.53 tty_snoop.c
--- kern/tty_snoop.c2001/04/17 20:53:11 1.53
+++ kern/tty_snoop.c2001/05/15 04:15:51
@@ -12,10 +12,9 @@
*
* Snoop stuff.
*
- * $FreeBSD: src/sys/kern/tty_snoop.c,v 1.53 2001/04/17 20:53:11 dd Exp $
+ * $FreeBSD$
*/
-#include opt_compat.h
#include sys/param.h
#include sys/systm.h
#include sys/filio.h
@@ -29,6 +28,7 @@
#include sys/kernel.h
#include sys/snoop.h
#include sys/vnode.h
+#include sys/conf.h
static d_open_tsnpopen;
static d_close_t snpclose;
@@ -61,9 +61,63 @@
static MALLOC_DEFINE(M_SNP, snp, Snoop device data);
+#define ttytosnp(t) (struct snoop *)(t)-t_sc
static struct tty *snpdevtotty __P((dev_t dev));
static int snp_detach __P((struct snoop *snp));
+/*
+ * The number of the snoop line discipline. This gets determined at
+ * module load time.
+ */
+static int mylinedisc;
+
+static int
+dsnwrite(struct tty *tp, struct uio *uio, int flag)
+{
+ struct snoop *snp = ttytosnp(tp);
+ int error = 0;
+ char ibuf[1024];
+ int ilen;
+ struct iovec iov;
+ struct uio uio2;
+
+ while (uio-uio_resid) {
+ ilen = MIN(sizeof(ibuf), uio-uio_resid);
+ error = uiomove(ibuf, ilen, uio);
+ if (error)
+ break;
+ snpin(snp, ibuf, ilen);
+ /* Hackish, but I think it's the least of all evils. */
+ iov.iov_base = ibuf;
+ iov.iov_len = ilen;
+ uio2.uio_iov = iov;
+ uio2.uio_iovcnt = 1;
+ uio2.uio_offset = 0;
+ uio2.uio_resid = ilen;
+ uio2.uio_segflg = UIO_SYSSPACE;
+ uio2.uio_rw = UIO_WRITE;
+ uio2.uio_procp = uio-uio_procp;
+ error = ttwrite(tp, uio2, flag);
+ if (error)
+ break;
+ }
+ return (error);
+}
+
+/*
+ * XXX should there be a global version of this?
+ */
+static int
+l_nullioctl(struct tty *tp, u_long cmd, char *data, int flags, struct proc *p)
+{
+
+ return (ENOIOCTL);
+}
+
+static struct linesw snpdisc = {
+ ttyopen,ttylclose, ttread, dsnwrite,
+ l_nullioctl,ttyinput, ttstart,ttymodem };
+
static struct tty *
snpdevtotty (dev)
dev_t dev;
@@ -98,7 +152,7 @@
tp = snp-snp_tty;
if ((tp-t_sc == snp) (tp-t_state TS_SNOOP)
- (tp-t_line == OTTYDISC || tp-t_line == NTTYDISC))
+ tp-t_line == mylinedisc)
goto tty_input;
printf(Snoop: attempt to write to bad tty.\n);
@@ -334,9 +388,10 @@
tp = snp-snp_tty;
if (tp (tp-t_sc == snp) (tp-t_state TS_SNOOP)
- (tp-t_line == OTTYDISC || tp-t_line == NTTYDISC)) {
+ tp-t_line == mylinedisc) {
tp-t_sc = NULL;
tp-t_state = ~TS_SNOOP;
+ tp-t_line = snp-snp_olddisc;
} else
printf(Snoop: bad attached tty data.\n);
@@ -409,12 +464,6 @@
if (!tp)
return (EINVAL);
- if ((tp-t_sc != (caddr_t)snp) (tp-t_state TS_SNOOP))
- return (EBUSY);
-
- if ((tp-t_line != OTTYDISC) (tp-t_line != NTTYDISC))
- return (EBUSY);
-
s = spltty();
if (snp-snp_target == NODEV) {
@@ -425,6 +474,8 @@
tp-t_sc = (caddr_t)snp;
tp-t_state |= TS_SNOOP;
+ snp-snp_olddisc = tp-t_line;
+ tp-t_line = mylinedisc;
snp-snp_tty = tp;
snp-snp_target = tdev;
@@ -503,8 +554,6 @@
return (revents);
}
-static void snp_drvinit __P((void *unused));
-
static void
snp_clone(void *arg, char *name, int namelen, dev_t *dev)
{
@@ -519,13 +568,31
xargs(1) replstr patch
Folks,
The attached patch adds a replacement string feature to xargs(1).
There's a full description in the man page update (also attached), but
the following should demonstrate the new functionality:
dima@spike% ./xargs -J [] echo CMD LINE [] ARGS test
CMD LINE this is the contents of the test file ARGS
dima@spike% ./xargs -J [] echo CMD [] LINE ARGS test
CMD this is the contents of the test file LINE ARGS
dima@spike% ./xargs -J [] echo [] CMD LINE ARGS test
this is the contents of the test file CMD LINE ARGS
This is similar to, but not identical to, the -I option described in
SUSv2. The latter allows the replstr ([] above) to be attached to
other arguments, and appear multiple times. Furthermore, it implies
'-n 1'. Although the features are similar, they can solve different
problems; even if -I is implemented later, this (-J) would still be
useful. -J also doesn't have the performance implications attached
with -I.
There was a nice, long thread about this on current a few weeks ago
(topic: Re: cp -d dir patch for review (or 'xargs'?)). It was
rather inconclusive, but nobody managed to come up with a way to
*properly* and *easily* imitate this functionality. Writing a script
to do this *properly* (i.e., handle environment growth) isn't as easy
as it sounds (although it's possible, of course).
The patch is a joint effort between myself and Garance Dorsihn (gad).
Comments? Suggestions?
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: xargs.1
===
RCS file: /st/src/FreeBSD/src/usr.bin/xargs/xargs.1,v
retrieving revision 1.13
diff -u -r1.13 xargs.1
--- xargs.1 2001/05/02 06:41:46 1.13
+++ xargs.1 2001/05/11 23:57:27
@@ -36,7 +36,7 @@
.\@(#)xargs.1 8.1 (Berkeley) 6/6/93
.\ $FreeBSD: src/usr.bin/xargs/xargs.1,v 1.13 2001/05/02 06:41:46 dd Exp $
.\
-.Dd June 6, 1993
+.Dd May 7, 2001
.Dt XARGS 1
.Os
.Sh NAME
@@ -45,6 +45,7 @@
.Sh SYNOPSIS
.Nm
.Op Fl 0
+.Op Fl J Ar replstr
.Oo
.Fl n Ar number
.Op Fl x
@@ -91,6 +92,38 @@
.Fl print0
function in
.Xr find 1 .
+.It Fl J Ar replstr
+If this option is specified,
+.Nm
+will use the data read from standard input to replace the first occurrence of
+.Ar replstr
+instead of appending that data after all other arguments.
+This option will not effect how many arguments will be read from input
+.Pq Fl n ,
+or the size of the command(s)
+.Nm
+will generate
+.Pq Fl s .
+The option just moves where those arguments will be placed in the command(s)
+that are executed.
+The
+.Ar replstr
+must show up as a distinct
+.Ar argument
+to
+.Nm .
+It will not be recognized if, for instance, it is in the middle of a
+quoted string.
+Furthermore, only the first occurrence of the
+.Ar replstr
+will be replaced.
+For example, the following command will copy the list of files and
+directories which start with an uppercase letter in the current
+directory to
+.Pa destdir :
+.Pp
+.Dl /bin/ls -1d [A-Z]* | xargs -J [] cp -rp [] destdir
+.Pp
.It Fl n Ar number
Set the maximum number of arguments taken from standard input for each
invocation of the utility.
@@ -173,6 +206,11 @@
utility is expected to be
.St -p1003.2
compliant.
+The
+.Fl J
+option is a non-standard
+.Fx
+extention which may not be available on other operating systems.
.Sh BUGS
If
.Ar utility
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/05/11 23:57:27
@@ -70,10 +70,15 @@
{
register int ch;
register char *p, *bbp, *ebp, **bxp, **exp, **xp;
- int cnt, indouble, insingle, nargs, nflag, nline, xflag, wasquoted;
- char **av, *argp, **ep = env;
+ int cnt, jfound, indouble, insingle;
+ int nargs, nflag, nline, xflag, wasquoted;
+ char **av, **avj, *argp, **ep, *replstr;
long arg_max;
+ ep = env;
+ jfound = 0;
+ replstr = NULL; /* set if user requests -J */
+
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
* caused some E2BIG errors, so it was changed to ARG_MAX - 4K. Given
@@ -96,8 +101,11 @@
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
nflag = xflag = wasquoted = 0;
- while ((ch = getopt(argc, argv, 0n:s:tx)) != -1)
+ while ((ch = getopt(argc, argv, 0J:n:s:tx)) != -1)
switch(ch) {
+ case 'J':
+ replstr = optarg;
+ break;
case 'n':
nflag = 1;
if ((nargs = atoi(optarg)) = 0)
@@ -144,6 +152,13 @@
else {
cnt = 0;
do
Re: xargs(1) replstr patch
Garance A Drosihn [EMAIL PROTECTED] writes: At 6:03 PM -0700 5/11/01, Dima Dorfman wrote: +For example, the following command will copy the list of files and +directories which start with an uppercase letter in the current +directory to +.Pa destdir : +.Pp +.Dl /bin/ls -1d [A-Z]* | xargs -J [] cp -rp [] destdir +.Pp When I install this man page on -stable, and do a 'man xargs', that last line is displayed to the user as: /bin/ls -1d [A-Z]* | xargs -J [] cp -rp /bin/ls0 0/bin/ls1 That's because it uses more than 8 arguments to .Dl. Old versions of mdoc (read: anything before about a month ago) had a silly limit on the number of arguments. This isn't a problem on any recent -current or -stable. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Who's cleaning up after disk_clone?
disk_clone is set as the dev_clone handler by the disk minilayer to create /dev/disk0sXY devices; however, as far as I can tell, those devices are never destroyed. For example (/dev is devfs here): dima@spike# mdconfig -a -t swap -s 32m md0 dima@spike# disklabel -r -w md0 auto dima@spike# ll /dev/md* crw-r- 1 root operator 95, 0x00010002 May 10 00:12 /dev/md0 crw-r- 1 root operator 95, 2 May 10 00:30 /dev/md0c crw--- 1 root wheel 95, 0x00ff May 10 00:12 /dev/mdctl dima@spike# mdconfig -du0 dima@spike# ll /dev/md* crw-r- 1 root operator 95, 2 May 10 00:30 /dev/md0c crw--- 1 root wheel 95, 0x00ff May 10 00:12 /dev/mdctl Why is md0c still there? It was created as part of the disklabel operation. Furthermore, dima@spike# kldunload md dima@spike# ls /dev/md0c will cause a page fault in kernel mode in this situation. I can't get a crash dump, but vn_isdisk() was called from vn_stat() which was called from stat() (ls called this), and I'm guessing it crashed because there is a stale (now unloaded) cdevsw associated with /dev/md0c. So, my questions are: - is this a bug? At least the page fault is; and - what should be destroying /dev/md0c? Thanks for any insight, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Who's cleaning up after disk_clone?
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Dima Dorfman writes:
- what should be destroying /dev/md0c?
The disk-minilayer.
We need some to keep track of cloned dev_t's so we can nuke them
at various strategic points, havn't gotten to that yet.
Well, that sounds pretty easy to do. Patch attached. It solves this
problem quite effectively. At this point it only nukes the clones
when disk_destroy is called; I don't know if there are other places
this should be done.
Comments?
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/conf.h
===
RCS file: /st/src/FreeBSD/src/sys/sys/conf.h,v
retrieving revision 1.127
diff -u -r1.127 conf.h
--- sys/conf.h 2001/05/01 08:13:17 1.127
+++ sys/conf.h 2001/05/11 03:17:14
@@ -86,6 +86,7 @@
int __sid_bsize_best; /* optimal block size */
} __si_disk;
} __si_u;
+ LIST_ENTRY(specinfo)si_clist;
};
#define si_tty __si_u.__si_tty.__sit_tty
Index: sys/disk.h
===
RCS file: /st/src/FreeBSD/src/sys/sys/disk.h,v
retrieving revision 1.17
diff -u -r1.17 disk.h
--- sys/disk.h 2000/06/15 20:30:53 1.17
+++ sys/disk.h 2001/05/11 03:17:14
@@ -30,6 +30,7 @@
dev_t d_dev;
struct diskslices *d_slice;
struct disklabeld_label;
+ LIST_HEAD(, specinfo) d_clones;
LIST_ENTRY(disk)d_list;
};
Index: kern/subr_disk.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/subr_disk.c,v
retrieving revision 1.36
diff -u -r1.36 subr_disk.c
--- kern/subr_disk.c2001/05/06 21:55:22 1.36
+++ kern/subr_disk.c2001/05/11 03:17:14
@@ -86,6 +86,7 @@
*dev = make_dev(pdev-si_devsw, dkmakeminor(u, s, p),
UID_ROOT, GID_OPERATOR, 0640, name);
+ LIST_INSERT_HEAD(dp-d_clones, *dev, si_clist);
return;
}
}
@@ -129,6 +130,7 @@
dp-d_dev = dev;
dp-d_dsflags = flags;
dp-d_devsw = cdevsw;
+ LIST_INIT(dp-d_clones);
LIST_INSERT_HEAD(disklist, dp, d_list);
if (!once) {
EVENTHANDLER_REGISTER(dev_clone, disk_clone, 0, 1000);
@@ -174,7 +176,14 @@
void
disk_destroy(dev_t dev)
{
+ dev_t pdev;
+
LIST_REMOVE(dev-si_disk, d_list);
+ while (!LIST_EMPTY(dev-si_disk-d_clones)) {
+ pdev = LIST_FIRST(dev-si_disk-d_clones);
+ LIST_REMOVE(pdev, si_clist);
+ destroy_dev(pdev);
+ }
bzero(dev-si_disk, sizeof(*dev-si_disk));
dev-si_disk = NULL;
destroy_dev(dev);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Getting peer credentials on a unix domain socket
Terry Lambert [EMAIL PROTECTED] writes: I think adding a new system call is _not_ the way to go; there are perfectly good fcntl() commands, which fail to work under FreeBSD, but work just fine under Solaris, SunOS, Linux, and most other UNIX systems (we are back to struct fileops being major suckage here). Are you objecting to specifically making this a system call, or implementing it in general? I.e., is a socket option acceptable? Basically, this thread is about trying to find a mechanism that can be used to meet these two conditions on unix domain sockets: 1. Server can obtain the credentials of the connect() caller. 2. The above can be done without depending on the connect() caller to send any data through the socket. Condition 1 is easy to meet; SCM_CREDS already exists. On the other hand, nobody has found an existing way to meet condition 2. If you can change this (i.e., describe a way to do this for the list), great. Otherwise, I have a patch[1] that implements this as a socket option, and William Baxter has a patch to implement it as a system call. Dima Dorfman [EMAIL PROTECTED] [1] http://www.unixfreak.org/~dima/home/peercred.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Man page for struct ucred/xucred
I wrote a rather short manual page about struct ucred, struct xucred, and the routines used to manipulate the former. There really isn't all that much to write about, but I thought it'd be useful to have something that describes the cr* functions even though the code isn't hard to find or particularly difficult to understand. In addition it mentions that struct ucred shouldn't be exported to the userland; it may seem obvious, but implicit traditions are rarely a good thing. While writing this I also noticed that there's no routine to make a struct xucred from a struct ucred. Should there be one? I think so. Perhaps something with an API of void crxucred(struct ucred *cr, struct xucred *xcr); would be useful. Diff against /dev/null for the man page attached. Comments? Suggestions? Thanks, Dima Dorfman [EMAIL PROTECTED] --- /dev/null Sat May 5 16:12:17 2001 +++ ucred.9 Sat May 5 16:49:03 2001 @@ -0,0 +1,108 @@ +.\ +.\ Copyright (c) 2001 Dima Dorfman [EMAIL PROTECTED] +.\ All rights reserved. +.\ +.\ Redistribution and use in source and binary forms, with or without +.\ modification, are permitted provided that the following conditions +.\ are met: +.\ 1. Redistributions of source code must retain the above copyright +.\notice, this list of conditions and the following disclaimer. +.\ 2. Redistributions in binary form must reproduce the above copyright +.\notice, this list of conditions and the following disclaimer in the +.\documentation and/or other materials provided with the distribution. +.\ +.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\ SUCH DAMAGE. +.\ +.\ $FreeBSD$ +.\ +.Dd May 5, 2001 +.Dt UCRED 9 +.Os +.Sh NAME +.Nm ucred , +.Nm xucred +.Nd structures to describe user credentials in the kernel and userland +.Sh SYNOPSIS +.Fd #include sys/types.h +.Fd #include sys/ucred.h +.Ft struct ucred * +.Fn crget void +.Ft void +.Fn crhold struct ucred *cr +.Ft void +.Fn crfree struct ucred *cr +.Ft struct ucred * +.Fn crcopy struct ucred *cr +.Ft struct ucred * +.Fn crdup struct ucred *cr +.Sh DESCRIPTION +The +.Ft ucred +structure describes the user credentials within the kernel. +The +.Ft xucred +structure describes the same user credentials in the userland. +A +.Ft struct ucred +should never be exported to the userland; +instead, it should be converted into a +.Ft struct xucred . +.Pp +The following kernel functions exist to facilitate the maintenance of +user credentials structures within the kernel. +.Pp +.Bl -tag -width crcopy +.It Fn crget +Allocate the memory for and return a zeroed structure. +The reference count is set to 1. +.It Fn crhold +Increment the reference count of +.Fa cr . +.It Fn crfree +Decrement the reference count of +.Fa cr . +If the reference count drops to 0, +the memory for the structure is deallocated. +.It Fn crcopy +Make a copy and subsequently free +.Fa cr . +If the reference count was 1, +this is equivilent to just assigning the address of +.Fa cr +to the new variable. +Otherwise, it is equivilent to calling +.Fn crdup +and +.Fn crfree . +.It Fn crdup +Allocate memory for a new structure and populate its contents with +those from +.Fa cr . +The reference count of the new structure is set to 1. +.El +.Sh NOTES +The +.Dv cr_uid +member of +.Ft struct ucred +should never be inspected directly to determine whether the user +associated with this credentials structure should have superuser +privileges. +Instead, one of the +.Xr suser 9 +functions should be used. +.Sh BUGS +There is no routine to convert a +.Ft struct ucred +into a +.Ft struct xucred . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Getting peer credentials on a unix domain socket
Is there a reliable method of obtaining the credentials (uid/gid) of a peer (SOCK_STREAM sockets only, obviously) on a unix domain socket? All the Stevens books I have suggest that there isn't, but I'm wondering if something has been developed since those books were published. Note that a BSD/OS-like LOCAL_CREDS socket opt is not sufficient because using the latter the process must wait until the peer sends something before they can learn its credentials. If this process intends to drop the connection if it's not from an authorized source, this may lead to a DoS attack. Timers don't help, either; think of TCP SYN flood-like attacks. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Getting peer credentials on a unix domain socket
William E. Baxter [EMAIL PROTECTED] writes: On Fri, May 04, 2001 at 05:07:38PM -0700, Alfred Perlstein wrote: * Dima Dorfman [EMAIL PROTECTED] [010504 16:06] wrote: Is there a reliable method of obtaining the credentials (uid/gid) of a peer (SOCK_STREAM sockets only, obviously) on a unix domain socket? All the Stevens books I have suggest that there isn't, but I'm wondering if something has been developed since those books were published. Note that a BSD/OS-like LOCAL_CREDS socket opt is not sufficient because using the latter the process must wait until the peer sends something before they can learn its credentials. If this process intends to drop the connection if it's not from an authorized source, this may lead to a DoS attack. Timers don't help, either; think of TCP SYN flood-like attacks. Someone had some patches for a getpeercreds() syscall, but I wasn't happy with it considering we already have the sendmsg() stuff to pass credentials along with the fact that the initial creator of a socket may be long gone before it's used to connect to something. I wrote that patch. Links to my patches appear at http://www.superscript.com/patches/intro.html Cool! Actually, I wrote a patch[1] to implement something simlar before sending my original e-mail. I looked at your patches, and it seems the main difference is that mine uses the getsockopt interface instead of a system call, and mine uses struct xucred which, I believe, is the correct way of passing user credentials to the userland (this structure didn't exist in FreeBSD 4.0, which is what it looks like your patch is against). Other than that they do pretty much the same thing :-). Explanatory material and links to the same appear at http://www.superscript.com/ucspi-ipc/getpeereid.html My patch is designed to satisfy these conditions: 1. Server can obtain credentials of connect() caller (effective uid and gid suffice). 2. Server can obtain credentials without depending on client to send data. Having met these conditions, it is nearly trivial to create privileged servers that run behind a unix socket, in an environment under their own control. In many instances one can replace setuid programs with such servers. Just to expand on that a little more (for others on the list), consider crontab(1). It's setuid root right now. Obviously that's not good. One way of getting rid of that setuid bit is to have cron(8) (or another daemon) listen on a world-writable unix domain socket, and have crontab(1) just be a user interface which sends the information via that socket. With some mechanism to get the credentials of the user that connected, this would be possible. Regards, Dima Dorfman [EMAIL PROTECTED] [1] http://www.unixfreak.org/~dima/home/peercred.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Getting peer credentials on a unix domain socket
Alfred Perlstein [EMAIL PROTECTED] writes: * Dima Dorfman [EMAIL PROTECTED] [010504 20:22] wrote: Just to expand on that a little more (for others on the list), consider crontab(1). It's setuid root right now. Obviously that's not good. One way of getting rid of that setuid bit is to have cron(8) (or another daemon) listen on a world-writable unix domain socket, and have crontab(1) just be a user interface which sends the information via that socket. With some mechanism to get the credentials of the user that connected, this would be possible. The silly part of it is that the socket's initial credentials might be different than the holder's credentials. Perhaps it is silly to a human, but I don't see how it makes much of a difference. I'm assuming you're talking about either fork()/exec() or descriptor passing. I don't mean to sound rude, but if a user is silly enough to forget to close that descriptor before exec'ing an untrusted program, or he passes it to a program that has no business using it, there are bigger problems. OTOH, the user may legitmately want to do that. If the server is concerned about that, it can always use both techniques (this and SCM_CREDS) together. Without using this, however, the server may be vulnerable to a DoS attack. In cron's case, this attack may be in the form of opening lots of connections and not writing anything. It can't refuse duplicate connections from the same user because it doesn't know who's connected until they send something. BTW, I hope I made it clear that this is for *stream sockets*. It's horribly useless on datagram sockets. Just making sure in case that's what you were thinking about. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Port-related C++ question
Jos Backus [EMAIL PROTECTED] writes: On Sat, Apr 28, 2001 at 09:32:51PM -0700, Dima Dorfman wrote: Jos Backus [EMAIL PROTECTED] writes: void stdin(const Config config); -=== line 99 `stdin' is a global variable which, surprisingly enough, refers to the standard input stream. Don't name a function after it and your problem should go away. Yeah, I am just puzzled as to how this can build at all on other platforms (Linux?), unless they don't define this variable. I don't know how other systems do it, but I can imagine that they could define `stdin' as a real global variable--as compared to a #define in FreeBSD. Then the above just spams over the symbol. I don't know the details of C's scoping rules to know if that would work as they want it, but I guess it's possible. Thanks, -- Jos Backus _/ _/_/_/Modularity is not a hack. _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Port-related C++ question
Jos Backus [EMAIL PROTECTED] writes: void stdin(const Config config); -=== line 99 `stdin' is a global variable which, surprisingly enough, refers to the standard input stream. Don't name a function after it and your problem should go away. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
allscreens_flags for kbdcontrol (patch)
The attached patch adds an rc.conf option, allscreenskbd_flags, which
does the same thing as allscreens_flags except it runs kbdcontrol
instead of vidcontrol. I'm not really sure why these programs were
separated, but that's another story. This patch allows one to stick
'allscreenskbd_flags=-h 200' in rc.conf and automatically have the
scrollback buffer size set to 200 lines for all the virtual terminals.
Comments?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: rc.syscons
===
RCS file: /st/src/FreeBSD/src/etc/rc.syscons,v
retrieving revision 1.1
diff -u -r1.1 rc.syscons
--- rc.syscons 2001/01/09 22:28:17 1.1
+++ rc.syscons 2001/04/25 03:55:46
@@ -173,4 +173,13 @@
done
fi
+# set this mode for all virtual screens, but use kbdcontrol
+#
+if [ -n ${allscreenskbd_flags} ]; then
+ echo -n ' allscreenskbd'
+ for ttyv in /dev/ttyv*; do
+ kbdcontrol ${allscreenskbd_flags} ${ttyv} ${ttyv} 21
+ done
+fi
+
echo '.'
Index: defaults/rc.conf
===
RCS file: /st/src/FreeBSD/src/etc/defaults/rc.conf,v
retrieving revision 1.99
diff -u -r1.99 rc.conf
--- defaults/rc.conf2001/04/04 16:48:56 1.99
+++ defaults/rc.conf2001/04/25 03:55:47
@@ -293,6 +293,7 @@
moused_port=/dev/psm0 # Set to your mouse port.
moused_flags=# Any additional flags to moused.
allscreens_flags=# Set this vidcontrol mode for all virtual screens
+allscreenskbd_flags= # Set this kbdcontrol mode for all virtual screens
##
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
cut(1) and long lines
Attached is a rather short patch to make cut(1) properly deal with
long lines. Basically, it converts it to use fgetln() instead of
fgets(). An an aside, this also fixed the case where the last line
doesn't have a trailing newline. Note that specifying a list over
2048 on the command line (e.g., the -f option) still isn't supported,
but at least cut(1) doesn't choke when you want the second token but
feed it a couple thousand characters in one line.
Comments?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: cut.c
===
RCS file: /st/src/FreeBSD/src/usr.bin/cut/cut.c,v
retrieving revision 1.12
diff -u -r1.12 cut.c
--- cut.c 2001/02/06 20:03:48 1.12
+++ cut.c 2001/04/20 07:58:59
@@ -228,19 +228,22 @@
int ch, field, isdelim;
char *pos, *p, sep;
int output;
- char lbuf[_POSIX2_LINE_MAX + 1];
+ char *lbuf;
+ size_t lbuflen;
- for (sep = dchar; fgets(lbuf, sizeof(lbuf), fp);) {
+ for (sep = dchar; (lbuf = fgetln(fp, lbuflen)) != NULL;) {
+ /* Assert EOL has a newline. */
+ if (*(lbuf + lbuflen - 1) != '\n')
+ *(lbuf + lbuflen) = '\n';
output = 0;
- for (isdelim = 0, p = lbuf;; ++p) {
- if (!(ch = *p))
- errx(1, "%s: line too long.", fname);
+ for (isdelim = 0, p = lbuf; p lbuf + lbuflen; ++p) {
+ ch = *p;
/* this should work if newline is delimiter */
if (ch == sep)
isdelim = 1;
if (ch == '\n') {
if (!isdelim !sflag)
- (void)printf("%s", lbuf);
+ (void)fwrite(lbuf, lbuflen, 1, stdout);
break;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Restricting the console to one vty (patch)
Attached is a patch that makes it possible to restrict (``freeze'')
the console to a single vty (the active one). This can be used in
conjunction with, e.g., lock(1) to setup a relative safeguard against
malicious access while the user is away from his terminal (lock(1)
alone doesn't help unless the user wants to do it for every vty he's
logged into, which quickly gets repetitive). I believe this would be
especially useful for laptops.
Of course, this doesn't prevent malicious access in terms of somebody
ripping out a disk, rebooting off of another disk, or one of the other
umpteen things one can do with physical access to a computer.
Instead, this is intended to protect things like ssh-agent sessions
where rebooting destroys the cached credentials.
Comments? Suggestions?
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/sys/consio.h
===
RCS file: /home/ncvs/src/sys/sys/consio.h,v
retrieving revision 1.6
diff -u -r1.6 consio.h
--- sys/sys/consio.h2000/04/27 13:34:31 1.6
+++ sys/sys/consio.h2001/04/18 07:29:30
@@ -116,6 +116,9 @@
/* set the history (scroll back) buffer size (in lines) */
#define CONS_HISTORY _IOW('c', 9, int)
+/* freeze the console (prevent vty switching) */
+#define CONS_FREEZE_IOW('c', 10, int)
+
/* mouse cursor ioctl */
struct mouse_data {
int x;
Index: sys/dev/syscons/syscons.c
===
RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.355
diff -u -r1.355 syscons.c
--- sys/dev/syscons/syscons.c 2001/03/26 12:40:39 1.355
+++ sys/dev/syscons/syscons.c 2001/04/18 07:29:32
@@ -747,6 +747,13 @@
sc-flags = ~SC_QUIET_BELL;
return 0;
+case CONS_FREEZE:
+ if ((*(int *)data) 0x01)
+ sc-flags |= SC_SCRN_FROZEN;
+ else
+ sc-flags = ~SC_SCRN_FROZEN;
+ return 0;
+
case CONS_GETINFO: /* get current (virtual) console info */
{
vid_info_t *ptr = (vid_info_t*)data;
@@ -2070,6 +2077,13 @@
int s;
DPRINTF(5, ("sc0: sc_switch_scr() %d ", next_scr + 1));
+
+/* if the console is frozen, disallow vty switching */
+if (sc-flags SC_SCRN_FROZEN) {
+ sc_bell(sc-cur_scp, sc-cur_scp-bell_pitch,
+ sc-cur_scp-bell_duration);
+ return EPERM;
+}
/* delay switch if the screen is blanked or being updated */
if ((sc-flags SC_SCRN_BLANKED) || sc-write_in_progress
Index: sys/dev/syscons/syscons.h
===
RCS file: /home/ncvs/src/sys/dev/syscons/syscons.h,v
retrieving revision 1.65
diff -u -r1.65 syscons.h
--- sys/dev/syscons/syscons.h 2001/03/11 22:48:03 1.65
+++ sys/dev/syscons/syscons.h 2001/04/18 07:29:32
@@ -163,6 +163,7 @@
#defineSC_SCRN_IDLE(1 5)
#defineSC_SCRN_BLANKED (1 6)
#defineSC_SAVER_FAILED (1 7)
+#defineSC_SCRN_FROZEN (1 8)
#defineSC_INIT_DONE(1 16)
#defineSC_SPLASH_SCRN (1 17)
Index: usr.sbin/vidcontrol/vidcontrol.1
===
RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v
retrieving revision 1.33
diff -u -r1.33 vidcontrol.1
--- usr.sbin/vidcontrol/vidcontrol.12001/04/18 07:21:58 1.33
+++ usr.sbin/vidcontrol/vidcontrol.12001/04/18 07:29:33
@@ -30,6 +30,7 @@
.Ar file
.Oc
.Op Fl g Ar geometry
+.Op Fl h Cm on | off
.Op Fl i Cm adapter | mode
.Op Fl l Ar screen_map
.Op Fl L
@@ -163,6 +164,11 @@
and
.Sx EXAMPLES
below.
+.It Fl h Cm on | off
+Freeze or unfreeze the console.
+When the console is frozen
+.Pq Cm on ,
+all attempts to switch to a different virtual terminal will fail.
.It Fl i Cm adapter
Shows info about the current video adapter.
.It Fl i Cm mode
Index: usr.sbin/vidcontrol/vidcontrol.c
===
RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v
retrieving revision 1.35
diff -u -r1.35 vidcontrol.c
--- usr.sbin/vidcontrol/vidcontrol.c2001/04/09 17:24:29 1.35
+++ usr.sbin/vidcontrol/vidcontrol.c2001/04/18 07:29:33
@@ -69,7 +69,7 @@
{
fprintf(stderr, "%s\n%s\n%s\n%s\n",
"usage: vidcontrol [-r fg bg] [-b color] [-c appearance] [-d] [-l scrmap]",
-" [-i adapter | mode] [-L] [-M char] [-m on|off]",
+" [-i adapter | mode] [-L] [-M char] [-m on|off] [-h on|off]",
" [-f size file] [-s number] [-t N|off] [-x] [-g geometry]",
" [mode] [fgcol [bgcol]] [show]");
exit(1);
@@ -470,6 +470,25 @@
}
void
+set_freeze(char *arg)
+{
+ int data;
+ int rv = 0;
+
+ if (strcmp(arg, &quo
Patch to make snp(4) devfs-friendly
Attached is a patch to make the snp(4) driver play ball with DEVFS.
For better or for worse, I used the bpf(4) driver as a guide on how to
do this.
If someone could review this, and, if nothing is wrong with it, commit
it, I'd appreciate it.
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 08:17:23
@@ -286,12 +286,9 @@
if ((error = suser(p)) != 0)
return (error);
- if (dev-si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (dev-si_drv1 == NULL)
dev-si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
- } else
+ else
return (EBUSY);
/*
@@ -365,6 +362,7 @@
free(snp-snp_buf, M_SNP);
snp-snp_flags = ~SNOOP_OPEN;
dev-si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +503,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", u) != 1)
+ return;
+ *dev = make_dev(snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(snp_cdevsw);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
Brian Somers [EMAIL PROTECTED] writes:
I haven't actually tested the code, but looking at the patch, I think
there's a problem with it...
Specifically, on a non-devfs system - where the device nodes are
created with mknod(1), snp_clone() isn't going to be called before
snpopen().
I've (ab)used drv2 as a flag to say whether make_dev() has been
called in net/if_tun.c, but I'm not sure if this is the right answer
either :*]
I think the correct approach is to check for !(si_flags SI_NAMED) as
done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug,
which has since been fixed). That was written by phk, who I take to
be pretty authoritative on the subject; looking at the places SI_NAMED
is used also supports this conclusion.
A corrected patch is attached (although I didn't test it in the
non-devfs case).
Thanks!
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 09:16:52
@@ -287,10 +287,10 @@
return (error);
if (dev-si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (!(dev-si_flags SI_NAMED))
+ make_dev(snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL,
+ 0600, "snp%d", dev2unit(dev));
dev-si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
} else
return (EBUSY);
@@ -365,6 +365,7 @@
free(snp-snp_buf, M_SNP);
snp-snp_flags = ~SNOOP_OPEN;
dev-si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +506,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", u) != 1)
+ return;
+ *dev = make_dev(snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(snp_cdevsw);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
Brian Somers [EMAIL PROTECTED] writes:
This looks good. I'd say you should commit the change yourself -
feel free to say it's reviewed by me.
I'm not a src/ committer.. :-/
As an aside, when I did this to if_tun, I chose to do all the
destroy_dev()s at module unload time (I guess the snp device could do
with a MODULE_DECLARE). This allows the administrator to relax the
The problem with making snp a module is that it relies on hooks in the
tty subsystem which normally aren't there. Take a look at tty.c and
search for "DEV_SNP". If we wanted to make it a module, those hooks
would have to be compiled into the base kernel. Since they call some
snp-specific functions (snpin, snpinc), those would also have to be in
the base kernel. Of course, all of that stuff can be made a kernel
option, but that kind of defeats the purpose of making it a module.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: question on kvm_getprocs
Evan S [EMAIL PROTECTED] writes:
if ((kinfo = malloc(nentries * sizeof(*kinfo))) == NULL)
err(1, NULL);
for (i = nentries; --i = 0; ++proc_list) {
(kinfo[i])-ki_p = proc_list;
if (KI_PROC(kinfo[i])-p_prison)
{
printf("Jailed Process\n");
printf("%s\n",
KI_PROC(kinfo[i])-p_prison-pr_host);
}
}
KI_PROC is just a macro that is
#define KI_PROC(ki) ((ki)-ki_p-kp_proc)
[teqnix](~/work/c/getprocs)%gcc -g -lkvm getprocs.c -o getprocs
getprocs.c: In function `main':
getprocs.c:87: dereferencing pointer to incomplete type
pr_host is a member of struct prison, which is a kernel structure.
It's under #ifdef _KERNEL, which is why you don't have a definition
for it. I'm not quite sure where you're getting your process list
from, but I think that p_prison is a kernel pointer in your context.
Obviously, trying to follow that from the userland won't do what you
want. :-)
Then again, I could be wrong. If you want, take the definition of
struct prison from /usr/include/sys/jail.h and paste it into your
code. That will get rid of the warning. If your program seg faults
when you try to run it, you'll know I was right.
Regards,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
Boris Popov [EMAIL PROTECTED] writes:
This is not a bikeshed, but sysctl is the wrong interface to do
this. Use VFSs/VOPs instead. This isn't a big problem with passing string
from kernel to userland.
I like your idea of using the extattr interface. It isn't a perfect
match, since ideally this would be a VFS operation, but it works quite
well. The only modifications required are to mount(8) to try to get
this attribute, and then to any filesystem which wishes to support it.
Below is a patch which makes the necessary changes to mount(8), and
adds support for this to NFS. It's amazingly simple, and doesn't
interfere with anything else (i.e., you don't have to rebuild half the
world to use it). The only thing I don't like is that the "mountopts"
and "mountopts_verbose" constants aren't macroized, but that can be
easily solved (I just didn't know where to put them). With it,
mount(8) outputs stuff like this:
dima@spike% /sbin/mount -vt nfs
pid295@spike:/host on /host (nfs, v2, udp, hard, intr)
pid295@spike:/st on /st (nfs, v2, udp, hard, intr)
bazooka:/a on /.amd/bazooka/host/a (nfs, nodev, nosuid, v3, tcp, hard, intr)
bazooka:/b on /.amd/bazooka/host/b (nfs, nodev, nosuid, v3, tcp, hard, intr)
Comments? Suggestions?
Thanks in advance
Dima Dorfman
[EMAIL PROTECTED]
P.S. Would anyone have a fit if I wrote man pages for
extattr_get_file, extattr_set_file, and extattr_delete_file?
Index: sbin/mount/mount.c
===
RCS file: /st/src/FreeBSD/src/sbin/mount/mount.c,v
retrieving revision 1.41
diff -u -r1.41 mount.c
--- sbin/mount/mount.c 2000/11/22 17:54:56 1.41
+++ sbin/mount/mount.c 2001/03/25 22:16:14
@@ -49,6 +49,7 @@
#include sys/mount.h
#include sys/stat.h
#include sys/wait.h
+#include sys/uio.h
#include err.h
#include errno.h
@@ -505,6 +506,8 @@
int flags;
struct opt *o;
struct passwd *pw;
+ struct iovec iov;
+ char buf[128];
(void)printf("%s on %s (%s", sfp-f_mntfromname, sfp-f_mntonname,
sfp-f_fstypename);
@@ -515,6 +518,11 @@
(void)printf(", %s", o-o_name);
flags = ~o-o_opt;
}
+ iov.iov_base = buf;
+ iov.iov_len = sizeof(buf);
+ if (extattr_get_file(sfp-f_mntonname,
+ verbose ? "mountopts_verbose" : "mountopts", iov, 1) 0)
+ (void)printf(", %s", iov.iov_base);
if (sfp-f_owner) {
(void)printf(", mounted by ");
if ((pw = getpwuid(sfp-f_owner)) != NULL)
Index: sys/nfs/nfs_vnops.c
===
RCS file: /st/src/FreeBSD/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.164
diff -u -r1.164 nfs_vnops.c
--- sys/nfs/nfs_vnops.c 2001/02/28 04:13:11 1.164
+++ sys/nfs/nfs_vnops.c 2001/03/25 22:16:14
@@ -62,6 +62,7 @@
#include sys/lockf.h
#include sys/stat.h
#include sys/sysctl.h
+#include sys/sbuf.h
#include vm/vm.h
#include vm/vm_extern.h
@@ -130,6 +131,7 @@
static int nfs_print __P((struct vop_print_args *));
static int nfs_advlock __P((struct vop_advlock_args *));
static int nfs_bwrite __P((struct vop_bwrite_args *));
+static int nfs_getextattr __P((struct vop_getextattr_args *));
/*
* Global vfs data structures for nfs
*/
@@ -169,6 +171,7 @@
{ vop_symlink_desc,(vop_t *) nfs_symlink },
{ vop_unlock_desc, (vop_t *) vop_stdunlock },
{ vop_write_desc, (vop_t *) nfs_write },
+ { vop_getextattr_desc, (vop_t *) nfs_getextattr },
{ NULL, NULL }
};
static struct vnodeopv_desc nfsv2_vnodeop_opv_desc =
@@ -3397,4 +3400,51 @@
}
}
return (VOCALL(fifo_vnodeop_p, VOFFSET(vop_close), ap));
+}
+
+/*
+ * Get extended attributes. Currently this is only used to retrieve
+ * filesystem-specific mount options for consumption by mount(8).
+ */
+static int
+nfs_getextattr(ap)
+ struct vop_getextattr_args /*{
+ IN struct vnode *a_vp;
+ IN const char *a_name;
+ INOUT struct uio *a_uio;
+ IN struct ucred *a_cred;
+ IN struct proc *a_p;
+ }; */ *ap;
+{
+ struct nfsmount *nmp = VFSTONFS(ap-a_vp-v_mount);
+ struct sbuf sb;
+ char *outp;
+ int outl, verbose = 0, error = 0;
+
+ /* XXX macroize "mountopts" and "mountopts_verbose"! */
+ if (strncmp(ap-a_name, "mountopts", 9) != 0)
+ return (ENOENT);
+ if (strncmp(ap-a_name, "mountopts_verbose", 17) == 0)
+ verbose = 1;
+
+ sbuf_new(sb, NULL, 128, 0);
+ sbuf_printf(sb, "%s", nmp-nm_flag NFSMNT_NFSV3 ? "v3&quo
Re: Displaying options for current NFS mounts
Gerald Pfeifer [EMAIL PROTECTED] writes:
What I'd like to see is `mount -v' printing
vexpert:/files5 on /.amd_mnt/vexpert/files5 (nfs: v3, udp)
instead of
vexpert:/files5 on /.amd_mnt/vexpert/files5 (nfs)
^^^
This kind of information is incredibly useful for debugging, yet I
haven't found ANY way to obtain it, let alone such a natural one.
IIRC tcpdump can detect NFS3 vs. NFS2, but that's suboptimal.
Implementing the above functionality in mount(8) isn't actually that
hard. We would need to export the filesystem-specific fs_args
structures (e.g., nfs_args, ffs_args) to the userland. If we do that,
mount(8) will be able to display all kinds of interesting,
filesystem-specific stuff (e.g., NFS version and transport, whether a
mounted CDROM is using Joilet, etc.).
I tried to export this stuff in struct statfs, but ran into a problem:
I'd need the complete definitions of fs_args in sys/mount.h, but I
can't include, e.g., nfs/nfs.h because the latter includes the
former (sys/mount.h)!
The patch below kind of implements this functionality. I only export
nfs_args (not otherfs_args), and I only modified mount(8) to print
the NFS version, but printing the transport and others is simple from
there. To work around the above problem, I pasted the struct nfs_args
definition into mount.h. It is *horribly* ugly, but it does work.
If some other people display intrest in this, and someone can suggest
a less ugly way of getting the definitions of fs_args into mount.h
(the only other way I can think of is to just move all of them from
fs/fs.h to mount.h permamently), I'll implement this stuff in the
other filesystems.
Regards
Dima Dorfman
[EMAIL PROTECTED]
P.S. If you want to try the patch, you'll need to rebuild at least
the kernel, libc, mount, mountd, and amd, since the size of struct
statfs changes. I only did those, and it seems to work on my system.
Index: sys/sys/mount.h
===
RCS file: /st/src/FreeBSD/src/sys/sys/mount.h,v
retrieving revision 1.102
diff -u -r1.102 mount.h
--- sys/sys/mount.h 2001/03/01 20:59:59 1.102
+++ sys/sys/mount.h 2001/03/24 22:03:13
@@ -69,6 +69,44 @@
#defineMNAMELEN72 /* length of buffer for returned name */
#endif
+/* XXXDD: from src/sys/nfs/nfs.h! fixme! */
+/*
+ * Arguments to mount NFS
+ */
+#ifndef NFS_ARGS_DEFINED
+#define NFS_ARGS_DEFINED
+#define NFS_ARGSVERSION3 /* change when nfs_args changes */
+struct nfs_args {
+ int version;/* args structure version number */
+ struct sockaddr *addr; /* file server address */
+ int addrlen;/* length of address */
+ int sotype; /* Socket type */
+ int proto; /* and Protocol */
+ u_char *fh;/* File handle to be mounted */
+ int fhsize; /* Size, in bytes, of fh */
+ int flags; /* flags */
+ int wsize; /* write size in bytes */
+ int rsize; /* read size in bytes */
+ int readdirsize;/* readdir size in bytes */
+ int timeo; /* initial timeout in .1 secs */
+ int retrans;/* times to retry send */
+ int maxgrouplist; /* Max. size of group list */
+ int readahead; /* # of blocks to readahead */
+ int leaseterm; /* Term (sec) of lease */
+ int deadthresh; /* Retrans threshold */
+ char*hostname; /* server's name */
+ int acregmin; /* cache attrs for reg files min time */
+ int acregmax; /* cache attrs for reg files max time */
+ int acdirmin; /* cache attrs for dirs min time */
+ int acdirmax; /* cache attrs for dirs max time */
+};
+#endif /* !NFS_ARGS_DEFINED */
+
+/* filesystem-specific mount options */
+union mount_info {
+ struct nfs_args nfs;
+};
+
struct statfs {
longf_spare2; /* placeholder */
longf_bsize;/* fundamental file system block size */
@@ -92,6 +130,7 @@
charf_mntfromname[MNAMELEN];/* mounted filesystem */
short f_spares2; /* unused spare */
longf_spare[2]; /* unused spare */
+ union mount_info f_mtinfo; /* filesystem-specific mount info */
};
#ifdef _KERNEL
Index: sys/nfs/nfs.h
===
RCS file: /st/src/FreeBSD/src/sys/nfs/nfs.h,v
retrieving revision 1.57
diff -u -r1.57 nfs.h
--- sys
Minor (cosmetic) ps(1) fixes
Hello -hackers When the kinfo_proc structure was introduced, the ps(1) manual page was not updated. Thus, it still talks about keywords that don't exist. Also, one line in ps.c was forgotten. The latter results in an annoying warning when using ps(1) with the -j flag: dd@ref5% ps -j ps: sess: keyword not found [ normal ps(1) output follows ] Attached is a patch that fixes this bug, and updates the man page. Comments? If this is okay, could someone please commit at least the source part? Thanks Dima Dorfman [EMAIL PROTECTED] Index: ps.1 === RCS file: /st/src/FreeBSD/src/bin/ps/ps.1,v retrieving revision 1.30 diff -u -r1.30 ps.1 --- ps.12001/02/01 16:24:50 1.30 +++ ps.12001/03/20 03:34:55 @@ -99,7 +99,7 @@ header per page of information. .It Fl j Print information associated with the following keywords: -user, pid, ppid, pgid, sess, jobc, state, tt, time and command. +user, pid, ppid, pgid, jobc, state, tt, time and command. .It Fl L List the set of available keywords. .It Fl l @@ -367,8 +367,6 @@ job control count .It ktrace tracing flags -.It ktracep -tracing vnode .It lim memoryuse limit .It logname @@ -400,8 +398,6 @@ wait channel (as an address) .It oublk total blocks written (alias oublock) -.It p_ru -resource usage (valid only for zombie) .It paddr swap address .It pagein @@ -427,8 +423,6 @@ reverse link on run queue, or 0 .It rss resident set size -.It rsz -resident set size + (text size / text use count) (alias rssize) .It rtprio realtime priority (101 = not a realtime process) .It ruid @@ -436,8 +430,6 @@ .Tn ID .It ruser user name (from ruid) -.It sess -session pointer .It sig pending signals (alias pending) .It sigcatch Index: ps.c === RCS file: /st/src/FreeBSD/src/bin/ps/ps.c,v retrieving revision 1.36 diff -u -r1.36 ps.c --- ps.c2001/03/03 01:46:58 1.36 +++ ps.c2001/03/20 03:34:55 @@ -104,7 +104,7 @@ static uid_t *getuids(const char *, int *); char dfmt[] = "pid tt state time command"; -char jfmt[] = "user pid ppid pgid sess jobc state tt time command"; +char jfmt[] = "user pid ppid pgid jobc state tt time command"; char lfmt[] = "uid pid ppid cpu pri nice vsz rss wchan state tt time command"; char o1[] = "pid"; char o2[] = "tt state time command"; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sysctl_kern_proc doesn't handle the case when no procs match given criteria
Hello -hackers
The sysctl_kern_proc routine in kern_proc.c doesn't handle the case
when no processes match the given criteria. I.e., if no processes
match, it will return 0 even though it never called SYSCTL_OUT; thus,
the output data is junk. This can be demonstrated by giving ps(1)
arguments such that no processes match. In this example, the user
`nobody' isn't running anything:
dd@ref5% ps U nobody
ps: kinfo_proc size mismatch (expected 648, got -791621424)
Obviously, this isn't the desired mode of failure. Attached is a
patch that will make sysctl_kern_proc return ESRCH if it didn't find
any processes. AFAIK, without the patch, the only way to detect this
condition (no processes match search criteria) is to check that a call
into this routine via sysctl didn't modify whatever is pointed at by
the oldp pointer (see sysctl(3)).
Comments? Suggestions?
Thanks
Dima Dorfman
[EMAIL PROTECTED]
P.S. libkvm and/or ps(1) should probably be taught to check for this
condition and react more gently (on -stable, ps just prints the column
labels when this happens). I'll probably do this later.
Index: kern_proc.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/kern_proc.c,v
retrieving revision 1.89
diff -u -r1.89 kern_proc.c
--- kern_proc.c 2001/03/07 06:52:12 1.89
+++ kern_proc.c 2001/03/17 04:20:49
@@ -555,6 +555,7 @@
struct proc *p;
int doingzomb;
int error = 0;
+ int match = 0;
if (oidp-oid_number == KERN_PROC_PID) {
if (namelen != 1)
@@ -640,9 +641,12 @@
ALLPROC_LOCK(AP_RELEASE);
return (error);
}
+ match = 1;
}
}
ALLPROC_LOCK(AP_RELEASE);
+ if (!match)
+ return (ESRCH);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Patch to fix panic when detaching a mounted md device
Hello -hackers
Right now, if you try to detach an md device that's currently mounted,
you will get a panic (maybe not immedietely, but it will come, esp. if
you ever try to use that mountpoint again). I'm pretty sure this is a
known problem, with the solution--or workaround--being, "then don't do
that." The problem is, someone will invariably do it. The fix is to
make md complain if you try to detach a device that's currently
opened. Below is a patch that implements this by keeping track of the
number of times a device has been opened.
Comments?
Thanks
Dima Dorfman
[EMAIL PROTECTED]
Index: md.c
===
RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v
retrieving revision 1.26
diff -u -r1.26 md.c
--- md.c2001/03/09 20:06:30 1.26
+++ md.c2001/03/13 07:04:43
@@ -122,11 +122,12 @@
static d_strategy_t mdstrategy;
static d_open_t mdopen;
+static d_close_t mdclose;
static d_ioctl_t mdioctl, mdctlioctl;
static struct cdevsw md_cdevsw = {
/* open */ mdopen,
-/* close */ nullclose,
+/* close */ mdclose,
/* read */ physread,
/* write */ physwrite,
/* ioctl */ mdioctl,
@@ -169,6 +170,7 @@
unsigned nsect;
unsigned secsize;
unsigned flags;
+ unsigned opencnt;
/* MD_MALLOC related fields */
u_char **secp;
@@ -205,6 +207,18 @@
dl-d_secpercyl = dl-d_nsectors * dl-d_ntracks;
dl-d_secperunit = sc-nsect;
dl-d_ncylinders = dl-d_secperunit / dl-d_secpercyl;
+ sc-opencnt++;
+ return (0);
+}
+
+static int
+mdclose(dev_t dev, int flag, int fmt, struct proc *p)
+{
+ struct md_s *sc;
+
+ sc = dev-si_drv1;
+ KASSERT(sc-opencnt 0, ("md: closing an unopened device"));
+ sc-opencnt--;
return (0);
}
@@ -824,6 +838,8 @@
sc = mdfind(mdio-md_unit);
if (sc == NULL)
return (ENOENT);
+ if (sc-opencnt != 0)
+ return (EBUSY);
switch(sc-type) {
case MD_VNODE:
case MD_SWAP:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Inheriting the nodump flag
Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
dump's tree walker is a little weird, so the patch is a little more
complicated than calling fts_set with FTS_SKIP. For the technical
details of what it does, see:
http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
[.]
Comments?
Just that I noticed a typo in a comment where ``inherited'' is misspelt
``herited'' going via your URL but it's fixed in the attached
patch :-) It's probably worth updating the web page.
That page is the archive of the [EMAIL PROTECTED] mailing list, and
as such can't be changed (much less by me). I provided it because it
offers a very good technical explanation of the patch, which I didn't
want to repeat. I took the patch there almost verbatim, except for,
obviously, the exact placement of the code, and the comments; I didn't
take the latter because the person who wrote it isn't a natural
English speaker (as far as I can tell, anyway), and as such didn't
write such great comments ("such great" being a reference to the
English grammar and spelling, not their technical accuracy).
I'd certainly like to see this committed - I'm sick of backing up
release directories, cvs repositories and /usr/obj :-)
Yes, this was my motivation for porting this, too. :-)
Thanks
Dima Dorfman
[EMAIL PROTECTED]
P.S. I just sent this patch to -audit per request of rwatson.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Inheriting the nodump flag
Hello -hackers
Some time ago, on -arch, phk proposed that the nodump flag should be
inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000).
This was generally considered a good idea, however, the patch to the
kernel he proposed was thought an ugly hack. In addition, jeroen
pointed out that NetBSD had implemented this functionality the Right
Way(tm), in dump(8).
Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
dump's tree walker is a little weird, so the patch is a little more
complicated than calling fts_set with FTS_SKIP. For the technical
details of what it does, see:
http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
I've been using this on two of my hosts for a while, and it works as
expected. Given the additional fact that NetBSD has had this for
almost two years, and that the patch below looks very similar to the
one they applied, I doubt it significantly breaks anything.
Comments?
Thanks in advance
Dima Dorfman
[EMAIL PROTECTED]
Index: traverse.c
===
RCS file: /st/src/FreeBSD/src/sbin/dump/traverse.c,v
retrieving revision 1.11
diff -u -r1.11 traverse.c
--- traverse.c 2000/04/14 06:14:59 1.11
+++ traverse.c 2001/02/20 01:39:06
@@ -74,9 +74,11 @@
typedeflong fsizeT;
#endif
-static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size));
+static int dirindir __P((ino_t ino, daddr_t blkno, int level, long *size,
+long *tapesize, int nodump));
static void dmpindir __P((ino_t ino, daddr_t blk, int level, fsizeT *size));
-static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize));
+static int searchdir __P((ino_t ino, daddr_t blkno, long size, long filesize,
+long *tapesize, int nodump));
/*
* This is an estimation of the number of TP_BSIZE blocks in the file.
@@ -152,10 +154,14 @@
dp = getino(ino);
if ((mode = (dp-di_mode IFMT)) == 0)
continue;
- SETINO(ino, usedinomap);
+ /*
+* All dirs go in dumpdirmap; only inodes that are to
+* be dumped go in usedinomap and dumpinomap, however.
+*/
if (mode == IFDIR)
SETINO(ino, dumpdirmap);
if (WANTTODUMP(dp)) {
+ SETINO(ino, usedinomap);
SETINO(ino, dumpinomap);
if (mode != IFREG mode != IFDIR mode != IFLNK)
*tapesize += 1;
@@ -192,9 +198,10 @@
long *tapesize;
{
register struct dinode *dp;
- register int i, isdir;
+ register int i, isdir, nodump;
register char *map;
register ino_t ino;
+ struct dinode di;
long filesize;
int ret, change = 0;
@@ -204,24 +211,34 @@
isdir = *map++;
else
isdir = 1;
- if ((isdir 1) == 0 || TSTINO(ino, dumpinomap))
+ /*
+* If a directory has been removed from usedinomap, it
+* either has the nodump flag set, or has inherited
+* it. Although a directory can't be in dumpinomap if
+* it isn't in usedinomap, we have to go through it to
+* propogate the nodump flag.
+*/
+ nodump = (TSTINO(ino, usedinomap) == 0);
+ if ((isdir 1) == 0 || (TSTINO(ino, dumpinomap) !nodump))
continue;
dp = getino(ino);
- filesize = dp-di_size;
+ di = *dp; /* inode buf may change in searchdir(). */
+ filesize = di.di_size;
for (ret = 0, i = 0; filesize 0 i NDADDR; i++) {
- if (dp-di_db[i] != 0)
- ret |= searchdir(ino, dp-di_db[i],
+ if (di.di_db[i] != 0)
+ ret |= searchdir(ino, di.di_db[i],
(long)dblksize(sblock, dp, i),
- filesize);
+ filesize, tapesize, nodump);
if (ret HASDUMPEDFILE)
filesize = 0;
else
filesize -= sblock-fs_bsize;
}
for (i = 0; filesize 0 i NIADDR; i++) {
- if (dp-di_ib[i] == 0)
+ if (di.di_ib[i] == 0)
continue;
- ret |= dirindir(ino, dp-di_ib[i], i, filesize);
+ ret |= dirindir(ino, di.di_ib[i], i, filesize,
+ tapesize, nodump);
}
if (ret HAS
Re: Why does a named pipe (FIFO) give me my data twice ???
If the first program calls open(2) before the second one calls
close(2) the former will not block because there's already a writer on
the pipe. A possible workaround would be to unlink and recreate the
fifo in program one, like so:
for (;;)
{
int fifo;
mkfifo(fifo_path, fifo_mode);
fifo = open(fifo_path, O_RDONLY);
read(fifo, ...);
printf(...);
close(fifo);
unlink(fifo_path);
}
As for why this actually happens, I don't know. None of my Stevens
books explain this.
Hope this helps
Dima Dorfman
[EMAIL PROTECTED]
hello!
I've got a program that creates a named pipe, and then spawns a
thread
which sits in a loop:
// error checking snipped.
//
while (1) {
int fifo = open(fifoPath, O_RDONLY); // this blocks
fprintf(stderr, "somebody opened the other end!\n");
read(fifo, buf, sizeof(buf));
fprintf(stderr, "got the following data: %s\n", buf);
close(fifo);
}
i then have another instance of the same program do the following:
fifo = open(fifoPath, O_WRONLY);
write(fifo, buf, strlen(buf);
now, the problem is that the first process succeeds suddenly for
the
open, reads the data, closes the fifo, and IMMEDIATELY SUCCEEDS THE
open(2)
again, reading in the same data.
After that, all is as expected.
Note that this doesn't happen ALL the time -- only about 80% of the
time.
Any idea why this would happen?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Inheriting the nodump flag
1) This method of handling recursive nodump is far superior to any actual inheritence of the flag as part of file system operations, as currently no other file flags are inherited from the parent directory -- the only property that is inherited is the group. With ACLs, the parent's default ACL will also play a role in the new access ACL. In any case, there is no precedent for file flag inheritence. I'm not sure if this is supposed to be a confirmation, but, just to clear things up, the patch doesn't cause the nodump flag to be inherited in the filesystem per se. I.e., you won't see entire trees of files marked nodump that weren't marked before after running dump with this patch applied. It is inherited in terms of dump's internal maps; perhaps propagated would be a better word to describe its behavior. 2) Please run the patch by freebsd-audit -- there have been a fair number of vulnerabilities in the fts code in the past due to race conditions of various sorts, and it's important that any modifications be carefully scrutinized to prevent the reintroduction of vulnerabilites. dump doesn't use fts; I used calling fts_set as an example because in a program that uses fts, pruning a directory and everything under it is a matter of one library call. In dump's case, it's not that simple. Nevertheless (or should that be consequently?), your point is well taken. I will send this to -audit in a few days barring any objections here. Thanks again Dima Dorfman [EMAIL PROTECTED] However, the general idea sounds very useful, and something that I'd find applicable on a daily basis :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 26 Feb 2001, Dima Dorfman wrote: Hello -hackers Some time ago, on -arch, phk proposed that the nodump flag should be inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000). This was generally considered a good idea, however, the patch to the kernel he proposed was thought an ugly hack. In addition, jeroen pointed out that NetBSD had implemented this functionality the Right Way(tm), in dump(8). Attached below is a port of NetBSD's patch to FreeBSD's dump(8). dump's tree walker is a little weird, so the patch is a little more complicated than calling fts_set with FTS_SKIP. For the technical details of what it does, see: http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. I've been using this on two of my hosts for a while, and it works as expected. Given the additional fact that NetBSD has had this for almost two years, and that the patch below looks very similar to the one they applied, I doubt it significantly breaks anything. Comments? Thanks in advance Dima Dorfman [EMAIL PROTECTED] [ Patch snipped to conserve bandwidth of those who have to pay for it; it's available at http://www.unixfreak.org/~dima/home/nodump.diff or the mailing list archives if you're interested. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Listing configured md(4) devices
Hello phk and -hackers
With md(4)'s great autounit feature, it's becoming harder to keep
track of md(4) devices. Without autounit, you pretty much knew what
was what since you had to specify the unit number; with autounit,
things like `make release` configure an arbitrary unit without telling
you what it is, or even letting you change it (which isn't really
necessary).
jhb recently suggested that a way to get a list of active md(4)
devices and the way they were configured (size, type, etc.) would be a
nice remedy to the problem describe above (see "doFS.sh should obey
MDDEVICE if available" on -current a few weeks back).
I've come up with a relatively short patch to implement this. It adds
a new ioctl, MDIOCQUERY, to get information on a configured md(4)
device (it returns a filled in md_ioctl structure modulo md_file,
which, I think, can't be obtained without explicitly storing the path
during cofiguration (i.e., you can't derive a path from a vnode)), and
uses the 'kern.disks' sysctl to find out which devices are currently
configured. With it, `mdconfig -l` will list all devices and their
configurations, and `mdconfig -d -u x` will print information on the
device specified.
Comments? Suggestions?
Thanks
Dima Dorfman
[EMAIL PROTECTED]
Index: sys/dev/md/md.c
===
RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v
retrieving revision 1.23
diff -u -r1.23 md.c
--- sys/dev/md/md.c 2001/01/28 20:55:55 1.23
+++ sys/dev/md/md.c 2001/02/21 08:27:08
@@ -829,6 +829,30 @@
default:
return (EOPNOTSUPP);
}
+ case MDIOCQUERY:
+ sc = mdfind(mdio-md_unit);
+ if (sc == NULL)
+ return (ENOENT);
+ mdio-md_type = sc-type;
+ mdio-md_options = sc-flags;
+ switch (sc-type) {
+ case MD_MALLOC:
+ mdio-md_size = sc-nsect;
+ break;
+ case MD_PRELOAD:
+ mdio-md_size = sc-nsect;
+ (u_char *)(uintptr_t)mdio-md_base = sc-pl_ptr;
+ break;
+ case MD_SWAP:
+ mdio-md_size = sc-nsect * (PAGE_SIZE / DEV_BSIZE);
+ break;
+ case MD_VNODE:
+ mdio-md_size = sc-nsect;
+ /* XXX fill this in */
+ mdio-md_file = NULL;
+ break;
+ }
+ return (0);
default:
return (ENOIOCTL);
};
Index: sys/sys/mdioctl.h
===
RCS file: /st/src/FreeBSD/src/sys/sys/mdioctl.h,v
retrieving revision 1.7
diff -u -r1.7 mdioctl.h
--- sys/sys/mdioctl.h 2001/01/01 23:08:26 1.7
+++ sys/sys/mdioctl.h 2001/02/21 08:27:08
@@ -75,6 +75,7 @@
#define MDIOCATTACH_IOWR('m', 0, struct md_ioctl) /* attach disk */
#define MDIOCDETACH_IOWR('m', 1, struct md_ioctl) /* detach disk */
+#define MDIOCQUERY _IOWR('m', 2, struct md_ioctl) /* query status */
#define MD_CLUSTER 0x01/* Don't cluster */
#define MD_RESERVE 0x02/* Pre-reserve swap */
Index: sbin/mdconfig/mdconfig.c
===
RCS file: /st/src/FreeBSD/src/sbin/mdconfig/mdconfig.c,v
retrieving revision 1.6
diff -u -r1.6 mdconfig.c
--- sbin/mdconfig/mdconfig.c2001/01/31 08:41:18 1.6
+++ sbin/mdconfig/mdconfig.c2001/02/21 08:27:08
@@ -19,7 +19,12 @@
#include sys/ioctl.h
#include sys/param.h
#include sys/mdioctl.h
+#include sys/sysctl.h
+int intcmp(const void *, const void *);
+int list(void);
+int query(const int);
+
struct md_ioctl mdio;
enum {UNSET, ATTACH, DETACH} action = UNSET;
@@ -30,6 +35,7 @@
fprintf(stderr, "Usage:\n");
fprintf(stderr, "\tmdconfig -a -t type [-o [no]option]... [ -f file] [-s size]
[-u unit]\n");
fprintf(stderr, "\tmdconfig -d -u unit\n");
+ fprintf(stderr, "\tmdconfig -l [-u unit]\n");
fprintf(stderr, "\t\ttype = {malloc, preload, vnode, swap}\n");
fprintf(stderr, "\t\toption = {cluster, compress, reserve, autounit}\n");
fprintf(stderr, "\t\tsize = %%d (512 byte blocks), %%dk (kB), %%dm (MB) or
%%dg (GB)\n");
@@ -41,10 +47,10 @@
{
int ch, fd, i;
char *p;
- int cmdline = 0;
+ int cmdline = 0, haveunit = 0;
for (;;) {
- ch = getopt(argc, argv, "ab:df:o:s:t:u:");
+ ch = getopt(argc, argv, "ab:df:lo:s:t:u:");
if (ch == -1)
break;
switch (ch) {
@@ -86,6 +92,11 @@
Re: Listing configured md(4) devices
2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that
it would also match any other device name that might begin with md, which
potentially might not be provided by the md driver. This is currently (I
suspect) hypothetical as we don't have any other drivers beginning with
md, but it would be nice not to preclude that in the future. Restricting
all possible disk device names to two letters, of which the second is
always d, is not a scalable approach. That said, writing an easy matching
function without that assumption probably isn't all that easy, either.
Assuming that a device name must consist of letters (which I suspect
is the case), it's fairly trivial; just check that what follows 'md'
is a number.
Here's a patch against what I sent in previously to do that. The
original with this included can be found at
http://www.unixfreak.org/~dima/home/md-list3.diff.
Thanks again
Dima Dorfman
[EMAIL PROTECTED]
--- mdconfig.c.o2 Thu Feb 21 05:27:00 2001
+++ mdconfig.c Thu Feb 22 16:32:34 2001
@@ -195,7 +195,7 @@
int
list(void)
{
- char *disklist, *p, *p2;
+ char *disklist, *p, *p2, *p3;
int dll;/* disklist length */
int mds[512], *mdsp, mdsc, i;
@@ -211,7 +211,9 @@
if (strncmp(p2, "md", 2) != 0)
continue;
p2 += 2;
- *mdsp = strtoul(p2, NULL, 10);
+ *mdsp = strtoul(p2, p3, 10);
+ if (p2 == p3)
+ continue;
mdsc++;
if (++mdsp = mds[sizeof(mds)])
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: An example script for creating a bootable floppy
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ans i -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/kern_sig.c ../../kern/kern_sig.c:359: warning: function declaration isn't a prototype ../../kern/kern_sig.c: In function `osigaction': ../../kern/kern_sig.c:367: dereferencing pointer to incomplete type Wild guess: try sticking ``options COMPAT_43'' in the config file. This smells of missing 4.3BSD compatibility structures or something. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An example script for creating a bootable floppy
[ dropping -doc ] On 3 Feb 2001, at 18:02, Dima Dorfman wrote: Wild guess: try sticking ``options COMPAT_43'' in the config file. This smells of missing 4.3BSD compatibility structures or something. That got me quite a bit further. Any ideas about this one please? It's the keyboard isn't it? From LINT, I added these: That would be it. cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat- extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL - include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking kernel scvidctl.o: In function `sc_set_text_mode': scvidctl.o(.text+0x19): undefined reference to `vidsw' After a brief inspection of the code, I think adding a 'vga' device will help: device vga0at isa? Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mount_md (was: mdconfig config file (was: cvs commit: src/sys/i386/conf GENERIC))
[ cvs-(all|commiters) -- -hackers ] :snip : : (this whole thing is predicated on someone writing a mount_md wrapper : for MD that mimics the options mount_mfs accepts, for compatibility). : :I'll do it. Would it be safe to assume that it's acceptable to write :a C program to parse the arguments, build command lines to :appropriately invoke disklabel, newfs, maybe tunefs, and mount, then :call system(3) to execute them? : : Dima Dorfman : [EMAIL PROTECTED] Yes, though preferably I'd fork/exec the sub-programs (and use absolute paths) rather then use system(), because the mount program will be running during booting and its important to have it use as few system resources as possible in case the system is screwed up. We don't want it exec'ing /bin/sh. Point taken. I kind of figured system() was a little evil; that's why I asked. I've written the majority of the code. You can find it at: http://www.unixfreak.org/~dima/home/mount_md.c. It is mostly functional. It accepts just about all of the arguments that mount_mfs does, plus a few others. It has the ability to create vnode, swap, and malloc -backed disks. It's not terribly well-documented (I'll write up a man page if it's decided that this is acceptable), but most of the options are easily explained by looking at a few lines of code. Some thoughts: - If you want softupdates, you need to specify the -S flag. Should softupdates be the default? - To suppress the output of disklabel/newfs/etc., it closes fds 0-2. Is this evil? Should I devise another method of doing this (something like opening /dev/null and dup2'ing that fd to 0-2)? - Should there be an option to make use of md's autounit feature? I don't think it will be very hard to implement, but I don't know how useful it would be. I think that's it. Comments? Suggestions? Thanks in advance Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mdconfig config file (was: cvs commit: src/sys/i386/conf GENERIC)
[cvs-(all|commiters) - -hackers] If anybody writes a patch to mdconfig to DTRT based on some less bogus /etc/fstab entries, I'll happily review and commit it. Does this sort of functionality really belong in mdconfig? Not by definition, and I'm not religious about it. Okay, any objections then to jhb's configuration file idea? The idea is that mdconfig parses a file (md.conf or something) and sets up some memory disks accordingly, including optional disklabel/newfs stuff. Later, a simple 'ffs'-type fstab entry will mount it wherever the user wants. This may be a little complicated for the simple /tmp case, but I can think of some environments where this would be useful. vnconfig also supports a similar config file option, so I think it's fitting that mdconfig should, too. I've come up with a preliminary patch to teach mdconfig(8) to parse a config file. It's a little early to be of practical use (and it lacks the disklabel/newfs option), but it's a start. It's a little long because I made some of the code in the switch(ch) block into functions to avoid having two blocks doing the same thing, so I've decided not to attach it not to bother the uninterested parties. If you could take a minute or two and comment on it I'd appreciate it. You can find it at http://www.unixfreak.org/~dima/mdconfig1.diff The current format of the config file is: unit type argument=value,arg=value,... for example: md0 swapsize=64m Comments? Suggestions? Thanks in advance Dima Dorfman [EMAIL PROTECTED] P.S. Is there any reason the -b (baseaddr) option for preload disks is currently unimplemented? The patch implements it (it was one line, so I thought 'what the heck'); the ioctl works, but I was unable to test it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix make buildkernel requires full obj directory mistake
Like lots of people who use FreeBSD rather than tinker with it,
I have never done "make any-kind-of-world" and never expect to.
I create a kernel config with my stuff in it, and do config,
make, make install. I trust this is not going to be broken?
This is not broken, and will not be broken. Lots of people will
scream if it is, myself included (this was discussed when buildkernel
was first introduced, and the consensus was that the "old way"
should/will always work). This thread is about not teaching two ways
(buildkernel and make make install) to new users who, as you
described yourself, have never done make any-kind-of-world, and only
want to build a kernel for whatever reason (hardware not in GENERIC,
memory footprint, etc.).
In other, shorter, words: both ways will work, we just don't want to
confuse new users with two ways to achieve the same task.
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: startx /dev/mem problem
Fatal server error: xf86OpenConsole: Server must be suid root As it says, the server must be run setuid to root. Old versions of XFree86 (3.x.y) installed all servers setuid to root by default. This is a security hazard. XFree86 4.0.x do not install them setuid to root. You either need to use xdm (or a compatible login manager), or run the server setuid to root. If you choose the latter, you may find the Xwrapper port (/usr/ports/x11/wrapper) may be of some assistance. It allows you not to have every server setuid to root, only itsself, which will run the appropriate server (in short). Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix make buildkernel requires full obj directory mistake
The other reason to encourage it strongly is that there are too many
binary incompatibilities with the kernel interface for some programs,
even in -stable, so we'd want to encourage people to build and install
both at the same time. I'd imagine that the same sort of argument
would apply for picobsd since you don't want that to be cross
threaded. :-). But maybe I'm being overly paranoid here. Maybe I've
answered one too many questions that boil down to "just rebuild the
world and stop arguing with me, things will start to work".
While this is all true, I believe the intention of the patch was to
make it possible to do a buildkernel even if you aren't upgrading
(i.e., you're running the same version of the kernel that you're
trying to build). In some cases, such as fresh installs, people don't
want to have to do a buildworld to configure and install a custom
kernel.
Of course, there's always the "old way" (config make depend, etc.)
of doing this, but it seems that most people agree that recommending
two different ways of doing one task depending on the environment adds
unnecessary confusion for newcomers (e.g., "use buildkernel if you're
doing an upgrade, but config if you're not, but if you upgrade later
you still need buildkernel", etc. is more confusing than, "use
buildkernel"). This thread and patch originated as a response to a
thread on -doc (I think) where this was discussed. See the current
archives if you're interested, you can't miss it.
Personally, I think that if there's no technical reason why
buildkernel can't work without a prior buildworld assuming that the
kernel you're building is of the same version that's currently
running, trying to explain two different methods to new users should
be avoided.
Thanks
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
Recommendation:
A number of the executables located in /sbin and /usr/sbin are
never going to be invoked for any legitimate use by anyone other
than the superuser. In particular, servers such as portmap and
inetd run by non-root users are unlikely to do what was intended.
It seems a prudent measure to simply not set execute permission
by "other" on such programs during the install, giving the user
a handy "Permission denied" message when such an attempt is made.
Since these files don't run with any extra privileges (i.e., they're
not setuid or setgid), nothing stops a user from uploading their own
copy and running it. Your proposal doesn't actually improve security;
it just annoys the attacker. Whether this is a good thing or a waste
of time is a matter of opinion; personally, I'm in the latter boat
(i.e., I see no reason to do this).
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 10:11, Mark Murray wrote: [use flock(2)] But what part of the solution does flock solve? It solves the problem of finding out whether the Perl script is already running, but as I understood the original posting, this isn't what you were asking. See below. I'm not sure if my lack of comprehension stems from my initial description being inadequete or my knowledge being too narrow. Probably from it being a little confusing. Here's how I understand it. You have some program putting files in directory /x. You need something that will be notified when a new file appears in /x. That something then starts a Perl script to process the files. If you control the program that's putting files into /x, the easiest way would be to have it send a signal to your daemon. You can put its PID in a well-known file for it to look at. If, however, you don't control the program, you may have to resort to looking at the directory every now and then and checking for new files (``polling''). Depending on your application, this may or may not be acceptable. If you don't want to use polling, you might try fooling around with the select(2), poll(2), or kqueue(2) interfaces. The former two were designed to be used with regular files or sockets, but in unix, a directory is just a special type of file. I don't know how they'd react to it. In particular, the EVFILT_VNODE filter with the NOTE_EXTEND event/flag (notifies you when the file descriptor specified was extended) looks promising. Then again, I'm not a filesystem whiz, so this may all be nonsense. Hopefully I've at least interpreted your question correctly. Regards Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bugfixes, security fixes, versions
The whole "Stable Branch" thread on -security gave me an idea that's been perculating for some time. Problem: We have security problems in (say) -STABLE. They get fixed. We post an advisory about it, giving correction dates for -STABLE and -CURRENT, and the associated cutoff in which releases are fixed and which are not. However, tracking dates on buildworlds etc is hard. I'm sure I'm not the only one who usually does build/installworlds on source at least a week old. I check it it, built it, and if it's clean, wait to see if anyone else has any problems with it. And since I tend to put off building the kernel until I install, the date uname gives isn't necessarily useful for checking this sort of stuff. Idea: In the version string (or maybe somewhere else convenient), start adding codes at each -RELEASE along a branch. So, say we find a bug in fingerd. It's in 4.1-RELEASE, fixed in 4.1-STABLE at some point, and fixed in 4.2-RELEASE. We could add an 'a' to the version string in -STABLE, so it will read out as "4.1-STABLE a". Find another bug and fix it, we have "4.1-STABLE b". Presumably, this would only apply to such things as Why not just use a date? I do this on most of my systems. My `uname -r` reads: 4.1-2916-STABLE I started doing this for the exact same reason you described above--to know when I updated the system. It does clutter the `uname -a` output a bit, so it could be done similar to the way you suggested with the flag: "4.1-STABLE 2916". Just a thought. Regards -- Dima Dorfman [EMAIL PROTECTED] Finger [EMAIL PROTECTED] for my public PGP key. It's kind of fun to do the impossible. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bugfixes, security fixes, versions
On Sun, Oct 08, 2000 at 12:53:16AM -0700, a little birdie told me that Dima Dorfman remarked Why not just use a date? I do this on most of my systems. My `uname -r` reads: 4.1-2916-STABLE I started doing this for the exact same reason you described above--to know when I updated the system. It does clutter the `uname -a` output a bit, so it could be done similar to the way you suggested with the flag: "4.1-STABLE 2916". Just a thought. And a good way of doing it too, if we were already. My thought was 'as long as we're changing it already, might as well make it foolproof'. With a date, you still have a little uncertainty because of lags between CVSup servers, what time of the day the fix was committed, That's true. I wasn't concerned with that because I know that I have cvsup set up to always run at 01:00 local time, and the most it can deviate from that is by ten or twenty minutes if the cvsup server is busy. etc. It's maybe 90% sure, but you just *KNOW* someone is gonna try to sue us or raise holy hell over that 10% when it happens to them. With tags per-fix in the version, we're pretty much 100% certain that the fix is or isn't in that specific system, outside of people muddying things Again, you're right. Now it just needs to be decided when these tags should be advanced (for example, what is a showstopper bug for one environment may be irrelevant to another), and get somebody to implement it. The technical part of putting it in shouldn't be so hard (I'm willing to help work on that), but getting commiters to start using them may be somewhat difficult. -- Dima Dorfman [EMAIL PROTECTED] Finger [EMAIL PROTECTED] for my public PGP key. I've used up all my sick days so I'm calling in dead! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
icmp raw sockets
hi, i was reading some of the mailing list archives to get an answer to 'why dont icmp echo requests get passed to the raw sockets', and now that i have the answer i was wondering... is there a way to tell the kernel NOT to process echo/timestamp/mask requests and instead pass those to the raw sockets? i'm looking for a solution that doesnt involve kernel modifications. thanks in advance, --dima -- Dima Dorfman /-\ | irc: eclipze@efnet/dalnet | whois: DD10140@internic | | email: [EMAIL PROTECTED] | http: www.unixfreak.org | \-/ finger [EMAIL PROTECTED] for public PGP key Windoze droolz. FreeBSD rulez. http://www.FreeBSD.org/ BeOS - develop on me... wait, what c compiler? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
icmp raw sockets
hi, i was reading some of the mailing list archives to get an answer to 'why dont icmp echo requests get passed to the raw sockets', and now that i have the answer i was wondering... is there a way to tell the kernel NOT to process echo/timestamp/mask requests and instead pass those to the raw sockets? i'm looking for a solution that doesnt involve kernel modifications. thanks in advance, --dima -- Dima Dorfman /-\ | irc: ecli...@efnet/dalnet | whois: dd10...@internic | | email: d...@unixfreak.org | http: www.unixfreak.org | \-/ finger di...@unixfreak.org for public PGP key Windoze droolz. FreeBSD rulez. http://www.FreeBSD.org/ BeOS - develop on me... wait, what c compiler? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
