Re: Human readable df
Here's a slightly better patch. It tries harder to fill up the 5
digit field with as many sig figs as possible (always up to 3). It
uses better constants for things than the magic numbers of the first
patch. I've not tried to patch the man page yet. Also patched where
the gross use of "BKMGTP"[unit], the disorder in the prototypes. I
also fixed it so that disk larger then 1000Pbytes are displayed in
petabytes rather than bytes like the old code.
I think this looks a little better than the orignial patch singe it
now gives the same resolution of data for each file system.
I experimented with setting the throttle from 1000.00 the previous
unit to 2000.00 the previous unit to give it a more multi-meter look
and to give higher resolution around 1 which would give you a more
linear amount of data (taken as the log of the rounding error), but
that didn't look as good, so I left it on the cutting room floor.
I also experimented with a format that looked like
/dev/da0s1e 192.M 167.M 9.22M95% /usr
but that too didn't look good to my eye, even though it was more
pedantically correct from a sigfig point of view (since 200M means
there is one sig fig, while 200.M means two, at least in the sig fig
system I learned in high school).
Here's the output
FilesystemSize UsedAvail Capacity Mounted on
/dev/da0s1a 62.0M 31.0M 26.1M54% /
/dev/da0s1e 192M 167M 9.22M95% /usr
/dev/da0s1d 61.4M 11.3M 45.2M20% /var
/dev/da0s1f 288M 247M 18.4M93% /usr/local
/dev/da0s1g 2.17G 1.88G 122M94% /home
procfs 4.00K 4.00K 0B 100% /proc
/dev/sd1a 990M 376M 534M41% /jaz
/dev/da2s4c 1.94G 1.72G 68.0M96% /hawk
/dev/da3s4a 3.93G 1.95G 1.67G54% /u
Warner
P.S. I thought of doing a -H as well that used real SI units rather
than the traditional CS si-ish units, but thought better of it. I
also didn't use the new ki, Mi, et al either since that would just
make the display look wrong to my eye (I was also unsure of their
exact spelling :-).
Index: df.c
===
RCS file: /home/imp/FreeBSD/CVS/src/bin/df/df.c,v
retrieving revision 1.22
diff -u -r1.22 df.c
--- df.c1999/11/01 04:57:43 1.22
+++ df.c1999/11/30 07:19:07
@@ -59,21 +59,28 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-int checkvfsname __P((const char *, char **));
-char **makevfslist __P((char *));
-long regetmntinfo __P((struct statfs **, long, char **));
+typedef enum { NONE = 0, KILO, MEGA, GIGA, TERA, PETA /* , EXA */ } unit_t;
+const char *unit_string = "BKMGTP";
+
int bread __P((off_t, void *, int));
+int checkvfsname __P((const char *, char **));
char*getmntpt __P((char *));
+char **makevfslist __P((char *));
+void prthuman __P((struct statfs *, long));
+void prthumanval __P((double));
void prtstat __P((struct statfs *, int));
+long regetmntinfo __P((struct statfs **, long, char **));
int ufs_df __P((char *, int));
+unit_t unit_adjust __P((double *));
void usage __P((void));
-intaflag = 0, iflag, nflag;
+intaflag = 0, iflag, nflag, hflag;
struct ufs_args mdev;
int
@@ -88,11 +95,14 @@
char *mntpt, *mntpath, **vfslist;
vfslist = NULL;
- while ((ch = getopt(argc, argv, "aiknt:")) != -1)
+ while ((ch = getopt(argc, argv, "ahiknt:")) != -1)
switch (ch) {
case 'a':
aflag = 1;
break;
+ case 'h':
+ hflag = 1;
+ break;
case 'i':
iflag = 1;
break;
@@ -272,20 +282,26 @@
if (maxwidth < 11)
maxwidth = 11;
if (++timesthrough == 1) {
- header = getbsize(&headerlen, &blocksize);
- (void)printf("%-*.*s %s UsedAvail Capacity",
+ if(hflag)
+ header = " Size";
+ else
+ header = getbsize(&headerlen, &blocksize);
+ (void)printf("%-*.*s %s UsedAvail Capacity",
maxwidth, maxwidth, "Filesystem", header);
if (iflag)
(void)printf(" iused ifree %%iused");
- (void)printf(" Mounted on\n");
+ (void)printf(" Mounted on\n");
}
(void)printf("%-*.*s", maxwidth, maxwidth, sfsp->f_mntfromname);
used = sfsp->f_blocks - sfsp->f_bfree;
availblks = sfsp->f_bavail + used;
- (void)printf(" %*ld %8ld %8ld", headerlen,
- fsbtoblk(sfsp->f_blocks, sfsp->f_bsize, blocksize),
- fsbtoblk(used, sfsp->f_bsize, blocksize),
- fsbtoblk(sfsp->f_bavail, sfsp->f_bsize, blocksize));
+ if(hflag)
+ prthuman(sfsp, used);
+ else
Re: Human readable df
In message <[EMAIL PROTECTED]> Warner Losh writes: : It also appears that this patch ignores blocksize, but maybe that's : something that I've missed somehow... Never mind this comment. It was my mistake. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
In message <19991129230436.A6501@badmofo> [EMAIL PROTECTED] writes: : [badmofo@/home/matt] df -h : FilesystemSize UsedAvail Capacity Mounted on : /dev/wd0s1a 722M20M 644M 3% / : /dev/wd0s2h 9.9G 4.4G 4.8G48% /usr : procfs4.0K 4.0K 0B 100% /proc Note, this uses the "traditional computer science SI extention" units. Where M == 1 << 20, G == 1 << 30, etc. Disk drive manufacturers use the real SI units where M == 10 ^ 6, G == 10 ^ 9, etc. There are new Si units for the old traditional CS SI units, but I don't like them :-) It also appears that this patch ignores blocksize, but maybe that's something that I've missed somehow... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
On Mon, 29 Nov 1999 [EMAIL PROTECTED] wrote: > Not sure if -hackers is the place for this, but here goes. > > Here's a patch to add -h flag to df to produce human readable > output. This makes it easier to read if the disk is big. You should submit this as a PR so it doesn't fall through the cracks (although it looks like Chris might take care of it, he seems to like adding options to commands :-) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
On Mon, Nov 29, 1999 at 09:39:53PM -0800, Chris Piazza wrote:
Oops, plus the usage change which I forgot (of course).
@@ -382,6 +463,6 @@
usage()
{
(void)fprintf(stderr,
- "usage: df [-aikn] [-t type] [file | filesystem ...]\n");
+ "usage: df [-ahikn] [-t type] [file | filesystem ...]\n");
exit(1);
}
-Chris
--
[EMAIL PROTECTED] [EMAIL PROTECTED]
Abbotsford, BC, Canada
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
On Mon, Nov 29, 1999 at 11:04:36PM -0500, [EMAIL PROTECTED] wrote:
> Not sure if -hackers is the place for this, but here goes.
>
> Here's a patch to add -h flag to df to produce human readable
> output. This makes it easier to read if the disk is big.
> Example:
>
> [badmofo@/home/matt] df -h
> FilesystemSize UsedAvail Capacity Mounted on
> /dev/wd0s1a 722M20M 644M 3% /
> /dev/wd0s2h 9.9G 4.4G 4.8G48% /usr
> procfs4.0K 4.0K 0B 100% /proc
>
>
> Code merged from OpenBSD and added to FreeBSD-STABLE.
[patch snipped]
For what it's worth, I'd ported this a few months back (file dated
Aug 28), but forgot about it :-). Here's the patch updated for
-current, anyway.
Index: df.1
===
RCS file: /home/ncvs/src/bin/df/df.1,v
retrieving revision 1.17
diff -u -r1.17 df.1
--- df.11999/11/01 04:57:42 1.17
+++ df.11999/11/30 05:38:47
@@ -40,7 +40,7 @@
.Nd display free disk space
.Sh SYNOPSIS
.Nm df
-.Op Fl aikn
+.Op Fl ahikmn
.Op Fl t Ar type
.Op Ar file | Ar filesystem ...
.Sh DESCRIPTION
@@ -62,6 +62,10 @@
.It Fl a
Show all mount points, including those that were mounted with the MNT_IGNORE
flag.
+.It Fl h
+"Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte,
+Gigabyte, Terabyte, Petabyte, Exabyte in order to reduce the number of
+digits to four or less.
.It Fl i
Include statistics on the number of free inodes.
.It Fl k
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.22
diff -u -r1.22 df.c
--- df.c1999/11/01 04:57:43 1.22
+++ df.c1999/11/30 05:38:47
@@ -59,21 +59,27 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+typedef enum { NONE = 0, KILO, MEGA, GIGA, TERA, PETA /* , EXA */ } unit_t;
+
int checkvfsname __P((const char *, char **));
char **makevfslist __P((char *));
long regetmntinfo __P((struct statfs **, long, char **));
int bread __P((off_t, void *, int));
char*getmntpt __P((char *));
+void prthuman __P((struct statfs *, long));
+void prthumanval __P((double));
void prtstat __P((struct statfs *, int));
int ufs_df __P((char *, int));
+unit_t unit_adjust __P((double *));
void usage __P((void));
-intaflag = 0, iflag, nflag;
+intaflag = 0, hflag, iflag, nflag;
struct ufs_args mdev;
int
@@ -88,11 +94,14 @@
char *mntpt, *mntpath, **vfslist;
vfslist = NULL;
- while ((ch = getopt(argc, argv, "aiknt:")) != -1)
+ while ((ch = getopt(argc, argv, "ahiknt:")) != -1)
switch (ch) {
case 'a':
aflag = 1;
break;
+ case 'h':
+ hflag = 1;
+ break;
case 'i':
iflag = 1;
break;
@@ -249,6 +258,68 @@
}
/*
+ * Output in "human-readable" format. Uses 3 digits max and puts
+ * unit suffixes at the end. Makes output compact and easy to read,
+ * especially on huge disks.
+ *
+ */
+
+unit_t
+unit_adjust(val)
+ double *val;
+{
+ double abval;
+ unit_t unit;
+
+ abval = fabs(*val);
+ if (abval < 1024)
+ unit = NONE;
+ else if (abval < 1048576ULL) {
+ unit = KILO;
+ *val /= 1024;
+ } else if (abval < 1073741824ULL) {
+ unit = MEGA;
+ *val /= 1048576;
+ } else if (abval < 1099511627776ULL) {
+ unit = GIGA;
+ *val /= 1073741824ULL;
+ } else if (abval < 1125899906842624ULL) {
+ unit = TERA;
+ *val /= 1099511627776ULL;
+ } else if (abval < 1152921504606846976ULL) {
+ unit = PETA;
+ *val /= 1125899906842624ULL;
+ }
+ return (unit);
+}
+
+void
+prthuman(sfsp, used)
+ struct statfs *sfsp;
+ long used;
+{
+ prthumanval((double)(sfsp->f_blocks) * (double)(sfsp->f_bsize));
+ prthumanval((double)(used) * (double)(sfsp->f_bsize));
+ prthumanval((double)(sfsp->f_bavail) * (double)(sfsp->f_bsize));
+}
+
+void
+prthumanval(bytes)
+ double bytes;
+{
+ unit_t unit;
+
+ unit = unit_adjust(&bytes);
+
+ if (bytes == 0)
+ (void)printf(" 0B");
+ else if (bytes > 10)
+ (void)printf(" %5.0f%c", bytes, "BKMGTPE"[unit]);
+ else
+ (void)printf(" %5.1f%c", bytes, "BKMGTPE"[unit]);
+}
+
+/*
* Convert statfs returned filesystem size into BLOCKSIZE units.
* Attempts to avoid overflow for large filesystems.
*/
@@ -272,9 +343,16 @@
if (maxwidth < 11)
maxwidth = 11;
if (++timesthrough == 1) {
- header = getbsize(&headerlen, &blocksize);
- (void)p
Human readable df
Not sure if -hackers is the place for this, but here goes.
Here's a patch to add -h flag to df to produce human readable
output. This makes it easier to read if the disk is big.
Example:
[badmofo@/home/matt] df -h
FilesystemSize UsedAvail Capacity Mounted on
/dev/wd0s1a 722M20M 644M 3% /
/dev/wd0s2h 9.9G 4.4G 4.8G48% /usr
procfs4.0K 4.0K 0B 100% /proc
Code merged from OpenBSD and added to FreeBSD-STABLE.
[badmofo@/usr/src/bin/df] diff -u df df~
diff -u df/df.1 df~/df.1
--- df/df.1 Sun Aug 29 10:12:14 1999
+++ df~/df.1Mon Nov 29 22:57:01 1999
@@ -40,7 +40,7 @@
.Nd display free disk space
.Sh SYNOPSIS
.Nm df
-.Op Fl ikn
+.Op Fl hikn
.Op Fl t Ar type
.Op Ar file | Ar filesystem ...
.Sh DESCRIPTION
@@ -59,6 +59,10 @@
.Pp
The following options are available:
.Bl -tag -width Ds
+.It Fl h
+"Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte,
+Gigabyte, Terabyte, Petabyte, Exabyte in order to reduce the number of
+digits to four or less.
.It Fl i
Include statistics on the number of free inodes.
.It Fl k
diff -u df/df.c df~/df.c
--- df/df.c Sun Aug 29 10:12:15 1999
+++ df~/df.cMon Nov 29 22:57:01 1999
@@ -59,11 +59,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+typedef enum { NONE = 0, KILO, MEGA, GIGA, TERA, PETA /* , EXA */ } unit_t;
+
int checkvfsname __P((const char *, char **));
char **makevfslist __P((char *));
long regetmntinfo __P((struct statfs **, long, char **));
@@ -71,9 +74,12 @@
char*getmntpt __P((char *));
void prtstat __P((struct statfs *, int));
int ufs_df __P((char *, int));
+unit_t unit_adjust __P((double *));
+void prthumanval __P((double));
+void prthuman __P((struct statfs *, long));
void usage __P((void));
-intiflag, nflag;
+intiflag, nflag, hflag;
struct ufs_args mdev;
int
@@ -88,8 +94,11 @@
char *mntpt, *mntpath, **vfslist;
vfslist = NULL;
- while ((ch = getopt(argc, argv, "iknt:")) != -1)
+ while ((ch = getopt(argc, argv, "hiknt:")) != -1)
switch (ch) {
+ case 'h':
+ hflag = 1;
+ break;
case 'i':
iflag = 1;
break;
@@ -267,20 +276,26 @@
if (maxwidth < 11)
maxwidth = 11;
if (++timesthrough == 1) {
- header = getbsize(&headerlen, &blocksize);
- (void)printf("%-*.*s %s UsedAvail Capacity",
+ if(hflag)
+ header = " Size";
+ else
+ header = getbsize(&headerlen, &blocksize);
+ (void)printf("%-*.*s %s UsedAvail Capacity",
maxwidth, maxwidth, "Filesystem", header);
if (iflag)
(void)printf(" iused ifree %%iused");
- (void)printf(" Mounted on\n");
+ (void)printf(" Mounted on\n");
}
(void)printf("%-*.*s", maxwidth, maxwidth, sfsp->f_mntfromname);
used = sfsp->f_blocks - sfsp->f_bfree;
availblks = sfsp->f_bavail + used;
- (void)printf(" %*ld %8ld %8ld", headerlen,
- fsbtoblk(sfsp->f_blocks, sfsp->f_bsize, blocksize),
- fsbtoblk(used, sfsp->f_bsize, blocksize),
- fsbtoblk(sfsp->f_bavail, sfsp->f_bsize, blocksize));
+ if(hflag)
+ prthuman(sfsp, used);
+ else
+ (void)printf(" %*ld %8ld %8ld", headerlen,
+fsbtoblk(sfsp->f_blocks, sfsp->f_bsize, blocksize),
+fsbtoblk(used, sfsp->f_bsize, blocksize),
+fsbtoblk(sfsp->f_bavail, sfsp->f_bsize, blocksize));
(void)printf(" %5.0f%%",
availblks == 0 ? 100.0 : (double)used / (double)availblks * 100.0);
if (iflag) {
@@ -290,7 +305,67 @@
inodes == 0 ? 100.0 : (double)used / (double)inodes * 100.0);
} else
(void)printf(" ");
- (void)printf(" %s\n", sfsp->f_mntonname);
+ (void)printf(" %s\n", sfsp->f_mntonname);
+}
+
+/*
+ * "human-readable" output: use 3 digits max.--put unit suffixes at
+ * the end. Makes output compact and easy-to-read esp. on huge disks.
+ */
+
+unit_t
+unit_adjust(val)
+ double *val;
+{
+ double abval;
+ unit_t unit;
+
+ abval = fabs(*val);
+ if (abval < 1024)
+ unit = NONE;
+ else if (abval < 1048576ULL) {
+ unit = KILO;
+ *val /= 1024;
+ } else if (abval < 1073741824ULL) {
+ unit = MEGA;
+ *val /= 1048576;
+ } else if (abval < 1099511627776ULL) {
+ unit = GIGA;
+ *val /= 1073741824ULL;
+ } else if (abval < 1125899906842624ULL) {
+ unit = TERA;
+ *val /= 1099511627776ULL;
+ } else if (abva
Linking causes sendmail gas
I've had this problem across the last two or three releases of FreeBSD. Currently I'm running: bash-2.03$ uname -sr FreeBSD 3.2-RELEASE And whenever I *link* a particular program, sendmail starts complaining! Nov 29 18:55:53 tuva sendmail[36003]: NOQUEUE: SYSERR: putoutmsg (NO-HOST): error on output channel sending "451 fill_fd: before readcf: fd 1 not open: Bad file descriptor": Input/output error Nov 29 18:55:53 tuva sendmail[36003]: NOQUEUE: SYSERR(bwithrow): fill_fd: before readcf: fd 1 not open: Bad file descriptor Nov 29 18:55:57 tuva sendmail[36003]: NOQUEUE: SYSERR(bwithrow): fill_fd: before readcf: fd 2 not open: Bad file descriptor Nov 29 19:23:59 tuva sendmail[40563]: NOQUEUE: SYSERR: putoutmsg (NO-HOST): error on output channel sending "451 fill_fd: before main() initmaps: fd 1 not open: Bad file descriptor": Input/output error Nov 29 19:23:59 tuva sendmail[40563]: NOQUEUE: SYSERR(bwithrow): fill_fd: before main() initmaps: fd 1 not open: Bad file descriptor Nov 29 19:24:02 tuva sendmail[40563]: NOQUEUE: SYSERR(bwithrow): fill_fd: before main() initmaps: fd 2 not open: Bad file descriptor Nov 29 19:24:47 tuva sendmail[42779]: NOQUEUE: SYSERR: putoutmsg (NO-HOST): error on output channel sending "451 fill_fd: before readcf: fd 1 not open: Bad file descriptor": Input/output error Nov 29 19:24:47 tuva sendmail[42779]: NOQUEUE: SYSERR(bwithrow): fill_fd: before readcf: fd 1 not open: Bad file descriptor Nov 29 19:25:01 tuva sendmail[42779]: NOQUEUE: SYSERR(bwithrow): fill_fd: before readcf: fd 2 not open: Bad file descriptor The link line looks like this (with the names changed to protect the innocent): gcc -o /someplace/thing /someplace/thingMain.o /someplace/os_host.o /someplace/host_stubs.o /someplace/os_host_stubs.o -L/someplace -lsystem -lcommands -lshow -lnewshow -lndm -lscripts -lndmmql -lsystem -lmql -lmib -lmibdb -ltype -ltcllite -lutil -ledit -lcompat Why would linking a program cause sendmail to complain? I'm suspicious that it isn't *entirely* a sendmail problem, since it is triggered by normal system activity unrelated to mail processing. If nothing else it suggest a possible denial-of-service attack doesn't it? Suggestions? Comments? Searching through the archives shows that at least one other person has this problem besides me, and I haven't found a solution posted. Reference follow: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1894326+1897263+/usr/local/www/db/text/1999/freebsd-questions/19990509.freebsd-questions -- Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
Dag-Erling Smorgrav wrote: > > Luigi Rizzo <[EMAIL PROTECTED]> writes: > > > The attached patch prevents switching into promiscuous mode when > > > running in "Network secure mode" (securelevel 3 or higher). > > > > What happens with yout patch if i need to run an mrouted on such a > > machine ? > > It'll crash and burn, which demonstrates the inadequacy of the secure > level mechanism. Or you start mrouted before going to securelevel 3. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
| >I'm fairly certain that rpc.lockd is included with Darwin from Apple, | >I've not closely compared it to what we have in -STABLE or -CURRENT | >to see if it actually works. | | It doesn't, sorry... if someone gets a *BSD version of NFS locking operating | I'd help see it into Darwin. | | BTW, is anyone working on NFS Version 4 for BSD? Rick? A few of us talked about this on IRC a few weeks ago and it was decided that when/if we implement NFSv4 it would have to be from scratch. A pretty big task. -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
random (6)
I have a small patch that adds an option (-s) to the random command. It prints one random line out of every _denominator_ lines to stdout. For example, if you feed it an ls of /bin (32 files) to stdin, with "random -s 4" you will get series of 8 (=32/4) random filenames from /bin. dalroi * cd /bin dalroi * ls|random -s 4 chio dd domainname hostname mv red rmail test If anybody is interested I'll send it, according to the guidelines (But then I'll have to read up a bit on them first, this is my first FreeBSD patch). -- Alban Hertroys http://wit401310.student.utwente.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Install a BSD and become religious. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SYN flood and freebsd?
On Mon, 29 Nov 1999, Mark D. Anderson wrote: > i've searched around deja and freebsd.org and come up wanting > (email archives show rarely show resolutions...). > > what is the current status in stable and latest regarding > defense against SYN flood, and how is it implemented? > > i found some discussion regarding the inadequacy of the "SYN cookie" > defense added to linux -- i couldn't make out whether that > fix has actually been withdrawn from linux or not. > i also didn't find an explanation of exactly what was bad about > it -- something about firewalls or NAT. > see for example: > http://x41.deja.com/getdoc.xp?AN=491586304&CONTEXT=942635225.1891434518&hitnum=26 I can't comment about the SYN-cookie approach, since I haven't heard about its pitfalls. > and openbsd has apparently settled on a random dropping of > old half-open connections. > > appreciate some clarification on this, as well as pointers > to where answers to things like this might be found, for > those of us who don't want to run grep through kernel sources. There was some discussion about this on freebsd-net or freebsd-hackers in September 1996 which can be reviewed by using the mail list search page at http://www.freebsd.org/search/search.html. Anyway, the CVS history gives the definitive answer for which you are looking. The pages at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c and http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket2.c shows that random drop was implemented (see tcp_input.c versions 1.54 & 1.55 and uipc_socket2.c versions 1.15 & 1.16). Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- [EMAIL PROTECTED] Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] Teaching Assistant, ComS 652 Distributed Operating Systems http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Getting structures from kernelspace to userspace
In the embedded system I'm working on, I have a need to get detailed hard
drive information in a userland process. Specifically, I need the contents
of all the values in wddrives[].
While I've made it work, I've run into a few difficulties. If someone thinks
this is useful enough, I'll clean it up to make it more presentable for
inclusion, as well as a port to the ATA driver.
I added the following routine to sys/i386/isa/wd.c :
static intsysctl_hw_wddrives SYSCTL_HANDLER_ARGS{
int error=0;
int i;
for (i=0;i
#include
static struct disk wddrives[NWD]; /* table of units */
void foo(void) {
unsigned int len;
int i;
len = sizeof(struct disk) * NWD;
for (i=0;i
SYN flood and freebsd?
(I've struck out now on freebsd-security and freebsd-net, now trying freebsd-hackers) i've searched around deja and freebsd.org and come up wanting (email archives show rarely show resolutions...). what is the current status in stable and latest regarding defense against SYN flood, and how is it implemented? i found some discussion regarding the inadequacy of the "SYN cookie" defense added to linux -- i couldn't make out whether that fix has actually been withdrawn from linux or not. i also didn't find an explanation of exactly what was bad about it -- something about firewalls or NAT. see for example: http://x41.deja.com/getdoc.xp?AN=491586304&CONTEXT=942635225.1891434518&hitnum=26 and openbsd has apparently settled on a random dropping of old half-open connections. appreciate some clarification on this, as well as pointers to where answers to things like this might be found, for those of us who don't want to run grep through kernel sources. -mda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message -- End Forwarded Message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
:I can't help with the code either - what little time I have available :is going towards the SMP project. I will be shorting beginning work ^ shortly. Bleh. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
:Well, I am starting to get pretty seriously involved. It looks pretty :easy, just a lot of small details (this is the kind of coding I like :) : :A couple of issues need to be worked out. First I need to backport :the FH open/stat/etc. calls to -STABLE. The main reason for this is that :... I can't help with the code either - what little time I have available is going towards the SMP project. I will be shorting beginning work work on another startup and consulting on a second (but that won't stop me from continuing to badger core to remove the idiotic extra restrictions they still have on my commit privs). But I do I have time to test patchsets as your work progresses. My test boxes are currently split into a -stable test box and a -current test box so I can test under both. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
Luigi Rizzo <[EMAIL PROTECTED]> writes: > > The attached patch prevents switching into promiscuous mode when > > running in "Network secure mode" (securelevel 3 or higher). > What happens with yout patch if i need to run an mrouted on such a > machine ? It'll crash and burn, which demonstrates the inadequacy of the secure level mechanism. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
> The attached patch prevents switching into promiscuous mode when > running in "Network secure mode" (securelevel 3 or higher). What happens with yout patch if i need to run an mrouted on such a machine ? cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
[moving from -ipfw and -arch to -hackers]
Tony Landells <[EMAIL PROTECTED]> writes:
> One concern I would have with that is that there are a lot of tools
> built on BPF that I would prefer to not be able to run on the firewall.
Don't confuse BPF with promiscuous mode. BPF is simply a programmable
packet filter and does not in and of itself represent a security risk.
Promiscuous mode allows a host to capture packets not destined to
itself, and may represent a security risk on shared media networks
(e.g. 10Base2, unswitched 10BaseT).
The attached patch prevents switching into promiscuous mode when
running in "Network secure mode" (securelevel 3 or higher).
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.77
diff -u -r1.77 if.c
--- if.c1999/11/22 02:44:51 1.77
+++ if.c1999/11/29 12:52:07
@@ -908,6 +908,8 @@
int error;
if (pswitch) {
+ if (securelevel >= 3)
+ return (EPERM);
/*
* If the device is not configured up, we cannot put it in
* promiscuous mode.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cdrom speed adjustment ioctl
On Mon, Nov 29, 1999 at 11:06:53AM +, [EMAIL PROTECTED] wrote: > >There would not be such a thing for SCSI cdrom's too? It would probably > >squeeze a few extra months out of my cdrom player. On some cd's (mainly ones > >you get with magazines and books) it's making gut-wrenching noises and > >spinning up and down all the time. > > No idea if there's an ioctl, but you should be able to do this with camcontrol, > e.g. if your drive supports the MMC Set CD Speed command: > > camcontrol -n cd -u -c "BB 00 XX XX 00 00 00 00 00 00 00 00" > > Where is the number of the CD device you want to set the speed of, and XX XX > is the hex of the desired speed in kbps. Is this a project for a rainy day I see before me? cdspeed(1) Imaginary Man Page cdspeed(1) NAME cdspeed - control (slow down!) the speed that a cdrom will operate at. SYOPSIS cdspeed YADDA yadda yadda yadda FreeBSD 3.3 November 29 19991 -- Mike Bristow, Geek At Large ``Beware of Invisible Cows'' GK/RT0011 - Essential reading for train-spotters. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: cdrom speed adjustment ioctl
>There would not be such a thing for SCSI cdrom's too? It would probably >squeeze a few extra months out of my cdrom player. On some cd's (mainly ones >you get with magazines and books) it's making gut-wrenching noises and >spinning up and down all the time. No idea if there's an ioctl, but you should be able to do this with camcontrol, e.g. if your drive supports the MMC Set CD Speed command: camcontrol -n cd -u -c "BB 00 XX XX 00 00 00 00 00 00 00 00" Where is the number of the CD device you want to set the speed of, and XX XX is the hex of the desired speed in kbps. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more softpower/apm..
Hi, Bryan.
> Does anyone know if its possible for FreeBSD to execute a halt from
> the powerswitch?
>
> >From reading the apmd doco, this is what apmd is suppose to do, handle
> events from the APM bios and execute according to apmd.conf
>
> If an ATX powersupply/motherboard is setup to suspend on power button,
> (i.e hold down for 5 seconds to turn off)
> can FreeBSD pick up this button press and do clean shutdown?
> I tried running apmd -dv, but I cant seem to see any events from the power
> button pressing.
Apmd was developed for you :-)
You can reject suspend request on power button and execute shutdown -p
instead.
For example, My box was setup to suspend on power button and issues
USERSUSPENDREQ, so my apmd.conf is like this;
apm_event USERSUSPENDREQ {
reject;
exec "shutdown -p now";
}
Have fun!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: cdrom speed adjustment ioctl
> > I've just hacked a new ioctl into the ATAPI cdrom driver, which > lets the user to specify (pronounce: ``slow down'' :) the speed > of todays' extremely high speed drives. > There would not be such a thing for SCSI cdrom's too? It would probably squeeze a few extra months out of my cdrom player. On some cd's (mainly ones you get with magazines and books) it's making gut-wrenching noises and spinning up and down all the time. Interesting fact: the FreeBSD cdrom are never a problem. Does cdrom.com balance them before shipping them? Kees Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Sun, 28 Nov 1999, Arun Sharma wrote:
>
> [ For some reason, this post through muc.lists.freebsd.hackers gateway didn't
> show up on the mailing list. Forwarding it to the mailing list.. ]
>
> On Thu, 04 Nov 1999 20:38:50 -0800, Mike Smith <[EMAIL PROTECTED]> wrote:
> > > I don't see any examples in sys/modules. The SYSCTL_INT macros eventually
> > > expands to DATA_SET which puts certain data in a different ELF section.
> >
> > You don't do anything magic at all; it's handled invisibly by the
> > kernel linker.
>
> I was thinking about implementing SMP cpu stats using sysctl today and
> I have a question - can I create sysctl nodes dynamically ?
>
> i.e.
>
> for (cpu = 0; cpu < get_num_cpus(); cpu++) {
> /* create sysctl node here ? */
> }
Yes. See for example linux emulator or my SPY module:
http://www.freebsd.org/~abial/spy
You can also create whole new branches, as the second example shows.
Andrzej Bialecki
// <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
Well, I am starting to get pretty seriously involved. It looks pretty easy, just a lot of small details (this is the kind of coding I like :) A couple of issues need to be worked out. First I need to backport the FH open/stat/etc. calls to -STABLE. The main reason for this is that I am developing rpc.lockd for out main servers, which for obvious reasons run -STABLE. Second I need some input and advice. Looking at Solaris' lockd, they use NLM version 2 as a method of IPC between lockd and statd this is an undocumented interface. I would suggest a unix domain socket as an alternate method (any objections). This I feel has a number of advantages, such as providing an easier Kernel interface to the user-land lock manager (it is my reading that rpc.lockd should perform the tasks of maintaining local locks on remote servers as well as managing locks on local filesystems from remote servers.) Thank you to the person who provided the Open-Group Spec. I had read that it was available from them in the NFS3 RFC, I just figured I would need to pay much $$$ to actually get it :) -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
At 1:36 PM -0800 11/25/99, C. Stephen Gunn wrote: >On Mon, Nov 22, 1999 at 02:07:58PM -0800, Alfred Perlstein wrote: >> > Does NetBSD have a working rpc.lockd... that would make this much easier. >> >> at a glance at http://cvsweb.netbsd.org/... no. >I'm fairly certain that rpc.lockd is included with Darwin from Apple, >I've not closely compared it to what we have in -STABLE or -CURRENT >to see if it actually works. It doesn't, sorry... if someone gets a *BSD version of NFS locking operating I'd help see it into Darwin. BTW, is anyone working on NFS Version 4 for BSD? Rick? -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
